No existe el OCR perfecto

La pregunta equivocada

«¿Qué OCR me recomiendas?» es una pregunta trampa. Llevo años digitalizando archivos (facturas, contratos, expedientes, papeles de hace décadas) y si algo he aprendido es que ningún motor gana en todo. Los rankings de internet comparan motores sobre datasets académicos que no se parecen en nada al cajón de papeles real de una empresa: escaneos torcidos, sellos encima del texto, fotocopias de fotocopias, letra de médico.

La única respuesta honesta es: depende de tus documentos. Y eso no se opina; se mide. Así que lo medimos.

El banco de pruebas

El corpus: 56 facturas escaneadas reales (102 páginas) de cinco empresas distintas, con los seis campos que importan en contabilidad (NIF, número de factura, fecha, base imponible, IVA y total) validados a mano por humanos como verdad de referencia. Nada de datasets académicos: papel real, escaneado como se escanea en una oficina.

Encima, un harness reproducible: pasa cada motor candidato por todo el corpus, normaliza formatos (fechas, decimales) y puntúa campo a campo. Montarlo costó una tarde con ayuda de la IA; re-evaluar un motor nuevo cuesta minutos. Resultado: siete rondas de shoot-out en tres semanas, cada una respondiendo una pregunta concreta. El servicio final lleva además su propia batería de tests automatizados (30+ tests con salidas reales de los motores como fixtures), para que recalibrar algo no rompa lo demás sin enterarnos.

Ronda 1: los OCR clásicos entre sí

Primera pregunta: de los motores que corren en CPU, sin GPU y sin pagar por página, ¿cuál recupera más datos? Métrica: el valor correcto aparece en el texto extraído.

Sorpresa: el motor más ligero (~50 MB de modelos) gana en precisión Y en velocidad. Y una lección que justifica el benchmark por sí sola: nuestra primera integración de MinerU puntuaba un ridículo 25,3%. El benchmark destapó el motivo: el parser leía solo los bloques de texto plano y se perdía las tablas, que es exactamente donde viven los importes de una factura. Arreglado el parser: 73,5%. Sin el benchmark, ese bug habría llegado a producción indexando facturas sin importes.

Ronda 2: los modelos de visión generalistas

Segunda pregunta, con métrica más exigente: no «¿está el dato en el texto?» sino «¿me devuelve el campo extraído, estructurado y exacto?». Aquí entran los modelos grandes de visión leyendo el PDF directamente:

La brecha entre ambos no es visual, es semántica: los dos leen bien, pero el avanzado distingue el NIF del emisor del NIF del cliente (del 38% al 82%). Y lo que ni el avanzado saca (base e IVA ~75-80%) no son errores de lectura: son retenciones, suplidos e inversiones del sujeto pasivo. La factura dice una cosa y la contabilidad registra otra. Eso no lo arregla ningún OCR; lo arreglan validaciones de negocio.

El desfile de aspirantes (o por qué no fiarse de rankings)

Durante las semanas siguientes pasamos por el mismo corpus cada modelo especialista en OCR que la prensa técnica coronaba como el nuevo campeón. Todos llegaban con benchmarks públicos espectaculares. Contra nuestras facturas:

Siete veces medimos y siete veces se confirmó la regla: los benchmarks públicos no transfieren a tus documentos. El caso más peligroso fue el modelo que inventaba: NIFs con dígitos cambiados, fechas de 2026 convertidas en 2020, importes cercanos pero falsos. Errores que pasan una revisión visual rápida precisamente porque parecen válidos. Un motor que falla escupiendo basura es molesto; uno que falla inventando datos verosímiles es un peligro.

Otra constante: el techo de ~86% en presencia de campos lo marcaron los propios escaneados, no los motores. A partir de cierta calidad de papel, cambiar de motor no compra nada.

Manuscrito: otra liga

Todo lo anterior es documento impreso. Con manuscrito el cuadro cambia por completo, y aquí el corpus de pruebas es especialmente mío: mis propias libretas de hace años, con ideas de proyectos que nunca digitalicé porque ningún OCR podía con ellas.

Los OCR clásicos producen con esto directamente basura: texto corrupto, inutilizable (la literatura independiente mide <3% de palabras exactas en manuscrito difícil). Los modelos grandes de visión, en cambio, sacan texto casi perfecto de las mismas páginas, con layout respetado e incluso las tachaduras marcadas.

Y aquí toca dar un nombre: de todo lo que he probado, Chandra es de lejos el que mejores resultados produce en manuscrito. Nada de lo que ha pasado por el banco de pruebas se le acerca: transcribe mis libretas casi perfectas donde el resto ni empieza. La letra pequeña es que cobra en GPU y en tiempo por página: es un modelo pesado, que quiere una gráfica seria y avanza a ritmo de segundos por página, no de milisegundos. Mi lectura práctica: si es para un servicio propio, con tu volumen y tu paciencia, adelante: GPU en casa y a correr. Pero si vas corto de VRAM, o quieres dar servicio a terceros con garantías de latencia y volumen, probablemente lo sensato sea subalquilar la solución: la versión alojada por API o GPU por horas, pagando céntimos por página en vez de mantener el hierro encendido. Es la misma lógica de todo el artículo: el motor caro, solo para los documentos que lo necesitan, y solo en la modalidad que te salga a cuenta.

