“Une évaluation, c'est le détecteur de fumée. Agaçant jusqu'à la nuit où il sauve la maison.”
Ce qu'est une évaluation
Une évaluation est un ensemble d'entrées appairées à une façon de juger la sortie, plus un script qui exécute votre système dessus et rapporte un score. C'est tout. La discipline n'est pas compliquée ; elle est juste rarement mise en pratique. La plupart des équipes « évaluent » en essayant quelques prompts à la main et en retenant ce qui semble mieux — c'est ainsi que les régressions sont livrées.
Commencez ridiculement petit. Vingt à cinquante entrées réelles, chacune étant un cas que votre système devrait gérer, avec la réponse attendue ou un moyen de la noter. Ajoutez chaque échec que vous découvrez en production. Cela devient le bien le plus précieux que votre équipe IA possède.
Trois types d'évaluation, classés par levier
- Évaluation de régression — cas réels d'entrée/sortie, exécutés à chaque changement de prompt ou de modèle. Attrape « le correctif qui a cassé dix choses ».
- Évaluation adversariale — entrées conçues pour casser le système : requêtes ambiguës, injection de prompt, contexte non pertinent, cas limites. Exécutez avant chaque livraison.
- Évaluation de calibration — le système sait-il quand il est incertain ? Suivez si les réponses à haute confiance sont réellement plus souvent correctes.
L'évaluation de régression est celle à construire en premier et à exécuter constamment. Les autres comptent, mais une évaluation de régression qui s'exécute à chaque changement est ce qui transforme le développement IA de devinette en ingénierie.
Comment noter les sorties
Trois méthodes de notation, par ordre de préférence. La correspondance exacte ou par règles quand la réponse est structurée (un nombre, une catégorie, du JSON valide) — peu coûteuse, déterministe, digne de confiance. Le LLM comme juge quand la réponse est ouverte (un résumé, une explication) — un modèle note selon une grille d'évaluation. Et la revue humaine pour les cas qui comptent le plus.
Le LLM comme juge est séduisant parce qu'il passe à l'échelle, mais il est bruité et biaisé — les juges favorisent les réponses plus longues, leur propre style, la première option présentée. Ancrez-le avec une grille d'évaluation claire, validez-le contre des notes humaines sur un échantillon, et appairez-le avec la correspondance exacte partout où vous le pouvez. Ne faites jamais confiance à un juge que vous n'avez pas audité.
Observabilité : les évaluations pour la réalité de production
Les évaluations vous renseignent sur les cas auxquels vous avez pensé. L'observabilité vous renseigne sur les cas que les utilisateurs envoient réellement. Tracez chaque requête : le prompt complet, le contexte récupéré, chaque appel d'outil, la sortie brute, la latence et le coût. Quand quelque chose se passe mal — et ça arrivera — vous devez pouvoir rejouer exactement ce qui s'est passé.
La boucle qui fait croître la qualité : les traces de production révèlent de vrais échecs ; les vrais échecs deviennent de nouveaux cas d'évaluation ; le jeu d'évaluation s'affine ; le système s'améliore de façon mesurable. Les équipes qui ferment cette boucle distancent celles qui ne le font pas.
En une ligne chacun
- Une évaluation, c'est des entrées plus une façon de noter les sorties plus un script. Commencez avec 20 cas réels et grandissez à partir des échecs.
- Trois types : régression (toujours en cours), adversarial (avant les livraisons), calibration. Construisez d'abord l'évaluation de régression.
- Notez avec la correspondance exacte quand vous pouvez, le LLM comme juge (audité) quand vous ne pouvez pas, les humains pour ce qui compte le plus.
- L'observabilité ferme la boucle : les traces de production deviennent de nouveaux cas d'évaluation. Ne supprimez jamais les cas qui échouent.
Où aller ensuite