Rôle des données dans les évaluations

  • 5 minutes

La qualité et la nature des données jouent un rôle essentiel dans la détermination de l’efficacité et de la fiabilité des processus d’évaluation. Les données constituent l’épine dorsale pour les tests, la validation et l’affinement des systèmes IA afin que les résultats reflètent ce que les utilisateurs sont susceptibles d’expérimenter en production. Les jeux de données de haute qualité, diversifiés et représentatifs permettent de s’assurer que les résultats de l’évaluateur reflètent les forces et faiblesses réelles du modèle au lieu des cas les plus simples.

Caractéristiques des données d’évaluation correctes

Les données utilisées pour l’évaluation des applications IA génératives doivent posséder les caractéristiques suivantes :

  • Diversité : de bonnes données d’évaluation englobent un large éventail de scénarios, de contextes et de variantes, ce qui garantit que l’application est testée sur différents types d’entrées.
  • Représentation : les données doivent refléter avec précision les scénarios réels dans lesquels le modèle IA est déployé, en capturant les nuances et les complexités des interactions utilisateur réelles.
  • Qualité : les données de haute qualité sont propres, bien étiquetées et exemptes d’erreurs ou d’incohérences. Les données de haute qualité garantissent que les métriques d'évaluation ne sont pas biaisées par le bruit ou les inexactitudes.
  • Pertinence : les données doivent être alignées sur les objectifs et exigences spécifiques de l’application IA, en se concentrant sur les aspects les plus critiques pour ses performances et son expérience utilisateur.
  • Mise à jour régulière : actualisez régulièrement les données d’évaluation pour refléter les besoins, les stratégies et les scénarios des utilisateurs en constante évolution.
  • Qualité et quantité équilibrée des données : assurez-vous que les données sont de haute qualité et suffisamment volumineuses pour fournir des résultats d’évaluation significatifs et précis.

Faites correspondre le jeu de données non seulement à la tâche utilisateur, mais également aux contraintes de l’évaluateur que vous envisagez d’utiliser. Certains évaluateurs juges documentent les limitations linguistiques, et certains évaluateurs d'agent documentent une prise en charge limitée de certains types d’outils spécifiques. Un jeu de données représentatif n’est utile que si l’évaluateur peut l’interpréter correctement.

Importance de la gestion des cas limites

Les cas de périphérie, bien que rares, peuvent avoir des implications significatives pour les performances et la fiabilité des applications d’IA génératives. En incluant des cas de périphérie dans les données d’évaluation, les développeurs peuvent vérifier que le système est robuste et capable de gérer un large éventail d’entrées. Dans l’IA générative, les cas de périphérie peuvent inclure des entrées qui diffèrent des données généralement observées lors du développement ou des tests précoces. Ces cas révèlent souvent des faiblesses, un comportement dangereux ou des hypothèses inutiles que les scores moyens peuvent masquer.

Considérez une application IA générative conçue pour les chatbots de service client. Un cas de périphérie pour cette application peut impliquer un utilisateur dans la saisie d’un message comprenant un mélange de langues, telles que l’anglais et le mandarin, ainsi que le jargon propre à l’industrie. Par exemple, un utilisateur peut taper « Hey, pouvez-vous帮我reset我的密码 ? Merci ! Cette entrée combine l’anglais, le mandarin et la langue informelle, ce qui pourrait défier les fonctionnalités de traitement linguistique du chatbot. L’évaluation de la réponse du système d’IA à ces entrées peut aider les développeurs à déterminer si le chatbot peut comprendre et répondre avec précision aux requêtes multilingues et informelles, ce qui garantit la robustesse et la fiabilité dans divers scénarios de communication.

Données requises

Les flux de travail d’évaluation ne commencent pas tous à partir du même type d’entrée. Dans le portail, vous pouvez évaluer un agent, un modèle ou un jeu de données. Lorsque vous utilisez un jeu de données dans le portail, le fichier chargé doit être CSV ou JSONL. Dans les flux de travail cloud et SDK, vous pouvez réutiliser un jeu de données chargé par ID ou fournir des évaluations en ligne file_content. Les évaluations du modèle et de la cible de l’agent génèrent alors des réponses à l'exécution à partir de vos requêtes d’entrée.

Les champs d’évaluation courants sont les suivants :

Requête : question ou invite spécifique donnée à l’IA.

Ex : « Qu’est-ce que la capitale/la grande ville de France ? »

Réponse : réponse générée par l’IA à la requête.

Ex : "La capitale/grande ville de France est Paris. C’est une grande ville avec une tour célèbre appelée tour Eiffel.

Contexte : matériau de base utilisé pour produire la réponse, tel que le texte récupéré pour un système RAG.

Ex : « Paris est la capitale/grande ville de France. »

