docTR vs Docling em Notas Fiscais
Velocidade em Passagem Única vs Pipeline de Documentos (2026)

O que o Docling é (e o que não é): OCR de Passo Único vs. Pipeline de Análise

Os dois motores estão em lados opostos de uma divisão arquitetônica fundamental, e essa divisão — não uma diferença de código ou de ajuste — é toda a história desta página. docTR é um motor de OCR neural de passo único: uma etapa de detecção localiza as caixas delimitadoras do texto e uma etapa de reconhecimento transcreve os caracteres dentro delas, compostos em um único preditor de OCR cuja passagem direta produz linhas de texto brutas. Não há modelo de layout, nem analisador de tabelas, nem reconstrução de ordem de leitura — o que está impresso é o que sai, na ordem em que o reconhecedor o lê. Docling não é um motor de OCR nem um modelo de visão-linguagem; é um pipeline de análise de documentos. De acordo com seu próprio relatório técnico (citado para contexto arquitetônico, não para qualquer número nesta página), ele executa uma sequência de modelos por página — análise de layout, detecção de tabelas, inferência de ordem de leitura — os agrega e monta um objeto de documento intermediário antes de emitir o texto, razão pela qual sua saída carrega estrutura (rótulos, ordem, zonas) que as linhas do docTR não têm.

Por que esse mecanismo importa para um benchmark: cada modelo em etapas na cadeia do Docling existe para explorar a estrutura do layout — uma tabela para analisar, um formulário de duas colunas, um caminho de leitura que não é a ordem lexical. Um recibo em inglês simples quase não tem nada disso: coluna única, algumas zonas, um caminho de cima para baixo previsível, sem tabelas. A maquinaria em etapas ainda é executada em cada página — é por isso que é mais lenta e custosa — mas sem estrutura para explorar, a sobrecarga não se converte em texto melhor. Esta página isola exatamente esse custo e mostra o que ele compra — e o que não compra.

Precisão de Caracteres: O Custo do Pipeline no Texto Bruto

No SROIE 2019, a lacuna no texto bruto não é pequena: CER 0.1971 vs 0.5909 (Docling) — uma penalidade de 3,0× — e WER 0.3199 vs 0.7596. A Taxa de Erro de Caracteres mede inserções, exclusões e substituições divididas pelos caracteres do texto de referência — um CER de 0,197 significa ~19,7 caracteres mal lidos a cada 100; a Taxa de Erro de Palavras aplica a mesma lógica de distância de edição em granularidade de palavras. O 0,5909 do Docling ocupa a 7ª posição entre 8 mecanismos na execução subjacente, à frente apenas do Unlimited-OCR (0,6552, coluna cer do summary_metrics.csv, todas as linhas sroie_2019) — o confronto direto docTR-vs-Surya2 documentou o docTR como um dos dois melhores reconhecedores neste mesmo benchmark, e esta página mostra que o mesmo mecanismo na outra extremidade da tabela de precisão de texto é um pipeline, não uma família de reconhecedores mais fraca.

Fonte: summary_metrics.csv — colunas cer e wer, linhas sroie_2019. docTR cer 0,19707 / wer 0,31990; Docling cer 0,59092 / wer 0,75961. Menor é melhor. 361 amostras por mecanismo; ambos com error_rate 0,0.

Tabela: summary_metrics.csv — colunas cer / wer / error_rate, linhas sroie_2019. Valores exatos: docTR cer 0,19707 / wer 0,31990; Docling cer 0,59092 / wer 0,75961. O CER do Docling no SROIE é o segundo pior dos oito mecanismos na execução subjacente (à frente apenas do 0,6552 do Unlimited-OCR) — a precisão bruta de caracteres é onde o custo do pipeline aparece primeiro.

A Inversão: Extração de Campos por Regex Inverte o Resultado

