docTR vs Surya2 : OCR de reçus
Comparatif direct (2026)

Le taux d'erreur de caractère (CER) est la mesure classique de l'OCR : insertions, suppressions et substitutions divisées par les caractères de référence — un CER de 0,197 signifie environ 19,7 caractères mal lus pour 100. Le taux d'erreur de mot (WER) applique le même calcul de distance d'édition au niveau du mot. C'est la dimension où les deux moteurs sont inséparables.

Sur SROIE 2019, docTR et Surya2 sont les deux meilleurs reconnaissateurs de caractères du benchmark, séparés par 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

L'égalité est importante car 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, préservant la casse et la mise en page brutes du texte imprimé. Surya2 est un modèle de vision-langage d'analyse de documents : il lit l'image entière du document et produit du texte compris — casse unifiée, paires étiquette/valeur fusionnées, lignes réordonnées — ce qui se rapproche de ce que les systèmes en aval souhaitent mais s'éloigne des correspondances exactes de caractères. Le CER évalue les correspondances exactes de caractères, il est donc légèrement conservateur envers Surya2 ; le fait que l'égalité survive 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 meilleur ; les deux exécutions se sont terminées avec error_rate 0,0.

Là où ils divergent : l'extraction de champs hors de la boîte inverse le résultat

Testez le texte brut des moteurs avec les mêmes expressions régulières 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 : Surya2 extrait les champs avec un F1 de 0,3183 contre 0,0766 pour docTR, un avantage de 4,2×. docTR a la précision de caractères la meilleure de sa classe et la pire extraction de champs par regex dans le test des huit moteurs — la précision du texte et la précision des champs sont décorrélées.

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 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 unifiée, paires clé-valeur fusionnées) correspond beaucoup plus souvent à ces motifs, tandis que le texte brut de docTR — précis selon le CER, mais avec la casse originale 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 basée sur des règles en aval, pas 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).

Tableau : field_method_comparison.csv — colonnes regex, lignes sroie_2019. Ce sont les métriques postprocessed_sroie_receipt_regex_* : motifs fixes appliqués au texte OCR de chaque moteur (post-traité, pas extraction native). Le F1 sur les valeurs de champ de docTR avec regex de 0,0766 est le plus bas des huit moteurs dans l'exécution sous-jacente malgré le deuxième meilleur CER.

Le levier LLM : le choix du moteur n'a plus d'importance

Alimentez le texte OCR des deux moteurs à un postprocesseur LLM (deepseek-v4-flash, température 0) avec un prompt d'extraction structurée, et l'écart sur les valeurs de champ disparaît presque : docTR 0,6171 contre Surya2 0,6139 de 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éterminant.

C'est le même schéma observé sur l'ensemble du benchmark à huit moteurs : le post-traitement LLM tire les moteurs performants vers une bande convergente de F1 sur les valeurs de champ car il comprend la sémantique (nombres, dates, noms) au lieu de correspondre aux formes des caractères. Le texte de base plus propre de docTR prend une mince avance ; la structure normalisée de Surya2 perd cet infime avantage sous l'effet du LLM. Le levier a deux coûts : 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, coûts d'API et de même nature), et il ne peut pas sauver un texte qu'un moteur a fondamentalement échoué à 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 un coût d'API et est séparée de la latence du moteur (summary_metrics.csv latency_p50_ms).

L'enveloppe opérationnelle : où réside 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 de l'un ni de l'autre si les chiffres ne suivent pas. Sur la même RTX 4090 au même tarif horaire enregistré de $0,76/heure, docTR maintient 449,3 pages/min à 108,7 ms p50 par page pour $0,048 pour 1 000 pages ; Surya2 maintient 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é au rythme de Surya2 est une conversation d'architecture différente de celui dimensionné au rythme de docTR.

