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

Viacheslav Dubrov

2026-03-04 · Atualizado 2026-08-10 · 15 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.

As tabelas de classificação de OCR não coincidem porque testam documentos, outputs e avaliadores diferentes. Um snapshot do início de 2026 do OmniDocBench e do OCR Arena produziu ordenações de modelos bastante 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 do workload real.

Os vision-language models (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 nítida, 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. Verifique cada projeto antes de tomar uma decisão atual.

Repositório complementar: The OCR Gauntlet contém três notebooks. O notebook principal compara até cinco engines de OCR em cinco amostras descarregadas e apresenta CER, WER, ANLS, latência e custo estimado. A execução incluída no repositório contém Tesseract, Docling + Tesseract, Mistral OCR v3 e uma execução com Gemini; dots.ocr não estava disponível. Não utilize a linha do Gemini para comparar modelos: o runner solicita gemini-2.5-flash, mas o notebook incluído identifica esse output como Gemini 3 Flash.

Este guia destina-se a engenheiros que escolhem um pipeline de OCR ou de document AI para workloads reais em que o texto, o layout, as tabelas ou os campos extraídos são importantes.

Depois de o ler, deverá conseguir escolher uma baseline, comparar modelos com métricas específicas da tarefa e encaminhar campos incertos ou de alto risco para validação ou revisão.

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

Para uma versão compacta sobre seleção de modelos, consulte Melhores modelos de OCR em 2026: OCR clássico, PaddleOCR-VL, VLMs.

O OCR define agora a qualidade a jusante

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

A qualidade de recuperação do seu sistema de RAG está limitada pela qualidade do OCR. Se a extração baralhar uma tabela, interpretar mal uma data ou omitir um parágrafo, alterações posteriores ao chunking e ao embedding 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.

Por isso, o OCR faz parte da infraestrutura de recuperação e de agentes, juntamente com o parsing, o chunking, o embedding e a 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 presente numa imagem em caracteres legíveis por máquina. Document AI é o sistema mais amplo que o envolve: 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 dessas 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 language model.

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

O OCR-2.0 funde uma parte maior desse pipeline num vision encoder e num language decoder. Modelos como o GOT-OCR 2.0 conseguem emitir texto e estrutura em conjunto, enquanto os VLMs gerais também podem mapear campos para um schema solicitado. Os compromissos dependem do workload: latência, custo de GPU ou de API e risco de produzir texto plausível que não existe na imagem.

Uma ressalva prática: não se deixe enganar pelo rótulo «end-to-end». Em produção, o OCR-2.0 unifica a inferência do modelo, não todo o pipeline documental. Continua a precisar de rasterização de PDF para produzir imagens, normalização de imagem (deskew, ajuste de DPI) para obter uma qualidade consistente e parsing do output para extrair campos estruturados do texto do modelo. O pipeline ficou mais curto, não desapareceu.

O que os benchmarks de OCR medem — e o que deixam de fora

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

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 são diferentes.

No OCR Arena, os utilizadores votam anonimamente em outputs apresentados frente a frente. Em 2026-08-09, a ordenação em tempo real colocava o Gemini 3 Flash acima do GLM-OCR e do DeepSeek-OCR, enquanto a tabela versionada do OmniDocBench, apresentada mais à frente neste artigo, classificava os modelos especializados em documentos acima do Gemini 3 Flash. Os resultados da arena mudam após novos confrontos, pelo que a ordenação é evidência direcional e não um snapshot de benchmark reproduzível. As duas leaderboards não devem ser combinadas numa única pontuação, porque uma utiliza métricas de dataset e a outra votos de preferência.

Entre os fatores prováveis estão a combinação 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 triagem inicial, mas a seleção final precisa de um conjunto de validação separado proveniente do workload-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 nítidos.

Os engines tradicionais são baselines úteis porque podem ser executados 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 o benchmark nas mesmas páginas anotadas utilizadas na avaliação dos VLMs.

Tesseract para impressão nítida

O Tesseract (v5.5.x, Apache 2.0) é um engine maduro, apenas para CPU, com mais de 100 language packs. A exatidão em impressão nítida pode ser elevada após uma rasterização e um 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, e não uma liderança universal em exatidão.

EasyOCR

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

O snippet requer pip install easyocr, PyTorch, os pesos de modelo descarregados do EasyOCR e um receipt.jpg local. Foi verificada apenas a sintaxe; não foi executado pelo runner de Markdown 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

O PaddleOCR 3 reúne pipelines mantidos de OCR, parsing documental 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 utilizam .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 de modelo descarregados e um receipt.jpg local. Foi verificada apenas a sintaxe; não foi executado pelo runner de Markdown 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 especializadas e gerais

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

A nova vaga de OCR especializado

A lista de modelos desta secção corresponde ao snapshot verificado em 2026-08-09. Não é uma ordenação atual. Entre os modelos especializados de parsing documental publicados entre 2024 e 2026 encontram-se:

• PaddleOCR-VL 1.6: Um pipeline em duas etapas que realiza a análise de layout e utiliza depois um componente VLM de 0.9B nas regiões detetadas. O PaddleOCR indica 109 idiomas e uma pontuação de 96.3 no OmniDocBench v1.6; associe esse resultado do fornecedor ao pipeline identificado e à versão do benchmark.
• dots.mocr (3B): O sucessor, lançado em março de 2026, do dots.ocr-1.5 analisa 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; por isso, meça a memória de pico 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 na 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 uma das gerações como específicos do hardware e do dataset.
• Mistral OCR 4.0 (mistral-ocr-4-0), snapshot de 2026-08-09: O serviço proprietário de extração de texto e estrutura documentado pela Mistral. O OCR 3 (mistral-ocr-2512) continua disponível para integrações existentes e é a versão utilizada pelo notebook complementar. O notebook utiliza deliberadamente o OCR 3 para garantir a reprodutibilidade, não por o OCR 3 ser mais recente. Os preços e os números dos benchmarks mudam; consulte o model card atual e os termos do fornecedor quando os comparar.

VLMs de fronteira

Os VLMs gerais são outra opção quando a tarefa combina extração com raciocínio visual ou semântico. Os exemplos abaixo refletem o snapshot do início de 2026 apresentado no artigo, e não uma ordenação atual:

• Qwen3-VL (Alibaba): Uma família de VLMs com open weights, vários tamanhos e variantes com contexto longo.
• Gemini 3 Flash (Google): Um modelo multimodal alojado que obteve uma classificação elevada no snapshot citado do OCR Arena.
• Claude Opus 4.6 (Anthropic): Um VLM geral alojado com suporte para structured outputs.
• GPT-5.2 (OpenAI): Um VLM geral alojado para inputs visuais e textuais combinados.

Meça a latência por nível

Meça a latência por página com a resolução real, o tamanho do batch, o hardware ou a região do fornecedor e o comprimento do output. Inclua o preprocessing e as tentativas repetidas 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 opções de normalização como maiúsculas e minúsculas, espaços e pontuação; por isso, fixe o protocolo de comparação antes de comparar modelos.
• EMR e Field F1 para formulários e recibos. A Exact Match Rate é binária, que é precisamente o que pretende para números de identificação fiscal e totais. A Field F1 equilibra precision e recall por tipo de campo.
• TEDS para tabelas. A Tree-Edit-Distance-based Similarity compara as árvores HTML prevista e de referência, detetando erros estruturais e de conteúdo das células que o CER não revela.
• ANLS para document VQA. A Average Normalized Levenshtein Similarity atribui crédito parcial a respostas com pequenos erros de OCR.

Para implementações: jiwer trata CER/WER out of the box, e as implementações de TEDS encontram-se no repositório do OmniDocBench.

Testar VLMs com OpenRouter

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

O snippet requer pip install openai, uma OPENROUTER_API_KEY, acesso à rede, uma receipt.jpg local e IDs de modelos ainda suportados pelo OpenRouter. Foi verificada apenas a sintaxe; não foi executado pelo runner de Markdown 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,
    )
    return response.choices[0].message.content

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