Avalie o texto de ambos os motores pelos mesmos padrões regex fixos nos quatro campos de recibos SROIE (empresa, data, endereço, total) — a abordagem tradicional de OCR + extração de informações-chave baseada em regras (KIE) — e a classificação se inverte: Docling extrai campos com 0.2237 campo F1 contra 0.0766 do docTR, uma vantagem de 2.9×. Estas são as métricas postprocessed_sroie_receipt_regex_* do benchmark: padrões fixos aplicados ao texto OCR de cada motor — pós-processado, não a saída estruturada nativa de nenhum dos motores, e o modelo de documento nativo do Docling não é avaliado aqui.

O F1 de valor de campo é a média harmônica de precisão e recall sobre os valores dos campos extraídos em relação à verdade fundamental — 1.0 significa que todos os campos do recibo foram perfeitamente recuperados, 0 significa nada. O mecanismo por trás da inversão é a mesma diferença de arquitetura que causou a lacuna de CER, atuando na direção oposta: o modelo de documento do Docling reordena o texto em um caminho de leitura e associa rótulos a valores, então seu texto emitido é mais próximo em formato do que os padrões fixos esperam; o texto de linhas limpo-mas-bruto do docTR — preciso por CER, mas com caixa original e ruído de separador e sem enquadramento de rótulo — derrota os padrões. O F1 de campo por regex de 0.0766 do docTR é o pior de todos os oito motores na execução subjacente, apesar de seu CER de melhor classe (colunas field_f1_regex e cer do summary_metrics.csv, todas as linhas sroie_2019); o 0.2237 do Docling fica em sexto lugar. O mesmo desacoplamento documentado no confronto direto no topo da escala de precisão (docTR vs Surya2) se repete aqui na base: precisão de texto não é precisão de campo.

Fonte: field_method_comparison.csv — colunas regex_field_value_f1 / llm_field_value_f1, linhas sroie_2019 (decimais de 0–1 mostrados como %). Pós-processador LLM: deepseek-v4-flash (coluna llm_model). 361 amostras por motor (llm_ok_count).

Tabela: field_method_comparison.csv — colunas regex, linhas sroie_2019. Estas são métricas postprocessed_sroie_receipt_regex_*: padrões fixos aplicados ao texto OCR de cada engine, não extração estruturada nativa. Nenhuma engine acerta todos os quatro campos exatamente via regex em qualquer único recibo SROIE (0.0000, um zero literal registrado no CSV). O F1 de campos por regex do docTR de 0.0766 é o mais baixo de todas as oito engines na execução subjacente.

Pós-processamento por LLM Restaura o Ranking — Parcialmente

Alimente o texto de ambas as engines a um pós-processador LLM (deepseek-v4-flash com temperatura 0) com um prompt de extração estruturada, e o docTR retoma a liderança: F1 de campo 0.6171 vs 0.5685 — uma margem de 0,049 ponto, pequena comparada à lacuna bruta de CER, mas não apagada. O texto base mais limpo revela mais valores de campo recuperáveis; o LLM compensa parcialmente os artefatos de layout do Docling, mas não os elimina.

Esta é a mesma banda de convergência vista no benchmark completo de oito engines — o pós-processamento por LLM aproxima engines saudáveis porque entende semântica (números, datas, nomes) em vez de combinar formas de caracteres — e a lacuna residual importa: o 0.6171 do docTR é o melhor F1 de campo por LLM de todas as oito engines, enquanto o 0.5685 do Docling fica em sexto lugar (field_method_comparison.csv llm_field_value_f1, todas as linhas sroie_2019). A barra mais exigente — documentos onde todos os quatro campos coincidem exatamente — os separa por 2,7×: docTR 0.1496 vs Docling 0.0554. Dois custos vêm com a alavanca: uma chamada de LLM adiciona ~2,0–2,4 s de latência mediana por documento além do tempo de OCR (1.996,3 ms para o texto do docTR, 2.365,1 ms para o do Docling — incorridos via API e idênticos em natureza), e ele não pode resgatar texto que uma engine falhou fundamentalmente em ler.

