BV-OCR: el motor de lectura de documentos, por dentro

Leer documentos a escala operativa son dos problemas disfrazados de uno. El primero es de throughput: una operación real no procesa un PDF, procesa miles —facturas, formularios, correo escaneado— y cada segundo por página se multiplica por todo el archivo. El segundo es de confianza: da igual lo rápido que leas si nadie puede demostrar de dónde salió cada dato. Un motor de lectura que resuelve solo el primero produce errores más deprisa; uno que resuelve solo el segundo no llega a producción.

BV-OCR es el motor de lectura de documentos de BiVelio: la pila que alimenta el módulo Documents y que está debajo del pipeline que describimos en Del documento al dato gobernado. Aquel artículo cuenta qué hace Documents; este cuenta cómo lee. La respuesta corta: con tres piezas coordinadas, y una puerta entre las dos últimas que es la que convierte "salida de un modelo" en "dato con evidencia".

La arquitectura en tres piezas

BV-OCR separa deliberadamente tres trabajos que otros sistemas mezclan en uno:

1. Parsing determinista en GPU —un parser documental propio de BiVelio, escrito en C++ sobre CUDA y TensorRT— convierte cada página en texto literal con coordenadas, estructura de layout, tablas y fórmulas. Rápido, local y reproducible: la misma página produce el mismo texto.
2. Comprensión con un modelo visión-lenguaje compacto, servido con inferencia optimizada para NVIDIA, que propone interpretaciones campo a campo sobre ese texto: cuál de los importes es el total, cuál de las fechas es el vencimiento.
3. La puerta value-in-OCR, la regla central del motor: todo valor propuesto por el modelo debe poder rastrearse hasta un fragmento del texto que el OCR reconoció. Lo que no se ancla, se rechaza y va a revisión humana.

¿Por qué la división? Porque cada pieza es buena exactamente en lo que la otra no puede hacer. El parser determinista da velocidad y texto literal con coordenadas —el ancla física de toda evidencia posterior—, pero no entiende qué significa cada línea. El modelo entiende, pero genera: nada en un modelo generativo garantiza que un valor salga del documento y no de su imaginación. La puerta une ambas mitades: el modelo puede proponer lo que quiera, pero solo lo que existe en el texto reconocido puede entrar en la operación.

La alternativa de moda —un parser VLM puro que mira la página y escribe directamente la salida estructurada— colapsa esas tres funciones en una sola pasada generativa. Es más simple, y en los layouts más difíciles es incluso más preciso (los números, abajo). Pero paga dos precios que para BiVelio son inaceptables: es órdenes de magnitud más lento por página, y no deja ancla literal: el texto que emite es generado, no reconocido, así que no hay fragmento del original contra el que verificar un valor sin releer el documento entero.

Parsing determinista en GPU

La primera pieza es el parser documental de BV-OCR, desarrollo propio de BiVelio escrito en C++ sobre CUDA y TensorRT. No es "un OCR con extras": es un pipeline completo de parsing sobre un único motor GPU multi-stream, local —sin ningún VLM en el bucle— y servido por HTTP y gRPC. Como toda la investigación de BiVelio, corre sobre inferencia y hardware NVIDIA.

Las etapas, en orden:

• Detección y reconocimiento de texto: dónde hay texto en la página y qué dice, línea a línea, con caja de coordenadas y confianza por línea.
• Análisis de layout: qué regiones son párrafo, título, tabla, figura, fórmula.
• Tablas → HTML: la estructura de celdas se conserva, no se aplana en texto corrido.
• Fórmulas → LaTeX.
• Markdown en orden de lectura: todo lo anterior, ensamblado en el orden en que un humano leería la página.

Ese último paso importa más de lo que parece. El Markdown en orden de lectura es lo que la segunda pieza consume: un documento textual fiel, ordenado, con las tablas como tablas y las fórmulas como fórmulas — y donde cada línea sigue siendo rastreable a su región del original. Sin él, el modelo recibiría una sopa de fragmentos sin orden, y "el importe que sigue a la etiqueta Total" dejaría de tener sentido.

Los números del banco de pruebas

Las cifras que siguen salen del banco de pruebas reproducible de BV-OCR, medido sobre datasets públicos en una sola GPU NVIDIA (RTX 5090):

