Regex vs LLM pour l'extraction de champs sur 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 bat le regex pour chacun des 8 moteurs — la plus faible amélioration est de 1,76× (PaddleOCR-VL 0,337 → 0,592), la plus forte de 8,1×. Et le LLM réduit presque à néant 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), là où leurs résultats regex étaient étalés sur 0,26 point (0,077–0,338).

SROIE (Scanned Receipt OCR and Information Extraction, ICDAR 2019) est la référence standard pour les 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 un texte OCR sur une configuration RTX 4090 commune ; ce texte a ensuite été envoyé à 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 un prompt d'extraction structurée. Les deux ont été évalués par rapport aux mêmes champs de vérité terrain. Le graphique montre le F1 par champ pour le regex (bleu) vs le F1 par champ pour le LLM (vert) par moteur.

Source : field_method_comparison.csv — lignes pour dataset=sroie_2019, colonnes regex_field_value_f1 / llm_field_value_f1 (stockées sous forme de 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 %). docTR F1 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 stress)

CORD élargit l'écart, non pas parce que le LLM s'améliore — ce n'est pas le cas — mais parce que les regex s'effondrent : six des huit moteurs obtiennent un F1 de champ regex à ou en dessous de 10,8 %, 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 manuscrits ne peuvent pas.

CORD v2 est un jeu de données de reçus en indonésien avec des champs imbriqués (menu, sub_total, total) (Park et al., 2019), exécuté comme un test de stress inter-langues : aucun des 8 moteurs n'a été principalement entraîné sur des reçus indonésiens. Deux mises en garde s'appliquent à la lecture de ce tableau. Premièrement, le texte de référence de CORD inclut des différences de structure d'annotation et de normalisation de sortie VLM, qui gonflent systématiquement le CER brut pour chaque moteur — donc les métriques de champ ci-dessous, et non le CER, sont la comparaison inter-modèles équitable. Deuxièmement, les motifs regex ont été écrits pour le schéma plat anglais SROIE ; le schéma imbriqué de CORD et le formatage indonésien (devise Rp, conventions de date) les déjouent — ce qui est en soi la découverte : les règles ajustées à un marché ne se déplacent 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 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 comble l'écart — et où se situe son plafond

Trois schémas dans les chiffres expliquent ce qui se passe en coulisses. Chacun 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 avait une importance énorme : le F1 des champs SROIE allait de 0,077 (docTR) à 0,338 (Unlimited-OCR) — un écart de 0,26 point. Avec le LLM, six des sept moteurs hors 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 doit simplement produire du texte lisible ; le LLM en extrait les champs avec une qualité à peu près indépendante du moteur. Deux moteurs traînent en deçà de cette bande : EasyOCR à 0,372 (le plus bas F1 LLM sur les reçus anglais) et Tesseract à 0,439. Sur CORD, Tesseract devient le retardataire manifeste — son 0,163 est le pire résultat LLM de l'ensemble du tableau.

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

« Garbage in, garbage out » s'applique même au posttraitement 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 erronés 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 sous-jacent — une contrainte qu'aucun ingénierie 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 était le postprocesseur, pas 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 multi-lignes. Avec le LLM, le même texte produit le meilleur résultat SROIE 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 sous regex, 0,5500 sous le LLM.

Quand le Regex Suffit vs Quand Utiliser un LLM

Le vrai compromis n'est pas « le regex est cassé » mais « le regex est fragile lorsque les reçus sont variables ». Le post-traitement par regex est déterministe, gratuit et instantané ; un post-traitement par 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 retour, le LLM a récupéré 1,76–8,1× plus de champs sur SROIE — et sur CORD, où le regex s'effondrait presque à zéro pour la plupart des moteurs, le LLM a récupéré 33,8–55,3 % des champs que l'extraction basée sur des règles ne pouvait tout simplement pas atteindre.

Quand le 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 numéro de facture fixe, une seule convention de date, une seule devise — le regex est l'outil qu'il faut : il ne coûte rien, s'exécute en microsecondes et ses échecs sont prévisibles. Les cas de base du benchmark le montrent : les moteurs avec un regex adapté aux reçus atteignent encore 0,34 de F1 sur les champs pour SROIE (Unlimited-OCR 0,3376, PaddleOCR-VL 0,3368).

