Bonnes pratiques d’évaluation

Les résultats de l’IA générative sont variables. Pour une même entrée, un modèle produit parfois des sorties différentes. Les méthodes classiques de test logiciel ne suffisent donc pas pour les architectures d’IA. Les évaluations (evals) permettent de tester votre système d’IA malgré cette variabilité.

Ce guide présente les grands principes de conception des évaluations. Pour commencer à utiliser l’API Evals, consultez le guide Évaluer les performances d’un modèle.

Qu’est-ce qu’une évaluation ?

Les évaluations sont des tests structurés qui mesurent les performances d’un modèle. Elles aident à garantir l’exactitude des résultats, les performances et la fiabilité des systèmes d’IA malgré leur caractère non déterministe. Elles constituent aussi l’un des rares moyens d’améliorer les performances d’une application fondée sur un LLM (grâce à l’affinage).

Types d’évaluations

Le terme « évaluations » peut renvoyer à plusieurs choses :

• Des tests de référence utilisés dans le secteur pour comparer des modèles pris isolément, comme MMLU et ceux du classement de Hugging Face
• Des scores numériques standard, comme ROUGE et BERTScore, que vous pouvez utiliser pour concevoir des évaluations adaptées à votre cas d’usage
• Des tests spécifiques que vous mettez en place pour mesurer les performances de votre application fondée sur un LLM

Ce guide porte sur le troisième type : la conception de vos propres évaluations.

Interpréter les évaluations

Les scores d’évaluation sont souvent compris entre 0 et 1. Un score ne suffit pas à interpréter une évaluation. Associez les métriques au jugement humain pour vérifier que vous répondez aux bonnes questions.

Concevez votre processus d’évaluation

Un workflow d’évaluation comporte plusieurs étapes importantes :

1. Définissez l’objectif de l’évaluation. Quels sont les critères de réussite ?
2. Constituez le jeu de données. Quelles données vous permettront de vérifier si votre objectif est atteint ? Envisagez des données d’évaluation synthétiques, propres au domaine, achetées ou sélectionnées par des personnes, ainsi que des données de production et des données historiques.
3. Définissez les métriques d’évaluation. Comment vérifierez-vous que les critères de réussite sont remplis ?
4. Exécutez les évaluations et comparez les résultats. Procédez par itérations pour améliorer les performances du modèle sur votre tâche ou dans votre système.
5. Évaluez en continu. Mettez en place une évaluation continue (CE) pour exécuter les tests à chaque modification. Surveillez votre application pour repérer de nouveaux cas de comportement non déterministe et enrichissez progressivement votre jeu d’évaluation.

Voyons quelques exemples.

Exemple : résumer des transcriptions

Pour tester la capacité de votre application fondée sur un LLM à résumer des transcriptions, vous pouvez procéder ainsi :

1. Définissez l’objectif de l’évaluation
   Les résumés du modèle doivent pouvoir rivaliser avec les résumés de référence en matière de pertinence et d’exactitude.
2. Constituez le jeu de données
   Combinez des données de production issues des avis des utilisateurs sur les résumés générés et des jeux de données créés par des spécialistes du domaine (ici, des rédacteurs) pour déterminer ce qui fait un « bon » résumé.
3. Définissez les métriques d’évaluation
   Sur un jeu réservé au test comprenant 1 000 transcriptions associées à leurs résumés de référence, votre implémentation doit obtenir un score ROUGE-L d’au moins 0,40 et un score de cohérence d’au moins 80 % avec G-Eval.
4. Exécutez les évaluations et comparez les résultats
   Utilisez l’API Evals pour créer et exécuter des évaluations dans le tableau de bord OpenAI.
5. Évaluez en continu
   Mettez en place une évaluation continue (CE) pour exécuter les tests à chaque modification. Surveillez votre application pour repérer de nouveaux cas de comportement non déterministe et enrichissez progressivement votre jeu d’évaluation.

Exemple : répondre à des questions à partir de documents

