docTR vs Docling sur les reçus
Vitesse en passage unique vs pipeline documentaire (2026)

Ce qu'est Docling (et ce qu'il n'est pas) : OCR en une seule passe vs pipeline d'analyse

Les deux moteurs se situent aux extrémités d'une division architecturale fondamentale, et cette division — et non une différence de code ou de paramétrage — est toute l'histoire de cette page. docTR est un moteur OCR neuronal en une seule passe : une étape de détection localise les boîtes englobantes du texte et une étape de reconnaissance transcrit les caractères à l'intérieur, le tout composé en un seul prédicteur OCR dont le passage avant produit des lignes de texte brutes. Il n'y a pas de modèle de disposition, pas d'analyseur de tableaux et pas de reconstruction de l'ordre de lecture — ce qui est imprimé est ce qui sort, dans l'ordre où le reconnaître le lit. Docling n'est pas un moteur OCR ni un modèle vision-langage ; c'est un pipeline d'analyse de documents. Selon son propre rapport technique (cité pour le contexte architectural, et non pour un quelconque chiffre de cette page), il déploie une séquence de modèles par page — analyse de disposition, détection de tableaux, inférence de l'ordre de lecture — les agrège et assemble un objet document intermédiaire avant d'émettre le texte, ce qui explique que sa sortie contienne de la structure (étiquettes, ordre, zones) que les lignes de docTR n'ont pas.

Pourquoi ce mécanisme est-il important pour un benchmark : chaque modèle séquentiel dans la chaîne de Docling existe pour exploiter la structure de la disposition — un tableau à analyser, un formulaire à deux colonnes, un chemin de lecture qui n'est pas l'ordre lexical. Un reçu en anglais simple n'en a presque aucun : une seule colonne, quelques zones, un chemin de haut en bas largement prévisible, pas de tableaux. La machinerie séquentielle s'exécute quand même sur chaque page — c'est pourquoi elle est plus lente et plus coûteuse — mais sans structure à exploiter, la surcharge ne peut pas se convertir en meilleur texte. Cette page isole précisément ce coût et montre ce qu'il achète — et ce qu'il n'achète pas.

Précision des caractères : le coût du pipeline sur le texte brut

Sur SROIE 2019, l'écart sur le texte brut est important : CER 0.1971 contre 0.5909 (Docling) — une pénalité de 3,0× — et WER 0.3199 contre 0.7596. Le taux d'erreur de caractères (CER) mesure les insertions, suppressions et substitutions divisées par les caractères de référence — un CER de 0,197 signifie ~19,7 caractères mal lus pour 100 ; le taux d'erreur de mots (WER) applique la même logique de distance d'édition au niveau des mots. Le 0,5909 de Docling le classe 7ᵉ sur 8 moteurs dans l'exécution sous-jacente, devant uniquement Unlimited-OCR (0,6552, colonne cer de summary_metrics.csv, toutes les lignes sroie_2019) — le face-à-face docTR-vs-Surya2 avait documenté docTR comme l'un des deux meilleurs reconnaissances dans ce même benchmark, et cette page montre que le même moteur se trouve à l'autre bout du tableau de précision textuelle est un pipeline, pas une famille de reconnaissance plus faible.

Source : summary_metrics.csv — colonnes cer et wer, lignes sroie_2019. docTR cer 0,19707 / wer 0,31990 ; Docling cer 0,59092 / wer 0,75961. Plus bas est meilleur. 361 échantillons par moteur ; error_rate 0,0 pour les deux.

Tableau : summary_metrics.csv — colonnes cer / wer / error_rate, lignes sroie_2019. Valeurs exactes : docTR cer 0,19707 / wer 0,31990 ; Docling cer 0,59092 / wer 0,75961. Le CER SROIE de Docling est le deuxième pire des huit moteurs dans l'exécution sous-jacente (devant uniquement les 0,6552 d'Unlimited-OCR) — la précision brute des caractères est là où le coût du pipeline apparaît en premier.

L'inversion : l'extraction de champs par regex inverse le résultat

