Modellen kiezen voor data-extractie uit tabellen en CSV

Het geautomatiseerd extraheren en structureren van gegevens uit tabellen, CSV-bestanden en spreadsheets vormt een hardnekkig knelpunt binnen gegevensverwerking. Waar traditionele, deterministische parsers zoals reguliere expressies of vaste scripts direct vastlopen op ontbrekende scheidingstekens, samengevoegde cellen of wisselende kolomvolgordes, bieden moderne taal- en visiemodellen flexibiliteit. Tegelijkertijd introduceert het inzetten van generatieve AI nieuwe risico's: subtiele hallucinaties in numerieke cellen, het overslaan van rijen bij omvangrijke tabellen en onvoorspelbare tokenkosten.

Binnen de bredere taakverdeling van taalmodellen valt tabelextractie onder gespecialiseerde documenttransformatie. Wie wil verkennen hoe deze taak zich verhoudt tot bredere use cases, kan het overzicht van AI-modellen per taak raadplegen voor een systematische vergelijking. In dit artikel analyseren we hoe verschillende modelklassen omgaan met ruimtelijke en tekstuele tabelstructuren, welke specifieke foutmodi optreden bij verschillende bestandsformaten en hoe de afweging tussen precisie, rekentijd en operationele kosten gemaakt moet worden.

Taakdefinitie: Van ongestructureerde cellen naar betrouwbare schema's

Data-extractie uit tabellen bevindt zich op het snijvlak van semantisch tekstbegrip en tweedimensionale structurele reconstructie. In tegenstelling tot reguliere tekstverwerking, waarbij betekenis sequentieel van links naar rechts vloeit, ontleent een individuele cel zijn betekenis aan de kruising van een horizontale rij-entiteit en een verticale kolomdefinitie. Zodra kolomkoppen over meerdere regels zijn verdeeld of cellen zijn samengevoegd, verdwijnt het lineaire verband volledig.

In de praktijk verwerken productiepijplijnen drie fundamenteel verschillende invoerbronnen:

1. Platte tekstuele tabellen: CSV-, TSV- of Markdown-tabellen waarin rijen en kolommen zijn afgebakend met leestekens. De complexiteit zit hier niet in visuele aspecten, maar in inconsistente escaping, geneste komma's binnen aanhalingstekens, wisselende datumformaten en onverwachte regeleinden binnen een cel.

2. Semigestructureerde spreadsheets: Werkbladen waarin menselijke gebruikers opmaak hebben toegevoegd als betekenisdrager. Denk aan kleurcoderingen, samengevoegde kopregels, verborgen kolommen, lege scheidingsrijen en formules die tussentijdse subtotalen berekenen.

3. Visuele en gerenderde tabellen: Tabellen binnen PDF-documenten, scans of schermafbeeldingen. Hier ontbreekt onderliggende structurele markup en moet de ruimtelijke ordening visueel worden herleid voordat extractie kan plaatsvinden.

Het doel van de extractietaak is vrijwel altijd het transformeren van deze heterogene invoer naar een gevalideerd formaat, zoals een strikt JSON-schema of genormaliseerde databaserecords. Wie specifiek zoekt naar technieken om modellen strikt binnen een JSON-schema te laten antwoorden, kan het artikel over modellen kiezen voor gestructureerde uitvoer raadplegen voor diepgaande schemavalidatiemethoden.

Technische eisen: Waar tabelverwerking op stukloopt

Bij het evalueren van AI-modellen voor tabulaire extractie gelden specifieke criteria die sterk afwijken van standaard tekstgeneratie. Een model dat uitblinkt in het schrijven of samenvatten van proza kan volstrekt ongeschikt zijn voor het nauwkeurig parsen van een financiële balansrekening.

1. Tokenisatie en ruimtelijke blindheid

Taalmodellen breken tekst op in tokens via algoritmes zoals Byte-Pair Encoding (BPE). Getallen, witruimtes en leestekens worden hierbij niet uniform behandeld. Een reeks spaties die kolommen uitlijnt in een platte teksttabel kan worden samengevoegd tot één token of juist versplinteren over meerdere subtokens. Hierdoor verliest een puur tekstueel model het overzicht over welke cel onder welke kolomkop staat. Modellen met een sterke code-achtergrond presteren hier doorgaans beter, omdat formele syntaxis en spatie-indents een vast onderdeel zijn van hun trainingsdata.