Quand utiliser un LLM : dès que la variance des formats entre en jeu — devises multiples, formats de date régionaux, adresses multi-lignes, noms de fournisseurs dans des styles variés, ou une deuxième langue. Chacun de ces éléments brise un schéma ; le LLM les absorbe tous en un seul prompt. Les résultats sur CORD du benchmark quantifient ce que « une langue de plus » coûte à un pipeline basé sur des règles : le F1 sur les champs du regex est tombé de 0,08–0,34 (anglais SROIE) à 0,00–0,34 (indonésien CORD), tandis que le LLM maintenait 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. L'architecture adaptée à la plupart des flux de production est hybride : extraction par LLM pour les champs variables, validation par regex ou basée sur des règles pour les champs aux formats attendus stricts, avec le coût LLM de 1,8–2,4 s par document amorti par un traitement par lots asynchrone plutôt que par des attentes utilisateur synchrones.

Foire aux questions

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 LLM (deepseek-v4-flash) a surpassé le post-traitement regex pour les 8 moteurs OCR sur les deux jeux de données (field_method_comparison.csv, les 16 lignes). Sur les reçus anglais SROIE, le F1 des champs LLM était de 0,37–0,62 contre 0,08–0,34 pour le 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 LLM ?

docTR sur SROIE, avec un F1 de 0,6171 pour les champs — mais les différences entre les moteurs disparaissent presque toutes une fois qu'un LLM est dans la boucle : six des sept moteurs autres que 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, suivi de près par docTR à 0,5500.

Pourquoi Tesseract est-il en retard 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ère est de 0,9523 (summary_metrics.csv, tesseract/cord_v2), ce qui plafonne son F1 de champs LLM à 0,1627 — le pire résultat LLM du benchmark (field_method_comparison.csv, tesseract/cord_v2, llm_field_value_f1).

De combien un LLM améliore-t-il l'extraction de champs par rapport au regex ?

Entre 1,76× et 8,1× sur les reçus anglais selon le moteur, avec le plus grand gain sur docTR (0,077 → 0,617 F1 des champs, field_method_comparison.csv lignes sroie_2019). Sur les reçus indonésiens, le gain est bien plus important — 36× pour PaddleOCR et pratiquement illimité pour docTR (0,0 → 0,55) car le regex n'avait presque rien récupéré.

Le post-traitement LLM obtient-il chaque champ correctement ?

Non — et les lecteurs ne doivent pas s'y attendre. Le meilleur score F1 pour un champ LLM dans le benchmark est de 0,617 (docTR, SROIE), ce qui signifie qu'environ 38% des champs étaient toujours manquants ou erronés, et le meilleur taux de correspondance exacte pour un 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 expressions régulières, pas une solution miracle ; le scoring de confiance au niveau des champs et la révision 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,33M de tokens d'invite + 0,28M de tokens 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 des reçus non anglais ?

Mieux que les expressions régulières, mais avec un plafond plus bas. Sur les reçus indonésiens CORD, le LLM a maintenu un score F1 pour les champs entre 0,16 et 0,55 là où les expressions régulières sont tombées entre 0,00 et 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 cessé de fonctionner essentiellement ; le LLM s'est dégradé de manière plus gracieuse.

Méthodologie & Sources

Protocole

Cette page présente la comparaison d'extraction de champs du benchmark OCR open-source d'ImageToTable.ai — une expérimentation indépendante et reproductible (niveau officiel), et non une enquête sur des affirmations de tiers. Le pipeline pour chaque paire (modèle × jeu de données) : le moteur OCR produit du texte à partir d'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 référence. Le postprocesseur LLM est deepseek-v4-flash (la colonne llm_model dans le CSV de comparaison), exécuté à température 0 pour une sortie déterministe. Les 361 échantillons SROIE et 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é uniquement en CPU (pas de 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 les exécutions et sont enregistrées exactement dans les manifests 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 — un passage de chauffage fixe précède le passage mesuré, de sorte que les chiffres de latence sont en régime permanent.
• Jeux de données : SROIE 2019 test — 361 reçus en anglais, champs plats (entreprise, date, adresse, total), CC-BY-4.0 ; CORD v2 test — 100 reçus indonésiens, champs imbriqués (menu, sub_total, total), CC-BY-4.0.
• Nombre d'échantillons : SROIE 361 / CORD 100, tous issus des partitions de test fixes (pas de fuite de données d'entraînement).

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

