💬 NLP

LLMStructBench: Benchmarking Large Language Model Structured Data Extraction

Dit paper introduceert LLMStructBench, een nieuw benchmark voor het evalueren van het vermogen van grote taalmodellen om gestructureerde JSON-data te extraheren, waarbij wordt vastgesteld dat de keuze van de promptstrategie belangrijker is dan het modelgrootte voor het garanderen van structurele validiteit.

Oorspronkelijke auteurs: Sönke Tenckhoff, Mario Koddenbrock, Erik Rodner

Gepubliceerd 2026-02-17

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Sönke Tenckhoff, Mario Koddenbrock, Erik Rodner

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat je een enorme bibliotheek hebt vol met rommelige, handgeschreven briefjes van mensen. Op sommige briefjes staat: "Ik wil graag een laptop lenen, mijn naam is Jan, en ik heb hem nodig tot vrijdag." Op andere briefjes staat een wirwar van zinnen over een ziekteverlof of een projectverlenging.

Jouw doel is om al die rommelige tekst om te zetten in een strakke, digitale lijst (een JSON-bestand) die een computer direct kan begrijpen en verwerken. Bijvoorbeeld: {"naam": "Jan", "item": "laptop", "datum": "vrijdag"}.

Dit is precies wat LLMStructBench onderzoekt. Het is een test voor de slimste kunstmatige intelligenties (LLMs) om te zien hoe goed ze die rommelige tekst in een strakke lijst kunnen zetten.

Hier is de uitleg in simpele taal, met een paar creatieve vergelijkingen:

1. Het Probleem: De "Vertaler" die soms hallucineert

Stel je voor dat je een vertaler hebt die heel goed Engels spreekt, maar als je hem vraagt om een recept in een strakke tabel te zetten, doet hij soms raar.

Soms schrijft hij de hele tabel in een verhaal (de computer kan het niet lezen).
Soms vergeet hij een ingrediënt (de lijst is incompleet).
Soms schrijft hij "suiker" in plaats van "zout" (de structuur klopt, maar de inhoud is fout).

De auteurs van dit paper zeggen: "We weten niet precies welke vertaler het beste is, of of het helpt als je de vertaler een heel strakke sjabloon geeft."

2. De Test: Een "Kookwedstrijd" met 22 Chefs

Om dit uit te zoeken, hebben de onderzoekers een enorme wedstrijd georganiseerd:

De Ingrediënten: Ze hebben 995 verschillende scenario's gemaakt (zoals een klacht over een defecte printer, een ziekteverlofaanvraag, of een vergaderinschrijving).
De Chefs: Ze hebben 22 verschillende AI-modellen uitgenodigd (van kleine, snelle modellen tot gigantische, dure modellen).
De Sjablonen: Ze hebben de chefs verschillende instructies gegeven. Sommigen kregen alleen een simpele zin: "Zet dit in een lijstje." Anderen kregen een heel gedetailleerd bouwplan met voorbeelden.

3. De Grote Ontdekking: De Chef is minder belangrijk dan het Recept!

Dit is het meest verrassende resultaat van de paper. Je zou denken dat de grootste, duurste AI (de "Superchef") altijd het beste zou zijn. Maar dat bleek niet zo te zijn.

De Analogie: Het is alsof je een beroemde kok vraagt om een cake te bakken. Als je hem alleen zegt: "Maak een cake," maakt hij misschien een rommelige brij. Als je hem echter een perfect recept geeft met foto's van hoe de cake eruit moet zien, maakt hij zelfs met minder ervaring een perfecte cake.
De Conclusie: De manier waarop je de AI vraagt (de "prompt-strategie") is belangrijker dan hoe groot of slim de AI zelf is. Een klein model met het juiste recept deed het vaak beter dan een groot model met een slecht recept.

4. Twee Soorten Fouten: De "Lege Bak" vs. De "Verkeerde Ingrediënt"

De onderzoekers keken naar twee soorten fouten:

Structuurfouten (De lege bak): De AI gaf helemaal geen lijstje, of het lijstje was zo kapot dat de computer het niet kon openen. Dit is een ramp voor een computer.
Inhoudsfouten (Het verkeerde ingrediënt): De AI gaf een perfect lijstje, maar schreef "suiker" in plaats van "zout". De computer kan het bestand wel openen, maar het resultaat is verkeerd.

