docTR vs Surya2 : OCR de reçus
Benchmark comparatif (2026)

Sur SROIE 2019, docTR et Surya2 sont les deux plus forts reconnaisseurs de caractères du benchmark, séparés de 0,006 point — dans la marge de bruit pour un corpus de 361 échantillons. Le WER raconte la même histoire : Surya2 0,2735, docTR 0,3199. Le récit « les VLM surpassent l'OCR traditionnel » ne survit pas à cette comparaison sur la précision brute des caractères des reçus en anglais.

Précision des caractères : une égalité statistique

Cette égalité compte parce que les deux moteurs sont architecturalement opposés. docTR est un pipeline OCR neuronal traditionnel en deux étapes : un détecteur localise les mots et un reconnaisseur les transcrit, en préservant la casse et la mise en page d'origine du texte imprimé. Surya2 est un modèle vision-langage d'analyse de documents : il lit l'image du document entier et produit un texte compris — casse normalisée, paires libellé/valeur fusionnées, lignes réordonnées — ce qui est plus proche de ce que veulent les systèmes en aval, mais plus éloigné des correspondances exactes de caractères. Le CER mesure les correspondances exactes de caractères, il est donc légèrement défavorable à Surya2 ; le fait que l'égalité subsiste malgré cette asymétrie est ce qui la rend significative.

Tableau : summary_metrics.csv — colonnes cer et wer, lignes sroie_2019. Valeurs exactes : docTR cer 0,19707 / wer 0,31990 ; Surya2 cer 0,19147 / wer 0,27352. Plus bas est mieux ; les deux exécutions se sont terminées avec error_rate 0,0.

Là où ils divergent : l'extraction de champs prête à l'emploi renverse le résultat

Évaluez le texte brut des moteurs avec les mêmes expressions régulières fixes sur les quatre champs de reçu 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 : Surya2 extrait les champs à 0,3183 de F1 sur les champs contre 0,0766 pour docTR, soit un avantage de 4,2×. docTR a la meilleure précision de caractères de sa catégorie et la pire extraction de champs par regex des huit moteurs testés — la précision du texte et celle des champs sont découplées.

Le F1 sur les valeurs 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 que rien ne l'est. Le mécanisme derrière ce renversement est la différence de forme de sortie décrite ci-dessus. Les expressions régulières ont été écrites pour des valeurs formatées comme RM 12.00 ou 14/08/2020 ; la sortie normalisée et structurée par étiquettes de Surya2 (casse réduite, fusion clé-valeur) correspond beaucoup plus souvent à ces modèles, tandis que le texte brut en lignes de docTR — précis selon le CER, mais avec la casse d'origine et le bruit des séparateurs — les fait échouer. Les colonnes « extraction de champs par regex » sont les métriques postprocessed_sroie_receipt_regex_* du benchmark : elles mesurent le texte OCR + l'extraction en aval basée sur des règles, et non la sortie structurée native.

Source : field_method_comparison.csv — colonnes regex_field_value_f1 / llm_field_value_f1, lignes sroie_2019 (décimales stockées de 0 à 1 affichées en %). Postprocesseur 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 (post-traité, pas d’extraction native). Le F1 regex de docTR de 0,0766 est le plus bas des huit moteurs de l’exécution sous-jacente, malgré le deuxième meilleur CER.

Le levier LLM : le choix du moteur cesse d’importer

En alimentant le texte OCR des deux moteurs à un postprocesseur LLM (deepseek-v4-flash, température 0) avec une invite d’extraction structurée, l’écart de champs disparaît presque : docTR 0,6171 contre Surya2 0,6139 en F1 sur les valeurs de champ — un avantage de 0,003 point pour le moteur traditionnel, une égalité en pratique. Le postprocesseur, et non le moteur OCR, devient le composant décisif.

C’est le même schéma observé sur l’ensemble du benchmark à huit moteurs : le post-traitement LLM ramène les moteurs performants dans une bande convergente de F1 sur les champs, car il comprend la sémantique (nombres, dates, noms) au lieu de faire correspondre des formes de caractères. Le texte de base plus propre de docTR prend une légère avance ; la structure normalisée de Surya2 perd ce minuscule avantage sous le LLM. Deux coûts accompagnent ce levier : un appel LLM ajoute environ 2,0–2,3 s de latence médiane par document en plus du temps OCR (1 996,3 ms pour le texte de docTR, 2 261,7 ms pour celui de Surya2, imputables à l’API et identiques en nature), et il ne sauve pas un texte que le moteur n’a pas fondamentalement réussi à lire.

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 imputable à l’API et distincte de la latence du moteur (summary_metrics.csv latency_p50_ms).

