Évaluer une application basée sur un grand modèle de langage (LLM) consiste à la tester de façon systématique, avant et après chaque modification. Le guide détaille comment choisir les méthodes de notation, concevoir un juge LLM fiable, puis évaluer les systèmes RAG et les agents tout au long du cycle de publication.
Lire quelques réponses et les trouver satisfaisantes ne suffit pas. Une modification du prompt, un changement de modèle ou de la recherche documentaire peut casser un comportement sans qu’on s’en aperçoive, et il devient ensuite difficile de déterminer quel changement en est responsable. Évaluer revient à constituer des cas de test, à noter chaque réponse selon des critères écrits, puis à comparer les scores avant et après chaque changement, sur le modèle des tests de non-régression du code classique.
Les réponses d’un LLM varient d’une exécution à l’autre, et la notion de « bonne réponse » dépend du contexte. Un test unitaire vérifie une égalité, alors que « Vous pouvez retourner des chaussures sous 30 jours » et « Les retours sont acceptés pendant un mois après la livraison » sont toutes deux correctes. Le guide distingue l’évaluation, qui mesure une qualité relative selon des critères flous, des tests, qui valident une mise en production par des contrôles binaires, comme un JSON valide ou l’absence d’une formule interdite. Bloquer un déploiement sur un score de fidélité de 0,7 reviendrait, selon l’auteur, à débattre chaque semaine d’un seuil arbitraire.
Trois façons de noter une réponse
Un scoreur reçoit un cas de test, composé d’une entrée, d’une réponse et parfois d’un contexte ou d’une référence, puis renvoie un verdict ou un nombre. Les scoreurs de code appliquent des règles déterministes, pour vérifier le format, la longueur ou la présence de certaines chaînes. Les scoreurs fondés sur une référence comparent la réponse à une réponse connue. Les métriques de chevauchement comme BLEU et ROUGE, par exemple, ne reconnaissent pas une paraphrase correcte. Le juge LLM, enfin, est un modèle chargé d’appliquer une grille de critères à la réponse d’un autre modèle, utile pour le ton, l’ancrage dans les sources ou l’utilité.
Le guide recommande de commencer par le code partout où une règle suffit, car ces scoreurs ne coûtent rien et donnent toujours le même résultat. Trois configurations de juge sont décrites : ponctuelle, où il attribue un label ou une note à une réponse isolée ; par paires, où il choisit la meilleure de deux réponses, méthode courante pour comparer deux prompts ou deux modèles ; et guidée par référence, lorsqu’il dispose d’une réponse de référence.
Rendre le juge fiable
Une grille de critères bien rédigée décide de la qualité du juge. Le guide la décrit en quatre parties : la définition du critère, les données que le juge peut utiliser, la procédure à suivre et un format de sortie strict, de préférence en JSON. Le raisonnement doit précéder le verdict, et la température est fixée à 0 pour réduire le bruit d’échantillonnage, sans le supprimer. Pour les critères sensibles, le guide suggère un nombre impair d’exécutions et de retenir le verdict majoritaire.
La méthode QAG (génération de questions-réponses) demande au juge de répondre à des questions fermées par oui ou par non, le calcul étant ensuite effectué par le code. La fidélité d’une réponse de quatre affirmations dont trois sont étayées vaut ainsi 0,75. Pour les critères subjectifs, la méthode G-Eval calcule une moyenne pondérée par les probabilités des notes possibles, si bien qu’un modèle partagé à 60/40 entre 4 et 5 obtient 4,4. Des biais sont documentés dans des travaux de recherche sur le jugement des sorties de LLM : biais de position, biais de verbosité et biais d’auto-préférence pour les modèles de la même famille. Le guide propose d’inverser l’ordre des réponses, de tester des cas de longueur comparable et d’utiliser un juge issu d’une autre famille de modèles.
La calibration reste l’étape la plus importante. Le guide conseille d’étiqueter soi-même de 30 à 50 réponses, puis de comparer ces étiquettes à celles du juge à l’aide du kappa de Cohen, qui corrige l’accord dû au hasard. Un score de 0 correspond à un accord au niveau du hasard, et 1 à un accord parfait. Au-delà d’environ 0,6, l’accord est généralement jugé substantiel.
RAG, agents et cycle de publication
Un système RAG (génération augmentée par la récupération) combine deux composants qui peuvent échouer séparément : le moteur de recherche, qui retrouve le contexte, et le générateur, qui rédige la réponse. Le guide propose de mesurer la précision du contexte, son rappel, la fidélité de la réponse aux documents récupérés et sa pertinence par rapport à la question. Une fidélité élevée associée à un rappel faible signale par exemple une recherche insuffisante.
Pour les agents, le guide commence par la réalisation de la tâche, puis examine l’exactitude de l’outil choisi, celle de ses arguments et la trajectoire suivie, sans appels redondants ni boucles. Les évaluations hors ligne se font avant mise en production, sur un jeu de 25 à 50 cas versionné, avec des critères de publication fixés à l’avance. Les évaluations en ligne portent sur un échantillon du trafic réel. Chaque échec observé en production peut ensuite devenir un cas de test de référence.
