Extraction de champs par regex vs LLM pour les reçus
Résultats du benchmark interne (2026)

Résultats SROIE : reçus en anglais (361 échantillons)

Sur les reçus en anglais, le LLM surpasse le regex pour chacun des 8 moteurs — l'amélioration la plus faible est de 1,76× (PaddleOCR-VL 0,337 → 0,592), la plus élevée de 8,1×. Et le LLM efface presque l'écart entre les modèles : 6 des 7 moteurs non-Tesseract se situent dans une bande de 0,05 point (0,569–0,617), alors que leurs résultats regex étaient répartis sur 0,26 point (0,077–0,338).

SROIE (Scanned Receipt OCR and Information Extraction, ICDAR 2019) est le benchmark standard des reçus en anglais : 361 reçus de test avec quatre champs cibles — entreprise, date, adresse et total (Huang et al., 2019). Chaque moteur a d'abord produit du texte OCR sur une configuration RTX 4090 partagée ; ce texte a ensuite été transmis à deux postprocesseurs parallèles : un ensemble fixe de motifs regex (l'approche traditionnelle OCR + KIE basée sur des règles) et le LLM deepseek-v4-flash avec une invite d'extraction structurée. Les deux ont été évalués sur les mêmes champs de vérité terrain. Le graphique montre le F1 du champ regex (bleu) par rapport au F1 du champ LLM (vert) pour chaque moteur.

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

Source : field_method_comparison.csv — lignes sroie_2019 : regex_field_value_f1 / llm_field_value_f1 / regex_field_value_accuracy / llm_field_value_accuracy (décimales 0–1 affichées en %). F1 docTR 0,0766 → 0,6171 ; Surya2 0,3183 → 0,6139 ; PaddleOCR 0,3254 → 0,5810.

Résultats CORD : reçus indonésiens (100 échantillons, test de résistance)

CORD creuse l'écart, non parce que le LLM s'améliore — ce n'est pas le cas — mais parce que le regex s'effondre : six des huit moteurs obtiennent un F1 regex par champ à 10,8 % ou moins, et deux (docTR 0,0 %, EasyOCR 0,7 %) ne récupèrent presque rien. Le LLM élève toujours chaque moteur non-Tesseract à 33,8 % ou plus, prouvant que son extraction se généralise à travers les langues et les mises en page là où les motifs écrits à la main ne le peuvent pas.

CORD v2 est un ensemble de données de reçus en indonésien avec des champs imbriqués (menu, sub_total, total) (Park et al., 2019), utilisé comme test de résistance interlangue : aucun des 8 moteurs n'a été principalement entraîné sur des reçus indonésiens. Deux réserves s'appliquent à la lecture de ce tableau. Premièrement, le texte de vérité terrain de CORD inclut la structure d'annotation et les différences de normalisation de sortie des VLM, ce qui gonfle systématiquement le CER brut pour chaque moteur — les métriques par champ ci-dessous, et non le CER, constituent donc la comparaison équitable entre modèles. Deuxièmement, les motifs regex ont été écrits pour le schéma plat anglais SROIE ; le schéma imbriqué de CORD et le format indonésien (devise Rp, conventions de dates) les neutralisent — ce qui est en soi la conclusion : des règles adaptées à un marché ne voyagent pas.

Source : field_method_comparison.csv — lignes pour dataset=cord_v2, colonnes regex_field_value_f1 / llm_field_value_f1 (décimales 0–1 affichées en %). 100 échantillons par moteur (llm_ok_count).

Source : field_method_comparison.csv — lignes cord_v2 (F1 et précision des valeurs de champ regex/llm, décimales 0–1 affichées en %). PaddleOCR LLM F1 0,0154 → 0,5527 ; docTR 0,0 → 0,5500 ; tesseract 0,0752 → 0,1627.

Pourquoi le LLM aplatit l'écart — et où se situe son plafond

Trois tendances dans les chiffres expliquent ce qui se passe en surface. Chacune est une affirmation testable avec ses cellules CSV exactes ci-dessous.

