CC-OCR submeteu nove principais modelos de IA a 7.058 documentos reais, e a maioria falhou nos fundamentos

Alimente um modelo de visão-linguagem de última geração com uma foto do cardápio de um restaurante tailandês, tirada em um ângulo ligeiro sob iluminação fluorescente, e peça para ele extrair os nomes dos pratos e os preços. Um número surpreendente deles começará com confiança, mas depois ficará travado. Não travado no sentido de "resposta errada". Travado no sentido de repetir as mesmas três palavras repetidamente até que a saída seja interrompida, como um disco riscado.

Esse é um dos achados enterrados no CC-OCR, um benchmark lançado em dezembro de 2024 por uma equipe principalmente do grupo Qwen da Alibaba, em conjunto com a Universidade de Tecnologia do Sul da China. O artigo testou nove grandes modelos multimodais proeminentes, incluindo GPT-4o e Gemini, em 7.058 imagens reais e anotadas em quatro categorias de tarefas de leitura de texto. O resultado principal: modelos que consideramos amplamente capazes de "ler" imagens possuem modos de falha específicos e previsíveis que uma simples pontuação de precisão nunca revela. Se você está construindo algo baseado em processamento de documentos impulsionado por IA, essa distinção importa mais do que a posição no ranking.

Um recibo real do conjunto de dados CORD — o tipo de documento do mundo real, em ângulo, que o CC-OCR usa para testar modelos. Fonte: CORD (Park et al., NAVER CLOVA, 2019), licenciado sob CC BY 4.0.

O que os benchmarks de OCR geralmente erram

O reconhecimento óptico de caracteres, que consiste em extrair texto legível de uma imagem, costumava significar executar um modelo especializado treinado para uma tarefa restrita: ler texto impresso em inglês em uma página digitalizada, por exemplo, ou ler placas de veículos. Os grandes modelos multimodais (LMMs) mudaram essa perspectiva. Esses modelos pertencem à mesma família capaz de descrever uma foto ou responder perguntas sobre um gráfico, e também podem ler texto embutido em imagens, pois foram treinados em enormes conjuntos de pares de imagem e texto coletados da internet, PDFs e capturas de tela.

O problema é que "ler o texto" acaba escondendo muitas habilidades subalternas diferentes e mais difíceis assim que saímos de páginas digitalizadas limpas. Documentos reais têm texto em ângulos estranhos. Eles possuem tabelas onde o significado reside na estrutura da grade, não apenas nas palavras. Eles misturam idiomas dentro de uma única linha. Podem ser manuscritos, danificados pela água ou fotografados em um ângulo estranho com o celular de alguém.

A maioria dos benchmarks de OCR existentes antes do CC-OCR testava uma fatia restrita desse problema. Alguns focavam puramente em texto de cena (placas de rua, fachadas de lojas). Outros focavam puramente na análise de documentos (convertendo um PDF em Markdown ou HTML estruturado). Poucos testavam múltiplos idiomas além do inglês e do chinês. Quase nenhum combinava "o modelo encontra a região correta da imagem" (grounding) com "o modelo produz texto preciso" como coisas separadas e mensuráveis. Essa lacuna é o que o CC-OCR buscou fechar, e é por isso que o artigo vale a pena ser lido, mesmo que você nunca treine um modelo por conta própria. Ele informa o que você deve realmente verificar antes de confiar em um pipeline de OCR com seus documentos.

Como o CC-OCR é construído: quatro trilhas, não uma única pontuação

O CC-OCR divide a avaliação em quatro trilhas, cada uma direcionada a um cenário do mundo real diferente:

Leitura de texto em múltiplas cenas. Este é o clássico "texto no mundo real": placas de rua, embalagens de produtos, capturas de tela, recibos. O desafio não é ler o texto isoladamente, mas sim encontrar o texto quando ele é pequeno, inclinado ou embutido em um fundo movimentado, e então lê-lo com precisão.

Leitura de texto multilíngue. O benchmark abrange idiomas além do par inglês/chinês que domina a pesquisa em OCR, testando se um modelo que lê bem placas em inglês também consegue lidar, por exemplo, com texto vertical em japonês ou escrita árabe da direita para a esquerda.

