Tesseract vs PaddleOCR sur les reçus
CPU ancien vs GPU moderne (2026)

Ce que sont les deux moteurs : 35 ans d'OCR vs un pipeline CNN à deux étages

L'histoire de cette page est une question d'écart architectural. Tesseract est le moteur OCR open-source classique — initialement développé chez HP dans les années 1980 et open-source par Google en 2005, ce qui lui confère environ 35 ans de lignée. Son pipeline est de la vision par ordinateur traditionnelle : binarisation adaptative, segmentation de page, analyse de composants connectés et reconnaissance de caractères — basée sur LSTM depuis la version 4 — le tout s'exécutant sur CPU sans facturation GPU dans ce benchmark (compute_type = cpu dans le CSV). PaddleOCR est un moteur d'apprentissage profond moderne issu de l'écosystème PaddlePaddle : un pipeline à deux étages de la famille PP-OCR — une étape de détection qui localise les régions de texte (style DBNet), puis une étape de reconnaissance qui les transcrit — s'exécutant sur GPU. Un moteur lit en faisant correspondre les formes des caractères à des motifs appris ; l'autre lit en apprenant où se trouve le texte et ce qu'il dit. Ce benchmark soumet les deux aux mêmes reçus, au même protocole, sur la même machine.

Pourquoi ce mécanisme est important : l'approche de Tesseract est peu coûteuse à exécuter et ne nécessite pas de GPU — mais son modèle de caractères est figé depuis des décennies de reconnaissance classique, ce qui se traduit par un plafond dur sur la qualité du texte. L'approche de PaddleOCR coûte du temps GPU mais lit un texte nettement plus propre. Le travail du benchmark est de chiffrer les deux côtés de ce compromis à partir d'une seule exécution contrôlée — et la surprise est de constater à quel point le côté coût de fonctionnement du compromis s'est avéré étroit.

Précision des caractères : l'architecture moderne gagne sur toutes les métriques de texte

Sur SROIE 2019, l'écart de précision du texte est large et unilatéral : CER 0.2045 vs 0.3347 (Tesseract) — une amélioration relative de 39% — et WER 0.3256 vs 0.5591, un écart relatif de 42%. Le CER de Tesseract de 0.3347 se classe cinquième sur les huit moteurs de l'exécution sous-jacente — milieu de peloton, pas dernier — mais chaque moteur au-dessus de lui, à l'exception d'un, est un moteur d'apprentissage profond, et l'écart entre Tesseract et le niveau apprentissage profond (meilleur : Surya2 0.1915, docTR 0.1971) est plus grand que l'écart entre ces moteurs et PaddleOCR (0.2045, troisième).

Le taux d'erreur de caractères (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.335 signifie environ 33,5 caractères mal lus pour 100. Le taux d'erreur de mots (WER) applique le même calcul de distance d'édition au niveau des mots. Les deux sont « plus bas c'est mieux ». Le fait que l'écart WER (42%) soit plus large que l'écart CER (39%) signifie que les erreurs de caractères de Tesseract se cumulent en échecs de mots entiers sur ce corpus — le mode d'échec classique qu'un extracteur de champs en aval hérite directement.

Source : summary_metrics.csv — colonnes cer et wer, lignes sroie_2019. PaddleOCR cer 0.20449 / wer 0.32563 ; Tesseract cer 0.33468 / wer 0.55915. Plus bas c'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 : Tesseract cer 0.33468 / wer 0.55915 ; PaddleOCR cer 0.20449 / wer 0.32563. Un CER/WER plus bas est meilleur. Contexte de classement du même CSV : Le CER SROIE sur les huit moteurs est surya2 0.1915, doctr 0.1971, PaddleOCR 0.2045 (3e), easyocr 0.2833, Tesseract 0.3347 (5e), paddleocr_vl 0.3370, docling 0.5909, unlimited_ocr 0.6552. Aucun des deux moteurs ici n'est le champion de précision du benchmark — docTR et Surya2 détiennent les deux premières places en CER.

Extraction de champs : l'écart qui décide des choix en production

La précision du texte classe les moteurs ; l'extraction de champs est ce que les systèmes en aval consomment réellement. Les métriques de champs SROIE du benchmark ciblent quatre champs de reçus simples (entreprise, date, adresse, total) en utilisant deux post-processeurs sur le texte OCR de chaque moteur : des modèles regex fixes (l'approche traditionnelle OCR + extraction d'informations clés basée sur des règles) et un post-processeur LLM (deepseek-v4-flash à température 0) avec un prompt structuré. Via regex, PaddleOCR extrait les champs avec un F1 de champ de 0.3254 contre 0.2335 pour Tesseract — un avantage de 1,39× ; via le LLM, l'écart persiste à 0,5810 contre 0,4389 (1,32×). L'avantage du LLM aide les deux moteurs, mais il part de la base plus faible de Tesseract — et l'argument du plafond qui décide des pipelines de production se trouve dans la section suivante.