L'enveloppe opérationnelle : là où se joue la vraie différence

La précision des caractères est à égalité, la précision des champs converge sous un LLM — mais un pipeline par lots ne se soucie ni de l'une ni de l'autre si les chiffres ne finissent pas. Sur la même RTX 4090 au même tarif enregistré de 0,76 $ de l'heure, docTR soutient 449,3 pages/min à 108,7 ms p50 par page pour 0,048 $ pour 1 000 pages ; Surya2 soutient 12,1 pages/min à 2 668,0 ms p50 pour 1,061 $ pour 1 000 pages — un écart de débit de 37×, un écart de latence de 24,5× et un écart de coût de 22,2×. Un pipeline dimensionné pour le rythme de Surya2 relève d'une tout autre conversation d'architecture qu'un pipeline dimensionné pour le rythme de docTR.

Le coût est calculé comme le temps d'exécution × le tarif RunPod RTX 4090 (0,76 $ de l'heure, prix horodaté dans les manifestes 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, y compris cette même initialisation. Les latences p50/p95 sont des temps d'inférence par page en régime permanent, mesurés à chaud puis notés (chargement du modèle exclu) ; la queue de distribution de Surya2 est proportionnellement pire — 5 872,2 ms en p95 contre 281,4 ms pour docTR — car les pics de préremplissage/décodage du VLM dominent la queue sur les premières pages.

Source : summary_metrics.csv — colonne latency_p50_ms, lignes sroie_2019. docTR 108,7166, Surya2 2667,9800. Latence en régime permanent (mode de mesure warm_then_scored).

Source : summary_metrics.csv — colonne cost_per_1000_pages, lignes sroie_2019. docTR 0,0479, Surya2 1,0609. Coût = temps d'exécution × 0,76 $/h, y compris l'initialisation du modèle, prix horodaté dans les manifestes d'exécution (août 2026).

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 de $0,76/h horodaté dans les manifests) ; le coût inclut l'initialisation du modèle, pas le débit pur en régime permanent. Valeurs exactes : docTR p50 108,7 / p95 281,4 / 449,3 pg/min / $0,0479 ; Surya2 p50 2668,0 / p95 5872,2 / 12,1 pg/min / $1,0609.

CORD (reçus indonésiens) : les deux moteurs s'effondrent, mis en quarantaine par le protocole

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 : CER 0,8959 (Surya2) et 0,9101 (docTR). Conformément au protocole de référence, les chiffres CORD sont tenus à l'écart de la comparaison SROIE — ils ne sont fusionnés dans aucun 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 du véritable décalage linguistique.

Sur les métriques de champ, le même schéma de divergence que pour SROIE se confirme, de manière resserrée : via les motifs regex, docTR ne récupère aucun champ (F1 de champ 0,0000 — un zéro littéral dans le CSV, pas une valeur manquante) car les motifs au format anglais n'ont rien trouvé dans le texte indonésien, tandis que la sortie normalisée de Surya2 extrait 0,2458. Le LLM reconverge ensuite la paire à 0,5500 (docTR) et 0,5203 (Surya2) — le choc linguistique est absorbé par le postprocesseur, pas par le moteur. 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.

Tableau : summary_metrics.csv (cer) et field_method_comparison.csv (F1 de champ), lignes cord_v2. Ne fusionnez pas ces chiffres dans un classement SROIE : le CER CORD combine un véritable décalage linguistique avec une inflation due à la structure d'annotation dans la vérité terrain ; les motifs regex ont été écrits pour des formats anglais. Le F1 de champ regex de docTR de 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. Ces deux moteurs se partagent nettement les axes, et ce partage est le constat : la précision des caractères est à égalité, la commodité des champs structurés favorise Surya2, tous les axes coût/latence/débit favorisent docTR, et un postprocesseur LLM rend le choix du moteur presque sans importance pour la qualité finale des champs.

Questions fréquentes

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

Non — sur la précision brute des caractères, ils sont statistiquement à égalité : CER SROIE 0,1915 (Surya2) contre 0,1971 (docTR), un écart de 0,006 point (summary_metrics.csv, cer, lignes sroie_2019). Là où ils diffèrent, c'est sur la sortie structurée des champs prête à l'emploi (Surya2 gagne 4,2× avec regex) et sur l'enveloppe opérationnelle (docTR gagne 24,5× sur la latence, 22,2× sur le coût, 37× sur le débit).

