Por que um modelo excelente em fotos é ruim para ler sua fatura
Baseado em: MonkeyOCRv2: A Visual-Text Foundation Model for Document AI — Yuliang Liu, Zhang Li, Ziyang Zhang, Shuo Zhang, Qiang Liu, Jiajun Song, Zidun Guo, Xinhan Wang, Handong Zheng, Yang Liu, Dongliang Luo, Zhiyin Ma, Jiarui Zhang, Xiang Bai
Desfoque uma foto de um golden retriever em alguns pixels e você ainda o chamará de cachorro. Desfoque uma fatura digitalizada na mesma quantidade e "$1.987,00" pode se tornar "$1.387,00" sem ninguém perceber até que os números parem de bater. Esse é todo o problema em uma frase: fotos do mundo toleram imprecisão, e páginas de texto não. Um novo artigo chamado MonkeyOCRv2 leva essa discrepância a sério, e a solução é mais interessante do que "treinar com mais documentos".

Os olhos foram treinados nas imagens erradas
Todo sistema moderno de IA para documentos, seja analisando um PDF ou respondendo perguntas sobre um formulário escaneado, começa com um codificador de visão: uma rede neural que transforma uma imagem em uma representação compacta sobre a qual o restante do modelo pode raciocinar. O problema apontado pela equipe do MonkeyOCRv2 é que quase todos esses codificadores, incluindo os embutidos nos modelos multimodais populares de hoje, foram pré-treinados em imagens naturais. Pense em ImageNet, LAION, a dieta padrão de gatos, carros e fotos de férias.
Esse pré-treinamento ensina uma rede a reconhecer objetos e cenas em um nível grosseiro. Um cachorro continua sendo um cachorro, mesmo que esteja levemente desfocado, rotacionado ou fotografado de três pés mais perto. Mas uma página de texto é um tipo de imagem completamente diferente. A diferença entre "cl" e "d" é de alguns pixels. Uma vírgula versus um ponto pode mudar o significado de um número. Um subscrito em uma fórmula química posicionado um pixel acima ou abaixo do correto altera a fórmula. O artigo chama isso de "percepção visual em nível de caractere", e é uma lacuna real: um codificador excelente em distinguir um poodle de um labrador não tem razão particular para ser bom em distinguir um 3 de um 8 em fonte tamanho 8, porque nada em seu treinamento exigiu esse nível de precisão.
É por isso que acoplar um codificador de visão de propósito geral a um modelo de linguagem e chamá-lo de sistema de IA para documentos tende a produzir algo fluente, mas ocasionalmente errado de maneiras difíceis de detectar. Ele lê a forma de uma página mais do que lê a página em si.
Construindo a maior pilha de documentos já usada para pré-treinamento
A resposta da equipe do MonkeyOCRv2 começa com os dados: um corpus chamado MonkeyDoc v2, que, segundo eles, é o maior conjunto de pré-treinamento de imagens de documentos construído até agora, com 113 milhões de imagens abrangendo 17 idiomas. Isso não significa 113 milhões de documentos raspados uma vez e deixados de lado. É a matéria-prima para um tipo específico de treinamento que os conjuntos de dados de imagens naturais nunca foram projetados para suportar, pois um corpus de fotos de gatos não precisa de alinhamento em nível de caractere entre pixels e texto.
Apenas a escala não resolveria o problema subjacente, no entanto. Você poderia pré-treinar um codificador no estilo de imagens naturais em 113 milhões de imagens de documentos e ainda acabar com algo que trata uma página como um único objeto grande e borrado, a menos que o objetivo de treinamento force o modelo a se preocupar com traços individuais.
Dois trabalhos para um único codificador
O truque real está em como o pré-treinamento funciona, e é um design genuinamente inteligente. O modelo aprende duas tarefas ao mesmo tempo, usando o mesmo backbone visual:
- Geração de texto a partir de imagem. Dada uma imagem de documento, produza o texto que ela contém. Esta é a tarefa familiar de OCR, e ela ensina o codificador a alinhar o que ele vê com o significado das palavras.
- Reconstrução de documento em nível de pixel. Dada uma imagem de documento, reconstrua a própria imagem em nível de pixel, preservando os traços dos caracteres e o layout.
Pense nisso como a diferença entre um aluno que lê uma página e a resume, versus um que precisa redesenhar a página de memória, traço por traço. A primeira tarefa sozinha pode produzir um modelo que capta a essência de um documento enquanto suaviza exatamente os detalhes finos, como um pequeno serifado ou a cauda de um "g" minúsculo, que separam uma transcrição correta de uma incorreta que parece plausível. Forçar o mesmo codificador a também reconstruir pixels significa que ele não pode se safar com uma representação interna vaga. Ele precisa manter detalhes suficientes para redesenhar o traço, não apenas adivinhar a palavra.
A combinação das duas é mais importante do que qualquer uma isoladamente. A reconstrução sem o objetivo de geração de texto produziria apenas um compressor de imagem muito bom, sem nenhum entendimento particular do que os sinais significam. A geração de texto sem reconstrução é o status quo, e o status quo é o que falha em textos densos, pequenos ou degradados.
Testando onde realmente importa
Em vez de criar uma única demonstração chamativa, a equipe substituiu o codificador do MonkeyOCRv2 em sistemas existentes em cinco tarefas distintas de documentos e verificou se o desempenho melhorou: reconhecimento de texto, reconhecimento de fórmulas, detecção de texto, detecção de adulteração de documentos e segmentação de texto sobreposto.
Esse último par merece uma pausa, pois não são as tarefas mais discutidas no marketing de OCR. A detecção de adulteração significa identificar quando um documento foi alterado digitalmente, como um recibo com total modificado ou um certificado com nome trocado. A segmentação de texto sobreposto significa separar corretamente o texto quando ele é carimbado, marcado com marca d'água ou escrito à mão sobre texto impresso, o que acontece constantemente em formulários digitalizados, sinistros de seguro e registros arquivísticos antigos. Ambas as tarefas dependem exatamente da fidelidade em nível de pixel que o objetivo de reconstrução foi projetado para preservar: você não pode detectar que um dígito foi alterado se o seu codificador já descartou os detalhes finos que revelariam isso.
Em todas as cinco tarefas, substituir o codificador original pelo do MonkeyOCRv2 resultou em melhorias. Essa consistência é o achado mais significativo aqui. Um modelo que vence no reconhecimento de texto, mas perde no reconhecimento de fórmulas, sugeriria que os ganhos vêm de overfitting às peculiaridades de um único benchmark. Vencer em cinco tarefas genuinamente diferentes é uma evidência melhor de que o codificador aprendeu algo geral sobre documentos, em vez de algo restrito a um único conjunto de dados.

