Tesseract vs PaddleOCR sur les reçus
CPU hérité vs GPU moderne (2026)

Ce que sont les deux moteurs : 35 ans d'OCR contre un pipeline CNN en deux étapes

Toute l'histoire de cette page est un écart d'architecture. Tesseract est le moteur OCR open-source classique — développé à l'origine chez HP dans les années 1980 et open-sourcé par Google en 2005, d'où ses quelque 35 ans d'héritage. Son pipeline est de la vision par ordinateur traditionnelle : binarisation adaptative, segmentation de page, analyse des composantes connexes 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 moderne d'apprentissage profond issu de l'écosystème PaddlePaddle : un pipeline en deux étapes dans la famille PP-OCR — une étape de détection qui localise les zones de texte (style DBNet), puis une étape de reconnaissance qui les transcrit — fonctionnant sur GPU. Un moteur lit en comparant les formes de 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, à la même machine.

Pourquoi ce mécanisme compte : 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é dans 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 rôle 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 à quel point le côté coût d'exploitation du compromis s'est révélé étroit.

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

Sur SROIE 2019, l'écart de précision du texte est important et unilatéral : CER 0,2045 contre 0,3347 (Tesseract) — une amélioration relative de 39% — et WER 0,3256 contre 0,5591, un écart relatif de 42%. Le CER de Tesseract de 0,3347 se classe cinquième des huit moteurs de l'exécution sous-jacente — en milieu de peloton, pas dernier — mais tous les moteurs au-dessus, sauf un, sont des moteurs d'apprentissage profond, et l'écart entre Tesseract et le niveau d'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 OCR classique : 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 du mot. Pour les deux, plus bas est mieux. L'écart de WER (42%) étant plus large que l'écart de CER (39%) signifie que les erreurs de caractères de Tesseract se cumulent en échecs de mots entiers sur ce corpus — le mode de défaillance 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 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 issu du même CSV : le CER SROIE sur les huit moteurs donne 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 de ces deux moteurs n'est le champion de précision du benchmark — docTR et Surya2 occupent les deux premières places en CER.

Extraction de champs : l'écart qui décide des choix de 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 postprocesseurs sur le texte OCR de chaque moteur : des expressions régulières fixes (l'approche traditionnelle OCR + extraction d'informations clés par règles) et un postprocesseur LLM (deepseek-v4-flash à température 0) avec une invite structurée. Par expressions régulières, PaddleOCR extrait les champs à 0.3254 de F1 de champs contre 0.2335 pour Tesseract — un avantage de 1.39× ; via le LLM, l'écart persiste à 0.5810 contre 0.4389 (1.32×). Le levier 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 une section plus bas.

Le F1 valeur-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. Les colonnes de champs regex SROIE correspondent aux métriques postprocessed_sroie_receipt_regex_* du benchmark : des motifs fixes appliqués au texte OCR de chaque moteur — post-traité, et non une sortie structurée native. Contexte de classement : le F1 regex de PaddleOCR de 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 au global (summary_metrics.csv, lignes field_f1_regex, sroie_2019) — le moteur classique est un extracteur de champs de niveau 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 stockées 0–1 affichées en %). Post-processeur LLM : deepseek-v4-flash (colonne llm_model). 361 échantillons par moteur (llm_ok_count).

Table : field_method_comparison.csv — colonnes regex et llm, lignes sroie_2019. Les colonnes regex sont les métriques postprocessed_sroie_receipt_regex_* : des 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 induite par l’API et distincte de la latence du moteur (summary_metrics.csv latency_p50_ms). « Docs with all fields exact » désigne 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 5e sur 8 ; Tesseract 0,4389 se classe 7e, devant seulement EasyOCR avec 0,3717.

La surprise : parité de débit CPU au temps réel

Le constat le plus marquant de cette page, qu’aucune comparaison tierce ne documente, est le suivant : sur les mêmes reçus, un moteur classique CPU uniquement égale un moteur GPU moderne en pages par minute au temps réel — 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 contredire les chiffres de latence, et mérite une réconciliation 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 à chaud puis notée, hors chargement du modèle — les 297,0 ms de PaddleOCR sont réellement plus rapides que les 670,9 ms de Tesseract. Les pages par minute correspondent au débit au temps réel de l’ensemble de l’exécution, y compris 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_per_minute) : PaddleOCR consacre environ 753 ms par page au temps réel contre une p50 de 297 ms — soit environ 456 ms par page d’initialisation/préremplissage et de surcharge de lot ; Tesseract consacre environ 763 ms par page au temps réel contre une p50 de 671 ms — soit environ 92 ms de surcharge. L’exécution CPU allégée de Tesseract démarre vite et s’écoule régulièrement ; le pipeline GPU de PaddleOCR paie un coût de chargement/préremplissage plus lourd par exécution, qui annule presque son avantage en régime permanent sur ce corpus de 361 pages. Un pipeline à chaud de longue durée voit l’avantage par page de PaddleOCR ; un pipeline dominé par les démarrages à froid, les petits lots ou les réinitialisations fréquentes voit les deux moteurs à parité, voire avec un avantage côté classique.