Wat ze zagen:

Als je de AI heel strikt instructies geeft (het "PJ+" recept), krijg je bijna altijd een perfect lijstje (geen structuurfouten).
MAAR: De AI maakt dan vaker inhoudsfouten. Het lijkt alsof de AI zo gefocust is op het volgen van de regels, dat hij soms de betekenis van de tekst een beetje kwijtraakt.
Als je de AI vrijer laat (het "P" recept), maakt hij vaker structuurfouten (geen lijstje), maar als hij er wel een maakt, is de inhoud vaak beter.

5. De Grootte van de AI: Meer is niet altijd beter

Je zou denken: "Hoe groter de AI, hoe slimmer."

Bij het begrijpen van tekst (inhoud) helpt een grotere AI zeker.
Maar bij het volgen van regels (het maken van een perfect lijstje) maakt de grootte minder uit dan je denkt. Een klein model dat goed getraind is op het volgen van instructies, kan een gigantisch model verslaan.

Samenvatting voor de Praktijk

Stel je voor dat je een bedrijf runt en je wilt AI gebruiken om e-mails om te zetten in bestellingen.

Koop niet direct de duurste, grootste AI.
Investeer in het vinden van de juiste instructies. Leer de AI precies hoe je het bestandje wilt zien.
Wees voorzichtig: Als je de AI dwingt om perfect te zijn, kan hij soms de inhoud verdraaien. Je moet misschien een extra controle toevoegen om te kijken of de "suiker" wel echt "suiker" is.

Kortom: In de wereld van AI is het niet alleen belangrijk wie je hebt (het model), maar vooral hoe je met hem praat (de prompt). Een goed gesprek is vaak belangrijker dan een groot brein.

Probleemstelling