Testez les deux moteurs avec les mêmes motifs regex fixes sur les quatre champs de reçus SROIE (entreprise, date, adresse, total) — l'approche traditionnelle OCR + extraction d'informations clés (KIE) basée sur des règles — et le classement s'inverse : Docling extrait les champs avec un F1 de 0,2237 contre 0,0766 pour docTR, un avantage de 2,9×. Ce sont les métriques postprocessed_sroie_receipt_regex_* du benchmark : motifs fixes appliqués au texte OCR de chaque moteur — post-traité, pas la sortie structurée native d'aucun moteur, et le modèle document natif de Docling n'est pas évalué ici.

Le F1 de valeur de champ est la moyenne harmonique de la précision et du rappel sur les valeurs des champs extraits par rapport à la vérité terrain — 1,0 signifie que chaque champ du reçu est parfaitement récupéré, 0 signifie rien. Le mécanisme derrière l'inversion est la même différence d'architecture qui a causé l'écart de CER, agissant dans le sens opposé : le modèle document de Docling réordonne le texte en un chemin de lecture et associe les étiquettes aux valeurs, donc son texte émis est de forme plus proche de ce que les motifs fixes attendent ; le texte brut mais propre de docTR — précis par CER, mais avec la casse originale et le bruit des séparateurs et sans cadrage d'étiquettes — fait échouer les motifs. Le F1 regex de champ de docTR de 0,0766 est le pire des huit moteurs dans l'exécution sous-jacente malgré son CER de meilleure classe (colonnes field_f1_regex et cer de summary_metrics.csv, toutes les lignes sroie_2019) ; celui de Docling, 0,2237, se classe sixième. Le même découplage documenté dans le duel direct en haut de l'échelle de précision (docTR vs Surya2) se reproduit ici en bas : la précision du texte n'est pas la précision des champs.

Source : field_method_comparison.csv — colonnes regex_field_value_f1 / llm_field_value_f1, lignes sroie_2019 (décimales de 0 à 1 affichées en %). Post-traitement LLM : deepseek-v4-flash (colonne llm_model). 361 échantillons par moteur (llm_ok_count).

Table : field_method_comparison.csv — colonnes regex, lignes sroie_2019. Il s'agit des métriques postprocessed_sroie_receipt_regex_* : des motifs fixes appliqués au texte OCR de chaque moteur, pas une extraction structurée native. Aucun moteur n'obtient les quatre champs exactement corrects via regex sur un seul reçu SROIE (0,0000, un zéro littéral enregistré dans le CSV). Le F1 champ regex de docTR, 0,0766, est le plus bas des huit moteurs dans l'exécution sous-jacente.

Le post-traitement LLM restaure le classement — partiellement

En passant le texte des deux moteurs à un post-processeur LLM (deepseek-v4-flash à température 0) avec un prompt d'extraction structurée, docTR reprend la tête : F1 champ 0,6171 vs 0,5685 — un avantage de 0,049 point, faible par rapport à l'écart brut de CER mais non effacé. Le texte de base plus propre fait émerger des valeurs de champ plus récupérables ; le LLM compense partiellement les artefacts de mise en page de Docling sans les éliminer.

C'est la même bande de convergence observée sur l'ensemble du benchmark à huit moteurs — le post-traitement LLM rapproche les moteurs performants car il comprend la sémantique (nombres, dates, noms) au lieu de correspondre aux formes de caractères — et l'écart résiduel compte : le 0,6171 de docTR est le meilleur F1 champ LLM des huit moteurs, tandis que le 0,5685 de Docling se classe sixième (field_method_comparison.csv llm_field_value_f1, toutes les lignes sroie_2019). Le critère plus strict — documents où tous les quatre champs correspondent exactement — les sépare de 2,7× : docTR 0,1496 vs Docling 0,0554. Deux coûts accompagnent ce levier : un appel LLM ajoute ~2,0–2,4 s de latence médiane par document en plus du temps OCR (1 996,3 ms pour le texte de docTR, 2 365,1 ms pour celui de Docling — imputés à l'API et de même nature), et il ne peut pas sauver un texte qu'un moteur n'a pas réussi à lire fondamentalement.