La valeur F1 du 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. Les colonnes de champs regex SROIE sont les métriques postprocessed_sroie_receipt_regex_* du benchmark : des motifs fixes appliqués au texte OCR de chaque moteur — post-traité, pas la sortie structurée native. Contexte de classement : le F1 regex de PaddleOCR à 0,3254 est le meilleur parmi les quatre moteurs purement traditionnels du benchmark à 8 moteurs (derrière seulement Unlimited-OCR 0,3376 et PaddleOCR-VL 0,3368) ; celui de Tesseract à 0,2335 est le quatrième meilleur résultat regex global (summary_metrics.csv, field_f1_regex, lignes sroie_2019) — le moteur classique est un extracteur de champs moyen sur du texte anglais propre, ce qui est précisément là où il cesse d'être compétitif.

Source : field_method_comparison.csv — colonnes regex_field_value_f1 / llm_field_value_f1, lignes sroie_2019 (décimales 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 et llm, lignes sroie_2019. Les colonnes regex sont les métriques postprocessed_sroie_receipt_regex_* : motifs fixes appliqués au texte OCR de chaque moteur. Postprocesseur 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). « Docs with all fields exact » est la fraction de documents où chaque champ cible correspond exactement — un critère bien plus strict que le F1 par champ. Contexte de classement (llm_field_value_f1, toutes les lignes sroie_2019) : PaddleOCR 0,5810 se classe 5ᵉ sur 8 ; Tesseract 0,4389 se classe 7ᵉ, devant uniquement EasyOCR avec 0,3717.

La surprise : parité de débit CPU à l'horloge réelle

La découverte à la une de la page est celle que personne ne documente dans ses comparaisons tierces : sur les mêmes reçus, un moteur classique exclusivement CPU égale un moteur GPU moderne en pages par minute à l'horloge réelle — 78,6 contre 79,7 (PaddleOCR), soit environ 1,4% d'écart, une parité statistique. Le moteur classique n'est pas « lent en volume » : il est lent par page mais régulier — et sur ce corpus, il dépasse quatre des sept moteurs GPU de l'exécution sous-jacente (docling 56,7, paddleocr_vl 68,2, unlimited_ocr 34,4, surya2 12,1 pages/min).

Cela semble contradictoire avec les chiffres de latence et mérite une explication honnête plutôt qu'une note de bas de page. La latence p50 est l'inférence par page en régime permanent, mesurée après chauffe puis notée, avec le chargement du modèle exclu — les 297,0 ms de PaddleOCR sont réellement plus rapides que les 670,9 ms de Tesseract. Les pages par minute sont le débit à l'horloge réelle de l'exécution complète, incluant l'initialisation du modèle et les effets de lot. Convertissez le débit du CSV en temps réel par page (60 secondes ÷ pages_par_minute) : PaddleOCR passe ~753 ms par page à l'horloge réelle contre un p50 de 297 ms — soit environ 456 ms par page d'initialisation/préremplissage et de surcharge de lot ; Tesseract passe ~763 ms par page à l'horloge réelle contre un p50 de 671 ms — soit environ 92 ms de surcharge. L'environnement d'exécution CPU dépouillé de Tesseract démarre vite et fonctionne de manière régulière ; le pipeline GPU de PaddleOCR paie un coût plus élevé de chargement/préremplissage par exécution qui annule presque son avantage en régime permanent sur ce corpus de 361 pages. Un pipeline long et chaud verra l'avantage par page de PaddleOCR ; un pipeline dominé par des démarrages à froid, de petits lots ou des réinitialisations fréquentes verra les deux moteurs à parité ou mieux du côté classique.

La queue p95 raconte la même histoire en un seul chiffre : le p95 de Tesseract de 1 507,0 ms est 2,2× plus resserré que celui de PaddleOCR de 3 331,4 ms. Le pic de première page/préremplissage du moteur GPU — le même chemin de chargement qui gonfle son temps réel par page — domine sa pire queue, tandis que le moteur CPU n'a pas un tel pic. Pour les charges de travail sensibles à la latence de queue ou planifiées en capacité, le moteur classique est le plus prévisible.