Con matiz importante: eso vale para notas y texto corrido. Los formularios manuscritos (casillas, campos, letra apretada) siguen siendo el punto débil universal: ahí ningún modelo actual pasa del aprobado raspado, y la revisión humana no es opcional.

Lo que aguanta un motor y lo que no: degradación medida

Este experimento viene de antes del shoot-out, y le tengo cariño porque conecta con la otra mitad de mi trabajo: la gestión documental. El motor clásico de aquellas pruebas era el de Therefore, el gestor documental de Canon que llevo más de una década implantando y que bajo el capó utilizaba IRIS como motor de OCR. Y un apunte justo: su Capture Client era un buen cliente para hacer automatizaciones de captura (carpetas vigiladas, perfiles de escaneo, clasificación al vuelo); el eslabón débil no era el flujo, era lo que el OCR de entonces podía leer.

La prueba: cogimos una factura real y generamos 29 variantes degradadas (desenfoque, brillo, ruido, resolución, inclinación, y combinados tipo «fotocopia vieja», «fax», «foto de móvil»). Umbrales medidos con ese OCR clásico:

• Por debajo de 100 dpi, fallo total (a 50 dpi, cero caracteres).
• Inclinación de 3° o más: se pierde entre un tercio y dos tercios del texto.
• Calidad fax: queda un 29%.
• El ruido apenas afecta (94%+ de acierto hasta niveles altos).

El mismo lote degradado con un modelo de visión: ~100% de campos hasta 72 dpi, donde el clásico sacaba entre 0 y 67%. Estos umbrales no son trivia: son exactamente las puertas del router: rechazar por resolución, auto-enderezar por inclinación, detectar calidad-fax y escalar al motor pesado.

Ninguna lectura única basta: el acuerdo de dos lecturas

La conclusión transversal de todas las rondas: ni el mejor OCR ni el mejor modelo de visión bastan solos. Lo que sí funciona, medido:

1. Dos lecturas independientes del mismo documento, con motores de familias distintas, y comparar campo a campo.
2. Validación aritmética encima (¿base + IVA ≈ total?): esa regla sola cazó 22 de 22 casos en que ambas lecturas coincidían en un valor equivocado. Todos eran discrepancias contables (retenciones, suplidos), no errores de lectura.
3. El resultado final: en documentos que pasan la validación, el acuerdo entre las dos lecturas tuvo 100% de precisión medida (197/197 campos). Eso permite auto-aprobar ~89% de los campos con cero errores observados, y mandar a revisión humana solo el ~11% restante más los documentos marcados.

Coste de todo el cruce: unos céntimos por documento escaneado. Y solo los escaneados, que son ~10% del volumen real.

El pipeline resultante

Con los datos encima de la mesa, el sistema no elige «un OCR»: elige una cadena, con lo barato primero y lo pesado al final:

Documento
    -> ¿tiene capa de texto? (~90% de docs reales)
         sí -> extracción directa, milisegundos, gratis
    -> clasificador ligero (impreso / manuscrito / degradado)
    -> impreso  -> motor clásico rápido en CPU
    -> ¿salida sospechosa? (detector de texto-basura, sin diccionario)
         -> siguiente motor de la cadena
    -> tablas y estructura -> motor de layout, bajo demanda
    -> manuscrito o degradado -> modelo de visión grande
    -> campos críticos -> segunda lectura independiente + validación
         acuerdo -> auto-aprobado | desacuerdo -> revisión humana

La mayoría de los documentos los resuelve la vía barata en milisegundos; solo los difíciles escalan hasta la artillería. Y cuando los documentos no pueden salir de la empresa, esa artillería corre en GPU propia, en casa.

El resultado

• Decisiones de motor basadas en datos propios, no en rankings de internet (que, medidos siete veces, siete veces fallaron).
• Un bug de producción (facturas sin importes) cazado por el benchmark antes de desplegarse.
• Un pipeline que escala el coste al documento: lo fácil, gratis o casi; lo difícil, con artillería.
• Campos críticos auto-aprobados con doble lectura y cero errores medidos.
• Un banco de pruebas listo: cuando salga el próximo «campeón del OCR», evaluarlo sobre nuestros documentos cuesta una tarde, no un mes.

Esto es parte de cómo trabajo en Soft2Help. La parte de negocio (para qué sirve digitalizar bien un archivo) la cuento en cómo elegir un software de gestión documental.