OCR of een taalmodel: wanneer wat

De vraag "OCR of AI?" gaat over twee verschillende stappen. De eerste stap haalt tekst van een pagina: uit een tekstlaag in de PDF, of met OCR uit een afbeelding. De tweede stap haalt betekenis uit die tekst: welk getal is het factuurbedrag, welke regel is een orderregel. Voor die tweede stap zijn vaste regels of een taalmodel de keus. Welke combinatie u nodig heeft, hangt af van wat er binnenkomt, en dat wisselt per document. Hieronder één werkdag in een gedeelde postbus van een typische administratie, in volgorde van binnenkomst.

08:10, de factuur van de energieleverancier

Een PDF, elke maand dezelfde opmaak. De tekst zit al in het bestand: een PDF-bibliotheek zoals PyMuPDF geeft de tekst terug zoals die in het document is gecodeerd, zonder dat er een pixel wordt bekeken; de leesvolgorde kan afwijken, maar de tekens kloppen. OCR toepassen op zo'n bestand is een omweg die alleen fouten kan toevoegen.

De betekenis is hier ook geen interpretatievraag. Het factuurnummer staat achter hetzelfde label, het totaalbedrag op dezelfde regel, het betalingskenmerk heeft een vaste lengte. Een paar regels die op die labels zoeken en het bedrag als getal parsen, doen dit werk zonder een model, en doen het volgende maand precies zo. Dat is de regel van de veelgestelde vragen: alles wat met vaste regels kan, doen we met vaste regels, omdat die voorspelbaar, testbaar en goedkoper zijn. Een taalmodel kan hetzelfde antwoord geven, maar met een kans op een ander antwoord, en zonder test die dat aantoont.

Waar de regels ophouden: bij de maand waarin de leverancier zijn sjabloon vernieuwt. Dan geeft de regel niets terug, en dat moet hij ook: leeg is beter dan verkeerd.

09:30, de bon uit de portemonnee

Een foto van een kassabon, met in pen erop een kenteken en "tanken". De gedrukte regels zijn OCR-werk. De documentatie van Tesseract, een open-source OCR-motor, raadt daarvoor minstens 300 dpi en een rechtgetrokken beeld aan; een telefoonfoto in een auto komt daar zelden bij in de buurt. Het kenteken in pen is een ander verhaal. De Tesseract-FAQ zegt over handschrift: het kan, maar het werkt niet goed, want Tesseract is voor gedrukte tekst gemaakt. De clouddiensten kunnen meer, maar met een grens: het Read-model van Azure Document Intelligence ondersteunt handschrift in twaalf talen, en Nederlands staat daar niet bij; gedrukt Nederlands wel.

Een taalmodel dat beelden begrijpt, komt met zulke briefjes verder. In OmniDocBench, een benchmark met negen documentsoorten, scoort de pijplijntool MinerU op handgeschreven notities een editafstand van 0,984, tegenover 0,168 voor het beeldtaalmodel Qwen2-VL; lager is beter, en 0,984 betekent in de praktijk onleesbaar. Dat is één vergelijking tussen twee systemen, geen wet, maar het patroon is herkenbaar. Alleen: een kenteken is zes tekens waarvan er geen één fout mag zijn. Hier leest de techniek voor, en kijkt een mens na. Dat is geen tussenoplossing maar het ontwerp.

11:15, de order in lopende tekst

Een e-mail van een vaste klant: "Doe mij er nog twaalf van die van vorige week, en de helft in de andere maat, graag donderdag." Geen pagina, dus geen OCR. Geen vast label, dus geen regel die u vooraf kunt schrijven. Hier doet een taalmodel zijn werk: de tekst omzetten in twee orderregels, met een artikel uit de vorige order en een leverdatum afgeleid uit "donderdag".

Of dat de moeite loont, hangt af van hoe vaak dit soort mails binnenkomt; die rekensom staat in wanneer AI loont in het mkb. Wat hier telt: het model levert een voorstel, geen order, en het voorstel maakt onderscheid tussen wat letterlijk in de mail staat en wat is afgeleid. "Twaalf" staat er; "die van vorige week" is een afleiding, en die wordt pas een orderregel als iemand hem bevestigt.

14:00, de scan van een pakbon

Van de scanner in het magazijn, 200 dpi, iets scheef, met een tabel van artikelnummer, omschrijving en aantal. Dit is wél OCR-werk, maar de tabel moet als tabel terugkomen, anders staan de aantallen los van de artikelen. De Tesseract-documentatie noemt tabellen zelf als zwak punt; de lay-outmodellen van de clouddiensten en gespecialiseerde tabeltools doen dat beter. In dezelfde benchmark haalt de tabeltool RapidTable een TEDS-score van 82,5 tegenover 71,0 voor Qwen2-VL-72B: op tabellen wint hier de gespecialiseerde OCR-pijplijn van het grote model, tot de tabel gedraaid op de scan staat, dan zakt ook RapidTable naar 42,7.

Is de tabel eenmaal tekst, dan is de rest weer regelwerk: artikelnummer opzoeken, aantal vergelijken met de inkooporder, verschil melden. Daar komt geen model aan te pas.

16:30, wat er is blijven liggen

Vier documenten, vier combinaties. De energiefactuur en de pakbon zijn na de tekststap volledig regelwerk. De bon met handschrift is techniek plus een mens. De e-mail is het enige document waar een taalmodel de kern is, en zelfs daar met een bevestiging voordat het een order wordt.

Wat om vijf uur nog in de wachtrij staat, is niet wat de techniek niet kon lezen, maar wat ze niet zeker wist: het kenteken, "die van vorige week", een regel die na een sjabloonwijziging leeg terugkwam. Zo hoort dat bij facturen die zichzelf inboeken: wat vaststaat wordt verwerkt, en alleen het onzekere deel gaat naar een mens. Hoe dat technisch in elkaar zit, en waarom niet alles een taalmodel hoeft, staat op de pagina over de techniek.