Análise de documentos. Esta é a tarefa de "PDF para texto estruturado" que se torna cada vez mais central nos fluxos de trabalho de IA: pegar um documento escaneado e convertê-lo em Markdown, HTML ou outro formato estruturado que preserve tabelas, cabeçalhos e a ordem de leitura, e não apenas uma transcrição plana de texto.

Extração de informações-chave. Dado um documento como uma fatura ou um formulário, extrair campos específicos, o valor total, a data, o nome do fornecedor, em vez de transcrever tudo indiscriminadamente. Esta é a tarefa que mais diretamente se alinha ao que as empresas realmente desejam do OCR: não "leia-me a página inteira", mas "diga-me o número da fatura".

Ao longo dessas quatro trilhas, o benchmark inclui 39 subconjuntos. Uma escolha de design notável: 41% das 7.058 imagens vêm de aplicações reais e foram lançadas pela primeira vez neste artigo, em vez de serem reaproveitadas de conjuntos de dados acadêmicos mais antigos. Isso é importante porque os benchmarks antigos tendem a ser memorizados. Um modelo que tenha visto as imagens de um conjunto de dados durante o treinamento parecerá artificialmente forte nele. Imagens frescas e do mundo real tornam o teste mais difícil de burlar e mais próximo do que um sistema de produção realmente encontrará.

A avaliação também separa duas coisas que a maioria das pontuações de OCR confla: se o modelo encontra a localização correta na imagem (ancoragem, geralmente pontuada por quão bem uma caixa delimitadora prevista se sobrepõe à verdadeira) e se o texto extraído é preciso. Um modelo pode acertar o texto e ainda assim ser penalizado se não conseguir indicar de onde esse texto veio, o que se revela ser uma falha comum e reveladora.

Por que recibos e placas rotacionadas quebram os modelos de última geração

O artigo testou nove LMMs proeminentes, abrangendo tanto modelos proprietários (as famílias GPT-4o e Gemini) quanto de código aberto, e os resultados se dividiram claramente em três pontos fracos recorrentes.

A ancoragem de texto é pior do que a precisão bruta de leitura sugere. Um modelo pode transcrever corretamente o texto de uma placa, mas ser incapaz de desenhar uma caixa delimitadora precisa ao redor da localização desse texto na imagem. Isso pode parecer uma lacuna técnica menor, mas representa a diferença entre "o modelo leu o total da fatura" e "o modelo pode informar ao seu sistema downstream exatamente onde o total da fatura está, para que você possa destacá-lo, censurá-lo ou cruzá-lo com um modelo". Para qualquer pipeline que faça mais do que transcrição, essa lacuna é o fator decisivo.

Texto em múltiplas orientações é um ponto cego consistente. Texto rotacionado, vertical ou de outra forma não horizontal atrapalha modelos que lidam bem com texto horizontal padrão da esquerda para a direita. Isso está em linha com algo que qualquer pessoa que já lidou com documentos digitalizados já sabe: digitalizações do mundo real nunca estão perfeitamente alinhadas. Um recibo fotografado em ângulo, um formulário digitalizado de cabeça para baixo, uma placa japonesa disposta verticalmente; esses não são casos extremos em produção, são a rotina de uma terça-feira qualquer.

A alucinação por repetição é a descoberta mais incomum. Em imagens mais difíceis ou visualmente mais agitadas, alguns modelos ficam presos em um loop, repetindo uma palavra, frase ou linha repetidamente, em vez de produzir uma saída coerente e delimitada. Não se trata do modelo obter a resposta errada; é o modelo ficar preso em um padrão de saída degenerado. É um modo de falha conhecido na geração de linguagem em geral (os modelos às vezes caem em loops de repetição quando estão incertos sobre o que deve vir a seguir), mas vê-lo aparecer especificamente em tarefas de OCR, onde se esperaria que a saída "correta" fosse rigidamente restrita pelo que está literalmente na página, é um aviso útil. A filtragem baseada em confiança não necessariamente capturará isso, porque o modelo não está expressando incerteza de uma forma que uma verificação downstream ingênua perceberia. Ele apenas se repete com total convicção.

