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

Le CER est un algorithme de scoring par 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 minimum d'insertions, suppressions et 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 dans la spécification d'évaluation OCR-D). Il compte les différences et ne peut pas distinguer une mauvaise lecture d'une reformulation 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 pénalise des comportements qui ne sont pas du tout des erreurs 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 originales, de sorte que leur convention de sortie est proche de la référence et le CER mesure quelque chose proche d'une erreur de lecture réelle. Les VLM d'analyse de documents (Surya2, Unlimited-OCR, PaddleOCR-VL) émettent du texte compris : ils appliquent la normalisation de casse (TAN CHAY YEE devient tan chay yee), la fusion étiquette/valeur (INVOICE NO\n: PEGIV devient Invoice No : PEGIV) et la réorganisation des lignes — les conventions de sortie d'un lecteur, pas d'un scanner. Chaque casse normalisée et ligne fusionnée entraîne une pénalité de distance d'édition, même lorsque la valeur du champ sous-jacente 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 — avec les valeurs de champ réelles (entreprise, total, date, adresse) correctes. Cette décomposition est une estimation dérivée du protocole, issue des notes d'analyse du benchmark, pas une colonne CSV ; considérez la répartition comme indicative, pas précise. C'est la direction qui compte : la normalisation de casse seule peut expliquer une grande partie du « mauvais » CER d'un VLM sur des reçus anglais propres.

Deux lignes CSV rendent le mécanisme visible sans aucune décomposition. Unlimited-OCR obtient un CER de 0,6552 mais un WER de 0,4779 sur SROIE — ses caractères semblent brouillés tandis que ses mots survivent, car 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 un CER de 0,1915 — le meilleur CER brut de l'ensemble des 8 moteurs, indistingable d'un moteur traditionnel performant (summary_metrics.csv, cer, ligne surya2/sroie_2019). C'est la convention de sortie du VLM, et non sa capacité de lecture, que la colonne CER mesure principalement.

La preuve est dans les inversions : CER et F1 champ ne sont pas d'accord

Le classement CER du benchmark et son classement d'extraction de champs ne sont pas d'accord de manière significative. 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 — et le gagnant est Unlimited-OCR (0,3376), le moteur que le CER classe tout dernier. L'une des deux colonnes ne mesure pas ce que les systèmes en aval consomment réellement.

