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

O que o Docling é (e não é): OCR de passagem única vs. um pipeline de análise

Os dois mecanismos estão em lados opostos de uma divisão arquitetural 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 mecanismo neural de OCR de passagem única: um estágio de detecção localiza caixas delimitadoras de texto e um estágio de reconhecimento transcreve os caracteres dentro delas, compostos em um único preditor de OCR cuja passagem direta produz linhas de texto bruto. Não há modelo de layout, analisador de tabelas ou reconstrução de ordem de leitura — o que é impresso é o que sai, na ordem em que o reconhecedor lê. Docling não é um mecanismo 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 de arquitetura, não para qualquer número nesta página), ele encadeia 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 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 estágios 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 é ordem lexical. Um recibo simples em inglês não tem quase nada disso: uma coluna, algumas zonas, um caminho de cima para baixo em grande parte previsível, sem tabelas. A maquinaria em estágios ainda é executada em todas as páginas — é por isso que é mais lenta e mais cara — mas sem estrutura para explorar, a sobrecarga não pode se converter 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 Imposto do Pipeline sobre Texto Bruto

No SROIE 2019, a diferença 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 de referência — um CER de 0.197 significa ~19,7 caracteres lidos incorretamente por 100; a Taxa de Erro de Palavras aplica a mesma lógica de distância de edição em granularidade de palavra. O 0.5909 do Docling ocupa a 7ª posição de 8 engines na execução subjacente, à frente apenas do Unlimited-OCR (0.6552, coluna cer do summary_metrics.csv, todas as linhas sroie_2019) — o comparativo direto docTR-vs-Surya2 documentou o docTR como um dos dois melhores reconhecedores neste mesmo benchmark, e esta página mostra o mesmo engine na outra ponta 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 engine; ambos 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 engines na execução subjacente (à frente apenas do 0.6552 do Unlimited-OCR) — a precisão bruta de caracteres é onde o imposto do pipeline aparece primeiro.

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

Avalie o texto de ambos os mecanismos com os mesmos padrões fixos de regex nos quatro campos de recibo do SROIE (empresa, data, endereço, total) — a abordagem tradicional de OCR + extração de informações-chave (KIE) baseada em regras — e a classificação se inverte: Docling extrai campos com 0.2237 de F1 de campo 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 do OCR de cada mecanismo — pós-processado, não saída estruturada nativa de nenhum dos mecanismos, e o modelo de documento nativo do Docling não é pontuado aqui.

