OCR traditionnel vs VLM d'analyse de documents
Résultats du benchmark sur reçus (2026)

Le taux d'erreur de caractères (CER) mesure la fraction de caractères individuels mal lus — suppressions, insertions et substitutions divisées par les caractères de référence. C'est la mesure classique de l'OCR, et c'est là que le récit de la « supériorité des VLM » s'effondre sur les reçus en anglais.

Sur SROIE 2019, les deux meilleurs reconnaisseurs de texte sont un VLM et un moteur traditionnel, séparés de 0,006 point : Surya2 à 0,191 et docTR à 0,197, avec PaddleOCR troisième (0,204). Les trois autres VLM — PaddleOCR-VL 0,337, Docling 0,591, Unlimited-OCR 0,655 — se situent au niveau ou en dessous des moteurs traditionnels comme EasyOCR (0,283) et Tesseract (0,335).

Précision des caractères par modèle sur SROIE (reçus en anglais)

Source : summary_metrics.csv — colonne cer, lignes sroie_2019 (8 lignes). Surya2 0,1915, docTR 0,1971, PaddleOCR 0,2045, EasyOCR 0,2833, Tesseract 0,3347, PaddleOCR-VL 0,3370, Docling 0,5909, Unlimited-OCR 0,6552. Plus bas = mieux. Tesseract est limité au CPU.

Tableau : summary_metrics.csv — colonnes cer et wer, lignes sroie_2019, 361 échantillons chacune (error_rate 0.0 pour les 8 modèles). CER = taux d'erreur de caractères, WER = taux d'erreur de mots ; plus bas, c'est mieux. Valeurs exactes : Surya2 cer 0.19147 / wer 0.27352 ; docTR cer 0.19707 / wer 0.31990.

Le taux d'erreur de mots raconte la même histoire avec une granularité différente : il évalue les erreurs au niveau des mots entiers plutôt que des caractères. Surya2 mène le WER à 0.274, docTR suit à 0.320. À noter la valeur aberrante en bas : Unlimited-OCR a le pire CER (0.655) mais un WER dans la moyenne (0.478) — sa sortie est fortement normalisée en casse et en format (une convention de sortie discutée dans la section méthodologie), ce qui gonfle les modifications au niveau des caractères même lorsque les mots sont largement intacts.

Docling mérite une note de classification avant d'apparaître dans les comparaisons : ce n'est ni un moteur OCR traditionnel pur, ni un VLM. Docling est un analyseur en pipeline — une chaîne d'outils par étapes qui exécute l'analyse de mise en page, la détection de tableaux et la reconstruction de l'ordre de lecture autour d'un cœur OCR. Sur un simple reçu, cette surcharge de pipeline apporte peu, ce qui explique en partie pourquoi son CER brut (0,591 sur SROIE) est inférieur à celui des moteurs à passage unique.

Coût et latence : l'avantage des moteurs traditionnels

Si la précision des caractères ne départage pas les deux familles, le coût et la latence décident presque tout. Sur la même répartition de test, docTR soutient 449 pages/min à 108,7 ms p50 par page pour 0,048 $ pour 1 000 pages ; Surya2 soutient 12 pages/min à 2 668 ms p50 pour 1,061 $ pour 1 000 pages — soit environ 37× le débit, 24,5× la latence par page, et 22× le coût pour mille pages.

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) — le prix que vous paieriez réellement pour le temps GPU, y compris l'initialisation du modèle. Tesseract est le cas particulier : CPU uniquement, il n'a aucun coût GPU et atteint tout de même 78,6 pages/min sur SROIE ; sa cellule de coût est vide dans le CSV par conception, non pas parce qu'il est gratuit, mais parce qu'il ne consomme aucune heure GPU facturée.

Source : summary_metrics.csv — colonne latency_p50_ms, lignes sroie_2019. docTR 108,7, PaddleOCR 297,0, EasyOCR 413,6, Tesseract 670,9 (CPU), PaddleOCR-VL 694,3, Docling 732,0, Unlimited-OCR 1600,7, Surya2 2668,0. Latence en régime permanent, mode de mesure warm-then-scored (exclut le chargement du modèle).