F1 champ est la moyenne harmonique de la précision et du rappel sur les valeurs des champs extraits (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, donc la seule variable est 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 tant que grandeurs (unités différentes), mais leurs classements ne sont pas d'accord, c'est le point.

Tableau : summary_metrics.csv — colonnes cer / wer / field_f1_regex, lignes sroie_2019. Les rangs sont calculés sur les 8 lignes de ce tableau (1 = meilleur pour cette métrique : CER le plus bas, F1 champ le plus élevé). Il s'agit des métriques postprocessed_sroie_receipt_regex_* : des motifs fixes appliqués au texte OCR de chaque moteur, pas une sortie structurée native. Tesseract a été exécuté en CPU uniquement (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 lentille champ classe premier. docTR : 2e meilleur CER (0.1971), pire F1 champ (0.0766) — parfait en texte, échec en champ. PaddleOCR-VL s'inverse aussi en marge (CER rang 6, champ rang 2), tandis que les deux lignes alignées (PaddleOCR 3e/3e, Tesseract 5e/5e) sont des moteurs traditionnels dont la convention de sortie texte brut est exactement ce que le CER a été conçu pour évaluer. Classer les moteurs par CER seul donne un vainqueur différent que de classer par ce que la production consomme — l'inversion est la démonstration, pas une anomalie.

La Métrique Champ est la Lentille Fiable Inter-Familles

Faites passer le texte brut de chaque moteur par le même post-traitement d'extraction de champs LLM (deepseek-v4-flash, température 0) et les six moteurs avec un texte OCR exploitable convergent vers 0,57–0,62 de F1 champ — la frontière famille VLM-vs-traditionnelle que le classement CER fait paraître é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 par ce qui compte vraiment — la récupération des champs en aval — et ce de manière cohérente à travers la frontière familiale.

Il s'agit du même ensemble de moteurs que le tableau CER ci-dessus, re-évalué uniquement sur la dimension champ : l'inversion CER entre Unlimited-OCR et docTR a disparu, car la récupération des valeurs de champ est ce que le pipeline consomme. Le mécanisme est que le post-traitement absorbe les différences de convention de sortie que le CER sanctionnait — il lit le texte normalisé en casse et fusionné en étiquettes et extrait les valeurs. Le F1 champ LLM ici est la colonne llm_field_value_f1 de la comparaison méthodologique 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. La colonne CER est répétée depuis summary_metrics.csv uniquement pour référence croisée. La « bande de convergence » est la plage observée de 0,5685 à 0,6171 des six moteurs avec un texte exploitable ; les deux lignes en dessous de la bande sont indiquées comme des observations, et non comme une classification des moteurs.

CORD ajoute une deuxième couche de gonflement : la structure de la référence

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

L'artéfact extrême est le CER CORD de PaddleOCR-VL, à 1,0805, le pire des 8 moteurs — non pas une lecture de sa qualité de texte, mais le gonflement structurel qui agit le plus fortement contre la sortie la plus propre et la plus courte, qui a la plus grande distance d'édition relative par rapport à la référence de CORD chargée en structure. Sur le plan des champs, le même moteur obtient le meilleur F1 champ regex CORD (0,3412) du benchmark. Le CER CORD est structurellement inutilisable ; les métriques de champ sont le seul prisme 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 une structure d'annotation, donc le CER mesure la distance à une chaîne structurellement augmentée, et non au texte visible.

Tableau : summary_metrics.csv — colonnes cer / field_f1_regex, lignes cord_v2. CORD n'est pas intégré au classement SROIE (règle du protocole) : la structure de la référence gonfle le CER pour chaque moteur, et les patterns regex ont été écrits pour des formats anglais. Les métriques champ sont le seul prisme équitable pour CORD. Trié par F1 champ, pas par CER — le point est que la colonne CER ne fournit aucun signal de tri.

Le prisme champ retourne 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 n'est extrait — tandis que son CER CORD (0.9101) se situe au milieu du groupe et ne dit rien à ce sujet. Sur CORD, publier le CER sans les chiffres champ n'est pas seulement non informatif ; cela classe activement les moteurs dans le mauvais ordre.

Quand le CER est 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 lorsque le consommateur en aval a besoin de texte littéral, 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 », et non « 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 la qualité de lecture réelle : la colonne CER du moteur traditionnel dans ce benchmark (0,1971–0,3347 sur SROIE) suit de près les performances sur champs, bien plus que pour les VLMs (corrélation de rang avec le F1 champ regex : PaddleOCR et Tesseract sont exactement alignés au 3e/3e et 5e/5e).
• Cas d'usage en texte littéral. Les consommateurs en aval basés sur la correspondance exacte — recherche plein texte devant trouver une chaîne littérale, pistes d'audit rejouant les caractères d'un document, ou vérifications passe/échec sur une séquence de caractères requise — consomment des caractères, et non des champs. Pour ceux-ci, la reproduction exacte des caractères (CER) est la mesure fidèle et le F1 champ est le mauvais angle.
• 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 annotation augmentée comme le gt_text de CORD). Si l'un des deux est inconnu, le chiffre n'est pas transposable 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 document ; le F1 champ (post-traité par regex ou LLM) est équitable des deux côtés. Utilisez le CER pour la qualité du texte brut intra-famille, le F1 champ pour la comparaison inter-familles — et signalez toujours la mise en garde de décomposition pour les lignes VLM.

Foire aux questions

Pourquoi le CER est-il trompeur lors de la comparaison des moteurs OCR et des VLM ?