La queue p95 raconte la même histoire en un chiffre : la p95 de Tesseract, à 1 507,0 ms, est 2,2× plus resserrée que celle de PaddleOCR, à 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 par page au temps réel — domine sa pire queue, tandis que le moteur CPU ne présente aucun pic de ce type. 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 en temps réel, y compris l'initialisation du modèle ; la latence en régime permanent par page correspond à la colonne latency_p50_ms (voir le graphique ci-dessous). Réconciliation : 60 ÷ 78.63285 = 763 ms/page contre 60 ÷ 79.71298 = 753 ms/page en 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 en régime permanent (mode de mesure warm_then_scored, exclut le chargement du modèle). La tension entre p50 et pages/min est réconciliée dans le texte ci-dessus : horloges différentes, 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 en régime permanent par page (évaluation à chaud, exclut le chargement du modèle) ; les pages/min sont en temps réel, y compris l'initialisation 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.

Le coût : là où le moteur historique l’emporte nettement

Le coût est le seul axe où l’ancienneté de Tesseract est un avantage, et il est structurel : Tesseract est exclusivement CPU, sa cellule de coût dans le CSV est donc vide par conception — aucune facturation GPU à mesurer — tandis que PaddleOCR facture 0,2214 $ pour 1 000 pages sur la même RTX 4090 au tarif enregistré de 0,76 $/h. Pour une charge liée au débit (la parité ci-dessus), le coût d’exploitation du moteur classique sur une infrastructure sans facturation GPU est nettement inférieur — c’est le point de référence pour la décision « la mise à niveau en vaut-elle la peine ».

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 manifestes d’exécution), y compris l’initialisation du modèle. La cellule Tesseract vide n’est pas un zéro — c’est une valeur manquante parce que le moteur n’a jamais touché le GPU ; le benchmark l’enregistre comme vide plutôt que de supposer un nombre (règle de protocole : une cellule vide est not_applicable, jamais 0). Deux chiffres de contexte assurent cette honnêteté : les 0,2214 $ de PaddleOCR se situent dans la moyenne des sept moteurs GPU (docTR détient la ligne GPU la moins chère du benchmark à 0,048 $ pour 1 000 pages), et sur CORD, le coût de PaddleOCR monte à 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 CPU uniquement, aucune facturation GPU — tracé comme omis, pas zéro. Coût = temps d’exécution réel × 0,76 $/h, y compris l’initialisation du modèle, prix horodaté dans les manifestes d’exécution (août 2026). Moteur GPU le moins cher du benchmark : 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 (vide, pas 0,0000) parce que le moteur est CPU uniquement ; le coût GPU de PaddleOCR inclut l’initialisation du modèle au tarif enregistré de 0,76 $/h. 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) : effondrement des deux moteurs — et le plus grand écart de champs du benchmark se creuse

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 inter-langues — et les deux s'effondrent sur le CER brut : 0,9083 (PaddleOCR) et 0,9523 (Tesseract), un match nul dû à l'inadéquation linguistique. Conformément au 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.

Là où les deux moteurs se démarquent vraiment, c'est sur le levier de champ LLM, et c'est le point de données le plus fort de cette page : grâce au postprocesseur LLM, le F1 de champ 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 tout le benchmark. Cet écart de 0,39 point est la plus grande différence entre deux lignes de champs LLM frères de l'exécution. Le mécanisme est l'argument du plafond rendu concret : le texte CORD de Tesseract est trop illisible (CER 0,9523) pour qu'un postprocesseur — regex ou LLM — puisse en extraire les 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 un texte que le moteur n'a jamais lu. 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 (field F1), lignes cord_v2. Ne fusionnez pas les chiffres CORD dans un classement SROIE : le CER CORD combine un véritable 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 des deux moteurs chute à environ 1–8 %). Contexte du 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 entre lignes frères le plus large du benchmark. La cellule de coût de Tesseract est vide (CPU uniquement), jamais 0.

