Surya2 vs Unlimited-OCR vs PaddleOCR-VL :
Benchmark VLM sur reçus (2026)

Les trois moteurs sont des modèles vision-langage (VLM) d'analyse de documents : des modèles neuronaux qui lisent une image de document entière et produisent un texte compris — avec casse normalisée, paires étiquette/valeur fusionnées en lignes uniques, lignes réordonnées selon l'ordre de lecture — plutôt que les flux de caractères bruts avec leur casse d'origine que renvoient les moteurs OCR traditionnels (Tesseract, PaddleOCR, EasyOCR, docTR — les autres moteurs de l'exécution sous-jacente). Cette convention de sortie explique pourquoi leurs scores d'extraction de champs sont solides dès le départ et pourquoi leurs taux d'erreur de caractères bruts sont trompeurs, comme le montre la section suivante. Au sein de la famille VLM, les trois modèles diffèrent nettement en taille et en objectif d'entraînement : Surya2 est un modèle de 650M de paramètres, centré sur le texte, optimisé pour la transcription propre de pages entières (90+ langues) ; PaddleOCR-VL est un généraliste compact de 0,9B conçu pour la largeur de couverture (langues, tableaux, formules) ; Unlimited-OCR est orienté vers l'analyse de longs documents et le traitement par lots (la lecture en une seule passe de documents de plus de 40 pages est son cœur de marché). Une réserve importante s'applique à chaque chiffre de CER ci-dessous : le taux d'erreur de caractères compte les insertions, suppressions et substitutions par rapport aux caractères de référence, il pénalise donc exactement les normalisations que les VLM sont entraînés à effectuer. Le score F1 au niveau des champs est la référence la plus équitable entre VLM, et c'est l'épine dorsale de cette page.

Pourquoi ne pas utiliser le CER pour les VLM : l'écart de 3,4× est une convention de sortie, pas une capacité de lecture