Tabela: field_method_comparison.csv — colunas llm_*, linhas sroie_2019. Modelo LLM: deepseek-v4-flash com temperatura 0 (coluna llm_model). A latência LLM é causada pela API e separada da latência do motor (coluna latency_p50_ms em summary_metrics.csv). Ambas as linhas foram concluídas com llm_ok_count 361.

A Envelope de Operação: 6,7× Latência, 7,9× Throughput, 8,3× Custo

O imposto do pipeline é mais pesado onde o planejamento de throughput vive. No mesmo RTX 4090 com a mesma taxa registrada de $0,76/hr, o docTR sustenta 449,3 páginas/min com 108,7 ms p50 por página por $0,048 por 1.000 páginas; o Docling sustenta 56,7 páginas/min com 732,0 ms p50 por $0,398 por 1.000 páginas — uma diferença de latência de 6,7×, uma diferença de throughput de 7,9× e uma diferença de custo de 8,3×. A cauda é proporcionalmente pior para o pipeline: p95 281,4 ms vs 3.239,8 ms, uma diferença de 11,5×, porque os modelos em estágios do Docling combinam seus piores tempos de execução página a página.

O custo é calculado como tempo de execução em relógio de parede × a taxa do RunPod RTX 4090 ($0,76/hora, preço com carimbo de data nos manifests de execução), incluindo a inicialização do modelo — o preço que você realmente pagaria pelo tempo de GPU. O throughput são páginas por minuto em relógio de parede, incluindo essa mesma inicialização. A latência p50/p95 são tempos de inferência por página em estado estável, medidos em modo aquecido-então-pontuado (excluindo o carregamento do modelo). O docTR é o motor mais rápido e mais barato de todos os oito na execução subjacente no SROIE; o Docling, com 56,7 páginas/min e $0,398 por 1.000 páginas, fica na metade inferior da tabela da envelope de operação (summary_metrics.csv, colunas latency_p50_ms / pages_per_minute / cost_per_1000_pages, todas as linhas sroie_2019).

Fonte: summary_metrics.csv — colunas latency_p50_ms / latency_p95_ms, linhas sroie_2019. docTR p50 108,72 / p95 281,38; Docling p50 732,00 / p95 3239,79. Latência em estado estável (modo de medição warm_then_scored, exclui carregamento do modelo).

Fonte: summary_metrics.csv — coluna cost_per_1000_pages, linhas sroie_2019. docTR 0,0479, Docling 0,3978. Custo = tempo de execução em relógio de parede × $0,76/hr incluindo init do modelo, preço com carimbo de data nos manifests de execução (agosto de 2026). O docTR é o motor mais barato dos oito na execução subjacente.

Tabela: summary_metrics.csv — latency_p50_ms / latency_p95_ms / pages_per_minute / cost_per_1000_pages, linhas sroie_2019. Ambos os motores em GPU (RTX 4090, preço de $0.76/hr com timestamp nos manifests); custo inclui inicialização do modelo. Valores exatos: docTR p50 108.72 / p95 281.38 / 449.31 pg/min / $0.0479; Docling p50 732.00 / p95 3239.79 / 56.66 pg/min / $0.3978.

CORD (Recibos Indonésios): Ambos Colapsam, a Recuperação de Campos por LLM do docTR Ainda Lidera

Nenhum dos motores foi treinado predominantemente em recibos indonésios, então o CORD v2 (100 amostras, campos aninhados menu/sub_total/total) funciona como um teste de estresse entre idiomas — e ambos colapsam no CER bruto: 0.9101 (docTR) e 0.9219 (Docling), um empate por incompatibilidade de idioma. De acordo com o protocolo de benchmark, os números do CORD são mantidos isolados da comparação com SROIE — nunca mesclados em qualquer ranking — porque o texto de referência do CORD incorpora a estrutura de anotação, o que infla o CER bruto para cada motor além da incompatibilidade de idioma genuína.

