Pourquoi le CER induit en erreur pour les VLM d'analyse de documents
Quantifié avec des données de benchmark propriétaires (2026)

Le CER est un algorithme de correspondance exacte, pas un indicateur de qualité

Le CER est la distance d'édition de Levenshtein entre le texte reconnu et la référence — le nombre minimal d'insertions, de suppressions et de substitutions de caractères nécessaires pour transformer l'un en l'autre, divisé par la longueur de la référence (la définition formelle est publiée par la spécification d'évaluation OCR-D). Il compte les différences et ne peut pas distinguer une erreur de lecture d'un reformatage légitime. Lorsque la convention de sortie d'un moteur diffère de la référence — casse, séparateurs, ordre des lignes — le CER impute des erreurs pour un comportement qui n'est pas du tout une erreur de lecture.

Les moteurs OCR traditionnels (Tesseract, PaddleOCR, EasyOCR, docTR) émettent des flux de caractères bruts qui préservent la casse et la mise en page d'origine, de sorte que leur convention de sortie est proche de la référence et que le CER mesure quelque chose de proche d'une véritable erreur de lecture. Les VLM d'analyse de documents (Surya2, Unlimited-OCR, PaddleOCR-VL) émettent du texte compris : ils appliquent une normalisation de casse (TAN CHAY YEE devient tan chay yee), une fusion étiquette/valeur (INVOICE NO\n: PEGIV devient Invoice No : PEGIV) et un réordonnancement des lignes — les conventions de sortie d'un lecteur, pas d'un scanner. Chaque casse normalisée et chaque ligne fusionnée représente une pénalité de distance d'édition, même lorsque la valeur du champ sous-jacent est correcte.

L'analyse du protocole du benchmark sur les prédictions SROIE publiées décompose le budget CER brut d'un VLM en environ ~76 % de caractères identiques à la référence, ~18 % de substitutions de casse et ~10 % de fusions de lignes / séparateurs supprimés — les valeurs réelles des champs (entreprise, total, date, adresse) étant correctes. Cette décomposition est une estimation dérivée du protocole à partir des notes d'analyse du benchmark, pas une colonne CSV ; considérez la répartition comme directionnelle, pas précise. Ce qui compte, c'est la direction : la normalisation de casse seule peut expliquer une grande partie du CER « médiocre » d'un VLM sur des reçus anglais propres.

Deux lignes CSV rendent le mécanisme visible sans aucune décomposition. Unlimited-OCR obtient CER 0,6552 mais WER 0,4779 sur SROIE — ses caractères semblent déformés alors que ses mots survivent, parce que la normalisation de casse remplace des caractères sans casser les mots (summary_metrics.csv, cer / wer, ligne unlimited_ocr/sroie_2019). Et le VLM qui normalise le moins, Surya2, obtient CER 0,1915 — le meilleur CER brut de toute la série de 8 moteurs, impossible à distinguer d'un moteur traditionnel performant (summary_metrics.csv, cer, ligne surya2/sroie_2019). C'est la convention de sortie du VLM, pas sa capacité de lecture, que la colonne CER mesure principalement.

La preuve est dans les inversions : le CER et le F1 champ divergent

Le classement CER du benchmark et son classement d’extraction de champs divergent sensiblement. Classez les huit moteurs par CER SROIE et le gagnant est Surya2 (0,1915) ; classez-les par F1 champ regex — la métrique qui se rapproche de ce qu’un pipeline de production consomme réellement — et le gagnant est Unlimited-OCR (0,3376), le moteur que le CER classe bon dernier. L’une des deux colonnes ne mesure pas ce que les systèmes en aval consomment réellement.

Le F1 champ est la moyenne harmonique de la précision et du rappel sur les valeurs de champs extraites (entreprise, date, adresse, total sur SROIE) : un champ est une unité binaire — il correspond ou il échoue. La colonne regex applique le même ensemble de motifs fixes au texte de chaque moteur, la seule variable étant la sortie du moteur. Le tableau ci-dessous associe le CER de chaque moteur à son F1 champ regex sur les mêmes 361 reçus, avec le rang de chaque moteur sous les deux métriques.

Source : summary_metrics.csv — colonnes cer et field_f1_regex, lignes sroie_2019 (361 échantillons par moteur, error_rate 0,0 pour les 8). Les deux séries ne sont pas comparables entre elles en termes de magnitudes (unités différentes), mais leurs classements divergent, ce qui est le point essentiel.

Tableau : summary_metrics.csv — colonnes cer / wer / field_f1_regex, lignes sroie_2019. Rangs calculés parmi les 8 lignes de ce tableau (1 = meilleur sous cette métrique : CER le plus bas, F1 champ le plus élevé). Il s'agit de métriques postprocessed_sroie_receipt_regex_* : des motifs fixes appliqués au texte OCR de chaque moteur, et non une sortie structurée native. Tesseract a fonctionné uniquement sur CPU (compute_type=cpu).

Lisez explicitement les deux paires d’inversion. Unlimited-OCR : pire CER (0,6552), meilleur F1 champ (0,3376) — le moteur que la métrique OCR brute classe dernier est celui que la perspective champ classe premier. docTR : 2e meilleur CER (0,1971), pire F1 champ (0,0766) — texte parfait, échec au niveau des champs. PaddleOCR-VL s’inverse aussi à la marge (rang CER 6, rang champ 2), tandis que les deux lignes alignées (PaddleOCR 3e/3e, Tesseract 5e/5e) sont toutes deux des moteurs traditionnels dont la convention de sortie de texte brut est exactement ce que le CER a été conçu pour évaluer. Classer les moteurs uniquement par le CER donne un gagnant différent de celui obtenu en classant selon ce que la production consomme — l’inversion est la démonstration, pas une anomalie.

La métrique champ est la lentille inter-familles fiable

En passant le texte brut de chaque moteur par le même post-traitement d’extraction de champs par LLM (deepseek-v4-flash, température 0), les six moteurs avec un texte OCR exploitable convergent vers 0,57–0,62 de F1 champ — la frontière VLM-vs-traditionnel que le classement CER semble rendre énorme (0,19 à 0,66) disparaît presque. Deux moteurs tombent sous la bande : EasyOCR à 0,3717 et Tesseract à 0,4389. La métrique champ sépare les moteurs selon ce qui compte vraiment — la récupération des champs en aval — et elle le fait de manière cohérente au-delà de la frontière entre familles.

Il s’agit du même ensemble de moteurs que le tableau CER ci-dessus, réévalué uniquement sur la dimension champ : l’inversion CER entre Unlimited-OCR et docTR a disparu, car c’est la récupération des valeurs de champ que le pipeline consomme. Le mécanisme est que le post-traitement absorbe les différences de convention de sortie que le CER pénalisait — il lit le texte normalisé en casse et fusionné étiquette/valeur, puis extrait les valeurs. Le F1 champ LLM correspond ici à la colonne llm_field_value_f1 de la comparaison de méthodes du benchmark, avec le modèle LLM enregistré par ligne.

Tableau : field_method_comparison.csv — colonne llm_field_value_f1, lignes sroie_2019, llm_model=deepseek-v4-flash. Colonne CER répétée depuis summary_metrics.csv à titre de référence croisée uniquement. La “bande de convergence” est la plage observée de 0,5685–0,6171 des six moteurs avec texte exploitable ; les deux lignes sous la bande sont indiquées comme observations, pas comme une classification des moteurs.

CORD ajoute une deuxième couche d’inflation : la structure de la référence

Le texte de référence publié de CORD (gt_text) intègre la structure d’annotation — étiquettes de champs, entrées de menu et coordonnées — plutôt qu’un texte visible pur. Le CER calcule la distance d’édition par rapport à cette chaîne structurellement augmentée, de sorte que le CER CORD de chaque moteur est systématiquement gonflé avant même qu’une erreur de lecture ne soit prise en compte. Résultat : les huit moteurs se regroupent à CER CORD 0,90–1,08 — une plage inutilement compressée qui n’indique presque rien sur la qualité du texte.

L’artefact extrême est le CER CORD de PaddleOCR-VL de 1,0805, le pire des 8 moteurs — non pas une mesure de la qualité de son texte, mais l’inflation structurelle qui pénalise le plus la sortie la plus propre et la plus courte, qui présente la plus grande distance d’édition relative par rapport à la référence chargée de structure de CORD. Sur le plan des champs, le même moteur affiche le meilleur F1 regex de champ CORD du benchmark (0,3412). Le CER CORD est structurellement inutilisable ; les métriques de champ sont la seule optique CORD équitable, et elles sont strictement séparées de tout classement SROIE dans ce benchmark (langue différente — indonésien — et structure de référence différente).

Source : summary_metrics.csv — colonnes cer et field_f1_regex, lignes cord_v2 (100 échantillons par moteur). Le CER CORD n’est pas comparable entre familles ni même entre moteurs — la référence intègre la structure d’annotation, donc le CER mesure la distance par rapport à une chaîne structurellement augmentée, et non par rapport au texte visible.

Tableau : summary_metrics.csv — colonnes cer / field_f1_regex, lignes cord_v2. CORD n’est fusionné dans aucun classement SROIE (règle du protocole) : la structure de la référence gonfle le CER de chaque moteur, et les motifs regex ont été écrits pour des formats anglais. Les métriques de champ sont la seule lecture CORD équitable. Tri par F1 champ, pas par CER — le but est que la colonne CER ne porte aucun signal de tri.

La lecture par champ renverse complètement le tableau CORD. Le moteur avec le pire CER CORD du benchmark (PaddleOCR-VL, 1.0805) a le meilleur F1 champ CORD (0.3412) ; le F1 champ CORD de docTR est littéralement 0.0000 — rien d’extrait — alors que son CER CORD (0.9101) se situe au milieu du groupe et ne dit rien à son sujet. Sur CORD, publier le CER sans les chiffres de champ n’est pas seulement peu informatif ; cela classe activement les moteurs dans le mauvais ordre.

Quand le CER est réellement la bonne métrique

Le CER mesure toujours quelque chose de réel — la reproduction exacte des caractères — et c'est la bonne métrique dès lors que le consommateur en aval a besoin de texte verbatim, et non de champs. La conclusion de cette page est « le CER induit en erreur pour la comparaison inter-familles des sorties de type VLM », pas « le CER est toujours faux ».

• Au sein de la famille OCR brut, le CER conserve sa valeur. Les moteurs traditionnels émettent du texte brut avec la casse et la mise en page préservées, donc le CER mesure une véritable qualité de lecture : la colonne CER des moteurs traditionnels dans ce benchmark (0,1971–0,3347 sur SROIE) suit leur performance sur les champs de bien plus près que pour les VLM (corrélation de rang avec le F1 champ regex : PaddleOCR et Tesseract sont exactement alignés à 3e/3e et 5e/5e).
• Cas d'usage du texte verbatim. Les consommateurs en aval qui exigent une correspondance exacte — recherche plein texte qui doit trouver une chaîne littérale, pistes d'audit qui rejouent les caractères d'un document, ou contrôles de réussite/échec sur une séquence de caractères requise — consomment des caractères, pas des champs. Pour eux, la reproduction exacte des caractères (CER) est la mesure fidèle et le F1 champ est la mauvaise optique.
• Règle de publication. Lorsque vous publiez un chiffre de CER, indiquez à la fois la convention de sortie du moteur (normalise-t-il la casse ? fusionne-t-il les étiquettes ? réordonne-t-il les lignes ?) et la construction de la référence (texte visible pur, ou enrichi d'annotations comme le gt_text de CORD). Si l'un des deux est inconnu, le chiffre n'est pas portable entre moteurs ou jeux de données.
• La règle de frontière de ce benchmark. Le CER est équitable au sein de la famille OCR brut et inéquitable à la frontière OCR traditionnel / VLM d'analyse de documents ; le F1 au niveau champ (regex ou post-traitement LLM) est équitable des deux côtés. Utilisez le CER pour la qualité du texte brut au sein d'une même famille, et le F1 champ pour la comparaison inter-familles — et signalez toujours la réserve de décomposition pour les lignes VLM.

Questions fréquemment posées

Pourquoi le CER est-il trompeur pour comparer les moteurs OCR et les VLM ?

Parce que le CER est un score de distance d'édition au caractère exact, et que les VLM de parsing de documents ne reproduisent délibérément pas les caractères exactement — ils normalisent la casse, fusionnent les lignes étiquette/valeur et réordonnent le texte. Chacune de ces normalisations est comptée comme une erreur même lorsque la valeur du champ est correcte. Dans ce benchmark, Unlimited-OCR obtient le pire CER SROIE (0,6552) tout en ayant le meilleur F1 champ regex (0,3376) sur les mêmes 361 reçus (summary_metrics.csv, cer / field_f1_regex, ligne unlimited_ocr/sroie_2019) — le classement CER et le classement champ désignent des gagnants différents.

Le CER reste-t-il une métrique OCR utile ?

Oui — au sein de la famille OCR brut et pour les consommateurs de texte verbatim. Les moteurs traditionnels (Tesseract, PaddleOCR, EasyOCR, docTR) produisent des flux de caractères bruts que le CER mesure équitablement : dans ce benchmark, leur CER SROIE s'étend de 0,1971 à 0,3347 et suit la performance champ (PaddleOCR 3e/3e, Tesseract 5e/5e sous CER et F1 champ). Le CER est la mauvaise métrique lorsque le moteur normalise sa sortie (style VLM) ou lorsque la référence intègre une structure plutôt qu'un texte visible (CORD).

Pourquoi les modèles OCR VLM ont-ils des taux d'erreur de caractères élevés ?

Principalement une convention de sortie, pas une capacité de lecture. L'analyse du protocole du benchmark attribue environ ~18 % du budget CER SROIE d'un VLM aux substitutions de casse et ~10 % aux fusions de lignes/séparateurs supprimés (estimation dérivée du protocole à partir des notes d'analyse du benchmark, pas une colonne CSV) — tandis que les valeurs de champ elles-mêmes sont correctes. Le CER 0,6552 d'Unlimited-OCR contre un WER 0,4779 montre la signature : les caractères sont pliés, les mots survivent (summary_metrics.csv, cer / wer, ligne unlimited_ocr/sroie_2019).

Quelle est la meilleure métrique pour comparer les moteurs OCR et les VLM d'analyse de documents ?

Le F1 au niveau champ — post-traité par regex pour un pipeline OCR brut, post-traité par LLM pour les deux familles. Sur SROIE, le F1 champ LLM converge six moteurs vers 0,57–0,62 quelle que soit la famille (field_method_comparison.csv, llm_field_value_f1, lignes sroie_2019), et le F1 champ regex est la seule optique qui classe correctement la table CORD, où le 0,3412 de PaddleOCR-VL est le meilleur du benchmark (summary_metrics.csv, field_f1_regex, lignes cord_v2). Indiquez toujours le post-traitement et la convention de sortie avec le nombre.

Pourquoi le CER de PaddleOCR-VL est-il si élevé sur CORD alors que son F1 champ est le meilleur ?

Parce que la référence de CORD intègre la structure d'annotation (étiquettes de champ, coordonnées, entrées de menu) plutôt que le texte visible pur, et la sortie de PaddleOCR-VL est la plus propre — la plus courte, la plus normalisée — donc sa distance d'édition par rapport à cette chaîne structurellement augmentée est la plus grande (CER 1,0805, le pire des 8). Sur l'optique champ, le même texte extrait les champs de reçu indonésiens à 0,3412 de F1 champ, le meilleur du benchmark (summary_metrics.csv, cer / field_f1_regex, ligne paddleocr_vl_vllm/cord_v2). Le CER CORD est structurellement inutilisable pour chaque moteur ; les métriques champ sont la seule comparaison CORD équitable.

Qu'est-ce que la normalisation de casse et pourquoi gonfle-t-elle le CER ?

La normalisation de casse consiste à uniformiser tout le texte en une seule casse — TAN CHAY YEE devient tan chay yee. Le CER compare les caractères exactement, donc chaque lettre normalisée est une substitution par rapport aux majuscules de la référence, même si la valeur est identique. Dans l'analyse du protocole de ce benchmark, les substitutions de casse représentent environ ~18 % du budget CER SROIE d'un VLM (estimation dérivée du protocole) — c'est pourquoi un VLM peut lire parfaitement un reçu et afficher quand même un CER qui ressemble à un modèle défaillant.

Dois-je comparer les moteurs OCR par CER ou par F1 au niveau des champs ?

Par F1 au niveau des champs pour toute comparaison qui touche à la fois les moteurs OCR traditionnels et les moteurs VLM — car votre pipeline consomme des champs, pas des flux de caractères, et parce que le CER est systématiquement gonflé pour la sortie VLM normalisée et la référence augmentée par la structure. Utilisez le CER uniquement au sein de la famille OCR brut ou lorsque le consommateur en aval a besoin de texte verbatim (recherche, audit, correspondance exacte). Les deux métriques divergent fortement dans ce benchmark : le CER classe docTR 2e et Unlimited-OCR 8e ; le F1 champ regex classe docTR 8e et Unlimited-OCR 1er (summary_metrics.csv, lignes sroie_2019).

D'où viennent ces chiffres de CER et de F1 champ ?

Chaque chiffre du tableau est une ligne du results/summary_metrics.csv ou du results/field_method_comparison.csv publié par le benchmark propriétaire, hébergé sur ImageToTableai/benchmark-ocr, avec un manifest.json expurgé par exécution enregistrant les versions des modèles et les empreintes d'environnement. La décomposition CER d'environ 76 %/~18 %/~10 % est une estimation dérivée du protocole à partir des notes d'analyse du benchmark, explicitement pas une colonne CSV. Les définitions des ensembles de données proviennent des articles SROIE et CORD cités ci-dessous.

Méthodologie et sources

Protocole

Cette page rend compte de la dimension d'équité des métriques d'une exécution de benchmark indépendante et reproductible (niveau officiel) — pas d'une enquête sur des affirmations de tiers. Uniquement des ensembles de test fixes : test SROIE 2019 (361 reçus anglais, champs plats company/date/address/total, CC-BY-4.0) et test CORD v2 (100 reçus indonésiens, champs imbriqués menu/sub_total/total, CC-BY-4.0) ; les ensembles d'entraînement n'ont jamais été évalués. Huit moteurs ont été exécutés tels quels, sans fine-tuning, sous le protocole figé reports/receipt_v1_official_protocol.md (échauffement puis notation, niveau officiel uniquement). Les 16 exécutions notées ont toutes été complétées avec error_rate 0.0 (colonne error_rate de summary_metrics.csv). Les données ont été collectées en août 2026.

Environnement d'exécution

• Matériel : toutes les exécutions GPU sur une seule NVIDIA RTX 4090 (24 Go) ; Tesseract a tourné CPU uniquement (compute_type=cpu) et est étiqueté comme tel sur chaque tableau.
• Moteurs et versions (selon les manifestes d'exécution) : Tesseract 5.3.4, PaddleOCR 3.7.0, EasyOCR 1.7.2, docTR v1.0.1, Docling 2.119.0, Surya2 0.22.1, Unlimited-OCR servi par vLLM, PaddleOCR-VL 1.6.
• Post-traitements de champ : F1 champ regex = motifs fixes sroie_receipt_regex/cord_receipt_regex appliqués au texte OCR de chaque moteur (post-traité, pas d'extraction native) ; F1 champ LLM = deepseek-v4-flash (température 0) lisant le même texte (colonne llm_model de field_method_comparison.csv).

Définitions des métriques

• Character Error Rate (CER) : distance d'édition de Levenshtein entre le texte reconnu et la référence — minimum d'insertions/suppressions/substitutions divisé par la longueur de la référence (spécification d'évaluation OCR-D). Plus bas est mieux. Mesure uniquement la reproduction exacte des caractères.
• Word Error Rate (WER) : même logique de distance d'édition au niveau des mots — un mot survit à une seule substitution de casse, donc l'écart CER/WER révèle une normalisation qui change les caractères sans casser les mots.
• F1 champ-valeur : moyenne harmonique de la précision et du rappel sur les valeurs de champs extraites ; un champ ne correspond que s'il est exactement égal à la référence. Les colonnes regex et LLM sont deux post-traitements sur le même texte OCR, jamais mélangés.
• Convention de sortie : la façon dont un moteur formate son texte (casse, séparateurs, ordre des lignes). Les moteurs traditionnels la préservent ; les VLM d'analyse de documents la normalisent — c'est l'axe que cette page mesure.
• Structure de référence : si le texte de référence est du texte visible pur (SROIE) ou augmenté d'une structure d'annotation (CORD gt_text), ce qui gonfle le CER de chaque moteur.

Liste des sources

1. summary_metrics.csv (GitHub raw). 16 lignes = 8 moteurs × 2 jeux de données de reçus. Les colonnes incluent cer, wer, field_f1_regex, field_acc_regex, compute_type, error_rate. Chaque valeur CER/WER et F1 champ regex de cette page provient d'une ligne ici, citée au niveau fichier/modèle/jeu de données/métrique.
2. field_method_comparison.csv (GitHub raw). Comparaison côte à côte de l'extraction de champs par regex vs LLM (llm_field_value_f1, llm_model=deepseek-v4-flash). Source du tableau F1 champ LLM.
3. Dépôt ImageToTableai/benchmark-ocr. Dépôt public hébergeant les CSV de résultats, les manifests de runs expurgés, le protocole figé (reports/receipt_v1_official_protocol.md) et les listes d'échantillons fixes pour la reproduction.
4. results/manifests/ (GitHub). Un manifest.json expurgé par run publié avec les versions de modèles, les empreintes d'environnement et les hachages d'artefacts.
5. receipt_v1_official_protocol.md. Le contrat de run figé : répartitions de test fixes, niveau officiel, mesure à chaud puis scorée, règles de séparation CORD vs SROIE. Source des règles au niveau protocole citées sur cette page.
6. Notes d'analyse du protocole de benchmark (documentation interne de run, WRITING_BRIEF §8.2/§8.3). Le mécanisme de normalisation VLM (normalisation de casse, fusion étiquette/valeur, réordonnancement des lignes), le mécanisme de structure de référence CORD et la décomposition CER SROIE (~76 % identiques / ~18 % casse / ~10 % fusion de lignes). Cité ici avec l'étiquette explicite “estimation dérivée du protocole — pas une colonne CSV” ; la répartition est directionnelle, pas précise.
7. Projet OCR-D — Spécification d'assurance qualité. Définition formelle du CER (insertions + suppressions + substitutions) / nombre total de caractères et l'analogue WER. Ancrage définitionnel formel.
8. 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, licence (CC-BY-4.0).
9. Park et al., “CORD: A Consolidated Receipt Dataset for Post-OCR Parsing” (2020). Définition du jeu de données CORD, schéma de champs imbriqués, licence (CC-BY-4.0).

Limitations

• Les chiffres de décomposition sont des estimations dérivées du protocole, pas des mesures : la décomposition CER SROIE d’environ 76 %/18 %/10 % provient des notes d’analyse du protocole du benchmark (WRITING_BRIEF §8.2), pas d’une colonne CSV. La tendance (la normalisation, pas les erreurs de lecture, domine le CER des VLM) est robuste ; les pourcentages exacts doivent être considérés comme des estimations directionnelles, pas comme des mesures ponctuelles.
• Post-traitement LLM unique : tous les chiffres de F1 champ des LLM utilisent deepseek-v4-flash à température 0. Un LLM différent modifie les valeurs absolues de F1 et éventuellement la bande de convergence ; l’ordre inter-familles au sein de la bande est le signal stable.
• Le CER reste valide pour les cas de texte verbatim : la conclusion se limite à la comparaison inter-familles des sorties de type VLM. Pour la comparaison même famille en OCR brut et les consommateurs aval exigeant des caractères exacts (recherche, audit, le CER reste une métrique légitime — cette page n’est pas un argument contre le CER dans ces contextes.
• Taille d’échantillon : 361 + 100 échantillons ; les intervalles de confiance bootstrap sont rapportés dans la sortie d’évaluation du benchmark mais ne sont pas reproduits ligne par ligne sur cette page.

Références associées : Précision au niveau champ vs au niveau caractère (définition) · OCR traditionnel vs VLM de parsing de documents · Regex vs extraction de champs par LLM · PaddleOCR vs EasyOCR sur reçus · Surya2 vs Unlimited-OCR vs PaddleOCR-VL · Benchmark de latence OCR · Coût OCR pour 1 000 pages

Lectures complémentaires : pourquoi la précision de l’OCR IA diverge de l’OCR traditionnel · extraction IA depuis des images vs pipelines OCR traditionnels