Table : field_method_comparison.csv — colonnes llm_*, lignes sroie_2019. Modèle LLM : deepseek-v4-flash à température 0 (colonne llm_model). La latence LLM est imposée par l'API et distincte de la latence du moteur (summary_metrics.csv latency_p50_ms). Les deux lignes ont été complétées avec llm_ok_count 361.

Enveloppe opérationnelle : latence ×6,7, débit ×7,9, coût ×8,3

La taxe du pipeline est la plus lourde là où se situe la planification du débit. Sur la même RTX 4090 au même tarif enregistré de 0,76 $/h, docTR maintient 449,3 pages/min avec une latence p50 de 108,7 ms par page pour 0,048 $ pour 1 000 pages ; Docling maintient 56,7 pages/min avec une latence p50 de 732,0 ms pour 0,398 $ pour 1 000 pages — un écart de latence de ×6,7, un écart de débit de ×7,9 et un écart de coût de ×8,3. La queue est proportionnellement pire pour le pipeline : p95 281,4 ms contre 3 239,8 ms, un écart de ×11,5, car les modèles séquentiels de Docling cumulent leurs temps les plus mauvais page après page.

Le coût est calculé comme durée d'exécution réelle × le tarif RunPod RTX 4090 (0,76 $/heure, prix horodaté dans les manifests d'exécution), incluant l'initialisation du modèle — le prix que vous paieriez réellement pour le temps GPU. Le débit est le nombre de pages par minute en temps réel, incluant cette même initialisation. Les latences p50/p95 sont les temps d'inférence par page en régime permanent, mesurés en mode warm-then-scored (chargement du modèle exclu). docTR est le moteur le plus rapide et le moins cher des huit dans l'exécution de base sur SROIE ; Docling, à 56,7 pages/min et 0,398 $ pour 1 000 pages, se situe dans la moitié inférieure du tableau de l'enveloppe opérationnelle (summary_metrics.csv, colonnes latency_p50_ms / pages_per_minute / cost_per_1000_pages, toutes les lignes sroie_2019).

Source : summary_metrics.csv — colonnes latency_p50_ms / latency_p95_ms, lignes sroie_2019. docTR p50 108,72 / p95 281,38 ; Docling p50 732,00 / p95 3239,79. Latence en régime permanent (mode de mesure warm_then_scored, chargement du modèle exclu).

Source : summary_metrics.csv — colonne cost_per_1000_pages, lignes sroie_2019. docTR 0,0479, Docling 0,3978. Coût = durée d'exécution réelle × 0,76 $/h incluant l'initialisation du modèle, prix horodaté dans les manifests d'exécution (août 2026). docTR est le moteur le moins cher des huit dans l'exécution de base.

Tableau : summary_metrics.csv — latency_p50_ms / latency_p95_ms / pages_per_minute / cost_per_1000_pages, lignes sroie_2019. Les deux moteurs sur GPU (RTX 4090, prix horaire de $0.76 horodaté dans les manifests) ; le coût inclut l'initialisation du modèle. Valeurs exactes : 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 (reçus indonésiens) : les deux s'effondrent, la récupération de champs par LLM de docTR reste en tête

Aucun moteur n'a été principalement entraîné sur des reçus indonésiens, donc CORD v2 (100 échantillons, champs imbriqués menu/sub_total/total) sert de test de résistance interlingue — et les deux s'effondrent sur le CER brut : 0.9101 (docTR) et 0.9219 (Docling), un match nul d'inadéquation linguistique. Selon le protocole de référence, les chiffres de CORD sont maintenus isolés de la comparaison SROIE — jamais fusionnés dans un classement — car le texte de référence de CORD intègre la structure d'annotation, ce qui gonfle le CER brut pour chaque moteur en plus de la véritable inadéquation linguistique.

Sur les métriques de champs, l'avantage unique préservé de Docling se réduit à presque rien : via les expressions régulières, les deux moteurs récupèrent presque aucun champ CORD (docTR 0.0000 — un zéro littéral dans le CSV — contre 0.0612 pour Docling, car les motifs au format anglais n'ont jamais été conçus pour le texte indonésien). Le post-traitement LLM absorbe le choc linguistique des deux côtés mais maintient docTR en tête : F1 des champs 0.5500 contre 0.4695. CORD est cité ici pour le contexte de robustesse linguistique ; il est délibéré de ne jamais le regrouper avec les chiffres SROIE dans un classement unique.

