De l'extraction à l'exactitude : Évaluation des données de factures extraites avec LLM comme juge

De l'extraction à l'exactitude : Évaluation des données de factures extraites avec LLM comme juge

Dans les parties précédentes de cette série sur l'IA agentique, nous avons exploré comment les systèmes d'IA peuvent raisonner, utiliser des outils, récupérer des connaissances et orchestrer des flux de travail complexes. Mais à mesure que les systèmes d'IA deviennent plus capables et autonomes, une question tout aussi importante commence à prendre de l'importance : comment évaluer si l'IA a réellement bien performé ?

Que la tâche soit gérée par un seul modèle, un pipeline d'IA ou un flux de travail multi-agents, le résultat doit toujours être mesuré par rapport à quelque chose d'objectif. En d'autres termes, la capacité sans évaluation est incomplète.

Imaginez que vous ayez construit un pipeline d'IA qui lit les factures des fournisseurs et extrait trois champs clés : ID de facture, Montant total, Nom du fournisseur. L'extraction s'effectue. Les données atterrissent dans votre base de données. Mais maintenant, la question difficile se pose : comment savez-vous si ce qui a été extrait est réellement correct ?

Vérifier manuellement des milliers de documents ne peut pas être à l'échelle. La validation basée sur des règles est fragile. Les simples comparaisons de chaînes échouent lorsque des différences de format apparaissent.

C'est ici qu'intervient LLM-as-a-Judge. Au lieu d'écrire une logique de validation fragile ou d'auditer manuellement les enregistrements, nous pouvons utiliser un modèle de langage pour agir en tant qu'évaluateur. Le modèle compare ce que le pipeline d'IA a extrait par rapport à la vérité de référence (valeurs vérifiées par des humains) et produit une évaluation structurée avec :

• un score de précision
• une classification de correspondance
• une brève explication de la décision

Qu'est-ce que LLM-as-a-Judge ?

LLM-as-a-Judge est un modèle d'évaluation où vous utilisez un grand modèle de langage non pas pour effectuer la tâche principale, mais pour noter la sortie d'un autre modèle (ou pipeline) réalisant la tâche principale.

Il est devenu populaire dans les systèmes d'IA en production car :

• Il évolue : vous pouvez évaluer des milliers d'enregistrements sans qu'un examinateur humain soit nécessaire pour chacun d'eux.

• Il est flexible : il peut gérer des correspondances floues, des différences de format et des réponses partielles qu'une simple comparaison de chaînes considérerait comme incorrectes.

• Il est auditable : vous obtenez un score ET une explication lisible par un humain pour chaque décision.

Sans vérité de référence, LLM-as-a-Judge ne peut vérifier que la plausibilité, c'est-à-dire si la valeur extraite semble raisonnable par rapport au document source. Avec la vérité de référence (valeurs connues comme correctes), cela devient une véritable mesure de précision.

Dans cet article, nous allons passer en revue une mise en œuvre complète de bout en bout : création des tables d'évaluation, génération de données de factures synthétiques avec une qualité d'extraction variée, construction de la fonction LLM-as-a-Judge dans Snowflake Cortex, exécution du pipeline d'évaluation et analyse des résultats.

Le résultat est un cadre d'évaluation en boucle fermée où les sorties d'IA sont continuellement mesurées, surveillées et améliorées. C'est une capacité essentielle à mesure que les systèmes d'IA agentique s'intègrent de plus en plus dans les flux de travail d'entreprise.

Étapes de mise en œuvre

Configuration initiale :

Nous allons commencer par créer une base de données et un schéma dédiés pour ce tutoriel.

Étape 1 — Créer les tables :

Nous avons besoin de trois tables. La table des extractions contient ce que votre pipeline d'IA a extrait de chaque document. La table de vérité de référence contient les réponses correctes, vérifiées par un humain. La table des résultats est celle où le juge écrit ses scores.

• Table des extractions : C'est la sortie de votre pipeline d'extraction de factures existant. Pour ce tutoriel, nous allons la remplir avec des données synthétiques ayant un mélange délibéré d'extractions correctes, partiellement correctes et incorrectes.

• Table de vérité de référence : C'est votre ensemble de données de référence contenant les valeurs connues comme correctes. Dans un projet réel, une petite équipe de réviseurs annotent un échantillon représentatif. Même 50 à 100 factures vérifiées vous donnent une référence significative.

• Table des résultats d'évaluation : Le juge écrira une ligne par champ par facture. Chaque ligne capture la valeur extraite, la vérité de référence, le score (de 0,0 à 1,0), une catégorie de type de correspondance et une explication en langage clair.

Étape 2 : Insérer des données synthétiques pour la vérité de référence :

Plutôt que d'attendre un véritable lot de factures, nous allons créer 10 documents de factures synthétiques avec une variété délibérée de résultats d'extraction. Cela vous permet de voir toute la gamme des scores du juge en une seule exécution. Pour simplifier, supposons que nous avons déjà traité les factures et que nous avons stocké les données dans un format structuré.

Étape 3 : Insérer les extractions :

Insérons maintenant les valeurs extraites par l'IA.

Remarque : Dans un pipeline réel, ces valeurs seraient généralement extraites dans des tables structurées à l'aide de capacités d'IA_EXTRACT. Pour ce tutoriel, nous supposons que l'étape d'extraction a déjà été complétée et que les résultats sont disponibles dans une table structurée. L'accent de cet article est sur l'évaluation LLM-as-a-Judge, et non sur les mécanismes d'extraction.

Étape 4 : Créer la fonction LLM-as-a-Judge :

C'est le cœur du pipeline. Nous créons une fonction UDF (User-Defined Function) dans Snowflake qui appelle le point de terminaison COMPLETE de Snowflake Cortex, effectuant essentiellement un appel API à un LLM hébergé, et lui demande d'évaluer un champ à la fois.

La fonction prend quatre arguments : le nom du champ, la valeur extraite, la valeur de vérité de référence et le texte du document original pour le contexte. Elle retourne un objet JSON avec un score, une étiquette de type de correspondance et une explication en une phrase.

Étape 5 : Exécuter l'évaluation :

Avec la fonction en place, nous joignons les tables d'extractions et de vérité de référence, déplions les trois champs en lignes séparées (afin que chaque champ soit évalué indépendamment), appelons le juge sur chaque ligne et insérons les résultats dans INVOICE_EVAL_RESULTS.

Une note sur la colonne de raisonnement : pourquoi un CTE normalisé au lieu d'utiliser la chaîne de raisonnement ? La décision architecturale clé ici est le CTE normalisé. Plutôt que de passer eval_result:reasoning::STRING à la sortie, nous extrayons uniquement match_type et score du résultat du LLM et normalisons immédiatement match_type en supprimant les guillemets et les espaces intégrés. À partir de ce moment, le texte brut du LLM n'est plus référencé.