Un eval (abréviation d'évaluation) est un test structuré qui mesure si un modèle de langage ou un système d'IA produit le bon résultat pour une entrée donnée. Les evals vont de simples vérifications automatisées à des évaluations notées par des humains, et constituent le principal moyen pour les équipes de savoir si un modèle se comporte comme prévu.
Pourquoi les evals existent
Les modèles de langage ne tombent pas en panne de la même façon que les logiciels déterministes. Une fonction qui renvoie un entier incorrect est clairement défaillante. Un modèle qui renvoie une réponse plausible mais subtilement incorrecte est plus difficile à détecter. Les evals fournissent une méthode reproductible pour faire remonter ces défaillances avant qu'elles n'atteignent la production.
Sans evals, les seuls signaux disponibles sont les réclamations des utilisateurs ou l'inspection manuelle, deux approches qui ne passent pas à l'échelle.
Ce que contient un eval
La plupart des evals partagent la même structure :
- Entrée : une invite, un document, une requête ou un tour de conversation
- Résultat attendu : la bonne réponse, une réponse de référence ou un critère d'évaluation décrivant ce à quoi un bon résultat ressemble
- Méthode de notation : correspondance exacte, similarité sémantique, un second modèle agissant comme juge, ou révision humaine
L'ensemble des entrées utilisées dans un eval est appelé jeu de données d'eval ou benchmark. Un jeu de données d'eval bien maintenu s'enrichit au fil du temps, notamment lorsque les défaillances réelles y sont réintégrées après leur découverte.
Types d'eval
Les evals automatisés comparent la sortie du modèle à une référence fixe. Ils sont rapides et peu coûteux. Ils fonctionnent bien lorsque la bonne réponse est sans ambiguïté : récupération factuelle, extraction structurée, classification.
Les evals notés par un modèle utilisent un second modèle de langage pour noter la sortie du premier. Ils gèrent les tâches ouvertes pour lesquelles la correspondance exacte n'est pas pratique. L'inconvénient est que le modèle de notation peut lui-même être dans l'erreur, aussi sa fiabilité doit-elle être établie séparément.
Les evals humains impliquent des personnes qui évaluent ou comparent les résultats. Ils constituent le signal le plus fiable, mais aussi le plus coûteux à mettre en œuvre. Les evals humains sont généralement utilisés pour calibrer les evals automatisés ou pour évaluer des tâches pour lesquelles aucun indicateur automatisé n'est suffisamment fiable.
Les evals dans un système RAG ou agentique
Dans un pipeline RAG, les evals se décomposent souvent en deux questions distinctes : l'étape de récupération a-t-elle renvoyé un contexte pertinent, et le modèle a-t-il utilisé ce contexte correctement ? Les confondre rend le diagnostic des défaillances difficile.
Dans les systèmes agentiques, les evals deviennent plus complexes car le système effectue une séquence d'actions plutôt que de produire une réponse unique. L'eval doit tenir compte des étapes intermédiaires, et pas seulement du résultat final.
Ce qui rend un eval utile
Un eval n'est utile qu'en fonction de son jeu de données et de sa méthode de notation. Modes d'échec courants :
- Fuite du jeu de données : le modèle a été exposé aux entrées de l'eval lors de l'entraînement, ce qui fausse les scores à la hausse
- Effondrement du proxy : la métrique mesurée s'éloigne de ce qui compte réellement
- Lacunes de couverture : l'eval teste des conditions restreintes et manque les cas qui échouent en production
- Absence de suivi des régressions : les scores sont vérifiés une fois mais ne sont pas suivis entre les versions du modèle ou les modifications de prompt
Les équipes qui accordent une importance sérieuse aux evals traitent la suite d'evals comme un artefact d'ingénierie pérenne, et non comme une vérification ponctuelle.
Evals et modifications de prompt
Chaque fois qu'un prompt est modifié, le comportement du modèle peut changer. Les evals servent de suite de régression pour le prompt engineering, de la même manière que les tests unitaires servent de suite de régression pour le code. C'est l'une des raisons pour lesquelles le prompt engineering est moins empirique qu'on ne le présente parfois : cette discipline ne devient gérable que lorsque des evals permettent de vérifier qu'une modification a globalement amélioré les choses sans rien casser silencieusement.
Ce que nous évaluons
Pour les candidats au poste d'ingénieur IA, la conception d'évaluations est l'un des deux domaines supplémentaires que nous évaluons au-delà des sessions de sélection standard. Dans l'évaluation AI-native, nous cherchons à savoir si un candidat est capable de construire une évaluation valide pour une tâche réaliste, de choisir une méthode de notation adaptée au type de sortie, et d'expliquer dans quels cas l'évaluation pourrait induire en erreur. Ce point est étroitement lié à la capacité à reconnaître quand un modèle est tout simplement le mauvais outil. Le détail complet sur la structure et la notation des deux sessions est disponible sur how we vet.
Réponses courtes
Quelle est la différence entre un eval et un benchmark ?
Un benchmark est un jeu de données d'eval publié et standardisé, utilisé pour comparer les modèles de manière générale. Un eval est le terme générique, qui inclut les suites de tests privées et spécifiques à une tâche, construites par une équipe pour son propre système. La plupart des équipes en production s'appuient sur des evals internes plutôt que sur des benchmarks publics.
Combien d'exemples faut-il dans un jeu de données d'eval ?
Les estimations varient considérablement. Il en faut suffisamment pour couvrir les principaux types d'entrées et les cas limites, sans être si réduit qu'un seul outlier fausse les résultats. Des centaines d'exemples constituent un point de départ raisonnable pour une tâche ciblée ; les systèmes plus larges en nécessitent davantage. La qualité et la couverture importent plus que le nombre brut.
Peut-on utiliser un modèle de langage pour évaluer la sortie d'un autre modèle de langage ?
Oui, et c'est une pratique courante pour les tâches ouvertes. Le modèle de notation doit d'abord être validé par rapport au jugement humain, et ses propres biais, tels que la préférence pour des réponses plus longues ou plus assurées, doivent être bien compris avant de faire confiance à ses scores.
