OCR em 2026: pipelines clássicos, VLMs e Document AI

Viacheslav Dubrov

2026-03-04 · Atualizado 2026-09-06 · 18 min · Sistemas de recuperação e linguagem

Tradução automática Este artigo foi traduzido automaticamente a partir da versão original em inglês.

Atualização do artigo

Publicado originalmente a 4 de março de 2026. Revisto e atualizado a 6 de setembro de 2026. A atualização acrescenta candidatos mais recentes de OCR e modelos de visão, referências a benchmarks e orientações para interpretar resultados de extração de documentos.

As tabelas de classificação de OCR não coincidem porque testam documentos, outputs e avaliadores diferentes. A tabela versionada do benchmark OmniDocBench e os votos de preferência em direto do OCR Arena podem produzir ordenações diferentes; as pontuações não são intercambiáveis, mas a divergência é útil. Uma escolha para produção precisa de documentos e métricas provenientes da carga de trabalho real.

Os modelos vision-language (VLMs) conseguem lidar com layout, escrita manual, tabelas e imagens degradadas que fazem falhar um pipeline simples de reconhecimento de texto. Os engines tradicionais continuam competitivos em impressão limpa, sobretudo quando a latência em CPU e o custo operacional são importantes. O snapshot datado abaixo inclui PaddleOCR-VL 1.6 e dots.mocr, com diferentes compromissos entre hardware, privacidade e output. Consulte cada projeto antes de tomar uma decisão atual.

Repositório complementar: The OCR Gauntlet contém três notebooks didáticos e cinco amostras descarregadas. É uma demonstração de smoke test, não uma ordenação validada de engines. Na revisão inspecionada, os labels do Docling não selecionam de forma fiável o pipeline anunciado, as referências de reconhecimento de recibos incluem chaves de anotação, as falhas desaparecem das médias e o pedido Gemini usa gemini-2.5-flash, enquanto o notebook o identifica como Gemini 3 Flash. As métricas ANLS da página completa e os cenários de custo também precisam de uma interpretação separada. Estes defeitos de implementação têm de ser corrigidos antes de utilizar as pontuações para escolher um modelo.

Em resumo: Comece por verificar se existe uma camada de texto incorporada. Faça benchmark de um engine tradicional em digitalizações limpas e, em seguida, acrescente um VLM especializado ou geral apenas para as classes de documentos que não atingem o objetivo de qualidade. Compare separadamente as métricas de texto, tabelas e campos, e encaminhe campos com baixa confiança ou elevado risco para outro modelo ou para uma pessoa.

Para a versão compacta de seleção de modelos, consulte Best OCR Models in 2026: Classical OCR, PaddleOCR-VL, VLMs.

O OCR define agora a qualidade a jusante

O OCR alimenta há muito tempo arquivos, sistemas postais, ferramentas de acessibilidade e gestão documental. O RAG e os agentes de documentos tornaram os seus modos de falha visíveis a um grupo mais alargado de engenheiros: um modelo a jusante não consegue recuperar texto ou estrutura de tabelas que a extração tenha descartado.

A qualidade de retrieval do seu sistema RAG está limitada pela qualidade do OCR. Se a extração corromper uma tabela, interpretar mal uma data ou eliminar um parágrafo, alterações posteriores ao chunking e aos embeddings não conseguem recuperar a informação em falta. Esses erros podem ocultar uma cláusula contratual, alterar o total de uma fatura ou corromper um registo médico.

O OCR faz, por isso, parte da infraestrutura de retrieval e de agentes, juntamente com parsing, chunking, embedding e indexação. Os seus erros precisam de uma avaliação própria, em vez de serem absorvidos por uma única pontuação end-to-end.

O que significa OCR na era dos foundation models

O OCR converte texto numa imagem em caracteres legíveis por máquina. Document AI é o sistema mais abrangente à sua volta: análise de layout, parsing de tabelas e fórmulas, extração de campos, raciocínio semântico, proveniência e validação. Alguns artigos usam “OCR-2.0” para modelos end-to-end que combinam várias destas etapas, mas esse rótulo não deve apagar a distinção entre reconhecimento e compreensão documental.

