Évaluateurs de rubriques (préversion)

Un évaluateur de rubrique note une réponse d’agent ou de modèle par rapport aux critères personnalisés que vous définissez, en utilisant un LLM comme juge. Il vous donne un contrôle total sur ce que signifie « bon » pour votre cas d’usage tout en appliquant ce jugement de manière cohérente à grande échelle.

Une rubrique est un ensemble de critères qui définit comment évaluer la réponse. Chaque rubrique contient des dimensions de scoring ; chaque dimension a une description de ce qu’elle mesure et d’un poids qui reflète son importance relative. Le juge LLM note chaque dimension applicable de 1 à 5 sur une seule réponse ou une conversation à plusieurs tour. Le score de la rubrique globale est la moyenne pondérée de ces scores, normalisée à une plage de 0 à 1.

Utilisez les évaluateurs de rubrique comme mesure principale de la qualité de l’agent, car ils vous permettent d’exprimer les critères exacts qui importent pour votre cas d’usage. Associez-les à des évaluateurs intégrés en matière de sécurité, de sol et de contenu pour couvrir les risques que la rubrique ne mesure pas. Le reste de cet article décrit comment générer une rubrique, les champs qu’il contient, comment choisir un modèle de juge LLM et comment examiner les résultats.

Générer un évaluateur de rubrique

Vous pouvez créer un évaluateur de rubrique de deux façons :

Générer automatiquement une rubrique (recommandée)

Vous pouvez créer automatiquement un évaluateur de rubrique en sélectionnant un modèle LLM pour générer la rubrique à partir du contexte de votre agent. Fournissez au moins l’une des entrées de base suivantes :

• Agent Foundry : sélectionnez un agent Foundry existant. Le service extrait les instructions de l’agent (pour les agents d’invite) ou sa description (pour les agents hébergés) à utiliser comme contexte de génération.
• Invite système de l’agent : collez les instructions qui définissent le comportement prévu de votre agent. Utilisez cette option lorsque l’agent n’est pas inscrit dans Foundry ou lorsque son contexte inscrit ne capture pas entièrement son comportement.
• Fichiers de référence : documents, contenu de base de connaissances ou instructions de domaine qui décrivent le contexte de votre agent et la qualité de réponse attendue.

Pour obtenir de meilleurs résultats, ajoutez des traces de production de l’agent au-dessus de n’importe quelle entrée de base au-dessus de la base pour baser la rubrique sur l’utilisation réelle :

• Traces : traces de production de l’agent collectées à partir du suivi Foundry dans Application Insights. Les traces ne peuvent pas être utilisées seules ; associez-les à un agent Foundry, à une invite système d’agent ou à des fichiers de référence.

Chaque rubrique générée contient les champs suivants :

Choisir un modèle de juge LLM

Tous les modèles ne fonctionnent pas de la même façon que les juges de la rubrique. Le tableau suivant répertorie les modèles de conversation pris en charge pour la génération et le scoring des rubriques.

Créer manuellement une rubrique

Écrivez votre propre rubrique en définissant les dimensions id, descriptionet weight. Utilisez cette approche lorsque vous disposez déjà d’une rubrique définie ailleurs que vous souhaitez apporter à Foundry.

Examiner et ajuster la rubrique

Après avoir généré ou créé une rubrique, passez en revue les dimensions pour confirmer qu’elles correspondent à vos attentes en matière de qualité de l’agent. Vous pouvez:

• Modifiez , idet description— Affinez weight la langue pour qu’elle soit plus spécifique sur ce qui se qualifie pour chaque niveau de dimension. Les descriptions précises et le poids améliorent la cohérence du scoring.
• Ajouter ou supprimer des dimensions : insérez des dimensions de qualité qui importent pour votre domaine ou supprimez celles qui ne s’appliquent pas.
• Ajuster les seuils : définissez le seuil de passage pour contrôler ce que le score global qualifie de passage. Les valeurs sont comprises entre 0,0 et 1,0, où 1,0 est le score le plus élevé. Augmentez le seuil d’une norme de qualité plus stricte, ou réduisez-le pour être plus permissif.
• Définir toujours applicable : cochez ou désactivez la case Toujours applicable pour un critère. Lorsqu’il est sélectionné, le juge LLM note ce critère pour chaque réponse sans vérifier d’abord la pertinence.