O F1 de valor de campo é a média harmônica de precisão e recall sobre os valores de campo extraídos contra a verdade absoluta — 1.0 significa que todo campo de recibo foi perfeitamente recuperado, 0 significa nada. O mecanismo por trás da inversão é a mesma diferença de arquitetura que causou a lacuna de CER, funcionando 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 forma do que os padrões fixos esperam; o texto de linha limpo, mas bruto, do docTR — preciso pelo CER, mas com maiúsculas originais, ruído de separadores e sem enquadramento de rótulos — derrota os padrões. O F1 de campo por regex do docTR de 0.0766 é o pior entre todos os oito mecanismos na execução subjacente, apesar do 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 ocupa o sexto lugar. O mesmo desacoplamento que o confronto direto irmão documentou 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 armazenados de 0–1 mostrados como %). Pós-processador LLM: deepseek-v4-flash (coluna llm_model). 361 amostras por mecanismo (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 de OCR de cada mecanismo, não extração estruturada nativa. Nenhum mecanismo acerta exatamente todos os quatro campos via regex em nenhum recibo SROIE (0.0000, um zero literal registrado no CSV). O F1 de campo via regex do docTR, de 0.0766, é o mais baixo entre todos os oito mecanismos na execução subjacente.

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

Alimente o texto de ambos os mecanismos a um pós-processador LLM (deepseek-v4-flash a 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 vantagem de 0.049 ponto, pequena comparada à lacuna bruta de CER, mas não eliminada. O texto base mais limpo expõe mais valores de campo recuperáveis; o LLM compensa parcialmente os artefatos de layout do Docling, mas não os apaga.

Esta é a mesma faixa de convergência observada em todo o benchmark de oito mecanismos — o pós-processamento com LLM aproxima mecanismos saudáveis porque entende semântica (números, datas, nomes) em vez de comparar formas de caracteres — e a lacuna residual importa: o 0.6171 do docTR é o melhor F1 de campo via LLM entre todos os oito mecanismos, enquanto o 0.5685 do Docling ocupa o sexto lugar (field_method_comparison.csv llm_field_value_f1, todas as linhas sroie_2019). A barra mais rigorosa — documentos em que todos os quatro campos correspondem exatamente — os separa em 2,7×: docTR 0.1496 vs Docling 0.0554. Dois custos vêm com essa 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 ela não consegue resgatar texto que um mecanismo fundamentalmente falhou 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 do LLM é incorrida pela API e separada da latência do mecanismo (summary_metrics.csv latency_p50_ms). Ambas as linhas concluídas com llm_ok_count 361.

O Envelope Operacional: 6,7× de Latência, 7,9× de Throughput, 8,3× de Custo

O custo do pipeline é mais pesado onde o planejamento de throughput vive. Na mesma RTX 4090 à mesma taxa registrada de $0,76/hora, o docTR sustenta 449,3 páginas/min a 108,7 ms p50 por página por $0,048 por 1.000 páginas; o Docling sustenta 56,7 páginas/min a 732,0 ms p50 por $0,398 por 1.000 páginas — uma diferença de 6,7× na latência, uma diferença de 7,9× no throughput e uma diferença de 8,3× no custo. 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 agravam seus piores tempos página a página.

O custo é calculado como tempo de execução × a taxa da RTX 4090 do RunPod ($0,76/hora, preço com registro de data/hora nos manifests de execução), incluindo a inicialização do modelo — o preço que você realmente pagaria pelo tempo de GPU. O throughput é o total de páginas por minuto em tempo real, incluindo essa mesma inicialização. As latências p50/p95 são tempos de inferência por página em estado estável, medidos após aquecimento (excluindo o carregamento do modelo). O docTR é o mecanismo mais rápido e mais barato de todos os oito na execução subjacente no SROIE; o Docling, a 56,7 páginas/min e $0,398 por 1.000 páginas, fica na metade inferior da tabela do envelope operacional (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 o 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 × $0,76/hora, incluindo a inicialização do modelo, preço com registro de data/hora nos manifests de execução (agosto de 2026). O docTR é o mecanismo 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/h com timestamp nos manifests); o custo inclui a 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 mecanismos foi treinado predominantemente com 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. Conforme o protocolo do benchmark, os números do CORD são mantidos em quarentena da comparação SROIE — nunca mesclados em qualquer ranking — porque o texto de referência do CORD incorpora estrutura de anotação, o que infla o CER bruto para todos os mecanismos, além da incompatibilidade real de idioma.

Nas métricas de campo, a única vantagem preservada do Docling se reduz a quase nada: por meio de padrões regex, ambos os mecanismos recuperam quase nenhum campo do CORD (docTR 0.0000 — um zero literal no CSV — vs. 0.0612 do Docling, porque os padrões em formato 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 à frente: F1 de campo 0.5500 vs. 0.4695. O CORD é citado aqui para contexto de robustez de idioma; ele nunca é deliberadamente agrupado com os números do SROIE em um único ranking.

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

Quem Vence Quando: O Resumo

“Melhor” depende da carga de trabalho, e este confronto divide os eixos com clareza: em um recibo simples em inglês, todos os eixos de velocidade/custo e de texto bruto favorecem o docTR; a inversão de campos por regex fora da caixa favorece o Docling; um pós-processador LLM os aproxima a uma vantagem de 0.049 pontos para o docTR; e os recursos para os quais o Docling existe — layout, tabelas, ordem de leitura, documentos longos — não foram medidos aqui, não foram refutados.

Perguntas Frequentes

O Docling é mais preciso que o docTR em recibos?

Não — na precisão bruta de caracteres, o docling é 3,0× pior: SROIE CER 0,5909 vs 0,1971, e WER 0,7596 vs 0,3199 (summary_metrics.csv, cer / wer, linhas sroie_2019). O Docling “vence” apenas um eixo medido: extração de campos por regex pronta para uso (0,2237 vs 0,0766 de F1 de campo) — e um pós-processador com LLM devolve essa vantagem ao 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 reorganiza o texto em um caminho de leitura e associa rótulos a valores, então o texto emitido fica estruturalmente mais próximo do que os padrões fixos de regex esperam; o docTR emite texto bruto de linha limpo, preciso por CER, mas que não se encaixa nos padrões (0,0766 de F1 de campo, o pior dos oito mecanismos, contra o melhor CER da classe). Esses são os scores postprocessed_sroie_receipt_regex_* — texto de OCR processado por padrões fixos — não saída estruturada nativa (field_method_comparison.csv, regex_field_value_f1, linhas sroie_2019). A mesma dissociação entre precisão de texto ≠ precisão de campo aparece em todo este benchmark.

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

Porque ele executa um pipeline de documentos em etapas — análise de layout, detecção de tabelas, reconstrução da ordem de leitura e um modelo intermediário de documento — em todas as páginas, mesmo quando a página é um recibo simples sem estrutura a 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, linhas sroie_2019).

Um pós-processador de LLM elimina a diferença entre docTR e Docling?

Em grande parte, mas não totalmente: o F1 de campo com pós-processamento de LLM no SROIE fica em docTR 0,6171 vs Docling 0,5685 — uma vantagem de 0,049 ponto para docTR que sobrevive à compensação parcial do LLM pelos artefatos de layout do Docling (field_method_comparison.csv, llm_field_value_f1, linhas sroie_2019). O custo da convergência é de ~2,0–2,4 s adicionais de latência mediana 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. O 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 só de recibos não consegue testar. O que esta página mostra é mais restrito: em um recibo simples de uma página, a sobrecarga do pipeline não se justifica (CER 3,0× pior, custo 8,3× maior), e sua única vantagem medida (F1 de campo regex 2,9×) é eliminada por um pós-processador de LLM. O enquadramento honesto é escopo, não veredito.

Por que ambos os mecanismos pontuam tão mal em recibos CORD?

Duas causas combinadas que o protocolo mantém separadas do ranking SROIE: uma incompatibilidade linguística real (recibos indonésios fora do foco de treinamento de ambos os mecanismos) e inflação da estrutura de anotação no texto de referência 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 de LLM, o F1 de campo do docTR se mantém em 0,5500 vs 0,4695 do Docling — a ordem do SROIE, comprimida. As linhas CORD são citadas e nunca agrupadas em um ranking combinado.

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

Para texto de recibos em alto volume com custo medido, a vantagem do docTR é decisiva: 108,7 ms p50, 449,3 páginas/min, US$ 0,048 por 1.000 páginas — o mecanismo mais rápido e mais barato entre os oito avaliados. Se o seu pipeline consome texto estruturado pronto sem pós-processamento, a vantagem do Docling em campos por regex (0,2237 vs 0,0766) é um ponto de partida real. Se o pós-processamento com LLM faz parte do design, o docTR continua à frente por 0,049 e é mais barato de alimentar. Se a sua carga de trabalho envolve documentos com muito layout — 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 desta página?

Cada número é uma linha dos CSVs publicados do benchmark de primeira parte — results/summary_metrics.csv (CER/WER, F1 de campos por regex, latência, custo, throughput) e results/field_method_comparison.csv (regex vs pós-processamento com LLM, llm_model = deepseek-v4-flash) — hospedados em ImageToTableai/benchmark-ocr, com um manifest.json editado 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 e Fontes

Protocolo

Esta página relata um recorte comparativo de uma execução de benchmark independente e reproduzível (nível oficial) — não é um levantamento de alegações de terceiros, nem uma página de comparação de fornecedores. Apenas divisões de teste fixas: teste SROIE 2019 (361 recibos em inglês, campos simples company/date/address/total) e teste CORD v2 (100 recibos em indonésio, campos aninhados menu/sub_total/total); as divisões de treinamento nunca foram avaliadas. Ambos os mecanismos viram as mesmas imagens, o mesmo ground truth e o mesmo protocolo de medição (warm_then_scored: uma passada de aquecimento fixa precede a passada avaliada, então os números de latência refletem o estado estável). Ambas as execuções terminaram com error_rate 0,0 nos dois conjuntos de dados (coluna error_rate em summary_metrics.csv). A execução subjacente contém oito mecanismos no total; esta página compara apenas os dois mecanismos nomeados, com os demais citados somente como contexto de classificação. Os resultados completos dos 8 mecanismos são publicados separadamente em Traditional OCR vs Document Parsing VLMs.

Ambiente de Execução

• Hardware: ambos os motores foram executados na mesma NVIDIA RTX 4090 (24 GB); o custo de GPU foi calculado com a tarifa on-demand de RunPod de $0,76/hora, com o preço registrado no manifest de cada execução (agosto de 2026).
• Motores: prontos para uso, sem fine-tuning. Versões fixadas: docTR v1.0.1 (OCR neural de passada única — estágio de deteçã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, deteção de tabelas, reconstrução da ordem de leitura organizados em torno de um núcleo de OCR, GPU) — conforme a tabela de modelos do repositório público (README.md) e os manifests de execução.
• Pós-processador LLM: deepseek-v4-flash via API a temperatura 0 para saída determinística (columna llm_model em field_method_comparison.csv); foi o único modelo usado para todas as filas de campos LLM em ambos os motores.
• Base de custo: tempo de execução de parede × $0,76/hora, 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 SROIE são postprocessed_sroie_receipt_regex_* (colunas regex_* em field_method_comparison.csv) — campos extraídos do texto de OCR por um conjunto fixo de padrões. Medem OCR + extração downstream, não saída estruturada nativa de nenhum modelo; as colunas LLM_* medem texto de OCR + extração LLM. As duas pipelines nunca são combinadas, e o modelo de documento nativo de Docling não é avaliado por este benchmark.

Definições de Métricas

• CER (Character Error Rate): distância de edição (inserções + deleções + substituições) entre o texto de OCR e o ground truth, dividida pelos caracteres do ground truth. Quanto menor, melhor.
• WER (Word Error Rate): o mesmo cálculo de distância de edição a nível de palavra.
• F1 de valor de campo (regex): média harmónica de precisão/recall sobre valores de campo extraídos usando padrões regex fixos no texto de OCR (pipeline tradicional de OCR + KIE baseado em regras). Columna: regex_field_value_f1. Uma pontuación de 0 significa que nenhun valor de campo foi recuperado.
• F1 de valor de campo (LLM): a mesma métrica na saída do pós-processador LLM (texto de OCR → deepseek-v4-flash → campos). Columna: llm_field_value_f1. As duas pipelines são diferentes e nunca são combinadas.
• Exactitud de campos do documento: fracción de documentos onde todos os campos alvo coincidieron exactamente — um padrão muito mais estricto que F1 por campo.
• Latencia p50/p95 & páginas/min: tempo de inferencia por página em estado estacionario (calentado y luego evaluado, excluyendo la carga del modelo) y rendimiento de pared incluyendo la inicialización del modelo. Miden relojes diferentes.
• Costo por 1.000 páginas: horas de GPU facturadas por 1.000 páginas a la tarifa registrada de $0,76/hora, incluyendo la inicialización del 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 provêm das linhas doctr e docling aqui.
2. field_method_comparison.csv (GitHub raw). 16 linhas; colunas model, dataset, llm_model (= deepseek-v4-flash), precisão e F1 de valores de campo regex/llm, document-fields-exact, llm_median_latency_ms, contagens de tokens. Todos os números de F1 de campo regex/LLM provêm das linhas doctr e docling aqui (e de todas as oito linhas 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 editados, protocolo congelado e listas de amostras de conjuntos de dados (divisões de teste fixas) para reprodução.
4. results/manifests/ (GitHub). Um manifest.json editado por execução publicada (16 execuções) com versões de modelo, GPU/driver, versões de 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 de tarefas 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 de arquitetura — descreve o pipeline em etapas do Docling (análise de layout, detecção de tabelas, inferência de ordem de leitura, montagem de documentos). Nenhum número de benchmark nesta página é retirado dele.

Limitações

• Escopo do documento — apenas recibos: SROIE + CORD. Nada aqui mede o tratamento de layout/tabelas/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 uma página, a sobrecarga do pipeline não compensa.
• Tamanho da amostra: 361 recibos em inglês + 100 em indonésio. O F1 por campo e o 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 poucos pontos percentuais devem ser tratadas como ruído, não como verdade de engenharia.
• Um único nível de GPU e um único preço: todos os números vêm de uma RTX 4090 a $0,76/hora, com preço datado de agosto de 2026 nos manifests de execução. Outras GPUs, serviço multi-GPU, agendamento em lote ou mudanças de preço alterarão latência, throughput e custo — recalcule os custos com as tarifas atuais antes de planejar o orçamento.
• Pós-processador LLM único: todas as linhas com LLM usam deepseek-v4-flash a temperatura 0. Um LLM diferente altera o F1 absoluto dos campos; a vantagem de 0,049 ponto do docTR pode oscilar nas margens. A latência do LLM (~1.996–2.365 ms de mediana no SROIE, field_method_comparison.csv llm_median_latency_ms) é incorrida pela API e não faz parte da latência de nenhum dos dois mecanismos.
• Ajuste de regex: o conjunto de padrões foi escrito uma vez por conjunto de dados. Uma biblioteca de padrões fortemente ajustada por formato poderia pontuar mais alto em seus próprios layouts — ao custo de manutenção que o LLM elimina; a vantagem de 2,9× do Docling em regex é medida contra este único conjunto fixo de padrões.
• A saída nativa do Docling não é avaliada: 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 que pontuasse 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: o ground truth do CORD embute estrutura de anotação e nenhum dos dois mecanismos foi treinado predominantemente em indonésio; o CER do CORD (~0,91–0,92) reflete incompatibilidade de idioma + inflação do ground truth. As linhas do CORD são citadas com contexto e nunca mescladas em qualquer ranking do SROIE (regra do protocolo).
• Versões fixadas: os resultados valem para docTR v1.0.1 e Docling 2.119.0 (agosto de 2026). Versões mais recentes de qualquer um dos mecanismos podem alterar todos os números desta página.

Referências relacionadas: Benchmark de recibos docTR vs Surya2 · Benchmark de recibos PaddleOCR vs EasyOCR · OCR tradicional vs VLMs de parsing de documentos · Extração baseada em regras vs extração com LLM · Precisão em nível de campo vs nível de caractere

Leitura relacionada: a lacuna de precisão entre IA e OCR tradicional · extração de imagens com IA comparada ao OCR tradicional · Preços de Extração de Documentos com IA (2026)