2. Contextvenster versus aandachtsspreiding

Een CSV-bestand met enkele duizenden rijen overschrijdt al snel tienduizenden tokens. Hoewel moderne modellen omvangrijke contextvensters ondersteunen, treedt bij lange tabellen regelmatig aandachtsverslapping op. Rijen in het midden van het bestand worden overgeslagen, of kolomdefinities uit de eerste regel worden halverwege het document verkeerd gekoppeld. Om te begrijpen hoe contextlengte de aandachtsverdeling en rekenkracht beïnvloedt, legt het artikel over hoe een contextvenster werkt de onderliggende transformermechanismen uit.

3. Numerieke betrouwbaarheid en afrondingen

In tabellen vertegenwoordigen cijfers harde feiten: geldbedragen, percentages, serienummers, IBAN-nummers of datums. Waar een kleine synoniemverwisseling in lopende tekst acceptabel kan zijn, maakt een veranderde decimaal of een weggelaten minteken een datarecord waardeloos. Modellen moeten beschikken over een extreem lage hallucinatiegraad bij het kopiëren van numerieke data en mogen cijfers niet afronden tenzij expliciet geïnstrueerd.

Kandidaatmodellen: Architectuurklassen en geschiktheid

Voor tabel- en CSV-extractie onderscheiden we drie primaire modelcategorieën, elk met specifieke sterktes, beperkingen en operationele kosten.

De keuze hangt sterk af van de representatie van de invoerdata. Wanneer tabellen opgesloten zitten in visuele documenten, is een multimodale benadering vaak robuuster dan het eerst forceren van platte tekst via optische tekenherkenning (OCR). Wie wil bepalen wanneer een vision-model effectiever is dan traditionele pijplijnen, vindt in de vergelijking tussen vision-modellen en traditionele OCR een analyse van herkenningsfouten en lay-outbehoud.

Randgevallen en foutmodi in tabulaire data

Tabel-extractie faalt zelden op eenvoudige, uniforme tabellen; het zijn de randgevallen waarin modellen ontsporen. Een betrouwbare architectuur moet expliciet rekening houden met de volgende patronen:

1. Samengevoegde cellen en hiërarchische headers

In financiële overzichten beslaat een bovenliggende categorie vaak meerdere onderliggende kwartaalkolommen. Een puur tekstueel model leest de regels sequentieel en koppelt de categorienaam uitsluitend aan de eerste kolom eronder, waardoor de resterende kolommen verkeerd gelabeld worden. Multimodale modellen of specifieke markdown-transformaties waarin cellen expliciet worden gedupliceerd (zogenaamde spanning unrolling), voorkomen deze fout.

2. Tussentijdse totalen en aggregatierijen

Spreadsheets bevatten regelmatig subtotalen, sectietitels of voetnoten middenin het datablok. Wanneer een model de opdracht krijgt om "alle rijen te converteren naar JSON-records", worden deze subtotalen vaak als reguliere transacties geëxtraheerd. Dit leidt tot dubbeltellingen in downstream analyses. De prompt en het extractieschema moeten expliciet onderscheid maken tussen detailregels en geaggregeerde rijen.

3. Inconsistente datum- en valutaconventies

In internationale datasets lopen notaties door elkaar: datumnotaties met wisselende dag- en maandvolgordes zorgen voor verwarring, evenals getalsnotaties waarbij punten en komma's voor decimalen en duizendtallen wisselen. Een extractiemodel moet worden geïnstrueerd om waarden te normaliseren naar ISO 8601 en numerieke floats zonder scheidingstekens, of de brondata strikt ongewijzigd over te nemen.

Evaluatiemethodiek: Hoe meet je tabelkwaliteit?

Het valideren van tabel-extractie vraagt om een meetbare benchmarkset. Het handmatig steekproefsgewijs bekijken van enkele records geeft een vals gevoel van zekerheid. Een methodische evaluatie rust op vier pijlers:

1. Cel-niveau precisie, recall en F1-score

Vergelijk elk geëxtraheerd veld exact met een handmatig geannoteerde grondwaarheid (ground truth). Maak hierbij onderscheid tussen stringvelden (waar een genormaliseerde Levenshtein-afstand of exacte match geldt) en numerieke velden (waarbij elke afwijking groter dan 0 direct als fout telt).

2. TEDS: Tree-Edit-Distance-based Similarity

Voor complexe tabellen met wisselende lay-outs is TEDS de industriestandaard. Deze metriek representeert tabellen als een HTML-achtige boomstructuur van rijen, kolommen en cellen. TEDS berekent het aantal bewerkingen (invoegen, verwijderen, hernoemen) dat nodig is om de voorspelde boomstructuur om te vormen tot de ware boomstructuur. Hierdoor worden zowel structurele fouten (zoals het verschuiven van een kolom) als inhoudelijke parseerfouten evenredig gewogen.

3. Schema-conformiteit en JSON-validatieratio

Meet het percentage gegenereerde antwoorden dat zonder fouten valideert tegen het vooraf gedefinieerde JSON-schema. In productieomgevingen moet deze score boven de 99,5% liggen om te voorkomen dat automatische gegevensstromen vastlopen.

4. Rijenbehoud (Row Completeness Ratio)

Controleer of het aantal geëxtraheerde rijen exact overeenkomt met de bron. Modellen hebben bij lange tabellen de neiging om herhalende rijen samen te voegen of af te kappen met samenvattende opmerkingen. Een geautomatiseerde controle op rij-aantallen detecteert deze afkappingsfouten onmiddellijk.

Kosten- en efficiëntieafweging: Bulkverwerking versus precisie

Bij het verwerken van duizenden spreadsheets lopen de kosten van commerciële API's exponentieel op. Een CSV van duizenden rijen verbruikt al snel tienduizenden tokens aan context. Als dit bestand integraal naar een frontier-model wordt gestuurd om slechts enkele records te filteren, betaal je voor tienduizenden overbodige tokens.

Om de financiële impact van omvangrijke documenten exact te berekenen, toont de rekenbrug voor de werkelijke kosten van lange contextvensters hoe inputkosten per call oplopen wanneer documenten onbewerkt worden aangeboden. Daarnaast biedt het benchmarkoverzicht van kosten per taak vergelijken tussen modellen een objectieve meetmethode om tokenverbruik af te zetten tegen extractienauwkeurigheid.

In productie blijkt een gelaagde verwerkingsstrategie het meest rendabel:

1. Deterministische voorbewerking: Gebruik reguliere code (zoals Python met Polars of Pandas) om lege kolommen te verwijderen, uniforme witruimte af te dwingen en irrelevante metadata te strippen vóórdat de tekst naar het LLM gaat.

2. Chunking met header-behoud: Knip lange tabellen op in logische blokken van 50 tot 100 rijen, waarbij de oorspronkelijke kolomkoppen en contextuele metagegevens aan elk blok worden toegevoegd. Dit voorkomt dat het model het overzicht verliest en houdt de responstijd per aanroep laag.

3. Dynamische routering: Eenvoudige, platte tabellen worden afgehandeld door een compact lokaal model. Alleen tabellen die falen op schemavalidatie of visueel complexe bestanden worden automatisch doorgestuurd naar een zwaarder frontier-model.

Implementatievoorbeeld: CSV naar strikte JSON met schema-handhaving

Onderstaand Python-voorbeeld toont hoe een semigestructureerde CSV-invoer wordt omgezet naar een strikt getypte JSON-structuur via Pydantic. Het schema dwingt af dat optionele velden als null worden weergegeven en dat numerieke waarden exact behouden blijven.

from pydantic import BaseModel, Field
from typing import List, Optional