Tableau : summary_metrics.csv (cer / cost_per_1000_pages / pages_per_minute) et field_method_comparison.csv (F1 des champs), lignes cord_v2. Ne fusionnez pas les chiffres CORD dans un quelconque classement SROIE : le CER de CORD combine une véritable inadéquation linguistique avec une inflation de la structure d'annotation dans la vérité terrain, et les expressions régulières ont été rédigées pour des formats anglais. Le F1 des champs regex de docTR sur CORD, à 0.0000, est un zéro littéral enregistré dans le CSV, pas une valeur manquante.

Qui gagne quand : le tableau récapitulatif

“Mieux” dépend de la charge de travail, et cette confrontation directe sépare clairement les axes : sur un reçu en anglais simple, tous les axes vitesse/coût et texte brut favorisent docTR ; l'inversion des champs regex hors de la boîte favorise Docling ; un postprocesseur LLM les ramène à un avantage de 0,049 point pour docTR ; et les fonctionnalités pour lesquelles Docling existe — mise en page, tableaux, ordre de lecture, longs documents — ne sont pas mesurées ici, pas réfutées.

Foire aux questions

Docling est-il plus précis que docTR pour les reçus ?

Non — en termes de précision brute des caractères, docling est 3,0× moins précis : CER SROIE 0,5909 contre 0,1971, et WER 0,7596 contre 0,3199 (summary_metrics.csv, cer / wer, lignes sroie_2019). Docling ne « gagne » que sur un seul axe mesuré : l'extraction de champs par regex hors de la boîte (0,2237 contre 0,0766 field F1) — et un postprocesseur LLM renverse la situation en faveur de docTR (0,6171 contre 0,5685).

Pourquoi Docling extrait-il mieux les champs avec des regex malgré un texte brut beaucoup moins précis ?

Parce que les deux métriques évaluent des choses différentes, et que la forme de sortie de Docling correspond par hasard aux motifs. Le pipeline documentaire de Docling réordonne le texte en un chemin de lecture et associe des étiquettes aux valeurs, de sorte que son texte émis est structurellement plus proche de ce que les motifs regex fixes attendent ; docTR émet du texte brut de ligne propre qui est précis selon le CER mais qui déjoue les motifs (0,0766 field F1, le pire des huit moteurs, contre un CER de meilleure classe). Il s'agit des scores postprocessed_sroie_receipt_regex_* — du texte OCR passé dans des motifs fixes — et non d'une sortie structurée native (field_method_comparison.csv, regex_field_value_f1, lignes sroie_2019). Cette dissociation précision du texte ≠ précision des champs apparaît dans l'ensemble de ce benchmark.

Pourquoi Docling est-il si beaucoup plus lent et coûteux par page ?

Parce qu'il exécute un pipeline documentaire par étapes — analyse de la mise en page, détection des tableaux, reconstruction de l'ordre de lecture et un modèle documentaire intermédiaire — sur chaque page, même lorsque la page est un reçu simple sans structure à exploiter. Sur SROIE, cette charge mesure 6,7× au p50 (108,7 contre 732,0 ms), 11,5× au p95, un débit 7,9× inférieur (449,3 contre 56,7 pages/min) et un coût 8,3× supérieur pour 1 000 pages ($0,048 contre $0,398) — même GPU, même protocole (summary_metrics.csv, lignes sroie_2019).

Un post-traitement LLM comble-t-il l'écart entre docTR et Docling ?

En grande partie, mais pas totalement : le F1 des champs post-traités par LLM sur SROIE atteint docTR 0.6171 contre Docling 0.5685 — un avantage de 0,049 point pour docTR qui survit à la compensation partielle du LLM pour les artefacts de mise en page de Docling (field_method_comparison.csv, llm_field_value_f1, lignes sroie_2019). Le coût de cette convergence est d'environ 2,0 à 2,4 s de latence LLM médiane supplémentaire par document (llm_median_latency_ms, mêmes lignes).

