Prompts voor data-extractie uit ongestructureerde tekst

De uitdaging van ongestructureerde data

Wanneer we een LLM inzetten voor data-extractie, verschuift onze rol van programmeur naar instructeur. Het model begrijpt de semantiek van de tekst, maar heeft sturing nodig om de output in een machinaal leesbaar formaat te dwingen. Zonder strakke richtlijnen zal een LLM hallucineren (data verzinnen die niet in de tekst staat), sleutelnamen (keys) in JSON willekeurig veranderen, of extra conversationele tekst toevoegen zoals "Hier is de JSON die je vroeg:".

Om deze problemen te voorkomen, moeten we onze prompts strategisch opbouwen. In dit artikel behandelen we de essentiële pijlers van een goede extractie-prompt: velddefinities, omgaan met missende waarden, few-shot prompting, en foutdetectie. Bovendien leveren we direct bruikbare sjablonen voor veelvoorkomende extractietaken.

1. Velden definiëren en het schema afdwingen

De absolute basis van een succesvolle extractie is het wegnemen van ambiguïteit over het gewenste outputformaat. Je kunt niet volstaan met de instructie "geef me een JSON met naam en adres". Je moet een hard contract opstellen tussen jou en het LLM.

Dit doe je door het verwachte schema expliciet in de systeemprompt op te nemen. Vaak werkt een TypeScript-interface of een versimpeld JSON-schema het beste. Het dwingt het model om na te denken over datatypes (string, boolean, array, number). Bekijk ook onze uitgebreide gids over output-formaten afdwingen voor meer technische implementaties rondom JSON mode en function calling.

Jij bent een nauwkeurige data-extractie API. 
Jouw enige taak is het extraheren van informatie uit de onderstaande tekst en dit te retourneren als een valide JSON-object.

Gebruik EXACT dit JSON-schema:
{
  "klantnaam": "string", // De volledige bedrijfsnaam of naam van de persoon.
  "totaalbedrag": "number", // Het eindbedrag inclusief BTW. Gebruik een punt voor decimalen, geen komma.
  "valuta": "string", // De drieletterige ISO-code (bijv. EUR, USD).
  "factuur_betaald": "boolean" // true als uit de tekst blijkt dat de factuur al is voldaan, anders false.
}

