Créer un jeu de données d’évaluation et des évaluateurs (version préliminaire)

Important

Agent Optimizer est actuellement en préversion. Cette version préliminaire est fournie sans contrat de niveau de service, et nous la déconseillons pour les charges de travail en production. Certaines fonctionnalités peuvent ne pas être prises en charge ou avoir des fonctionnalités contraintes. Pour plus d’informations, consultez Conditions d'utilisation supplémentaires pour les versions préliminaires de Microsoft Azure.

L’optimiseur d’agent évalue votre agent par rapport à un jeu de données , une collection de tâches, évaluée par les évaluateurs. Vous pouvez générer les deux automatiquement à partir de l’interface CLI ou créer manuellement un jeu de données pour un contrôle total.

Les deux parties sont essentielles à une bonne optimisation : le jeu de données définit ce qu’il faut tester et les évaluateurs définissent comment juger chaque réponse. Les évaluateurs faibles produisent des scores bruyants qui mènent à une optimisation médiocre, donc investir dans des évaluateurs forts autant que des tâches représentatives.

La création de ces éléments est la deuxième étape du processus d’optimisation, après avoir préparé votre agent pour l’optimisation. L’optimiseur les utilise pour évaluer votre référence et classer les candidats.

Prerequisites

Le moyen le plus rapide de créer des ressources d’évaluation est avec azd ai agent eval generate. La commande détecte automatiquement votre agent et génère tout ce dont l’optimiseur a besoin :

azd ai agent eval generate

Par défaut, elle génère :

  • Jeu de données initial de tâches adaptées au domaine de votre agent.
  • Évaluateurs qui évaluent les réponses : un évaluateur intégré (tel que builtin.task_adherence), ainsi qu’un évaluateur fondé sur une grille d’évaluation personnalisé, adapté à votre agent.
  • Un exécutable eval.yaml qui les connecte entre eux.

Pour l’Assistant interactif, les indicateurs non interactifs et les détails sur les artefacts générés, consultez Initialiser les ressources d’évaluation.

Après la génération, azd ai agent optimize détecte automatiquement eval.yaml:

azd ai agent optimize

Pour personnaliser les ressources générées, consultez Personnaliser les évaluateurs et créer un jeu de données personnalisé. Pour modifier les options d’exécution, modifiez eval.yaml; consultez Configurer l’exécution d’optimisation.

Personnaliser les évaluateurs (avancés)

Les évaluateurs scorent chaque réponse de l’agent. L’optimiseur prend en charge deux types :

  • Évaluateurs intégrés, tels que builtin.task_adherence, qui évaluent chaque critère au niveau de la tâche en tant que réussite ou échec.
  • Évaluateurs de rubrique personnalisés, qui scorent les réponses sur plusieurs dimensions de qualité paramétrées à votre agent. azd ai agent eval generate crée automatiquement un fichier modifiable rubric_dimensions.json .

Pour la plupart des agents, l’évaluateur de rubrique généré donne les scores les plus significatifs, car il est adapté à votre domaine. Modifiez le rubric_dimensions.json généré pour en affiner les dimensions, puis exécutez azd ai agent eval update pour enregistrer les modifications comme nouvelle version. Pour plus d’informations sur la génération, la modification et le contrôle de version des évaluateurs, consultez Initialiser les ressources d’évaluation.

Pour connecter des évaluateurs à votre configuration d’exécution, consultez Configurer l’exécution d’optimisation.

Créer un jeu de données personnalisé (avancé)

Créez un jeu de données personnalisé lorsque vous avez besoin d’un contrôle précis sur les scénarios de test ou que les données de production doivent être utilisées directement. L’approche recommandée consiste à effectuer une itération au-dessus du jeu de données de départ qui azd ai agent eval generate produit : l’affiner dans un jeu de données local ou pointer vers un autre jeu de données déjà inscrit dans votre projet Foundry.

Choisir une source de jeu de données

Un jeu de données peut provenir de l’une des deux sources suivantes :

  • Jeu de données Foundry : jeu de données déjà inscrit dans votre projet Foundry. Faites-y référence dans eval.yaml avec name et version.
  • Jeu de données local : fichier JSONL que vous créez et conservez dans votre projet. Faites-y référence dans eval.yaml par local_uri.

Les deux sources utilisent le même schéma de tâche décrit dans la section suivante. Pour le eval.yaml câblage, consultez Configurer l’exécution de l’optimisation.

Schéma du jeu de données

Un jeu de données utilise le format JSONL (lignes JSON). Chaque ligne est un objet JSON qui représente une tâche d’évaluation unique , un scénario individuel. Une tâche comporte une invite (query) et, éventuellement, des criteria au niveau de la tâche.