Lisez la colonne CER brute seule et Unlimited-OCR ressemble à un modèle défaillant (0,6552 sur SROIE) tandis que Surya2 semble de classe mondiale (0,1915, à égalité avec le docTR traditionnel à 0,1971 pour le meilleur CER brut de l'exécution des 8 moteurs). Ces deux lectures sont des artefacts du style de sortie. Le même texte Unlimited-OCR qui obtient un CER de 0,6552 obtient un WER de 0,4779 — ses mots survivent tandis que ses caractères semblent mutilés, car la réduction de casse remplace les caractères sans casser les mots. Les chiffres de PaddleOCR-VL inversent le schéma : son CER CORD de 1,0805 est le pire des 8 moteurs tandis que son F1 de champ CORD de 0,3412 est le meilleur des 8 — le CSV du benchmark lui-même contredit le classement CER.

Le mécanisme a deux couches. Couche 1 — la taxe de normalisation : les VLM d'analyse de documents produisent un texte « compris » — TAN CHAY YEE devient tan chay yee, INVOICE NO : PEGIV fusionne une étiquette et une valeur en une seule ligne. Le CER est une correspondance exacte de caractères, donc chaque casse réduite et chaque ligne fusionnée est comptée comme une erreur même lorsque la valeur du champ est correcte. L'analyse de décomposition des erreurs du benchmark sur les prédictions SROIE publiées attribue environ un cinquième du budget CER brut aux substitutions de casse et environ un dixième aux fusions/suppressions de lignes ; les trois moteurs paient cette taxe à des taux différents — la forte réduction de casse d'Unlimited-OCR gonfle son CER bien au-delà de son WER, tandis que la fusion de lignes/étiquettes de PaddleOCR-VL pousse son WER (0,6462) au-dessus de son propre CER (0,3370). Couche 2 — l'inflation de la structure de référence sur CORD : le texte de référence de CORD intègre la structure d'annotation (entrées de menu, coordonnées, étiquettes de champ), donc le CER est systématiquement gonflé pour chaque moteur en plus du véritable décalage linguistique — le groupe de CER CORD de 0,90–1,08 pour tous les moteurs (Tesseract traditionnel 0,9523, docTR 0,9101, et chaque VLM inclus) confirme que l'inflation est propre au corpus, pas au modèle.

Tableau : summary_metrics.csv — colonnes cer et wer, lignes sroie_2019. Valeurs exactes : Surya2 cer 0.19147 / wer 0.27352 ; Unlimited-OCR cer 0.65524 / wer 0.47788 ; PaddleOCR-VL cer 0.33696 / wer 0.64623. Plus bas = mieux ; les trois exécutions se sont terminées avec error_rate 0.0. Ne classez pas les VLM sur le CER : la divergence CER/WER d'Unlimited-OCR (0.6552 vs 0.4779) et l'inversion CER-vs-F1-champ de PaddleOCR-VL sur CORD (voir plus bas) sont des artefacts de conventions de sortie, exactement du type que le protocole de ce benchmark signale pour les lignes VLM.

La conséquence des couches 1 et 2 est que chaque section restante de cette page compare les trois VLM sur le score F1 d'extraction de champs (les métriques que leur sortie structurée alimente directement) et sur l'enveloppe opérationnelle (latence, débit, coût) — et ne cite le CER qu'avec ses réserves. C'est la règle du protocole du benchmark pour les lignes VLM de parsing de documents, et c'est le bon prisme : un pipeline de reçus consomme des champs (entreprise, date, adresse, total), pas des flux de caractères.

Extraction de champs prête à l'emploi : la sortie structurée est la marque de fabrique de la famille VLM

En faisant passer le texte brut de chaque moteur dans les mêmes motifs regex fixes sur les quatre champs de reçu SROIE (entreprise, date, adresse, total) — l'approche traditionnelle OCR + extraction d'informations clés (KIE) par règles — les trois VLM se situent dans une bande de 0,02 point : Unlimited-OCR 0,3376, PaddleOCR-VL 0,3368, Surya2 0,3183. Tous trois se classent dans le top quatre des huit moteurs testés ; deux battent le meilleur moteur traditionnel (le 0,3254 de PaddleOCR), et le troisième le suit de 0,007 point. Leur « texte compris » atteint les consommateurs de champs même sans postprocesseur LLM — la caractéristique familiale qui manque aux moteurs OCR à caractères bruts.

Le score F1 des valeurs de champs 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. Le mécanisme derrière l'avantage de la famille VLM est la forme de sortie décrite ci-dessus — le même texte en minuscules et structuré par étiquettes qui gonfle le CER correspond par coïncidence aux motifs d'extraction. Les colonnes « extraction de champs par regex » sont les métriques postprocessed_sroie_receipt_regex_* du benchmark : elles mesurent le texte OCR + l'extraction par règles en aval, pas la sortie structurée native, et le même ensemble de motifs a été appliqué à chaque moteur. Pour contraste, le F1 des champs par regex des moteurs traditionnels se situe à 0,0766 (docTR), 0,1477 (EasyOCR), 0,2237 (Docling) et 0,2335 (Tesseract) — six des sept moteurs non-VLM se situent sous le membre le plus bas du trio.

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 %). Postprocesseur LLM : deepseek-v4-flash (colonne llm_model). 361 échantillons par moteur (llm_ok_count).

