se suponía que debían ser leídos por una máquina. Facturas antiguas de hotel, extractos bancarios, nóminas, solicitudes de préstamos, facturas médicas, formularios de aduana, expedientes judiciales, órdenes de trabajo.
La mayoría de las empresas utilizan herramientas gratuitas junto con API pagas para intentar convertir estos documentos, y si desea una salida estructurada, las API como Textract Structured le costarán alrededor de $ 65 por cada 1000 páginas.
Sin embargo, en los últimos años han aparecido muchas opciones nuevas: modelos de visión de código abierto más pequeños especializados para OCR, modelos de lenguaje de visión general y herramientas de análisis de documentos como LlamaParse, cambiando lo que es posible y su costo.
Así que me pareció un buen momento para hacer mi propio experimento para probar algunos de estos con documentos de diferente dificultad.
Busqué 93 documentos que podrían actuar como un indicador de para qué las empresas usan OCR (notas escritas a mano, tablas, documentos financieros heredados, facturas escaneadas, recibos, gráficos, periódicos antiguos, formularios de impuestos) y luego los ejecuté en 14 motores diferentes.
La idea era ver cómo manejaban dos cosas: la recuperación de texto y la capacidad de preservar la estructura útil de las tablas.
La pregunta principal que quería respuesta: ¿realmente necesitas pagar $65 por 1.000 páginas estructuradas, o puedes reducir eso a una fracción? ¿Y los modelos especializados ganan a los generalistas?
Al hacer experimentos como este siempre encuentras bastantes cosas extrañas, que también cubriré. Pero para responder a la pregunta principal, le explicaré qué es el OCR (omítalo si no es nuevo), los aspectos económicos, la prueba, algunos de los resultados y qué más me mostró esto.
Nota: No probé la extracción de campo completo, ya que es más difícil comparar limpiamente entre catorce motores.
TL;DR
No existe un mejor motor de OCR. OCR es un problema de enrutamiento.
Para documentos limpios de gran volumen, Tesseract sigue siendo difícil de superar porque es gratuito y rápido. Para documentos de producción mixta, Gemini Flash fue el mejor todoterreno en esta prueba. Para las tablas, Mistral OCR parecía la opción estructurada más económica.
Los modelos especializados más pequeños lucían bien dentro de su zona de confort, pero fallaron aún más en documentos que no habían visto. Por lo tanto, para documentos confusos o de alto riesgo, tiene sentido escalar a un modelo más grande.
La conclusión principal es económica: no pague por el costoso OCR estructurado cuando el documento no lo necesita. Clasifique sus documentos, pruebe motores con sus propios datos y realice rutas según el costo, la precisión, la estructura y la tolerancia a fallas.
Los puntos de referencia son útiles para el descubrimiento, pero no le indicarán qué funciona en sus documentos.
Explícame el espacio OCR
OCR (reconocimiento óptico de caracteres) es la forma en que una máquina convierte una imagen en texto legible por máquina. Simple en principio, y para documentos más fáciles en su mayoría resueltos, pero más difícil cuando las cosas se vuelven más humanas.
Solo para brindarle una descripción general rápida, el OCR anterior encontraba texto en una página, lo dividía en caracteres y comparaba cada uno con una biblioteca de formas conocidas. Tesseract ha hecho esto desde los años 1980.
Sin embargo, el OCR moderno (incluidas las versiones más recientes de Tesseract) suele utilizar una red neuronal que examina toda la página a la vez y genera el documento como texto. Entonces, si su documento es un PDF limpio o un escaneo de alta calidad en una fuente estándar, el OCR es en gran medida un problema resuelto.
Deja de resolverse en el momento en que las cosas se complican más: recibos fotografiados, notas escritas a mano, gráficos y tablas extraños, tablas financieras densas o formularios de impuestos y solicitudes de préstamos escaneados.
Las empresas necesitan que esto se haga bien por razones obvias, ya que es algo sobre lo que actúan todos los sistemas posteriores. Cuanto mejor es el OCR, más papeleo se convierte en algo sobre lo que un sistema puede razonar en lugar de algo que un humano tiene que leer a mano.
También está el hecho de que si alimentamos a los sistemas de inteligencia artificial con documentos mal analizados, será difícil confiar en todo lo que suceda después.
Me encanta la economía, así que este espacio me llamó la atención una vez que vi cuánto dinero se invierte en él. Se prevé que el mercado del procesamiento inteligente de documentos (IDP) crezca hasta alcanzar entre 20.000 y 90.000 millones de dólares a principios de la década de 2030, según a qué analista se le pregunte.
Probablemente impulsado por empresas que pagan entre 15 y 25 dólares por factura en costos de manipulación manual.
Y como me mantengo cerca del mundo de la tecnología, he visto una ola de pequeños modelos de OCR especializados durante el año pasado (en su mayoría chinos), que ahora son utilizados por desarrolladores de todo el mundo.
Lo que plantea la pregunta que quería probar: ¿pueden los pequeños modelos de código abierto realmente hacer el trabajo que cobran las costosas API o deberíamos buscar modelos de visión general para manejar también OCR?
Omita la siguiente sección si desea comprender lo que mostró este experimento. Primero tengo que realizar la configuración de prueba.
Los documentos, los motores y las métricas.
Este experimento se reduce a tres preguntas: qué motores usamos, con qué documentos probamos y cómo decidimos quién ganó.
Para los motores, quería una gama que cubriera todas las opciones de las que hablé, esto significaba: antiguo y nuevo, abierto y cerrado, local y en la nube, especializado y general.
Tesseract se convirtió en la elección clásica. Se ejecuta localmente y es muy rápido. Luego agregué dos canales de análisis de documentos: Docling y Marker. Docling es más lento pero se ejecuta en la CPU, Marker es de peso abierto pero necesita una GPU para funcionar rápidamente, lo que se muestra más adelante en el precio.
Luego, la nueva ola de modelos OCR abiertos especializados: GLM-OCR, PaddleOCR-VL, DeepSeek-OCR y MinerU 2.5 (un caso límite, en realidad una tubería con un VLM en su interior). Los elegí de la tabla de clasificación OmniDocBench de OpenDataLab, donde ocuparon el primer, segundo, cuarto y quinto lugar.
Los alojé en Modal y entregué los correspondientes con vLLM, agrupando por lotes para acelerar las cosas. Conté el tiempo de ampliación cuando midí la latencia más tarde.
También agregué un modelo cerrado especialmente diseñado, Mistral OCR, del que había oído hablar bien.
En el lado abierto, utilicé Qwen3-VL (8B, de Alibaba), también alojado en Modal con el resto de modelos más pequeños. Debo señalar que le di un mensaje de transcripción simple en lugar de la configuración de publicación optimizada para la que fue diseñado, por lo que es posible que no le haya dado una oportunidad justa.
En el lado cerrado, para los modelos generales, elegí Gemini Flash 3.1 Lite (actualmente primero en la tabla de clasificación IDP, la contraparte occidental construida sobre OmniDocBench v1.5) y Claude Sonnet 4.6, en sexto lugar.
Para los servicios documentales en la nube: LlamaParse y AWS Textract, tanto en su forma textual como estructurada. Structured Textract puede hacer mucho más de lo que le pedí. Solo probé la precisión del texto en todos los ámbitos y la extracción de tablas en ocho de los otros motores.
Pasemos a los documentos. Elegí diecisiete tipos de documentos que eran fáciles, medios o difíciles. Noventa y tres expedientes en total.
Fácil fue lo que el OCR resolvió principalmente hace años: facturas y recibos limpios. El medio provino en gran medida del conjunto de datos OmniAI OCR Benchmark: extractos bancarios, notas médicas, recibos fotografiados, documentos de envío, formularios de impuestos.
Se eligió Difícil cuando las cosas se pusieron más difíciles: gráficos, formularios, notas escritas a mano, tablas financieras extrañamente escaneadas, documentos legales, periódicos e informes antiguos.
Algunos documentos eran realmente bastante difíciles, como los documentos escaneados heredados que ves a continuación, y esto se debía simplemente a que tenía curiosidad por saber si algunos realmente podían hacerlo bien.
Algunas de estas imágenes venían con datos básicos de oro y otras no, y los datos básicos que tenía no siempre eran consistentes, algunos archivos estaban etiquetados correctamente, otros no, por lo que también deberíamos cubrir brevemente las métricas.
Dado que cada motor emite marcas diferentes, la puntuación habitual no encajaba del todo. Se podría elegir Precisión y Recuperación para un caso como este.
La precisión analiza cuántas palabras de la salida de OCR coinciden realmente en el GT, mientras que Recall mide cuántas veces se capturó cada palabra GT.
La precisión castigaría a los motores que emiten una estructura de rebajas que el GT no contiene; además, el GT a veces se saltaba las etiquetas por completo, lo que castigaría al motor injustamente. El recuerdo mediría las palabras pero castigaría la frecuencia.
Entonces, agregué una tercera métrica llamada Cobertura. Sólo quería medir qué parte de la verdad fundamental aparece en algún lugar de la potencia del motor. No es perfecto, pero me dice si un motor captó la mayor parte de lo que importaba, sin penalizarlo por brechas que fueron culpa del terreno y no del motor.
Para los documentos sin ninguna verdad fundamental, recurrí a un juez de LLM, con Gemini 3 Pro como modelo base y cualquiera que haya usado uno sabe que este es un negocio voluble.
Lo que mostró este experimento
Asignamos cada documento a la métrica de Cobertura para crear un gráfico de dispersión y realizamos un seguimiento de la latencia en un gráfico separado. Sin embargo, lo que un gráfico generalizado no puede decirle es que los motores fallaron de diferentes maneras.
El gráfico de burbujas mostró que la mayoría de los motores se ubican en algún lugar en el medio superior, con dos valores atípicos a ambos lados.
Gemini Flash y Textract Text obtuvieron muy buenos resultados en todos los ámbitos con algunos casos extremos. Todos los modelos especializados estaban por debajo de los modelos generales y las API especializadas. Sonnet obtuvo el rendimiento más alto, pero también con un precio más elevado.
Puede que esto no haya sido una sorpresa, ya que el conjunto de prueba era muy inusual. Es posible que algunos de los modelos especializados no hayan visto muchos de ellos. Además, esta prueba se realizó con documentos en inglés y la mayoría de estos modelos más pequeños son de origen chino.
Cuando también mapeamos la latencia, algunos de los modelos resultaron ser muy lentos, pero nuevamente la mayoría terminó en algún punto intermedio.
Los valores atípicos aquí fueron: Tesseract, Claude Sonnet 4.6 y Docling. Tesseract fue increíblemente rápido en comparación con todos los demás motores. Debería ser su opción para documentos más fáciles.
Estos gráficos se generalizan en todos los documentos, pero separé los resultados según el tipo y el nivel de dificultad.
Para empezar con los documentos sencillos. En las facturas, todos los motores obtuvieron buenos resultados, especialmente el Tesseract. Los recibos derribaron un poco a todos.
El único caso atípico fue Docling, que tuvo problemas en muchas categorías, incluso en las fáciles.
Cuando analicé los fallos de Docling encontré cosas como Ifjointreturn en lugar de “retorno conjunto” y, peor aún, cadenas como City,wrostffielfouaveaoreignadresalcomletacesb. DeepSeek también omitió detalles clave aquí, como el número de factura y la fecha, por lo que su número es bajo.
El mismo patrón se mantiene en la categoría media, aunque ahí es donde PaddleOCR comenzó a degradarse en tipos específicos: extractos bancarios, envíos, formularios de impuestos. Los formularios de impuestos fueron difíciles para todos, pero PaddleOCR y Docling terminaron al final.
Textract fue el mejor motor en muchos de los tipos medianos, junto con Claude Sonnet 4.6 y Mistral OCR.
En los tipos más difíciles, Gemini Flash comenzó a crecer, superando a Textract en formularios y notas escritas a mano, igualándolo en otros lugares. Le fue notablemente bien en todas partes. Tesseract y Docling fracasaron mucho con la escritura a mano y los formularios también les resultaron difíciles.
Casi todos los modelos especializados no salieron adelante en estos documentos más difíciles, excepto en las tablas financieras, donde se mantuvieron casi igualados.
Para los documentos sin fundamento (periódicos, asuntos legales, informes, algunos documentos heredados escaneados) utilizamos un juez de LLM. Estos son realmente difíciles, por lo que no sorprende que casi todos fallaran en los informes y periódicos.
Excepto Gemini Flash, que tuvo un desempeño razonablemente bueno en todas partes. Mistral OCR también obtuvo buenos resultados en los periódicos. Gemini Flash ganó en todas partes con el juez, aunque usamos Gemini Pro como juez, así que tómalo con cautela (pero lo revisé dos veces).
Antes de terminar: también ejecuté 8 motores contra Textract Structured para ver cómo les iba en las tablas financieras, extrayendo una tabla HTML. Utilicé la salida de Textract Structured como base para TEDS (Tree Edit Distance Similarity) y califiqué Claude Sonnet 4.6, LlamaParse, Mistral OCR, Gemini Flash, Marker, MinerU, DeepSeek-OCR y Docling en su contra.
Mistral OCR, LlamaParse y Sonnet obtuvieron muy buenos resultados y fueron mucho más baratos. También lo pasé por un juez de LLM y los ganadores fueron los mismos tres (incluso antes de Textract Structured), aunque me gustaría desarrollar mejor esa prueba antes de confiar plenamente en ella.
Ahora, hablemos de lo que cuesta ampliar esto y de qué tendría sentido y dónde.
¿Cuándo tiene sentido lo que
Repasemos lo que cuesta escalar con estos motores y luego, según estos documentos, qué elegiría y dónde.
Primero, el costo de usar estos motores varía enormemente, como vio antes. A veces ayuda ver el costo no solo de un documento, sino de miles hasta un millón.
Nos hospedamos nosotros mismos en Modal, por lo que estos costos provienen del uso real allí. Puedes ejecutarlo localmente, pero mi computadora no lo permitía y no quería probarlo.
Si tuviera que utilizar un solo motor que maneje documentos tanto fáciles como difíciles, creo que terminaría con una factura mayor de lo necesario. El uso de Textract Structured para cualquier documento que no sea necesario le generaría una factura de $6.5 mil por cada 100 mil documentos.
Me pregunto cuántas empresas optan por el camino fácil y eligen las opciones costosas para documentos fáciles y difíciles y dejan mucho dinero sobre la mesa.
La idea clave que debe tener aquí es que no existe un mejor motor para cada caso de uso, depende del tipo de documento, la privacidad, la estructura de la tabla, la tolerancia a fallas, el costo, etc.
Para los documentos que tenemos aquí, Gemini Flash 3.1-Lite es un claro ganador. Éste tenía razón al mirar las tablas de clasificación. A Mistral OCR le fue bien en tablas estructuradas sin dejar de ser barato. Claude Sonnet 4.6 también funcionó muy bien, pero es comparativamente muy lento y caro.
La documentación es muy lenta en mi computadora portátil. Estoy seguro de que hay formas de acelerarlo, pero también falló de manera que lo hace inherentemente inestable (aunque sigue siendo una prueba pequeña).
Los modelos de OCR especializados eran un dolor de cabeza, especialmente en documentos en inglés; Vi errores de salida en chino que cubriré más adelante, así que me pregunto si eso es parte del problema.
Textract es una opción estable, pero estructurado casi no le brinda precisión de texto adicional, por lo que si está pagando ese alto margen de beneficio por una salida estructurada, asegúrese de usarlo. Supongo que es un modelo de negocio bastante bueno para ellos.
Entonces, en general, para esta prueba tan pequeña: para una impresión limpia y de gran volumen, simplemente use Tesseract. Para una producción heterogénea general, utilice Gemini Flash. Para un costo mínimo con estructura de tabla, pruebe Mistral OCR. Para documentos de alto riesgo, opte por Sonnet o un modelo más grande.
Dado que a todos les fue bien en diferentes maneras, tendrás que contactarme para obtener detalles específicos, pero si necesitas hacerlo en privado, puede que valga la pena intentar ajustar un modelo en tus documentos. O utilice un modelo pequeño especializado y escale las fallas.
Permítanme hablar rápidamente sobre algunas cosas que se destacaron después de realizar este experimento.
Otras cosas que debo mencionar
De esto surgieron un puñado de cosas que vale la pena sacar a la luz por sí solas.
En primer lugar, si desea comprender cómo funcionará un modelo o motor en sus documentos, la única forma es realizar pruebas en esos documentos; no puede confiar en los puntos de referencia para saberlo. Esta fue la idea número uno que mostró. La utilidad del OCR depende de su propia combinación de documentos, diseños, idiomas, escaneos, tablas, escritura a mano y tolerancia a fallas.
No pague por la estructura si no la necesita. Me pregunto cuántos utilizan ciertas API o modelos por una razón que no pueden justificar. Mapee el costo para comprender lo que está perdiendo al no utilizar el motor correcto para los documentos.
Los modelos especializados, como se mencionó anteriormente, tienen límites muy claros. Esto es obvio, pueden ser excelentes dentro de su distribución de entrenamiento pero fallar fuera de ella. Aquí es donde ganarán los modelos generales.
Si desea realizar ajustes, puede ser útil, pero solo si la secuencia es estable, ya que también fallará si se introducen constantemente nuevas clases de documentos.
Por último, los modos de falla nos dijeron más que los promedios.
PaddleOCR tenía bucles de repetición, fusión de columnas y respaldo al texto de plantilla de libro de texto chino como 书名:___ repetido cientos de veces. Mientras que Docling tiene errores de caracteres, fusión de palabras y desalineación de columnas, todos se acumulan.
DeepSeek OCR tiene ceguera para los gráficos y resultados vacíos en algunos documentos. Tesseract funcionó bien en documentos limpios (como se mencionó), pero falló en fotografías/escritura a mano y generó basura por completo.
Advertencias a considerar
Antes de terminar, permítanme explicarles cómo esta prueba es, en última instancia, imperfecta, nombrando los problemas en el GT, las métricas utilizadas y el tamaño de la muestra.
Cubrí esto en una de las secciones anteriores, pero la verdad fundamental difiere entre los documentos según el conjunto de datos donde se encontraron. En general, los artefactos de tokenización pueden hacer que el OCR correcto parezca peor de lo que es.
La mayoría de los motores tienen diferentes formatos, algunos devuelven texto sin formato, algunos rebajados, algunos HTML/rebajado enriquecido y es difícil generalizar entre todos.
Estamos usando Cobertura y luego también algunas otras métricas, pero no son perfectas. La cobertura no cargará el motor si genera demasiado texto o si su estructura no es correcta. Aunque descubrí que los motores que fallaron, lo hicieron al principio o a la mitad en lugar de al final.
Esto significa que es útil para clasificar, pero no es una forma perfecta de puntuar.
Los jueces de LLM no son una verdad neutral: he cubierto esto en el pasado, pero son parciales y muy sensibles.
Entonces solo necesito decir que esta prueba es interesante pero no tan grande, el tamaño de la muestra es demasiado pequeño para usarla como un estudio fáctico. Pero no confío plenamente en estas métricas ni en el juez, por lo que era la única manera de poder verificar los resultados por mi cuenta sin que esto se convirtiera en un proyecto de un año de duración.
Por lo tanto, esta prueba es útil para orientar y tener una idea de lo que funciona, pero para tener una idea de su caso de uso, debe ejecutarla con sus documentos específicos.
Por último, la latencia y la reproducibilidad son inestables. Los arranques en frío sin servidor hacen que la sincronización sea ruidosa y los modelos API pueden cambiar silenciosamente con el tiempo, por lo que la reproducción exacta es difícil.
Como siempre con estos artículos, se necesita bastante tiempo para hacer un experimento como este, pero no lo hago solo por el contenido, lo hago porque tengo verdadera curiosidad.
Sin embargo, lo que parece es que el OCR parece ser un problema de enrutamiento y quizás un problema de evaluación. Clasifique sus documentos y ejecútelos en varios motores, luego intente crear un enrutador y un validador decentes en su proceso para escalar las fallas y luego registrar los costos.
Si necesita obtener los resultados completos de este experimento o quiere que lo revise con sus documentos, póngase en contacto.
Puede seguir mis escritos en Medium, mi sitio web o conectarse conmigo a través de LinkedIn.
❤
Todos los conjuntos de datos utilizados en este punto de referencia están disponibles públicamente y provienen de HuggingFace. Las licencias incluyen MIT, CC-BY-4.0 y marcos de uso legítimo (Biblioteca de documentos industriales de UCSF) que cubren investigación, becas y educación. No se reproducen documentos fuente; los conjuntos de datos se utilizaron únicamente como entradas de evaluación para medir el rendimiento del motor OCR.