{"name": "task_1", "query": "Your prompt here"}
{"name": "task_2", "query": "Another prompt", "ground_truth": "Expected answer"}
Champ Obligatoire Description
name Oui Identificateur de tâche unique (par exemple, "greeting", "math_test").
query Oui Message envoyé à l’agent.
ground_truth Non Réponse attendue, utilisée par les évaluateurs qui prennent en charge une référence.
criteria Non Vérifications facultatives au niveau des tâches. Consultez Ajouter des critères au niveau des tâches.

Lorsque vous utilisez un jeu de données local, validez la syntaxe JSONL avant d’exécuter l’optimisation :

python -c "import json; [json.loads(l) for l in open('eval.jsonl')]"

Ajouter des critères au niveau des tâches

Les critères sont facultatifs. Les évaluateurs que vous configurez s’appliquent eval.yaml à chaque tâche du jeu de données. Ajoutez criteria pour chaque tâche uniquement lorsqu’une tâche spécifique nécessite des vérifications au-delà de celles effectuées par les évaluateurs partagés. Lorsque des criteria sont présents pour une tâche, ils sont notés et agrégés avec les évaluateurs partagés afin de produire le score global de la tâche.

Champ Obligatoire Description
criteria[].name Oui Nom court pour le critère (par exemple, "is_polite").
criteria[].instruction Oui Ce que l’évaluateur vérifie. Être spécifique et testable.

Le jeu de données de support client suivant présente les tâches avec des critères au niveau des tâches :

{"name": "refund_policy", "query": "What is your refund policy?", "criteria": [{"name": "mentions_30_days", "instruction": "Response must mention the 30-day refund window"}, {"name": "polite_tone", "instruction": "Response must be professional and empathetic"}]}
{"name": "order_status", "query": "Where is my order #12345?", "criteria": [{"name": "asks_for_details", "instruction": "Agent should ask for email or order details to look up the order"}, {"name": "no_hallucination", "instruction": "Agent must NOT make up a fake order status"}]}
{"name": "out_of_scope", "query": "Can you help me fix my car?", "criteria": [{"name": "polite_decline", "instruction": "Agent should politely explain this is outside its scope"}, {"name": "redirect", "instruction": "Agent should suggest contacting an appropriate service"}]}

Conseils pour l’écriture de jeux de données appropriés

Inclure les cas limites

Ne vous limitez pas au scénario idéal. Incluez ce qui suit :

  • Demandes hors portée : entrées que votre agent doit refuser ou rediriger
  • Requêtes ambiguës : tâches où l’agent doit demander des clarifications
  • Entrées adversariales — Tentatives de pousser l’agent à adopter un mauvais comportement
  • Tâches en plusieurs étapes : requêtes complexes nécessitant un raisonnement structuré

Recommandations en matière de taille

Taille du jeu de données Compromis
3 à 5 tâches Itération rapide, signal limité
5 à 10 tâches Bon équilibre de vitesse et de couverture
10 à 20 tâches Évaluation complète, exécutions plus longues
20+ tâches Exhaustif mais lent — à envisager pour la validation finale

Les jeux de données plus volumineux offrent une couverture plus large, mais prennent plus de temps à évaluer.

Fournir la vérité de base lorsqu’elle est utile

Le ground_truth champ donne aux évaluateurs une réponse de référence à comparer. Ce n’est pas obligatoire : les évaluateurs peuvent également juger les réponses uniquement à partir de leurs instructions et de tout critère propre à la tâche.

{"name": "geography_fact", "query": "What is the largest city in France by population?", "ground_truth": "Paris", "criteria": [{"name": "correct_answer", "instruction": "Response must state that Paris is the largest city in France by population"}]}

Rédigez des requêtes comme de vrais utilisateurs

Utilisez les messages réels de vos utilisateurs si possible. Les prompts réels capturent le vocabulaire et le contexte auxquels votre agent est confronté en production, ce qui vous aide également à rédiger des critères réalistes à l’échelle des tâches.

Être spécifique dans les critères

Les critères vagues entraînent une notation incohérente. Rendre chaque critère spécifique et testable.

Mauvais:

{"name": "good_answer", "instruction": "The response should be good"}

Bon:

{"name": "mentions_30_days", "instruction": "Response must explicitly mention the 30-day refund window"}

Résolution des problèmes

Problème Cause Réparer
dataset not found Chemin incorrect dans eval.yaml Pour dataset.local_uri, utilisez un chemin d’accès relatif à l’emplacement du fichier config. Pour un jeu de données Foundry, vérifiez dataset.name et dataset.version.
invalid JSON on line N JSONL mal formé Vérifiez que chaque ligne est json valide. Vérifiez la présence de virgules finales.
Les scores sont incohérents entre les exécutions Critères vagues Définissez des critères spécifiques et testables.