Qui gagne quand : la grille récapitulative

“Mieux” dépend de la charge de travail, et ce face-à-face sépare 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).

Questions fréquentes

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

Oui — sur tous les axes de précision mesurés dans ce benchmark. Sur SROIE 2019 : CER 0,2045 contre 0,3347 (amélioration relative de 39 %), WER 0,3256 contre 0,5591 (42 %), F1 du champ regex 0,3254 contre 0,2335 (1,39×), F1 du champ post-traité par LLM 0,5810 contre 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 du benchmark — Surya2 (CER 0,1915) et docTR (0,1971) détiennent ce titre.

Pourquoi Tesseract égalise-t-il PaddleOCR en pages par minute malgré son fonctionnement uniquement sur CPU ?

Parce que les pages par minute mesurent le débit en temps réel, pas la vitesse d’inférence par page. Le p50 en régime permanent 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 consacre ~753 ms par page en temps réel contre son p50 de 297 ms, tandis que le runtime CPU allégé de Tesseract consacre ~763 ms par page contre son p50 de 671 ms — le moteur GPU paie un coût de chargement/prefill plus lourd à chaque exécution, ce 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 serrée que celle de PaddleOCR ?

Parce que le pic de première page/prefill du moteur GPU domine sa queue de distribution la plus défavorable : p95 de PaddleOCR 3 331,4 ms contre p95 de Tesseract 1 507,0 ms, une inversion de 2,2× de 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 diffuse en continu ; le régime permanent rapide de PaddleOCR s’accompagne d’un chemin d’initialisation plus lourd à chaque exécution. Les deux horloges mesurent des choses différentes et toutes deux sont réelles.

Tesseract est-il moins cher que PaddleOCR ?

Sur facturation GPU, oui — Tesseract n'en a pas : il est CPU uniquement, donc sa cellule de coût dans le CSV est vide par conception (jamais 0), tandis que PaddleOCR facture 0,2214 $ par 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 dans l'ensemble est docTR à 0,048 $ par 1 000 pages.

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

Parce que le postprocesseur 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 — effectivement 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é du texte de base.

Pourquoi les deux moteurs obtiennent-ils d'aussi mauvais résultats sur les reçus CORD ?

