LLM-as-a-Judge : l'IA révolutionne l'évaluation des factures

L'importance de l'évaluation dans les systèmes d'IA

Dans le cadre de notre exploration continue des systèmes d'IA agentique, nous avons déjà abordé divers aspects tels que le raisonnement, l'utilisation d'outils, et la gestion de flux de travail complexes. Cependant, à mesure que ces systèmes gagnent en autonomie et en capacité, une question cruciale émerge : comment s'assurer que l'IA fonctionne correctement ?

Que l'on parle d'un modèle unique, d'un pipeline d'IA ou d'un système multi-agents, il est essentiel de mesurer les résultats par rapport à une norme objective. En effet, la capacité d'un système sans une évaluation adéquate reste incomplète.

Imaginez que vous ayez mis en place un pipeline d'IA pour lire les factures de vos fournisseurs et en extraire trois informations clés : l'ID de facture, le Montant total, et le Nom du fournisseur. Une fois l'extraction effectuée, ces données sont enregistrées dans votre base de données. Mais comment être certain que ces informations sont exactes ?

La vérification manuelle de milliers de documents n'est pas viable à grande échelle. De même, une validation basée sur des règles peut s'avérer fragile, et les simples comparaisons de chaînes échouent souvent face aux variations de format.

LLM-as-a-Judge : une solution innovante

C'est ici qu'intervient le concept de LLM-as-a-Judge. Plutôt que de s'appuyer sur une logique de validation fragile ou de procéder à des audits manuels, un modèle de langage peut être utilisé pour évaluer les résultats. Ce modèle compare les données extraites par le pipeline d'IA avec une vérité de référence, c'est-à-dire des valeurs vérifiées par des humains, et produit une évaluation structurée comprenant :

• Un score de précision
• Une classification de correspondance
• Une explication concise de la décision

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

Le concept de LLM-as-a-Judge repose sur l'utilisation d'un grand modèle de langage pour évaluer, et non réaliser, la tâche principale. Cette approche est devenue populaire dans les systèmes d'IA en production pour plusieurs raisons :

• Évolutivité : elle permet d'évaluer des milliers d'enregistrements sans nécessiter l'intervention d'un examinateur humain pour chacun.
• Flexibilité : elle gère les correspondances floues, les différences de format et les réponses partielles, là où une simple comparaison de chaînes échouerait.
• Auditabilité : elle fournit un score et une explication lisible par un humain pour chaque décision.

Sans une vérité de référence, LLM-as-a-Judge ne peut vérifier que la plausibilité des données extraites. Cependant, avec des valeurs de référence connues, il devient un véritable outil de mesure de précision.

Dans cet article, nous allons détailler une mise en œuvre complète de ce concept, de la création des tables d'évaluation à l'analyse des résultats, en passant par la génération de données synthétiques et la construction de la fonction LLM-as-a-Judge dans Snowflake Cortex.

Mise en œuvre étape par étape

Configuration initiale

Pour commencer, nous allons créer une base de données et un schéma dédiés à ce tutoriel.

Étape 1 : Création des tables

Trois tables sont nécessaires. La table des extractions contient les données extraites par votre pipeline d'IA. La table de vérité de référence contient les réponses correctes, vérifiées par des humains. Enfin, la table des résultats est celle où le juge inscrit ses scores.

• Table des extractions : elle représente la sortie de votre pipeline d'extraction de factures existant. Pour ce tutoriel, elle sera remplie de données synthétiques avec un mélange d'extractions correctes, partiellement correctes et incorrectes.

• Table de vérité de référence : elle contient les valeurs correctes connues. Dans un projet réel, une équipe de réviseurs annoterait un échantillon représentatif, même 50 à 100 factures vérifiées suffisent pour une référence significative.

• Table des résultats d'évaluation : le juge y inscrit une ligne par champ par facture, capturant 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 : Insertion de données synthétiques

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é de résultats d'extraction. Cela permet de visualiser l'ensemble des scores du juge en une seule exécution. Pour simplifier, supposons que nous avons déjà traité les factures et stocké les données dans un format structuré.

Étape 3 : Insertion des extractions

Nous insérons ensuite les valeurs extraites par l'IA. 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 est déjà 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éation de 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écution de 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é.

Un cadre d'évaluation en boucle fermée

Le résultat de cette mise en œuvre est un cadre d'évaluation en boucle fermée où les sorties d'IA sont continuellement mesurées, surveillées et améliorées. Ce processus est essentiel à mesure que les systèmes d'IA agentique s'intègrent de plus en plus dans les flux de travail d'entreprise, garantissant ainsi une amélioration constante et une fiabilité accrue des données traitées par l'IA.