- Ao extrair informações de documentos complexos, abordagens tradicionais de OCR e parsing não conseguem preservar adequadamente o significado
- A Morphik implementou uma abordagem de embeddings visuais de documentos baseada no modelo ColPali, capaz de compreender diretamente até tabelas, gráficos e o contexto de layout
- Em comparação com pipelines convencionais, esse método é muito superior em precisão e preservação de informação, alcançando até 95,56% de acurácia em testes de benchmark
- Além disso, com a adoção de MUVERA e Turbopuffer, houve ganho de velocidade em buscas de documentos em larga escala
- Daqui para frente, o objetivo é automatizar de forma prática o trabalho com documentos, com recursos como raciocínio sobre múltiplos documentos, integração a workflows e interpretação em nível especialista
Os limites do parsing de documentos complexos e o sofrimento do RAG
- Ao tentar extrair informações de documentos PDF complexos com gráficos, diagramas e tabelas misturados, pipelines de OCR e parsing frequentemente perdem as informações desejadas
- Em situações reais, ficam evidentes as limitações dos pipelines tradicionais, como em tabelas aninhadas, diagramas importantes, documentos técnicos cheios de anotações e até manuais sem texto
- Etapas de um pipeline tradicional:
- Aplicar OCR ao PDF (podendo ler números ou caracteres de forma errada)
- Tentar separar tabelas/diagramas com um modelo de detecção de layout (com alta chance de falha)
- Reconstruir a ordem de leitura (o fluxo visual pode se perder)
- Reconhecer legendas de diagramas (frequentemente com perda de nuances)
- Fazer chunking de texto (informações relacionadas podem ser separadas)
- Gerar embeddings vetoriais e armazenar em um banco de dados vetorial (perdendo informações de posição e contexto)
- Exemplo: até uma tabela simples pode ter
1,000 lido como l,0O0, ou a tabela e o cabeçalho serem separados, fazendo falhar o cálculo do total
- Casos reais de perda de informação são frequentes, como confundir a legenda de um gráfico com o corpo do texto, ou espalhar valores percentuais em posições erradas
Nova abordagem: mudança para compreensão de documentos baseada em visão
- A equipe da Morphik encontrou um ponto de virada com a pergunta: "E se entendêssemos documentos como objetos visuais, como os humanos fazem?"
- Com pesquisas recentes (ColPali) e o avanço dos Vision Language Models (VLMs), tornou-se possível fazer embeddings diretamente a partir de imagens, preservando o contexto completo do documento e as informações visuais sem parsing nem OCR
- Cada página do documento é processada como uma imagem em alta resolução e dividida em patches, gerando embeddings que refletem tanto informações visuais quanto textuais
- O SigLIP-So400m Vision Transformer gera embeddings dos patches visuais, e o modelo de linguagem PaliGemma-3B entende a estrutura do documento
- Para consultas como "tendência de receita no Q3", a busca por late interaction recupera com precisão informações relevantes, incluindo pistas visuais como texto, gráficos, tabelas e cores
- A posição no documento, o layout, as cores, as mudanças em gráficos e todas as demais informações visuais são preservadas — de forma semelhante a como uma pessoa vê um documento de relance
Comparação entre parsing tradicional e a abordagem ColPali
- O pipeline tradicional baseado em parsing perde informação em cada etapa, e como embeddings de texto e imagem ficam separados, torna-se impossível interpretar as relações espaciais dentro do documento
- Já a abordagem ColPali integra todas as informações em um único espaço de embeddings visuais, preservando o significado global e o contexto do documento
- Em benchmarks reais (focados em documentos financeiros, com datasets públicos), a Morphik (baseada em ColPali) registrou até 95,56% de acurácia (enquanto LangChain + OpenAI text-embedding ficaram em 72%, e a busca de arquivos da OpenAI em apenas 13,33%)
- No benchmark ViDoRe, a abordagem visual superou a de parsing tradicional em mais de 14 pontos percentuais em nDCG@5
Otimização de desempenho e aplicação prática
- A desvantagem inicial da abordagem era a queda de velocidade causada pela carga computacional, já que a estrutura exigia busca vetorial para cada patch, o que a tornava inadequada para dezenas de milhões de consultas por segundo
- Com base no paper MUVERA, foi introduzido um método que substitui a busca multivetorial por busca vetorial única (codificação de dimensão fixa)
- Em combinação com o banco de dados vetorial especializado Turbopuffer, a velocidade de consulta melhorou de 3–4 segundos para cerca de 30 ms
- Com isso, tornou-se possível pesquisar milhões de documentos em velocidade muito superior à do parsing textual tradicional
Áreas de aplicação e API simples
- Suporte a buscas de alta precisão sem perda da estrutura visual nem das informações em diversos tipos de documentos
- Documentos financeiros em que tabelas e gráficos complexos são importantes
- Manuais técnicos centrados em diagramas
- Extração de informações baseada em layout em faturas e recibos
- Compreensão de materiais visuais e dados numéricos em artigos de pesquisa
- Reconhecimento de relações baseado em layout em registros médicos
- A API tem uma estrutura muito simples: basta fazer upload do documento e consultar em linguagem natural, com suporte a pedidos como "mostre todos os contratos com cláusulas de multa acima de 10 mil dólares"
Direção futura: inteligência multocumento e compreensão mais profunda
- Inteligência multocumento: desenvolvimento de recursos de referência cruzada e rastreamento de informações entre vários documentos
- Indo além da busca em documento único, com suporte a rastreamento de relações e raciocínio entre vários documentos (por exemplo, ligar cláusulas de contrato → documentos regulatórios → manuais de execução)
- Sistema de compreensão por agentes: além de perguntas e respostas simples dentro de um documento, automatiza raciocínio lógico entre chunks, como extração de cláusulas → validação em outro documento → verificação cruzada de detalhes
- Integração a workflows: evolução da inteligência de automação documental alinhada a processos reais de trabalho, como comparar condições entre vários contratos ou rastrear o histórico de decisões técnicas
Limitações e próximos objetivos
- A abordagem atual ainda não chega ao nível de interpretação e julgamento contextual de um especialista
- Aspectos como a análise aprofundada de um especialista financeiro ainda são tecnicamente insuficientes, e necessidades corporativas como confiabilidade e quantificação de incerteza exigem desenvolvimento adicional
- A combinação entre compreensão visual e grafos de conhecimento de domínio, raciocínio causal e oferta de métricas de confiabilidade são os principais desafios daqui para frente
Conclusão
- Documentos devem ser tratados como objetos visuais de conhecimento, e, indo além dos limites do parsing, a compreensão de documentos baseada em imagem é uma solução superior no ambiente de RAG
- A Morphik quer apresentar um novo padrão para extração de informações de documentos, mirando a automação de workflows documentais complexos e a aplicação em tarefas reais
- É possível experimentar os recursos em detalhes em morphik.ai
1 comentários
Comentários no Hacker News
Há vários problemas fundamentais que as pessoas precisam entender
Os LLMs em geral são pré-treinados com cerca de 4k tokens de texto e depois estendidos para janelas de contexto longas (passar de 4000 para 4001 é fácil, mas com imagens isso não é possível porque a tokenização é diferente)
Como resultado, sai-se da distribuição, e ao lidar com mais de duas ou três imagens o problema de alucinação fica grave
Um PDF em resolução 1536×2048 usa de 3 a 5 vezes mais tokens do que texto, então o custo de inferência aumenta e as respostas ficam mais lentas
Se baixar a resolução, a imagem fica borrada
Imagens também são pesadas por natureza, então só baixar as imagens necessárias já adiciona latência a cada requisição
Em benchmarks pequenos, isso naturalmente funciona melhor do que o chunking de texto básico para documentos financeiros com muitos gráficos e tabelas
Pessoalmente, eu gostaria de comparar os resultados com algo como o Gemini permitindo anotações OCR sobre a imagem
Uma abordagem de ponta a ponta com imagens faz sentido em casos especiais (patentes, diagramas de arquitetura etc.), mas realmente é o último recurso
O problema é que o LLM pode inventar um texto plausível nas partes que não consegue ler, piorando ainda mais o resultado
Por exemplo, o GPT4.1 funcionou perfeitamente numa captura de tela de 1296×179, mas ao reduzir 50% e passar 650×84, ele devolveu "Pdf's at 1536 × 2048 use 3 to 5X more tokens" como "A PNG at 512x 2048 is 3.5k more tokens"
Na maior parte ele acerta, mas é preciso ter cuidado com esse tipo de mudança sutil nos detalhes
Uma característica interessante da família gemma3 é que aumentar o tamanho da imagem de entrada não aumenta a exigência de memória de processamento
Isso porque o encoder do segundo estágio comprime para tokens de tamanho fixo
Na prática, é bem útil
Mas aí todo o conjunto de documentos processado teria necessariamente de passar por um VLM grande
Pode ficar caro e lento demais
Claramente há um trade-off aqui
Na maioria dos casos, o jeito atual foi o mais eficaz
Às vezes colocam qualquer coisa dentro do LLM, mas dependendo do caso isso pode não ser adequado
Nem tudo precisa obrigatoriamente ser processado por um LLM
Parece que isso pode se expandir para uma ideia que mude o pipeline de RAG
Para cada resultado do RAG, na etapa de processamento do modelo seria possível extrair da imagem apenas a informação diretamente relevante para a consulta do usuário e usar esses resultados em texto como entrada para a geração final
Assim dá para contornar o limite de tokens de várias imagens e paralelizar o processo de entendimento das imagens
Eu e meus colegas implementamos algo assim há 6 meses para uma agência do governo francês
Disponibilizamos como open source aqui: https://github.com/jolibrain/colette
Não é nosso negócio principal e está meio largado, mas com alguns ajustes funciona de forma bem eficiente
O verdadeiro charme é que dá para tornar o pipeline inteiro totalmente diferenciável e fazer fine-tuning do viz rag especializado para um dataset específico
Também é possível customizar o modelo de layout para entendimento preciso de documentos
Em geral, o maior obstáculo é a necessidade de um conjunto de avaliação de alta qualidade (como sempre)
Fizemos vários estudos de benchmark entre OCR e imagem + LLM genérico: https://getomni.ai/blog/ocr-benchmark
O maior problema da abordagem de extração direta da imagem é documento com múltiplas páginas
Em página única, no comparativo (OCR=>LLM vs Image=LLM), a imagem direta foi ligeiramente melhor, mas ao passar de 5 imagens ou mais a precisão despenca em relação à abordagem OCR-first
Na verdade, recall de longo contexto em texto já é um desafio difícil, embora os LLMs sejam otimizados para isso; em imagens, o recall de longo contexto ainda deixa muito a desejar
Também funciona bastante bem colocar uma pequena camada de transformação LLM diretamente sobre a imagem (ou seja, em vez de fazer OCR direto, enviar 5 imagens de uma vez para um modelo de visão pequeno e extrair só os pontos mais importantes do documento)
Atualmente estamos pesquisando modificar o cache ou o attention map do LLM para que batches maiores de imagens funcionem melhor
Abordagens como sliding window ou infinite retrieval parecem promissoras
É um palpite pessoal, mas vendo a aceleração do progresso em modelos multimodais, acho que em breve longo contexto de imagem não será um grande problema
Este post do blog faz observações boas sobre usar modelos de visão para retrieval, mas quero apontar alguns problemas
Parsing de documentos é o trabalho de transformar um documento em texto estruturado, como Markdown/JSON (ou, no caso de extração, uma saída conforme um schema)
RAG é apenas um dos usos disso, e há vários outros
O ColPali é excelente para retrieval, mas não serve para parsing puro de documentos (pelo menos não de forma nativa)
O autor menciona principalmente benchmarks de retrieval visual
Muitas vezes funciona melhor do que OCR padrão, mas
a. ainda há problemas de precisão na long tail
b. faltam metadados como confidence score, bounding box etc.
c. o próprio pipeline de screenshots exige esforço para ficar sofisticado
Tokens de imagem são muito mais poderosos, mas tokens de texto são muito mais baratos de armazenar, então é possível consultar documentos inteiros no retrieval (em vez de só chunks)
(Para contexto: sou CEO da llamaindex e já fiz tanto parsing quanto retrieval com o LlamaCloud; é só uma visão geral)
No ano passado passei bastante tempo construindo um sistema de análise de documentos de patente
Patentes incluem vários tipos de conteúdo, como diagramas abstratos, fórmulas químicas e expressões matemáticas, então preparar os dados para LLM foi realmente complicado
O jeito mais simples que encontrei foi converter cada página como se fosse uma “foto” e então pedir ao LLM para gerar um JSON descrevendo o conteúdo e metadados (número da página, quantidade de elementos visuais etc.)
Para imagens complexas, basta pedir ao modelo para descrevê-las
Assim fica fácil embutir o JSON no vector store que você quiser
É difícil avaliar a relação custo-benefício, mas esse método é mais simples e eficaz do que o proposto pelo autor
Por exemplo, mesmo que o modelo extraia corretamente a maioria dos pares x, y de um gráfico, se o usuário perguntar por um x/y específico ele pode acabar omitindo
Se você mostrar a imagem diretamente ao modelo na etapa de inferência, ele poderá responder exatamente ao que o usuário perguntar, então essa abordagem é mais eficaz
O único obstáculo real aqui é a qualidade do retrieval, e isso é um problema relativamente pequeno
Ou seja, se você conseguir passar o contexto adequado, o LLM cobre o resto por conta própria
Caso contrário, o número de problemas a resolver com OCR, parsing, descrição de imagem etc. cresce rapidamente
Mas também mostra que a oportunidade dos LLMs está concentrada em reclassificar/reprocessar valor já existente (como documentos de patente)
Nos anos 90-2000, empresas de software tiveram sucesso convertendo documentação em papel existente para bancos de dados
Criar do zero datasets novos e valiosos ainda exige muito investimento e esforço
Pela minha experiência, essa abordagem não é muito boa
Dependendo da fonte, é difícil distinguir o (letra o) de 0 (zero)
Ao converter um documento (doc/xls/pdf/html) em imagem, você perde esse tipo de informação distintiva
Em números de série e similares, às vezes nem uma pessoa consegue diferenciar olhando
Então, para PDF, renderizar como imagem e extrair assim é bastante razoável
Para os demais formatos, é melhor fazer parsing direto do documento
Mas, na prática, ao trabalhar com design de páginas, mostrar a imagem real ao modelo é muito mais eficaz para depuração do que passar apenas o código
Os problemas de 1 vs I e 0 vs O realmente existem, mas em documentos com muitos diagramas/gráficos eu frequentemente tive muito mais facilidade processando só por imagem
(Pode haver viés de seleção)
Passei vários minutos tentando copiar um cronograma para o Gemini e fazer perguntas, mas mesmo em HTML não funcionava direito
No fim, tirei um screenshot, cobri as partes desnecessárias com caixas pretas e enviei a imagem, e funcionou muito bem
Fiquei curioso porque parece que RAG multimodal já resolve esse problema
Obtive resultados de análise de imagem bastante satisfatórios com Flash 2.5, Sonnet 3.7 etc.
Na verdade, tenho a impressão de que recebo respostas melhores quando forneço imagens do que texto
https://www.youtube.com/watch?v=p7yRLIj9IyQ
Só que multi-vector em estado bruto (a base do RAG multimodal) é muito difícil de lidar e o cálculo de similaridade é muito caro, então é difícil escalar
É preciso quantização, conversão para vetor único (codificação de dimensão fixa), otimização de indexação etc.
É exatamente nisso que trabalhamos na Morphik
Eu também tentei escanear todas as minhas contas de uma vez, extraindo só os anexos da caixa de correio e rodando um script para enviar um por um e extrair “invoice: sim/não”, além de cada item/nome do fornecedor/data/número da invoice etc.
No fim, a taxa de leitura foi alta e houve mais de 3 horas de chamadas para LLM, mas como era automação não me importei
Depois ainda pedi ao LLM para fazer o matching com o extrato bancário, e só ficaram faltando algumas invoices que não tinham vindo como anexo
Mas o matching invoice-extrato foi bem fraco (se houvesse diferença de alguns dólares ele simplesmente respondia que era aquele extrato)
Então, por enquanto, parece que ainda é preciso um contador
Não estimei bem o custo, e usei um modelo barato como o Claude 3.7
Entendo por que o ColPali parece intuitivo e poderoso, mas ainda assim há vantagens no processamento de documentos