Nenhum dos nove modelos domina em todas as quatro categorias. Um modelo que é forte em texto de cena em inglês pode ser medíocre em documentos multilíngues; um modelo que analisa documentos em Markdown limpo pode ter dificuldade com a extração de informações-chave nas mesmas imagens de origem. Esse é o destaque prático: "melhor modelo de OCR" não é um título único e transferível. Depende fortemente de como seus documentos realmente se parecem.

Por que isso importa se você está construindo sobre OCR

Se você está escolhendo um mecanismo de OCR ou construindo um produto que depende de um, três aspectos deste artigo devem mudar a forma como você avalia as opções.

Primeiro, teste com seus documentos reais, não com exemplos de demonstração do fornecedor. A própria contribuição do CC-OCR é, em parte, uma crítica à avaliação limitada: um modelo que obtém boas pontuações em texto de cena limpo, horizontal e apenas em inglês não diz quase nada sobre como ele lidará com uma fatura rotacionada, multilíngue e com muitas tabelas de um cliente real. Se seu produto lida com recibos, documentos em idiomas estrangeiros ou formulários manuscritos, faça benchmarks especificamente com esses tipos, porque a classificação geral em leaderboards não será preditiva.

Segundo, separe "o texto foi lido" de "o sistema consegue indicar onde o texto está". Se seu caso de uso envolve destacar campos extraídos, construir dados estruturados a partir de documentos ou realizar qualquer tipo de fluxo de revisão humana, a precisão de localização (grounding) não é um recurso opcional, é uma funcionalidade central, e é exatamente a dimensão em que o CC-OCR mostra que os modelos são mais fracos em relação à precisão bruta do texto.

Terceiro, fique atento a loops de repetição em produção, não apenas a respostas erradas. Um modelo que alucina um total plausível, mas incorreto, é um risco conhecido e gerenciável; você pode sinalizar extrações de baixa confiança e adicionar uma etapa de revisão. Um modelo que fica preso repetindo uma frase até atingir o limite de tokens é um tipo de falha completamente diferente, que pode consumir silenciosamente seu orçamento de API em um único documento e produzir uma saída obviamente quebrada, mas fácil de passar despercebida em um pipeline automatizado se você não estiver verificando especificamente por isso. Incluir uma verificação de comprimento ou repetição na sua etapa de pós-processamento não é exagero, é uma resposta direta a um modo de falha documentado.

Este também é o argumento prático para testar mais de um mecanismo contra o mesmo documento, em vez de apostar tudo em um único modelo. Como nenhum modelo testado no CC-OCR dominou em todas as quatro categorias (leitura de múltiplas cenas, leitura multilíngue, análise de documentos e extração de informações-chave), a aposta mais segura para um sistema de produção é tratar a escolha do mecanismo como dependente do tipo de documento, em vez de uma decisão única, e ter um caminho de fallback quando as fraquezas específicas do seu mecanismo principal aparecerem em uma determinada entrada.

O que o artigo não resolve

O CC-OCR é um retrato de nove modelos no final de 2024, e o campo avança rapidamente: novos modelos multimodais foram lançados desde então, e alguns podem ter abordado especificamente os problemas de grounding e repetição que este artigo destaca. O benchmark também não investiga profundamente por que a alucinação de repetição ocorre; ele documenta o padrão sem oferecer uma solução, o que obriga os profissionais a desenvolverem sua própria lógica de detecção e mitigação, em vez de dependerem de uma correção documentada.

Vale lembrar também que um benchmark, por mais abrangente que seja, ainda é um conjunto fixo de 7.058 imagens. Documentos reais continuam surpreendendo de maneiras que nenhum conjunto de testes fixo captura totalmente: um novo modelo de fatura, uma combinação de idiomas que ninguém pensou em incluir, um artefato de scanner único ao hardware de um cliente. O CC-OCR é um mapa genuinamente útil de onde os modelos atuais tendem a ter dificuldades. Não é um substituto para testar contra seus próprios documentos antes de colocar em produção.

Essa é realmente a linha condutora de todo o artigo: a capacidade geral de "o modelo pode ler imagens" e o OCR confiável e de nível de produção são coisas relacionadas, mas distintas, e a lacuna entre elas aparece de maneiras específicas e testáveis, como orientação, grounding e repetição descontrolada, em vez de ser um único controle que você pode ajustar.