Surya2 vs Unlimited-OCR vs PaddleOCR-VL :
Benchmark VLM pour 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 du texte compris — cas normalisé, paires étiquette/valeur fusionnées sur une seule ligne, lignes réordonnées selon l'ordre de lecture — plutôt que les flux bruts de caractères avec la casse d'origine que retournent les moteurs OCR traditionnels (Tesseract, PaddleOCR, EasyOCR, docTR — les autres moteurs de l'exécution sous-jacente). Cette convention de sortie est ce qui rend leurs chiffres d'extraction de champs solides dès le départ et leurs chiffres bruts d'erreur de caractères trompeurs, comme la section suivante le montre. Au sein de la famille VLM, les trois diffèrent nettement par leur taille et leur objectif d'entraînement : Surya2 est un modèle de 650 millions de paramètres, centré sur le texte, optimisé pour la transcription complète de pages propres (plus de 90 langues) ; PaddleOCR-VL est un généraliste compact de 0,9 milliard de paramètres, conçu pour couvrir un large éventail de langues, de tableaux et de formules ; Unlimited-OCR est orienté vers l'analyse de longs documents et le traitement par lots (la lecture en un seul passage de documents de plus de 40 pages est son cœur commercialisé). Un avertissement important 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 champ est la mesure inter-VLM plus équitable, et c'est l'axe 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

En lisant uniquement la colonne CER brute, Unlimited-OCR ressemble à un modèle raté (0,6552 sur SROIE) tandis que Surya2 a l'air d'un modèle de classe mondiale (0,1915, à égalité avec le CER brut traditionnel de docTR à 0,1971, le meilleur CER brut des 8 moteurs). Les deux lectures sont des artefacts du style de sortie. Le même texte Unlimited-OCR qui obtient 0,6552 de CER obtient 0,4779 de WER — ses mots survivent tandis que ses caractères semblent déformés, car la normalisation de cas remplace des caractères sans casser les mots. Les chiffres de PaddleOCR-VL inversent le schéma : son CER sur CORD de 1,0805 est le pire des 8 moteurs tandis que son score F1 sur les champs CORD de 0,3412 est le meilleur des 8 — le CSV du benchmark contredit lui-même le classement par CER.

Le mécanisme a deux couches. Couche 1 — la taxe de normalisation : les VLM d'analyse de documents produisent du texte « compris » — TAN CHAY YEE devient tan chay yee, INVOICE NO : PEGIV fusionne une étiquette et une valeur sur une seule ligne. Le CER est une correspondance exacte de caractères, donc chaque cas normalisé et ligne fusionnée est comptabilisé 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 de CER brut aux substitutions de cas et environ un dixième aux fusions/suppressions de lignes ; les trois moteurs paient cette taxe à des taux différents — la normalisation intensive d'Unlimited-OCR gonfle son CER bien au-delà de son WER, tandis que la fusion lignes/étiquettes de PaddleOCR-VL pousse son WER (0,6462) au-dessus de son propre CER (0,3370). Couche 2 — gonflement 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 champs), donc le CER est systématiquement gonflé pour chaque moteur en plus de la véritable inadéquation linguistique — le regroupement des CER sur CORD pour tous les moteurs entre 0,90 et 1,08 (Tesseract traditionnel 0,9523, docTR 0,9101, et chaque VLM inclus) confirme que le gonflement est général au corpus, pas spécifique à un 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 est meilleur ; 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-field-F1 de PaddleOCR-VL sur CORD (voir ci-dessous) sont des artefacts de convention de sortie du même type que ceux que le protocole de ce benchmark signale pour les lignes de 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 dont leur sortie structurée se nourrit 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 de ce benchmark pour les lignes de 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êts à l'emploi : la sortie structurée est le trait commun des VLM

Faites passer le texte brut de chaque moteur à travers les mêmes expressions régulières fixes sur les quatre champs de reçus SROIE (entreprise, date, adresse, total) — l'approche traditionnelle OCR + extraction d'informations clés (KIE) basée sur des règles — et 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 figurent dans le top quatre des huit moteurs testés ; deux d'entre eux surpassent le meilleur moteur traditionnel (0,3254 pour PaddleOCR), et le troisième ne le suit que de 0,007 point. Leur « texte compris » parvient aux consommateurs de champs même sans aucun postprocesseur LLM — le trait commun que les moteurs OCR à caractères bruts n'ont pas.

