Évaluations avancées et bonnes pratiques

Notateurs personnalisés avec LLM

Pour un contrôle total, vous pouvez créer vos propres notateurs LLM plutôt que d’utiliser le llm-rubric intégré de Promptfoo :

def evaluate_with_llm(model_output, criteria):
    response = client.messages.create(
        model="claude-sonnet-5",
        max_tokens=500,
        system="Tu es un évaluateur strict. Note la réponse sur 10 selon les critères fournis.",
        messages=[{
            "role": "user",
            "content": f"""Évalue cette reponse selon les critères suivants :

<critères>
{criteria}
</critères>

<reponse>
{model_output}
</reponse>

Donne un score de 0 a 10 et justifie brievement. Format :
Score: X/10
Justification: ..."""
        }]
    )
    return response.content[0].text

Trois décisions de conception se lisent dans cette fonction. Le prompt système fixe la posture du juge : demander explicitement un évaluateur strict évite la complaisance naturelle des modèles, qui tendent à trouver la plupart des réponses acceptables. Les critères et la réponse sont chacun encadrés par une balise, ce qui empêche le contenu évalué de se faire passer pour une instruction.

Le format de sortie imposé, enfin, rend le résultat exploitable : un score sur dix se parse en une ligne et s’agrège sur tout le jeu de test, tandis que la justification éclaire les cas litigieux sans relire la réponse complète. C’est ce que vous gagnez sur llm-rubric — vous décidez de l’échelle, de la posture et du format, donc vous branchez ce notateur sur vos propres tableaux de suivi.

Stratégie d’évaluation complète

Une démarche d’évaluation ne se construit pas d’un bloc. Elle passe par trois phases, et vouloir sauter directement à la dernière est le meilleur moyen de ne jamais commencer.

Phase 1 : évaluations minimales

Commencez avec 10-20 cas de test couvrant les scénarios principaux et des assertions par code simples. L’objectif n’est pas la couverture, il est d’obtenir un chiffre reproductible avant de toucher au prompt. Une équipe qui dispose de quinze cas et d’un score de base travaille déjà mieux qu’une équipe qui planifie depuis trois semaines un jeu de test exhaustif.

Phase 2 : élargissement

Ajoutez des cas limites, des scénarios adversariaux et des cas ambigus. C’est le moment où votre évaluation cesse de flatter votre prompt : les entrées faciles ont toutes réussi en phase 1, et ce sont les autres qui vous apprendront quelque chose. Introduisez la notation par modèle pour les critères subjectifs, en gardant le code partout où il suffit.

Phase 3 : production

La dernière phase installe l’évaluation dans le cycle de vie du produit. Les évaluations automatisées tournent dans le pipeline CI/CD et rendent une régression visible avant qu’elle n’atteigne les utilisateurs. Le monitoring en production suit les métriques de qualité sur les vraies requêtes, celles que vous n’aviez pas imaginées. Des revues humaines périodiques sur un échantillon vérifient enfin que vos notateurs mesurent toujours ce que vous croyez.

Concevoir un bon jeu de test

Quatre exigences déterminent si un jeu de test vous renseigne ou vous berce d’illusions.

La diversité vient en premier : couvrez toutes les catégories, toutes les longueurs d’entrée, tous les niveaux de complexité et les cas limites. Un jeu composé uniquement de messages courts et bien rédigés donnera un excellent score et ne prédira rien du comportement sur le message de quatre paragraphes truffé de fautes que vous recevrez lundi.

Le réalisme suit immédiatement : utilisez des données proches de la production, car les cas artificiels ne révèlent pas les vrais problèmes. Un exemple que vous écrivez pour illustrer une catégorie sera toujours plus propre et plus univoque qu’un message rédigé par un client pressé.

L’évolution est la plus négligée. Mettez à jour le jeu de test régulièrement : les cas de production qui échouent deviennent de nouveaux tests. Ce réflexe garantit qu’une erreur réparée ne réapparaîtra pas six mois plus tard.

Reste la taille, qui conditionne la fiabilité statistique du chiffre que vous lisez.

• Minimum : 50-100 cas pour une couverture de base
• Idéal : 200+ cas pour une confiance statistique
• Par classe : au moins 20-30 exemples par catégorie