(a) Le LLM transforme un écart de modèle de 0,26 point en une bande de 0,05 point

Avec regex, le moteur choisi importait énormément : le F1 du champ SROIE s'étendait de 0,077 (docTR) à 0,338 (Unlimited-OCR) — un écart de 0,26 point. Avec le LLM, six des sept moteurs non-Tesseract se situent entre 0,569 (Docling) et 0,617 (docTR) — une bande de 0,05 point (field_method_comparison.csv, lignes sroie_2019, regex_field_value_f1 vs llm_field_value_f1). L'OCR en amont n'a besoin que de produire un texte lisible ; le LLM en extrait les champs avec une qualité globalement indépendante du moteur. Deux moteurs restent en dehors de cette bande : EasyOCR à 0,372 (le F1 LLM le plus bas sur les reçus anglais) et Tesseract à 0,439. Sur CORD, Tesseract devient le retardataire évident — son 0,163 est le pire résultat LLM de tout le tableau.

(b) Le plafond de Tesseract est fixé par son OCR, pas par son postprocesseur

« Garbage in, garbage out » s'applique même au post-traitement par LLM. Le texte OCR brut de Tesseract sur les reçus indonésiens a un taux d'erreur de caractères de 0,9523 (summary_metrics.csv, tesseract/cord_v2, cer) — environ 95 caractères sur 100 sont faux ou mal ordonnés. Son F1 de champ LLM sur CORD est par conséquent de 0,1627 (field_method_comparison.csv, tesseract/cord_v2, llm_field_value_f1) : un LLM ne peut pas extraire un nom d'entreprise ou un total d'un texte qu'il ne peut pas lire. Le plafond de tout postprocesseur est fixé par la qualité de base de l'OCR en dessous — une contrainte qu'aucun réglage de prompt ne supprime.

(c) docTR est le plus grand bénéficiaire : du plancher regex au sommet LLM

L'histoire de docTR est la démonstration la plus claire que le problème venait du postprocesseur, pas de l'OCR. Son F1 de champ regex sur SROIE était le plus bas des 8 moteurs à 0,0766 — son texte propre et précis (CER SROIE 0,1971, le meilleur du benchmark, ligne summary_metrics.csv pour doctr/sroie_2019) ne correspondait tout simplement pas aux motifs regex pour les totaux avec séparateurs de milliers ou les adresses multilignes. Avec le LLM, le même texte produit le résultat SROIE le plus élevé du benchmark, 0,6171 — un gain de 8,1× et le plus important du tableau (field_method_comparison.csv, doctr/sroie_2019, regex_field_value_f1 0,0766 → llm_field_value_f1 0,6171). Sur CORD, l'effet se répète : 0,0 avec regex, 0,5500 avec le LLM.

Quand la regex suffit vs quand utiliser un LLM

Le vrai compromis n'est pas « la regex est cassée » mais « la regex est fragile là où les reçus sont variables ». Le post-traitement par regex est déterministe, gratuit et instantané ; un post-processeur LLM ajoute des tokens et 1,8–2,4 s de médiane par document (field_method_comparison.csv, llm_median_latency_ms sur les 16 lignes). En contrepartie, le LLM a récupéré 1,76–8,1× plus de champs sur SROIE — et sur CORD, où la regex s'est effondrée à près de zéro pour la plupart des moteurs, le LLM a récupéré 33,8–55,3 % des champs que l'extraction par règles ne pouvait tout simplement pas atteindre.

Quand la regex suffit : si vos documents proviennent d'un petit ensemble stable de mises en page et que les champs dont vous avez besoin apparaissent dans des formats quasi constants — un motif de numéro de facture fixe, une seule convention de date, une seule devise — la regex est le bon outil : elle ne coûte rien, s'exécute en microsecondes, et ses échecs sont prévisibles. Les cas planchers du benchmark le montrent : les moteurs avec une regex alignée sur les reçus ont encore atteint 0,34 de F1 sur les champs de SROIE (Unlimited-OCR 0,3376, PaddleOCR-VL 0,3368).

