Wanneer volstaat een klein model voor documentwerk?

Het grootste model is voor smalle documenttaken vaak de dure keuze, niet de veilige. Zo meten wij of een kleiner model het werk aankan, en waar het misloopt.

Wie een demo met een groot frontiermodel heeft gezien, stuurt daarna vaak elk document naar datzelfde model. Voor smalle, repetitieve taken is dat zelden de goedkoopste keuze, en ook niet altijd de veiligste. Denk aan inkomende post classificeren, een vaste set velden uit facturen halen of nagaan of een contract het sjabloon volgt: kleinere modellen doen dat werk vandaag goed genoeg dat het grootste model vooral de duurste optie wordt.

Er speelt nog iets mee. Een klein model kunnen we in een Europees datacenter of op de eigen infrastructuur van de klant draaien, waardoor de vraag waar de documenten naartoe gaan al beantwoord is voor de juridische dienst ze stelt. Of een klein model volstaat, weten we echter pas na meten, en dat meten gebeurt op een vaste manier.

Eerst een evaluatieset uit echte documenten

We beginnen niet met een model maar met een stapel documenten van de klant zelf. Geen opgeschoonde voorbeelden uit een handleiding, wel wat er effectief binnenkomt op een gewone dinsdag. Bij elk document leggen we vast wat het correcte antwoord is: de juiste categorie, de juiste waarde per veld, of het document al dan niet aan het sjabloon voldoet. Dat labelen doen we samen met de mensen die het werk nu manueel doen, omdat zij weten welke uitzonderingen in de praktijk tellen.

De eerste keer dat we dit deden, bestond onze set vooral uit nette pdf's, omdat die snel te labelen waren. Het kleine model leek klaar, tot de eerste week productie vol scheve scans en tweetalige formulieren zat. Sindsdien zoeken we de lelijke gevallen bewust op en nemen we ze op in ongeveer de verhouding waarin ze ook binnenkomen.

• scans van fotokopieën, scheef of met vlekken

• documenten die halverwege van Nederlands naar Frans overschakelen

• handgeschreven notities in de marge of op een stempel

• formulieren volgens een oude versie van het sjabloon

• bijlagen die eigenlijk een ander documenttype zijn

• velden die leeg zijn en leeg moeten blijven

Kijken waar het misgaat

Op die set laten we een klein en een groot model lopen, met dezelfde instructies en hetzelfde uitvoerformaat. Het gemiddelde zegt dan weinig. Twee modellen met een vergelijkbare totaalscore kunnen heel verschillend falen: het ene mist af en toe een veld op willekeurige plaatsen, het andere faalt systematisch op scans of op Franstalige documenten.

Daarom splitsen we de resultaten op per documenttype, per taal, per veld en per bron. Vaak blijkt het kleine model op de gewone gevallen even goed als het grote, en zitten de fouten geconcentreerd in een herkenbare groep. Zo'n groep kunnen we opvangen. Fouten die verspreid zitten over alle categorieën zijn een veel slechter teken, ook als het gemiddelde er redelijk uitziet.

Waar de fouten herkenbaar zijn, routeren we. Het kleine model verwerkt alles, en een eenvoudige regel of een aparte classificatiestap stuurt de moeilijke gevallen door naar een groter model of naar een mens. Als signaal gebruiken we onder meer een lage OCR-kwaliteit, een gedetecteerde taalwissel, uitvoer die niet door de schemavalidatie komt, of velden die onderling niet kloppen, zoals een totaal dat niet gelijk is aan de som van de lijnen. Het grote model ziet zo maar een klein deel van het volume, en precies het deel waar het zijn prijs waard is.

Het gemiddelde vertelt of een model bruikbaar is. De verdeling van de fouten vertelt of je het kunt vertrouwen.

Een vast schema doet meer voor een klein model

Een groot model maakt van een losse instructie als 'geef de relevante gegevens terug' meestal nog iets bruikbaars. Een klein model heeft minder marge: het verandert veldnamen, zet uitleg rond de JSON of kiest per document een andere structuur. Elk van die afwijkingen is een fout die niets met de inhoud van het document te maken heeft, maar die in de score even zwaar weegt.

We leggen daarom een vast schema op, met vaste veldnamen, types, een gesloten lijst toegelaten categorieën en een expliciete waarde voor 'niet gevonden'. Die laatste is nodig omdat een klein model anders een ontbrekend btw-nummer graag invult met iets dat er plausibel uitziet. Waar de inferentieserver het toelaat, dwingen we de structuur af tijdens het genereren met constrained decoding, zodat ongeldige uitvoer niet meer kan. Het model hoeft dan niet meer te bedenken hoe het antwoordt, enkel wat, en voor een klein model maakt dat in onze ervaring een groter verschil dan voor een groot.

Wat het kost, en waar het grote model blijft

Voor sommige taken beginnen we niet aan een klein model. Wie een beding op pagina veertig moet afwegen tegen een definitie op pagina drie, of wil weten wat er over een heel dossier veranderd is, heeft redeneervermogen over een lange context nodig. Kleine modellen verliezen daar sneller de draad, ook als hun contextvenster op papier groot genoeg is. Opknippen helpt minder dan men hoopt, omdat de verbanden net over de grenzen van de stukken lopen.

Ook de besparing is niet gratis. Een model zelf hosten betekent GPU-capaciteit huren of reserveren, een inferentieserver onderhouden, updates opvolgen en iemand hebben die ingrijpt als de dienst 's nachts stilvalt; bij een laag volume weegt dat zelden op tegen een API-factuur. Daarbovenop moet de evaluatieset beter zijn dan bij een groot model: representatiever, en bijgewerkt telkens er een nieuw documenttype of een nieuwe leverancier bijkomt. Dat onderhoud stopt niet na de oplevering.

Wie overweegt een deel van de documentstroom naar een kleiner model te verhuizen, begint dus het best bij de evaluatieset en pas daarna bij de modelkeuze. Wil je dat we samen naar je eigen documenten kijken, dan kun je ons bereiken via de contactpagina.