Vérité de base : réponse de référence approuvée créée par une source humaine ou autre approuvée.

Ex : « Paris est la capitale/la ville principale et la ville la plus populeuse de France. »

Appels d’outils : données d’appel d’outils structurées utilisées par les évaluateurs d’agent et certains évaluateurs de sécurité spécifiques à l’agent.

Définitions d’outils : descriptions structurées des outils disponibles pour un agent. Plusieurs évaluateurs d’agents les utilisent pour juger le choix des outils et la qualité des paramètres.

Ce ne sont pas les seuls schémas valides. Document Retrieval utilise retrieval_ground_truth et retrieved_documents. Task Navigation Efficiency utilise actions et expected_actions. Les évaluations de l’agent peuvent également utiliser des formats de tableau de conversation au lieu de chaînes simples afin que les évaluateurs puissent inspecter les messages système, les appels d’outils, les résultats de l’outil et les réponses finales.

Certains évaluateurs n’ont besoin que query et response. D'autres ont besoin de context, ground_truth champs d'étiquette de récupération, tool_calls ou tool_definitions. Ne supposez pas qu’un schéma fonctionne pour chaque exécution. Planifiez le jeu de données autour du jeu d’évaluateurs que vous utilisez et vérifiez le mappage des champs avant de soumettre l’évaluation.

Quel que soit le schéma que vous choisissez, vérifiez que chaque ligne est cohérente en interne et que le mappage de champs correspond aux exigences de l’évaluateur.

Types et sources de données d’évaluation

Il existe plusieurs types et sources de données qui peuvent être utilisés pour évaluer les applications d’IA génératives, chacune offrant des avantages et des défis uniques.

Données réelles

Les données réelles sont générées par l’utilisateur ou des données de type production qui reflètent les interactions et scénarios réels. Il est inestimable pour tester les performances dans des conditions réalistes, car il contient les variations subtiles, l’ambiguïté et la formulation désordonnée que les exemples synthétiques manquent souvent. Lorsque vous utilisez des données réelles, assurez-vous qu’elles sont gérées de manière appropriée pour la confidentialité, la conformité et la sécurité.

Données synthétiques

Les données synthétiques sont des données générées artificiellement conçues pour imiter des scénarios réels. Il est utile lorsque les données de production sont rares, sensibles ou pas encore disponibles. Les données synthétiques peuvent étendre rapidement la couverture, en particulier au début du développement, mais elles doivent compléter plutôt que remplacer des exemples réels représentatifs.

Les conseils actuels du portail Foundry vous permettent de générer un jeu de données synthétique lors de la configuration de l’évaluation lorsque vous n’avez pas encore de données de test. Ce flux de travail du portail actuel nécessite un modèle avec la fonctionnalité d’API Réponses.

Microsoft Learn documente également une Simulator classe dans le Kit de développement logiciel (SDK) Azure AI Evaluation pour les workflows classiques qui génèrent des requêtes et des conversations non contradictoires à partir de texte source ou d’index. Utilisez ces conseils uniquement si vous travaillez intentionnellement sur un projet Foundry classique ou basé sur un hub. L’article classique indique explicitement qu’il ne s’applique pas aux projets Foundry actuels.

Ce guide de simulateur inclut des fonctionnalités telles que :

  • Créer des données synthétiques basées sur du texte ou des index pour l’entrée
  • Définir des rappels cibles à des fins de simulation
  • Personnaliser la façon dont les paires requête-réponse sont générées à partir du texte d’entrée
  • Utiliser des démarrages de conversation fixes pour les simulations

Les données synthétiques sont précieuses pour la couverture, mais elles doivent se compléter plutôt que remplacer des exemples réels représentatifs.

Données contradictoires

Les données contradictoires font référence à des entrées soigneusement conçues pour défier, confondre ou exploiter des systèmes IA. Il est essentiel pour le test de contrainte d’un modèle, car il pousse les limites du système et révèle des points d’échec potentiels. L’évaluation contradictoire est particulièrement importante pour les jailbreaks, l’injection d’invite, l’exposition à du contenu nocif et d’autres risques de sûreté ou de sécurité.

Les recommandations actuelles de Foundry mettent l'accent sur le red teaming de l'IA dans le cloud pour des tests adversaires avant le déploiement. L'agent rouge d'IA peut générer des instructions de type attaque et utiliser des évaluateurs de sûreté pour mesurer si un modèle ou un agent échoue à ces tests à grande échelle. Microsoft Learn documente également un AdversarialSimulator flux de travail classique, mais traite cela comme des conseils hérités ou classiques plutôt que le flux de travail par défaut pour les nouveaux projets Foundry.

Note

Si vous n’avez pas encore de jeu de données de production, utilisez les instructions qui correspondent à votre scénario :