Nas métricas de campo, a única vantagem preservada do Docling se reduz a quase nada: através de padrões regex, ambos os motores recuperam quase nenhum campo do CORD (docTR 0.0000 — um zero literal no CSV — vs Docling 0.0612, porque os padrões de formato em inglês nunca foram escritos para texto indonésio). O pós-processador LLM absorve o choque de idioma em ambos os lados, mas mantém o docTR na frente: F1 de campo 0.5500 vs 0.4695. O CORD é citado aqui para contexto de robustez de idioma; ele é deliberadamente nunca agrupado com os números do SROIE em um único leaderboard.

Tabela: summary_metrics.csv (cer / cost_per_1000_pages / pages_per_minute) e field_method_comparison.csv (field F1), linhas cord_v2. Não mescle os números do CORD em qualquer ranking SROIE: o CER do CORD combina incompatibilidade genuína de idioma com inflação de estrutura de anotação no ground truth, e os padrões regex foram escritos para formatos em inglês. O field F1 do regex CORD do docTR de 0.0000 é um zero literal registrado no CSV, não um valor ausente.

Quem Vence Quando: O Resumo Comparativo

“Melhor” depende da carga de trabalho, e esta comparação direta separa os eixos claramente: em um recibo em inglês simples, todos os eixos de velocidade/custo e de texto bruto favorecem docTR; a inversão de regex de campo fora da caixa favorece Docling; um pós-processador LLM os traz de volta a uma vantagem de 0,049 pontos para docTR; e as capacidades para as quais Docling existe — layout, tabelas, ordem de leitura, documentos longos — não são medidas aqui, não são refutadas.

Perguntas Frequentes

O Docling é mais preciso que o docTR em recibos?

Não — na precisão bruta de caracteres, o docling é 3,0× pior: CER do SROIE 0,5909 vs 0,1971, e WER 0,7596 vs 0,3199 (summary_metrics.csv, cer / wer, sroie_2019 rows). O Docling “vence” em apenas um eixo medido: extração de campos com regex pronta para uso (0,2237 vs 0,0766 field F1) — e um pós-processador LLM reverte isso para o docTR (0,6171 vs 0,5685).

Por que o Docling extrai campos melhor com regex, apesar do texto bruto muito pior?

Porque as duas métricas avaliam coisas diferentes, e o formato de saída do Docling acaba se encaixando nos padrões. O pipeline de documentos do Docling reordena o texto em um caminho de leitura e associa rótulos a valores, de modo que seu texto emitido está estruturalmente mais próximo do que os padrões regex fixos esperam; o docTR emite texto de linha bruto limpo, que é preciso pelo CER, mas derrota os padrões (0,0766 field F1, o pior dos oito motores, contra um CER de melhor classe). Estas são as pontuações postprocessed_sroie_receipt_regex_* — texto OCR processado por padrões fixos — não saída estruturada nativa (field_method_comparison.csv, regex_field_value_f1, sroie_2019 rows). O mesmo desacoplamento entre precisão de texto ≠ precisão de campo aparece neste benchmark.

Por que o Docling é tão mais lento e custoso por página?

Porque ele executa um pipeline de documentos em etapas — análise de layout, detecção de tabela, reconstrução de ordem de leitura e um modelo de documento intermediário — em cada página, mesmo quando a página é um recibo simples sem estrutura para explorar. No SROIE, esse custo mede 6,7× no p50 (108,7 vs 732,0 ms), 11,5× no p95, 7,9× menor throughput (449,3 vs 56,7 páginas/min) e 8,3× maior custo por 1.000 páginas ($0,048 vs $0,398) — mesma GPU, mesmo protocolo (summary_metrics.csv, sroie_2019 rows).

Um pós-processador LLM fecha a lacuna entre docTR e Docling?

Em grande parte, mas não totalmente: O F1 de campos pós-processado por LLM no SROIE fica em docTR 0.6171 vs Docling 0.5685 — uma vantagem de 0,049 pontos para docTR que sobrevive à compensação parcial do LLM para os artefatos de layout do Docling (field_method_comparison.csv, llm_field_value_f1, linhas sroie_2019). O custo da convergência é ~2,0–2,4 s de latência mediana adicional do LLM por documento (llm_median_latency_ms, mesmas linhas).

Este benchmark significa que o Docling é ruim?

