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

Ce qu’est Docling (et ce qu’il n’est pas) : OCR en un seul passage vs pipeline d’analyse

Les deux moteurs se situent de part et d’autre d’une fracture architecturale fondamentale, et c’est cette fracture — et non une différence de code ou de réglage — qui explique tout ce qui suit sur cette page. docTR est un moteur OCR neuronal en un seul passage : une étape de détection localise les boîtes englobantes du texte et une étape de reconnaissance transcrit les caractères qu’elles contiennent, le tout composé en un seul prédicteur OCR dont la passe avant de bout en bout produit des lignes de texte brutes. Il n’y a ni modèle de mise en page, ni analyseur de tableaux, ni reconstruction de l’ordre de lecture — ce qui est imprimé est ce qui ressort, dans l’ordre où le reconnaisseur le lit. Docling n’est ni 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 enchaîne une séquence de modèles par page — analyse de mise en page, détection de tableaux, inférence de l’ordre de lecture — les agrège, puis assemble un objet document intermédiaire avant d’émettre le texte, ce qui explique pourquoi sa sortie porte une structure (étiquettes, ordre, zones) que les lignes de docTR n’ont pas.

Pourquoi ce mécanisme compte pour un benchmark : chaque modèle étagé de la chaîne de Docling existe pour exploiter la structure de mise en page — un tableau à analyser, un formulaire sur deux colonnes, un parcours de lecture qui n’est pas l’ordre lexical. Un reçu en anglais tout simple n’a presque rien de tout cela : une seule colonne, quelques zones, un parcours de haut en bas largement prévisible, aucun tableau. La machinerie étagée 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 permet d’obtenir — et ce qu’il ne permet pas.

Précision des caractères : la taxe de pipeline sur le texte brut

Sur SROIE 2019, l'écart sur le texte brut n'est pas mince : 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 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 applique la même logique de distance d'édition au niveau des mots. Le 0,5909 de Docling se classe 7e sur 8 moteurs dans l'exécution sous-jacente, devant seulement Unlimited-OCR (0,6552, colonne cer de summary_metrics.csv, toutes les lignes sroie_2019) — le face-à-face docTR-vs-Surya2 documentait docTR comme l'un des deux meilleurs reconnaisseurs dans ce même benchmark, et cette page montre que le même moteur à l'autre bout du tableau de précision textuelle est un pipeline, pas une famille de reconnaisseurs 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 mieux. 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 de l'exécution sous-jacente (devant seulement le 0,6552 d'Unlimited-OCR) — la précision brute des caractères est là où la taxe de pipeline apparaît en premier.

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

Comparez le texte des deux moteurs via les mêmes motifs regex fixes sur les quatre champs de reçus SROIE (entreprise, date, adresse, total) — l'approche traditionnelle d'extraction d'informations clés (KIE) par OCR + règles — et le classement s'inverse : Docling extrait les champs à 0,2237 de F1 de champs contre 0,0766 pour docTR, soit un avantage de 2,9×. Ce sont les métriques postprocessed_sroie_receipt_regex_* du benchmark : des motifs fixes appliqués au texte OCR de chaque moteur — post-traité, pas une sortie structurée native d'aucun des deux moteurs, et le modèle documentaire 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 de champs extraites par rapport à la vérité terrain — 1,0 signifie que chaque champ de 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, mais agissant dans la direction opposée : le modèle documentaire de Docling réordonne le texte en un parcours de lecture et associe les étiquettes aux valeurs, donc son texte émis est plus proche en forme de ce que les motifs fixes attendent ; le texte de ligne brut mais propre de docTR — précis selon le CER, mais avec la casse d'origine, le bruit des séparateurs et sans cadre d'étiquettes — fait échouer les motifs. Le F1 de champs regex 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 que le face-à-face frère a documenté 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 stockées 0–1 affichées en %). Post-processeur LLM : deepseek-v4-flash (colonne llm_model). 361 échantillons par moteur (llm_ok_count).

Tableau : field_method_comparison.csv — colonnes regex, lignes sroie_2019. Ce sont 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 exacts via regex sur un seul reçu SROIE (0.0000, un zéro littéral enregistré dans le CSV). Le F1 regex de docTR de 0.0766 est le plus bas des huit moteurs de l'exécution sous-jacente.

Le post-traitement par LLM rétablit partiellement le classement