Retourneer UITSLUITEND de JSON. Geen inleiding, geen uitleg, geen markdown-blokken zoals ```json.

2. Omgaan met ontbrekende waarden (Missing Values)

Een van de grootste risico's bij het gebruik van LLM's voor extractie is hun neiging om behulpzaam te willen zijn. Als een bepaald stukje informatie (bijvoorbeeld een einddatum) niet in de tekst staat, zal een ongetraind model vaak proberen dit te extrapoleren of te verzinnen op basis van algemene kennis. In de data-engineering wordt dit een hallucinatie genoemd, en het corrumpeert je database.

Je moet expliciete ontsnappingsroutes (escape hatches) in je prompt inbouwen voor ontbrekende data. Instrueer het model glashelder over wat er moet gebeuren als informatie ontbreekt.

REGELS VOOR ONTBREKENDE DATA:
- Verzin NOOIT informatie. 
- Leid geen data af die niet expliciet of impliciet in de brontekst staat.
- Als een veld ontbreekt, wijs dan expliciet de waarde `null` toe (gebruik geen "onbekend", "N/A" of lege strings "").
- Als een array leeg hoort te zijn, retourneer dan `[]`.

Door het model te dwingen null te gebruiken, kun je in je backend eenvoudig valideren welke data wel en niet met succes is opgehaald, zonder dat je allerlei tekstuele variaties ("niet gevonden", "NVT", "onbekend") hoeft te parsen.

3. De kracht van Few-Shot voorbeelden kiezen

Hoewel moderne modellen zoals GPT-4 of Claude 3.5 Sonnet uitstekend zijn in zero-shot extractie (extractie zonder voorbeelden), neemt de betrouwbaarheid gigantisch toe wanneer je few-shot prompting toepast. Bij complexe domeinen, zoals juridische teksten, is dit zelfs verplicht.

Het geheim van een goede few-shot prompt voor extractie zit in het kiezen van de *juiste* voorbeelden. Geef niet alleen de 'happy flow' (waarin alle data netjes aanwezig is). Zorg dat je voorbeelden bevatten waarin de tekst extreem rommelig is, of waarin juist heel veel velden ontbreken, zodat het model in de praktijk ziet hoe het null moet toepassen.

Een typische structuur ziet er als volgt uit:

• Systeeminstructie: De regels en het schema.
• Voorbeeld 1 (User): Een standaard stuk tekst.
• Voorbeeld 1 (Assistant): De perfect geëxtraheerde JSON.
• Voorbeeld 2 (User): Een tekst met ontbrekende velden en verwarrende typo's.
• Voorbeeld 2 (Assistant): De correcte JSON met null waarden waar nodig.
• Huidige input (User): De tekst die je nu wilt verwerken.

4. Extractiefouten systematisch opsporen

Hoe goed je prompt ook is, LLM's zijn stochastisch; de output kan variëren. Om data-extractie robuust te maken voor productie, mag je er nooit vanuit gaan dat de output 100% correct is. Er is een validatielaag nodig tussen het LLM en je database.

Als je complexe extracties over meerdere stappen wilt valideren, overweeg dan het gebruik van prompt chaining, waarbij een tweede model puur de taak krijgt om de output van het eerste model te verifiëren. Voor structurele validatie (klopt de JSON, zijn de datatypes correct?) raden we sterk aan om in je applicatiecode gebruik te maken van bibliotheken zoals Pydantic (voor Python) of Zod (voor TypeScript). Dit onderwerp wordt diepgaand behandeld op ons leerplatform over geavanceerde datapijplijnen.

Wanneer een parsing error optreedt in je code (bijvoorbeeld het LLM stuurde een string in plaats van een getal), kun je de foutmelding direct terugvoeren aan het LLM met de instructie: "De vorige output bevatte een fout: [error message]. Corrigeer de JSON."

5. Herbruikbare Promptsjablonen

Hieronder vind je drie uitvoerig geteste systeemprompts voor veelvoorkomende extractiescenario's. Je kunt deze direct kopiëren en in je eigen applicaties gebruiken.

Sjabloon 1: Facturen en Kwitanties (Financieel)

Facturen zijn berucht omdat ze visueel gestructureerd zijn (tabellen), maar als ongestructureerde tekst worden ingelezen via OCR of PDF-extractie.

Jij bent een expert in financiële administratie. Extraheer de data uit de onderstaande OCR-tekst van een factuur.

REGELS:
1. Volg strikt het onderstaande JSON-schema.
2. Bedragen moeten nummers zijn, zonder valutasymbolen (bijv. 1250.50).
3. Datums moeten geformatteerd worden in YYYY-MM-DD. Als de dag of maand onbekend is, retourneer null.
4. Verzin geen data. Als een waarde niet te vinden is, retourneer `null`.
5. Negeer algemene voorwaarden of reclame-teksten in het document.

VERWACHT JSON-SCHEMA:
{
  "factuurnummer": "string | null",
  "factuurdatum": "string (YYYY-MM-DD) | null",
  "leverancier": {
    "naam": "string | null",
    "kvk_nummer": "string | null",
    "btw_nummer": "string | null"
  },
  "totaal_exclusief_btw": "number | null",
  "totaal_inclusief_btw": "number | null",
  "btw_bedrag": "number | null",
  "regelitems": [
    {
      "omschrijving": "string",
      "aantal": "number | null",
      "stukprijs": "number | null",
      "totaal": "number | null"
    }
  ]
}

Retourneer enkel en alleen de rauwe JSON. Geen andere tekst.

Sjabloon 2: E-mails en Actiepunten (Communicatie)

Bij het extraheren van data uit e-mails wil je vaak voorbij de formele begroetingen kijken en direct naar de kern: wie moet wat doen, en tegen wanneer?

Analyseer de onderstaande e-mail(thread) en extraheer de kerninformatie en actiepunten.

REGELS:
- Focus alleen op zakelijke afspraken en acties. Negeer koetjes en kalfjes.
- Identificeer de hoofd-afzender (degene die de mail initieert).
- Een 'actiepunt' is een specifieke taak die aan een specifiek persoon is toegewezen.
- Als een deadline vaag is (bijv. "volgende week"), probeer dit om te zetten naar een concrete datum in ISO-formaat (YYYY-MM-DD) ALS de context de huidige datum vermeldt. Anders, gebruik `null`.

VERWACHT JSON-SCHEMA:
{
  "onderwerp_samenvatting": "string (max 10 woorden)",
  "urgentie": "Laag" | "Normaal" | "Hoog",
  "hoofd_afzender": "string (Naam of e-mailadres) | null",
  "actiepunten": [
    {
      "taak_beschrijving": "string",
      "toegewezen_aan": "string (Naam persoon) | null",
      "deadline": "string (YYYY-MM-DD) | null"
    }
  ]
}

Geef uitsluitend de JSON als output.

Sjabloon 3: Complexe Medische of Technische Rapporten

Rapporten vereisen vaak extractie van geneste data en het isoleren van specifieke bevindingen uit pagina's vol jargon.

Je bent een data-assistent voor technische analyses. Lees het onderstaande inspectierapport en extraheer uitsluitend de geconstateerde defecten en de bijbehorende aanbevelingen.

CRITISCHE INSTRUCTIES:
- Zoek naar de secties "Bevindingen", "Defecten", "Risico's" of vergelijkbare synoniemen.
- Neem geen oplossingen op als defecten, en vice versa.
- Classificeer de ernst van elk defect op basis van de tekst. Als de ernst niet expliciet wordt genoemd, schat deze dan niet in, maar retourneer `null`.
- Verwijs (indien mogelijk) naar de paginanaam of het alineanummer als bron.

VERWACHT JSON-SCHEMA:
{
  "rapport_titel": "string | null",
  "inspectie_datum": "string (YYYY-MM-DD) | null",
  "geconstateerde_defecten": [
    {
      "korte_omschrijving": "string",
      "ernst": "Kritiek" | "Matig" | "Laag" | null,
      "voorgestelde_oplossing": "string | null",
      "bron_alinea_of_pagina": "string | null"
    }
  ]
}

Retourneer uitsluitend valide JSON.

Conclusie

Data-extractie uit ongestructureerde tekst is een van de meest waardevolle toepassingen van Large Language Models in het hedendaagse bedrijfsleven. Door het model strak aan banden te leggen met duidelijke schema's, strikte regels voor ontbrekende waarden en goedgekozen few-shot voorbeelden, transformeer je een tekstgenerator in een betrouwbare data-parser. Onthoud altijd: stuur de juiste prompt in, en controleer de JSON-output systematisch in je programmacode voordat je deze opslaat in je database.