Source : summary_metrics.csv — colonne pages_per_minute, lignes sroie_2019. Tesseract 78.63285, PaddleOCR 79.71298. Pages/min temps réel incluant l'initialisation du modèle ; la latence par page à régime établi est la colonne latency_p50_ms (voir graphique ci-dessous). Réconciliation : 60 ÷ 78.63285 = 763 ms/page vs 60 ÷ 79.71298 = 753 ms/page temps réel.

Source : summary_metrics.csv — colonnes latency_p50_ms / latency_p95_ms, lignes sroie_2019. Tesseract p50 670,87 / p95 1506,99 ; PaddleOCR p50 296,99 / p95 3331,35. Latence à régime établi (mode de mesure warm_then_scored, exclut le chargement du modèle). La tension p50-vs-pages/min est réconciliée dans le texte ci-dessus : différentes horloges, toutes deux réelles.

Tableau : summary_metrics.csv — latency_p50_ms / latency_p95_ms / pages_per_minute, lignes sroie_2019. Valeurs exactes : Tesseract p50 670,87 / p95 1506,99 / 78,63 pg/min ; PaddleOCR p50 296,99 / p95 3331,35 / 79,71 pg/min. La latence est par page à régime établi (chaud puis mesuré, exclut le chargement du modèle) ; les pages/min sont en temps réel incluant l'init et les effets de lot — la parité et l'inversion du p95 sont des faits liés au modèle de mesure et à l'architecture, pas des contradictions.

L'histoire des coûts : où le moteur historique l'emporte clairement

Le coût est le seul axe où l'ancienneté de Tesseract est un avantage, et c'est un avantage structurel : Tesseract est uniquement CPU, donc sa cellule de coût dans le CSV est vide par conception — pas de facturation GPU à mesurer — tandis que PaddleOCR facture $0,2214 pour 1 000 pages sur le même RTX 4090 au tarif enregistré de $0,76/heure. Pour une charge de travail liée au débit (la parité ci-dessus), le coût de fonctionnement du moteur classique sur une infrastructure sans facturation GPU est matériellement plus bas — l'ancre de prix pour la décision « la mise à jour en vaut-elle la peine ».

Le coût est calculé comme le temps d'exécution horloge × le tarif RunPod RTX 4090 ($0,76/heure, prix horodaté dans les manifests d'exécution), incluant l'initialisation du modèle. La cellule vide de Tesseract n'est pas un zéro — c'est une valeur manquante car le moteur n'a jamais touché le GPU ; l'essai l'enregistre comme vide plutôt que de supposer un chiffre (règle du protocole : une cellule vide est not_applicable, jamais 0). Deux chiffres de contexte garantissent l'honnêteté : les $0,2214 de PaddleOCR sont au milieu du peloton des sept moteurs GPU (docTR détient la ligne GPU la moins chère de l'essai à $0,048 pour 1 000 pages), et sur CORD le coût de PaddleOCR augmente à $0,3419 pour 1 000 pages à 141,0 pages/min.

Source : summary_metrics.csv — colonne cost_per_1000_pages, lignes sroie_2019. PaddleOCR 0,2214. La valeur de Tesseract est vide (cellule vide dans le CSV) : type de calcul uniquement CPU, pas de facturation GPU — tracé comme omis, pas zéro. Coût = temps d'exécution horloge × $0,76/heure incluant l'init du modèle, prix horodaté dans les manifests d'exécution (août 2026). Moteur GPU le moins cher de l'essai : docTR $0,048 pour 1 000 pages (ligne doctr/sroie_2019).

Tableau : summary_metrics.csv — colonnes cost_per_1000_pages / compute_type, lignes sroie_2019. La cellule de coût de Tesseract est vide (blanche, pas 0,0000) car le moteur est uniquement CPU ; le coût GPU de PaddleOCR inclut l'initialisation du modèle au tarif enregistré de $0,76/heure. Sur CORD, le coût de PaddleOCR est de $0,3419 pour 1 000 pages à 141,0 pages/min (ligne paddleocr/cord_v2).

CORD (reçus indonésiens) : Les deux s'effondrent — et le plus grand écart de champs du benchmark s'ouvre

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) fonctionne comme un test de résistance interlingue — et les deux s'effondrent sur le CER brut : 0.9083 (PaddleOCR) et 0.9523 (Tesseract), un échec lié à l'inadéquation linguistique. Selon le protocole du benchmark, les chiffres 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 une structure d'annotation, ce qui gonfle le CER brut pour chaque moteur en plus de l'inadéquation linguistique réelle.