Le score F1 des champs est la moyenne harmonique de la précision et du rappel sur les valeurs des champs extraits par rapport à la vérité terrain : 1,0 signifie que chaque champ du 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 structuré par étiquettes et à casse uniforme qui gonfle le CER correspond aux motifs d'extraction. Les colonnes « regex field extraction » sont les métriques postprocessed_sroie_receipt_regex_* du benchmark : elles mesurent le texte OCR + l'extraction basée sur des règles en aval, pas la sortie structurée native, et le même jeu de motifs a été appliqué à chaque moteur. À titre de comparaison, le score F1 des champs par regex des moteurs traditionnels atteint 0,0766 (docTR), 0,1477 (EasyOCR), 0,2237 (Docling) et 0,2335 (Tesseract) — six des sept moteurs non-VLM se situent en dessous du membre le plus faible du trio.

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

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

Le levier LLM : les trois moteurs convergent

Alimentez un post-traitement LLM (deepseek-v4-flash, température 0) avec le texte OCR des trois moteurs et un prompt d'extraction structurée, et la bande de dispersion se resserre en un 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 des moteurs sains. Le post-traitement, et non le VLM, devient le composant déterminant.

C'est le même schéma de convergence que montre l'exécution complète des 8 moteurs : un LLM comprend la sémantique (noms, dates, chiffres) au lieu de correspondre aux formes des caractères, il absorbe donc la plupart des différences de qualité du texte en amont — à condition que le texte soit suffisamment lisible pour servir de base. Les trois VLMs (modèles vision-langage) répondent aux critères ; les trois atterrissent 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 — coûts API, de même nature), ce qui favorise le traitement asynchrone par lots plutôt que les attentes synchrones page par page. L'exactitude au niveau document — la fraction de reçus où tous les quatre champs correspondent — reste faible pour les trois (0,1219 à 0,1551), rappelant que le score F1 par champ est l'indicateur opérationnel significatif.

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 un coût API, séparée de la latence moteur (summary_metrics.csv latency_p50_ms).

CORD (reçus indonésiens) : le généraliste compact gagne

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 distinguent réellement. Avec les mêmes expressions régulières au format anglais, PaddleOCR-VL extrait les champs des reçus indonésiens avec un score F1 de 0,3412 par champ — le plus élevé des 8 moteurs de l'ensemble du benchmark — tandis que Surya2 obtient 0,2458 et Unlimited-OCR chute à 0,1079. L'ampleur de l'entraînement du généraliste compact se manifeste exactement là où les modèles centrés sur le texte et les documents longs perdent du terrain.

Toutes les valeurs de CER de CORD sont isolées par le protocole du benchmark et ne sont jamais intégrées au classement SROIE : la vérité terrain de CORD intègre la structure d'annotation (gonflant le CER brut pour chaque moteur en plus de la véritable inadéquation linguistique — le cluster de CER pour tous les moteurs sur CORD se situe entre 0,90 et 1,08), et les expressions régulières ont été rédigées pour des formats anglais. La comparaison CORD ci-dessous ne présente que les métriques par champ. Avec un post-traitement LLM, le choc linguistique est absorbé comme sur SROIE : le trio converge à nouveau vers un score F1 de 0,4678–0,5203 par champ (Surya2 0,5203, PaddleOCR-VL 0,5198, Unlimited-OCR 0,4678) — c'est le post-traitement, et non le moteur, qui assure 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 maximum de field_f1_regex sur les 16 lignes du fichier ; le meilleur suivant sur CORD regex est Surya2 0,2458.

Tableau : 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 un quelconque classement SROIE : le CER de CORD combine une véritable inadéquation linguistique avec une inflation liée à la structure des annotations dans la vérité terrain (tous les moteurs se regroupent entre 0,90–1,08 — Tesseract traditionnel 0,9523, docTR 0,9101 inclus) ; le CER de PaddleOCR-VL de 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 de structure de CORD — tandis que son score F1 regex par champ est le meilleur de l'ensemble de référence.

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