Ce benchmark signifie-t-il que Docling est mauvais ?

Non — cela signifie que les forces de Docling ne sont pas mesurées ici. Docling est un pipeline d'analyse de documents dont la proposition de valeur — structure de mise en page, tableaux, ordre de lecture, formulaires, documents longs — est exactement ce qu'un benchmark limité aux reçus ne peut pas évaluer. Ce que cette page montre est plus restreint : sur un reçu simple d'une seule page, la surcharge du pipeline ne s'amortit pas (CER 3,0× pire, coût 8,3×), et son seul avantage mesuré (F1 regex des champs 2,9×) est effacé par un post-traitement LLM. Le cadre honnête est celui de la portée, pas du verdict.

Pourquoi les deux moteurs obtiennent-ils de si mauvais scores sur les reçus CORD ?

Deux causes cumulatives que le protocole sépare du classement SROIE : une véritable inadéquation linguistique (reçus indonésiens en dehors du champ d'entraînement des deux moteurs) et une inflation de la structure d'annotation dans le texte de référence de CORD — le CER atteint 0,9101 (docTR) et 0,9219 (Docling) (summary_metrics.csv, cer, lignes cord_v2). Avec un post-traitement LLM, le F1 des champs de docTR se maintient à 0,5500 contre 0,4695 pour Docling — l'ordre de SROIE, compressé. Les lignes CORD sont citées et jamais regroupées dans un classement combiné.

Quel moteur choisir pour un pipeline de reçus, docTR ou Docling ?

Pour du texte de reçu à haut volume avec coût mesuré, l'enveloppe de docTR est décisive : 108,7 ms p50, 449,3 pages/min, 0,048 $ pour 1 000 pages — le moteur le plus rapide et le moins cher du test des huit moteurs. Si votre pipeline consomme du texte structuré prêt à l'emploi sans aucun post-traitement, l'avantage regex de Docling (0,2237 vs 0,0766) est un vrai point de départ. Si le post-traitement par LLM fait partie de la conception, docTR reste en avance de 0,049 et coûte moins cher à alimenter. Si votre charge de travail est des documents à mise en page complexe — tableaux, formulaires, longs rapports — ce benchmark n'est pas la bonne preuve pour la décision ; il ne mesure que les reçus (voir Limites).

D'où viennent les chiffres sur cette page ?

Chaque chiffre est une ligne des CSV publiés du benchmark interne — results/summary_metrics.csv (CER/WER, F1 regex, latence, coût, débit) et results/field_method_comparison.csv (regex vs post-traitement LLM, llm_model = deepseek-v4-flash) — hébergés sur ImageToTableai/benchmark-ocr, avec un manifest.json édité par exécution pour les empreintes d'environnement. Les définitions des jeux de données proviennent des articles SROIE 2019 et CORD cités ci-dessous.

Méthodologie & Sources

Protocole

Cette page présente un extrait comparatif d'un benchmark indépendant et reproductible (niveau officiel) — pas un recueil d'affirmations tierces, ni une page de comparaison fournisseurs. Uniquement des ensembles de test fixes : SROIE 2019 test (361 reçus anglais, champs plats entreprise/date/adresse/total) et CORD v2 test (100 reçus indonésiens, champs imbriqués menu/sous_total/total) ; les ensembles d'entraînement n'ont jamais été évalués. Les deux moteurs ont vu les mêmes images, la même vérité terrain et le même protocole de mesure (warm_then_scored : un passage de chauffage fixe précède le passage mesuré, donc les chiffres de latence sont en régime permanent). Les deux exécutions se sont terminées avec un error_rate de 0,0 sur les deux jeux de données (colonne error_rate de summary_metrics.csv). L'exécution sous-jacente contient huit moteurs au total ; cette page ne compare que les deux moteurs nommés, les autres n'étant cités que comme contexte de classement. Les résultats complets des 8 moteurs sont publiés séparément sur Traditional OCR vs Document Parsing VLMs.

Environnement d'exécution

• Matériel : les deux moteurs ont tourné sur le même NVIDIA RTX 4090 (24 Go) ; coût GPU calculé au tarif à la demande de RunPod de $0.76/hr, le prix étant horodaté dans le manifeste édité de chaque exécution (août 2026).
• Moteurs : en configuration standard, sans affinage. Versions verrouillées : docTR v1.0.1 (OCR neuronal en une seule passe — étape de détection + étape de reconnaissance composées en un seul prédicteur OCR, GPU) et Docling 2.119.0 (pipeline d'analyse de documents — analyse de mise en page, détection de tableaux, reconstruction de l'ordre de lecture organisés autour d'un noyau OCR, GPU) — selon le tableau des modèles du dépôt public (README.md) et les manifestes d'exécution.
• Post-traitement LLM : deepseek-v4-flash via API à température 0 pour une sortie déterministe (colonne llm_model dans field_method_comparison.csv) ; c'était le seul modèle utilisé pour toutes les lignes de champs LLM sur les deux moteurs.
• Base de coût : temps d'exécution réel × $0.76/hr, incluant l'initialisation du modèle — le traitement par lots réduit le coût par page.
• Post-traitement des champs : les métriques de champs regex SROIE sont postprocessed_sroie_receipt_regex_* (colonnes regex_* de field_method_comparison.csv) — champs extraits du texte OCR par un ensemble de motifs fixes. Elles mesurent l'OCR + l'extraction en aval, pas la sortie structurée native de l'un ou l'autre modèle ; les colonnes LLM_* mesurent le texte OCR + l'extraction LLM. Les deux pipelines ne sont jamais mélangés, et le modèle document natif de Docling n'est pas évalué par ce benchmark.

Définitions des métriques

• CER (Taux d'erreur de caractères) : distance d'édition (insertions + suppressions + substitutions) entre le texte OCR et la vérité terrain, divisée par le nombre de caractères de la vérité terrain. Plus bas est mieux.
• WER (Taux d'erreur de mots) : le même calcul de distance d'édition au niveau des mots.
• F1 sur les valeurs de champs (regex) : moyenne harmonique précision/rappel sur les valeurs de champs extraites en utilisant des motifs regex fixes sur le texte OCR (pipeline OCR traditionnel + KIE basé sur des règles). Colonne : regex_field_value_f1. Un score de 0 signifie qu'aucune valeur de champ n'a été récupérée.
• F1 sur les valeurs de champs (LLM) : la même métrique sur la sortie du post-traitement LLM (texte OCR → deepseek-v4-flash → champs). Colonne : llm_field_value_f1. Les deux pipelines sont différents et ne sont jamais mélangés.
• Champs de document exacts : fraction des documents où tous les champs cibles correspondaient exactement — un critère bien plus strict que le F1 par champ.
• Latence p50/p95 et pages/min : temps d'inférence par page en régime permanent (après chauffe puis mesuré, excluant le chargement du modèle) et débit réel incluant l'initialisation du modèle. Ils mesurent des horloges différentes.
• Coût pour 1 000 pages : heures GPU facturées pour 1 000 pages au tarif enregistré de $0.76/hr, incluant l'initialisation du modèle.

Liste des sources

1. summary_metrics.csv (GitHub raw). 16 lignes = 8 modèles × 2 jeux de données. Colonnes : 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. Chaque donnée de CER/WER, latence, coût et débit sur cette page provient des lignes doctr et docling ici.
2. field_method_comparison.csv (GitHub raw). 16 lignes ; colonnes model, dataset, llm_model (= deepseek-v4-flash), précision et F1 regex/llm pour les champs, document-fields-exact, llm_median_latency_ms, compteurs de tokens. Chaque donnée de F1 regex/LLM pour les champs provient des lignes doctr et docling ici (et des huit lignes sroie_2019 dans le contexte du classement).
3. Dépôt ImageToTableai/benchmark-ocr. Dépôt public hébergeant les CSV de résultats, les manifests d'exécution caviardés, le protocole figé et les listes d'échantillons de jeux de données (partitions de test fixes) pour la reproductibilité.
4. results/manifests/ (GitHub). Un manifest.json caviardé par exécution publiée (16 exécutions) avec les versions des modèles, GPU/pilotes, versions torch/CUDA/Python, métadonnées de coût avec horodatage des prix et empreintes des artefacts.
5. Huang et al., « ICDAR2019 Competition on Scanned Receipt OCR and Information Extraction » (2019). Définition du jeu de données SROIE 2019, structure des tâches et licence (CC-BY-4.0).
6. Park et al., « CORD: A Consolidated Receipt Dataset for Post-OCR Parsing » (2020). Définition du jeu de données CORD v2, schéma de champs imbriqués et licence (CC-BY-4.0).
7. Auer et al., « Docling Technical Report » (2024). Contexte architectural uniquement — décrit le pipeline par étapes de Docling (analyse de mise en page, détection de tableaux, inférence de l'ordre de lecture, assemblage du document). Aucune donnée de benchmark sur cette page n'est tirée de cette source.

Limitations

• Périmètre du document — reçus uniquement : SROIE + CORD. Rien ici n'évalue la gestion de la mise en page/tableaux/ordre de lecture/documents longs qui définit la proposition de valeur de Docling ; ces capacités sont hors périmètre, pas réfutées. N'utilisez pas cette page pour conclure « Docling est mauvais ». Elle conclut : sur un reçu simple d'une seule page, la surcharge du pipeline ne vaut pas le coup.
• Taille de l'échantillon : 361 reçus en anglais + 100 reçus en indonésien. Les scores F1 et CER par champ sont sensibles au corpus ; les écarts documentés ici (3,0× CER, 6,7× p50, 8,3× coût) sont bien au-delà de la bande de bruit, mais les différences de quelques points de pourcentage doivent être traitées comme du bruit, pas comme une vérité d'ingénierie.
• Un seul niveau de GPU et un seul prix : tous les chiffres proviennent d'un seul RTX 4090 à 0,76 $/h, horodaté en août 2026 dans les manifests d'exécution. D'autres GPU, un service multi-GPU, une planification par lots ou des changements de prix modifieront la latence, le débit et le coût — recalculez les coûts aux tarifs actuels avant de budgétiser.
• Un seul postprocesseur LLM : toutes les lignes LLM utilisent deepseek-v4-flash à température 0. Un LLM différent modifierait le score F1 absolu par champ ; l'avantage de 0,049 point de docTR pourrait évoluer aux marges. La latence du LLM (~1 996–2 365 ms médiane sur SROIE, champ llm_median_latency_ms dans field_method_comparison.csv) est imputée à l'API et ne fait pas partie de la latence propre à l'un ou l'autre moteur.
• Paramétrage des regex : l'ensemble de motifs a été écrit une fois par jeu de données. Une bibliothèque de motifs paramétrée par format et fortement optimisée pourrait obtenir de meilleurs résultats sur ses propres mises en page — au prix de maintenance que le LLM supprime ; l'avantage de 2,9× de Docling sur les regex est mesuré par rapport à cet ensemble de motifs fixe unique.
• La sortie native de Docling n'est pas évaluée : Docling émet un modèle de document structuré, mais le benchmark évalue le texte + les postprocesseurs, pas la sortie structurée native. Une variante du benchmark évaluant les champs natifs de Docling serait une expérience différente ; cette page ne l'entreprend pas.
• Le CER de CORD n'est pas une mesure de qualité par modèle : la vérité terrain de CORD intègre la structure d'annotation et aucun des deux moteurs n'a été principalement entraîné sur de l'indonésien ; le CER de CORD (~0,91–0,92) reflète l'inadéquation linguistique + l'inflation de la vérité terrain. Les lignes CORD sont citées avec un contexte et ne sont jamais fusionnées dans un classement SROIE (règle de protocole).
• Verrouillage des versions : les résultats sont valables pour docTR v1.0.1 et Docling 2.119.0 (août 2026). De nouvelles versions de l'un ou l'autre moteur pourraient modifier chaque chiffre de cette page.

Références associées : 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

Lectures associées : AI OCR vs Traditional OCR Accuracy · AI Image Data Extraction vs Traditional OCR · AI Document Extraction Pricing (2026)