Là où les deux moteurs se séparent vraiment, c'est sur le levier de champs LLM, et c'est le point de données le plus fort de cette page : via le post-traitement LLM, le F1 de champs CORD de PaddleOCR se maintient à 0.5527 — le meilleur des huit moteurs sur CORD — tandis que celui de Tesseract s'effondre à 0.1627, le pire des huit moteurs de l'ensemble du benchmark. Cet écart de 0,39 point est le plus large entre deux lignes LLM-champs sœurs de l'exécution. Le mécanisme est l'argument du plafond rendu concret : le texte CORD de Tesseract est suffisamment illisible (CER 0,9523) pour qu'aucun post-traitement — regex ou LLM — ne puisse en extraire des champs. Le levier LLM aide (le F1 SROIE de Tesseract passe de 0,2335 en regex à 0,4389 en LLM), mais il part d'une base plus faible et ne peut pas fabriquer du texte que le moteur n'a jamais lu. 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 par regex des deux moteurs s'effondre à ~1–8%). Contexte de classement (llm_field_value_f1, toutes les lignes cord_v2) : PaddleOCR 0,5527 est le meilleur des huit ; Tesseract 0,1627 est le pire des huit — l'écart le plus large entre lignes frères du benchmark. La cellule de coût de Tesseract est vide (CPU uniquement), jamais 0.

Qui gagne quand : le tableau récapitulatif

“Mieux” dépend de la charge de travail, et cette confrontation divise les axes avec une clarté inhabituelle : chaque axe de précision favorise PaddleOCR ; le coût, la simplicité CPU et la queue p95 serrée favorisent Tesseract ; le débit en temps réel est une égalité statistique ; la latence par page favorise PaddleOCR ; et le championnat du CER brut n'appartient à aucun des deux (docTR/Surya2).

Foire aux questions

PaddleOCR est-il plus précis que Tesseract pour les reçus ?

Oui — sur chaque axe de précision mesuré dans ce benchmark. Sur SROIE 2019 : CER 0,2045 vs 0,3347 (amélioration relative de 39 %), WER 0,3256 vs 0,5591 (42 %), F1 des champs regex 0,3254 vs 0,2335 (1,39×), F1 des champs post-traités par LLM 0,5810 vs 0,4389 (1,32×) (summary_metrics.csv et field_method_comparison.csv, lignes sroie_2019). Aucun des deux moteurs n'est le champion global du texte dans ce benchmark — Surya2 (CER 0,1915) et docTR (0,1971) détiennent ce titre.

Pourquoi Tesseract est-il au niveau de PaddleOCR en pages par minute malgré un fonctionnement uniquement sur CPU ?

Parce que les pages par minute mesurent le débit en temps réel, et non la vitesse d'inférence par page. Le p50 en régime stable de PaddleOCR (297,0 ms) est réellement 2,3× plus rapide que celui de Tesseract (670,9 ms), mais le débit en temps réel inclut l'initialisation du modèle et les effets de lot : à 79,7 pages/min, PaddleOCR passe ~753 ms par page en temps réel contre son p50 de 297 ms, tandis que l'environnement CPU dépouillé de Tesseract passe ~763 ms par page contre son p50 de 671 ms — le moteur GPU paie un coût plus élevé de chargement/préremplissage par exécution qui annule presque son avantage de vitesse sur ce corpus de 361 pages (summary_metrics.csv, pages_per_minute / latency_p50_ms, lignes sroie_2019).

Pourquoi la latence p95 de Tesseract est-elle plus resserrée que celle de PaddleOCR ?

Parce que le pic de la première page/préremplissage du moteur GPU domine son cas le plus défavorable : PaddleOCR p95 3 331,4 ms vs Tesseract p95 1 507,0 ms, une inversion de 2,2× par rapport à l'ordre du p50 (summary_metrics.csv, latency_p95_ms, lignes sroie_2019). Le pipeline CPU de Tesseract n'a pas de pic de chargement et fonctionne de manière régulière ; l'état stable rapide de PaddleOCR s'accompagne d'un chemin d'initialisation plus lourd à chaque exécution. Les deux horloges mesurent des choses différentes et les deux sont réelles.

Tesseract est-il moins cher que PaddleOCR ?

