Si votre système RAG n'a pas d'eval set, chaque changement de prompt est une release au feeling. La bonne nouvelle : vous pouvez construire un eval set utile en une semaine. Pas un parfait — un utile. Le parfait est le piège qui empêche les équipes d'avoir le moindre eval.
Voici la recette que nous utilisons sur les missions où le client a 0 à 5 evals au premier jour et en a besoin de 200 en fin de semaine.
La forme
Vous voulez trois choses :
- Un corpus figé — les documents réels sur lesquels votre système fait du retrieval, photographiés à un instant donné.
- 200 questions qu'un utilisateur réel pourrait poser, avec leurs réponses de référence et leurs citations.
- Un ensemble réservé — 30 de ces 200, mises sous clé, jamais utilisées pour régler quoi que ce soit.
L'ensemble réservé est le plus important et le plus souvent sauté. Nous y reviendrons.
Jour 1–2 : extraire de vraies questions
Sautez les ateliers « qu'est-ce que les utilisateurs demanderaient ? ». Ils produisent des questions qu'aucun utilisateur n'a jamais réellement posées. Allez à vos sources :
- Tickets de support mentionnant un sujet couvert par le RAG.
- Logs de recherche de votre barre de recherche existante, si vous en avez une.
- Canaux Slack où l'on pose la question en interne.
- Les logs de chat de votre système LLM actuel, si vous en avez un en service.
Visez 250 questions brutes. Dédupliquez, normalisez les formulations, jetez celles qui sont manifestement hors périmètre. Vous atterrirez autour de 200.
Jour 3 : taguer par difficulté et sujet
Mettez chaque question dans un seau :
- Difficulté : triviale (la réponse tient dans un paragraphe), moyenne (la réponse demande de synthétiser 2 à 3 documents), difficile (demande de comprendre une procédure ou une règle).
- Domaine — généralement 5 à 15 seaux, selon votre domaine.
- Drapeau adversarial — questions conçues pour déclencher des modes de défaillance connus (hors périmètre, infos contradictoires, infos récemment mises à jour).
Vous voulez un mélange. Une suite à 90 % de questions triviales vous dira que votre système est génial, et vous déploierez une régression parce que les cas moyens et difficiles auront cassé.
Jour 4 : vérité terrain
Pour chaque question, il vous faut :
- La réponse attendue — rédigée, 1 à 3 phrases, la réponse qu'un expert métier donnerait.
- Les passages justificatifs — des pointeurs (IDs de doc, plages de lignes, IDs de chunk) vers les parties du corpus qui devraient être retrouvées pour répondre.
C'est la partie lente. Comptez ~3 minutes par question = ~10 heures pour 200 questions. Deux personnes en parallèle, une demi-semaine. Utilisez un expert métier.
Ça vaut le coup. C'est cette partie qui transforme « le LLM a dit un truc plausible » en « le LLM a cité la bonne source et a donné la bonne réponse ».
Jour 5 : baselines + métriques
Lancez votre système actuel (ou un stub si vous n'en avez pas) sur les 170 questions visibles. Enregistrez :
- Retrieval@k : les top-k chunks retournés incluaient-ils les passages justificatifs attendus ?
- Justesse de la réponse : notée par un LLM juge contre la réponse attendue, avec la référence réservée. Étalonnez le juge contre ~30 notes humaines pour vous assurer qu'il ne valide pas tout aveuglément.
- Précision des citations : parmi les citations retournées, quelle fraction étaye réellement l'affirmation ?
Vous avez maintenant des baselines. Tout futur changement de prompt ou de retrieval apparaît comme un delta par rapport à elles.
L'ensemble « à ne pas optimiser »
Les 30 questions réservées existent pour une seule raison : se rattraper soi-même.
Toute équipe qui construit un eval set finit par régler le système contre l'eval set. Nouvelle révision de prompt, on lance les evals, le score monte, on livre. Trois mois plus tard, votre score en-suite est à 95 % et la satisfaction utilisateur est inchangée parce que vous faites de l'overfitting.
Les 30 questions réservées ne sont lancées que lors des bilans de santé trimestriels. Si elles régressent pendant que le reste de la suite s'améliore, c'est le détecteur de fumée pour l'overfitting. Elles sont un contrôle sur le contrôle.
Ne les regardez pas. N'en rajoutez pas. Ne les remplacez pas par des équivalents. Mettez-les au coffre.
Ce que ça vous apporte
- Un signal reproductible qui gate les changements de prompt et de retrieval.
- Une baseline comparable lors de l'évaluation de nouvelles versions de LLM.
- Une réponse défendable à « comment savez-vous que votre RAG est bon ? ».
Construisez la v1 en une semaine. Itérez les questions chaque mois. Remplacez l'ensemble réservé une fois par an.
Vous n'aurez jamais le temps de construire l'eval set parfait. Vous avez tout à fait le temps de construire l'utile.