BV-OCR: el motor de lectura de documents, per dins

Llegir documents a escala operativa són dos problemes disfressats d'un de sol. El primer és de throughput: una operació real no processa un PDF, en processa milers —factures, formularis, correu escanejat— i cada segon per pàgina es multiplica per tot l'arxiu. El segon és de confiança: tant li fa com de ràpid llegeixis si ningú no pot demostrar d'on va sortir cada dada. Un motor de lectura que resol només el primer produeix errors més de pressa; un que resol només el segon no arriba mai a producció.

BV-OCR és el motor de lectura de documents de BiVelio: la pila que alimenta el mòdul Documents i que hi ha sota el pipeline que vam descriure a Del document a la dada governada. Aquell article explica què fa Documents; aquest explica com llegeix. La resposta curta: amb tres peces coordinades, i una porta entre les dues últimes que és la que converteix "sortida d'un model" en "dada amb evidència".

L'arquitectura en tres peces

BV-OCR separa deliberadament tres feines que altres sistemes barregen en una:

1. Parsing determinista en GPU —un parser documental propi de BiVelio, escrit en C++ sobre CUDA i TensorRT— converteix cada pàgina en text literal amb coordenades, estructura de layout, taules i fórmules. Ràpid, local i reproduïble: la mateixa pàgina produeix el mateix text.
2. Comprensió amb un model visió-llenguatge compacte, servit amb inferència optimitzada per a NVIDIA, que proposa interpretacions camp a camp sobre aquest text: quin dels imports és el total, quina de les dates és el venciment.
3. La porta value-in-OCR, la regla central del motor: tot valor que el model proposi ha de poder rastrejar-se fins a un fragment del text que l'OCR va reconèixer. El que no es pot ancorar, es rebutja i va a revisió humana.

Per què la divisió? Perquè cada peça és bona exactament en allò que l'altra no pot fer. El parser determinista dona velocitat i text literal amb coordenades —l'àncora física de tota l'evidència posterior—, però no entén què significa cada línia. El model entén, però genera: res en un model generatiu no garanteix que un valor surti del document i no de la seva imaginació. La porta uneix les dues meitats: el model pot proposar el que vulgui, però només el que existeix al text reconegut pot entrar a l'operació.

L'alternativa de moda —un parser VLM pur que mira la pàgina i escriu directament la sortida estructurada— col·lapsa aquestes tres funcions en una sola passada generativa. És més simple, i en els layouts més difícils és fins i tot més precís (els números, més avall). Però paga dos preus que per a BiVelio són inacceptables: és ordres de magnitud més lent per pàgina, i no deixa àncora literal: el text que emet és generat, no reconegut, així que no hi ha cap fragment de l'original contra el qual verificar un valor sense rellegir el document sencer.

Parsing determinista en GPU

La primera peça és el parser documental de BV-OCR, desenvolupament propi de BiVelio escrit en C++ sobre CUDA i TensorRT. No és "un OCR amb extres": és un pipeline complet de parsing sobre un únic motor GPU multi-stream, local —sense cap VLM al bucle— i servit per HTTP i gRPC. Com tota la recerca de BiVelio, corre sobre inferència i hardware NVIDIA.

Les etapes, en ordre:

• Detecció i reconeixement de text: on hi ha text a la pàgina i què diu, línia a línia, amb caixa de coordenades i confiança per línia.
• Anàlisi de layout: quines regions són paràgraf, títol, taula, figura, fórmula.
• Taules → HTML: l'estructura de cel·les es conserva, no s'aplana en text corregut.
• Fórmules → LaTeX.
• Markdown en ordre de lectura: tot l'anterior, assemblat en l'ordre en què un humà llegiria la pàgina.

Aquest últim pas importa més del que sembla. El Markdown en ordre de lectura és el que consumeix la segona peça: un document textual fidel, ordenat, amb les taules com a taules i les fórmules com a fórmules — i on cada línia continua sent rastrejable fins a la seva regió de l'original. Sense això, el model rebria una sopa de fragments sense ordre, i "l'import que segueix l'etiqueta Total" deixaria de tenir sentit.

Els números del banc de proves

Les xifres que segueixen surten del banc de proves reproduïble de BV-OCR, mesurat sobre datasets públics en una sola GPU NVIDIA (RTX 5090):

