Baidu Unlimited-OCR: un documento largo en una sola pasada, on-prem

El núcleo es una atención modificada en el decoder que mantiene la memoria constante. Los modelos OCR clásicos basados en transformer dejan crecer la llamada KV-cache con la longitud del documento. Cuanto más largo el PDF, más memoria, hasta que en algún momento ya no cabe en un solo procesamiento.

Unlimited-OCR reemplaza esa parte por Reference Sliding Window Attention (R-SWA). La KV-cache permanece así constante, independientemente de la longitud del documento. Justamente eso significa el término one-shot long-horizon parsing: un documento largo se lee en una sola pasada, en lugar de descomponerlo en secciones y unir los resultados después.

Notable es la vía de entrenamiento. El equipo no empezó desde cero, sino que entrenó adicionalmente el checkpoint de DeepSeek-OCR: congeló el encoder y solo ajustó el decoder a lo largo de unos 4.000 pasos. Con ello el modelo está en línea directa con DeepSeek-OCR, que ya hemos situado en el contexto del stack. Código y pesos están abiertos en GitHub.

El verdadero problema con los documentos largos no es la página individual, sino la coherencia a lo largo de las páginas. Cuando un modelo corta un documento de 60 páginas en bloques de diez páginas, se pierde justamente lo que cuenta en el día a día B2B: una tabla que cruza el salto de página, una cláusula que se refiere a una sección anterior, una posición cuya referencia está veinte páginas antes.

Una KV-cache constante permite mantener todo el documento en un solo contexto. La memoria no crece con la longitud, así que la estructura se conserva a lo largo de todas las páginas. De paso se vuelve más rápido: Baidu menciona en el modo base 5.580 tokens por segundo frente a 4.951 de DeepSeek-OCR, y con un límite de salida de 6.000 tokens la diferencia ronda el 35 por ciento.

En precisión, Unlimited-OCR se sitúa en OmniDocBench v1.5 en 93,23 puntos, 6,22 por encima de la base de DeepSeek-OCR, y en v1.6 en 93,92. Esas son las cifras del paper. En sus propios documentos, al final cuenta cómo el modelo maneja sus tablas, sellos y formularios, no el promedio de un conjunto de pruebas público. Emparentado está el desarrollo de los LLM subcuadráticos, que abaratan el contexto largo on-prem.

El beneficio surge allí donde documentos largos y estructurados deben convertirse en datos limpios y buscables. Unos cuantos puntos concretos:

• Contratos y acuerdos marco. Las referencias cruzadas y los anexos permanecen legibles en su contexto, en lugar de desmoronarse en los límites de bloque.
• Manuales técnicos y normas. Documentos largos con figuras, tablas y secciones numeradas en una sola pasada.
• Facturas y comprobantes de varias páginas. El texto extraído con limpieza es el paso previo para el procesamiento estructurado posterior, por ejemplo hacia la factura electrónica.
• Archivos y expedientes. Fondos que hasta ahora solo existían como escaneo se vuelven legibles por máquina, sin entregarlos a un servicio en la nube.

En casi todos los casos el OCR no es la meta, sino el primer paso. El texto parseado con limpieza es la base para una base de conocimiento con RAG: cuanto mejor el parsing, mejor encontrará la búsqueda después el pasaje correcto.

No toda tarea documental necesita reconocimiento de texto clásico, y esa es una ponderación honesta. Existe ya toda una rama que ni siquiera convierte los documentos en texto, sino que los busca como imagen, con modelos como ColPali o ColQwen. Este enfoque libre de OCR lo hemos descrito por separado.

La regla práctica que a nosotros nos ha funcionado:

• Necesita los caracteres reales (importes de factura, cláusulas contractuales, extracción estructurada, traspaso a otro sistema): entonces difícilmente hay salida sin OCR, y un modelo como Unlimited-OCR es potente aquí.
• Necesita el pasaje adecuado, no el texto completo (responder una pregunta sobre un gran fondo, reencontrar una figura): entonces la búsqueda visual de documentos puede ser el camino más directo.

A menudo es ambas cosas a la vez. Unlimited-OCR abarata la parte de OCR de ese stack y la hace más fiable en documentos largos.

Un buen valor de benchmark es motivo para probar el modelo, no para ponerlo en producción. Antes de poner Unlimited-OCR en un proceso de cliente, comprobaría cuatro cosas:

🔸 Documentos en alemán y escritura a mano. Las cifras de benchmark dicen poco sobre formularios alemanes, expedientes antiguos o anotaciones manuscritas. Eso pertenece a un conjunto de pruebas propio de documentos reales.

🔸 Tablas y layout. En documentos B2B, la fidelidad de tablas y columnas decide la utilidad. Aquí vale la pena la comparación directa con el stack actual.

🔸 Hardware y operación. 3B como MoE con unos 500M de parámetros activos es realista on-prem. Lo que eso significa en concreto en memoria de GPU y rendimiento hay que medirlo antes del despliegue, no estimarlo.

🔸 Licencia y procedencia. MIT permite el uso comercial, on-prem, sin notas al pie. Que el rastro del modelo lleve a uno de los autores de DeepSeek-OCR es una señal de calidad, pero no reemplaza la propia verificación.

Lo realmente interesante de esta publicación es para mí menos el modelo en sí que la dirección: documentos largos en una sola pasada, suficientemente pequeños para el propio centro de datos, bajo una licencia que no restringe a nadie. Justamente ahí el procesamiento de documentos en la pyme se vuelve práctico. ¿Cuáles de sus documentos haría pasar primero?