Évals LLM en pratique : tester les fonctions IA avant les utilisateurs
Le premier échec embarrassant d’une fonction IA ressemble rarement à un échec de benchmark. C’est plutôt un bot support qui applique la mauvaise règle de remboursement, un assistant de code qui modifie un fichier interdit, ou un copilote commercial qui invente une information parce qu’un champ CRM est vide. La démo était propre. Le prompt semblait bon. Puis un utilisateur réel a trouvé le cas que personne n’avait testé.
Les évals LLM servent à cela : pas à courir après les classements, mais à transformer les attentes produit en tests répétables, gates de régression et boucles de revue.
Pourquoi les évals LLM ne sont pas une QA classique
La QA classique vérifie une sortie attendue pour une entrée connue. Avec un LLM, plusieurs réponses peuvent être acceptables. La grille doit suivre le risque produit : cohérence factuelle, complétude, ton, refus, choix d’outil, permissions, récupération et capacité à s’arrêter. Notre article sur la fiabilité des agents IA le formule ainsi : le produit n’est pas seulement la sortie du modèle, mais les contrôles autour.
Construire un golden dataset avant de retoucher le prompt
Un golden dataset rassemble des cas réalistes avec comportement attendu, notes de scoring et métadonnées. Commencez avec 50 à 200 exemples : tâches fréquentes, erreurs coûteuses et cas limites. Pour le support, incluez messages agressifs, langues, informations manquantes et escalades. Pour un outil développeur, incluez petits bugs, refactors ambigus, tests cassés et limites de permission.
Ajoutez type de tâche, niveau de risque, sources requises, actions autorisées et justification du verdict. L’article de Hamel Husain sur les LLM evals est utile car il privilégie les exemples produit et le jugement humain plutôt que les benchmarks abstraits.
Comparer prompts et modèles comme des expériences produit
Faites tourner le même dataset sur le prompt de production, le prompt candidat et le modèle candidat. Analysez par tâche, langue, risque et segment, pas seulement par moyenne. ChainForge aide à comparer prompts et réponses, Vellum propose des workflows de prompts, évals et déploiement, et DeepEval est un framework open source pour tester des applications LLM.
Conservez la version du prompt, le modèle, le retrieval, le schema d’outils, la température et les instructions système. C’est essentiel pour les workflows multi-modèles comme ceux décrits dans notre article sur le développement logiciel avec LLMs.
Ajouter des gates de régression à CI/CD
Placez un petit smoke set dans CI/CD : conseils dangereux, JSON cassé, appels d’outils interdits, hallucinations sévères et escalades obligatoires. Tout changement de prompt, modèle, retrieval, schema ou routing doit exécuter ces évals. Les échecs à haut risque bloquent, les variations plus faibles avertissent.
Commencez par des checks déterministes : schema valide, citations requises, actions interdites, refus et choix d’outil simple. Ajoutez ensuite rubriques ou LLM-as-judge pour le ton, l’utilité et la complétude. Pour les agents, reprenez les patterns de MCP en production et de l’automatisation web façon Operator : logs d’outils, erreurs classées, schemas versionnés et tests des chemins d’échec.
La revue humaine transforme les échecs en meilleurs tests
Un set d’évals vieillit. Revoyez sorties, plaintes, escalades et quasi-incidents. Étiquetez les types d’échec : contexte manquant, mauvais outil, affirmation sans source, mauvais ton, action dangereuse, source obsolète, refus excessif ou refus insuffisant. Les meilleurs exemples rejoignent le golden dataset.
Les PMs et experts métier doivent participer, surtout pour les domaines risqués. Si vous avez un dashboard d’agents, reliez les échecs d’évals à ce flux ; notre funnel d’opérations d’agents donne un cadre pratique.
Quand les évals ouvertes type jeu aident
La plupart des équipes doivent commencer par golden datasets et gates. Les environnements ouverts deviennent utiles quand la fonction demande planification longue, récupération et nombreux appels d’outils. Factorio Learning Environment utilise Factorio pour évaluer des agents qui planifient, collectent, construisent et s’adaptent. C’est excessif pour un FAQ bot, mais pertinent pour des agents navigateur, code ou opérations.
Les bonnes évals ne rendent pas une fonction IA parfaite. Elles rendent les compromis visibles avant les utilisateurs. Les équipes mûres savent quels échecs comptent, détectent les régressions tôt et gardent l’humain dans la boucle quand jugement et responsabilité sont nécessaires.