Comment la qualité, les coûts et la latence sont évalués par Agent Evaluation (MLflow 2)
Databricks recommande d’utiliser MLflow 3 pour l’évaluation et le monitoring des applications GenAI. Cette page décrit MLflow 2 Agent Evaluation.
- Pour une introduction à l'évaluation et au monitoring sur MLflow 3, consultez Évaluer et surveiller les agents d'IA.
- Pour en savoir plus sur la migration vers MLflow 3, consultez Migration vers MLflow 3 depuis Agent Evaluation.
- Pour les informations MLflow 3 sur ce sujet, consultez les juges personnalisés.
Cet article explique comment l'Agent Evaluation évalue la qualité, le coût et la latence de votre application d'IA et fournit des insights pour guider vos améliorations de qualité et vos optimisations de coût et de latence. Il couvre les éléments suivants :
- Comment la qualité est évaluée par les juges LLM.
- Comment le coût et la latence sont évalués.
- Comment les métriques sont agrégées au niveau d'une exécution MLflow pour la qualité, le coût et la latence.
Pour plus d'informations sur chacun des juges LLM intégrés, consultez Juges IA intégrés (MLflow 2).
Comment la qualité est évaluée par les juges LLM
Agent Evaluation évalue la qualité en utilisant des juges LLM en deux étapes :
- Les juges LLM évaluent des aspects de qualité spécifiques (tels que l'exactitude et la pertinence factuelle) pour chaque ligne. Pour plus de détails, voir Étape 1 : Les juges LLM évaluent la qualité de chaque ligne.
- Agent Evaluation combine les évaluations des juges individuels en un score global de réussite/échec et la cause première de toute défaillance. Pour plus de détails, consultez Étape 2 : Combiner les évaluations des juges LLM pour identifier la cause première des problèmes de qualité.
Pour les informations sur la confiance et la sécurité des juges LLM, consultez Informations sur les modèles alimentant les juges LLM.
Pour les conversations à plusieurs tours, les juges LLM évaluent uniquement la dernière entrée de la conversation.
Étape 1 : les LLM juges évaluent la qualité de chaque ligne
Pour chaque ligne d'entrée, Agent Evaluation utilise une suite de juges LLM pour évaluer différents aspects de la qualité des sorties de l'agent. Chaque juge produit un score oui ou non et une justification écrite pour ce score, comme illustré dans l'exemple ci-dessous :

Pour plus de détails sur les juges LLM utilisés, consultez les juges d'IA intégrés.
Étape 2 : Combiner les évaluations des juges LLM pour identifier la cause première des problèmes de qualité
Après l’exécution des juges LLM, Agent Evaluation analyse leurs sorties pour évaluer la qualité globale et déterminer un score de qualité réussite/échec basé sur les évaluations collectives du juge. Si la qualité globale n'est pas satisfaisante, l'Agent Evaluation identifie le juge LLM spécifique à l'origine de l'échec et propose des corrections suggérées.
Les données sont affichées dans l'interface utilisateur de MLflow et sont également disponibles à partir de l'exécution MLflow dans un DataFrame retourné par l'appel mlflow.evaluate(...). Consultez le résultat de l'évaluation pour plus de détails sur la manière d'accéder au DataFrame.
La capture d'écran suivante est un exemple d'analyse récapitulative dans l'interface utilisateur :

Cliquez sur une requête pour voir les détails :

Juges IA intégrés
Voir Juges IA intégrés (MLflow 2) pour plus de détails sur les juges IA intégrés fournis par Agent Evaluation.
Voici des exemples, illustrés par les captures d'écran suivantes, de la façon dont ces juges apparaissent dans l'UI :


Comment la cause principale est déterminée
Si tous les juges sont validés, la qualité est considérée pass. Si un juge échoue, la cause première est déterminée comme étant le premier juge à échouer en fonction de la liste ordonnée ci-dessous. Cet ordre est utilisé car les évaluations du juge sont souvent corrélées de manière causale. Par exemple, si context_sufficiency évalue que l’extracteur n’a pas récupéré les bons segments ou documents pour la demande d’entrée, il est alors probable que le générateur ne parviendra pas à synthétiser une bonne réponse et que correctness échouera également.
Si la vérité terrain est fournie en entrée, l'ordre suivant est utilisé :
context_sufficiencygroundednesscorrectnesssafetyguideline_adherence(siguidelinesouglobal_guidelinessont fournis)- Tout juge LLM défini par le client
Si la vérité terrain n'est pas fournie en entrée, l'ordre suivant est utilisé :
chunk_relevance- Y a-t-il au moins 1 segment pertinent ?groundednessrelevant_to_querysafetyguideline_adherence(siguidelinesouglobal_guidelinessont fournis)- Tout juge LLM défini par le client
Comment Databricks maintient et améliore la précision des juges LLM
Databricks s'engage à améliorer la qualité de nos juges LLM. La qualité est évaluée en mesurant dans quelle mesure le juge LLM est d'accord avec les évaluateurs humains, en utilisant les métriques suivantes :
- Augmentation du Kappa de Cohen (une mesure d'accord inter-évaluateurs).
- Précision accrue (pourcentage d'étiquettes prédites qui correspondent à l'étiquette de l'évaluateur humain).
- Score F1 amélioré.
- Taux de faux positifs réduit.
- Taux de faux négatifs diminué.
Pour mesurer ces métriques, Databricks utilise des exemples variés et exigeants provenant de datasets académiques et propriétaires, représentatifs des datasets clients, afin d'évaluer et d'améliorer les juges par rapport aux approches de juges LLM à la pointe de la technologie, garantissant ainsi une amélioration continue et une grande précision.
Pour plus de détails sur la façon dont Databricks mesure et améliore continuellement la qualité des juges, voir Databricks annonce des améliorations significatives aux juges LLM intégrés dans l'Agent Evaluation.
Appeler les juges à l'aide du SDK Python
Le SDK databricks-agents comprend des APIs pour invoquer directement les juges sur les entrées utilisateur. Vous pouvez utiliser ces APIs pour une expérience rapide et facile afin de voir comment les juges fonctionnent.
Exécutez le code suivant pour installer le databricks-agents package et redémarrer le noyau Python :
%pip install databricks-agents==0.16.0 -U
dbutils.library.restartPython()
Vous pouvez ensuite exécuter le code suivant dans votre notebook, et le modifier si nécessaire pour essayer les différents juges sur vos propres entrées.
from databricks.agents.evals import judges
SAMPLE_REQUEST = "What is MLflow?"
SAMPLE_RESPONSE = "MLflow is an open-source platform"
SAMPLE_RETRIEVED_CONTEXT = [
{
"content": "MLflow is an open-source platform, purpose-built to assist machine learning practitioners and teams in handling the complexities of the machine learning process. MLflow focuses on the full lifecycle for machine learning projects, ensuring that each phase is manageable, traceable, and reproducible."
}
]
SAMPLE_EXPECTED_RESPONSE = "MLflow is an open-source platform, purpose-built to assist machine learning practitioners and teams in handling the complexities of the machine learning process. MLflow focuses on the full lifecycle for machine learning projects, ensuring that each phase is manageable, traceable, and reproducible."
# You can also just pass an array of guidelines directly to guidelines, but Databricks recommends naming them with a dictionary.
SAMPLE_GUIDELINES = {
"english": ["The response must be in English", "The retrieved context must be in English"],
"clarity": ["The response must be clear, coherent, and concise"],
}
SAMPLE_GUIDELINES_CONTEXT = {
"retrieved_context": str(SAMPLE_RETRIEVED_CONTEXT)
}
# For chunk_relevance, the required inputs are `request`, `response` and `retrieved_context`.
judges.chunk_relevance(
request=SAMPLE_REQUEST,
response=SAMPLE_RESPONSE,
retrieved_context=SAMPLE_RETRIEVED_CONTEXT,
)
# For context_sufficiency, the required inputs are `request`, `expected_response` and `retrieved_context`.
judges.context_sufficiency(
request=SAMPLE_REQUEST,
expected_response=SAMPLE_EXPECTED_RESPONSE,
retrieved_context=SAMPLE_RETRIEVED_CONTEXT,
)
# For correctness, required inputs are `request`, `response` and `expected_response`.
judges.correctness(
request=SAMPLE_REQUEST,
response=SAMPLE_RESPONSE,
expected_response=SAMPLE_EXPECTED_RESPONSE
)
# For relevance_to_query, the required inputs are `request` and `response`.
judges.relevance_to_query(
request=SAMPLE_REQUEST,
response=SAMPLE_RESPONSE,
)
# For groundedness, the required inputs are `request`, `response` and `retrieved_context`.
judges.groundedness(
request=SAMPLE_REQUEST,
response=SAMPLE_RESPONSE,
retrieved_context=SAMPLE_RETRIEVED_CONTEXT,
)
# For guideline_adherence, the required inputs are `request`, `response` or `guidelines_context`, and `guidelines`.
judges.guideline_adherence(
request=SAMPLE_REQUEST,
response=SAMPLE_RESPONSE,
guidelines=SAMPLE_GUIDELINES,
# `guidelines_context` requires `databricks-agents>=0.20.0`. It can be specified with or in place of the response.
guidelines_context=SAMPLE_GUIDELINES_CONTEXT,
)
# For safety, the required inputs are `request` and `response`.
judges.safety(
request=SAMPLE_REQUEST,
response=SAMPLE_RESPONSE,
)
Comment le coût et la latence sont évalués
Agent Evaluation mesure le nombre de jetons et la latence d'exécution pour vous aider à comprendre les performances de votre agent.
Coût des jetons
Pour évaluer les coûts, Agent Evaluation calcule le nombre total de jetons pour tous les appels de génération LLM dans la trace. Ceci estime le coût total en fonction du nombre de jetons, ce qui entraîne généralement un coût plus élevé. Le nombre de jetons n'est calculé que lorsqu'un trace est disponible. Si l'argument model est inclus dans l'appel à mlflow.evaluate(), une trace est automatiquement générée. Vous pouvez également fournir directement une colonne trace dans le dataset d'évaluation.
Les nombres de jetons suivants sont calculés pour chaque ligne :
Champ de données | Type | Description |
|---|---|---|
|
| Somme de tous les jetons d'entrée et de sortie dans toutes les portées LLM de la trace de l'agent. |
|
| Somme de tous les jetons d'entrée à travers tous les spans de LLM dans la trace de l'agent. |
|
| Somme de tous les jetons de sortie à travers toutes les étendues LLM dans la trace de l'agent. |
Latence d'exécution
Calcule la latence totale de l'application en secondes pour la trace. La latence n’est calculée que lorsqu’une trace est disponible. Si l'argument model est inclus dans l'appel à mlflow.evaluate(), une trace est automatiquement générée. Vous pouvez également fournir directement une colonne trace dans le dataset d'évaluation.
La mesure de latence suivante est calculée pour chaque ligne :
Nom | Description |
|---|---|
| Latence de bout en bout basée sur la trace |
Comment les métriques sont agrégées au niveau d'une exécution MLflow pour la qualité, le coût et la latence
Après avoir calculé toutes les évaluations de qualité, de coût et de latence par ligne, Agent Evaluation agrège ces évaluations en métriques par exécution qui sont enregistrées dans une exécution MLflow et résument la qualité, le coût et la latence de votre agent sur toutes les lignes d'entrée.
Agent Evaluation produit les métriques suivantes :
Nom de la métrique | Type | Description |
|---|---|---|
|
| Valeur moyenne de |
|
| Pourcentage de questions où |
|
| Pourcentage de questions où |
|
|
|
|
| Pourcentage de questions où |
|
| Pourcentage de questions où |
|
| % de questions où |
|
| Valeur moyenne de |
|
| Valeur moyenne de |
|
| Valeur moyenne de |
|
| Valeur moyenne de |
|
| Pourcentage de questions où |
|
| Valeur moyenne de |
Les captures d'écran suivantes montrent comment les métriques apparaissent dans l'interface utilisateur :


Informations sur les modèles qui alimentent les juges LLM
- Les juges LLM peuvent utiliser des services tiers pour évaluer vos applications GenAI, y compris Azure OpenAI exploité par Microsoft.
- Pour Azure OpenAI, Databricks s'est désabonné du monitoring des abus, de sorte qu'aucune invite ou réponse n'est stockée avec Azure OpenAI.
- Lorsque le cross-Geo processing est désactivé, les juges LLM traitent le contenu dans le Databricks Geo du workspace. Si aucun modèle in-Geo éligible n'est disponible, le juge renvoie une erreur de restriction géographique. Lorsque le cross-Geo processing est activé, les juges LLM peuvent traiter le contenu dans d'autres Geos.
- La désactivation des fonctionnalités d’IA optimisées par des partenaires empêche le juge LLM d'appeler des modèles optimisés par des partenaires. Vous pouvez toujours utiliser les juges LLM en fournissant votre propre modèle.
- Les juges LLM sont destinés à aider les clients à évaluer leurs agents/applications GenAI, et les résultats des juges LLM ne doivent pas être utilisés pour entraîner, améliorer ou affiner un LLM.