Não — significa que os pontos fortes do Docling não são medidos aqui. Docling é um pipeline de parsing de documentos cuja proposta de valor — estrutura de layout, tabelas, ordem de leitura, formulários, documentos longos — é exatamente o que um benchmark apenas de recibos não pode testar. O que esta página mostra é mais estreito: em um recibo simples de uma página, a sobrecarga do pipeline não se justifica (3,0× pior CER, 8,3× custo), e sua única vantagem medida (2,9× F1 de campos por regex) é apagada por um pós-processador LLM. A formulação honesta é escopo, não veredicto.

Por que ambos os motores pontuam tão mal nos recibos do CORD?

Duas causas combinadas que o protocolo mantém separadas do ranking do SROIE: uma incompatibilidade genuína de idioma (recibos indonesianos fora do foco de treinamento de ambos os motores) e inflação na estrutura de anotação dentro do texto ground-truth do CORD — o CER fica em 0.9101 (docTR) e 0.9219 (Docling) (summary_metrics.csv, cer, linhas cord_v2). Com um pós-processador LLM, o F1 de campos do docTR se mantém em 0,5500 vs 0,4695 do Docling — a ordenação do SROIE, comprimida. As linhas do CORD são citadas e nunca agrupadas em um ranking combinado.

Qual engine um pipeline de recibos deve escolher, docTR ou Docling?

Para alto volume de texto de recibos com custo mensurado, a envelope do docTR é decisiva: 108,7 ms p50, 449,3 páginas/min, $0,048 por 1.000 páginas — o engine mais rápido e barato na corrida subjacente de oito engines. Se seu pipeline consome texto estruturado pronto sem qualquer pós-processador, a vantagem de campos regex do Docling (0,2237 vs 0,0766) é uma vantagem real inicial. Se o pós-processamento por LLM faz parte do design, o docTR continua à frente por 0,049 e é mais barato de alimentar. Se sua carga de trabalho é documentos com muitos layouts — tabelas, formulários, relatórios longos — este benchmark não é a evidência certa para a decisão; ele mede apenas recibos (veja Limitações).

De onde vêm os números nesta página?

Cada valor é uma linha dos CSVs publicados do benchmark de primeira parte — results/summary_metrics.csv (CER/WER, F1 de campo regex, latência, custo, throughput) e results/field_method_comparison.csv (regex vs pós-processamento por LLM, llm_model = deepseek-v4-flash) — hospedados em ImageToTableai/benchmark-ocr, com um manifest.json censurado por execução para impressões digitais do ambiente. As definições dos conjuntos de dados vêm dos artigos SROIE 2019 e CORD citados abaixo.

Metodologia & Fontes

Protocolo

Esta página relata um recorte direto de uma execução de benchmark independente e reproduzível (nível oficial) — não uma pesquisa de alegações de terceiros, e não uma página de comparação de fornecedores. Apenas divisões de teste fixas: SROIE 2019 teste (361 recibos em inglês, campos simples empresa/data/endereço/total) e CORD v2 teste (100 recibos indonésios, campos aninhados menu/sub_total/total); divisões de treinamento nunca foram avaliadas. Ambos os engines viram as mesmas imagens, a mesma verdade de terreno e o mesmo protocolo de medição (warm_then_scored: uma passagem de aquecimento fixa precede a passagem pontuada, para que os valores de latência sejam em regime permanente). Ambas as execuções foram concluídas com error_rate 0,0 em ambos os conjuntos de dados (coluna error_rate do summary_metrics.csv). A execução subjacente contém oito engines no total; esta página compara apenas os dois engines nomeados, com outros engines citados apenas como contexto de classificação. Os resultados completos dos 8 engines são publicados separadamente em Traditional OCR vs Document Parsing VLMs.

Ambiente de Execução