O pipeline tradicional de OCR tem três etapas principais:

1. Deteção de texto: localizar regiões que contêm texto (por exemplo, CRAFT, DBNet).
2. Reconhecimento de texto: converter as regiões detetadas em sequências de caracteres (por exemplo, CRNN).
3. Pós-processamento: correção ortográfica e correção com um modelo de linguagem.

Isto funciona bem em documentos limpos, mas os erros de deteção, reconhecimento e pós-processamento podem acumular-se. Meça tanto a exatidão ao nível dos caracteres como a exatidão dos campos a jusante, para que uma página legível não esconda um total ou identificador incorreto.

Alguns percursos VLM end-to-end condensam uma parte maior desse pipeline num encoder visual e num decoder de linguagem. Modelos como GOT-OCR 2.0 podem emitir texto e estrutura em conjunto, enquanto VLMs gerais também conseguem mapear campos para um schema solicitado. Os compromissos dependem da carga de trabalho: latência, custo de GPU ou API e risco de texto plausível que não existe na imagem.

Nota prática: um modelo que recebe apenas imagens precisa de páginas rasterizadas, enquanto um serviço que aceita PDF pode tratar internamente da conversão. Deskewing, redimensionamento e limpeza são experiências específicas do pipeline, não melhorias obrigatórias. A AWS Textract recomenda preservar os inputs suportados em vez de os converter ou reduzir indiscriminadamente. O parsing e a validação do output continuam a pertencer à aplicação.

O que os benchmarks de OCR medem e não medem

Os datasets seguintes ilustram como diferentes tarefas de OCR produzem métricas diferentes. Os tamanhos dos datasets e as métricas descrevem a versão indicada do dataset; use a leaderboard atual de cada projeto para as pontuações dos modelos.

A contagem de linhas do IAM depende da divisão de writers e do protocolo de reconhecimento escolhidos; não é assumida aqui uma contagem única de linhas de teste.

A diferença entre “benchmark” e “arena”

As ordenações de benchmarks automatizados podem entrar em conflito com a preferência humana porque a distribuição dos inputs e os critérios de avaliação diferem.

No OCR Arena, os utilizadores votam cegamente em outputs apresentados frente a frente. A ordenação em direto muda à medida que chegam novos confrontos, pelo que não constitui um snapshot histórico reproduzível de benchmark. A tabela versionada do OmniDocBench mais adiante neste artigo responde a uma pergunta diferente, com métricas de dataset. Não combine as duas leaderboards numa única pontuação.

Os fatores prováveis incluem a mistura de documentos, a formatação do output, a cobertura linguística e os critérios do avaliador. Os números publicados são úteis para uma filtragem inicial, mas a seleção final precisa de um conjunto de validação separado proveniente da carga de trabalho-alvo.

Engines tradicionais de OCR: continuam relevantes

Se os engines tradicionais são piores em dados complexos, por que razão utilizá-los? Porque são rápidos e baratos em dados estruturados e limpos.

Os engines tradicionais são baselines úteis porque podem correr localmente em CPU. A latência e a exatidão dependem do modelo selecionado, da resolução da página, do idioma, do preprocessing e do hardware; por isso, faça benchmark nas mesmas páginas anotadas utilizadas na avaliação dos VLMs.

Tesseract para impressão limpa

O Tesseract (v5.5.x, Apache 2.0) é um engine maduro, sobretudo para CPU, com mais de 100 language packs. A exatidão em impressão limpa pode ser elevada após rasterização e preprocessing adequados, mas a escrita manual, o texto em cenas e os layouts complexos precisam de testes separados. A sua principal vantagem é um deployment local pequeno em CPU. O suporte experimental de OpenCL não demonstra uma vantagem geral de desempenho.

EasyOCR

O EasyOCR combina um detetor CRAFT com um reconhecedor CRNN. Com aceleração completa de GPU através de PyTorch, é uma opção rápida para prototipagem e texto em cenas.