Pourquoi docTR a-t-il la meilleure précision de caractères mais la pire extraction de champs par regex ?

Parce que les deux métriques évaluent des sorties différentes. docTR renvoie un texte de ligne brut propre — en préservant la casse et les séparateurs d'origine — et les motifs regex fixes, écrits pour des valeurs formatées, échouent en grande partie contre lui : son F1 de champ regex SROIE est de 0,0766, le plus bas des huit moteurs de l'exécution sous-jacente, contre le deuxième meilleur CER (0,1971) (summary_metrics.csv cer, field_method_comparison.csv regex_field_value_f1). La sortie structurée par étiquettes et en minuscules de Surya2 correspond par hasard aux motifs à 0,3183. En les envoyant tous deux à un LLM, l'écart se réduit à 0,003 — la regex, pas l'OCR, était le goulot d'étranglement.

L'ajout d'un postprocesseur LLM rend-il docTR et Surya2 égaux ?

Presque exactement — docTR 0,6171 contre Surya2 0,6139 en F1 de champ LLM sur SROIE (field_method_comparison.csv, llm_field_value_f1, lignes sroie_2019). Le coût de cette convergence est un supplément d'environ 2,0–2,3 s de latence LLM médiane par document (llm_median_latency_ms, mêmes lignes), adapté au traitement par lots asynchrone plutôt qu'aux attentes synchrones par page.

De combien docTR est-il plus rapide et moins cher que Surya2 ?

24,5× de latence p50 inférieure (108,7 ms contre 2 668,0 ms), 37× de débit supérieur (449,3 contre 12,1 pages/min), et 22,2× de coût inférieur pour 1 000 pages (0,048 $ contre 1,061 $) sur la même RTX 4090 à 0,76 $/h (summary_metrics.csv, latency_p50_ms / pages_per_minute / cost_per_1000_pages, lignes sroie_2019).

Pourquoi les deux moteurs obtiennent-ils des scores si faibles sur les reçus CORD ?