Sur la facturation GPU, oui — Tesseract n'en a pas : il est uniquement CPU, donc sa cellule de coût dans le CSV est vide par conception (jamais 0), tandis que PaddleOCR facture 0,2214 $ pour 1 000 pages sur SROIE et 0,3419 $ sur CORD, sur le même RTX 4090 à 0,76 $/h avec coût incluant l'initialisation du modèle (summary_metrics.csv, cost_per_1000_pages, lignes sroie_2019 et cord_v2). Le moteur GPU le moins cher du benchmark est docTR à 0,048 $ pour 1 000 pages.

Pourquoi le F1 de champ LLM de Tesseract sur CORD est-il le pire de tout le benchmark ?

Parce que le post-traitement LLM ne peut pas récupérer le texte que le moteur OCR n'a jamais lu. Le CER de Tesseract sur CORD est de 0,9523 — pratiquement illisible sur les reçus indonésiens — donc son F1 de champ LLM s'effondre à 0,1627, le pire des huit moteurs, tandis que celui de PaddleOCR se maintient à 0,5527, le meilleur des huit (field_method_comparison.csv, llm_field_value_f1, lignes cord_v2). Le même levier sur du texte anglais propre (SROIE) élève Tesseract à 0,4389 — mais le plafond est fixé par la qualité de base du texte.

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,9083 (PaddleOCR) et 0,9523 (Tesseract) (summary_metrics.csv, cer, lignes cord_v2). Ce qui les sépare encore est la récupération en aval par LLM : F1 de champ 0,5527 pour PaddleOCR contre 0,1627 pour Tesseract — l'écart le plus large entre lignes sœurs du benchmark. Les lignes CORD sont citées avec un cadrage et ne sont jamais regroupées dans un classement combiné.

Quel moteur choisir pour un pipeline de reçus, Tesseract ou PaddleOCR ?

