Unlimited OCR — o modelo de parsing de documentos longos em um único passo da Baidu
(github.com/baidu)- Modelo de OCR E2E baseado no DeepSeek OCR que substitui toda a atenção do decodificador para transcrever documentos de dezenas de páginas em uma única passagem direta (forward pass)
- O ponto central é a Reference Sliding Window Attention (R-SWA), que mantém o cache KV constante mesmo quando o comprimento da decodificação cresce, bloqueando o aumento de custo de memória e computação
- Adota uma abordagem que imita a memória de trabalho (working memory) humana ao copiar livros, esquecendo suavemente saídas distantes e consultando apenas o contexto adjacente
- No OmniDocBench v1.5, atingiu 93%, 6% à frente do DeepSeek OCR, e no v1.6 alcançou 93,92%, obtendo SOTA end-to-end
- A R-SWA é um mecanismo de atenção de parsing genérico aplicável não só a OCR, mas também a tarefas longas baseadas em referência como ASR e tradução
Contexto e definição do problema
- Humanos conseguem realizar tarefas longas, como transcrever centenas de páginas ou traduzir horas de áudio, sem perda de eficiência, mas modelos de OCR existentes não conseguem fazer parsing nem de 10 páginas em uma única passagem direta
- Os modelos atuais processam por página em esquema de for-loop, reinicializando a memória a cada etapa
- Esse método é apenas uma gambiarra de engenharia que fragmenta um processo longo e coerente em tarefas curtas isoladas, não um avanço rumo a uma inteligência orientada a AGI
- Usar um LLM como decodificador melhora o desempenho ao aproveitar a distribuição prévia da linguagem, mas, conforme a saída cresce, o cache KV acumulado aumenta o consumo de memória e reduz gradualmente a velocidade de geração
- O comportamento humano de transcrição não corresponde nem à full attention padrão nem à linear attention
- Em vez de reler todo o texto já escrito, a pessoa consulta apenas o contexto adjacente para manter a direção
- Tokens visuais/de referência não recebem atualização recorrente de estado — se fossem atualizados, as características visuais se degradariam gradualmente e a precisão de reconhecimento cairia
Reference Sliding Window Attention (R-SWA)
- Cada token acessa todos os tokens de referência (tokens visuais + prompt), enquanto a atenção de saída fica limitada apenas aos n tokens anteriores imediatos (valor padrão 128)
- Com isso, cada token percebe a imagem inteira enquanto acompanha autonomamente o progresso do OCR por meio da transição de estado dentro de uma janela deslizante causal
- Durante a inferência, o cache KV permanece constante, reduzindo a pressão de memória e o custo computacional
- A atenção é limitada a uma janela de dois segmentos de tamanho m+n
- m é a janela de prefixo, que inclui tokens visuais e prompt, permanece fixa durante uma inferência e depende apenas do número de páginas e da resolução, sem relação com o comprimento da decodificação
- n é a janela da área de decodificação, que desliza causalmente com tamanho fixo
-
Gerenciamento do cache KV
- A baseline DeepSeek OCR usa MHA padrão, então o tamanho do cache KV cresce indefinidamente como Lm + T
- A R-SWA mantém todo o cache de prefixo Lm, mas guarda da geração apenas os n tokens mais recentes, deixando o tamanho do cache em Lm + min(n,T) ≤ Lm + n, com limite superior constante
- Quando o comprimento de saída fica suficientemente grande, a razão de cache ρ(T) converge para 0 → o crescimento linear é reduzido a uma constante
-
Análise de kernel
- Nas medições do kernel Flash Attention v3, o MHA padrão do DeepSeek OCR apresenta aumento de latência a cada etapa de decodificação, enquanto o Unlimited OCR, graças à R-SWA, mantém duração constante
- No DeepSeek OCR, surgem picos quando o comprimento do cache KV ultrapassa certos limites de alinhamento e a eficiência de transferência de dados despenca; isso não ocorre com a R-SWA
- Na inferência, a memória de GPU do modelo original cresce linearmente, enquanto no Unlimited OCR permanece fixa — a estabilidade simultânea de computação e memória é o que viabiliza o parsing de textos longos
Arquitetura do modelo
- Usa o DeepSeek OCR como baseline, combinando DeepEncoder e decodificador MoE (3B no total, 500M de parâmetros ativos)
- O MHA existente foi substituído por R-SWA, somando ao cache KV de referência fixo m um buffer KV de saída de capacidade fixa n para viabilizar parsing longo
- O cache KV é implementado como uma fila com capacidade m+n; a cada novo token gerado, o KV do token na posição (m+1) é removido, garantindo que custo e memória não cresçam
-
DeepEncoder
- Faz um encadeamento de SAM-ViT e CLIP-ViT, com compressão de tokens em 16x na ponte — a parte inicial processa os tokens originais da imagem com window attention, e a atenção global fica restrita aos tokens comprimidos
- Ao codificar imagens em alta resolução, mantém ativações baixas para economizar memória de GPU, comprimindo uma imagem PDF de 1024×1024 em apenas 256 tokens
- Adota dois modos: Base para múltiplas páginas (1024×1024) e Gundam para página única (resolução dinâmica)
- Os tokens visuais são codificados uma vez e permanecem estáticos durante todo o processo, sem passar por transição de estado junto com a saída
Configuração de treinamento
- Treinado com cerca de 2 milhões de exemplos de OCR de documentos, com proporção de 9:1 entre página única e múltiplas páginas
- PDFs de página única foram anotados com Paddle OCR, ligando coordenadas e conteúdo de cada bloco para formar o ground truth; as coordenadas foram normalizadas para a faixa 0–1000
- O conjunto multipágina foi sintetizado pela concatenação de páginas únicas, com cerca de 200 mil amostras (2 a 50 páginas) usando o separador
<page>, empacotadas em sequências totais de 32K tokens
- A partir do checkpoint do DeepSeek OCR, foram feitos mais 4.000 passos de treinamento, com batch global 256, sequência máxima de 32K e uso de 8×16 GPUs A800
- Durante o treinamento, o DeepEncoder foi congelado e apenas os parâmetros do LLM foram treinados
- Baseado no framework Megatron-LM com otimizador AdamW, scheduler cosine annealing, taxa de aprendizado inicial 1e-4 e DeepEP (EP=4)
- Na inferência, a biblioteca Transformers implementa o gerenciamento de cache KV para R-SWA, e o motor SGLang oferece suporte otimizado — em ambos os frameworks, o sistema opera com TPS e memória de GPU constantes
Resultados de avaliação
- O benchmark principal é o OmniDocBench (v1.5/v1.6), que avalia capacidade de parsing multidimensional em texto, fórmulas, estrutura de tabelas, ordem de leitura etc.
- O v1.6 é a versão mais recente, com 296 imagens de teste a mais que o v1.5; o v1.5 oferece comparação com modelos clássicos, incluindo o DeepSeek OCR
- Também foi construído um conjunto de teste próprio para avaliar OCR de textos longos, separando romances, documentos e artigos em 2/5/10/20/40+ páginas (mais de 10 livros por categoria)
-
Desempenho principal
- Com apenas 2M de dados adicionais de treinamento, alcançou SOTA end-to-end, reduzindo a distância de edição de texto em 0,035 no v1.5 e melhorando o TEDS de tabelas em 5,96%
- No v1.6, obteve métrica geral de 93,92%, atingindo SOTA end-to-end — prova que substituir totalmente a atenção padrão por R-SWA com largura 128 é eficaz e sem perdas
- Inferência altamente eficiente com 0,5B de parâmetros ativos no MoE, atingindo 5580 TPS no modo Base (12,7% mais rápido que os 4951 TPS do DeepSeek OCR)
-
Análise por subcategoria
- Mostra melhorias consistentes em todas as métricas frente ao DeepSeek OCR, em nível de “almoço grátis (free lunch)”
- Em relação ao DeepSeek OCR 2, supera em 7 de 9 métricas tanto em distância de edição de texto quanto em ordem de leitura
- Não fica atrás nem em layouts complexos como PPT, jornais, revistas e anotações
-
Parsing de textos longos
- Com R-SWA, faz prefill de dezenas a centenas de páginas em passagem única, realizando parsing contínuo da primeira à última página e mantendo latência de saída constante com cache KV fixo
- Mostra resultados robustos mesmo com entrada simultânea de 20 páginas, mantendo distância de edição abaixo de 0,11 e Distinct-35 de 97% em 40+ páginas
- Erros de repetição decorrem da dificuldade de identificar letras pequenas no modo multipágina Base (1024×1024), não de perda de direção da R-SWA
Análise de eficiência
- Comparação de TPS de saída sob condição ideal de paralelismo (comprimento de prefill fixado em 10)
- Em 256 tokens, a velocidade de inferência dos dois modelos é quase igual
- À medida que o comprimento de saída aumenta, o TPS do DeepSeek OCR cai continuamente, ficando 35% atrás do Unlimited OCR em 6.000 tokens
- Reforça que velocidade de geração consistente é requisito essencial em tarefas longas de OCR
Limitações e trabalhos futuros
- Com comprimento de contexto finito (por exemplo, 32K), não é possível um parsing realmente ilimitado por causa da restrição de comprimento do prefill — mesmo com a alta taxa de compressão do DeepEncoder, o prefill cresce com o acúmulo de páginas
- No curto prazo, está previsto o treinamento de modelos com contexto mais longo, como 128K, para suportar prefill de mais páginas
- No longo prazo, o objetivo é construir um prefill pool e treinar o modelo para buscar automaticamente chunks de KV de prefill, imitando o efeito de um humano virando páginas, para atingir OCR realmente ilimitado
- Também há planos de levar a R-SWA para tarefas baseadas em referência como ASR e tradução
- O modelo está disponível no Hugging Face e no ModelScope, e o artigo foi publicado no arXiv
1 comentários
Comentários do Hacker News
Bem interessante. Pelo que entendi, os pesquisadores parecem ter encontrado um hack de arquitetura para impedir que a IA continue acumulando memória ao ler documentos longos
Normalmente, quando uma IA transcreve um PDF de 100 páginas, ela tenta se lembrar de todas as palavras já lidas, e esse cache KV, que é essa memória de curto prazo, cresce linearmente em O(N), esgotando a VRAM ou batendo no limite. Aí os desenvolvedores acabam criando um código meio gambiarra para dividir o PDF por páginas, processar tudo e depois juntar de novo
O Unlimited OCR divide o foco em dois caminhos com o Reference Sliding Window Attention (R-SWA). Um é uma referência global que vê a imagem original do documento por inteiro, e o outro é uma geração local que limita a memória de texto gerada pelo próprio modelo a uma janela deslizante estreita, como as 128 palavras mais recentes. Parece algo bem interessante para IA local, e estou curioso para ver o que a comunidade vai criar e expandir em cima disso
Por outro lado, fatos bem minuciosos, como o que alguém comeu hoje de manhã, podem ser úteis agora, mas no longo prazo não significam muita coisa além de tendências gerais. Para reconstruir uma conversa, é preciso encontrar o equilíbrio certo sem puxar tudo o que já foi discutido até aqui, então esse método parece valer uma análise mais profunda
Comprei recentemente um tablet para partituras, principalmente para substituir coletâneas do Jazz Real Book em jam sessions. O que é escaneado com a câmera do celular fica até aceitável, mas o tamanho é fixo e há muito ruído visual
Seria ótimo poder transpor na hora para instrumentos em Bb ou Eb, mas como é um escaneamento isso obviamente é impossível. Fui investigar o estado do reconhecimento óptico de partituras e cheguei à conclusão de que a música é quase um território inexplorado sob a ótica de IA. O reconhecimento óptico de partituras é bem ruim, e a compreensão de teoria musical pela IA também é péssima quando se trata de ler partituras reais. LLMs até lidam razoavelmente bem com descrições textuais de conceitos teóricos que provavelmente apareceram no texto online usado no treinamento
O problema parece ser que ainda falta um formato digital que codifique de forma adequada os pontinhos no papel que os músicos leem. A notação musical é bem rica. O MIDI foi criado principalmente para capturar aspectos necessários à reprodução ou execução, então não consegue conter tudo o que é necessário para uma compreensão simbólica. O MusicXML parece ser o formato digital mais próximo de conter a informação que os músicos querem, mas faltam bons corpora de treino que conectem representações em MusicXML a imagens de partituras ou áudio. Talvez porque o MusicXML sozinho não tenha informação suficiente para tudo o que é necessário na diagramação da partitura
Ferramentas como o MuseScore precisam rastrear muita informação de layout que não pode ser representada em MusicXML. O formato LilyPond é menos verboso que o MusicXML e contém um pouco mais de informação útil para quem produz partituras, mas a maioria das pessoas não cria partituras em LilyPond. Além disso, o estado das fontes de jazz no LilyPond deixa a desejar. Não gosto de ver partituras “com cara de clássico” em contexto de jazz. Sempre que vejo melhorias incrementais no OCR que parecem bem boas, lembro da situação desastrosa do OMR
O verovio consegue diagramar em SVG preservando o máximo possível da informação da partitura original em MEI, então dá para extrair metadados suficientes para criar datasets reais de detecção para modelos de deep learning. Também existe um script meio improvisado para gerar um dataset COCO a partir de um conjunto de partituras diagramadas com verovio: https://github.com/kwon-young/music/blob/main/svg2pl.py
Também publiquei o dataset sintético de partituras feito aqui: https://www.kaggle.com/datasets/kwonyoungchoi/trompa-coco/da... Quem quiser treinar um detector em cima disso é bem-vindo. O motivo de o OMR ser tão negligenciado é que a maioria subestima muito a dificuldade desse trabalho. É uma tarefa muito específica, com formas extremamente variadas e uma gramática gráfica muito complexa misturada
Fazendo isso, fica dolorosamente claro que a música nunca foi considerada uma parte importante em nenhum dataset de treinamento de IA. Hoje em dia a capacidade do Opus 4.8 de entender e explicar teoria musical é até impressionante, mas, se você pedir para transcrever uma partitura ou fazer OCR/OMR, ele entrega com toda confiança algo equivalente a “2 + 2 = cavalo” em MusicXML/LilyPond. Espero que essa área ignorada também seja arrastada pela maré crescente da IA, mas por enquanto ela continua injustamente subestimada
Claro que ela não fornece toda a informação extra necessária para diagramação ou para representar a música completa, mas existem datasets de pesquisa como https://github.com/smashub/choco. Para tarefas de análise, também usei o dataset https://github.com/MarkGotham/When-in-Rome, mas ele também não corresponde 100% ao que estou procurando. Para o caso de substituir standards de jazz no tablet e fazer transposição, talvez você goste do app “iReal Pro”. Para esse uso, ele é bem melhor que escanear com a câmera
Escrever “agradecemos aos modelos e ideias valiosos de Deepseek-OCR, Deepseek-OCR-2 e PaddleOCR” é uma postura elegante
Só para constar, “Unlimited OCR Works” é uma paródia de Unlimited Blade Works, de Fate/stay night. A ideia original de Unlimited Blade Works é uma magia que copia armas feitas por outras pessoas
O artigo está em https://arxiv.org/abs/2606.23050
Aliás, eu faço OCR local para um pequeno uso de RAG com citações que li em livros, e eu também quebro a entrada em chunks para economizar RAM, então acho interessante que essa abordagem natural também funcione em modelos com streaming
Parece mais promissor do que o que a Mistral acabou de lançar. Coincidência? Acho que não
Essa abordagem talvez também possa ser combinada com geração de imagem de alguma forma. Parece plausível ler ou observar uma imagem e depois começar a desenhá-la em ferramentas como Illustrator/Inkscape ou em SVG, preenchendo as partes que faltam depois
Fico curioso sobre como isso se compara ao infinty parser 2, que parecia superar bastante as outras ferramentas de OCR: https://huggingface.co/datasets/allenai/olmOCR-bench
Para ser justo, não existe um benchmark de OCR com um único vencedor, e esta ferramenta ainda não apareceu em nenhum deles
Posso soar como alguém totalmente por fora, mas qual é o motivo real de empresas divulgarem software realmente bom como código aberto?
Se fosse a Baidu ou o Google, não deveriam manter isso só para si para extrair valor sem deixar concorrentes copiarem?
A empresa ganha reputação, e isso ajuda no funil de contratação. Às vezes também pode ser uma jogada estratégica para desestabilizar concorrentes, como quando a Meta divulgou o Ollama
Minhas tentativas de fazer OCR com IA sempre acabavam misturando resultados inventados, então era difícil usar isso em produção. Fico curioso se aqui acontece o mesmo problema
Um exemplo simples é quando palavras que deveriam permanecer em outro idioma são automaticamente traduzidas para o inglês, arruinando o resultado
Em transcrição, você quer um resultado praticamente certo, ou então uma indicação clara de que aquilo não pôde ser lido com certeza. Dá para inferir pelo contexto, mas em certos OCRs é importante saber se houve inferência com base em algo além do fato de que as letras, em ordem, formam uma palavra
Por exemplo, em documentos censitários do familysearch.com, um transcritor “corrigiu” um nome para Joseph, mas as letras reais no manuscrito eram Josepth, que de fato era uma grafia variante local. Em outro documento, o autor escreveu “Joh” como abreviação, e provavelmente um transcritor humano registrou como John; embora fosse a hipótese mais plausível, ainda estava errado. Às vezes é importante saber que aquilo é apenas um palpite; em outros casos, basta ter o melhor palpite possível
Usando o restante do documento e excluindo só a página ou o parágrafo que você quer testar, dá para evitar que a frase em avaliação seja simplesmente regenerada a partir de artefatos da imagem. Depois da reconstrução, bastaria fazer uma comparação óptica para localizar caracteres desalinhados, encontrar erros e iterar. Seria caro, mas poderia garantir 100% de reconhecimento
A saída preserva adequadamente kanji/hiragana e inglês onde necessário, sem tentar traduzir. Converteu cerca de 200 páginas por hora
Não sei no que deu a Reducto. Há 12 a 15 meses ela parecia bastante promissora