Baidu Unlimited-OCR: een lang document in één keer, on-prem

De kern is een aangepast aandachtsmechanisme in de decoder, dat het geheugen constant houdt. Klassieke OCR-modellen op transformer-basis laten de zogenoemde KV-cache meegroeien met de lengte van het document. Hoe langer de PDF, hoe meer geheugen, tot het op een gegeven moment niet meer in een verwerking past.

Unlimited-OCR vervangt dit onderdeel door Reference Sliding Window Attention (R-SWA). De KV-cache blijft daarbij constant, onafhankelijk van de documentlengte. Precies dat bedoelt de term one-shot long-horizon parsing: een lang document wordt in één doorgang gelezen, in plaats van het in secties op te delen en de resultaten achteraf samen te voegen.

Opvallend is het trainingstraject. Het team is niet bij nul begonnen, maar heeft het DeepSeek-OCR-checkpoint verder getraind: de encoder bevroren en alleen de decoder over circa 4.000 stappen aangepast. Daarmee staat het model in directe lijn met DeepSeek-OCR, dat we in de stackcontext al hebben geplaatst. Code en gewichten liggen open op GitHub.

Het eigenlijke probleem bij lange documenten is niet de afzonderlijke pagina, maar de samenhang over de pagina's heen. Als een model een document van 60 pagina's in blokken van tien pagina's knipt, gaat precies verloren wat in de B2B-praktijk telt: een tabel die over de paginabreuk doorloopt, een clausule die verwijst naar een eerdere sectie, een post waarvan de referentiewaarde twintig pagina's eerder staat.

Een constante KV-cache maakt het mogelijk om het hele document in één context te houden. Het geheugen groeit niet mee met de lengte, dus blijft de structuur over alle pagina's behouden. Bovendien wordt het sneller: Baidu noemt in base-modus 5.580 tokens per seconde tegenover 4.951 bij DeepSeek-OCR, bij een outputlimiet van 6.000 tokens ligt het verschil rond de 35 procent.

Wat nauwkeurigheid betreft scoort Unlimited-OCR op OmniDocBench v1.5 93,23 punten, 6,22 boven de DeepSeek-OCR-basis, op v1.6 93,92. Dat zijn de cijfers uit het paper. Op uw eigen documenten telt uiteindelijk hoe het model omgaat met uw tabellen, stempels en formulieren, niet het gemiddelde van een publieke testset. Verwant is de ontwikkeling bij subkwadratische LLM's, die lange context on-premise goedkoper maken.

Het nut ontstaat daar waar lange, gestructureerde documenten omgezet moeten worden in schone, doorzoekbare data. Een paar concrete plekken:

• Contracten en raamovereenkomsten. Kruisverwijzingen en bijlagen blijven in samenhang leesbaar, in plaats van uiteen te vallen bij blokgrenzen.
• Technische handleidingen en normen. Lange documenten met afbeeldingen, tabellen en genummerde secties in één doorgang.
• Meerpagina's facturen en bonnen. Schoon geëxtraheerde tekst is de voorfase voor gestructureerde verdere verwerking, bijvoorbeeld richting e-factuur.
• Archieven en dossiers. Bestanden die tot nu toe alleen als scan bestonden, worden machinaal leesbaar, zonder ze aan een clouddienst te geven.

In bijna alle gevallen is OCR niet het doel, maar de eerste stap. Schoon geparste tekst is de basis voor een kennisbank met RAG: hoe beter het parsen, hoe beter de zoekfunctie later de juiste plek vindt.

Niet elke documenttaak heeft klassieke tekstherkenning nodig, en dat is een eerlijke afweging. Er bestaat inmiddels een hele tak die documenten helemaal niet eerst omzet in tekst, maar ze als beeld doorzoekt, met modellen zoals ColPali of ColQwen. Deze OCR-vrije aanpak hebben we apart beschreven.

De vuistregel die bij ons haar waarde heeft bewezen:

• U hebt de daadwerkelijke tekens nodig (factuurbedragen, contractclausules, gestructureerde extractie, doorgifte aan een ander systeem): dan is OCR nauwelijks te vermijden, en een model zoals Unlimited-OCR is hier sterk.
• U hebt de juiste plek nodig, niet de volledige tekst (een vraag over een groot bestand beantwoorden, een afbeelding terugvinden): dan kan visueel documenten zoeken de directere weg zijn.

Vaak is het beide naast elkaar. Unlimited-OCR maakt het OCR-deel van deze stack goedkoper en op lange documenten betrouwbaarder.

Een goede benchmarkscore is een reden om het model te testen, geen reden om het productief te zetten. Voordat ik Unlimited-OCR in een klantproces zou zetten, zou ik vier dingen controleren:

🔸 Duitse documenten en handschrift. De benchmarkcijfers zeggen weinig over Duitse formulieren, oude dossiers of handgeschreven aantekeningen. Dat hoort op een eigen testset van echte documenten.

🔸 Tabellen en layout. Bij B2B-documenten bepaalt de trouw van tabellen en kolommen het nut. Hier loont de directe vergelijking met de bestaande stack.

🔸 Hardware en beheer. 3B als MoE met circa 500M actieve parameters is on-premise realistisch. Wat dat concreet betekent aan GPU-geheugen en doorvoer, hoort voor de uitrol gemeten te worden, niet geschat.

🔸 Licentie en herkomst. MIT staat commercieel, on-premise gebruik zonder voetnoten toe. Dat het spoor van het model naar een van de DeepSeek-OCR-auteurs leidt, is een kwaliteitssignaal, maar vervangt niet de eigen controle.

Wat mij eigenlijk het meest interesseert aan deze release is minder het model zelf dan de richting: lange documenten in één doorgang, klein genoeg voor het eigen rekencentrum, onder een licentie die niemand beperkt. Precies daar wordt documentverwerking in het mkb nu praktisch. Welke van uw documenten zou u als eerste laten doorlopen?