Si votre pipeline exploite des champs — valeurs extraites pour l'entreprise, la date, les totaux — PaddleOCR est le choix évident par défaut pour les reçus : 1,39× de F1 sur les champs avec regex, 1,32× avec un LLM, et une récupération en aval via LLM qui résiste au choc linguistique du CORD (field_method_comparison.csv). Si vous avez besoin de texte brut en volume sur des documents anglais propres, sans coût GPU, sur une infrastructure CPU uniquement, ou avec une prévisibilité de latence extrême, Tesseract reste une option légitime : débit horaire équivalent (79,7 vs 78,6 pages/min), p95 2,2× plus serré, et aucune facturation GPU — mais prévoyez une base de texte de milieu de peloton (CER 0,3347, 5e sur 8) qui limite chaque pipeline de traitement de champs en aval. Ces résultats s'appliquent aux reçus en anglais et en indonésien sur un seul niveau de GPU en août 2026 ; relancez-les sur votre corpus cible avant toute décision de production (voir Limitations).

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 sur champs regex, latence, coût, débit ; les lignes tesseract portent compute_type=cpu et une cellule de coût vide) et results/field_method_comparison.csv (comparaison regex vs post-traitement LLM, llm_model = deepseek-v4-flash) — hébergés sur ImageToTableai/benchmark-ocr, avec un manifest.json partiellement caviardé 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 une tranche comparative directe 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 partitions de test fixes : test SROIE 2019 (361 reçus anglais, champs plats entreprise/date/adresse/total) et test CORD v2 (100 reçus indonésiens, champs imbriqués menu/sous_total/total) ; les partitions d'entraînement n'ont jamais été évaluées. 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 noté, donc les chiffres de latence sont en régime permanent). Les deux exécutions se sont terminées avec un taux d'erreur de 0,0 sur les deux jeux de données (colonne error_rate de summary_metrics.csv). L'asymétrie CPU/GPU est inhérente à cette comparaison : Tesseract a tourné sur CPU (compute_type=cpu) face à des moteurs accélérés par GPU, par conception — sa cellule de coût est vide car aucun temps GPU n'a été facturé, et sa latence/débit ont été mesurés sur la même machine selon le même protocole. L'exécution sous-jacente contenait 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 la même machine avec un NVIDIA RTX 4090 (24 Go) ; le coût GPU est calculé au tarif à la demande de RunPod de $0,76/heure, le prix étant horodaté dans le manifeste édité de chaque exécution (août 2026). Tesseract a tourné sur CPU et n'a engendré aucun coût GPU ; sa cellule de coût est vide par conception.
• Moteurs : prêts à l'emploi, sans affinage. Versions verrouillées : Tesseract 5.3.4 (moteur OCR open-source classique — pipeline CV traditionnel avec reconnaissance basée sur LSTM, uniquement CPU, exécuteur python3 système, pas d'environnement GPU) et PaddleOCR 3.7.0 (OCR deep-learning moderne en deux étapes — détection + reconnaissance PP-OCR, GPU) — d'après 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 (la 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/heure, incluant l'initialisation du modèle — le traitement par lots réduit le coût par page ; non applicable à Tesseract (uniquement CPU).
• 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ées.

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 bas est mieux.
• WER (Taux d'erreur de mot) : le même calcul de distance d'édition au niveau du mot.
• F1 sur la valeur du 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 qu'aucune valeur de champ n'a été récupérée.
• F1 sur la valeur du 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 mélangés.
• Exactitude document-champs : fraction des documents où tous les champs cibles correspondaient exactement — un critère beaucoup 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é, exclut le chargement du modèle) et débit réel incluant l'initialisation du modèle. Ils mesurent des horloges différentes ; la parité p50-vs-pages/min sur cette page est un fait du modèle de mesure, pas une erreur, et est réconciliée dans la section Parité de débit.
• Coût pour 1 000 pages : heures GPU facturées pour 1 000 pages au tarif enregistré de $0,76/heure, incluant l'initialisation du modèle. La cellule de Tesseract est vide (uniquement CPU) — une cellule vide est not_applicable, jamais 0.

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 sur cette page provient des lignes tesseract et paddleocr ici (tesseract : compute_type=cpu, cellule de coût vide).
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 valeur F1 de champ regex/LLM provient des lignes tesseract et paddleocr ici (et des huit lignes sroie_2019 / cord_v2 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 expurgé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 expurgé 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 de la tâche 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

• L'asymétrie CPU/GPU est inhérente, pas un défaut : Tesseract s'exécutait sur CPU contre des moteurs accélérés par GPU. Sa cellule de coût est vide par conception (pas de facturation GPU, jamais 0), et sa latence/débit sont des chiffres CPU mesurés sur la même machine selon le même protocole — une classe de machine différente pourrait déplacer son enveloppe de fonctionnement. Considérez la comparaison de coût comme « facturation GPU vs aucune », pas comme une vérité indépendante du matériel.
• Périmètre document — reçus uniquement : SROIE + CORD. Rien ici ne mesure le comportement de Tesseract sur des mises en page complexes, des tableaux, de l'écriture manuscrite ou de longs documents — des types de documents où les moteurs classiques sont connus pour se dégrader davantage — ni les capacités de mise en page/tableau PP-Structure de PaddleOCR. N'utilisez pas cette page pour conclure que l'un ou l'autre moteur « gagne sur tout ».
• Taille de l'échantillon : 361 reçus en anglais + 100 en indonésien. Le F1 par champ et le CER sont sensibles au corpus ; des différences d'un ou deux chiffres après la virgule doivent être traitées comme du bruit, pas comme une vérité d'ingénierie — bien que les écarts documentés ici (39% de CER, 1,39× le F1 regex, l'écart de 0,39 point pour le CORD LLM-F1) soient bien au-delà de cette marge.
• Un seul niveau de GPU et un seul prix : tous les chiffres GPU 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 post-processeur LLM : toutes les lignes LLM utilisent deepseek-v4-flash à température 0. Un LLM différent modifierait le F1 absolu par champ ; les écarts de 1,32× pour SROIE et de 0,39 point pour CORD pourraient évoluer en marge. La latence LLM (~1 817–1 837 ms médian sur SROIE, champ llm_median_latency_ms dans field_method_comparison.csv) est imputable à l'API et ne fait pas partie de la latence propre à l'un ou l'autre moteur.
• Paramétrage 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 un score plus élevé sur ses propres mises en page — au coût de 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 moteurs n'a été principalement entraîné sur de l'indonésien ; le CER de CORD (0,91–0,95) reflète l'inadéquation linguistique + la surestimation 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 de protocole).
• Verrouillage des versions : les résultats sont valables pour Tesseract 5.3.4 et PaddleOCR 3.7.0 (août 2026). De nouvelles versions de l'un ou l'autre moteur pourraient modifier chaque chiffre de cette page ; les résultats de Tesseract reflètent spécifiquement la version 5.3.4 et ont été revérifiés lors d'une exécution de répétition le 2026-08-14.

Références connexes : PaddleOCR vs EasyOCR Receipt Benchmark · docTR vs Surya2 Receipt Benchmark · Traditional OCR vs Document Parsing VLMs · Regex vs LLM Field Extraction · Field-Level vs Character-Level Accuracy

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