En dessous du minimum, un score qui passe de 80 % à 84 % peut n’être qu’un cas de test qui a basculé, autrement dit du bruit que vous prendriez pour un progrès.

Pièges à éviter

Quatre erreurs reviennent assez régulièrement pour mériter d’être nommées. Suroptimiser sur le jeu de test est la plus insidieuse : à force d’ajuster le prompt jusqu’à ce que les cinquante cas passent, on obtient un prompt taillé pour ces cinquante cas qui ne généralise plus. Le symptôme est reconnaissable — un score parfait en évaluation et des plaintes en production.

Ignorer les faux positifs vient ensuite : une réponse peut être notée correcte par le code tout en étant mauvaise. Un notateur contains qui cherche le mot « remboursement » validera une réponse qui le refuse aussi bien qu’une qui l’accorde. L’absence de baseline est le troisième piège, et le plus facile à éviter : mesurez un score de référence avant d’optimiser, sinon vous ne saurez jamais si vos deux heures de reformulation ont servi à quelque chose. Le quatrième tient aux métriques uniques : un seul chiffre cache toujours quelque chose, et plusieurs métriques complémentaires — précision globale, précision par classe, taux de format valide — sont nécessaires pour voir ce qui se passe réellement.

Résumé du cours

Le fil de ces neuf leçons se ramène à cinq gestes. Vous définissez vos critères de succès, c’est-à-dire ce qu’une bonne réponse veut dire pour votre usage précis. Vous construisez un jeu de test représentatif, assez fourni pour que ses chiffres veuillent dire quelque chose. Vous automatisez la notation en combinant code pour l’objectif et LLM pour le subjectif. Vous itérez sur vos prompts en mesurant l’impact de chaque changement plutôt qu’en vous fiant à votre lecture. Vous monitorez enfin en production et enrichissez les tests avec ce que le terrain vous renvoie.

Ces cinq gestes forment une boucle, pas une liste à cocher : un produit qui évolue déplace ses critères de succès, et un jeu de test figé finit toujours par mesurer un problème que vous n’avez plus.

Points clés à retenir

• Un notateur LLM écrit à la main vous rend le contrôle de la posture du juge, de l’échelle et du format de sortie.
• Progressez par phases : 10-20 cas et du code simple d’abord, cas limites et notation par modèle ensuite, CI/CD et monitoring en production.
• Un jeu de test utile est divers, réaliste, régulièrement enrichi et assez volumineux — 50-100 cas au minimum, 200+ pour une vraie confiance.
• Suroptimisation, faux positifs, absence de baseline et métrique unique expliquent la plupart des évaluations trompeuses.
• Les cas de production qui échouent doivent devenir des cas de test : c’est ce qui empêche une régression de revenir.

Testez vos connaissances

Dernier contrôle : le pipeline d’évaluation n’a plus de secret pour vous ?

1. Pourquoi trois exécutions manuelles ne suffisent-elles pas à valider un prompt ?

Réponse : Parce qu’elles n’échantillonnent que vos intuitions : la production apporte des entrées imprévues, et seule une évaluation systématique sur un jeu de données varié mesure la vraie performance.

2. Quand préférer une évaluation notée par code à une notation par modèle ?

Réponse : Quand le critère est vérifiable mécaniquement — format, syntaxe, classe exacte : le code est déterministe, instantané et gratuit ; le modèle juge les qualités subjectives.

3. Comment obtenir des notes discriminantes d'un juge LLM ?

Réponse : En exigeant forces, faiblesses et justification avant la note : un juge qui argumente fonde sa note sur son analyse au lieu de rendre des 6 prudents.

4. Que mesure une évaluation de classification, et avec quelle métrique simple ?

Réponse : La capacité du prompt à assigner la bonne étiquette : on compare la sortie à la référence attendue et on suit le taux d’exactitude sur l’ensemble du jeu.

5. Qu'apporte un outil comme Promptfoo par rapport à un script maison ?

Réponse : L’industrialisation : déclaration des cas en configuration, exécution en lot, comparaison de variantes côte à côte et rapports — le pipeline sans la plomberie.

Avec ces réflexes, chaque modification de prompt devient une expérience mesurée — c’est la fondation de tout le reste de la formation.