Source : summary_metrics.csv — colonne cost_per_1000_pages, lignes sroie_2019. docTR 0,0479, EasyOCR 0,1098, PaddleOCR-VL 0,2048, PaddleOCR 0,2214, Unlimited-OCR 0,3879, Docling 0,3978, Surya2 1,0609. Tesseract CPU uniquement : cellule vide dans le CSV (aucun coût GPU) ; le coût inclut l'initialisation du modèle, pas le débit pur en régime permanent.

Tableau : summary_metrics.csv — latency_p50_ms / latency_p95_ms / pages_per_minute / cost_per_1000_pages, lignes sroie_2019. Exécutions GPU sur RTX 4090 ($0.76/h, prix horodatés dans les manifests) ; Tesseract exécuté en CPU uniquement (cellule de coût vide, pas zéro). Le débit correspond aux pages/min en temps réel, y compris l'initialisation du modèle.

La colonne de latence en queue de distribution compte si vous vous souciez du pire scénario, pas seulement des médianes. Le p95 de PaddleOCR de 3 331 ms et celui de Docling de 3 240 ms sont loin de leurs valeurs p50 — les effets de première page et les pics de préremplissage dominent la queue sur les moteurs GPU — tandis que le p95 de docTR (281 ms) reste serré. Pour les charges de travail interactives (un utilisateur attendant une page), cet écart de p95 fait la différence entre une attente de 0,3 seconde et une attente de plus de 3 secondes.

CORD (reçus indonésiens) : décalage linguistique et inflation de la vérité terrain

CORD v2 est un jeu de données de reçus en langue indonésienne avec des champs imbriqués (menu, sub_total, total). Aucun des 8 moteurs n'a été principalement entraîné sur des reçus indonésiens. CORD sert donc de test de résistance interlinguistique — et le CER de chaque moteur s'effondre à 0,90–1,08. Ces chiffres doivent être lus en gardant à l'esprit que le texte de la vérité terrain de CORD intègre la structure d'annotation, ce qui gonfle le CER brut de chaque moteur ; les résultats CORD sont strictement séparés du classement SROIE et ne peuvent pas être fusionnés en un seul classement.

Deux forces distinctes poussent le CER de CORD vers 1,0, et une seule d'entre elles est la langue elle-même. Premièrement, la langue : les moteurs entraînés sur l'anglais lisent réellement mal les mots indonésiens — les noms indonésiens, les adresses de rue et les formats de devise (Rp) sont en dehors de leurs distributions d'entraînement. Deuxièmement, la vérité terrain : les annotations textuelles publiées de CORD intègrent la structure d'annotation (étiquettes de champs avec coordonnées) plutôt que le texte visible pur, donc le CER brut mesure la distance d'édition par rapport à une chaîne structurellement augmentée. Les exemples VLM les plus propres sont pénalisés le plus durement — PaddleOCR-VL avec un CER de 1,080 est l'artefact extrême de ce mécanisme, et non une lecture de sa qualité textuelle.

La comparaison équitable entre familles sur CORD est donc la métrique de champ, et non le CER (voir la section suivante). Ce que les colonnes CER montrent encore utilement, c'est que le décalage linguistique est réel et universel à travers les architectures — chaque famille, traditionnelle et VLM, se situe dans la même bande de 0,90–1,08 sans avantage structurel pour l'une ou l'autre.

Tableau : summary_metrics.csv — colonne cer, lignes cord_v2, 100 échantillons chacun. Ne comparez pas ces chiffres à SROIE dans un classement combiné : le CER CORD cumule un véritable décalage linguistique et une inflation de la structure d'annotation dans la vérité terrain (méthodologie ci-dessous). Un CER supérieur à 1,0 (PaddleOCR-VL 1.0805) est un artefact de distance d'édition dû à cette vérité terrain gonflée.

Champ F1 : le post-traitement LLM resserre l'écart