Le coût est calculé comme durée d'exécution réelle × le tarif horaire de la RTX 4090 sur RunPod ($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 réelles par minute incluant cette même initialisation. Les latences p50/p95 sont les temps d'inférence par page en régime stable mesurés à chaud puis scorés (chargement du modèle exclu) ; la queue de Surya2 est proportionnellement pire — 5 872,2 ms 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 stable (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 = durée d'exécution réelle × $0,76/heure incluant l'initialisation du modèle, prix horodaté dans les manifests 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 horaire de $0,76 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 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/sub_total/total) sert de test de résistance interlingue — et les deux s'effondrent : CER 0.8959 (Surya2) et 0.9101 (docTR). Selon le protocole de référence, les chiffres de CORD sont maintenus en quarantaine de la comparaison SROIE — ils ne sont pas intégrés à aucun classement — car le texte de vérité terrain de CORD intègre une 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 champ, le même schéma de divergence par rapport à SROIE se confirme, comprimé : via des expressions régulières, docTR ne récupère aucun champ (0.0000 field F1 — un zéro littéral dans le CSV, pas une valeur manquante) car les motifs au format anglais ne correspondaient à rien dans le texte indonésien, tandis que la sortie normalisée de Surya2 atteint 0.2458. Le LLM ré-converge 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 est délibéré de ne jamais le regrouper avec les chiffres SROIE dans un classement unique.

Tableau : summary_metrics.csv (cer) et field_method_comparison.csv (field F1), lignes cord_v2. Ne pas fusionner ces chiffres dans un quelconque classement SROIE : le CER de CORD combine une véritable inadéquation linguistique avec un gonflement de la structure d'annotation dans la vérité terrain ; les expressions régulières ont été rédigées pour des formats anglais. Le F1 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 répartissent proprement les axes, et cette répartition est la découverte : la précision des caractères est à égalité, la commodité des champs structurés favorise Surya2, chaque axe coût/latence/débit favorise docTR, et un postprocesseur LLM rend le choix du moteur quasiment sans importance pour la qualité finale des champs.

Foire aux questions

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

Non — en termes de 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). La différence se situe dans la sortie structurée des champs hors de la boîte (Surya2 gagne 4,2× avec regex) et 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 des caractères mais la pire extraction de champs par regex ?

Parce que les deux métriques évaluent des sorties différentes. docTR renvoie du texte brut de lignes propre — préservant la casse et les séparateurs originaux — et les motifs regex fixes, conçus pour des valeurs formatées, échouent majoritairement face à lui : son F1 sur les valeurs de champ regex SROIE est de 0,0766, le plus bas des huit moteurs dans 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 de Surya2, avec casse normalisée et structure de labels, correspond par hasard aux motifs à 0,3183. Alimentez les deux par un LLM à la place et l'écart se réduit à 0,003 — c'était le regex, et non l'OCR, qui é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 F1 sur les valeurs de champ LLM sur SROIE (field_method_comparison.csv, llm_field_value_f1, lignes sroie_2019). Le coût de cette convergence est une latence LLM médiane supplémentaire d'environ 2,0 à 2,3 s par document (llm_median_latency_ms, mêmes lignes), adaptée au traitement par lots asynchrone plutôt qu'à des attentes synchrones page par page.

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 le même RTX 4090 à $0,76/hr (summary_metrics.csv, latency_p50_ms / pages_per_minute / cost_per_1000_pages, lignes sroie_2019).

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

Deux causes cumulatives que le protocole de référence 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.8959 (Surya2) (summary_metrics.csv, lignes cer, cord_v2). Les métriques de champ absorbent une partie du choc une fois qu'un LLM est ajouté (0.5500 contre 0.5203), mais les lignes CORD sont citées et ne sont jamais regroupées dans un classement combiné.

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

Cela dépend de l'axe que votre pipeline consomme. Pour du texte brut en volume à coût mesuré, l'enveloppe de docTR (108,7 ms, 449,3 pages/min, 0,048 $/1K pages) domine. Pour des champs structurés sans aucun postprocesseur, le F1 regex hors boîte de Surya2 (0,3183 contre 0,0766) est un meilleur point de départ. Pour une qualité de champ finale avec posttraitement LLM, le choix importe peu (0,6171 contre 0,6139). Ces résultats s'appliquent aux reçus anglais et indonésiens sur un seul niveau de GPU en août 2026 ; toute décision de production devrait être relancée sur le corpus cible (voir Limites).

D'où viennent les chiffres de cette page ?