Envoyez le texte des deux moteurs à un post-processeur LLM (deepseek-v4-flash à température 0) avec une invite d'extraction structurée, et docTR reprend la tête : F1 champ 0.6171 contre 0.5685 — un écart de 0,049 point, faible comparé à l'écart CER brut mais pas effacé. Le texte de base plus propre révèle davantage de valeurs de champ récupérables ; le LLM compense partiellement les artefacts de mise en page de Docling mais ne les élimine pas.

C'est la même bande de convergence observée sur l'ensemble du benchmark à huit moteurs — le post-traitement par LLM rapproche les moteurs sains car il comprend la sémantique (nombres, dates, noms) au lieu de faire correspondre des 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 — les documents où les quatre champs correspondent exactement — les sépare de 2,7× : docTR 0.1496 contre 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 — imputables à l'API et identiques en nature), et il ne peut pas sauver un texte qu'un moteur n'a pas fondamentalement réussi à lire.

Tableau : 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 imputable à l'API et distincte de la latence du moteur (summary_metrics.csv latency_p50_ms). Les deux lignes ont abouti avec llm_ok_count 361.

L'enveloppe opérationnelle : 6,7× de latence, 7,9× de débit, 8,3× de coût

La taxe du pipeline est la plus lourde là où se planifie le débit. Sur la même RTX 4090 au même tarif enregistré de 0,76 $/h, docTR soutient 449,3 pages/min à 108,7 ms p50 par page pour 0,048 $ pour 1 000 pages ; Docling soutient 56,7 pages/min à 732,0 ms p50 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 de distribution est proportionnellement pire pour le pipeline : p95 281,4 ms contre 3 239,8 ms, soit un écart de 11,5×, car les modèles par étapes de Docling cumulent leurs pires temps de traitement page après page.

Le coût est calculé comme le temps d'exécution réel × le tarif RunPod RTX 4090 (0,76 $/heure, prix horodaté dans les manifests d'exécution), y compris l'initialisation du modèle — le prix que vous paieriez réellement pour le temps GPU. Le débit correspond aux pages par minute en temps réel, initialisation comprise. Les latences p50/p95 sont les temps d'inférence par page en régime permanent, mesurés à chaud puis notés (chargement du modèle exclu). docTR est le moteur le plus rapide et le moins cher des huit de l'exécution sous-jacente 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, 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 = temps d'exécution réel × 0,76 $/h, initialisation du modèle comprise, prix horodaté dans les manifests d'exécution (août 2026). docTR est le moteur le moins cher des huit de l'exécution sous-jacente.

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, tarif $0.76/h 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 des deux moteurs n'a été principalement entraîné sur des reçus indonésiens, donc CORD v2 (100 échantillons, champs imbriqués menu/sous-total/total) sert de test de résistance inter-langues — et les deux s'effondrent sur le CER brut : 0.9101 (docTR) et 0.9219 (Docling), un match nul dû à l'inadéquation linguistique. Selon le protocole du benchmark, les chiffres CORD sont tenus à l'écart de la comparaison SROIE — jamais fusionnés dans un classement — car le texte de vérité terrain de CORD intègre la structure d'annotation, ce qui gonfle le CER brut de chaque moteur en plus de la véritable inadéquation linguistique.

Sur les métriques de champs, le seul avantage préservé de Docling se réduit à presque rien : via les motifs regex, les deux moteurs ne 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é écrits pour du texte indonésien). Le postprocesseur 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 n'est délibérément jamais regroupé avec les chiffres SROIE dans un classement unique.

Table : summary_metrics.csv (cer / cost_per_1000_pages / pages_per_minute) et field_method_comparison.csv (F1 des champs), lignes cord_v2. Ne pas fusionner les chiffres CORD dans aucun classement SROIE : le CER CORD combine un vrai décalage linguistique avec une inflation de la structure d'annotation dans la vérité terrain, et les motifs regex ont été écrits pour des formats anglais. Le F1 regex CORD de docTR de 0,0000 est un zéro littéral enregistré dans le CSV, pas une valeur manquante.

Qui gagne quand : la grille récapitulative

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

Questions fréquentes

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

Non — en précision brute des caractères, docling est 3,0× moins bon : SROIE CER 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 prête à l’emploi (0,2237 contre 0,0766 en F1 de champs) — et un postprocesseur LLM fait basculer cet avantage vers docTR (0,6171 contre 0,5685).

Pourquoi Docling extrait-il mieux les champs avec des regex malgré un texte brut bien moins bon ?