• Throughput: hasta 559 imágenes/s en recibos, 520 en formularios y 200+ en documentos densos, con el tier más rápido (el de por defecto).
• Precisión en formularios y recibos: 92% de word-F1 en FUNSD y 93% en CORD con el tier de mayor precisión.
• Parsing estructurado completo (layout + tablas + fórmulas): ~20 páginas/s con un Overall de 0,90 en un subconjunto de 125 documentos de OmniDocBench (inglés + chino). En ese subconjunto, BV-OCR queda a unos 5 puntos del mejor parser VLM de referencia; los parsers documentales basados puramente en VLM rondan ~1 página/s.

Esa última comparación es el contraste honesto que anunciábamos: en los layouts más difíciles, el mejor parser VLM puro es ~5 puntos mejor. A cambio, el parser determinista es ~20× más rápido y, sobre todo, produce texto reconocido, no generado — la materia prima sin la cual la puerta value-in-OCR no existiría.

Tiers y hardware

BV-OCR ofrece tres tiers que intercambian velocidad por precisión sin cambiar de idiomas: del más rápido —el de por defecto, el de las cifras de throughput— al de mayor precisión, el de las cifras de FUNSD y CORD. Los tres cubren alfabeto latino, chino y japonés; árabe, cirílico, coreano, tailandés y griego se cubren con packs de reconocimiento adicionales.

En hardware, BV-OCR está diseñado y optimizado para GPUs NVIDIA: corre en Linux con una GPU NVIDIA (Turing o posterior), con ~4 GB de VRAM para solo texto y ~8 GB para el pipeline completo.

Comprensión con un modelo visión-lenguaje compacto

El texto literal no basta. Una factura reconocida al 100% sigue sin decirte cuál de sus siete importes es el total, ni cuál de sus tres fechas es el vencimiento. Ese es el trabajo de la segunda pieza: un modelo visión-lenguaje compacto con comprensión nativa de imágenes y documentos, servido con inferencia optimizada para NVIDIA.

Su papel en BV-OCR es deliberadamente estrecho: propone interpretaciones campo a campo sobre lo que el parser determinista ya reconoció. "El total de la factura es 1.240,00 €, el que aparece junto a la etiqueta Total." "La fecha de vencimiento es 2026-09-30, la de la línea Payment due." Propone; no transcribe. El OCR del documento ya está hecho, y hecho por un componente determinista.

Dos cosas que el modelo no hace en BV-OCR:

• No sustituye al OCR. El texto sobre el que trabaja —y contra el que se verificará cada propuesta— es el del parser determinista, no una transcripción propia.
• No decide. Sus propuestas no entran en la operación por sí mismas: cada una tiene que pasar la puerta value-in-OCR, y las dudosas acaban ante una persona.

Una capacidad sí se explota directamente: la profundidad de razonamiento ajustable. Los campos fáciles —una etiqueta clara, un valor al lado— no necesitan cadena de pensamiento; los difíciles —dos totales candidatos, una tabla ambigua— justifican gastar más cómputo en razonar antes de proponer. Un modelo compacto con esfuerzo ajustable permite pagar el razonamiento solo donde hace falta.

La puerta value-in-OCR

La tercera pieza es la razón de ser de las otras dos. La regla es una sola frase: todo valor que el modelo proponga debe poder rastrearse hasta un fragmento del texto que el parser determinista reconoció.

En la práctica, cada propuesta que supera la puerta sale con un localizador de evidencia: la región del original y el fragmento del texto reconocido de donde salió el valor. Eso es exactamente lo que el módulo Documents adjunta a cada campo extraído — el hecho señalable que un revisor comprueba en segundos.

¿Y cuando el ancla no existe? Cuando el modelo propone un valor que no aparece en el texto reconocido —porque lo alucinó, porque lo "corrigió", porque lo derivó de un cálculo—, la puerta lo rechaza. El campo no se descarta en silencio ni se acepta con un asterisco: se enruta a la consola de revisión humana, con el documento delante, para que decida una persona. Un modelo no puede inventarse un valor y que el sistema lo acepte; lo máximo que consigue un valor inventado es una cita con un revisor.

Nótese lo que la puerta no es: no es un umbral de confianza. Un umbral filtra por lo seguro que el modelo dice estar; la puerta filtra por lo que el documento dice. Un valor alucinado con confianza 0,99 pasa un umbral y no pasa la puerta. Esa es la tesis de Del documento al dato gobernado —la evidencia gana a la confianza a secas— aterrizada en el mecanismo concreto que la hace cumplir.