O snippet requer pip install easyocr, PyTorch, os pesos do modelo descarregados pelo EasyOCR e um receipt.jpg local. Está verificado sintaticamente, mas não é executado pelo Markdown runner do repositório.

import easyocr

# Three lines for complete OCR
reader = easyocr.Reader(["en"])
result = reader.readtext("receipt.jpg")
# Returns: [(bbox, text, confidence), ...]

PaddleOCR 3

PaddleOCR 3 inclui pipelines mantidos de OCR, parsing de documentos e deployment. O quick start atual utiliza a API predict() e definições explícitas de orientação. Fixe o pacote paddleocr e o pipeline selecionado, porque os exemplos da versão 2.x que usam .ocr(..., cls=True) não correspondem à API da versão 3.x.

O snippet requer pip install "paddleocr>=3,<4", um runtime PaddlePaddle compatível, pesos do modelo descarregados e um receipt.jpg local. Está verificado sintaticamente, mas não é executado pelo Markdown runner do repositório.

from paddleocr import PaddleOCR

ocr = PaddleOCR(
    use_doc_orientation_classify=False,
    use_doc_unwarping=False,
    use_textline_orientation=False,
)

for result in ocr.predict("receipt.jpg"):
    result.print()
    result.save_to_json("output")

Opções de VLM especializados e gerais

Recibos tortos, etiquetas de produtos inclinadas, escrita manual e layouts densos são os casos em que vale a pena testar VLMs especializados ou gerais contra engines tradicionais.

A nova geração de OCR especializado

A lista de modelos desta secção foi verificada em 2026-09-06. Não constitui uma ordenação atual. Entre os modelos especializados de parsing documental publicados entre 2024 e 2026 incluem-se:

• PaddleOCR-VL 1.6: Um pipeline de duas etapas que executa análise de layout e, em seguida, utiliza um componente VLM de 0.9B nas regiões detetadas. O PaddleOCR reporta 109 idiomas e 96.3 no OmniDocBench v1.6; mantenha esse resultado do fornecedor associado ao pipeline e à versão do benchmark indicados.
• dots.mocr (3B): O rebranding de março de 2026 do dots.ocr-1.5 faz parsing de texto e gráficos estruturados, incluindo uma variante orientada para SVG. O dots.ocr original continua a ser um modelo separado de 2025.
• GOT-OCR 2.0: Um modelo unificado com 580M de parâmetros que emite texto simples e outputs formatados como Markdown e LaTeX. O repositório oficial não publica um valor mínimo de VRAM; meça, por isso, o pico de memória com o runtime, a precisão, o tamanho da imagem e o limite de output escolhidos.
• DeepSeek-OCR2: O checkpoint documentado no repositório oficial à data do snapshot, sucessor do modelo DeepSeek-OCR original da classe 3B que introduziu a “compressão ótica contextual”. Trate os valores de throughput de qualquer geração como específicos do hardware e do dataset.
• Mistral OCR 4.1 (mistral-ocr-4-1): O seu model card data o lançamento de 16 de julho de 2026; o changelog regista a disponibilidade geral a 31 de agosto. Acrescenta confiança por bloco, para além de caixas de parágrafos e labels estruturais. Calibre a confiança contra a correção dos campos antes da aceitação automática. O identificador OCR 3 do material complementar é contexto histórico de execução, não o candidato ou preço atual. Fixe uma versão explícita para comparações; um alias latest pode mudar.
• Granite-Docling 258M: Emite DocTags que podem ser convertidos num DoclingDocument estruturado. O pipeline VLM do Docling tem de ser selecionado explicitamente; um conversor predefinido não prova que este modelo tenha sido executado.
• MinerU e olmOCR: Candidatos, respetivamente, para conversão estruturada e linearização de documentos. Inspecione os respetivos pipelines completos e as licenças dos modelos selecionados. Os termos dos modelos do MinerU acrescentam condições à base Apache 2.0, pelo que a licença da biblioteca, por si só, não determina os direitos de deployment.

VLMs de frontier

Os VLMs gerais são outra opção quando a tarefa combina extração com raciocínio visual ou semântico. Estes candidatos foram verificados em 2026-09-06 e são utilizados no exemplo de gateway abaixo. Constituem uma shortlist inicial, não uma ordenação de OCR:

• Gemini 3.8 Flash (Google): Um modelo multimodal geralmente disponível, com input de imagem e structured outputs. Utilize o seu ID estável ao iniciar uma nova comparação, em vez do exemplo antigo Gemini 3 Flash Preview.
• Claude Sonnet 5 (Anthropic): Uma geração Sonnet mais recente para uma comparação alojada. Teste a fidelidade da transcrição e a extração de campos nos seus próprios documentos; melhorias no raciocínio geral não demonstram exatidão de OCR.
• Qwen3.8-27B (Alibaba): Um modelo vision-language de pesos abertos que pode ser testado através de um gateway ou self-hosted. O seu tamanho de 27B torna-o uma escolha de deployment diferente do anterior Qwen3-VL 8B, que continua a ser um baseline menor útil quando a memória é limitada.

Uma versão mais recente ganha um lugar no conjunto de testes, não uma promoção automática para produção. Compare a correção dos campos, a abstenção, a latência e o custo por documento aceite, utilizando o mesmo protocolo.

Meça a latência por escalão

Meça a latência por página com a resolução real, o batch size, o hardware ou a região do provider e o comprimento do output. Inclua o preprocessing e os retries no total; uma medição apenas do modelo não permite calcular o custo de uma página processada com sucesso.

Métricas: medir o que importa

Escolha uma métrica que corresponda ao tipo de output:

• CER e WER para texto simples. Character e Word Error Rate dependem de escolhas de normalização como maiúsculas/minúsculas, espaços e pontuação; por isso, fixe o protocolo de comparação antes de comparar modelos.
• Field exact match e Field F1 para formulários e recibos. O exact match é binário para um campo; a sua taxa é a fração dos campos avaliados que passam. Reporte separadamente a correção de todos os campos ao nível do documento. Para Field F1, defina o matching de chaves/valores, a normalização, os campos duplicados e em falta e a agregação; um montante correto atribuído à linha errada é um erro.
• TEDS para tabelas. Tree-Edit-Distance-based Similarity compara árvores HTML previstas e de referência, detetando erros estruturais e de conteúdo das células que o CER oculta.
• Comparação da ordem de leitura quando o consumidor precisa de uma única sequência linear. Compare diretamente blocos ou spans ordenados, ou utilize uma métrica sensível à ordem; o OmniDocBench avalia a ordem de leitura separadamente. Caracteres e células de tabela corretos não estabelecem a ordem de uma página com várias colunas.
• ANLS para document VQA. Average Normalized Levenshtein Similarity pontua respostas face a referências aceites. A definição original de ST-VQA atribui 1 − normalized_distance apenas quando a distância é estritamente inferior a 0.5; caso contrário, atribui zero. Usa a melhor pontuação entre as referências aceites e calcula a média entre perguntas. O DocVQA adota ANLS. Fixe a normalização de maiúsculas/minúsculas, espaços e distância do evaluator ao reproduzir uma pontuação. O material complementar pontua strings de páginas completas e inclui o limite 0.5, pelo que a sua variante não corresponde ao protocolo do benchmark.

CER/WER contam substituições, eliminações e inserções divididas pelos caracteres ou palavras de referência. Podem exceder um quando predominam as inserções. Indique se a agregação soma os erros e os comprimentos de referência do corpus ou se calcula a média das pontuações dos documentos. Retenha a página, o bloco, a bounding box, o texto original e o histórico de normalização, para que um campo incorreto possa ser rastreado até à imagem.

Para implementações: jiwer trata CER/WER de raiz, e as implementações de TEDS estão no repositório do OmniDocBench.

Testar VLMs com OpenRouter

O OpenRouter fornece um gateway compatível com OpenAI para modelos de vários providers. Os IDs dos modelos e as funcionalidades suportadas nos requests mudam; verifique-os no catálogo atual do gateway antes de executar o exemplo.