La précision par champ converge ; le coût opérationnel, non. Sur la même RTX 4090 au même tarif enregistré de 0,76 $/h, PaddleOCR-VL maintient 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 l'exception en termes de prix et de 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 réel × le tarif RunPod RTX 4090 (0,76 $/heure, prix horodaté dans les manifests d'exécution), incluant 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 réel, incluant cette même initialisation. Les latences p50/p95 sont les temps d'inférence par page en régime permanent mesurés à chaud puis scorés (chargement du modèle exclu) ; la queue de Surya2 est proportionnellement pire — 5 872,2 ms p95 contre 1 154,3 ms pour PaddleOCR-VL — car les pics de préremplissage/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 est dépassé en débit réel par Unlimited-OCR sur CORD (73,99 contre 67,13 pages/min) — les chiffres réels incluent l'initialisation du modèle, et la gestion par lots vLLM d'Unlimited-OCR est suffisamment 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 réel × 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 le débit pur 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 séparent nettement : la précision des champs converge (regex et LLM), le texte brut brut favorise Surya2, les champs multilingues favorisent PaddleOCR-VL, et chaque axe coût/latence/débit favorise PaddleOCR-VL avec Unlimited-OCR au milieu. La conclusion honnête est que sur les reçus, avec n’importe quel postprocesseur dans le pipeline, le choix du VLM importe peu — et sans postprocesseur, le généraliste compact et bon marché bat les spécialistes coûteux sur les axes qui comptent généralement.

Foire aux questions

Quel VLM d'analyse de documents est le plus précis pour les reçus ?

Pour l'extraction de champs, c'est une quasi-égalité à trois sur les reçus anglais : le score F1 des champs regex SROIE va de 0,3183 à 0,3376 et le score F1 des champs LLM de 0,5921 à 0,6139 pour Surya2, Unlimited-OCR et PaddleOCR-VL (fichier field_method_comparison.csv, lignes sroie_2019). Sur les reçus indonésiens, la réponse change : le score F1 des champs regex CORD de PaddleOCR-VL, à 0,3412, est le meilleur des 8 moteurs du benchmark (fichier summary_metrics.csv, champ field_f1_regex, lignes cord_v2). Le taux d'erreur de caractères (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 taux d'erreur de caractères (CER) mais le meilleur score F1 des champs regex sur SROIE ?

Parce que les deux métriques évaluent des sorties différentes. La mise en minuscules intensive d'Unlimited-OCR gonfle les erreurs au niveau des caractères — son taux d'erreur de caractères (CER) de 0,6552 contre un taux d'erreur de mots (WER) de 0,4779 en est la preuve — tandis que le texte normalisé correspondant se trouve mieux correspondre aux motifs d'extraction fixes que tout autre moteur : le score F1 des champs regex SROIE de 0,3376, le plus élevé des 8 moteurs testés (fichier summary_metrics.csv cer / wer, fichier field_method_comparison.csv regex_field_value_f1, lignes sroie_2019).