Quand utiliser un LLM : dès que la variance de format entre en jeu — plusieurs devises, formats de date régionaux, adresses multi-lignes, noms de fournisseurs dans des styles variés, ou une seconde langue. Chacun de ces éléments casse un motif ; le LLM les absorbe tous en un seul prompt. Les résultats CORD du benchmark quantifient ce que « une langue de plus » coûte à un pipeline basé sur des règles : le F1 des champs regex est passé de 0,08–0,34 (SROIE anglais) à 0,00–0,34 (CORD indonésien), tandis que le LLM a maintenu 0,16–0,55 — une pénalité que l'approche regex a payée à 100 % et que le LLM n'a payée que partiellement. La bonne architecture pour la plupart des flux de production est hybride : extraction LLM pour les champs variables, validation par regex ou règles pour les champs aux formats stricts attendus, avec le coût LLM de 1,8–2,4 s par document amorti dans un traitement par lots asynchrone plutôt que dans des attentes utilisateur synchrones.

Questions fréquentes

L'extraction de champs par LLM est-elle plus précise que l'extraction par regex ?

Oui, dans ce benchmark, sur chaque ligne : le post-traitement par LLM (deepseek-v4-flash) a surpassé le post-traitement par regex pour les 8 moteurs OCR sur les deux jeux de données (field_method_comparison.csv, 16 lignes au total). Sur les reçus anglais SROIE, le F1 des champs par LLM était de 0,37–0,62 contre 0,08–0,34 pour la regex ; sur les reçus indonésiens CORD, 0,16–0,55 contre 0,00–0,34.

Quel modèle OCR extrait le mieux les champs de reçus avec un post-traitement par LLM ?

docTR sur SROIE, avec un F1 de champs de 0,6171 — mais les différences entre moteurs disparaissent en grande partie dès qu'un LLM est intégré : six des sept moteurs non-Tesseract se situent entre 0,569 et 0,617 (field_method_comparison.csv, lignes sroie_2019, llm_field_value_f1). Sur CORD, PaddleOCR mène avec 0,5527, docTR suivant de près avec 0,5500.

Pourquoi Tesseract reste-t-il à la traîne même avec un LLM ?

Parce que son texte OCR est trop dégradé pour qu'un post-processeur puisse en récupérer les champs. Sur les reçus indonésiens, son taux d'erreur de caractères est de 0,9523 (summary_metrics.csv, tesseract/cord_v2), ce qui plafonne son F1 de champs par LLM à 0,1627 — le pire résultat LLM du benchmark (field_method_comparison.csv, tesseract/cord_v2, llm_field_value_f1).

Dans quelle mesure un LLM améliore-t-il l'extraction de champs par rapport à la regex ?

Entre 1,76× et 8,1× sur les reçus anglais selon le moteur, avec la plus forte amélioration sur docTR (0,077 → 0,617 de F1 de champs, lignes sroie_2019 de field_method_comparison.csv). Sur les reçus indonésiens, l'amélioration est bien plus importante — 36× pour PaddleOCR et pratiquement illimitée pour docTR (0,0 → 0,55) car la regex ne récupérait presque rien.

Le post-traitement LLM détecte-t-il tous les champs correctement ?

Non — et les lecteurs ne doivent pas s'y attendre. Le meilleur F1 de champ LLM du benchmark est de 0,617 (docTR, SROIE), ce qui signifie qu'environ 38 % des champs ont encore été manqués ou mal détectés, et le meilleur taux de correspondance exacte de document entier est de 15,5 % (Surya2, SROIE, llm_document_fields_exact) — c'est-à-dire qu'au maximum ~1 document sur 6 avait les quatre champs exactement corrects. L'extraction par LLM est une grande amélioration par rapport aux regex, mais pas une solution miracle ; la notation de confiance au niveau du champ et la relecture humaine restent nécessaires en production.

Le post-traitement LLM est-il lent ou coûteux ?