Tableau : field_method_comparison.csv — colonnes regex, lignes sroie_2019. Ce sont les métriques postprocessed_sroie_receipt_regex_* : des motifs fixes appliqués au texte OCR de chaque moteur (post-traité, pas d'extraction native). Le 0.3183 de Surya2 est le plus bas du trio mais se classe quand même quatrième sur huit moteurs et se situe 0.007 sous le meilleur moteur traditionnel (PaddleOCR 0.3254, summary_metrics.csv field_f1_regex, ligne paddleocr/sroie_2019).

Le levier LLM : les trois moteurs convergent

En alimentant le texte OCR des trois moteurs dans un postprocesseur LLM (deepseek-v4-flash, température 0) avec une invite d'extraction structurée, l'écart hors boîte se resserre en quasi-égalité : Surya2 0,6139, Unlimited-OCR 0,6054, PaddleOCR-VL 0,5921 — un écart de 0,022 point, entièrement dans la bande de convergence de 0,57–0,62 du benchmark pour les moteurs sains. Le postprocesseur, et non le VLM, devient le composant décisif.

C'est le même schéma de convergence que celui de la course complète à 8 moteurs : un LLM comprend la sémantique (nombres, dates, noms) au lieu de faire correspondre des formes de caractères, il absorbe donc l'essentiel des différences de qualité du texte en amont — tant que le texte est assez lisible pour être exploité. Les trois VLM sont éligibles ; les trois se situent dans la bande. Le levier a un coût : un appel LLM ajoute environ 1,9–2,3 s de latence médiane par document en plus du temps OCR (1 946,7 ms pour le texte de PaddleOCR-VL, 1 982,0 ms pour celui d'Unlimited-OCR, 2 261,7 ms pour celui de Surya2 — imputable à l'API et identique en nature), ce qui favorise le traitement par lots asynchrone plutôt que les attentes synchrones page par page. L'exactitude au niveau du document — la fraction des reçus où tous les quatre champs correspondent — reste faible pour les trois (0,1219–0,1551), un rappel que le F1 par champ est le chiffre opérationnel pertinent.

Tableau : field_method_comparison.csv — colonnes llm_*, lignes sroie_2019. Modèle LLM : deepseek-v4-flash à température 0 (colonne llm_model). La latence LLM est imputable à l'API et distincte de la latence du moteur (latence_p50_ms de summary_metrics.csv).

CORD (reçus indonésiens) : le généraliste compact l'emporte

CORD v2 (100 reçus indonésiens, champs imbriqués menu/sub_total/total) est le test de résistance inter-langues du benchmark — et c'est là que les trois VLM se démarquent vraiment. Avec les mêmes motifs regex au format anglais, PaddleOCR-VL extrait les champs des reçus indonésiens à 0,3412 de score F1 sur les champs — le plus élevé des 8 moteurs de tout le benchmark — tandis que Surya2 atteint 0,2458 et Unlimited-OCR chute à 0,1079. L'étendue d'entraînement du généraliste compact montre précisément où les modèles centrés sur le texte et les modèles de longs documents perdent du terrain.

Toutes les valeurs CER de CORD sont mises en quarantaine par le protocole du benchmark et ne sont jamais fusionnées dans aucun classement SROIE : la vérité terrain de CORD intègre la structure d'annotation (gonflant le CER brut de chaque moteur en plus du véritable décalage linguistique — le cluster CER CORD tous moteurs confondus de 0,90–1,08), et les motifs regex ont été écrits pour des formats anglais. La comparaison CORD ci-dessous ne porte que sur les métriques de champs. Avec un postprocesseur LLM, le choc linguistique est absorbé comme sur SROIE : le trio reconverge vers 0,4678–0,5203 de score F1 sur les champs (Surya2 0,5203, PaddleOCR-VL 0,5198, Unlimited-OCR 0,4678) — c'est le postprocesseur, pas le moteur, qui fait le gros du travail inter-langues.

Source : summary_metrics.csv — colonne field_f1_regex, lignes cord_v2 (décimales stockées 0–1 affichées en %). PaddleOCR-VL 0,3412 est le field_f1_regex maximal sur les 16 lignes du fichier ; le deuxième meilleur sur CORD regex est Surya2 0,2458.

Table : summary_metrics.csv (field_f1_regex / cer) et field_method_comparison.csv (llm_field_value_f1), lignes cord_v2. Ne pas fusionner les chiffres CORD dans aucun classement SROIE : le CER CORD combine un vrai décalage linguistique avec une inflation de la structure d'annotation dans la vérité terrain (tous les moteurs se regroupent entre 0,90 et 1,08 — Tesseract traditionnel 0,9523, docTR 0,9101 inclus) ; le CER de PaddleOCR-VL, à 1,0805, est le plus élevé des 8 moteurs précisément parce que sa sortie propre et normalisée est la plus éloignée de la vérité terrain chargée en structure de CORD — alors que son F1 regex sur champs est le meilleur du benchmark.

L'enveloppe opérationnelle : 3,8× de latence, 5,2× de coût

La précision sur champs converge ; le coût opérationnel, non. Sur la même RTX 4090 au même tarif enregistré de 0,76 $/h, PaddleOCR-VL soutient 68,2 pages/min à 694,3 ms p50 par page pour 0,205 $ pour 1 000 pages ; Unlimited-OCR se situe au milieu de l'enveloppe à 34,4 pages/min, 1 600,7 ms p50, 0,388 $ pour 1 000 pages ; Surya2 est le cas extrême en prix et en latence à 12,1 pages/min, 2 668,0 ms p50, 1,061 $ pour 1 000 pages. Le VLM le plus rapide est 3,8× plus rapide et 5,2× moins cher que le plus lent sur du matériel identique.

Le coût est calculé comme le temps d'exécution mural × le tarif RunPod RTX 4090 (0,76 $/heure, prix horodaté dans les manifests d'exécution), y compris l'initialisation du modèle — le prix que vous paieriez réellement pour le temps GPU. Le débit est le nombre de pages par minute en temps mural, initialisation comprise. Les latences p50/p95 sont des temps d'inférence par page en régime permanent, mesurés à chaud puis scorés (chargement du modèle exclu) ; la queue de distribution de Surya2 est proportionnellement pire — 5 872,2 ms en p95 contre 1 154,3 ms pour PaddleOCR-VL — car les pics de prefill/décodage du VLM dominent la queue sur les premières pages. Deux chiffres à lire ensemble plutôt que l'un contre l'autre : PaddleOCR-VL a le p50 le plus bas mais se fait dépasser en débit mural par Unlimited-OCR sur CORD (73,99 contre 67,13 pages/min) — les chiffres en temps mural incluent l'initialisation du modèle, et la gestion par lots vLLM d'Unlimited-OCR est assez efficace pour inverser l'ordre ici.

