Évaluer un système LLM
On n'améliore pas ce qu'on ne mesure pas : un jeu de cas de test avec des critères explicites, rejoué à chaque changement de prompt ou de modèle, remplace l'impression que « c'est mieux ».
- évaluation
- eval
- jeu de test
- llm-juge
- llm as a judge
- régression
- métrique
Syntaxe
1. Jeu de test : 20 à 100 cas réels, dont les cas difficiles et les refus attendus2. Critères : exact (valeur, format) · règle codée (JSON valide, source citée) · grille humaine3. Notation : script quand c'est possible, LLM-juge avec grille sinon, humain sur un échantillon4. Rejouer à chaque changement de prompt, de modèle ou de données, et comparer au score précédentExemple
Assistant de réponse aux réclamations, 40 cas annotés.Critères : bonne catégorie · cite l'article des CGV concerné · aucun engagement de remboursementPrompt v1 : 31/40Prompt v2 : 36/40, mais 2 réponses promettent un remboursementRésultat attendu : la v2 n'est pas déployée tant que le critère bloquant« aucun engagement » n'est pas à 40/40.À retenir
- Séparez les critères bloquants (sécurité, conformité) des critères de qualité : une moyenne générale masque les régressions graves.
- Un LLM-juge a des biais connus : il favorise les réponses longues, l'option présentée en premier et parfois les textes de sa propre famille. Donnez-lui une grille précise et contrôlez-le sur un échantillon noté par un humain.
- Gardez les cas de test hors des exemples du prompt, sinon le score mesure la mémorisation et non la qualité.
- Pour un agent de code, la version minimale est décrite dans la fiche « Les 5 tâches golden » : des tests binaires rejoués après chaque changement de configuration.
- Piège : évaluer sur trois exemples choisis à la main après avoir vu les réponses. On retient sans le vouloir les cas qui fonctionnent.
Voir aussi
- Les 5 tâches goldenCinq tests binaires rejoués après chaque changement de rules, de hooks ou de modèle : trois tâches que l'agent doit réussir, deux interdits qu'il doit refuser. Le refus compte comme une réussite.
- HallucinationsUn LLM produit le texte le plus plausible, pas le plus vrai : il peut inventer une fonction, une loi ou une source avec aplomb. On s'en protège en fournissant des sources et en vérifiant.
- Sorties structurées (JSON Schema)Quand une réponse doit être lue par du code, on demande au modèle un JSON conforme à un schéma plutôt que du texte libre, puis on le valide côté application avant de s'en servir.
- Température et échantillonnageLe modèle choisit chaque token par tirage parmi les plus probables. La température et le top-p règlent ce hasard : valeur basse pour extraire ou coder, plus haute pour varier les idées.