Unlimited OCR — el modelo de Baidu para análisis de documentos largos en una sola pasada

 (github.com/baidu)
1 puntos por GN⁺ 4 시간 전 | 1 comentarios | Compartir por WhatsApp
  • Un modelo OCR E2E basado en DeepSeek OCR que reemplaza toda la atención del decodificador para transcribir documentos de decenas de páginas en una sola pasada hacia adelante (forward pass)
  • La clave es Reference Sliding Window Attention (R-SWA), que mantiene el KV cache constante incluso cuando aumenta la longitud de decodificación, evitando el crecimiento del costo de memoria y cómputo
  • Imita la memoria de trabajo (working memory) de un humano que copia un libro: olvida suavemente las salidas lejanas y solo consulta el contexto cercano
  • En OmniDocBench v1.5 alcanza 93%, 6% por encima de DeepSeek OCR, y en v1.6 logra 93.92%, alcanzando SOTA end-to-end
  • R-SWA es un mecanismo general de atención para parsing que puede aplicarse más allá de OCR, en tareas largas basadas en referencia como ASR y traducción

Contexto y definición del problema

  • Los humanos pueden realizar tareas largas como transcribir cientos de páginas o traducir horas de audio sin perder eficiencia, pero los modelos OCR existentes no pueden analizar ni siquiera 10 páginas en una sola pasada
    • Los modelos actuales procesan por página con un esquema de for-loop, reiniciando la memoria en cada paso
    • Ese enfoque es solo una solución de ingeniería que fragmenta un proceso largo y coherente en tareas cortas aisladas, no un avance hacia una inteligencia orientada a AGI
  • Usar un LLM como decodificador mejora el rendimiento al aprovechar la distribución previa del lenguaje, pero a medida que la salida crece, el KV cache acumulado aumenta el consumo de memoria y ralentiza gradualmente la generación
  • El comportamiento humano al transcribir no corresponde ni a full attention estándar ni a linear attention
    • No vuelve a recorrer todo el texto ya escrito; mantiene el rumbo consultando solo el contexto cercano
    • Los tokens visuales/de referencia no reciben actualización de estado recurrente; si se actualizan, las características visuales se degradan gradualmente y cae la precisión de reconocimiento

Reference Sliding Window Attention (R-SWA)

  • Cada token puede acceder a todos los tokens de referencia (tokens visuales + prompt), mientras que la atención sobre la salida se limita solo a los n tokens anteriores inmediatos (128 por defecto)
    • Así, cada token conserva conciencia de la imagen completa mientras sigue de forma autónoma el progreso del OCR mediante transiciones de estado dentro de una ventana deslizante causal
    • Durante la inferencia, el KV cache se mantiene constante, reduciendo la presión de memoria y el costo computacional
  • La atención se restringe a una ventana de dos segmentos de tamaño m+n
    • m es la ventana de prefijo que incluye tokens visuales y prompt; permanece fija durante una inferencia y depende solo del número de páginas y la resolución, no de la longitud de decodificación
    • n es la ventana del área de decodificación, de tamaño fijo y con deslizamiento causal

  • Gestión del KV cache

    • La línea base DeepSeek OCR usa MHA estándar, por lo que el tamaño del KV cache crece sin límite como Lm + T
    • R-SWA conserva todo el cache de prefijo Lm, pero de lo generado guarda solo los n tokens más recientes, de modo que el tamaño del cache queda acotado por Lm + min(n,T) ≤ Lm + n
    • Cuando la longitud de salida es suficientemente grande, la razón de cache ρ(T) converge a 0 → el crecimiento lineal se reduce a una constante

  • Análisis del kernel

    • En mediciones del kernel Flash Attention v3, el MHA estándar de DeepSeek OCR incrementa su latencia en cada paso de decodificación, mientras que Unlimited OCR mantiene una duración estable gracias a R-SWA
    • En DeepSeek OCR aparecen picos cuando la longitud del KV cache supera ciertos límites de alineación y cae la eficiencia de transferencia de datos; en R-SWA eso no ocurre
    • En inferencia, la memoria GPU del modelo original crece linealmente, mientras que en Unlimited OCR permanece fija: esa estabilidad simultánea en cómputo y memoria hace posible el parsing de documentos largos