O número que deveria deixar os concorrentes nervosos
Aqui está o resultado que eu destacaria se só pudesse escolher um. A equipe pegou seu codificador pré-treinado, congelou-o completamente (sem treinamento adicional nele), o combinou com um pequeno modelo de linguagem e construiu um modelo de análise de documentos com 0,7 bilhão de parâmetros.
Esse modelo estabeleceu um novo estado da arte de código aberto no MDPBench, um benchmark recente que abrange tanto documentos nascidos digitais (PDFs exportados limpos de softwares) quanto documentos fotografados (fotos tiradas com celular de papéis, com todos os problemas de iluminação e ângulo que isso implica) em 17 idiomas. Ele superou o melhor modelo de código aberto anterior, um sistema de 3 bilhões de parâmetros chamado dots.mocr, por 2,8 pontos percentuais, enquanto usava um codificador visual aproximadamente 11 vezes menor.
Um modelo menor superando um maior não é impressionante por si só; muitas arquiteturas eficientes fazem isso em benchmarks restritos. O que torna esse resultado digno de atenção séria é de onde vem a redução de tamanho. Não é um modelo de linguagem mais inteligente fazendo mais trabalho. É um codificador visual que precisa de menos parâmetros porque foi treinado com o tipo certo de dados desde o início, em vez de tentar compensar as falhas de um codificador de imagens naturais com um modelo downstream maior. Essa é uma lição significativamente diferente de "reduzir o tamanho do transformer". Ela diz que o campo tem pago demais por capacidade visual que estava apontada para o problema errado.
Não serve apenas para análise sintática
O artigo também testa o codificador congelado como um componente em modelos de compreensão de documentos, sistemas que não apenas transcrevem um documento, mas respondem a perguntas sobre ele, resumem-no ou raciocinam sobre seu layout. Aqui, eles comparam contra codificadores construídos sobre CLIP, DINO e SAM: três dos backbones de visão mais amplamente utilizados em IA multimodal, todos treinados principalmente em imagens naturais ou tarefas de segmentação geral, em vez de documentos especificamente.
Sob condições de treinamento idênticas, o codificador MonkeyOCRv2 superou os três em oito benchmarks. Esse é um controle útil: mesma arquitetura downstream, mesma receita de treinamento, apenas o codificador muda. Isso isola a afirmação para o que deve ser isolado, que o pré-treinamento visual específico para documentos produz uma base melhor do que o pré-treinamento de uso geral, em vez de ser um artefato de um pipeline de treinamento melhor em outro lugar do sistema.
O que o artigo não diz
Há alguns pontos que valem a pena destacar antes que alguém trate isso como um assunto encerrado.
Primeiro, o resumo não relata o custo ou o poder de computação de treinamento, e o mesmo vale para o resumo disponível aqui. Construir um corpus de pré-treinamento com 113 milhões de imagens e executar o objetivo conjunto nessa escala não é barato, e não está claro se laboratórios menores ou desenvolvedores independentes poderiam reproduzir algo próximo disso sem recursos semelhantes. A eficiência no momento da inferência (um modelo de 0,7B) não diz muito sobre a eficiência no momento do treinamento.
Segundo, a detecção de adulteração e a segmentação de texto sobreposto são capacidades úteis, mas também são benchmarks relativamente nichados, e pontuações altas nelas não necessariamente preveem como o modelo lida com os documentos do mundo real mais bagunçados: recibos amassados, digitalizações de fax de baixo contraste, manuscritos misturados com texto impresso, documentos fotografados de ângulo sob iluminação ruim. O MDPBench inclui documentos fotografados, o que é um bom sinal, mas "fotografados sob condições de benchmark" e "fotografados por alguém em um armazém com uma mão e a lanterna do celular" não são o mesmo teste.
Terceiro, não há menção sobre licenciamento, disponibilidade dos pesos ou se o próprio MonkeyDoc v2 será lançado. Grande parte do valor prático de um artigo como este, para pessoas que realmente estão construindo produtos de OCR, depende de o codificador pré-treinado aparecer em algum lugar utilizável, e não apenas em uma tabela de benchmark.
Por que isso importa para quem constrói ou compra OCR
Se você está avaliando motores de OCR ou construindo um pipeline que precisa sobreviver ao contato com documentos reais de clientes, a lição não é "use o MonkeyOCRv2 especificamente". É que o codificador de visão subjacente a um sistema de OCR ou de análise de documentos não é uma commodity intercambiável, e os dados de pré-treinamento por trás dele são tão importantes quanto o modelo de linguagem acoplado no topo. Um sistema construído em torno de um backbone visual de uso geral carrega uma desvantagem estrutural em textos densos, fórmulas pequenas e conteúdo alterado ou sobreposto, independentemente de quão bom seja seu modelo de linguagem na limpeza da saída posteriormente.
Na prática, isso significa algumas coisas que valem a pena verificar ao comparar motores: como eles se saem especificamente em documentos com muitas fórmulas ou fontes pequenas, não apenas em páginas impressas limpas; como eles lidam com documentos onde algo foi alterado ou carimbado por cima; e se os números de precisão alegados vêm de PDFs nascidos digitais, documentos fotografados ou ambos. O abismo entre essas categorias é exatamente onde os codificadores de visão de uso geral tendem a falhar, e é exatamente onde um artigo como este está tentando reduzir a distância.
O sinal mais amplo, se os resultados se mantiverem fora dos benchmarks deste único artigo, é que a IA de documentos está começando a desenvolver seus próprios modelos de fundação, em vez de emprestar aqueles construídos para um trabalho diferente. Essa é uma direção saudável. Um campo que continua reaproveitando codificadores de visão de gatos e carros para faturas e contratos sempre ia encontrar um teto em algum lugar, e este artigo é um argumento decente de que estamos encontrando-o.