Pourquoi le taux d'erreur de caractères (CER) de PaddleOCR-VL sur CORD est-il le pire du benchmark alors que son score F1 des champs 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 chargé en structure, de sorte que sa distance d'édition est la plus élevée (taux d'erreur de caractères (CER) de 1,0805). Le même style de sortie alimente bien les motifs d'extraction : le score F1 des champs regex CORD de 0,3412, le meilleur des 8 moteurs (fichier summary_metrics.csv, cer / field_f1_regex, lignes cord_v2). Cette inversion est la démonstration par le benchmark lui-même que le taux d'erreur de caractères (CER) sur CORD n'est pas une mesure de la qualité par modèle.

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 plus élevé (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 la 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 post-traitement LLM égalise-t-il les trois VLM ?

Presque — de 0,5921 à 0,6139 de score F1 de champ LLM sur SROIE, un écart de 0,022 point à l'intérieur de la bande de convergence de 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 doit-il choisir ?

Cela dépend de l'axe que votre pipeline consomme. Pour des champs interlangues natifs sans post-traitement, le score F1 regex CORD de PaddleOCR-VL (0,3412) est le seul niveau utile mesuré. Pour un service VLM le moins cher et le plus rapide, c'est encore PaddleOCR-VL (694,3 ms, 0,205 $/1K pages). Pour un texte brut anglais propre lorsque 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 score F1 de champ SROIE hors de la boîte). Avec un post-traitement LLM dans le pipeline, le choix importe peu sur les reçus — les trois se situent dans la bande de convergence. Ces résultats s'appliquent aux reçus en anglais et en indonésien sur un seul niveau de GPU en août 2026 ; toute décision de production devrait être relancé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 interne — results/summary_metrics.csv (CER/WER, champ F1, 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 partiellement masqué par exécution pour les empreintes d'environnement. Les définitions des jeux de données proviennent des articles SROIE 2019 et CORD cités ci-dessous.

Méthodologie & Sources

Protocole

Cette page présente une tranche à trois voies d'un benchmark indépendant et reproductible (niveau officiel) — pas un recueil d'affirmations de tiers, ni une page de comparaison de fournisseurs. Uniquement des partitions 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 partitions d'entraînement n'ont jamais été évaluées. 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 de chauffage 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 un error_rate de 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 OCR traditionnel vs VLM d'analyse de documents.

Environnement d'exécution

• Matériel : les trois moteurs ont tourné sur le même NVIDIA RTX 4090 (24 Go) ; le coût GPU calculé au tarif à la demande de RunPod de $0,76/heure, le prix horodaté dans le manifest masqué de chaque exécution (août 2026).
• Moteurs : en configuration d'usine, sans fine-tuning. Versions verrouillées : Surya2 (surya-ocr 0.22.1) et PaddleOCR-VL 1.6, tous deux servis via vLLM ; Unlimited-OCR servis via vLLM sans version publiquement figée (voir Limites) — selon le tableau des modèles du dépôt public (README.md) et les manifests 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 modèle unique utilisé pour toutes les lignes de champs LLM des trois moteurs.
• Base de coût : temps d'exécution réel × $0,76/heure, incluant l'initialisation du modèle — le traitement par lots réduit le coût par page.
• Post-traitement des champs : les métriques regex des champs SROIE sont postprocessed_sroie_receipt_regex_* (colonnes regex_* de field_method_comparison.csv) — champs extraits du texte OCR par un ensemble de motifs fixes. Ils mesurent l'OCR + l'extraction en aval, pas la sortie structurée native d'un modèle ; les colonnes LLM_* mesurent le texte OCR + l'extraction LLM. Les deux pipelines ne sont jamais mélangées.

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 bas est mieux. Injuste pour les VLM (modèles vision-langage) de parsing de documents : il pénalise la casse, la fusion étiquette/valeur et la réorganisation des lignes comme des erreurs, même lorsque les valeurs des 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. Lorsque le CER et le WER divergent fortement (Unlimited-OCR : 0,6552 vs 0,4779), l'écart indique que c'est la normalisation de la sortie, et non une mauvaise lecture, qui est en cause.
• Score F1 des valeurs de champ (regex) : moyenne harmonique précision/rappel sur les valeurs de champ extraites en utilisant des motifs regex fixes sur le texte OCR (pipeline OCR traditionnel + KIE basé sur des règles). Colonne : regex_field_value_f1. Un score de 0 signifie qu'aucune valeur de champ n'a été récupérée.
• Score F1 des valeurs de champ (LLM) : la 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.
• Champs du document exacts : fraction des documents où tous les champs cibles correspondent exactement — un critère bien plus strict que le score F1 par champ.
• Latence p50/p95 & pages/min : temps d'inférence par page en régime permanent (après chauffe puis mesure, exclut le chargement du modèle) et débit 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.

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 de CER/WER, latence, coût et débit sur 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 regex/llm pour les champs, document-fields-exact, llm_median_latency_ms, nombre de tokens. Chaque valeur de F1 pour les champs regex/LLM provient des trois lignes de moteurs nommés ici.
3. ImageToTableai/benchmark-ocr repository. Dépôt public hébergeant les CSV de résultats, les manifests d'exécution caviardés, le protocole figé et les listes d'échantillons de jeux de données (partitions de test fixes) pour la reproductibilité.
4. results/manifests/ (GitHub). Un manifest.json caviardé par exécution publiée (16 exécutions) avec les versions des modèles, GPU/pilote, versions torch/CUDA/Python, métadonnées de coût avec horodatage des prix et empreintes 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 de la tâche 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

• L'injustice du CER envers les VLM est la raison pour laquelle cette page est construite sur des métriques de champ : les VLM de parsing de documents fusionnent la casse, fusionnent les lignes étiquette/valeur et réorganisent le texte, donc les scores CER bruts considèrent les conventions de sortie comme des erreurs — la divergence du CER (0,6552) vs WER (0,4779) d'Unlimited-OCR et l'inversion de CORD de PaddleOCR-VL (pire CER 1,0805, meilleur score F1 de champ 0,3412) sont toutes des artefacts de cette taxe. Toute comparaison qui classe 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 document — reçus uniquement : SROIE + CORD. Rien ici ne mesure la gestion de la mise en page/tableaux/formules/documents longs où les VLM de parsing de documents revendiquent leurs plus grands avantages ; les forces commercialisées des trois moteurs (y compris le parsing en un seul passage de plus 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 reçus en indonésien. Le score F1 de champ et le CER sont sensibles au corpus ; des différences à un chiffre de quelques centièmes (y compris l'écart de 0,022 point du LLM-F1) doivent être traitées comme du bruit, et non comme une vérité d'ingénierie.
• Un seul niveau de GPU et un seul prix : tous les chiffres proviennent d'un seul RTX 4090 à 0,76 $/h, le prix étant horodaté en août 2026 dans les manifests d'exécution. D'autres GPU, un service multi-GPU, une planification par lots ou des changements de prix modifieront la latence, le débit et le coût — recalculez les coûts aux tarifs actuels avant de budgétiser.
• Un seul post-traitement LLM : toutes les lignes LLM utilisent deepseek-v4-flash à une température de 0. Un LLM différent modifie le score F1 de champ absolu ; l'ordre de convergence peut se déplacer aux marges. La latence du LLM (~1,9–2,3 s médiane, llm_median_latency_ms dans field_method_comparison.csv) est imputée à l'API et ne fait pas partie de la latence propre d'un moteur.
• Mise en quarantaine de CORD : la vérité terrain de CORD intègre la structure d'annotation et les expressions régulières ont été rédigées pour des formats anglais ; le CER de CORD (0,90–1,08 pour tous les moteurs) reflète l'inadéquation linguistique + l'inflation de la vérité terrain, et non la qualité par modèle. Les lignes CORD sont citées avec un cadrage et ne sont jamais fusionnées dans un classement SROIE (règle de protocole).
• Verrouillage des versions : les résultats sont valables pour Surya2 0.22.1, PaddleOCR-VL 1.6 et Unlimited-OCR servis via vLLM (août 2026). Unlimited-OCR n'a pas de numéro de version publiquement verrouillé dans le tableau des modèles publié du benchmark, donc sa ligne ne peut pas être retracée à une version exacte ; des versions plus récentes de n'importe quel moteur peuvent modifier chaque chiffre de cette page.
• Ajustement des expressions régulières : l'ensemble de motifs a été rédigé une fois par jeu de données. Une bibliothèque de motifs fortement ajustée par format pourrait obtenir un score plus élevé sur ses propres mises en page — au coût de maintenance que le LLM supprime.

Références connexes : Benchmark de reçus docTR vs Surya2 · OCR traditionnel vs VLM de parsing de documents · Regex vs extraction de champs par LLM · Précision au niveau champ vs au niveau caractère · Précision de l'OCR de reçus

Lectures complémentaires : Précision de l'OCR par IA vs OCR traditionnel · Extraction de données d'images par IA vs OCR traditionnel · Tarification de l'extraction de documents par IA (2026)