Dans ce benchmark, l'appel LLM a ajouté une latence médiane de 1,8 à 2,4 s par document (field_method_comparison.csv, llm_median_latency_ms, les 16 lignes), et l'exécution complète des 16 groupes a consommé environ 1,33 M de jetons de prompt + 0,28 M de jetons de complétion (somme de llm_prompt_tokens / llm_completion_tokens). Ce n'est pas une latence d'extraction de champs en temps réel — cela convient au traitement par lots asynchrone, pas aux recherches interactives.

Le post-traitement LLM fonctionne-t-il sur les reçus non anglais ?

Mieux que les regex, mais avec un plafond plus bas. Sur les reçus CORD indonésiens, le LLM a maintenu le F1 de champ à 0,16 à 0,55 là où les regex se sont effondrées à 0,00 à 0,34 (field_method_comparison.csv, lignes cord_v2) — mais le meilleur résultat CORD (0,5527) reste inférieur au meilleur résultat anglais (0,6171), reflétant à la fois l'écriture plus difficile et la base OCR dégradée. Les règles écrites pour les reçus anglais ont essentiellement cessé de fonctionner ; le LLM s'est dégradé avec élégance à la place.

Méthodologie et sources

Protocole

Cette page présente la comparaison d'extraction de champs du benchmark OCR open-source d'ImageToTable.ai — une exécution expérimentale indépendante et reproductible (niveau officiel), et non une synthèse de revendications tierces. Le pipeline pour chaque paire (modèle × jeu de données) : le moteur OCR produit le texte des images de reçus ; ce texte est ensuite extrait deux fois — une fois par un ensemble fixe de motifs regex et une fois par le postprocesseur LLM — et les deux sorties sont évaluées par rapport aux mêmes champs de vérité terrain. Le postprocesseur LLM est deepseek-v4-flash (colonne llm_model dans le CSV de comparaison), exécuté à température 0 pour une sortie déterministe. Les 361 échantillons SROIE et les 100 échantillons CORD ont tous été traités avec succès (llm_ok_count = 361 / 100).

Environnement d'exécution

• Matériel : toutes les exécutions GPU sur NVIDIA RTX 4090 (24 Go). Les moteurs basés sur PyTorch (docTR, EasyOCR, Docling) ont fonctionné avec PyTorch 2.8.0+cu128 (CUDA 12.8) ; Tesseract a fonctionné en CPU uniquement (aucun coût GPU) ; les moteurs servis par vLLM (Surya2, Unlimited-OCR, PaddleOCR-VL) ont fonctionné sur un pod vLLM. Les versions du pilote et de Python varient légèrement selon l'exécution et sont enregistrées exactement dans les manifestes d'exécution expurgés (voir Accès aux artefacts ci-dessous).
• Postprocesseur LLM : deepseek-v4-flash via API, température 0.
• Mode de mesure : warm_then_scored — une passe d'échauffement fixe précède la passe notée, de sorte que les chiffres de latence reflètent un état stable.
• Jeux de données : test SROIE 2019 — 361 reçus en anglais, champs plats (entreprise, date, adresse, total), CC-BY-4.0 ; test CORD v2 — 100 reçus en indonésien, champs imbriqués (menu, sub_total, total), CC-BY-4.0.
• Nombre d'échantillons : SROIE 361 / CORD 100, tous issus des divisions de test fixes (aucune fuite de données d'entraînement).

Le texte OCR en amont consommé par les deux postprocesseurs provient de ces versions de moteurs :