Estes IDs de modelos foram verificados no catálogo do OpenRouter em 2026-08-09. Consulte novamente o catálogo antes de executar o exemplo.

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 parseable; não valida os valores extraídos face à imagem. O bloco seguinte repete a configuração para ser legível de forma independente. Continua a requerer pip install openai, uma OPENROUTER_API_KEY, acesso à rede, uma receipt.jpg local e um modelo que suporte JSON Schema; o runner do repositório apenas verifica a sintaxe.

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-flash-preview",
    messages=[{
        "role": "user",
        "content": [
            {"type": "text", "text": "Extract the receipt fields from this image."},
            {"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"},
                    "date": {"type": "string"},
                    "items": {
                        "type": "array",
                        "items": {
                            "type": "object",
                            "properties": {
                                "description": {"type": "string"},
                                "amount": {"type": "number"},
                            },
                            "required": ["description", "amount"],
                            "additionalProperties": False,
                        },
                    },
                    "total": {"type": "number"},
                },
                "required": ["vendor", "date", "items", "total"],
                "additionalProperties": False,
            },
        },
    },
)
receipt = json.loads(response.choices[0].message.content)

Resultados dos benchmarks: 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. 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 notebook complementar calcula CER, WER, ANLS, latência e custo estimado nas cinco amostras descarregadas. Exclua a linha incorretamente identificada do Gemini, a menos que a identidade do modelo seja corrigida e as amostras sejam executadas novamente.

