Évaluer un LLM en pratique : des essais au feeling à une suite de tests
La plupart des fonctionnalités LLM partent en production après qu'une personne a essayé une douzaine de prompts et apprécié les réponses. Cela tient jusqu'à la première mise à jour du modèle, modification de prompt ou nouveau corpus qui dégrade discrètement les réponses. L'évaluation transforme « ça avait l'air bien » en un chiffre suivi dans le temps et un test qui échoue en CI. Ce guide décrit un dispositif pragmatique à la portée d'une petite équipe.
Commencer par un jeu de référence
Tout repose sur un ensemble d'exemples réels : les questions que vos utilisateurs posent vraiment, avec ce qu'une bonne réponse doit contenir. Cinquante cas bien choisis valent mieux que mille cas synthétiques.
- Prenez-les dans les logs, les tickets de support et auprès des experts métier.
- Couvrez la majorité facile, les cas difficiles connus et les questions que le système doit refuser.
- Pour chaque cas, écrivez les faits qu'une bonne réponse doit énoncer, pas un texte de référence complet.
- Versionnez le jeu avec le code et enrichissez-le à chaque bug trouvé.
Des outils comme Ragas génèrent des questions de test supplémentaires à partir de vos documents ; servez-vous-en pour élargir la couverture, puis relisez-les à la main.
| Slice | Share | Source |
|---|---|---|
| Common real requests | ≈ 50 % | sampled production logs, anonymised |
| Hard and edge cases | ≈ 20 % | past incidents, long or multilingual inputs |
| Should-decline / out of scope | ≈ 15 % | policy owners; sheet 06 for adversarial ones |
| Regression cases | ≈ 15 % | every bug fixed adds its case, forever |
Extrait de la fiche « Eval Harness Templates » · Demander la fiche complète
Choisir des métriques qui correspondent aux échecs
Les systèmes n'échouent pas de la même façon : mesurez les échecs que vous redoutez.
- RAG : la recherche a-t-elle trouvé les bons passages (précision et rappel du contexte), et la réponse s'y tient-elle (fidélité) ? Ragas calcule ces métriques.
- Assistants et agents : la tâche est-elle accomplie, les bons outils ont-ils été appelés avec les bons arguments, en combien d'étapes ?
- Tous les systèmes : validité du format (un JSON qui se parse, les champs obligatoires présents), refus quand il le faut, latence et coût par réponse.
Préférez les vérifications déterministes (une regex, un schéma, un champ exact) chaque fois que c'est possible. N'utilisez un LLM comme juge que pour ce que le code ne sait pas vérifier, comme la fidélité ou le ton, et validez le juge lui-même sur quelques dizaines de cas annotés par des humains avant de lui faire confiance.
| Grader | Checks | Tools |
|---|---|---|
| Deterministic | valid JSON / schema, regex, contains, length, latency, cost | pytest, promptfoo, DeepEval |
| Reference-based | similarity to a reference answer (embedding, BLEU/ROUGE for short text) | promptfoo similar, Ragas |
| RAG-specific | faithfulness to retrieved context, context precision and recall, answer relevance | Ragas, DeepEval, Phoenix evals |
| LLM-as-judge | rubric scores, pairwise preference between two versions | any eval tool; calibrate on 50-100 human-graded cases |
| Human review | ground truth for the judge, edge cases, launch decisions | annotation queues (Langfuse, LangSmith) |
Extrait de la fiche « LLMOps and Observability » · Demander la fiche complète
L'intégrer à la CI
- promptfoo exécute des fichiers de tests déclaratifs sur plusieurs prompts et modèles côte à côte, et inclut des sondes de red teaming contre l'injection et les fuites de données.
- DeepEval écrit les évaluations comme des tests pytest, avec des métriques LLM-as-judge, pour qu'elles tournent comme le reste de votre suite de tests.
- Ragas se concentre sur les métriques de recherche et de qualité RAG.
Un pipeline utile : les vérifications déterministes à chaque pull request, la suite complète jugée par LLM lors des changements de prompts, de modèles ou de recherche, avec des seuils qui bloquent la fusion quand la qualité baisse.
Extrait de la fiche « Eval Harness Templates » · Demander la fiche complète
Continuer à évaluer en production
Les tests hors ligne attrapent les régressions ; la production montre ce que vous n'aviez pas imaginé. Tracez chaque appel (entrées, contexte récupéré, sortie, coût) avec un outil d'observabilité comme Langfuse, échantillonnez une petite part pour relecture, et réinjectez chaque échec dans le jeu de référence. Suivez quelques chiffres dans le temps : qualité des réponses, taux de refus, coût et latence par requête.
En résumé
Construisez un petit jeu de référence à partir de vraies questions, mesurez les échecs qui comptent avec des vérifications déterministes d'abord et des juges LLM ensuite, exécutez-le en CI et continuez à l'alimenter depuis la production. C'est l'évaluation qui permet de changer de modèle et de prompt sans crainte.