Les empreintes de reproductibilité complètes par exécution se trouvent dans les manifests 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 de l'exécution, le modèle + version, le hash du script d'exécution (SHA-256), le modèle/pilote/VRAM du GPU, les versions torch/CUDA/torchvision/torchaudio, la version Python, le hash du pip-freeze, les métadonnées de coût ($/heure GPU et horodatage du prix), le mode de mesure, et les hashes des artefacts (liste d'échantillons, prédictions, métriques, performances).

Définitions des métriques

• F1 champ-valeur (approche regex) : moyenne harmonique de la précision et du rappel sur les valeurs de champs extraites, utilisant un post-traitement regex — l'approche OCR traditionnelle + KIE basée sur des règles. Colonne : regex_field_value_f1.
• F1 champ-valeur (approche LLM) : la même métrique calculée sur la sortie du post-processeur LLM — l'approche OCR + post-traitement LLM. Colonne : llm_field_value_f1. Ces deux approches sont des pipelines différents et ne sont jamais combinées.
• Précision champ-valeur : fraction des valeurs de champs extraites qui correspondent exactement à la vérité terrain (regex_field_value_accuracy / llm_field_value_accuracy).
• Document-champs-exact : fraction des documents où chaque champ cible a correspondu exactement (regex_document_fields_exact / llm_document_fields_exact).
• CER/WER (contexte uniquement) : taux d'erreur par caractère/mot 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), regex/llm field F1 + accuracy, document-fields-exact, llm_median_latency_ms, llm_prompt_tokens, llm_completion_tokens. Chaque chiffre F1 champ-valeur et 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 0.1971.
3. Dépôt ImageToTableai/benchmark-ocr. Dépôt public hébergeant les CSV de résultats, les manifests d'exécution et les listes d'échantillons de jeux de données pour la reproduction.
4. results/manifests/ (GitHub). Un manifest.json caviardé par exécution publiée (16 exécutions), avec l'empreinte de l'environnement par exécution et les empreintes des artefacts listées 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.

Limitations

• Périmètre du document : Reçus uniquement (SROIE + CORD). Les résultats ne sont pas généralisables 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 différences de quelques centièmes comme du bruit.
• Modèle LLM unique : Toutes les lignes LLM utilisent deepseek-v4-flash. Un autre LLM (taille, prompt ou fournisseur) produirait des chiffres absolus différents ; l'ordre regex-vs-LLM pourrait varier aux marges.
• Avertissement sur la vérité terrain CORD : Le gt_text de CORD inclut des différences de structure d'annotation et de normalisation VLM, donc le CER brut sur CORD est systématiquement gonflé pour chaque moteur (par exemple, le CER de 1.08 pour PaddleOCR-VL est un artefact, pas une vraie mesure de la qualité de son texte). Les métriques par champ sont la comparaison juste ; le CER n'est utilisé ici que pour l'explication de 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'appel complet OCR-texte → extraction de champs par LLM, pas la recherche par champ, et n'inclut pas le temps d'OCR lui-même.
• Paramétrage des regex : Les motifs regex sont un ensemble fixe écrit une fois par jeu de données (schéma SROIE-flat) ; une bibliothèque de regex fortement optimisée par fournisseur pourrait obtenir de meilleurs résultats sur ses propres formats — au prix de la charge de maintenance que le LLM supprime.

Références associées : Précision au niveau champ vs au niveau caractère · Précision OCR des reçus · Précision OCR par type de document

Lectures associées : Comment lire les affirmations de précision OCR