Pour tester la capacité de votre application fondée sur un LLM à répondre à des questions à partir de documents, vous pouvez procéder ainsi :

1. Définissez l’objectif de l’évaluation
   Le modèle doit fournir des réponses précises, retrouver les éléments de contexte nécessaires pour raisonner à partir des prompts des utilisateurs et répondre à leur besoin.
2. Constituez le jeu de données
   Combinez des données de production sur la satisfaction des utilisateurs à l’égard des réponses reçues, des réponses correctes codées en dur à des questions rédigées par des spécialistes du domaine, et des données historiques issues des journaux.
3. Définissez les métriques d’évaluation
   Visez un rappel du contexte d’au moins 0,85, une précision du contexte supérieure à 0,7 et au moins 70 % de réponses évaluées positivement.
4. Exécutez les évaluations et comparez les résultats
   Utilisez l’API Evals pour créer et exécuter des évaluations dans le tableau de bord OpenAI.
5. Évaluez en continu
   Mettez en place une évaluation continue (CE) pour exécuter les tests à chaque modification. Surveillez votre application pour repérer de nouveaux cas de comportement non déterministe et enrichissez progressivement votre jeu d’évaluation.

Déterminez où mettre en place des évaluations

La complexité de votre système augmente à mesure que son architecture s’enrichit. Voici quatre architectures courantes :

• Interactions avec le modèle en un seul échange
• Workflows
• Architectures à agent unique
• Architectures multi-agents

Pour chaque architecture, repérez dans les descriptions ci-dessous où apparaît le non-déterminisme. C’est là que vous aurez intérêt à mettre en place des évaluations.

Interactions avec le modèle en un seul échange

Dans cette architecture, l’utilisateur fournit une entrée au modèle. Le modèle la traite avec les éventuels prompts du développeur pour produire la sortie correspondante.

Exemple

Prenons l’exemple d’une boutique en ligne. Votre prompt système demande au modèle de classer la question du client dans l’une des catégories suivantes :

• order_status
• return_policy
• technical_issue
• cancel_order
• other

Pour offrir une expérience utilisateur cohérente et efficace, le modèle doit renvoyer uniquement l’étiquette correspondant à l’intention de l’utilisateur. Supposons que le client demande : « Où en est ma commande ? »

Architectures de workflow

Pour résoudre des problèmes plus complexes, vous passerez probablement d’un échange unique avec le modèle à un workflow en plusieurs étapes qui enchaîne les appels au modèle. Les workflows n’introduisent pas de nouvelle source de non-déterminisme, mais ils comportent plusieurs interactions avec le modèle que vous pouvez évaluer séparément.

Exemple

Reprenons l’exemple du client qui s’interroge sur l’état de sa commande. Le workflow classe la demande du client et l’oriente vers un traitement en plusieurs étapes :

1. Extraction de l’identifiant de commande
2. Recherche des détails de la commande
3. Transmission de ces détails à un modèle pour qu’il formule la réponse finale

Chaque étape du workflow possède son propre prompt système. Le modèle doit suivre ces prompts pour présenter toutes les données récupérées dans une réponse facile à comprendre.

Architectures à agent unique

Contrairement aux workflows, les agents résolvent des problèmes non structurés qui exigent d’adapter les décisions à la situation. Un agent dispose d’instructions et d’un ensemble d’outils. Il choisit dynamiquement l’outil à utiliser, ce qui introduit une nouvelle source de non-déterminisme.

Exemple

Adaptons notre exemple de service client à une architecture à agent unique. L’agent a accès à trois outils distincts :

• Un outil de recherche de commandes
• Un outil de réinitialisation de mot de passe
• Un outil de consultation de la FAQ sur les produits

Lorsque le client s’interroge sur l’état de sa commande, l’agent décide en fonction de la situation s’il doit appeler un outil ou répondre au client. Par exemple, si le client demande « Où en est ma commande ? », l’agent peut maintenant lui demander son identifiant de commande. L’échange est ainsi plus naturel.

Architectures multi-agents