La précision des caractères classe les moteurs ; l'extraction de champs est ce que les utilisateurs en production paient réellement. Le benchmark extrait quatre champs de reçu (entreprise, date, adresse, total) à partir du texte OCR de chaque moteur à l'aide de deux post-processeurs — des expressions régulières fixes (l'approche traditionnelle OCR + KIE basée sur des règles) et un LLM (deepseek-v4-flash) avec une invite structurée. Résultat : le LLM efface presque l'écart entre les moteurs sur SROIE, ramenant six des huit moteurs dans une bande de F1 champ de 0,57–0,62 — alors que leurs résultats en regex étaient répartis sur une plage de 0,26 point.

Le F1 de valeur de champ est la moyenne harmonique de la précision et du rappel sur les valeurs de champs extraites, évaluée par rapport à la vérité terrain — 1,0 signifie que chaque valeur de champ est parfaitement extraite, 0 signifie que rien n'est récupéré. Les colonnes regex utilisent un jeu de motifs fixe par jeu de données ; les colonnes LLM utilisent deepseek-v4-flash à température 0 pour une sortie déterministe (colonne llm_model dans le CSV de comparaison). Les deux métriques mesurent des pipelines différents et ne sont jamais combinées.

Source : field_method_comparison.csv — colonnes regex_field_value_f1 / llm_field_value_f1, lignes sroie_2019 (décimales stockées 0–1 affichées en %). Post-processeur LLM : deepseek-v4-flash (colonne llm_model). 361 échantillons par moteur (llm_ok_count).

Tableau : field_method_comparison.csv — regex_field_value_f1 / llm_field_value_f1, lignes sroie_2019. LLM = post-traitement deepseek-v4-flash (colonne llm_model). docTR regex 0.0766 → LLM 0.6171 (multiplication par 8,1×) ; les 6 moteurs non retardataires s'échelonnent de 0.5685–0.6171.

Deux résultats contre-intuitifs ressortent de ce tableau. Premièrement, docTR affiche le pire F1 champ regex sur SROIE (0.077) et le meilleur F1 champ LLM (0.617) — le même texte OCR propre que regex a réduit à 7,7 % des champs a atteint 61,7 % sous le LLM. Le post-processeur, et non l'OCR, était le goulot d'étranglement. Deuxièmement, les deux moteurs qui sortent de la bande 0.57–0.62 sont exactement ceux dont la base OCR est dégradée : EasyOCR (0.372, CER SROIE 0.283) et Tesseract — dont le résultat CORD (F1 champ LLM 0.163) montre qu'un LLM ne peut pas extraire des champs d'un texte qu'il ne peut fondamentalement pas lire (CER CORD 0.9523). Le plafond de tout post-processeur est la qualité de la base OCR qui le sous-tend.

Sur CORD, le LLM absorbe aussi une partie du choc linguistique : le F1 champ du LLM se maintient entre 0,47 et 0,55 pour les moteurs sains (PaddleOCR 0,553, docTR 0,550, PaddleOCR-VL 0,520, Surya2 0,520) alors que les regex s'effondrent presque à zéro (docTR 0,0, EasyOCR 0,7 %) — les motifs ont été écrits pour des formats anglais, et la pénalité d'« une langue de plus » est payée presque entièrement par les règles, pas par le LLM (field_method_comparison.csv, llm_field_value_f1 / regex_field_value_f1, lignes cord_v2).

Pourquoi le CER sous-estime les VLM d'analyse de documents

Le CER compare caractère par caractère la sortie du VLM à la vérité terrain, et les VLM sont pénalisés pour deux comportements légitimes qui ne sont pas des erreurs de reconnaissance : la normalisation de casse et la fusion étiquette/valeur. La décomposition du CER du benchmark sur SROIE attribue environ 18 % du CER des VLM à des différences de format de casse (par ex., TAN CHAY YEE → tan chay yee) et environ 10 % à la fusion de lignes ou à des lignes séparatrices supprimées — alors que les valeurs de champs elles-mêmes (entreprise, total, date) sont en réalité correctes (analyse de décomposition du CER consignée dans les notes de protocole du benchmark, exécutions SROIE).

La tension de conception est réelle et structurelle : les moteurs OCR traditionnels produisent du texte brut avec la casse intacte, ils sont donc optimisés par conception pour le score CER ; les VLM d'analyse de documents produisent du texte « compris » (casse normalisée, paires étiquette-valeur fusionnées, lignes réordonnées), ce qui est plus proche de ce qu'un système en aval souhaite mais plus éloigné des correspondances caractère par caractère. C'est pourquoi le titre de la page n'utilise le CER que là où il s'agit d'une comparaison équitable entre sorties similaires, et pourquoi la comparaison équitable entre familles réside dans les métriques de champs — et pourquoi le CER de CORD (qui porte en plus une inflation due à la structure d'annotation) est confiné à sa propre section. Le point plus large : un écart de CER entre familles n'est pas automatiquement un écart de précision, et quiconque compare des modèles entre familles devrait vérifier ce que mesure le CER avant de conclure qu'une famille « lit mieux ».

Comment choisir : quel axe compte pour votre charge de travail

« Mieux » n'a pas de sens sans charge de travail. La conclusion honnête du benchmark est que les deux familles gagnent sur des axes différents, et les reçus mesurent précisément les axes où les moteurs traditionnels gagnent et les axes où le post-traitement — et non la famille de moteurs — détermine la qualité des champs.

Les conseils de sélection sont dérivés directement des lignes CSV citées ; il s'agit d'une aide à la lecture fondée sur les données, pas d'une recommandation de fournisseur. Vos résultats exacts varient selon le matériel, le mélange de documents et les versions de modèles.

Questions fréquentes

Les VLM d'analyse de documents sont-ils plus précis que l'OCR traditionnel sur les reçus ?

Pas sur la précision brute des caractères — le meilleur VLM et le meilleur moteur traditionnel sont statistiquement à égalité sur SROIE 2019 (Surya2 CER 0.191 contre docTR 0.197, lignes sroie_2019 de summary_metrics.csv), et PaddleOCR (0.204) est troisième. Lorsque l'extraction de champs est l'objectif, VLM ou non, le post-traitement par LLM est le facteur décisif (bande de convergence 0.57–0.62, field_method_comparison.csv).

Quand l'OCR traditionnel est-il plus pertinent qu'un VLM d'analyse de documents ?

Lorsque le volume est élevé, que le coût est mesuré ou que la latence est interactive. Sur SROIE, docTR a traité 449 pages/min à $0.048 pour 1 000 pages et 108,7 ms p50 ; Surya2 a traité 12 pages/min à $1.061 pour 1 000 pages et 2 668 ms p50 (summary_metrics.csv, lignes doctr et surya2 sroie_2019). Pour une attente interactive par page, la différence est de 0,1 seconde contre 2,7 secondes.

Pourquoi les VLM d'analyse de documents obtiennent-ils parfois de moins bons scores CER que l'OCR bon marché ?

Parce que le CER mesure les correspondances exactes de caractères, et que les VLM sont pénalisés pour la normalisation de casse et la fusion étiquette/valeur qui sont des conventions de sortie, pas des erreurs de lecture. La décomposition CER du benchmark sur SROIE attribue environ 18% du CER des VLM à des différences de format de casse et ~10% à la fusion de lignes/séparateurs supprimés — alors que les valeurs de champs elles-mêmes sont souvent correctes (voir Méthodologie). Le CER de CORD est en outre gonflé par la structure d'annotation dans sa vérité terrain, c'est pourquoi cette page isole le CER de CORD de tout classement et utilise des métriques de champs pour la comparaison inter-familles.

Combien coûte l'OCR de reçus par page sur une RTX 4090 ?

Entre 0,048 $ (docTR) et 1,061 $ (Surya2) pour 1 000 pages sur une RTX 4090 à 0,76 $/h, prix horodaté d'août 2026 dans les manifests d'exécution (lignes sroie_2019 de summary_metrics.csv cost_per_1000_pages). Tesseract est limité au CPU et ne consomme aucune heure GPU. Le coût inclut l'initialisation du modèle, donc le coût par page diminue à mesure que la taille du lot augmente.

Pourquoi chaque modèle obtient-il un CER supérieur à 0,90 sur les reçus CORD ?

Deux causes cumulées : un décalage linguistique réel (reçus indonésiens hors de la zone d'entraînement de chaque moteur) et une inflation de la structure d'annotation dans le texte de référence de CORD. Aucune famille n'y échappe — les 8 modèles se situent dans la bande 0,90–1,08 (lignes cord_v2 de summary_metrics.csv cer). CORD est un jeu de stress de robustesse linguistique et de mise en page, conservé séparé du classement SROIE.

Un LLM corrigera-t-il simplement ma mauvaise sortie OCR ?

Seulement jusqu'à la qualité du texte de base. Sur SROIE, le LLM a hissé six moteurs dans une bande de F1 champ de 0,57–0,62 quel que soit le moteur (field_method_comparison.csv), mais le cas CORD de Tesseract montre le plancher : à un CER de 0,9523, son F1 champ LLM est de 0,163 — un LLM ne peut pas extraire des champs d'un texte qu'il ne peut pas lire.

Quel est l'OCR le plus rapide pour les reçus ?

docTR dans ce benchmark : 108,7 ms p50 par page et 449 pages/min sur SROIE 2019 (summary_metrics.csv doctr/sroie_2019 : latency_p50_ms, pages_per_minute). Le plus lent testé, Surya2, était 24,5 fois plus lent en p50 (2 668 ms) et 37 fois plus lent en débit (12 pages/min).

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 (8 modèles × 2 jeux de données : CER/WER, F1 champ, latence, coût, débit) et results/field_method_comparison.csv (post-traitement regex vs LLM) — 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 la comparaison d'analyse de documents issue d'un benchmark indépendant et reproductible (niveau officiel) — et non une synthèse de revendications tierces. Uniquement des ensembles 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 ensembles d'entraînement n'ont jamais été évalués. Chaque paire (modèle × ensemble de données) réutilise les mêmes images, la même vérité terrain et le même protocole de mesure (warm_then_scored : une passe d'échauffement fixe précède la passe notée, afin que les chiffres de latence soient en régime permanent). Les 16 exécutions ont été complétées avec un error_rate de 0,0 (colonne error_rate de summary_metrics.csv).

Environnement d'exécution

• Matériel : toutes les exécutions GPU sur une NVIDIA RTX 4090 (24 Go) ; coût GPU calculé au tarif à la demande de RunPod de 0,76 $/h, avec l'horodatage du prix enregistré dans le manifeste expurgé de chaque exécution (août 2026). Tesseract a fonctionné uniquement sur CPU et n'a aucun coût GPU (cellule de coût vide dans le CSV).
• Moteurs : tous les modèles exécutés tels quels, sans réglage fin. Versions verrouillées selon les manifestes d'exécution.
• Post-traitement LLM : deepseek-v4-flash via API à température 0 pour une sortie déterministe (colonne llm_model dans field_method_comparison.csv) ; c'était le seul modèle utilisé pour toutes les lignes de champs LLM.
• 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 SROIE sont postprocessed_sroie_receipt_regex_* / variantes LLM — c'est-à-dire des champs extraits du texte OCR par un ensemble fixe d'expressions régulières ou le LLM. Elles mesurent l'OCR plus l'extraction en aval, et non la sortie structurée native des modèles.

Versions telles qu'enregistrées dans le tableau des modèles du benchmark (README.md) et dans les manifestes expurgés par exécution (results/manifests/, un par exécution publiée, 16 au total) — chaque manifeste enregistre l'identifiant d'exécution, la version du modèle, le hash du script d'exécution, le GPU/pilote, les versions torch/CUDA/Python, le hash pip-freeze, les métadonnées de coût avec horodatage du prix et les hash d'artefacts pour la reproductibilité.

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. Sensible à la casse et aux conventions de formatage.
• WER (taux d'erreur de mots) : même calcul de distance d'édition au niveau des mots.
• F1 champ (regex) : moyenne harmonique précision/rappel sur les valeurs de champs extraites à l'aide de motifs regex fixes appliqués au texte OCR (OCR traditionnel + pipeline KIE basé sur des règles). Colonne : regex_field_value_f1.
• F1 champ (LLM) : même métrique sur la sortie du post-processeur LLM (texte OCR → deepseek-v4-flash → champs). Colonne : llm_field_value_f1. Les deux pipelines sont différents et ne sont jamais combinés.
• Latence p50/p95 & 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 ; vide pour Tesseract (CPU uniquement).

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 d'une ligne 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 champs regex/LLM, document-fields-exact, llm_median_latency_ms, nombres de jetons. Chaque valeur F1 champ regex/LLM provient d'une ligne de ce fichier.
3. Dépôt ImageToTableai/benchmark-ocr. Dépôt public hébergeant les CSV de résultats, les manifestes de runs expurgés, le protocole figé et les listes d'échantillons des jeux de données (splits de test fixes) pour la reproduction.
4. results/manifests/ (GitHub). Un manifest.json expurgé par run publié (16 runs) avec l'empreinte d'environnement, la version du modèle, les métadonnées de coût et les 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

• Périmètre documentaire : Reçus uniquement (SROIE + CORD). Ce benchmark ne mesure rien concernant la gestion de la mise en page, des tableaux, des formules, des documents longs ou des champs hors reçus — les types de documents où les VLM d'analyse de documents revendiquent leurs plus grands avantages restent non mesurés ici. N'utilisez pas cette page pour conclure que « l'OCR traditionnel est meilleur partout ».
• Taille de l'échantillon : 361 reçus en anglais + 100 reçus en indonésien. Le F1 champ et le CER dépendent du corpus ; des différences de quelques centièmes doivent être traitées comme du bruit, pas comme une vérité d'ingénierie.
• Niveau de GPU unique : tous les chiffres GPU proviennent d'un seul RTX 4090 à 0,76 $/h. D'autres GPU, un service multi-GPU ou une planification par lots modifieront la latence, le débit et le coût.
• Asymétrie CPU/GPU : Tesseract (CPU) est comparé à des moteurs accélérés par GPU ; sa latence/temps reflète le matériel CPU tandis que son avantage de coût reflète une facturation GPU nulle. Cela est signalé sur chaque tableau pertinent, mais l'asymétrie est inhérente à la comparaison.
• Le post-processeur LLM est un modèle unique : toutes les lignes de champs LLM utilisent deepseek-v4-flash. Un LLM différent produirait un F1 absolu différent ; l'ordre de convergence peut changer à la marge. La latence LLM (~1,8–2,4 s médiane, field_method_comparison.csv llm_median_latency_ms) est due à l'API et ne fait pas partie de la latence propre du moteur OCR.
• Horodatage du coût : le prix GPU de 0,76 $/h a été enregistré dans les manifestes d'exécution en août 2026. Les prix GPU spot/à la demande changent ; recalculez les coûts aux tarifs actuels avant d'établir un budget.
• Le CER CORD n'est pas une mesure de qualité : la vérité terrain CORD intègre la structure d'annotation et les moteurs n'ont pas été entraînés sur l'indonésien. Le CER CORD (0,90–1,08 sur les 8 modèles) reflète un décalage linguistique + une inflation de la vérité terrain, pas la qualité de lecture par modèle ; les lignes CORD ne sont volontairement fusionnées dans aucun classement SROIE.
• Réglage des regex : l'ensemble de motifs regex a été écrit une fois par jeu de données. Une bibliothèque de motifs fortement réglée par fournisseur pourrait obtenir de meilleurs scores sur ses propres formats — au prix de maintenance que le LLM élimine.
• Aucun modèle cloud/API : AWS Textract, Google Document AI, Azure AI Document Intelligence et les API VLM hébergées (par exemple, les services OCR cloud) ne sont pas inclus ; 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 les versions de modèles d'août 2026 listées ci-dessus ; les versions plus récentes de tout moteur peuvent modifier les résultats, et les latences p50 des deux mesures avec de grands pics p95 (PaddleOCR, Docling) reflètent les effets de préremplissage/première page sous le modèle de lot de cette exécution.

Références connexes : les limites des regex pour l'extraction de champs · précision au niveau champ et au niveau caractère comparée · Précision OCR des reçus · données de précision OCR par type de document

Lectures connexes : précision de l'OCR IA vs OCR classique · comment l'extraction par vision IA lit les images différemment de l'OCR · Tarification de l'extraction de documents IA (2026)