Information Extraction

Information extraction dækker opgaven at læse ustruktureret eller halvstruktureret tekst og aflevere et defineret datasæt: felter, entities og relationer mellem dem. Output er ikke prosa, men en struktur du kan validere, gemme i en database og bygge videre på.

Grænsen mod klassifikation går ved output. Klassifikation vælger en label fra et kendt sæt, mens extraction finder værdier der ikke kendes på forhånd og skal lokaliseres i teksten. Grænsen mod summarisering går ved troværdighed: et resumé må omformulere, et ekstraheret beløb skal stå i kilden.

Use-casen forudsætter at teksten allerede foreligger. Skanning, OCR og layoutparsing hører til dokumentbehandling og leverer input. RAG er heller ikke det samme: der søger du efter relevant tekst til et svar, her behandler du et kendt dokument felt for felt.

Et typisk flow har fire led: normalisering af input, definition af schema, kald til modellen og validering af resultatet.

Schemaet er kernen. Du beskriver felterne som JSON Schema eller en Pydantic-model, med datatype, om feltet er påkrævet, og en kort beskrivelse af hvad der tæller som en gyldig værdi. Både GPT-5.6 Sol og Claude Sonnet 5 kan bindes til et schema via structured output eller tool calls, så svaret er syntaktisk gyldig JSON.

Syntaktisk gyldighed siger intet om indholdet. Kvaliteten afgøres af hvor præcist feltbeskrivelserne afgrænser de tvetydige tilfælde, af hvordan lange dokumenter deles i chunks, og af om modellen har lov til at markere et felt som ukendt i stedet for at gætte.

Ved store dokumenter betaler det sig ofte at køre to trin. Først lokaliserer du de afsnit hvor felterne kan stå, derefter ekstraherer du fra netop de afsnit. Det holder forbruget af context window nede og gør det lettere at spore hvor en værdi kom fra.

Den farligste fejltype er den tavse. Modellen returnerer et gyldigt JSON-objekt med et plausibelt beløb, der ikke findes i dokumentet eller stammer fra den forkerte række i en tabel. Fejlen ligner et resultat, ikke en fejl, og opdages først længere nede i pipelinen.

Manglende data håndteres typisk dårligt. Står fakturanummeret ikke i teksten, finder modellen gerne et tal der ligner. Feltet skal derfor kunne have værdien null, og prompten skal gøre det eksplicit at ingen værdi er et acceptabelt svar.

Normalisering er en anden kilde til fejl. Datoer, tusindtalsseparatorer, negative tal i parentes og valutaer skrevet på flere måder bliver ofte konverteret på gæt. Det er mere robust at bede om værdien præcis som den står, og lave konverteringen i kode bagefter.

Tabeller og flersidede dokumenter presser grænserne. Når en række fortsætter på næste side, eller når kolonneoverskrifter kun står øverst, mister modellen sammenhængen mellem celle og felt.

Extraction skal måles på feltniveau, ikke på dokumentniveau. Byg et gold set med håndannoterede dokumenter der dækker de formater du reelt modtager, og opgør precision og recall per felt. Et gennemsnit på 95 procent kan skjule at et enkelt kritisk felt rammer 60.

Konfidens kan tilnærmes ved at bede modellen returnere det tekstuddrag værdien er hentet fra. Manglende eller ikke-matchende citat er et brugbart signal om hvornår et dokument skal til manuelt gennemsyn.

Kvaliteten flytter sig når prompt, schema eller model ændres. Kør gold-settet igen ved hver ændring, og gem resultaterne, så du kan se hvilke felter der blev bedre og hvilke der blev dårligere.