Arquitectura del modelo

  • Toma a DeepSeek OCR como línea base y combina DeepEncoder con un decodificador MoE (3B en total, 500M parámetros activos)
    • Sustituye el MHA existente por R-SWA, sumando al cache KV de referencia m un búfer KV de salida de capacidad fija n para habilitar el parsing de documentos largos
    • El KV cache se implementa como una cola con capacidad m+n; cada vez que se genera un token nuevo, se expulsa el KV del token en la posición (m+1), garantizando que ni el costo ni la memoria aumenten

  • DeepEncoder

    • Encadena SAM-ViT y CLIP-ViT, aplicando compresión de tokens 16x en el puente: la primera parte procesa tokens de imagen originales con window attention, y la atención global queda reservada para los tokens comprimidos
    • Mantiene bajas las activaciones al codificar imágenes de alta resolución para ahorrar memoria GPU, comprimiendo una imagen PDF de 1024×1024 a solo 256 tokens
    • Adopta dos modos: Base (1024×1024) para multipágina y Gundam (resolución dinámica) para una sola página
    • Los tokens visuales se codifican una sola vez y permanecen estáticos durante todo el proceso, sin pasar por transiciones de estado junto con la salida

Configuración de entrenamiento

  • Se entrenó con cerca de 2 millones de ejemplos de datos OCR de documentos, con una proporción de 9:1 entre página única y multipágina
    • Los PDF de una sola página se anotaron con Paddle OCR, uniendo coordenadas y contenido de cada bloque para construir el ground truth; las coordenadas se normalizaron al rango 0–1000
    • Los ejemplos multipágina se sintetizaron concatenando páginas individuales, con unos 200 mil samples (de 2 a 50 páginas) y usando el separador <page>, empaquetados en secuencias completas de 32K tokens
  • A partir del checkpoint de DeepSeek OCR se hizo entrenamiento adicional por 4,000 pasos, con batch global de 256, secuencia máxima de 32K y uso de 8×16 GPU A800
    • Durante el entrenamiento, DeepEncoder se congeló y solo se entrenaron los parámetros del LLM
    • Se usó el optimizador AdamW, scheduler cosine annealing, learning rate inicial de 1e-4, DeepEP (EP=4) y el framework Megatron-LM
    • Para inferencia, se implementó la gestión del KV cache de R-SWA en la librería Transformers, con soporte de optimización en el motor SGLang; ambos frameworks operan con TPS y memoria GPU constantes

Resultados de evaluación

  • El benchmark principal es OmniDocBench (v1.5/v1.6), que evalúa parsing multidimensional de texto, fórmulas, estructura de tablas, orden de lectura y más
    • v1.6 es la versión más reciente, con 296 imágenes de prueba adicionales respecto a v1.5, y v1.5 permite comparar con modelos clásicos, incluido DeepSeek OCR
    • También se construyó un conjunto de prueba propio para OCR de documentos largos, dividiendo novelas, documentos y papers en grupos de 2/5/10/20/40+ páginas (más de 10 libros por categoría)

  • Rendimiento principal

    • Con solo entrenamiento adicional sobre 2M de datos, logra SOTA end-to-end; en v1.5 reduce la distancia de edición de texto en 0.035 y mejora el TEDS de tablas en 5.96%
    • En v1.6 obtiene una métrica global de 93.92%, logrando SOTA end-to-end y demostrando que reemplazar por completo la atención estándar con R-SWA de ancho 128 es eficaz y sin pérdida
    • Con 0.5B de parámetros activos MoE, ofrece inferencia de alta eficiencia, con 5580 TPS en modo Base (12.7% más rápido que los 4951 TPS de DeepSeek OCR)

  • Análisis por subcategorías

    • Frente a DeepSeek OCR muestra mejoras consistentes en todas las métricas, al nivel de una “comida gratis (free lunch)”
    • Frente a DeepSeek OCR 2 supera en 7 de 9 métricas tanto en distancia de edición de texto como en orden de lectura
    • No muestra desventajas incluso en layouts complejos como PPT, periódicos, revistas y notas

  • Parsing de documentos largos

    • Gracias a R-SWA puede hacer prefill en una sola pasada sobre decenas o cientos de páginas, analizando de forma continua desde la primera hasta la última con un KV cache fijo y latencia de salida estable
    • Mantiene resultados robustos incluso con entradas simultáneas de 20 páginas, y en 40+ páginas conserva una distancia de edición menor a 0.11 y Distinct-35 de 97%
    • Los errores de repetición se deben a la dificultad para distinguir texto pequeño en el modo multipágina Base (1024×1024), no a una pérdida de dirección causada por R-SWA