class FactuurPost(BaseModel):
  artikelcode: str = Field(description="Exacte artikelcode of SKU")
  omschrijving: str = Field(description="Omschrijving van het product of de dienst")
  aantal: float = Field(description="Aantal geleverde eenheden")
  eenheidsprijs: float = Field(description="Prijs per eenheid exclusief BTW")
  btw_tarief: float = Field(description="Toegepast BTW-percentage als decimaal, bijv 0.21")
  regel_totaal: float = Field(description="Totaalbedrag van deze regel exclusief BTW")
  korting_percentage: Optional[float] = Field(default=None, description="Korting indien vermeld")

class FactuurExtractie(BaseModel):
  factuurnummer: str
  factuurdatum: str = Field(description="Datum in ISO formaat YYYY-MM-DD")
  leverancier_kvk: Optional[str] = Field(default=None)
  posten: List[FactuurPost]
  totaal_excl_btw: float
  totaal_incl_btw: float

system_prompt = (
  "Je bent een gespecialiseerd data-extractiesysteem. Converteer de aangeleverde "
  "tabelgegevens strikt conform het JSON-schema. Neem getallen exact over zonder "
  "afronding. Indien een veld ontbreekt in de bron, vul dan null in."
)

Door het schema expliciet te definiëren, kan de API-provider via constrained decoding de logit-generatie van het model beperken tot tokens die grammaticaal correcte JSON opleveren. Hiermee worden syntaxfouten in de uitvoer geëlimineerd.

Wanneer moet je géén AI-modellen gebruiken voor tabel-extractie?

Hoewel taal- en visiemodellen flexibel zijn bij rommelige gegevens, is het inzetten van AI voor voorspelbare, gestructureerde dataverwerking een structurele ontwerpfout. Een LLM introduceert altijd een kans op niet-deterministisch gedrag, aanzienlijke responstijd en doorlopende operationele kosten.

Gebruik geen AI-modellen in de volgende situaties:

1. Standaard CSV- en TSV-exports: Wanneer bestanden gegenereerd zijn door databases, CRM-systemen of API's met consistente scheidingstekens. Traditionele parsers zoals Python's ingebouwde csv-module of polars.read_csv() verwerken honderdduizenden rijen per seconde, kosten nul euro aan API-tokens en maken nul hallucinaties.

2. Programmeerbare spreadsheets: Excel-documenten met een intacte structuur kunnen direct worden uitgelezen met bibliotheken zoals openpyxl of DuckDB. Formules, celeigenschappen en datatypes kunnen deterministisch worden uitgevraagd zonder AI.

3. Strikte latency-eisen onder de 50 milliseconden: In real-time transactieverwerking is de responstijd van een LLM (doorgaans honderden milliseconden tot meerdere seconden) onaanvaardbaar.

Zet AI uitsluitend in wanneer de structuur van de invoer onvoorspelbaar varieert, menselijke fouten in de lay-out gecorrigeerd moeten worden, of visuele elementen uit scans moeten worden omgezet naar betekenisvolle datavelden.

Stappenplan voor de juiste modelkeuze

Bij het inrichten van een productiesysteem voor tabelextractie leidt het volgen van een gestructureerd keuzeproces tot de meest stabiele en kostenefficiënte architectuur. Wie een breed toepasbaar evaluatiekader zoekt voor zakelijke AI-toepassingen, kan de herbruikbare methode voor modelkeuze binnen een vakgebied raadplegen om selectiecriteria te formaliseren.

De concrete stappen voor tabulaire workflows zijn als volgt:

1. Karakteriseer de invoerlaag: Beoordeel of de data puur tekstueel is (CSV/TSV), een semigestructureerde spreadsheet betreft, of een visueel document is (PDF/scan). Kies bij visuele bestanden direct voor een multimodaal model om fouten door tussenliggende OCR te vermijden.

2. Definieer het validatieschema vooraf: Bouw een strikt Pydantic- of JSON-schema en dwing constrained decoding af op de model-API.

3. Bouw een benchmarkset met randgevallen: Evalueer kandidaatmodellen op datasets met samengevoegde headers, ontbrekende waarden en afwijkende getalsnotaties met behulp van TEDS en cel-precisiemetingen.

4. Implementeer chunking en fallback-mechanismen: Knip grote tabellen op met behoud van headers en richt een routeringslaag in die eenvoudige taken lokaal afhandelt en complexe randgevallen escaleert naar zwaardere modellen.