💬 NLP

Information Extraction from Electricity Invoices with General-Purpose Large Language Models

Cette étude démontre que, pour les modèles de langage de grande taille à usage général extraire des informations de factures d'électricité espagnoles sans fine-tuning, la qualité de l'ingénierie des invites est le facteur déterminant de la performance, les stratégies few-shot surpassant nettement les références zero-shot pour atteindre des scores F1 dépassant 96 %.

Auteurs originaux : Javier Gómez, Javier Sánchez

Publié 2026-04-30

📖 6 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Javier Gómez, Javier Sánchez

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous avez une immense pile de factures d'électricité provenant de différentes entreprises. Certaines sont soignées et ordonnées, d'autres sont désordonnées, et elles ont toutes un aspect légèrement différent. Votre objectif est d'extraire des chiffres et des noms spécifiques (comme « Coût total » ou « Nom du client ») de chacune d'elles et de les insérer dans un tableur bien rangé.

Pendant des années, les ordinateurs ont eu du mal avec cela. Les programmes traditionnels étaient comme des robots rigides : si une facture ressemblait ne serait-ce qu'un tout petit peu à quelque chose de différent de ce sur quoi ils avaient été entraînés, ils se perdaient et échouaient.

Cet article traite de l'apprentissage d'un nouveau type de « robot sur-intelligent » (appelé Modèle de Langage de Grande Taille, ou LLM) à lire ces factures sans avoir besoin d'être réentraîné pour chaque nouveau design. Les chercheurs se sont demandé : Pouvons-nous simplement donner à ces robots intelligents les bonnes instructions, et vont-ils comprendre ?

Voici la décomposition de leurs résultats, en utilisant quelques analogies du quotidien :

1. La « Recette » compte plus que le « Chapeau de Chef »