Qué medimos y qué no

Un artículo técnico honesto tiene que separar tres tipos de afirmaciones:

• Las cifras son de nuestro banco de pruebas, sobre datasets públicos. Los números de throughput y precisión de este artículo (559 img/s, FUNSD 92% / CORD 93%, 0,90 en el subconjunto de OmniDocBench) están medidos con el harness reproducible de BV-OCR sobre datasets públicos, en una sola GPU NVIDIA (RTX 5090). Un dataset público no es una promesa sobre tus documentos: un dataset académico de recibos no es tu archivo de contratos escaneados.
• BiVelio no publica porcentajes de precisión sobre documentos de clientes. La precisión sobre tus documentos depende de tu corpus, y se valida en tu propio flujo de revisión. La garantía que sí ofrecemos no es estadística sino estructural: ningún valor entra sin evidencia, y lo dudoso acaba ante una persona.
• BV-OCR está diseñado y optimizado para GPUs NVIDIA. El motor está escrito en C++ sobre CUDA y TensorRT, y toda nuestra investigación corre sobre inferencia y hardware NVIDIA.

Dónde encaja BV-OCR

BV-OCR no es un producto que se compre suelto: es el motor debajo del módulo Documents. El mapa completo:

• El parser determinista lee cada documento ingerido: texto literal con coordenadas, layout, tablas, fórmulas, Markdown en orden de lectura.
• El modelo visión-lenguaje propone los campos que la operación necesita, con profundidad de razonamiento ajustada a la dificultad de cada uno.
• La puerta value-in-OCR ancla cada propuesta al texto reconocido y emite el localizador de evidencia que viaja con el dato.
• Lo rechazado y lo dudoso se encola en la consola de revisión humana —el principio de diseño que desarrollamos en Human-in-the-loop: 5 componentes, no un botón de aprobar— y las correcciones fluyen de vuelta al caso.
• El dato validado alimenta casos y flujos gobernados: permisos, traza de auditoría, puertas humanas en los pasos críticos.

El recorrido completo del dato —de la ingesta al caso— está en Del documento al dato gobernado; este artículo es la sala de máquinas de su primera mitad.

FAQ

¿BV-OCR es un producto separado del módulo Documents?

No. BV-OCR es el nombre del motor de lectura que alimenta el módulo Documents: la capa que convierte el documento en texto anclado y propuestas de campos con evidencia. Documents añade encima la conservación y versionado del original, la consola de revisión y la automatización gobernada.

¿Por qué no usar directamente un modelo visión-lenguaje para todo?

Porque un parser VLM puro genera el texto en lugar de reconocerlo: no deja ningún fragmento literal del original contra el que verificar un valor, y es mucho más lento por página (los parsers documentales basados puramente en VLM rondan ~1 página/s, frente a ~20 en el subconjunto de OmniDocBench citado). Sí es más preciso en los layouts más difíciles —BV-OCR queda a unos 5 puntos del mejor parser VLM de referencia en ese subconjunto—, y lo decimos tal cual: BV-OCR renuncia a esos puntos a cambio de throughput y, sobre todo, de evidencia anclable.

¿Qué pasa si el modelo alucina un valor?

Que no entra. La puerta value-in-OCR exige que cada valor propuesto se rastree hasta un fragmento del texto reconocido por el parser determinista; un valor que no aparece en ese texto se rechaza y el campo se enruta a la consola de revisión humana. La alucinación no se convierte en dato: se convierte en una tarea de revisión.

¿Las cifras de velocidad y precisión son de BiVelio?

Sí. Están medidas con el banco de pruebas reproducible de BV-OCR sobre datasets públicos (FUNSD, CORD y un subconjunto de OmniDocBench), en una sola GPU NVIDIA. Lo que BiVelio no publica son porcentajes de precisión sobre documentos de clientes: la precisión sobre tu corpus se valida en tu propio flujo de revisión, y la garantía que ofrece el sistema es estructural (evidencia obligatoria + revisión humana), no un número.

¿En qué hardware corre el motor?

BV-OCR está diseñado y optimizado para GPUs NVIDIA: corre en Linux con una GPU NVIDIA (Turing o posterior), con ~4 GB de VRAM para solo texto y ~8 GB para el pipeline completo.