• Throughput: fins a 559 imatges/s en rebuts, 520 en formularis i 200+ en documents densos, amb el tier més ràpid (el de per defecte).
• Precisió en formularis i rebuts: 92% de word-F1 a FUNSD i 93% a CORD amb el tier de més precisió.
• Parsing estructurat complet (layout + taules + fórmules): ~20 pàgines/s amb un Overall de 0,90 en un subconjunt de 125 documents d'OmniDocBench (anglès + xinès). En aquest subconjunt, BV-OCR queda a uns 5 punts del millor parser VLM de referència; els parsers documentals basats purament en VLM ronden ~1 pàgina/s.

Aquesta última comparació és el contrast honest que anunciàvem: en els layouts més difícils, el millor parser VLM pur és ~5 punts millor. A canvi, el parser determinista és ~20× més ràpid i, sobretot, produeix text reconegut, no generat — la matèria primera sense la qual la porta value-in-OCR no existiria.

Tiers i hardware

BV-OCR ofereix tres tiers que intercanvien velocitat per precisió sense canviar d'idiomes: del més ràpid —el de per defecte, el de les xifres de throughput— al de més precisió, el de les xifres de FUNSD i CORD. Tots tres cobreixen alfabet llatí, xinès i japonès; l'àrab, el ciríl·lic, el coreà, el tailandès i el grec es cobreixen amb packs de reconeixement addicionals.

En hardware, BV-OCR està dissenyat i optimitzat per a GPUs NVIDIA: corre en Linux amb una GPU NVIDIA (Turing o posterior), amb ~4 GB de VRAM per a només text i ~8 GB per al pipeline complet.

Comprensió amb un model visió-llenguatge compacte

El text literal no és suficient. Una factura reconeguda al 100% continua sense dir-te quin dels seus set imports és el total, ni quina de les seves tres dates és el venciment. Aquesta és la feina de la segona peça: un model visió-llenguatge compacte amb comprensió nativa d'imatges i documents, servit amb inferència optimitzada per a NVIDIA.

El seu paper a BV-OCR és deliberadament estret: proposa interpretacions camp a camp sobre el que el parser determinista ja va reconèixer. "El total de la factura és 1.240,00 €, el que apareix al costat de l'etiqueta Total." "La data de venciment és 2026-09-30, la de la línia Payment due." Proposa; no transcriu. L'OCR del document ja està fet, i fet per un component determinista.

Dues coses que el model no fa a BV-OCR:

• No substitueix l'OCR. El text sobre el qual treballa —i contra el qual es verificarà cada proposta— és el del parser determinista, no una transcripció pròpia.
• No decideix. Les seves propostes no entren a l'operació per si soles: cadascuna ha de passar la porta value-in-OCR, i les dubtoses acaben davant d'una persona.

Una capacitat sí que s'explota directament: la profunditat de raonament ajustable. Els camps fàcils —una etiqueta clara, un valor al costat— no necessiten cadena de pensament; els difícils —dos totals candidats, una taula ambigua— justifiquen gastar més còmput a raonar abans de proposar. Un model compacte amb esforç ajustable permet pagar el raonament només on cal.

La porta value-in-OCR

La tercera peça és la raó de ser de les altres dues. La regla cap en una sola frase: tot valor que el model proposi ha de poder rastrejar-se fins a un fragment del text que el parser determinista va reconèixer.

A la pràctica, cada proposta que supera la porta surt amb un localitzador d'evidència: la regió de l'original i el fragment del text reconegut d'on va sortir el valor. Això és exactament el que el mòdul Documents adjunta a cada camp extret — el fet assenyalable que un revisor comprova en segons.

I quan l'àncora no existeix? Quan el model proposa un valor que no apareix al text reconegut —perquè el va al·lucinar, perquè el va "corregir", perquè el va derivar d'un càlcul—, la porta el rebutja. El camp no es descarta en silenci ni s'accepta amb un asterisc: s'enruta a la consola de revisió humana, amb el document al davant, perquè decideixi una persona. Un model no pot inventar-se un valor i que el sistema l'accepti; el màxim que aconsegueix un valor inventat és una cita amb un revisor.

Fixem-nos en el que la porta no és: no és un llindar de confiança. Un llindar filtra per com de segur el model diu estar; la porta filtra pel que el document diu. Un valor al·lucinat amb confiança 0,99 passa un llindar i no passa la porta. Aquesta és la tesi de Del document a la dada governada —l'evidència guanya a la confiança a seques— aterrada en el mecanisme concret que la fa complir.