O snippet requer pip install openai, um OPENROUTER_API_KEY, acesso à rede, um receipt.jpg local e IDs de modelos ainda suportados pelo OpenRouter. Está verificado sintaticamente, mas não é executado pelo Markdown runner do repositório.

import base64
import os
from openai import OpenAI

client = OpenAI(
    base_url="https://openrouter.ai/api/v1",
    api_key=os.environ["OPENROUTER_API_KEY"],
)

def extract_text(image_path: str, model: str) -> str:
    with open(image_path, "rb") as f:
        image_b64 = base64.b64encode(f.read()).decode()

    response = client.chat.completions.create(
        model=model,
        messages=[{
            "role": "user",
            "content": [
                {"type": "text", "text": "Extract all text from this image, preserving layout as markdown."},
                {"type": "image_url", "image_url": {"url": f"data:image/jpeg;base64,{image_b64}"}},
            ],
        }],
        max_tokens=4096,
    )
    choice = response.choices[0]
    if choice.finish_reason != "stop":
        raise RuntimeError(f"{model} did not finish: {choice.finish_reason}")
    if not choice.message.content:
        raise RuntimeError(f"{model} returned no text (finish_reason={choice.finish_reason})")
    return choice.message.content

# Compare models by changing one string
models = [
    "google/gemini-3.8-flash",
    "anthropic/claude-sonnet-5",
    "qwen/qwen3.8-27b",
]
for model in models:
    print(f"\n--- {model} ---\n{extract_text('receipt.jpg', model)[:200]}...")

O catálogo de modelos do OpenRouter listava google/gemini-3.8-flash, anthropic/claude-sonnet-5 e qwen/qwen3.8-27b com input de imagem e parâmetros de structured outputs em 2026-09-06. O suporte no catálogo não prova que este request exato funcione em todos os endpoints encaminhados; não foi executada inferência paga nesta atualização.

Para extração estruturada, utilize response_format com um JSON Schema quando o modelo selecionado e o gateway o suportarem. Isto pode tornar a resposta parseável; não valida os valores extraídos contra a imagem. No OpenRouter, provider.require_parameters faz falhar o request quando nenhum endpoint encaminhado suporta todos os parâmetros pedidos, em vez de recorrer a um endpoint que não consiga respeitar o schema. O bloco seguinte repete a configuração para ser legível de forma independente. Continua a exigir pip install openai, um OPENROUTER_API_KEY, acesso à rede, um receipt.jpg local e um modelo que suporte JSON Schema; o runner do repositório apenas faz verificação sintática.

import base64
import json
import os
from openai import OpenAI

with open("receipt.jpg", "rb") as f:
    image_b64 = base64.b64encode(f.read()).decode()

client = OpenAI(
    base_url="https://openrouter.ai/api/v1",
    api_key=os.environ["OPENROUTER_API_KEY"],
)

response = client.chat.completions.create(
    model="google/gemini-3.8-flash",
    messages=[{
        "role": "user",
        "content": [
            {"type": "text", "text": "Extract only visible receipt fields. Copy amounts as source strings. Use null for absent or unreadable values; do not infer them. Use null for an unreadable item list, and [] only when no items are present."},
            {"type": "image_url", "image_url": {"url": f"data:image/jpeg;base64,{image_b64}"}},
        ],
    }],
    max_tokens=4096,
    response_format={
        "type": "json_schema",
        "json_schema": {
            "name": "receipt",
            "strict": True,
            "schema": {
                "type": "object",
                "properties": {
                    "vendor": {"type": ["string", "null"]},
                    "date": {"type": ["string", "null"]},
                    "items": {
                        "type": ["array", "null"],
                        "items": {
                            "type": "object",
                            "properties": {
                                "description": {"type": ["string", "null"]},
                                "amount": {"type": ["string", "null"]},
                            },
                            "required": ["description", "amount"],
                            "additionalProperties": False,
                        },
                    },
                    "total": {"type": ["string", "null"]},
                },
                "required": ["vendor", "date", "items", "total"],
                "additionalProperties": False,
            },
        },
    },
    extra_body={"provider": {"require_parameters": True}},
)