• Hardware: ambos os motores rodaram na mesma NVIDIA RTX 4090 (24 GB); custo da GPU calculado na taxa sob demanda do RunPod de $0.76/hr, preço com carimbo de data/hora no manifesto redatado de cada execução (agosto de 2026).
• Motores: prontos para uso, sem ajuste fino. Versões travadas: docTR v1.0.1 (OCR neural de passagem única — estágio de detecção + estágio de reconhecimento compostos em um único preditor de OCR, GPU) e Docling 2.119.0 (pipeline de análise de documentos — análise de layout, detecção de tabelas, reconstrução de ordem de leitura orquestrados em torno de um núcleo de OCR, GPU) — conforme a tabela de modelos do repositório público (README.md) e os manifestos de execução.
• Pós-processador LLM: deepseek-v4-flash via API com temperatura 0 para saída determinística (a coluna llm_model no field_method_comparison.csv); foi o único modelo usado para todas as linhas de campos LLM em ambos os motores.
• Base de custo: tempo de execução real × $0.76/hr, incluindo inicialização do modelo — o processamento em lote reduz o custo por página.
• Pós-processamento de campos: as métricas de campos regex do SROIE são postprocessed_sroie_receipt_regex_* (colunas regex_* no field_method_comparison.csv) — campos extraídos do texto OCR por um conjunto fixo de padrões. Elas medem OCR + extração downstream, não a saída estruturada nativa de nenhum dos modelos; as colunas LLM_* medem texto OCR + extração por LLM. Os dois pipelines nunca são misturados, e o modelo de documento nativo do Docling não é avaliado por este benchmark.

Definições das Métricas

• CER (Taxa de Erro de Caractere): distância de edição (inserções + exclusões + substituições) entre o texto OCR e o gabarito, dividida pelos caracteres do gabarito. Quanto menor, melhor.
• WER (Taxa de Erro de Palavra): o mesmo cálculo de distância de edição em granularidade de palavra.
• F1 de valor de campo (regex): média harmônica de precisão/recall sobre valores de campos extraídos usando padrões regex fixos no texto OCR (pipeline tradicional de OCR + KIE baseado em regras). Coluna: regex_field_value_f1. Uma pontuação de 0 significa que nenhum valor de campo foi recuperado.
• F1 de valor de campo (LLM): a mesma métrica na saída do pós-processador LLM (texto OCR → deepseek-v4-flash → campos). Coluna: llm_field_value_f1. Os dois pipelines são diferentes e nunca são misturados.
• Campos de documento exatos: fração de documentos onde todos os campos alvo corresponderam exatamente — um critério muito mais rigoroso que o F1 por campo.
• Latência p50/p95 e páginas/min: tempo de inferência por página em regime permanente (aquecido e depois pontuado, exclui carregamento do modelo) e throughput em tempo real incluindo inicialização do modelo. Eles medem relógios diferentes.
• Custo por 1.000 páginas: horas de GPU cobradas para 1.000 páginas na taxa registrada de $0.76/hr, incluindo inicialização do modelo.

Lista de Fontes

1. summary_metrics.csv (GitHub raw). 16 linhas = 8 modelos × 2 conjuntos de dados. Colunas: model, compute_type, dataset, cer, wer, field_f1_regex, field_acc_regex, latency_p50_ms, latency_p95_ms, cost_per_1000_pages, pages_per_minute, error_rate. Todos os números de CER/WER, latência, custo e throughput nesta página são rastreados até as linhas do doctr e docling aqui.
2. field_method_comparison.csv (GitHub raw). 16 linhas; colunas model, dataset, llm_model (= deepseek-v4-flash), regex/llm field-value accuracy e F1, document-fields-exact, llm_median_latency_ms, contagens de tokens. Todos os números de F1 de campos regex/LLM são rastreados até as linhas do doctr e docling aqui (e até todas as oito linhas do sroie_2019 no contexto de classificação).
3. Repositório ImageToTableai/benchmark-ocr. Repositório público que hospeda os CSVs de resultados, manifestos de execução redatados, protocolo congelado e listas de amostras de conjuntos de dados (divisões de teste fixas) para reprodução.
4. results/manifests/ (GitHub). Um manifesto.json redatado por execução publicada (16 execuções) com versões de modelos, GPU/driver, versões torch/CUDA/Python, metadados de custo com carimbo de data/hora do preço e hashes de artefatos.
5. Huang et al., "ICDAR2019 Competition on Scanned Receipt OCR and Information Extraction" (2019). Definição do conjunto de dados SROIE 2019, estrutura da tarefa e licença (CC-BY-4.0).
6. Park et al., "CORD: A Consolidated Receipt Dataset for Post-OCR Parsing" (2020). Definição do conjunto de dados CORD v2, esquema de campos aninhados e licença (CC-BY-4.0).
7. Auer et al., "Docling Technical Report" (2024). Apenas contexto arquitetônico — descreve o pipeline em estágios do Docling (análise de layout, detecção de tabelas, inferência de ordem de leitura, montagem do documento). Nenhum número de benchmark nesta página é extraído dele.