Parce que les deux métriques évaluent des choses différentes, et que la forme de sortie de Docling correspond justement aux motifs. Le pipeline documentaire de Docling réorganise le texte en un parcours de lecture et associe les libellés aux valeurs, donc son texte émis est structurellement plus proche de ce que les motifs regex fixes attendent ; docTR émet un texte de lignes brutes propre, précis selon le CER, mais qui ne correspond pas aux motifs (0,0766 en F1 de champs, le pire des huit moteurs, contre un CER de classe optimale). Ce sont des scores postprocessed_sroie_receipt_regex_* — du texte OCR passé dans des motifs fixes — et non une sortie structurée native (field_method_comparison.csv, regex_field_value_f1, lignes sroie_2019). Ce même découplage précision du texte ≠ précision des champs apparaît dans tout ce benchmark.

Pourquoi Docling est-il si lent et si 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 quand la page est un simple reçu sans structure à exploiter. Sur SROIE, ce surcoût se mesure à 6,7× en p50 (108,7 contre 732,0 ms), 11,5× en p95, 7,9× de débit en moins (449,3 contre 56,7 pages/min), et 8,3× de coût plus élevé pour 1 000 pages ($0,048 contre $0,398) — même GPU, même protocole (summary_metrics.csv, lignes sroie_2019).

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

En grande partie, mais pas entièrement : le F1 de champ post-traité par LLM sur SROIE place docTR à 0,6171 contre 0,5685 pour Docling — un avantage de 0,049 point pour docTR qui survit à la compensation partielle par le LLM des artefacts de mise en page de Docling (field_method_comparison.csv, llm_field_value_f1, lignes sroie_2019). Le coût de la 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 points forts de Docling ne sont pas mesurés 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 tester. Ce que cette page montre est plus étroit : sur un reçu simple d'une page, la surcharge du pipeline ne se justifie pas (CER 3,0× pire, coût 8,3×), et son seul avantage mesuré (F1 de champ regex 2,9×) est effacé par un postprocesseur LLM. Le cadrage honnête est la portée, pas le 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 hors de la zone d'entraînement des deux moteurs) et une inflation de la structure d'annotation dans le texte de vérité terrain de CORD — le CER atteint 0,9101 (docTR) et 0,9219 (Docling) (summary_metrics.csv, cer, lignes cord_v2). Avec un postprocesseur LLM, le F1 de champ de docTR se maintient à 0,5500 contre 0,4695 pour Docling — l'ordre SROIE, compressé. Les lignes CORD sont citées et jamais regroupées dans un classement combiné.

Quel moteur une pipeline de reçus devrait-elle choisir, docTR ou Docling ?

Pour le texte de reçus à volume élevé avec coût à l’usage, 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 parmi les huit moteurs de la série sous-jacente. Si votre pipeline consomme du texte structuré prêt à l’emploi sans postprocesseur, l’avantage de Docling sur les champs par regex (0,2237 contre 0,0766) est un vrai avantage de départ. Si le posttraitement par LLM fait partie de la conception, docTR reste en tête de 0,049 et coûte moins cher à alimenter. Si votre charge de travail est composée de documents à forte mise en page — tableaux, formulaires, longs rapports — ce benchmark ne constitue pas la bonne preuve pour la décision ; il ne mesure que des reçus (voir Limitations).

D’où viennent les chiffres de cette page ?

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

Méthodologie & Sources

Protocole