Análisis de eficiencia

  • Comparación de TPS de salida bajo condiciones ideales de concurrencia (con longitud de prefill fija en 10)
    • Con 256 tokens, la velocidad de inferencia de ambos modelos es casi igual
    • A medida que aumenta la longitud de salida, el TPS de DeepSeek OCR cae de forma sostenida, quedando 35% por detrás de Unlimited OCR con 6,000 tokens
    • Se reafirma que una velocidad de generación consistente es un requisito clave para tareas OCR largas

Limitaciones y trabajo futuro

  • Con una longitud de contexto finita (por ejemplo, 32K), no es posible un parsing verdaderamente ilimitado debido a la restricción en la longitud del prefill; incluso con la alta compresión de DeepEncoder, el prefill se alarga al acumular páginas
  • A corto plazo, planean entrenar modelos con contextos más largos, como 128K, para soportar prefill de más páginas
  • A largo plazo, el objetivo es construir un prefill pool y entrenar al modelo para que haga fetch automático de chunks de KV del prefill, imitando el efecto de un humano al pasar páginas para lograr un OCR realmente ilimitado
  • También planean transferir R-SWA a tareas basadas en referencia como ASR y traducción

Lecturas relacionadas

1 comentarios

 
GN⁺ 4 시간 전
Comentarios en Hacker News

  • Bastante interesante. Según entiendo, parece que los investigadores encontraron un hack de arquitectura para evitar que la IA siga acumulando memoria al leer documentos largos
    Normalmente, cuando una IA transcribe un PDF de 100 páginas, intenta recordar todas las palabras que ya leyó, y esa memoria de corto plazo, la KV cache, crece linealmente como O(N), así que la VRAM se agota o se topa con límites. Por eso, los desarrolladores terminan armando código tosco para partir el PDF por páginas, procesarlas y luego volver a unir todo
    Unlimited OCR divide el enfoque en dos rutas con Reference Sliding Window Attention (R-SWA). Una es una referencia global que ve completa la imagen del documento original, y la otra es una generación local que limita el recuerdo del texto generado por el propio modelo a una ventana móvil estrecha, como las 128 palabras más recientes. Parece bastante interesante para la IA local, y tengo curiosidad por ver qué construye y expande la comunidad

    • Parece que también hay un punto de encaje perfecto para las conversaciones. Desde hace bastante tiempo he estado experimentando con la encapsulación de conversaciones largas, donde hay contexto y hechos de nivel superior que no cambian mucho, como los nombres de los participantes o información de fondo
      En cambio, hechos muy finos como qué desayunaste hoy pueden ser útiles ahora, pero a largo plazo no significan mucho más allá de tendencias generales. Para reconstruir una conversación hay que encontrar el equilibrio adecuado sin arrastrar todo lo discutido hasta el momento, así que este enfoque parece valer la pena explorarlo más
    • Todavía no leí el paper completo, pero la ventana de generación local me parece un poco pequeña. Sobre todo porque la entrada de imágenes consume muchos tokens, así que dependiendo de dónde estén las capas de atención local, sería mejor que fuera más grande, de al menos unas 4096 palabras
    • Hago exactamente esto al hacer OCR de imágenes. Si corto una imagen grande en varias más pequeñas y se las envío al LLM, cada vez sale perfecto, pero si meto la imagen completa, el resultado era pésimo
    • Pensé que las principales herramientas de LLM ya soportaban sliding window attention
    • Por esto LeetCode sí sirve. Como he seguido resolviendo problemas de LeetCode, termino viendo por qué existen estas técnicas y cómo se usan en la práctica. Hay muchas cosas interesantes

  • Hace poco compré una tablet para partituras, principalmente para reemplazar los tomos del Real Book de jazz en jam sessions. Lo escaneado con la cámara del teléfono queda más o menos bien, pero el tamaño es fijo y tiene mucho ruido
    Estaría bueno poder transponer al instante para instrumentos en Bb o Eb, pero al ser un escaneo obviamente no se puede. Al investigar el estado del reconocimiento óptico de partituras, llegué a la conclusión de que la música es casi un territorio inexplorado desde la perspectiva de la IA. El reconocimiento óptico de partituras es bastante malo, y la comprensión de teoría musical por parte de la IA también es pésima cuando se trata de leer partituras reales. Los LLM más o menos se defienden con explicaciones en texto de conceptos teóricos que probablemente aparecieron en textos online usados para entrenamiento
    El problema parece ser que todavía faltan formatos digitales que codifiquen bien los puntitos sobre el papel que leen los músicos. La notación musical es bastante rica. MIDI se creó sobre todo para capturar aspectos necesarios para reproducción o interpretación, así que no contiene todo lo necesario para una comprensión simbólica. MusicXML parece lo más cercano a un formato digital que contenga la información que quieren los músicos, pero faltan buenos corpus de entrenamiento que conecten representaciones en MusicXML con imágenes de partituras o audio. Supongo que se debe a que solo con MusicXML no alcanza para la información necesaria en la maquetación de partituras
    Herramientas como MuseScore tienen que rastrear mucha información de diseño que no puede expresarse en MusicXML. El formato LilyPond es menos verboso que MusicXML y contiene un poco más de información útil para quienes preparan partituras, pero la mayoría no crea partituras con LilyPond. Además, por el estado de las tipografías de jazz, LilyPond se queda corto. En contexto de jazz, no me gusta ver partituras con estilo “clásico”. Cada vez que veo mejoras incrementales en OCR que se ven bastante bien, me acuerdo de lo desastroso que es el OMR

    • El formato que usan musicólogos e investigadores musicales es MEI: https://music-encoding.org/ y el grabador de referencia es verovio: https://www.verovio.org/index.xhtml
      verovio puede maquetar en formato SVG preservando al máximo la información de la partitura MEI original, así que se puede extraer suficiente metadato como para crear datasets reales de detección para modelos de deep learning. También hay un script medio improvisado para crear un dataset COCO a partir de un conjunto de partituras maquetadas con verovio: https://github.com/kwon-young/music/blob/main/svg2pl.py
      También publicaron el dataset sintético de partituras hecho aquí: https://www.kaggle.com/datasets/kwonyoungchoi/trompa-coco/da... Cualquiera que quiera entrenar un detector sobre eso es bienvenido. La razón por la que OMR está tan descuidado es que la mayoría subestima muchísimo la dificultad de este trabajo. Es una tarea especializada que mezcla formas extremadamente diversas con una gramática gráfica muy compleja
    • Lo de “la música es casi un territorio inexplorado para la IA” es totalmente cierto. Mi novia estudia musicología, y como por una discapacidad física a veces le cuesta tomar apuntes, la ayudo haciendo de a poco apps basadas en IA, como TTS/OCR
      En ese proceso se vuelve dolorosamente obvio que la música nunca fue considerada una parte importante en ningún dataset de entrenamiento de IA. Hoy en día la capacidad de Opus 4.8 para entender y explicar teoría musical es bastante sorprendente, pero si le pides transcribir partituras o hacer OCR/OMR, con total seguridad te devuelve resultados en MusicXML/LilyPond del tipo “2 + 2 = caballo”. Ojalá esta área ignorada también sea arrastrada por la creciente ola de IA, pero por ahora está injustamente subvalorada
    • Si solo necesitas análisis de acordes, existe la notación Harte, que busca representar notas sin ambigüedad: https://ismir2005.ismir.net/proceedings/1080.pdf
      Claro, no da toda la información adicional necesaria para maquetación o representación musical completa, pero sí hay datasets de investigación como https://github.com/smashub/choco. Para tareas de análisis también usé el dataset https://github.com/MarkGotham/When-in-Rome, aunque tampoco coincide al 100% con lo que buscas. Para reemplazar estándares de jazz y transponer en una tablet, puede que te guste la app “iReal Pro”. Para ese caso de uso funciona bastante mejor que un escaneo con cámara
    • ¿Qué tal un formato de maquetación musical como https://abcnotation.com/?
    • Siguiendo el área de OCR musical, hasta ahora me parece que la única solución realmente decente ha sido soundslice. Escaneas y luego solo revisas algunos edge cases, y el resultado es muy bueno. Es un servicio pago de una empresa pequeña, pero vale totalmente la pena apoyarlo

  • Es una actitud con clase escribir “agradecemos a Deepseek-OCR, Deepseek-OCR-2 y los modelos e ideas valiosos de PaddleOCR”

    • No entiendo por qué lo dicen con sarcasmo

  • Por cierto, “Unlimited OCR Works” es una parodia de Unlimited Blade Works de Fate/stay night. En el original, Unlimited Blade Works es una magia que permite copiar armas creadas por otros

  • El paper está en https://arxiv.org/abs/2606.23050
    Como referencia, yo hago OCR local para un pequeño RAG de citas que leo en libros, y también divido la entrada en chunks para ahorrar RAM, así que me parece interesante que este enfoque tan natural también funcione en modelos de streaming

  • Se ve más prometedor que lo que acaba de lanzar Mistral. ¿Coincidencia? No lo creo
    Parece que este enfoque también podría combinarse de alguna forma para generación de imágenes. Podría funcionar leyendo o mirando una imagen y luego empezar a dibujarla en herramientas como Illustrator/Inkscape o en SVG, para completar después las partes faltantes

  • Me intriga cómo se compara con infinty parser 2, que parecía aplastar a otras herramientas OCR: https://huggingface.co/datasets/allenai/olmOCR-bench
    Siendo justos, no existe un benchmark de OCR con un único ganador, y esta herramienta todavía no aparece en ninguno

  • Puede que suene como alguien que no entiende cómo funciona el mundo, pero ¿cuál es la razón real por la que las empresas publican software realmente bueno como open source?
    Si fueran Baidu o Google, ¿no deberían guardárselo para ellos mismos y extraerle valor sin dejar que la competencia los copie?

    • Incluso dentro de las grandes empresas hay personas que creen en el ideal del open source y convencen a su empleador de permitir que el proyecto se publique
      La empresa gana prestigio, y eso ayuda al embudo de contratación. A veces también puede servir para sacudir estratégicamente a la competencia, como cuando Meta publicó Ollama
    • Publicar modelos open source puede quitarles ingresos a los laboratorios de IA de EE. UU. Si eso reduce el dinero que pueden reinvertir para ganar en la competencia de largo plazo, podría beneficiar a China

  • Los intentos que he hecho de OCR con IA siempre terminaron mezclando resultados inventados, y por eso ha sido difícil usarlo en producción. Me pregunto si este también tiene ese problema
    Un ejemplo simple es cuando palabras que deberían permanecer en otro idioma se traducen automáticamente al inglés y arruinan el resultado

    • Uno termina sin querer nada que opere a un nivel mayor que la palabra, es decir, a nivel de pares de palabras, frases, oraciones, documentos o corpus
      En una transcripción, uno quiere un resultado casi seguro, o una marca clara de que no se pudo leer con certeza. Se puede inferir por contexto, pero en algunos OCR uno necesita saber si la suposición se hizo con alguna base distinta del hecho de que las letras, en ese orden, forman una palabra
      Por ejemplo, en un documento de censo de familysearch.com, el transcriptor “corrigió” un nombre a Joseph, pero las letras reales en el manuscrito eran Josepth, y de hecho esa era una variante ortográfica local. En otro documento, el autor escribió “Joh” como abreviatura, y probablemente un transcriptor humano lo pasó como John; era lo más probable, pero aun así era incorrecto. A veces importa que quede claro que fue una suposición, y otras veces solo hace falta la mejor suposición posible
    • Si quisiera un resultado de reconocimiento del 100%, combinaría este método con un modelo de imagen de reconstrucción del documento original. La idea sería hacer que reconstruya el documento original alineando el texto transcrito y el layout
      Si se usa el resto del documento excepto la página o el párrafo que se quiere probar, se puede evitar que la frase bajo prueba se regenere tal cual a partir de artefactos de la imagen. Después de la reconstrucción, bastaría con hacer una comparación óptica para detectar y alinear los caracteres desfasados, encontrar errores e iterar. Sería caro, pero podría garantizar un reconocimiento del 100%
    • Estoy probando transcribir con este modelo un PDF de gramática japonesa en una 4090. Es un documento escrito en inglés con muchos ejemplos en japonés, y en la parte que comparé manualmente parece funcionar bastante bien
      La salida conserva bien el kanji/hiragana y el inglés donde corresponde, y no intenta traducirlos. Convirtió unas 200 páginas por hora
    • Me da curiosidad saber qué modelos o herramientas han estado usando

  • No sé qué pasó con Reducto. Hace 12 a 15 meses parecía bastante prometedor