Les chercheurs ont testé deux « chefs » (modèles d'IA) différents : Gemini 1.5 Pro (un chef massif et complexe) et Mistral-small (un chef plus petit, plus rapide et plus efficace).

Ils ont également essayé de modifier les « paramètres de cuisson » (paramètres techniques comme la température et l'aléatoire). Ils s'attendaient à ce que peut-être le chef plus grand ou les paramètres de cuisson parfaits fassent la plus grande différence.

La Surprise : Cela n'a pas beaucoup importé quel chef ils ont utilisé ou comment ils ont ajusté les paramètres. La différence dans les résultats était minime — comme la différence entre un gâteau qui est parfait à 99 % et un autre qui est parfait à 99,5 %.

Le Vainqueur Réel : Le Prompt (les instructions données à l'IA).
Considérez le prompt comme la recette.

Zero-Shot (Sans Recette) : Dire simplement « Lisez cette facture et donnez-moi les chiffres » est comme demander à un chef de cuisiner sans recette. Les résultats étaient corrects (environ 78 % de précision), mais pas excellents.
Few-Shot (Avec Exemples) : Donner à l'IA quelques exemples de « Voici une facture, et voici les données que je veux » est comme donner au chef un plat échantillon à copier. La précision a bondi à plus de 96 %.

La Leçon : Il ne s'agit pas d'avoir le chef le plus cher ou le four le plus sophistiqué ; il s'agit de rédiger une très bonne recette.

2. La Stratégie du « Copieur » Fonctionne Mieux

Les chercheurs ont essayé différentes façons de donner des exemples :

La Méthode « One-Shot » : Montrer un exemple. Bien, mais pas le meilleur.
La Méthode « Cross-Validation » : C'est le champion. Ils ont montré à l'IA trois types de factures différents (comme une facture sous forme de tableau, une sous forme de liste et une complexe), puis lui ont demandé de lire un quatrième type qu'elle n'avait jamais vu auparavant.
- Résultat : L'IA est devenue un maître copieur. Elle a appris le concept d'une facture d'électricité, pas seulement l'apparence d'une facture spécifique. Elle a atteint 97,6 % de précision avec Gemini et 96,1 % avec Mistral.

3. Le Problème de la « Traduction »

Avant que l'IA puisse lire les factures, les chercheurs ont dû convertir les fichiers PDF en texte (Markdown).

L'Analogie : Imaginez essayer de lire une note manuscrite qui a été photocopiée à travers une fenêtre sale. Si la note est dans un tableau soigné, le texte ressort clair. Si la note est entassée dans une mise en page désordonnée et multi-colonnes, le texte devient confus.
Le Résultat : L'IA n'était aussi bonne que le texte qu'elle recevait. Lorsque la facture avait une mise en page propre, de type tableau, l'IA était presque parfaite. Lorsque la facture avait une conception dense et désordonnée, l'IA peinait car la « traduction » du PDF au texte perdait des indices importants.

4. Le Piège de l'« Hallucination »

Ils ont remarqué une différence de personnalité entre les deux chefs :

Gemini (Le Chef Prudent) : S'il n'était pas sûr d'où se trouvait un chiffre, il disait : « Je ne le vois pas. » Il était très précis mais manquait parfois des éléments.
Mistral (Le Chef Confiant) : S'il n'était pas sûr, il devinait un chiffre de toute façon. Il trouvait presque tout (un « Rappel » élevé), mais il inventait des chiffres qui n'étaient pas là (une « Précision » faible).
L'Enseignement : Si vous devez être sûr à 100 % que le chiffre est réel, vous voulez le chef prudent. Si vous voulez tout trouver et pouvez vérifier les réponses plus tard, le chef confiant convient.

5. Battre les Vieux Robots

L'article compare ces nouveaux chefs d'IA aux anciens « robots » (apprentissage automatique traditionnel).

Le Vieux Robot : Si vous l'entraîniez sur le Type de Facture A, il pouvait lire le Type de Facture A parfaitement (91 % de précision). Mais si vous lui présentiez le Type de Facture B, il s'effondrait (chutant à 67 % de précision). Il avait mémorisé l'apparence du papier, pas le sens.
Le Nouvel IA : Il n'avait pas besoin d'être entraîné sur le Type de Facture B. Parce qu'il comprenait le sens d'une facture d'électricité, il lisait les nouveaux types avec plus de 95 % de précision. Il généralisait la compétence plutôt que de mémoriser le motif.

Résumé

L'article conclut que pour faire lire parfaitement des documents commerciaux à un ordinateur, vous n'avez pas besoin de construire un cerveau personnalisé pour chaque type de document. Au lieu de cela, vous avez juste besoin de rédiger de meilleures instructions et de lui montrer quelques bons exemples.

La « sauce secrète » n'est pas la taille du modèle d'IA ou les paramètres mathématiques complexes ; c'est la qualité du prompt (les instructions) et la façon dont le document est converti en texte pour que l'IA puisse le lire.

1. Énoncé du problème

L'extraction automatisée d'informations structurées à partir de documents commerciaux semi-structurés (par exemple, les factures d'électricité) reste un goulot d'étranglement critique pour la gestion d'entreprise. Les approches traditionnelles rencontrent des limitations significatives :

Systèmes basés sur des règles ou des modèles : Ils échouent face aux variations de mise en page ou aux différents fournisseurs.
Apprentissage automatique (ML) classique : Des méthodes comme les SVM ou les forêts aléatoires nécessitent d'énormes jeux de données annotés manuellement pour chaque nouveau type de document, entraînant des problèmes de scalabilité et un surajustement sévère à des mises en page d'entraînement spécifiques.
Lacune actuelle : Bien que les modèles de langage larges (LLM) offrent un potentiel pour une extraction flexible sans fine-tuning, il manque d'études empiriques rigoureuses quantifiant leurs performances sur des documents commerciaux spécifiques par rapport aux bases de référence classiques. Plus précisément, il est unclear si l'ingénierie des prompts ou le réglage des paramètres d'inférence (par exemple, température, Top-p) est le principal moteur de la qualité de l'extraction.

2. Méthodologie

Jeu de données : IDSEM

L'étude utilise un sous-ensemble de la Base de données des factures du marché espagnol de l'électricité (IDSEM).

Échelle : 75 000 factures PDF générées synthétiquement réparties sur 6 modèles d'entraînement et 9 modèles de test.
Annotation : 107 étiquettes sémantiques (par exemple, nom du client, montant total, tarifs de l'énergie) organisées en 12 catégories.
Défi : Le jeu de données inclut des modèles non vus dans l'ensemble de test pour évaluer la généralisation.
Prétraitement : Les PDF ont été convertis en Markdown pour préserver la structure sémantique (tableaux, en-têtes) en vue de l'entrée des LLM. Un processus d'affinement de la vérité terrain a mappé les 107 étiquettes possibles sur le sous-ensemble spécifique présent dans chaque modèle afin d'éviter de pénaliser les modèles pour des champs manquants.

Modèles évalués

Deux LLM à usage général, architecturalement distincts, ont été testés sans fine-tuning spécifique à la tâche :

Gemini 1.5 Pro : Un modèle de type Mélange d'Experts (MoE) à grande échelle avec une fenêtre de contexte massive.
Mistral-small : Un modèle dense de 24 milliards de paramètres optimisé avec une fenêtre glissante et une attention par requêtes groupées pour l'efficacité.

Cadre expérimental

L'étude a isolé deux variables principales :

Paramètres d'inférence : Une recherche par grille de 19 configurations (Température, Top-K, Top-P) a été effectuée sur Gemini 1.5 Pro pour tester la sensibilité.
Stratégies d'ingénierie des prompts : Six stratégies distinctes ont été comparées sur les deux modèles en utilisant des paramètres déterministes (Température = 0) :
- Zero-shot : Instructions de tâche et schéma uniquement.
- Few-shot_v1 : Un exemple annoté avec des marqueurs d'étiquette explicites.
- Few-shot_v2 : Un exemple non annoté (texte brut).
- Cross-valid_v1 : Trois exemples issus de modèles séquentiels (T1-T3) testés sur T4-T6.
- Cross-valid_v2 : Trois exemples issus de modèles structurellement similaires (T1, T2, T4) testés sur des modèles structurellement différents (T3, T5, T6).
- Itératif : Extraction séquentielle champ par champ.

Métriques d'évaluation

La performance a été mesurée à l'aide de la Précision, du Rappel et du score F1 au niveau des champs, en comparant la sortie JSON du modèle à la vérité terrain après normalisation.

3. Résultats clés

A. Paramètres d'inférence vs Ingénierie des prompts

Sensibilité aux paramètres : La variation du score F1 sur les 19 configurations de paramètres était marginale (0,58 point de pourcentage). La différence entre le décodage déterministe (Temp=0) et l'échantillonnage stochastique était négligeable.
Conclusion : Le réglage des hyperparamètres a un impact négligeable sur la fidélité de l'extraction. Les praticiens peuvent utiliser des paramètres déterministes pour la reproductibilité sans sacrifier la performance.

B. Impact de l'ingénierie des prompts

Base de référence Zero-shot : A obtenu un score F1 d'environ 78 % (Gemini) et 83 % (Mistral).
Amélioration Few-shot : L'introduction d'exemples en contexte a produit des gains massifs (>11 points de pourcentage).
Meilleure performance : La stratégie Cross-valid_v2 (regroupement par similarité visuelle) a obtenu les scores les plus élevés :
- Gemini 1.5 Pro : 97,61 % de score F1.
- Mistral-small : 96,11 % de score F1.
Découverte clé : La qualité du prompt est le levier dominant de la performance, surpassant largement les différences d'architecture du modèle ou le réglage des paramètres.

C. Comparaison des modèles (Gemini vs Mistral)

Gemini 1.5 Pro : A présenté une Précision plus élevée (95,24 % en validation croisée), ce qui signifie qu'il était meilleur pour identifier quand un champ était absent (évitant les hallucinations).
Mistral-small : A présenté un Rappel plus élevé (souvent 100 %), mais une précision plus faible, indiquant une tendance à « halluciner » des valeurs pour des champs non présents dans le document.
Généralisation : Malgré sa taille plus réduite, Mistral a obtenu des résultats à 1-2 % de ceux de Gemini, prouvant que des modèles plus petits et efficaces peuvent être hautement performants avec une ingénierie des prompts appropriée.

D. Comparaison avec le ML classique

Base de référence classique (SVM) : A obtenu 91,86 % sur les modèles vus mais est tombé à 67,20 % sur les modèles non vus (T7), démontrant un surajustement sévère.
Performance des LLM : A maintenu une précision de 95,24 % (Gemini) et 91,50 % (Mistral) sur des modèles non vus structurellement différents.
Conclusion : Les LLM généralisent la tâche d'extraction via la compréhension sémantique, tandis que le ML classique mémorise les motifs de mise en page.

E. Influence structurelle

La structure du modèle de document a été identifiée comme le déterminant principal de la difficulté. Les modèles avec des mises en page tabulaires claires (T1) ont nettement mieux performé que les designs denses et multi-colonnes (T5), qui se sont dégradés lors de la conversion PDF vers Markdown.

4. Contributions clés

Validation empirique de l'ingénierie des prompts : Démonstration que la conception du prompt est le facteur critique pour le traitement de documents par LLM, rendant le réglage extensif des hyperparamètres inutile pour une extraction de haute fidélité.
Capacité de généralisation : Preuve que les LLM à usage général peuvent atteindre des résultats de pointe sur des mises en page de documents non vues sans fine-tuning, surpassant le ML classique d'environ 24 points de pourcentage dans des scénarios de généralisation.
Efficacité architecturale : Démonstration que des modèles denses efficaces (Mistral-small) peuvent rivaliser avec des modèles MoE massifs (Gemini) lorsqu'ils sont associés à des stratégies d'ingénierie des prompts optimales.
Cadre pratique : Établissement d'un pipeline reproductible (PDF $\to$ Markdown $\to$ LLM) qui atteint une extraction quasi parfaite (97,61 % de score F1) pour l'automatisation des entreprises.

5. Signification et implications

Transformation opérationnelle : Cette étude fournit une voie viable pour les entreprises afin d'automatiser le traitement des factures sans le coût élevé et les exigences de données liées à l'entraînement de modèles personnalisés.
Changement stratégique : L'accent de l'automatisation des documents se déplace de la « construction de modèles » (entraînement/fine-tuning) vers l'« orchestration de modèles » (ingénierie des prompts et conception de pipelines).
Limites et travaux futurs : L'étude s'est appuyée sur des données synthétiques et un traitement texte uniquement (Markdown). Les travaux futurs devraient traiter le bruit du monde réel, la perte d'informations visuelles lors de la conversion, et l'intégration de modèles Vision-Language (VLM) pour capturer directement les caractéristiques de mise en page à partir d'images.

En résumé, l'article établit que l'ingénierie des prompts est le principal moteur de succès dans l'extraction de documents par LLM, permettant une automatisation robuste et agnostique aux modèles, qui surpasse significativement les approches d'apprentissage automatique traditionnelles.