Dans les paramètres avancés de chaque rubrique, vous pouvez également afficher le niveau d’évaluation et la catégorie de cet évaluateur de rubrique.

Itérer sur la rubrique jusqu’à ce qu’il distingue de manière fiable les réponses acceptables et inacceptables de l’agent. Exécutez une petite évaluation sur un exemple de jeu de données pour vérifier que les scores de la rubrique s’alignent sur votre propre jugement avant de l’utiliser à grande échelle.

Exemple de rubrique

L’exemple suivant montre une rubrique d’agent de réservation de restaurant. Chaque critère cible une dimension de qualité spécifique, avec des pondérations reflétant l’importance relative :

[
  {
    "id": "intent_recognition",
    "description": "Correctly identifies the user's reservation intent (book, modify, cancel, inquire) and pursues the appropriate workflow without unnecessary clarification.",
    "weight": 9
  },
  {
    "id": "tool_usage_accuracy",
    "description": "Calls the correct tool with correct parameters. Does not call tools unnecessarily, and does not skip tool calls when they are needed.",
    "weight": 6
  },
  {
    "id": "policy_enforcement",
    "description": "Enforces business rules: dinner service 17:00-22:00, max party size 8, 30-day booking window. Does not create reservations that violate these constraints.",
    "weight": 5
  },
  {
    "id": "information_gathering",
    "description": "Collects all required information (date, time, party size, contact) before attempting to create a reservation. Does not ask for information already provided.",
    "weight": 4
  },
  {
    "id": "communication_clarity",
    "description": "Provides clear, concise responses. Confirms reservation details before finalizing. Uses a professional and helpful tone.",
    "weight": 2
  },
  {
    "id": "general_quality",
    "description": "Other important quality factors not already covered by the listed criteria.",
    "weight": 5,
    "always_applicable": true
  }
]

Dans cette rubrique, intent_recognition a le poids le plus élevé (9) parce que l’identification correcte de ce que l’utilisateur veut est le facteur déterminant le plus de résultats. Le general_quality critère l’utilise always_applicable: true de sorte que le juge la note pour chaque réponse, même si d’autres critères peuvent ne pas s’appliquer.

Utiliser les évaluateurs de rubrique pour exécuter l’évaluation

Les évaluateurs de rubriques fonctionnent bien pour les critères de qualité propres au domaine ou à l’organisation que les évaluateurs à usage général ne peuvent pas capturer. Définissez une rubrique lorsque vous avez besoin d’un scoring qui reflète les normes de qualité spécifiques de votre équipe, par exemple, le ton du support client, la précision médicale ou la conformité légale.

Le juge LLM lit la rubrique, examine les données d’entrée mappées, attribue un score et fournit une raison pour sa décision de notation. Cette approche combine la flexibilité des critères personnalisés avec la cohérence de l’évaluation basée sur LLM.

Pour plus d’informations sur l’exécution d’évaluations et la configuration de sources de données, consultez Exécuter des évaluations à partir du Kit de développement logiciel (SDK).

Pour obtenir un exemple exécutable, consultez sample_rubric_evaluator_generation_basic.py. Pour obtenir d’autres exemples de rubriques (génération de toutes sources, modification itérative, cycle de vie complet et création manuelle), consultez les exemples d’évaluations README.

Exemple de sortie

L’évaluateur de rubrique retourne un score pondéré pour chaque dimension, un score global, une étiquette de réussite/échec et une raison expliquant la décision. Le seuil de passage par défaut est 0,5. Les scores au-dessus ou au-dessus du seuil sont considérés comme passants.

Exemple de passe

Dans cet exemple, un utilisateur demande de réserver une table pour 4 le vendredi à 17 h 30. L’agent identifie correctement l’intention de réservation, appelle l’outil de réservation avec des paramètres valides et confirme la réservation :