Les empreintes de reproductibilité complètes par exécution figurent dans les manifestes d'exécution expurgés du benchmark sous results/manifests/ dans le dépôt public (un manifest.json par exécution publiée, 16 au total). Chacun divulgue : l'identifiant d'exécution, le modèle + la version, le hash du script d'exécution (SHA-256), le modèle/driver/VRAM GPU, les versions torch/CUDA/torchvision/torchaudio, la version Python, le hash pip-freeze, les métadonnées de coût (GPU $/heure et horodatage du prix), le mode de mesure et les hash des artefacts (liste d'échantillons, prédictions, métriques, performance).

Définitions des métriques

• F1 valeur de champ (approche regex) : moyenne harmonique de la précision et du rappel sur les valeurs de champs extraites, avec post-traitement regex — l'approche KIE traditionnelle basée sur OCR + règles. Colonne : regex_field_value_f1.
• F1 valeur de champ (approche LLM) : la même métrique calculée sur la sortie du postprocesseur LLM — l'approche OCR + post-traitement LLM. Colonne : llm_field_value_f1. Ces deux approches sont des pipelines distincts et ne sont jamais combinées.
• Précision valeur de champ : fraction des valeurs de champs extraites qui correspondent exactement à la vérité terrain (regex_field_value_accuracy / llm_field_value_accuracy).
• Champs de document exacts : fraction des documents où chaque champ cible correspond exactement (regex_document_fields_exact / llm_document_fields_exact).
• CER/WER (contexte uniquement) : taux d'erreur de caractères/mots du texte OCR brut, utilisé sur cette page uniquement pour expliquer le plafond LLM de Tesseract.

Accès aux artefacts

1. field_method_comparison.csv (GitHub raw). 16 lignes = 8 modèles × 2 jeux de données ; colonnes model, dataset, llm_model (= deepseek-v4-flash), F1 de champ regex/llm + précision, champs de document exacts, llm_median_latency_ms, llm_prompt_tokens, llm_completion_tokens. Chaque nombre de F1 et de précision sur cette page provient d'une ligne ici.
2. summary_metrics.csv (GitHub raw). CER/WER par modèle × jeu de données, utilisé pour l'explication du plafond Tesseract (tesseract/cord_v2 cer 0.9523) et le CER SROIE de docTR de 0.1971.
3. Dépôt ImageToTableai/benchmark-ocr. Dépôt public hébergeant les CSV de résultats, les manifestes d'exécution et les listes d'échantillons de jeux de données pour la reproduction.
4. results/manifests/ (GitHub). Un manifest.json expurgé par exécution publiée (16 exécutions), avec l'empreinte d'environnement par exécution et les hachages d'artefacts listés ci-dessus.
5. Huang et al., « ICDAR2019 Competition on Scanned Receipt OCR and Information Extraction » (2019). Définition et licence du jeu de données SROIE.
6. Park et al., « CORD: A Consolidated Receipt Dataset for Post-OCR Parsing » (2019). Définition et licence du jeu de données CORD v2.

Limites

• Portée du document : Reçus uniquement (SROIE + CORD). Les résultats ne se généralisent pas aux factures, formulaires ou documents longs sans tests supplémentaires.
• Taille de l'échantillon : 361 reçus en anglais + 100 reçus en indonésien. Le F1 par champ est sensible à la composition du corpus ; considérez les écarts de quelques centièmes comme du bruit.
• Modèle LLM unique : Toutes les lignes LLM utilisent deepseek-v4-flash. Un LLM différent (taille, prompt ou fournisseur) produirait des chiffres absolus différents ; l'ordre regex-vs-LLM pourrait changer à la marge.
• Réserve sur la vérité terrain CORD : Le gt_text de CORD inclut la structure d'annotation et les différences de normalisation VLM, donc le CER brut sur CORD est systématiquement gonflé pour chaque moteur (par exemple, le CER PaddleOCR-VL de 1,08 est un artefact, pas une mesure réelle de sa qualité textuelle). Les métriques par champ sont la comparaison équitable ; le CER n'est utilisé ici que pour l'explication Tesseract.
• La latence n'est pas la latence d'extraction en temps réel : llm_median_latency_ms (1,8–2,4 s) couvre l'ensemble de l'appel OCR-texte → extraction de champs LLM, pas la recherche par champ, et n'inclut pas le temps d'OCR lui-même.
• Réglage des regex : Les motifs regex sont un ensemble fixe écrit une fois par jeu de données (schéma SROIE-flat) ; une bibliothèque regex fortement réglée par fournisseur pourrait obtenir de meilleurs scores sur ses propres formats — au prix de la charge de maintenance que le LLM élimine.

Références associées : l'écart entre la précision des champs et celle des caractères · Précision OCR des reçus · benchmarks de précision par type de document

Lectures complémentaires : Comment lire les affirmations de précision OCR