Colocar OCR em produção

Uma arquitetura por níveis pode separar o preprocessing em CPU da inferência em GPU ou por API e reservar os caminhos dispendiosos para os documentos que deles necessitam.

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

O padrão de fallback por níveis

Comece pelo caminho mais barato que atinge o nível de qualidade pretendido e, em seguida, calibre o routing em páginas anotadas:

0. Verifique se existe texto incorporado (Nível 0). Nos PDFs, inspecione a camada de texto com PyMuPDF ou pdfplumber antes de rasterizar, mas valide se 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. Encaminhe as falhas de alto risco para uma pessoa. A revisão humana é um nível separado para valores cujo custo do erro ultrapassa o benefício da automação.

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

def area_weighted_confidence(page):
    """Compute area-weighted confidence from a 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"]
    ):
        area = (x_max - x_min) * (y_max - y_min)
        weighted_sum += score * area
        total_area += area
    return weighted_sum / total_area if total_area > 0 else 0

Análise de custos à escala

Não existe um ponto de equilíbrio universal, em termos de volume de páginas, entre uma API e o self-hosting. Construa a comparação a partir do mesmo workload:

Utilize uma fórmula comum: monthly pages × cost per successful page + review cost + fixed operating cost. Uma «página processada com sucesso» tem de cumprir os mesmos critérios de texto, tabela e campos em ambos os caminhos. Os preços dos fornecedores e o aluguer de GPUs mudam demasiado depressa para serem incorporados numa estimativa de procurement duradoura.

Tratamento de erros: o problema das alucinações

Os erros dos VLMs podem ser plausíveis no contexto e estar factualmente errados. Um total de recibo «$42.50» pode transformar-se em «$45.20»: sintaticamente válido, mas invisível para um corretor ortográfico.

Exemplo de falha sintética: Um VLM extrai três itens de uma linha de recibo e um total indicado que são coerentes entre si, mas um algarismo 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 caminho de revisão independente, e 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, face ao total indicado. Encaminhe componentes em falta ou discrepâncias para revisão.
• Verificações de sanidade com regex para datas (sem mês 13), números de telefone (número correto de algarismos) e formatos de moeda.
• Verificação entre modelos. Faça passar os campos críticos por dois modelos diferentes e assinale as discordâncias.
• Verificação cruzada independente de OCR. Execute um segundo caminho de extração para os valores críticos e assinale as discordâncias. A concordância aumenta a confiança apenas quando os dois caminhos têm modos de falha suficientemente diferentes; não é prova de correção.

Principais conclusões

1. Associe o nível do modelo a uma classe de documentos anotada. Os engines tradicionais podem ser suficientes para texto nítido; os VLMs especializados e gerais devem justificar o custo adicional em páginas mais difíceis.
2. Não combine leaderboards incompatíveis. 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 devem fazer parte da 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 processadas com sucesso. Inclua retries, revisão, operações fixas e quality gates 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, com crowdsourcing
• Repositório The OCR Gauntlet - Notebooks executáveis para comparar engines de OCR, inspecionar o 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 language model de 1.7B
• PaddleOCR - Toolkit e modelos de OCR tradicional
• OpenRouter - Gateway de acesso unificado para testes A/B de modelos