À mesure que vous ajoutez des outils et des tâches à une architecture à agent unique, le modèle peut avoir du mal à suivre les instructions ou à choisir l’outil à appeler. Les architectures multi-agents permettent de répartir le travail entre plusieurs agents, chacun spécialisé dans un domaine différent. Le classement des demandes et leur transfert entre agents introduisent une nouvelle source de non-déterminisme.

Exemple

Si nous répartissons les tâches de notre agent unique entre plusieurs agents, nous obtenons quatre agents distincts :

1. Agent d’orientation
2. Agent chargé des commandes
3. Agent chargé de la gestion des comptes
4. Agent commercial

Lorsque le client s’interroge sur l’état de sa commande, l’agent d’orientation peut transférer la conversation à l’agent chargé des commandes pour qu’il recherche la commande. Si le client change de sujet et pose une question sur un produit, l’agent chargé des commandes doit renvoyer la demande à l’agent d’orientation. Celui-ci la transmet ensuite à l’agent commercial pour qu’il récupère les informations sur le produit.

Créez et combinez différents types d’évaluateurs

Lorsque vous concevez vos évaluations, vous avez le choix entre plusieurs types d’évaluateurs. Pour choisir, demandez-vous quel rôle vous souhaitez confier à chacun.

Évaluations fondées sur des métriques

Les évaluations quantitatives fournissent un score numérique qui permet de filtrer et de classer les résultats. Ces scores servent de points de référence pour les tests de régression automatisés.

• Exemples : correspondance exacte, comparaison de chaînes de caractères, scores ROUGE ou BLEU, exactitude des appels de fonctions, évaluations exécutables (qui testent une fonctionnalité ou un comportement par exécution, par exemple pour text2sql)
• Limites : ces métriques peuvent être mal adaptées à certains cas d’usage et manquer de nuance

Évaluations humaines

Les évaluations fondées sur le jugement humain offrent la meilleure qualité, mais elles sont lentes et coûteuses.

• Exemples : parcourez les sorties du système pour juger si leur qualité semble s’améliorer ou se dégrader. Organisez un test randomisé en aveugle dans lequel des salariés, des prestataires ou des équipes d’annotation externes jugent la qualité des sorties (par exemple, en classant un petit ensemble de sorties possibles ou en attribuant à chacune une note de 1 à 5)
• Limites : désaccords entre spécialistes, coût élevé, lenteur
• Recommandations :
  • Organisez plusieurs séries d’examens détaillés par des personnes pour affiner la grille de notation
  • Illustrez le barème par des exemples concrets de différents niveaux de qualité (par exemple, des réponses notées 1, 3 et 8 sur 10)
  • Fixez un seuil de réussite en complément du score numérique
  • Pour synthétiser les avis de plusieurs évaluateurs, vous pouvez organiser un vote afin de dégager un consensus

LLM comme juge et modèles de notation

Faire évaluer les sorties par des modèles coûte moins cher que de faire appel à des personnes et permet de traiter de plus grands volumes. Si vous avez besoin d’un LLM performant comme juge, commencez par gpt-6-astra. Vérifiez que ses jugements concordent avec les annotations humaines avant de chercher à réduire les coûts ou la latence.

• Exemples :
  • Comparaison par paires : présentez deux réponses au modèle juge et demandez-lui de déterminer laquelle est la meilleure selon des critères précis
  • Notation d’une réponse individuelle : le modèle juge évalue une réponse isolément et lui attribue un score ou une appréciation selon des critères de qualité prédéfinis
  • Notation à partir d’une référence : fournissez au modèle juge une réponse de référence, ou « réponse étalon », à laquelle il comparera la réponse à évaluer