Parce que le CER est un score de distance d'édition au niveau du caractère exact, et les VLM de parsing de documents ne reproduisent pas délibérément les caractères exactement — ils normalisent la casse, fusionnent les lignes étiquette/valeur et réorganisent le texte. Chacune de ces normalisations est comptabilisé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, unlimited_ocr/sroie_2019 row) — le classement CER et le classement champ sélectionnent des gagnants différents.

Le CER est-il encore 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 les performances 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 que du texte visible (CORD).

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

Principalement à cause de la convention de sortie, et non de la 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, issue des notes d'analyse du benchmark, et non d'une colonne CSV) — tandis que les valeurs des champs elles-mêmes sont correctes. Le CER de 0.6552 vs le WER de 0.4779 d'Unlimited-OCR montre la signature : les caractères sont normalisés, les mots survivent (summary_metrics.csv, cer / wer, unlimited_ocr/sroie_2019 row).

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

F1 champ — post-traitement par regex pour un pipeline OCR brut, post-traitement par LLM pour les deux familles. Sur SROIE, le F1 champ LLM converge six moteurs à 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 le seul regard qui classe le tableau CORD de manière sensée, 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-traiteur et la convention de sortie avec le chiffre.

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 champs, coordonnées, entrées de menu) plutôt que le simple texte visible, 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 augmentée structurellement est la plus grande (CER 1,0805, le pire des 8). Sur le regard champ, le même texte extrait les champs du reçu indonésien à 0,3412 de F1 champ, le meilleur du benchmark (summary_metrics.csv, cer / field_f1_regex, ligne paddleocr_vl_vllm/cord_v2). Le CER de CORD est structurellement inutilisable pour tous les moteurs ; 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 à convertir 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 d'un VLM sur SROIE (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 à celui d'un modèle défaillant.

Faut-il comparer les moteurs OCR par CER ou par F1 champ ?

Par F1 champ pour toute comparaison impliquant à la fois des moteurs OCR traditionnels et des 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 en structure. Utilisez le CER uniquement au sein de la famille OCR brut ou lorsque le consommateur en aval a besoin du texte verbatim (recherche, audit, passage exact). 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 benchmark interne publié dans results/summary_metrics.csv ou results/field_method_comparison.csv hébergé sur ImageToTableai/benchmark-ocr, avec un manifest.json caviardé par exécution enregistrant les versions des modèles et les empreintes d'environnement. La décomposition CER ~76%/~18%/~10% est une estimation dérivée du protocole des notes d'analyse du benchmark, explicitement pas une colonne CSV. Les définitions des jeux de données proviennent des articles SROIE et CORD cités ci-dessous.

Méthodologie & Sources

Protocole