{
  "score": 0.9419354839,
  "label": "pass",
  "reason": "The verdict is driven most by intent_recognition (5), tool_usage_accuracy (5), and policy_enforcement (5). The assistant correctly identified the booking intent, called the reservation tool with valid parameters (Friday 7:30 PM, party of 4), and returned a clear confirmation with the reservation details.",
  "threshold": 0.5,
  "passed": true,
  "properties": {
    "dimension_scores": [
      {
        "id": "intent_recognition",
        "score": 5,
        "applicable": true,
        "weight": 9,
        "reason": "The user's request to book a table is correctly identified, and the assistant pursues the booking workflow without unnecessary clarification."
      },
      {
        "id": "tool_usage_accuracy",
        "score": 5,
        "applicable": true,
        "weight": 6,
        "reason": "The reservation tool is called once with the correct date, time, and party size parameters derived from the user's request."
      },
      {
        "id": "policy_enforcement",
        "score": 5,
        "applicable": true,
        "weight": 5,
        "reason": "The reservation falls within dinner service hours, the party size is within the maximum of 8, and the date is within the 30-day booking window."
      },
      {
        "id": "information_gathering",
        "score": 4,
        "applicable": true,
        "weight": 4,
        "reason": "All required information (date, time, party size, contact) is captured from the request without asking for details already provided."
      },
      {
        "id": "communication_clarity",
        "score": 5,
        "applicable": true,
        "weight": 2,
        "reason": "The confirmation is concise and includes the reservation date, time, and party size in a single clear message."
      },
      {
        "id": "general_quality",
        "score": 4,
        "applicable": true,
        "weight": 5,
        "reason": "Overall execution is strong: the assistant handles the booking end to end with no unnecessary turns or recovery steps."
      }
    ]
  }
}

Exemple d’échec

Dans cet exemple, un utilisateur demande de réserver une table pour 12 personnes le samedi. La taille maximale du tiers est 8, mais l’agent continue de réserver de toute façon sans marquer la violation de la stratégie :

{
  "score": 0.3548387097,
  "label": "fail",
  "reason": "The verdict is driven by very low policy_enforcement (1), tool_usage_accuracy (1), and general_quality (1). The user requested a table for 12, which exceeds the maximum party size of 8, but the assistant proceeded to call the reservation tool and confirmed a booking that violates business rules.",
  "threshold": 0.5,
  "passed": false,
  "properties": {
    "dimension_scores": [
      {
        "id": "intent_recognition",
        "score": 3,
        "applicable": true,
        "weight": 9,
        "reason": "The booking intent is identified, but the assistant fails to flag that the requested party size cannot be accommodated under business rules."
      },
      {
        "id": "tool_usage_accuracy",
        "score": 1,
        "applicable": true,
        "weight": 6,
        "reason": "The reservation tool is called with a party size that the business rules prohibit, producing an invalid booking."
      },
      {
        "id": "policy_enforcement",
        "score": 1,
        "applicable": true,
        "weight": 5,
        "reason": "The 8-person maximum party size is not enforced; the assistant should have declined or offered to split the party before attempting to book."
      },
      {
        "id": "information_gathering",
        "score": 2,
        "applicable": true,
        "weight": 4,
        "reason": "The assistant collected the party size and date but did not confirm a specific time, leaving required information incomplete."
      },
      {
        "id": "communication_clarity",
        "score": 2,
        "applicable": true,
        "weight": 2,
        "reason": "The final confirmation message is clear in form, but it asserts a booking that the system shouldn't have allowed, creating a misleading outcome."
      },
      {
        "id": "general_quality",
        "score": 1,
        "applicable": true,
        "weight": 5,
        "reason": "Overall quality is poor: the assistant violates a core business rule without warning the user or recovering, undermining trust in the booking outcome."
      }
    ]
  }
}

Chaque élément de sortie inclut des scores par dimension avec des raisons. Les dimensions marquées "applicable": false sont ignorées et ne contribuent pas au score global. Le score global est une moyenne pondérée de tous les scores de dimension applicables, normalisés à une plage de 0 à 1.

Configurer l’évaluation continue avec les évaluateurs de la rubrique

Une fois que votre évaluateur de rubrique reflète de manière fiable vos normes de qualité, configurez-le pour une évaluation continue et planifiée dans les paramètres Monitor. L’évaluation continue exécute automatiquement la rubrique sur le nouveau trafic de l’agent, ce qui vous permet d’intercepter les régressions de qualité en production, sans déclencher d’exécutions manuelles.

Pour connaître les étapes de configuration, consultez Surveiller les agents dans le tableau de bord.

Contenu connexe

• Exécuter des évaluations à partir du Kit de développement logiciel (SDK)
• Surveiller les agents dans le tableau de bord
• Configurer le suivi
• Évaluateurs personnalisés
• Évaluateurs à usage général
• Exemples du Kit de développement logiciel (SDK) de l’évaluateur de rubrique (Python)