Source : summary_metrics.csv — colonne latency_p50_ms, lignes sroie_2019. Surya2 2667,9800, Unlimited-OCR 1600,7459, PaddleOCR-VL 694,2519. Latence en régime permanent (mode de mesure warm_then_scored).

Source : summary_metrics.csv — colonne cost_per_1000_pages, lignes sroie_2019. Surya2 1.0609, Unlimited-OCR 0.3879, PaddleOCR-VL 0.2048. Coût = temps d'exécution × 0,76 $/h, incluant l'initialisation du modèle, prix horodaté dans les manifests d'exécution (août 2026).

Tableau : summary_metrics.csv — latency_p50_ms / latency_p95_ms / pages_per_minute / cost_per_1000_pages, lignes sroie_2019. Les trois moteurs sur GPU (RTX 4090, prix 0,76 $/h horodaté dans les manifests) ; le coût inclut l'initialisation du modèle, pas un pur débit en régime permanent. Valeurs exactes : Surya2 p50 2668,0 / p95 5872,2 / 12,1 pg/min / 1,0609 $ ; Unlimited-OCR p50 1600,7 / p95 2521,9 / 34,4 pg/min / 0,3879 $ ; PaddleOCR-VL p50 694,3 / p95 1154,3 / 68,2 pg/min / 0,2048 $.

Qui gagne quand : le tableau récapitulatif

“Mieux” dépend de la charge de travail, et parmi ces trois VLM, les axes se répartissent clairement : la précision des champs converge (regex et LLM), le texte brut favorise Surya2, les champs multilingues favorisent PaddleOCR-VL, et tous les axes coût/latence/débit favorisent PaddleOCR-VL avec Unlimited-OCR au milieu. Le constat honnête est que sur les reçus, avec n'importe quel postprocesseur dans le pipeline, le choix du VLM importe peu — et sans lui, le généraliste compact bon marché bat les spécialistes coûteux sur les axes qui comptent généralement.

Questions fréquentes

Quel VLM de parsing de documents est le plus précis sur les reçus ?

Sur l'extraction de champs, c'est une quasi-égalité à trois sur les reçus en anglais : score F1 regex SROIE de 0,3183–0,3376 et score F1 LLM de 0,5921–0,6139 pour Surya2, Unlimited-OCR et PaddleOCR-VL (field_method_comparison.csv, lignes sroie_2019). Sur les reçus indonésiens, la réponse change : le score F1 regex CORD de PaddleOCR-VL, soit 0,3412, est le meilleur des 8 moteurs du benchmark (summary_metrics.csv, field_f1_regex, lignes cord_v2). Le CER brut ne doit pas être utilisé pour classer les VLM — il compte les conventions de sortie (mise en minuscules, fusion de lignes) comme des erreurs (voir la section « Pourquoi ne pas utiliser le CER » ci-dessus).

Pourquoi Unlimited-OCR a-t-il le pire CER mais le meilleur score F1 regex sur SROIE ?

Parce que les deux métriques évaluent des sorties différentes. La forte mise en minuscules d'Unlimited-OCR gonfle les erreurs au niveau des caractères — son CER de 0,6552 contre un WER de 0,4779 le montre — tandis que le même texte normalisé correspond mieux aux motifs d'extraction fixes que tout autre moteur : score F1 regex SROIE de 0,3376, le meilleur des 8 moteurs (summary_metrics.csv cer / wer, field_method_comparison.csv regex_field_value_f1, lignes sroie_2019).

Pourquoi le CER CORD de PaddleOCR-VL est-il le pire du benchmark alors que son score F1 CORD est le meilleur ?

Parce que la vérité terrain de CORD intègre la structure d'annotation et que la sortie de PaddleOCR-VL est la plus propre et la plus normalisée — la plus éloignée de ce texte structuré, donc sa distance d'édition est la plus grande (CER 1,0805). Le même style de sortie alimente bien les motifs d'extraction : score F1 regex CORD de 0,3412, le meilleur des 8 moteurs (summary_metrics.csv, cer / field_f1_regex, lignes cord_v2). Cette inversion est la propre démonstration du benchmark que le CER CORD n'est pas une mesure de qualité par modèle.