Cette page présente la dimension équité des métriques d'une exécution de benchmark indépendante et reproductible (niveau officiel) — pas un recueil d'affirmations de tiers. Uniquement des partitions de test fixes : SROIE 2019 test (361 reçus anglais, champs plats entreprise/date/adresse/total, CC-BY-4.0) et CORD v2 test (100 reçus indonésiens, champs imbriqués menu/sous_total/total, CC-BY-4.0) ; les partitions d'entraînement n'ont jamais été évaluées. Huit moteurs ont été exécutés tels quels, sans affinage, sous le protocole figé reports/receipt_v1_official_protocol.md (chauffage puis notation, niveau officiel uniquement). Les 16 exécutions notées se sont toutes terminées avec un error_rate de 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 : tous les tests GPU ont été effectués sur un seul NVIDIA RTX 4090 (24 Go) ; Tesseract a fonctionné en CPU uniquement (compute_type=cpu) et est identifié comme tel dans chaque tableau.
• Moteurs et versions (selon les manifests 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 vLLM-served, PaddleOCR-VL 1.6.
• Post-traitement des champs : F1 champ par regex = motifs fixes sroie_receipt_regex/cord_receipt_regex appliqués au texte OCR de chaque moteur (post-traité, pas une extraction native) ; F1 champ par 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 — nombre minimum d'insertions/suppressions/substitutions divisé par la longueur de la référence (spécification d'évaluation OCR-D). Plus bas est meilleur. Mesure uniquement la reproduction exacte des caractères.
• Word Error Rate (WER) : la même logique de distance d'édition au niveau du mot — un mot survit à une substitution de cas unique, donc une divergence CER/WER révèle une normalisation qui modifie les caractères sans casser les mots.
• F1 champ : moyenne harmonique de la précision et du rappel sur les valeurs des champs extraits ; un champ ne correspond que s'il est strictement identique à 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 manière dont un moteur formate son texte (casse, séparateurs, ordre des lignes). Les moteurs traditionnels le préservent ; les VLM d'analyse de documents le normalisent — l'axe que cette page mesure.
• Structure de la référence : si le texte de référence est du texte visible pur (SROIE) ou enrichi d'une structure d'annotation (CORD gt_text), ce qui gonfle le CER pour 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 donnée 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 d'exécution expurgés, le protocole figé (reports/receipt_v1_official_protocol.md), et les listes d'échantillons fixes pour la reproductibilité.
4. results/manifests/ (GitHub). Un manifest.json expurgé par exécution publiée avec les versions des modèles, les empreintes d'environnement et les hachages des artefacts.
5. receipt_v1_official_protocol.md. Le contrat d'exécution figé : partitions de test fixes, niveau officiel, mesure chauffe-then-score, règles de séparation CORD-vs-SROIE. Source des règles au niveau du protocole citées sur cette page.
6. Notes d'analyse du protocole de benchmark (documentation interne des exécutions, 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 la référence CORD, et la décomposition du CER SROIE (~76% identique / ~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 indicative, pas précise.
7. OCR-D Project — Spécification d'assurance qualité. Définition formelle du CER (insertions + suppressions + substitutions) / caractères totaux et l'analogue WER. Ancre définitionnelle formelle.
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 du CER SROIE ~76%/~18%/~10% provient des notes d'analyse du protocole du benchmark (WRITING_BRIEF §8.2), pas d'une colonne CSV. La direction (la normalisation, pas la mauvaise lecture, domine le CER des VLM) est robuste ; les pourcentages exacts doivent être traités comme des estimations directionnelles, pas des mesures ponctuelles.
• Reçus uniquement : reçus SROIE (anglais) et CORD (indonésien). Le comportement sur factures, formulaires, tableaux ou documents longs n'est pas mesuré ; le mécanisme se généralise, les chiffres non.
• Un seul post-traitement LLM : tous les chiffres de F1 champ des LLM utilisent deepseek-v4-flash à température 0. Un LLM différent déplace les valeurs absolues de F1 et possiblement 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 est limitée à la comparaison inter-familles des sorties de type VLM. Pour la comparaison intra-famille OCR brut et les utilisateurs en aval nécessitant 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.
• CORD non fusionné dans les classements SROIE : langue différente, structure de référence différente. CORD est comparé uniquement sur les métriques de champ, selon le protocole du benchmark.
• Verrouillage de version et de matériel : les chiffres valent pour les versions de modèle d'août 2026 et un niveau de GPU (RTX 4090) listé ci-dessus. Les versions plus récentes déplacent le CER et le F1 champ ; les différences de l'ordre de l'unité en pourcentage doivent être traitées comme du bruit.
• Taille de l'échantillon : 361 + 100 échantillons ; les intervalles de confiance par 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 d'analyse de documents · Regex vs extraction de champ par LLM · PaddleOCR vs EasyOCR sur les reçus · Surya2 vs Unlimited-OCR vs PaddleOCR-VL · Benchmark de latence OCR · Coût OCR pour 1 000 pages

Lectures associées : Précision de l'OCR IA vs OCR traditionnel · Extraction de données d'images par IA vs OCR traditionnel