• Limites : biais de position (influence de l’ordre des réponses) et biais de verbosité (préférence pour les réponses longues)
• Recommandations :
  • Privilégiez la comparaison par paires ou un verdict de réussite ou d’échec pour gagner en fiabilité
  • Si possible, confiez la notation au modèle le plus performant. Commencez par gpt-6-astra, puis vérifiez si un modèle de raisonnement spécialisé donne de meilleurs résultats avec votre grille de notation ou votre jeu de réponses de référence
  • Contrôlez l’effet de la longueur des réponses, car les LLM ont généralement tendance à préférer les réponses longues
  • Demandez au modèle de raisonner et d’expliciter son raisonnement détaillé (« chain-of-thought ») avant d’attribuer une note : cette étape améliore les performances de l’évaluation
  • Passez à plus grande échelle une fois que le LLM juge est plus rapide et moins coûteux que les évaluateurs humains et que ses résultats concordent régulièrement avec leurs annotations
  • Formulez les questions de façon à automatiser la notation tout en préservant la nature de la tâche. Une méthode courante consiste à les reformuler en questions à choix multiples
  • Veillez à ce que les grilles d’évaluation soient claires et détaillées

Aucune stratégie n’est parfaite. La qualité des jugements d’un LLM dépend du contexte du problème, tandis que la production d’annotations de référence par des spécialistes prend du temps et coûte cher.

Prenez en compte les cas limites

Vos évaluations doivent couvrir les principaux scénarios où tout se déroule comme prévu pour chaque architecture. En conditions réelles, les systèmes d’IA rencontrent aussi fréquemment des cas limites qui mettent leurs performances à l’épreuve. Évaluez ces cas pour garantir la fiabilité du système et la qualité de l’expérience utilisateur.

Ces cas limites se répartissent en plusieurs catégories :

Variabilité des entrées

Comme les utilisateurs fournissent eux-mêmes les entrées au modèle, le système doit pouvoir s’adapter à différentes formes d’interaction :

• Des entrées dans une langue autre que l’anglais ou dans plusieurs langues
• Des formats autres que le texte libre (par exemple, XML, JSON, Markdown ou CSV)
• Différentes modalités d’entrée (par exemple, des images)

Vos évaluations du respect des instructions et de l’exactitude fonctionnelle doivent couvrir les entrées que les utilisateurs sont susceptibles d’essayer.

Complexité du contexte

De nombreuses applications fondées sur un LLM échouent parce qu’elles interprètent mal le contexte de la demande. Ce contexte peut provenir de l’utilisateur ou être brouillé par des éléments parasites dans l’historique de la conversation.

Voici quelques exemples :

• Plusieurs questions ou intentions dans une seule demande
• Des fautes de frappe ou d’orthographe
• Des demandes courtes avec très peu de contexte (par exemple, un utilisateur écrit simplement « retours »)
• Un contexte volumineux ou des conversations de longue durée
• Des appels d’outils qui renvoient des données dont les propriétés portent des noms ambigus (par exemple, "on: 123", où « on » représente le numéro de commande)
• Des appels multiples à des outils, qui conduisent parfois à utiliser des arguments incorrects
• Des transferts successifs entre agents, qui conduisent parfois à des boucles

Personnalisation et adaptation aux demandes

L’IA améliore l’expérience utilisateur en s’adaptant aux demandes de chacun, mais cette souplesse introduit de nombreux cas limites. Définissez clairement des évaluations pour les cas d’usage que vous souhaitez prendre en charge et pour ceux que vous souhaitez bloquer :

• Tentatives de jailbreak pour amener le modèle à s’écarter de sa tâche
• Demandes de mise en forme (par exemple, produire du JSON ou utiliser une liste à puces)
• Situations où les prompts des utilisateurs contredisent vos prompts système

Utilisez les évaluations pour améliorer les performances

Lorsque vos évaluations sont suffisamment abouties pour mesurer les performances de façon fiable, exploitez les données recueillies pour améliorer les performances de votre application.

Autres ressources

Pour trouver d’autres idées, consultez l’OpenAI Cookbook, qui propose des exemples de code et des liens vers des ressources tierces, ou explorez nos outils d’évaluation :

• Évaluer les performances d’un modèle
• Comment évaluer une tâche de résumé
• Affinage
• Outils de notation
• Référence de l’API Evals