Combien PaddleOCR-VL est-il plus rapide et moins cher que Surya2 ?

3,8× de latence p50 inférieure (694,3 ms contre 2 668,0 ms), 5,6× de débit supérieur (68,2 contre 12,1 pages/min) et 5,2× de coût inférieur pour 1 000 pages (0,205 $ contre 1,061 $) sur le même RTX 4090 à 0,76 $/h (summary_metrics.csv, latency_p50_ms / pages_per_minute / cost_per_1000_pages, lignes sroie_2019).

L’ajout d’un postprocesseur LLM rend-il les trois VLM équivalents ?

Presque — de 0,5921 à 0,6139 de F1 LLM sur les champs SROIE, un écart de 0,022 point dans la bande de convergence 0,57–0,62 du benchmark (field_method_comparison.csv, llm_field_value_f1, lignes sroie_2019). Le coût de cette convergence est d’environ 1,9–2,3 s de latence LLM médiane supplémentaire par document (llm_median_latency_ms, mêmes lignes), ce qui favorise le traitement par lots asynchrone.

Lequel des trois VLM un pipeline de reçus devrait-il choisir ?

Cela dépend de l’axe que votre pipeline consomme. Pour les champs multilingues natifs sans postprocesseur, le F1 regex CORD de PaddleOCR-VL (0,3412) est le seul niveau utile mesuré. Pour le service VLM le moins cher et le plus rapide, PaddleOCR-VL encore (694,3 ms, 0,205 $/1K pages). Pour un texte anglais brut propre quand le coût et la latence ne sont pas bloquants, le CER de Surya2 (0,1915) est le plus fort. Pour un point d’équilibre à volume moyen, Unlimited-OCR (1 600,7 ms, 0,388 $/1K pages, meilleur F1 SROIE hors boîte). Avec un postprocesseur LLM dans le pipeline, le choix importe peu sur les reçus — les trois se situent dans la bande de convergence. Ces résultats valent pour les reçus en anglais et en indonésien sur un niveau de GPU en août 2026 ; toute décision de production doit être re-testée sur le corpus cible (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, latence, coût, débit) et results/field_method_comparison.csv (regex vs post-traitement 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 un aperçu à trois volets d'une exécution de benchmark indépendante et reproductible (niveau officiel) — pas un recueil de revendications tierces, ni une page de comparaison de fournisseurs. Uniquement des ensembles de test fixes : test SROIE 2019 (361 reçus anglais, champs simples company/date/address/total) et test CORD v2 (100 reçus indonésiens, champs imbriqués menu/sub_total/total) ; les ensembles d'entraînement n'ont jamais été évalués. Les trois 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 d'échauffement fixe précède le passage noté, donc les chiffres de latence sont en régime permanent). Les trois exécutions se sont terminées avec error_rate 0.0 (colonne error_rate de summary_metrics.csv). L'exécution sous-jacente contient huit moteurs au total ; cette page ne compare que les trois VLM nommés, et 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 trois moteurs ont tourné sur le même 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).
• Moteurs : prêts à l'emploi, sans fine-tuning. Versions verrouillées : Surya2 (surya-ocr 0.22.1) et PaddleOCR-VL 1.6, tous deux servis par vLLM ; Unlimited-OCR servi par vLLM sans version publiquement épinglée (voir Limites) — selon le tableau des modèles du dépôt public (README.md) et les manifests d'exécution.
• Post-processeur 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 sur les trois moteurs.
• Base de coût : temps d'exécution réel × 0,76 $/h, y compris l'initialisation du modèle — le traitement par lot réduit le coût par page.
• 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 OCR + extraction en aval, pas la sortie structurée native d'un modèle ; les colonnes LLM_* mesurent texte OCR + 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. Injuste pour les VLM de parsing de documents : il pénalise la casse, la fusion étiquette/valeur et le réordonnancement des lignes comme des erreurs, même lorsque les valeurs de champs sont correctes. Cité sur cette page uniquement avec ses réserves.
• WER (taux d'erreur de mots) : le même calcul de distance d'édition au niveau des mots. Là où CER et WER divergent fortement (Unlimited-OCR : 0,6552 contre 0,4779), l'écart indique que c'est la normalisation de sortie, et non une erreur de lecture, qui cause le problème.
• F1 sur valeurs de champs (regex) : moyenne harmonique précision/rappel sur les valeurs de champs extraites à l'aide de motifs regex fixes appliqués au texte OCR (pipeline KIE traditionnel OCR + règles). Colonne : regex_field_value_f1. Un score de 0 signifie qu'aucune valeur de champ n'a été récupérée.
• F1 sur valeurs de champs (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.
• Champs de document exacts : fraction de documents où tous les champs cibles correspondent exactement — un critère bien plus strict que le F1 par champ.
• Latence p50/p95 & pages/min : temps d'inférence par page en régime permanent (échauffement puis évaluation, 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 $/heure.

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 surya2, unlimited_ocr et paddleocr_vl_vllm ici.
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 tokens. Chaque valeur de F1 de champs regex/LLM provient des trois lignes de moteurs nommés ici.
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 de 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 de modèles, GPU/driver, versions torch/CUDA/Python, métadonnées de coût avec horodatage du prix et hachages d'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

• Le CER est injuste envers les VLM, c'est pourquoi cette page repose sur des métriques de champ : les VLM de parsing de documents fusionnent la casse, rapprochent les lignes étiquette/valeur et réordonnent le texte, si bien que les scores CER bruts comptent les conventions de sortie comme des erreurs — la divergence CER (0,6552) vs WER (0,4779) d'Unlimited-OCR et l'inversion CORD de PaddleOCR-VL (pire CER 1,0805, meilleur F1 de champ 0,3412) sont toutes deux des artefacts de cette pénalité. Toute comparaison classant les VLM sur le CER — y compris sur cette page — doit être considérée comme une mesure du style de sortie, et non de la capacité de lecture.
• Périmètre des documents — reçus uniquement : SROIE + CORD. Rien ici ne mesure la gestion des mises en page, tableaux, formules ou documents longs, où les VLM de parsing de documents revendiquent leurs plus grands avantages ; les forces mises en avant par les trois moteurs (y compris le parsing mono-passe de 40+ pages d'Unlimited-OCR) sont non mesurées. N'utilisez pas cette page pour conclure « le VLM X gagne sur tout ».
• Taille de l'échantillon : 361 reçus en anglais + 100 en indonésien. Le F1 de champ et le CER dépendent du corpus ; les écarts de quelques centièmes (y compris l'écart de 0,022 point sur le F1 LLM) doivent être traités comme du bruit, pas comme une vérité d'ingénierie.
• Un seul niveau de GPU et un seul prix : tous les chiffres proviennent d'un RTX 4090 à 0,76 $/h, prix horodaté août 2026 dans les manifests d'exécution. D'autres GPU, le service multi-GPU, l'ordonnancement par lots ou les 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 autre LLM déplace le F1 de champ absolu ; l'ordre de convergence peut bouger à la marge. La latence LLM (médiane ~1,9–2,3 s, field_method_comparison.csv llm_median_latency_ms) est due à l'API et ne fait partie de la latence d'aucun moteur.
• Quarantaine CORD : la vérité terrain CORD intègre la structure d'annotation et les motifs regex ont été écrits pour des formats anglais ; le CER CORD (0,90–1,08 sur tous les moteurs) reflète la non-correspondance linguistique + l'inflation de la vérité terrain, pas la qualité par modèle. Les lignes CORD sont citées avec leur cadrage et ne sont jamais fusionnées dans un classement SROIE (règle du protocole).
• Épinglage des versions : les résultats valent pour Surya2 0.22.1, PaddleOCR-VL 1.6, et Unlimited-OCR servi par vLLM (août 2026). Unlimited-OCR n'a pas de numéro de version public épinglé dans le tableau de modèles publié du benchmark, donc sa ligne ne peut pas être rattachée à une version exacte ; des versions plus récentes de n'importe quel moteur peuvent déplacer chaque chiffre de cette page.
• Réglage des regex : l'ensemble de motifs a été écrit une fois par jeu de données. Une bibliothèque de motifs fortement réglée par format pourrait scorer plus haut sur ses propres mises en page — au coût de maintenance que le LLM élimine.

Références associées : Benchmark docTR vs Surya2 sur reçus · OCR traditionnel vs VLM de parsing de documents · quelle méthode d'extraction gagne sur les mises en page complexes · score par champ vs score par caractère · Précision de l'OCR sur reçus

Lectures complémentaires : OCR IA versus OCR traditionnel · extraction de données d'image vs moteurs OCR · Tarifs d'extraction de documents par IA (2026)