C’est la question qui sépare ceux qui ont mis un système en production de ceux qui ont fait des démonstrations. La réponse courte : avec un jeu de tests à soi, versionné, exécuté à chaque changement.
Ils mesurent des capacités générales sur des tâches académiques. Votre problème est de savoir si l’assistant répond correctement aux questions de vos clients sur vos documents. Un modèle premier au classement peut être moins bon que son concurrent sur votre cas précis, et l’inverse aussi.
S’ajoute la contamination : beaucoup de jeux publics ont fui dans les corpus d’entraînement, et les scores annoncés sont partiellement de la mémorisation.
C’est le vrai travail, et il est modeste : cinquante à deux cents cas suffisent pour commencer.
D’où ils viennent : des vraies questions d’utilisateurs si vous en avez déjà, des cas fournis par les experts métier sinon. Il faut inclure délibérément les cas difficiles — questions ambiguës, questions hors périmètre auxquelles il faut refuser de répondre, questions dont la réponse a changé récemment, tentatives de détournement.
Pour chaque cas, on note ce qui rend une réponse acceptable. Pas nécessairement le texte exact : les critères. « Doit mentionner le délai de 30 jours », « ne doit pas donner de conseil fiscal », « doit citer la bonne source ».
Ce qui est vérifiable mécaniquement, d’abord. Le JSON est-il valide ? Le champ existe-t-il ? L’identifiant retourné est-il dans la base ? La citation pointe-t-elle vers un passage réellement fourni ? Ces contrôles sont gratuits, déterministes, et attrapent une grande part des défauts.
Les métriques décomposées, pour un RAG. Séparer le rappel de la récupération — le bon passage est-il remonté — de la justesse de la réponse quand il l’est. Sans cette séparation, un score global qui baisse ne dit pas où chercher.
Le modèle juge, ensuite. Faire noter les réponses par un modèle, avec une grille explicite et des exemples de notation. C’est ce qui permet de passer à l’échelle. Les précautions à connaître : le juge favorise les réponses longues, il favorise les productions de sa propre famille de modèles, il est sensible à l’ordre quand on lui présente deux réponses. On limite ces biais par une grille détaillée, en demandant une justification avant la note, et en inversant l’ordre des comparaisons.
Un lot annoté à la main, pour calibrer le juge. Une trentaine de cas notés par un humain, comparés aux notes du juge. Si l’accord est faible, la grille est mauvaise et tous les chiffres qu’elle produit sont du bruit. Cette étape est celle que presque personne ne mentionne, et c’est celle qui rend l’évaluation automatique crédible.
Le jeu de tests ne couvre pas ce que les utilisateurs inventeront.
Traitez l’évaluation comme une suite de tests, pas comme une étude. Elle tourne à chaque modification d’invite, à chaque changement de modèle, à chaque réindexation, et un score qui baisse bloque le déploiement. Sans cela, chaque ajustement d’invite est un pari, et l’on découvre les régressions par les plaintes.