Het extraheren van gestructureerde informatie uit natuurlijke taal (bijv. e-mails, rapporten) naar formaten zoals JSON is essentieel voor toepassingen in human resources, financiën, logistiek en ETL-werkstromen (Extract, Transform, Load). Hoewel Large Language Models (LLM's) hier steeds vaker voor worden ingezet, is hun betrouwbaarheid onvoldoende onderzocht. Bestaande systemen falen vaak in het produceren van outputs die zowel syntactisch geldig (volledig JSON-compliant) als semantisch correct (waardevolle gegevens zijn juist) zijn. Downstream-systemen vertrouwen vaak op een perfecte output bij de eerste poging, wat zowel de structuur als de inhoud cruciaal maakt. Bestaande benchmarks focussen vaak alleen op schema-conformiteit of synthetische teksten, maar missen een realistische evaluatie van de balans tussen structuur en semantische nauwkeurigheid in open-source modellen.

Methodologie

1. Dataset: LLMStructBench
De auteurs hebben een open dataset ontwikkeld bestaande uit 995 handmatig geverifieerde samples.

Opbouw: De dataset omvat 5 verschillende use-cases (van IT-ondersteuning tot leningverzoeken) met variërende complexiteit (van vlakke sleutel-waarde paren tot diep geneste objecten en arrays).
Generatie: De data is synthetisch gegenereerd met GPT-4o (van JSON naar natuurlijke taal) en vervolgens handmatig gecontroleerd en opgeschoond om inconsistenties tussen tekst en schema te verwijderen.
Doel: Het simuleren van realistische scenario's zoals e-mails en verzoeken die in bedrijfsprocessen voorkomen.

2. Evaluatie-Setup

Modellen: Er zijn 22 open-source LLM's getest (families: Qwen3, Phi, Gemma3, Deepseek-R1, Llama3) met parametergroottes variërend van 0,6 tot 70 miljard. Daarnaast is GPT-4o opgenomen als gesloten referentie.
Prompting Strategieën: Vijf verschillende strategieën zijn geëvalueerd om te bepalen welke de meest betrouwbare JSON-outputs oplevert:
- Variatie in het instellen van de API format parameter (op "json" of een JSON-schema).
- Variatie in de instructies binnen de prompt (expliciete schema-instructies en voorbeelden).
- De beste strategieën bleken P (expliciete instructie met schema en voorbeeld) en PJ+ (API-formaat instelling + prompt met schema en voorbeeld).

3. Kwaliteitsmetrieken
De auteurs introduceerden een nieuwe set metrieken om zowel token-niveau als document-niveau prestaties te meten:

F1micro (Token-niveau): Een gewogen score die rekening houdt met ontbrekende sleutels (Missing Key), ontbrekende waarden (Missing Value) en verkeerde waarden (Wrong Value). Het straalt partial credit uit voor type-conversies of kleine tekstafwijkingen.
DOCmicro (Document-niveau): De fractie van volledig correcte generaties (zonder syntactische fouten of lege outputs). Dit meet de "brittleness" van het model.
Composiet Score: Een gewogen som van F1micro en DOCmicro ( $\lambda=0.5$ ) om modellen op één schaal te rangschikken.

Belangrijkste Bijdragen

LLLMStructBench Dataset: Een open, handmatig geverifieerde benchmark met 995 samples voor het evalueren van gestructureerde data-extractie in realistische scenario's.
Nieuwe Metrieken: Een evaluatieframework dat zowel syntactische validiteit als semantische nauwkeurigheid kwantificeert, waardoor het mogelijk is om foutprofielen (structuur vs. inhoud) te analyseren.
Uitgebreide Vergelijking: Een systematische evaluatie van 22 open-source modellen tegenover GPT-4o, met een focus op de impact van prompt-engineering versus modelgrootte.

Resultaten

1. Prompting Strategie is Cruciaal
De keuze van de prompting-strategie bleek belangrijker dan de modelgrootte.

Strategie P (expliciete instructie met schema) leverde vaak de beste balans op voor grotere modellen, maar faalde catastraal voor sommige families (zoals Phi).
Strategie PJ+ (API-schema + prompt) garandeerde bijna altijd een parseerbare JSON-structuur (hoge DOCmicro), maar verplaatste de fouten naar semantische inhoud (meer "Wrong Value" fouten).
Voor kleine of onbetrouwbare modellen was het gebruik van een schema in de prompt essentieel om structurele validiteit te bereiken.

2. Modelgrootte en Prestaties

Er is geen strikte monotoon relatie tussen parameteraantal en totale score.
Uitzonderingen: Kleinere modellen zoals Gemma3-12B en Qwen3-1.7B presteerden verrassend goed, soms beter dan veel grotere 70B-modellen. Dit suggereert dat data-curatie en architectuur efficiëntie belangrijker kunnen zijn dan pure schaal.
Foutprofielen:
- Missing Keys (MK): Verdwenen grotendeels bij modellen groter dan 7-8B parameters.
- Wrong Values (WV): Dit bleef de hoofdknelpunt voor alle modellen, zelfs de grootste. Zelfs de beste modellen maakten semantische fouten in ongeveer de helft van de tests. Grotere parametergroottes (>14B) leverden slechts marginale verbeteringen in waarde-nauwkeurigheid.

3. Vergelijking Open vs. Gesloten
GPT-4o presteerde goed, maar vertoonde geen duidelijke overwinning op de beste open-source modellen (zoals Gemma3-27B). Dit onderstreept dat open-weight systemen nu concurrerend zijn voor lokale, privacy-bewuste implementaties.

Betekenis en Conclusie

Het paper concludeert dat voor ETL-toepassingen en data-integratie de combinatie van modelarchitectuur en prompting-strategie minstens zo belangrijk is als de schaal van het model.

Voor structurele validiteit (zorgen dat de JSON parsebaar is) is het gebruik van schema-instructies (PJ+) cruciaal, vooral voor kleinere modellen.
Voor semantische nauwkeurigheid blijft het een uitdaging; zelfs de beste modellen hebben nog steeds last van verkeerde waarden, wat suggereert dat post-processing validatie of gespecialiseerde fine-tuning nodig is voor productie-omgevingen.
De benchmark biedt een realistische basis voor onderzoekers en practitioners om de juiste modellen en prompts te selecteren voor specifieke taken, waarbij ze niet blindelings hoeven te vertrouwen op de grootste modellen.