Chaque chiffre est une ligne des CSV publiés du benchmark interne — results/summary_metrics.csv (CER/WER, F1 de champ, 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 partiellement masqué 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 de tiers, ni une page de comparaison de 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 traité les mêmes images, les mêmes vérités terrain et le même protocole de mesure (warm_then_scored : un passage de chauffage fixe précède le passage mesuré, de sorte que les chiffres de latence sont en régime permanent). Les deux exécutions se sont terminées avec un error_rate de 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 le même NVIDIA RTX 4090 (24 Go) ; le coût GPU est 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 : configuration par défaut, sans affinage. Versions verrouillées : docTR v1.0.1 (OCR neuronal traditionnel à deux étapes, GPU) et Surya2 (surya-ocr 0.22.1) (VLM d'analyse de document, servi via 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 des 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. Ils 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 (Character Error Rate) : 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 meilleur. Sensible à la casse et aux conventions de formatage — légèrement conservateur par rapport à la sortie normalisée de Surya2 (fusion de casse, fusion étiquette/valeur).
• WER (Word Error Rate) : le même calcul de distance d'édition au niveau du mot.
• F1 sur les valeurs de champ (regex) : moyenne harmonique précision/rappel sur les valeurs de champ 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 aucune valeur de champ 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 du document exacts : fraction des documents où tous les champs cibles correspondent exactement — un critère beaucoup plus strict que le F1 par champ.
• Latence p50/p95 & pages/min : temps d'inférence par page en régime permanent (après chauffe puis mesure, exclut le 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/heure.

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. Tous les chiffres de CER/WER, latence, coût et débit sur cette page proviennent des lignes doctr et surya2 ici.
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, document-fields-exact, llm_median_latency_ms, compteurs de tokens. Tous les chiffres de F1 des valeurs de champ regex/LLM proviennent des lignes doctr et surya2 ici.
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 reproduction.
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 du 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).

Limitations

• Périmètre du document — reçus uniquement : SROIE + CORD. Rien ici n'évalue la gestion de la mise en page, des tableaux, des formules ou des documents longs, où les VLM d'analyse de documents revendiquent leurs plus grands avantages ; les forces commercialisées de Surya2 sont non mesurées. N'utilisez pas cette page pour conclure « docTR gagne sur tout. »
• Taille de l'échantillon : 361 reçus en anglais + 100 reçus en indonésien. Le F1 sur les valeurs de champ et le CER sont sensibles au corpus ; les écarts d'un seul chiffre de quelques centièmes (y compris l'écart de CER de 0,006 et l'écart de F1-LLM de 0,003) doivent être traités 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, le prix étant 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 à une température de 0. Un LLM différent modifie le F1 absolu sur les valeurs de champ ; l'ordre de convergence peut se déplacer en périphérie. La latence du LLM (~2,0–2,3 s médiane, 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 seule fois par jeu de données. Une bibliothèque de motifs fortement optimisée par format pourrait obtenir de meilleurs scores sur ses propres mises en page — au prix de la maintenance que le LLM supprime.
• 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 une inadéquation linguistique + une inflation de la vérité terrain. Les lignes CORD sont citées avec un contexte et ne sont jamais fusionnées dans un quelconque classement SROIE (règle du protocole).
• Équité du CER pour les VLM : le CER mesure les correspondances exactes de caractères, donc la sortie de Surya2, avec ses conventions de fusion des étiquettes et de pliage de casse, est légèrement pénalisée pour ses 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 au niveau des valeurs de champ sont la barre inter-familles la plus équitable.
• Deux moteurs uniquement : cette confrontation 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.
• Verrouillage des versions : les résultats sont valables pour docTR v1.0.1 et Surya2 0.22.1 (août 2026). De nouvelles versions de l'un ou l'autre moteur peuvent modifier chaque chiffre de cette page.

Références connexes : OCR traditionnel vs VLM d'analyse de documents · Regex vs extraction de valeurs de champ par LLM · Précision au niveau des valeurs de champ vs au niveau des caractères · Précision de l'OCR de reçus

Lectures connexes : Précision de l'OCR par IA vs OCR traditionnel · Extraction d'images de données par IA vs OCR traditionnel · Tarification de l'extraction de documents par IA (2026)