Què mesurem i què no

Un article tècnic honest ha de separar tres tipus d'afirmacions:

• Les xifres són del nostre banc de proves, sobre datasets públics. Els números de throughput i precisió d'aquest article (559 img/s, FUNSD 92% / CORD 93%, 0,90 al subconjunt d'OmniDocBench) estan mesurats amb el harness reproduïble de BV-OCR sobre datasets públics, en una sola GPU NVIDIA (RTX 5090). Un dataset públic no és una promesa sobre els teus documents: un dataset acadèmic de rebuts no és el teu arxiu de contractes escanejats.
• BiVelio no publica percentatges de precisió sobre documents de clients. La precisió sobre els teus documents depèn del teu corpus, i es valida en el teu propi flux de revisió. La garantia que sí que oferim no és estadística sinó estructural: cap valor no entra sense evidència, i el que és dubtós acaba davant d'una persona.
• BV-OCR està dissenyat i optimitzat per a GPUs NVIDIA. El motor està escrit en C++ sobre CUDA i TensorRT, i tota la nostra recerca corre sobre inferència i hardware NVIDIA.

On encaixa BV-OCR

BV-OCR no és un producte que es compri solt: és el motor sota el mòdul Documents. El mapa complet:

• El parser determinista llegeix cada document ingerit: text literal amb coordenades, layout, taules, fórmules, Markdown en ordre de lectura.
• El model visió-llenguatge proposa els camps que l'operació necessita, amb profunditat de raonament ajustada a la dificultat de cadascun.
• La porta value-in-OCR ancora cada proposta al text reconegut i emet el localitzador d'evidència que viatja amb la dada.
• El que es rebutja i el que és dubtós s'encua a la consola de revisió humana —el principi de disseny que desenvolupem a Human-in-the-loop: 5 components, no un botó d'aprovar— i les correccions flueixen de tornada al cas.
• La dada validada alimenta casos i fluxos governats: permisos, traça d'auditoria, portes humanes als passos crítics.

El recorregut complet de la dada —de la ingesta al cas— és a Del document a la dada governada; aquest article és la sala de màquines de la seva primera meitat.

FAQ

BV-OCR és un producte separat del mòdul Documents?

No. BV-OCR és el nom del motor de lectura que alimenta el mòdul Documents: la capa que converteix el document en text ancorat i propostes de camps amb evidència. Documents hi afegeix a sobre la conservació i versionat de l'original, la consola de revisió i l'automatització governada.

Per què no fer servir directament un model visió-llenguatge per a tot?

Perquè un parser VLM pur genera el text en lloc de reconèixer-lo: no deixa cap fragment literal de l'original contra el qual verificar un valor, i és molt més lent per pàgina (els parsers documentals basats purament en VLM ronden ~1 pàgina/s, davant de ~20 al subconjunt d'OmniDocBench citat). Sí que és més precís en els layouts més difícils —BV-OCR queda a uns 5 punts del millor parser VLM de referència en aquest subconjunt—, i ho diem tal qual: BV-OCR renuncia a aquests punts a canvi de throughput i, sobretot, d'evidència ancorable.

Què passa si el model al·lucina un valor?

Que no entra. La porta value-in-OCR exigeix que cada valor proposat es rastregi fins a un fragment del text reconegut pel parser determinista; un valor que no apareix en aquest text es rebutja i el camp s'enruta a la consola de revisió humana. L'al·lucinació no es converteix en dada: es converteix en una tasca de revisió.

Les xifres de velocitat i precisió són de BiVelio?

Sí. Estan mesurades amb el banc de proves reproduïble de BV-OCR sobre datasets públics (FUNSD, CORD i un subconjunt d'OmniDocBench), en una sola GPU NVIDIA. El que BiVelio no publica són percentatges de precisió sobre documents de clients: la precisió sobre el teu corpus es valida en el teu propi flux de revisió, i la garantia que ofereix el sistema és estructural (evidència obligatòria + revisió humana), no un número.

En quin hardware corre el motor?

BV-OCR està dissenyat i optimitzat per a GPUs NVIDIA: corre en Linux amb una GPU NVIDIA (Turing o posterior), amb ~4 GB de VRAM per a només text i ~8 GB per al pipeline complet.