def completed_text(response, label: str) -> str:
    choice = response.choices[0]
    if choice.finish_reason != "stop":
        raise RuntimeError(f"{label} did not finish: {choice.finish_reason}")
    if not choice.message.content:
        raise RuntimeError(
            f"{label} returned no text (finish_reason={choice.finish_reason})"
        )
    return choice.message.content

receipt = json.loads(completed_text(response, "receipt extraction"))

Mantenha as strings dos montantes copiadas juntamente com os valores normalizados. Faça o parsing do dinheiro a jusante com aritmética decimal ou em unidades monetárias mínimas inteiras, sob uma moeda e um locale explícitos; a validade do schema não valida um total de pagamento. Encaminhe para revisão os campos críticos nulos.

Resultados do benchmark: o que os números mostram realmente

A tabela abaixo é um snapshot versionado: OmniDocBench v1.6_full, README oficial no commit 09ba2b606662695b16aafe5f5e36b7ef020e11a8, publicado em 2026-04-10 e consultado em 2026-08-09. Todas as quatro linhas provêm dessa tabela fixada. A tabela não combina valores de tabelas de artigos anteriores nem de outras leaderboards.

A conclusão está limitada a esta versão do OmniDocBench: o tamanho do modelo, por si só, não prevê a pontuação de parsing documental. O OmniDocBench registou posteriormente a v1.7 e a integração com o EvalScope. Alterações no matching entre previsões e referências podem alterar as pontuações mesmo com output idêntico do modelo. Preserve as linhas históricas acima; compare novas execuções apenas com um evaluator fixado. O valor composto inclui distância de edição de texto, TEDS de tabelas e CDM de fórmulas; a ordem de leitura precisa do seu resultado separado.

O material complementar calcula métricas ilustrativas em cinco amostras. Corrija a identidade do pipeline, as referências de reconhecimento, o tratamento das falhas, os nomes dos modelos, o protocolo das métricas e os pressupostos de custo antes de interpretar qualquer linha como evidência comparativa.

Fazer deployment de OCR em produção

Uma arquitetura por escalões pode separar o preprocessing em CPU da inferência em GPU ou através de API e reservar os percursos dispendiosos para os documentos que deles necessitam.

Nota sobre orquestração: Ferramentas como o Docling podem coordenar conversão e processamento em batch. A política de retry continua a pertencer à aplicação ou ao serviço envolvente, e o routing continua a precisar de labels e thresholds de qualidade próprios.

O padrão de fallback por escalões

Comece pelo percurso mais barato que atinja o objetivo de qualidade e, em seguida, calibre o routing em páginas anotadas:

0. Verifique se existe texto incorporado (Escalão 0). Para PDFs, inspecione a camada de texto com PyMuPDF ou pdfplumber antes de rasterizar, mas valide que a camada está completa e corretamente ordenada.
1. Tente com um modelo rápido. Utilize um engine tradicional para as classes de documentos em que atinge o objetivo.
2. Avalie a confiança calibrada. Combine a confiança do modelo com a classe do documento, a criticidade do campo e as regras de validação.
3. Escale para um modelo mais forte. Encaminhe as páginas incertas para um VLM especializado ou geral.
4. Escale as falhas de elevado risco para uma pessoa. A revisão humana é um escalão separado para valores cujo custo do erro exceda o benefício da automação.

Nota sobre confiança: As probabilidades brutas dos caracteres não estão automaticamente calibradas para a correção dos campos. A função ponderada pela área abaixo é um baseline para agregação ao nível da página, não um router universal. Calibre-a contra páginas anotadas e dê regras próprias aos campos críticos, porque uma média da página pode esconder um ID ou total incorreto.

def area_weighted_confidence(page):
    """Compute area-weighted confidence from one PaddleOCR 3.x result."""
    total_area, weighted_sum = 0, 0
    for (x_min, y_min, x_max, y_max), score in zip(
        page["rec_boxes"], page["rec_scores"]
    ):
        width = int(x_max) - int(x_min)
        height = int(y_max) - int(y_min)
        area = width * height
        weighted_sum += score * area
        total_area += area
    return weighted_sum / total_area if total_area > 0 else 0

