- Parte da percepção de que “se o texto for representado como imagem, é possível conter a mesma informação com muito menos tokens”
- É um modelo que propõe uma nova abordagem para comprimir informação textual em representação visual 2D, validando experimentalmente o conceito de compressão baseada em visão (Optical Compression) para lidar com contextos longos de forma eficiente
- O modelo é composto por DeepEncoder (encoder) e DeepSeek3B-MoE-A570M (decoder), alcançando baixa memória ativa mesmo com entradas de alta resolução e taxa de compressão de tokens na faixa de 10 a 20 vezes
- Mantém 97% de precisão de OCR com compressão de 10x e mais de 60% de acurácia com compressão de 20x, sugerindo possibilidade prática para pesquisas sobre compressão de contexto longo e mecanismos de esquecimento de memória
- No OmniDocBench, superou o GOT-OCR2.0 (256 tokens/página) com apenas 100 tokens visuais e registrou desempenho superior ao MinerU2.0 (média de 6000+ tokens/página) com menos de 800 tokens
- Com uma única GPU A100-40G, é possível gerar mais de 200 mil páginas por dia, o que lhe dá alto valor prático como motor de dados para treinamento em larga escala de LLM/VLM
1. Contexto da pesquisa
- LLMs existentes têm a limitação estrutural de que o custo computacional cresce quadraticamente conforme o comprimento da sequência
- O artigo parte da percepção de que “se o texto for representado como imagem, é possível conter a mesma informação com muito menos tokens”
- Isso é definido como compressão de contexto longo baseada em tokens visuais (Context Optical Compression), tendo OCR como campo experimental
- Como resultado, mostra um novo caminho em que representações visuais podem melhorar a eficiência de processamento de contexto dos LLMs
2. Estrutura do modelo
- DeepSeek-OCR = DeepEncoder + decoder DeepSeek3B-MoE
- DeepEncoder: SAM (Window Attention) + CLIP (Global Attention) + compressor de tokens de 16x
- DeepSeek3B-MoE: ativa 6 entre 64 especialistas, totalizando 570M de parâmetros ativos
- Suporte a modo multirresolução (Tiny~Gundam)
- Suporta entradas com resolução de 512 a 1280, processando composição de até 9 tiles
- O modo Gundam atende documentos em ultra-alta resolução (jornais etc.), usando até 800 tokens visuais
3. Motor de dados
- Combinação de 3 tipos de dados no total:
- Dados OCR 1.0: 30M de páginas baseadas em documentos em 100 idiomas, com anotações detalhadas de layout e texto
- Dados OCR 2.0: 16M de dados para reconhecimento composto, como gráficos, fórmulas químicas (SMILES) e formas geométricas
- Dados gerais de visão: para manter entendimento visual baseado em CLIP, 20% do total
- Dados apenas de texto: 10% para complementar a capacidade linguística
- Proporção total da composição dos dados de treinamento
- OCR 70% / visão 20% / texto 10%
4. Pipeline de treinamento
- Treinamento em duas etapas: DeepEncoder → DeepSeek-OCR
- Em um total de 20 nós (8× GPU A100), com paralelismo de dados DP=40 e batch global de 640
- Velocidade de treinamento: 90B tokens/dia em dados de texto, 70B tokens/dia em dados multimodais
5. Resultados de avaliação
(1) Experimento de compressão (benchmark Fox)
- 97% de acurácia com compressão de 10x, mantendo mais de 60% mesmo com 20x
- Quanto mais longo ou complexo o documento, maior a queda de desempenho, mas isso é interpretado como possibilidade de simular um “mecanismo de esquecimento”
- Com taxa de compressão de 10x ou menos, é possível restaurar o contexto quase sem perdas
(2) Reconhecimento de documentos reais (OmniDocBench)
- Comparação entre modos Tiny (64 tokens) e Gundam (800 tokens)
- Superior ao GOT-OCR2.0 (256 tokens) no modo Small (100 tokens)
- Supera o MinerU2.0 (7.000 tokens) com Gundam (800 tokens)
- O número de tokens exigido varia conforme o tipo de documento
- Slides, relatórios: 64 a 100 tokens são suficientes
- Jornais, artigos acadêmicos: 400 a 800 tokens são necessários
6. Análise qualitativa (Qualitative Study)
- Modo Deep Parsing
- Permite extração estruturada com um único prompt de gráficos, diagramas, fórmulas químicas e até imagens naturais
- Reconhecimento multilíngue
- Suporte a PDFs em cerca de 100 idiomas, incluindo línguas menos comuns como árabe e cingalês
- Entendimento visual geral
- Também executa descrição de imagens, detecção de objetos e grounding
- Em integração com LLM, pode ser usado como modelo base para raciocínio multimodal visão-linguagem
7. Discussão e implicações
- O DeepSeek-OCR é o primeiro experimento a explorar os limites da compressão de textos longos baseada em tokens visuais,
quantificando o conceito de que “uma imagem vale por mil palavras”
- Mesmo com compressão de 10x, a restauração pode ser feita quase sem perdas → possibilidade de expansão para compressão do histórico de conversas, otimização de memória de longo prazo etc.
- Propõe a simulação de atenuação de tokens semelhante à curva biológica de esquecimento por meio de um método de reduzir a resolução da imagem ao longo do tempo
8. Conclusão
- O DeepSeek-OCR é um modelo demonstrativo de mapeamento com compressão de 10 a 20x entre texto e visão,
propondo um novo paradigma para superar as limitações dos LLMs no processamento de contextos longos
- Além de OCR, a expectativa é de expansão futura para pré-treinamento híbrido digital-óptico e para modelos de contexto ultralongo baseados em ‘Optical Context Memory’
- O código está disponível publicamente e pode ser usado tanto em pesquisa quanto como motor de dados comercial
- O DeepSeek-OCR se destaca, em comparação com OCRs open source existentes, por sua estrutura baseada em LLM capaz de codificar informações visuais de forma eficaz
- Com suporte a várias resoluções (512×512~1280×1280) e modo Gundam para resolução dinâmica, adapta-se bem a diferentes ambientes
- Com design claro de prompts, suporta diversos modos de tarefa, como descrição geral de imagens, conversão para Markdown, OCR ignorando layout e parsing de gráficos
- O desempenho foi verificado em integração com benchmarks do setor como Fox e OminiDocBench, com validação baseada em experimentos de processamento real de documentos
- Foi implementado incorporando vantagens e ideias de outros projetos populares como GOT-OCR2.0 e PaddleOCR
- Resoluções suportadas
- Tiny: 512×512 (64 vision tokens)
- Small: 640×640 (100 vision tokens)
- Base: 1024×1024 (256 vision tokens)
- Large: 1280×1280 (400 vision tokens)
- Dynamic mode(=Gundam): resolução livre (n×640×640 + 1×1024×1024)
- Inferência paralela para PDF e imagens, com alta velocidade de processamento
- Com GPU A100, processamento de PDF de até ~2.500 tokens/segundo
- Contexto técnico e integração com o ecossistema
- Implementado 100% em Python
- Suporta os dois principais ambientes de inferência: vLLM e Transformers
- Utiliza benchmarks e frameworks de avaliação importantes como OpenChart, Fox e OminiDocBench
- Integra modelos anteriores como GOT-OCR2.0, PaddleOCR e Vary, aproveitando ideias e reforçando desempenho
1 comentários
Comentários no Hacker News
Este artigo não é apenas mais um VLM para OCR, mas avança para temas mais interessantes, como compressão
Por exemplo, há a citação: "Conduzimos estudos iniciais explorando os limites da compressão visão-texto, investigando quantos tokens visuais são necessários para decodificar tokens de texto. Resultados preliminares mostram que o DeepSeek-OCR alcança compressão de OCR quase sem perdas em uma razão de cerca de 10x, e mantém 60% de precisão mesmo com compressão de 20x"
Intuitivamente, isso significaria que um token visual carrega tanta informação quanto 10 tokens de texto
Gostaria que alguém explicasse, de forma acessível para iniciantes, por que esse resultado aparece do ponto de vista da teoria da informação
Será que isso acontece porque os tokens de texto ainda são subdivididos demais (ou redundantes) e não chegam perto de uma codificação por entropia, ou porque ao passar para tokens visuais se ultrapassa o limite da "unidade palavra" e se consegue chegar mais perto da entropia (como na diferença entre codificação aritmética e código de Huffman)?
E o artigo também discute a relação entre perda de informação nos domínios de texto e imagem ao realmente reduzir a escala das imagens para lidar com contextos longos
Tokens de texto são subunidades quantizadas (subwords), enquanto tokens visuais existem apenas no espaço de embeddings
Em LLMs, a tokenização de texto é estruturada como uma tabela de consulta entre IDs de token (pequenos) e embeddings vetoriais (grandes)
Ao enviar texto para um LLM, a string é dividida nos limites dos tokens, convertida em IDs de token, e então os vetores são buscados na tabela para formar a matriz de contexto
Transmitir a sequência real de tokens de texto é eficiente, porque basta enviar um array de números (IDs), normalmente algo como ~100 mil IDs de token únicos
Já transmitir a própria matriz de embeddings seria ineficiente, porque embeddings são compostos por milhares de números de ponto flutuante
Imagens são codificadas de forma diferente. Os dados da imagem são pré-processados e enviados diretamente para um codificador de imagem baseado em rede neural, que os transforma em vetores e adiciona esses vetores ao contexto
Ou seja, tokens de imagem não têm IDs de token nem tabela de consulta; vão direto dos dados para embeddings
Como resultado, para transmitir tokens de imagem é preciso enviar os próprios embeddings, o que é ineficiente
Mesmo que a imagem seja codificada com menos tokens, cada token é muito maior em capacidade
Em resumo, tokens de texto têm um mapeamento bem definido de inteiros (0~n) para vetores, então existem ‘n’ escolhas possíveis
Já tokens de imagem são arrays de
floatcom m dimensões (vetores), então ocupam um espaço de tokens muito maiorTambém em termos de padrão, tokens de texto correspondem diretamente a bytes UTF-8 contínuos e normalmente não passam dos limites de palavras, então padrões globais (por exemplo, “esta fala é de Hamlet”, “esta parte está em espanhol”) não podem ser expressos em um único token
Não sei exatamente como a entrada de imagem é embutida em um LLM multimodal, mas entendo que, no básico, a imagem é dividida em uma grade e cada região é codificada
No experimento da DeepSeek, mais do que propriedades de teoria da informação, o ponto central parece ser até que ponto dá para reduzir a resolução ou o tamanho da grade (patches) e ainda manter detalhes suficientes para fazer OCR com precisão
Seria ótimo se o Karpathy expandisse o NanoChat para multimodal e compartilhasse o know-how desse processo de codificação
A taxa de compressão adequada inevitavelmente depende do tamanho relativo entre a resolução de cada caractere e o tamanho do patch de cada token visual
Só assim o número de tokens de texto extraídos por OCR pode, no fim, permanecer independente da resolução da imagem
Cada token de texto costuma ser uma subword, mas os tokens visuais de um VLM vivem em um espaço semântico
Um espaço semântico consegue comprimir informação muito mais fortemente do que uma simples segmentação em subwords
Observação: não sou especialista, só estou pensando em voz alta
LLMs têm custo computacional que cresce quadraticamente com o número de tokens
Por isso, em VLMs, tenta-se comprimir tokens de texto em tokens visuais
Ao que parece, a ideia é primeiro renderizar o texto como imagem e depois tokenizar isso para reduzir custo de computação
O PyTorch foi um pouco chato de fazer rodar no NVIDIA Spark (ARM64), mas consegui fazer funcionar executando o Claude Code como root em um novo contêiner Docker
As notas detalhadas estão aqui
O resultado real pode ser visto neste link, testado sobre a imagem original do OCR (aqui)
O resultado do OCR é, no geral, muito sólido
Mas houve uma alucinação ao acrescentar conteúdo desnecessário no parágrafo logo abaixo da citação, conectando-o à coluna seguinte
Obrigado por tocar esse teste rapidamente
Dá para entender ter perdido o "A" no começo do texto (talvez o dataset não tivesse muitos artigos de notícias)
Mas achei mais interessante ele também ter deixado passar completamente todo o trecho "Hallucination is a risk and...", o tópico (“theme”) ao lado do autor e a parte final do e-mail
Só esse experimento já parece valer um post separado
"Executar o Claude Code como root em um novo contêiner Docker"
Tenho curiosidade sobre como configurar isso especificamente para rodar com privilégios de root
(Se estiver explicado, vou conferir no texto)
O artigo não menciona a Anna’s Archive
Acho possível que a DeepSeek tenha realmente aproveitado a oferta da Anna para dar a pesquisadores de OCR acesso a uma coleção de 7,5 milhões de livros (350 TB) de não ficção em chinês
Isso é um volume ainda maior que o da Library Genesis
Post de referência
Em um artigo anterior da DeepSeek, eles mencionam diretamente a Anna’s Archive
"Curamos 860 mil e-books em inglês, 180 mil em chinês e milhões de questões de prova K-12 da Anna’s Archive"
Veja o artigo do DeepSeek-VL
Fico em dúvida se realmente precisariam pedir acesso só porque ela estaria armazenando livros de terceiros
Eu também pensei imediatamente na Anna’s Archive e fiquei curioso sobre quando um dataset processado por OCR será publicado
Isso também significa que talvez o dataset nunca seja publicado
Numa situação dessas, preocupa pensar se a Anna’s Archive vai acabar sumindo por ser explorada demais por empresas de LLM
Como se não bastasse a META já ter sugado 70 TB da Library Genesis via torrent
Compartilhando experiência sobre o nível real dos benchmarks atuais e alternativos
O benchmark OmniAI não é muito bom
Em vez disso, recomendo o OmniDocBench
O Mistral OCR fica claramente atrás de modelos OCR open source e também do Gemini
OCR ponta a ponta ainda é muito difícil
A abordagem em pipeline (detecção de layout → definição da ordem de leitura → OCR de cada elemento) funciona melhor
Parsing de tabelas complexas ainda é um grande desafio
Também tenho curiosidade sobre comparações de benchmark com o Apple Vision Framework
Ele vem embutido em praticamente todos os dispositivos da Apple e, na prática, entrega OCR rápido e de alta qualidade (especialmente para conversão de PDF), mas parece pouco comentado
Tenho muita curiosidade de saber onde ele se posiciona nesses benchmarks
Segundo o benchmark da OmniAI, o Omni OCR apresenta o melhor desempenho
Imagino que muita gente nem vá questionar esse tipo de resultado
Gostaria de entender melhor quais são as vantagens e diferenças do OCR baseado em LLM em comparação com serviços como Azure AI Document Intelligence (link) e Google Vision API (link)
A OmniAI compara seu próprio LLM e OCR em nuvem em benchmarks entre si
Benchmark do blog da OmniAI (em fevereiro de 2025)
Desde então, os LLMs evoluíram rapidamente
Os resultados da linha Qwen3-VL, especialmente o Qwen3-VL-235B-A22B-Instruct, têm sido os melhores ultimamente
Meu palpite é que modelos comerciais/proprietários de OCR continuarão superiores em documentos reais
Isso se deve à grande quantidade de datasets privados de treinamento de alta qualidade
LLMs públicos foram treinados mais em dados de artigos do arXiv, e-books e semelhantes, então tendem a ir pior em documentos reais de trabalho
A abordagem com LLM reduz erros de substituição de caracteres (typos, variações), mas a consistência no nível da página inteira acaba sendo pior
Também pode produzir saídas totalmente erradas, como LLMs não voltados a OCR
Em caracteres CJK, OCR tradicional ainda produz muitas substituições inadequadas
Existem caracteres muito parecidos, às vezes distinguíveis só quase no nível microscópico ou binário
Como os LLMs impõem mais restrições às sequências de caracteres possíveis, dá para esperar resultados mais precisos
Pelo menos esse tipo de preocupação já motiva a adoção de OCR baseado em LLM
Não sei sobre outros modelos, mas na nossa empresa usamos Azure AI Document Intelligence para um sistema de parsing de currículos e estamos bastante satisfeitos
Depois de acertar o ajuste inicial, quase não precisou de manutenção no último ano
Testei vários VLMs, de modelos pequenos como Granite e Qwen até modelos grandes, e minha conclusão é que eles decepcionam como substitutos completos do OCR tradicional
Nosso sistema recebe documentos de clientes e devolve documentos padronizados com marcação conforme solicitado, no formato de bitmaps rasterizados multipágina
Para nós, a precisão na extração de coordenadas no nível de caracteres ou palavras individuais é importante, mas na prática a informação posicional dos VLMs é inconsistente demais, completamente alucinada ou vaga demais para garantir a precisão e granularidade desejadas
Até agora, continuamos com uma base em Tesseract, usando rotinas de limpeza no resultado, e só recorremos ocasionalmente à saída textual de VLMs como apoio quando não há dataset estruturado
Talvez nosso caso seja uma necessidade muito específica, e para a maioria das pessoas basta obter um dump de texto ou conversão para Markdown/HTML
Mesmo assim, sinto uma grande distância entre as alegações de que esses modelos “resolveram o OCR” e a experiência prática
Sugiro testar o modelo moondream 3 preview
O post do blog diz que ele supera o desempenho de vários VLMs e é um modelo leve
Veja a página principal, o modelo e o blog
Fiquei curioso se os documentos dos clientes incluem texto manuscrito
Também daria para detectar primeiro as bounding boxes do texto com uma CNN e rodar o VLM em cada caixa separadamente
Minha impressão pessoal era de que OCR já era um problema meio resolvido
O benchmark da OmniAI nem foi atualizado com modelos mais recentes, e achei que o motivo fosse os LLMs genéricos já terem superado o OCR daquele benchmark
Na prática, ao colocar cada imagem de página no Gemini 2.5 Flash Lite e pedir extração em Markdown, o custo foi de cerca de 20 centavos por 1000 páginas e o resultado foi muito bom
Então fiquei me perguntando o que ainda é difícil em OCR hoje em dia
A maioria dos OCRs/LLMs, inclusive o Gemini Pro 2.5, ainda sofre bastante para converter tabelas complexas em Markdown/HTML
Cabeçalhos múltiplos, células mescladas, colunas com checkboxes e outros problemas são frequentes, e eles também não entendem direito tabelas que atravessam várias páginas
O Llamaindex também falha feio nisso
Queria saber quais OCRs/LLMs se saem melhor nesses casos
Exemplo de tabela complexa, Exemplo completo de checklist ICAO
Na verdade, não é OCR, e sim HTR (reconhecimento/transcrição de escrita manual), que continua complicado
Com LLMs, a precisão melhorou bastante, mas os erros ficaram muito mais difíceis para humanos encontrarem (porque o modelo simplesmente inventa o que não consegue ler)
Se você aceita resultados que, em vez de dizer “não sei”, inventam partes ilegíveis, então sim, o problema está resolvido sem dificuldade
(Não estou sendo sarcástico; em alguns cenários isso realmente pode ser aceitável)
Eu sou o autor do benchmark OmniAI
O motivo de ele não estar atualizado com os modelos mais recentes é que o OCR API foi reduzido no produto
Internamente ainda usamos, mas o benchmark ficou desatualizado por pura preguiça
O Gemini é o melhor em OCR
Porém, quando o resultado fica perto demais dos dados de treino, ele costuma ter um erro de “recitation” em que cerca de 10% da saída simplesmente é cortada de repente
Em PDFs mistos, se entrar uma página em branco, às vezes ele produz alucinações engraçadas inventando conteúdo do nada
A OpenAI também não é ruim, mas o GPT5 não mostra diferença relevante em relação ao GPT-4o ou 4.1
Alguns conteúdos, como cabeçalhos/rodapés, frequentemente somem, e ele enlouquece quando a página está girada de lado
Também recusa com frequência conteúdos de documentos de identidade, arquivos médicos e outras coisas com alto risco de PII
Para mim, está longe de ser um problema resolvido
Tente fazer OCR de revistas com layout incomum e verá que é praticamente impossível
Coleciono revistas vintage e vivo tentando OCR com a tecnologia mais nova, mas sempre preciso de uma quantidade enorme de trabalho manual
Fiquei curioso se existe algum “modelo de OCR” pequeno
A necessidade é extrair apenas números de série em fotos tiradas no chão de fábrica, sem precisar de parsing de documento completo
Usar um modelo de 3 bilhões de parâmetros para isso parece exagerado demais
Tenho curiosidade sobre como o DeepSeek-OCR se compara ao Tesseract (link)
Eu uso bastante o ocrmypdf (link) e ele funciona muito bem localmente
Mas mesmo que o Tesseract entregue 80% de desempenho e um modelo moderno chegue a 95%, se o preço disso for 100x mais disco, Kubernetes/Docker e GPU com 16 GB de VRAM, isso já é uma consideração bem relevante
Como alguém que não acompanha a pesquisa mais recente, queria muito uma explicação estilo ELI5 do que é isso e por que importa
No GitHub e no título do artigo fala de OCR, mas no resumo e no
readme.mdo foco parece ser compressão de contexto para LLM, então fiquei confusoEstou procurando alguém que explique como essas duas coisas se conectam, no contexto mais amplo
A imagem conteria informação equivalente a “1000 tokens”
Na prática, como a imagem precisa ser transformada (decodificada) em features/embeddings,
se essa imagem for processada como 100 “tokens de imagem”, e esses tokens de imagem forem convertidos em 1000 “tokens de texto”,
então, do ponto de vista puramente da decodificação, a informação de saída foi transmitida com compressão de 10x
Do ponto de vista do LLM, isso significa que, se for possível comprimir antecipadamente em uma representação latente 10x menor, ele pode gerar o mesmo ou mais resultado sem precisar de 1000 tokens/embeddings