Limitações

• Escopo do documento — apenas recibos: SROIE + CORD. Nada aqui mede o manuseio de layout/tabela/ordem de leitura/documentos longos que define a proposta de valor do Docling; essas capacidades estão fora do escopo, não refutadas. Não use esta página para concluir "Docling é ruim." Ela conclui: em um recibo simples de página única, a sobrecarga do pipeline não compensa.
• Tamanho da amostra: 361 recibos em inglês + 100 em indonésio. F1 de campo e CER são sensíveis ao corpus; as lacunas documentadas aqui (3,0× CER, 6,7× p50, 8,3× custo) estão muito além da faixa de ruído, mas diferenças de um único dígito devem ser tratadas como ruído, não como verdade de engenharia.
• Única faixa de GPU e único preço: todos os números vêm de uma RTX 4090 a $0,76/hr, com carimbo de data de preço em agosto de 2026 nos manifests de execução. Outras GPUs, servimento multi-GPU, agendamento em lote ou alterações de preço mudarão latência, throughput e custo — recalcule os custos com as taxas atuais antes de orçar.
• Único pós-processador LLM: todas as linhas LLM usam deepseek-v4-flash com temperatura 0. Um LLM diferente muda o F1 absoluto de campo; a vantagem de 0,049 pontos do docTR pode se mover nas margens. A latência do LLM (~1.996–2.365 ms mediana no SROIE, llm_median_latency_ms no field_method_comparison.csv) é imposta pela API e não faz parte da latência própria de nenhum dos engines.
• Ajuste de regex: o conjunto de padrões foi escrito uma vez por conjunto de dados. Uma biblioteca de padrões ajustada por formato poderia pontuar mais alto em seus próprios layouts — com o custo de manutenção que o LLM elimina; a vantagem de 2,9× do Docling sobre regex é medida contra este único conjunto de padrões fixo.
• A saída nativa do Docling não é pontuada: o Docling emite um modelo de documento estruturado, mas o benchmark pontua texto + pós-processadores, não a saída estruturada nativa. Uma variante do benchmark pontuando os campos nativos do Docling seria um experimento diferente; esta página não tenta isso.
• O CER do CORD não é uma leitura de qualidade por modelo: a verdade básica do CORD incorpora a estrutura de anotação e nenhum dos engines foi treinado predominantemente em indonésio; o CER do CORD (~0,91–0,92) reflete incompatibilidade de idioma + inflação da verdade básica. As linhas do CORD são citadas com enquadramento e nunca mescladas em qualquer classificação SROIE (regra do protocolo).
• Fixação de versão: os resultados valem para docTR v1.0.1 e Docling 2.119.0 (agosto de 2026). Versões mais recentes de qualquer engine podem alterar todos os números nesta página.

Referências relacionadas: docTR vs Surya2 Receipt Benchmark · PaddleOCR vs EasyOCR Receipt Benchmark · Traditional OCR vs Document Parsing VLMs · Regex vs LLM Field Extraction · Field-Level vs Character-Level Accuracy

Leitura relacionada: AI OCR vs Traditional OCR Accuracy · AI Image Data Extraction vs Traditional OCR · AI Document Extraction Pricing (2026)