assert area_weighted_confidence({
    "rec_boxes": [[0, 0, 300, 300]], "rec_scores": [0.5]
}) == 0.5

Para cada par engine/documento planeado, retenha um resultado com estado de sucesso, erro ou ignorado. Outputs falhados, vazios e truncados continuam no denominador de documentos tentados, juntamente com o custo já incorrido. Reporte a taxa de conclusão, os erros em campos críticos entre as aceitações automáticas, a fração de revisão, a latência end-to-end p50/p95 e o custo por documento processado com sucesso. Reutilize objetos de conversão para medições em warm state e registe separadamente a inicialização.

Análise de custos à escala

Não existe um ponto de break-even universal, em volume de páginas, entre uma API e o self-hosting. Construa a comparação a partir da mesma carga de trabalho:

Utilize uma fórmula partilhada: monthly pages × cost per successful page + review cost + fixed operating cost. Uma “página bem-sucedida” tem de cumprir os mesmos critérios de texto, tabela e campos em ambos os percursos. Os preços dos providers e os alugueres de GPU mudam demasiado depressa para serem incorporados numa estimativa duradoura de procurement.

Tratamento de erros: o problema das alucinações

Os erros dos VLM podem ser plausíveis no contexto e, ainda assim, factualmente incorretos. Um total de recibo de “$42.50” pode tornar-se “$45.20”: sintaticamente válido, mas invisível para um spell-checker.

Exemplo de falha sintética: Um VLM extrai três linhas de itens de um recibo e um total indicado que são coerentes entre si, mas um dígito difere da imagem. A aritmética interna passa, embora a extração esteja errada. É por isso que a validação precisa de labels ancorados na imagem ou de um percurso de revisão independente, não apenas de verificações de consistência.

Algumas mitigações práticas:

• Reconciliação aritmética. Quando o schema os expõe, verifique subtotal + tax + fees + shipping - discounts, dentro da tolerância de arredondamento da moeda, contra o total indicado. Encaminhe para revisão os componentes em falta ou as discrepâncias.
• Verificações de sanidade com regex para datas (sem mês 13), números de telefone (número correto de dígitos) e formatos monetários.
• Verificação cruzada entre modelos. Faça passar os campos críticos por dois modelos diferentes e assinale divergências.
• Verificação cruzada com OCR independente. Execute um segundo percurso de extração sobre os valores críticos e assinale divergências. A concordância aumenta a confiança apenas quando os dois percursos têm modos de falha suficientemente diferentes; não constitui prova de correção.

Principais conclusões

1. Associe o escalão do modelo a uma classe de documentos anotada. Os engines tradicionais podem ser suficientes para texto limpo; os VLM especializados e gerais devem justificar o custo adicional em páginas mais difíceis.
2. Não combine leaderboards diferentes. As métricas do OmniDocBench e as preferências do OCR Arena respondem a perguntas diferentes.
3. Calibre o routing. Thresholds de confiança, classes de documentos, criticidade dos campos e política de revisão humana pertencem à mesma avaliação.
4. Valide outputs plausíveis. A conformidade com o schema e a aritmética interna não conseguem provar que um valor aparece na imagem.
5. Calcule o custo de páginas bem-sucedidas. Inclua retries, revisão, operações fixas e verificações de qualidade ao comparar APIs com self-hosting.

O preprocessing e a deteção continuam a ser importantes, mas o OCR em produção exige agora também routing, avaliação específica da tarefa e defesas contra erros de extração plausíveis.

Referências

• OCR Arena Leaderboard - Batalhas de modelos frente a frente, baseadas em crowdsourcing
• The OCR Gauntlet repo - Notebooks executáveis para comparar engines de OCR, inspecionar output do Docling e estimar custos
• OmniDocBench - Avaliação end-to-end de parsing documental
• dots.ocr - Cerca de 3B de parâmetros no total, incluindo um modelo de linguagem de 1.7B
• PaddleOCR - Toolkit e modelos tradicionais de OCR
• OpenRouter - Gateway de acesso unificado para testes A/B de modelos