Deux causes cumulatives que le protocole sépare du classement SROIE : un véritable décalage linguistique (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 vérité terrain de CORD — le CER atteint 0,9083 (PaddleOCR) et 0,9523 (Tesseract) (summary_metrics.csv, cer, lignes cord_v2). Ce qui les distingue encore, c'est la récupération en aval par LLM : PaddleOCR 0,5527 contre Tesseract 0,1627 en F1 de champ — l'écart le plus large entre lignes sœurs du benchmark. Les lignes CORD sont citées avec cadrage et jamais regroupées dans un classement combiné.

Quel moteur un pipeline de reçus devrait-il choisir, Tesseract ou PaddleOCR ?

Si votre pipeline consomme des champs — valeurs extraites pour l'entreprise, la date, les totaux — PaddleOCR est le choix par défaut évident pour les reçus : 1,39× le F1 des champs avec regex, 1,32× avec un LLM, et une récupération en aval par LLM qui survit au choc linguistique CORD (field_method_comparison.csv). Si vous avez besoin de texte brut à haut volume sur des documents anglais propres avec zéro coût GPU, une infrastructure CPU uniquement, ou une prévisibilité de latence de queue, Tesseract reste une option légitime : le débit en temps réel est équivalent (79,7 contre 78,6 pages/min), le p95 est 2,2× plus serré, et il n'y a pas de facturation GPU — mais prévoyez une base de texte de milieu de peloton (CER 0,3347, 5e sur 8) qui plafonne chaque pipeline de champs en aval. Ces résultats valent pour les reçus anglais et indonésiens sur un niveau de GPU en août 2026 ; relancez sur votre corpus cible avant les décisions de production (voir Limitations).

D'où viennent les chiffres de cette page ?

Chaque chiffre est une ligne des CSV publiés du benchmark propriétaire — results/summary_metrics.csv (CER/WER, F1 des 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 (post-traitement 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 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 d'une exécution de benchmark indépendante et reproductible (niveau officiel) — pas une enquête sur des affirmations de tiers, et pas une page de comparaison de fournisseurs. Uniquement des découpages 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 découpages 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é, donc les chiffres de latence sont en régime permanent). Les deux exécutions se sont terminées avec error_rate 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 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 sous le même protocole. L'exécution 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 machine avec une NVIDIA RTX 4090 (24 Go) ; le coût GPU est calculé au tarif à la demande de RunPod de 0,76 $/h, le prix étant horodaté dans le manifeste expurgé 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 ajustement fin. Versions verrouillées : Tesseract 5.3.4 (moteur OCR open source classique — pipeline CV traditionnel avec reconnaissance basée sur LSTM, CPU uniquement, exécuteur python3 système, sans environnement GPU) et PaddleOCR 3.7.0 (OCR moderne d'apprentissage profond en deux étapes — détection + reconnaissance PP-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 ; non applicable à Tesseract (CPU uniquement).
• 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, et non 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è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 de valeur de champ (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 + 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 de valeur 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 mélangés.
• Exactitude des champs de document : fraction de documents où tous les champs cibles correspondent exactement — une barre bien plus stricte que le F1 par champ.
• Latence p50/p95 et pages/min : temps d'inférence par page en régime permanent (échauffé puis noté, hors chargement du modèle) et débit en temps 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 $/h, y compris l'initialisation du modèle. La cellule de Tesseract est vide (CPU uniquement) — 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 de cette page provient des lignes tesseract et paddleocr de ce fichier (tesseract : compute_type=cpu, cellule coût vide).
2. field_method_comparison.csv (GitHub raw). 16 lignes ; colonnes model, dataset, llm_model (= deepseek-v4-flash), précision et F1 des valeurs de champs regex/llm, document-fields-exact, llm_median_latency_ms, nombre de jetons. Chaque valeur de F1 de champs regex/LLM provient des lignes tesseract et paddleocr de ce fichier (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 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 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).

Limites

• L'asymétrie CPU/GPU est inhérente, pas un défaut : Tesseract a été exécuté 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 avec le même protocole — une autre classe de machine pourrait modifier son enveloppe de fonctionnement. Considérez la comparaison des coûts comme « facturation GPU vs aucune », pas comme une vérité indépendante du matériel.
• Périmètre documentaire — 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 des documents longs — des types de documents où les moteurs classiques sont connus pour se dégrader davantage — ni les capacités de mise en page/tableaux 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 de quelques centièmes 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× de F1 regex, l'écart de 0,39 point de LLM-F1 sur CORD) soient bien au-delà de cette bande.
• Un seul niveau de GPU et un seul prix : tous les chiffres GPU proviennent d'un seul RTX 4090 à 0,76 $/h, prix horodaté août 2026 dans les manifestes 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 d'établir un budget.
• Un seul postprocesseur LLM : toutes les lignes LLM utilisent deepseek-v4-flash à température 0. Un LLM différent modifie le F1 absolu par champ ; les écarts de 1,32× sur SROIE et de 0,39 point sur CORD peuvent bouger à la marge. La latence du LLM (~1 817–1 837 ms médianes sur SROIE, llm_median_latency_ms dans field_method_comparison.csv) est due à l'API et ne fait pas partie de la latence propre de l'un ou l'autre moteur.
• Réglage des regex : le jeu de motifs a été écrit une fois par ensemble de données. Une bibliothèque de motifs fortement réglée par format pourrait obtenir un score plus élevé sur ses propres mises en page — au prix de la maintenance que le LLM élimine.
• Le CER CORD n'est pas une lecture de qualité par modèle : la vérité terrain CORD intègre la structure d'annotation et aucun des deux moteurs n'a été entraîné principalement sur de l'indonésien ; le CER CORD (0,91–0,95) 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 de protocole).
• Épinglage de version : les résultats valent pour Tesseract 5.3.4 et PaddleOCR 3.7.0 (août 2026). Les versions plus récentes de l'un ou l'autre moteur peuvent modifier chaque chiffre de cette page ; les résultats de Tesseract reflètent spécifiquement la version 5.3.4 et ont été re-vérifiés lors d'une exécution répétée le 14/08/2026.

Références associées : Benchmark de reçus PaddleOCR vs EasyOCR · Benchmark de reçus docTR vs Surya2 · la comparaison de huit moteurs d'OCR et de VLM · règles fixes vs modèles de langage pour les champs · pourquoi un nombre de caractères correct peut encore signifier un champ erroné

Lectures complémentaires : l'écart de précision entre l'IA et l'OCR traditionnel · pourquoi l'extraction par IA surpasse l'OCR sur les images · Tarifs de l'extraction de documents par IA (2026)