Cette page présente un aperçu en confrontation directe d’une exécution de benchmark indépendante et reproductible (niveau officiel) — pas un relevé de revendications tierces, ni une page de comparaison de fournisseurs. Uniquement des splits de test fixes : test SROIE 2019 (361 reçus anglais, champs aplanis company/date/address/total) et test CORD v2 (100 reçus indonésiens, champs imbriqués menu/sub_total/total) ; les splits 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 d’échauffement fixe précède le passage noté, donc les chiffres de latence correspondent à l’état stable). Les deux exécutions se sont terminées avec un error_rate de 0,0 sur les deux ensembles de données (colonne error_rate de summary_metrics.csv). La série sous-jacente contient huit moteurs au total ; cette page ne compare que les deux moteurs nommés, les autres moteurs 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 la même NVIDIA RTX 4090 (24 Go) ; le coût GPU est calculé au tarif à la demande RunPod de 0,76 $/h, prix horodaté dans le manifeste expurgé de chaque exécution (août 2026).
• Moteurs : configuration par défaut, sans fine-tuning. Versions verrouillées : docTR v1.0.1 (OCR neuronal en un seul passage — é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 cœur OCR, GPU) — selon le tableau des modèles du dépôt public (README.md) et les manifestes d'exécution.
• Postprocesseur LLM : deepseek-v4-flash via API à température 0 pour une sortie déterministe (colonne llm_model dans field_method_comparison.csv) ; c'est 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 $/h, y compris 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 d'aucun 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 de 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 c'est bas, mieux c'est.
• WER (taux d'erreur de mots) : le même calcul de distance d'édition au niveau des mots.
• F1 des valeurs de champs (regex) : moyenne harmonique précision/rappel sur les valeurs de champs extraites à l'aide de motifs regex fixes sur le texte OCR (pipeline KIE traditionnel OCR + 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 des valeurs de champs (LLM) : la même métrique sur la sortie du postprocesseur 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 de documents où tous les champs cibles correspondent 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 (échauffement puis évaluation, hors chargement du modèle) et débit en temps réel incluant l'init 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 $/h, y compris 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 valeur CER/WER, latence, coût et débit de cette page provient des lignes doctr et docling de ce fichier.
2. field_method_comparison.csv (GitHub raw). 16 lignes ; colonnes model, dataset, llm_model (= deepseek-v4-flash), précision regex/LLM des valeurs de champs et F1, document-fields-exact, llm_median_latency_ms, nombre de tokens. Chaque valeur de F1 regex/LLM provient des lignes doctr et docling de ce fichier (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 de runs expurgés, le protocole figé et les listes d'échantillons des jeux de données (splits de test fixes) pour la reproduction.
4. results/manifests/ (GitHub). Un manifest.json expurgé par run publié (16 runs) avec versions des modèles, GPU/pilote, versions torch/CUDA/Python, métadonnées de coût avec horodatage du prix et hachages 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 d'architecture 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). Aucun chiffre de benchmark de cette page n'en provient.

Limites

• Périmètre du document — reçus uniquement : SROIE + CORD. Rien ici ne mesure la gestion de la mise en page, des tableaux, de l'ordre de lecture ou des 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 que « Docling est mauvais ». Elle conclut que sur un reçu simple d'une page, le surcoût du pipeline ne se justifie pas.
• Taille de l'échantillon : 361 reçus en anglais + 100 en indonésien. Le F1 par champ et le CER dépendent du corpus ; les écarts documentés ici (3,0× CER, 6,7× p50, 8,3× coût) dépassent largement la bande de bruit, mais des 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 $/heure, prix horodaté août 2026 dans les manifestes de l'exécution. D'autres GPU, un service multi-GPU, une planification par lots ou des changements de prix feront varier 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 autre LLM modifie le F1 absolu par champ ; l'avance de 0,049 point de docTR peut bouger à la marge. La latence du LLM (~1 996–2 365 ms médianes sur SROIE, field_method_comparison.csv llm_median_latency_ms) est due à l'API et ne fait pas partie de la latence propre de l'un ou l'autre moteur.
• Réglage des expressions régulières : le jeu de motifs a été écrit une fois par jeu de données. Une bibliothèque de motifs fortement réglée par format pourrait obtenir des scores plus élevés sur ses propres mises en page — au prix de la maintenance que le LLM élimine ; l'avantage de 2,9× de Docling en regex est mesuré contre ce jeu de motifs fixe unique.
• La sortie native de Docling n'est pas notée : Docling émet un modèle de document structuré, mais le benchmark note le texte + les postprocesseurs, pas la sortie structurée native. Une variante du benchmark notant les champs natifs de Docling serait une expérience différente ; cette page ne la tente pas.
• Le CER de CORD n'est pas une lecture 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 cadrage et ne sont jamais fusionnées dans aucun classement SROIE (règle du protocole).
• Épinglage des versions : les résultats valent pour docTR v1.0.1 et Docling 2.119.0 (août 2026). De nouvelles versions de l'un ou l'autre moteur peuvent modifier chaque chiffre de cette page.

Références connexes : Benchmark de reçus docTR vs Surya2 · Benchmark de reçus PaddleOCR vs EasyOCR · OCR traditionnel vs VLMs de parsing de documents · Extraction par règles vs extraction par LLM · Précision au niveau champ vs au niveau caractère

Lectures complémentaires : l'écart de précision entre l'IA et l'OCR traditionnel · l'extraction d'images par IA comparée à l'OCR traditionnel · Tarification de l'extraction de documents par IA (2026)