Deux causes cumulatives que le protocole de référence maintient séparées du classement SROIE : un vrai décalage linguistique (les reçus indonésiens hors 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.8959 (Surya2) (summary_metrics.csv, cer, lignes cord_v2). Les métriques de champ absorbent une partie du choc une fois qu’un LLM est ajouté (0.5500 vs 0.5203), mais les lignes CORD sont citées et jamais regroupées dans un classement combiné.

Quel moteur un pipeline de reçus devrait-il choisir, docTR ou Surya2 ?

Cela dépend de l’axe que votre pipeline consomme. Pour le texte brut en volume avec un coût mesuré, l’enveloppe de docTR (108,7 ms, 449,3 pages/min, 0,048 $/1K pages) domine. Pour les champs structurés sans postprocesseur, le F1 regex prêt à l’emploi de Surya2 (0.3183 vs 0.0766) est le meilleur point de départ. Pour la qualité finale des champs avec posttraitement LLM, le choix importe à peine (0.6171 vs 0.6139). Ces résultats valent pour les reçus en anglais et en indonésien sur un niveau de GPU en août 2026 ; toute décision de production devrait être re-testée sur le corpus cible (voir Limitations).

D’où viennent les chiffres de cette page ?

Chaque figure est une ligne des CSV publiés de la référence interne — results/summary_metrics.csv (CER/WER, F1 sur les champs, latence, coût, débit) et results/field_method_comparison.csv (regex vs posttraitement 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 jeux de données proviennent des articles SROIE 2019 et CORD cités ci-dessous.

Méthodologie & sources

Protocole

Cette page présente un comparatif direct d'un benchmark indépendant et reproductible (niveau officiel) — pas une synthèse de revendications tierces, ni une page de comparaison de fournisseurs. Uniquement des ensembles de test fixes : test SROIE 2019 (361 reçus anglais, champs plats company/date/address/total) et test CORD v2 (100 reçus indonésiens, champs imbriqués menu/sub_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 préchauffage fixe précède le passage noté, afin que les chiffres de latence reflètent un état stable). Les deux exécutions se sont terminées avec error_rate 0.0 (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, et 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 : prêts à l'emploi, sans réglage fin. Versions verrouillées : docTR v1.0.1 (OCR neuronal traditionnel en deux étapes, GPU) et Surya2 (surya-ocr 0.22.1) (VLM de parsing de documents, servi par vLLM) — 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 de 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 jeu 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.

Définitions des métriques

• CER (taux d'erreur de caractère) : 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. Sensible à la casse et aux conventions de formatage — légèrement conservateur vis-à-vis de la sortie normalisée de Surya2 (normalisation de la casse, fusion étiquette/valeur).
• WER (taux d'erreur de mot) : le même calcul de distance d'édition au niveau des mots.
• F1 sur les valeurs de champ (regex) : moyenne harmonique précision/rappel sur les valeurs de champ extraites à l'aide de motifs regex fixes appliqués au 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 champ (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 combiné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 (mesuré après échauffement, hors chargement du modèle) et débit en temps réel incluant l'initialisation du modèle.
• Coût pour 1 000 pages : heures GPU facturées pour 1 000 pages au tarif enregistré de 0,76 $/h.

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, de latence, de coût et de débit sur cette page provient des lignes doctr et surya2 de ce fichier.
2. field_method_comparison.csv (GitHub raw). 16 lignes ; colonnes model, dataset, llm_model (= deepseek-v4-flash), précision et F1 des valeurs de champ regex/LLM, champs de document exacts, llm_median_latency_ms, nombres de jetons. Chaque valeur de F1 sur les champs regex/LLM provient des lignes doctr et surya2 de ce fichier.
3. Dépôt ImageToTableai/benchmark-ocr. Dépôt public hébergeant les CSV de résultats, les manifestes d'exécution 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 exécution publiée (16 exécutions) avec les versions de 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).

Limitations

• Portée du document — reçus uniquement : SROIE + CORD. Rien ici ne mesure la gestion des mises en page, tableaux, formules ou documents longs, là où les VLM de traitement de documents revendiquent leurs plus grands avantages ; les points forts commercialisés de Surya2 sont non mesurés. N'utilisez pas cette page pour conclure que « docTR gagne sur tout ».
• Taille de l'échantillon : 361 reçus en anglais + 100 en indonésien. Le F1 par champ et le CER dépendent du corpus ; des différences de quelques centièmes (y compris l'écart de CER de 0,006 et l'écart de F1-LLM de 0,003) doivent être considérées comme du bruit, et non 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, prix daté d'août 2026 dans les manifestes d'exécution. D'autres GPU, le service multi-GPU, la planification par lots ou les changements de prix modifieront la latence, le débit et le coût — recalculez les coûts aux tarifs actuels avant d'établir un budget.
• 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'ordre de convergence peut bouger à la marge. La latence du LLM (~2,0–2,3 s en médiane, field_method_comparison.csv llm_median_latency_ms) est due à l'API et ne fait pas partie de la latence propre de chaque 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 de meilleurs scores sur ses propres mises en page — au prix de la maintenance que le LLM élimine.
• 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 l'indonésien ; le CER de CORD (0,90–0,91) reflète un décalage linguistique + une inflation de la vérité terrain. Les lignes CORD sont citées avec leur contexte et ne sont jamais fusionnées dans un classement SROIE (règle de protocole).
• Équité du CER pour les VLM : le CER mesure les correspondances exactes de caractères, donc la sortie de Surya2, avec casse réduite et étiquettes fusionnées, est légèrement pénalisée pour des conventions de sortie, et non pour des erreurs de lecture (voir la référence connexe sur le CER). L'égalité du CER sous-estime donc légèrement Surya2 ; les métriques de champ sont la référence la plus équitable entre familles.
• Deux moteurs uniquement : ce face-à-face exclut délibérément les six autres moteurs de l'exécution sous-jacente, les services OCR cloud/API et les API VLM hébergées ; leurs modèles de latence et de tarification diffèrent fondamentalement des moteurs locaux mesurés ici.
• Épinglage de version : les résultats valent pour docTR v1.0.1 et Surya2 0.22.1 (août 2026). Les versions plus récentes de l'un ou l'autre moteur peuvent modifier tous les chiffres de cette page.

Références connexes : OCR traditionnel vs VLM de traitement de documents · où les expressions régulières échouent sur de vrais documents · pourquoi les comptages de caractères induisent en erreur l'extraction de champs · Précision de l'OCR des reçus

Lectures complémentaires : Précision de l'OCR IA vs OCR classique · extraction de données d'image vs moteurs OCR · Tarification de l'extraction de documents par IA (2026)