Comment la qualité, le coût et la latence sont évalués par l’évaluation de l’agent (MLflow 2)

Importante

Cette page décrit l’utilisation de la version 0.22 d’évaluation de l’agent avec MLflow 2. Databricks recommande d’utiliser MLflow 3, qui est intégré à l’évaluation de l’agent >1.0. Dans MLflow 3, les API d’évaluation de l’agent font désormais partie du mlflow package.

Pour plus d’informations sur cette rubrique, consultez Création de scorers LLM personnalisés.

Cet article explique comment l’évaluation de l’agent évalue la qualité, le coût et la latence de votre application IA et fournit des insights pour guider vos améliorations de qualité et vos optimisations de coût et de latence. Il couvre les points suivants :

• Comment la qualité est évaluée par les juges LLM.
• Comment les coûts 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 obtenir des informations de référence sur chacun des juges LLM intégrés, consultez les juges IA intégrés (MLflow 2).

Comment la qualité est évaluée par les juges LLM

L’agent évalue la qualité à l’aide des juges LLM en deux étapes :

1. Les juges LLM évaluent des aspects de qualité spécifiques (comme l’exactitude et le fondement) pour chaque ligne. Pour plus d' informations, consultez l’étape 1 : les juges LLM évaluent la qualité de chaque rangée.
2. L’évaluation de l’agent combine les évaluations d’un juge individuel en un score global de réussite/échec et une cause racine pour les défaillances. Pour plus d’informations, consultez l’étape 2 : Combiner des évaluations de juge LLM pour identifier la cause racine des problèmes de qualité.

Pour obtenir des informations sur la confiance et la sécurité du juge LLM, consultez Informations sur les modèles qui alimentent les juges LLM.

Remarque

Pour les conversations à plusieurs tours, les juges LLM évaluent uniquement la dernière entrée dans la conversation.

Étape 1 : les juges LLM évaluent la qualité de chaque rangée

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 indiqué dans l’exemple ci-dessous :

Pour plus d’informations sur les juges LLM utilisés, consultez les juges IA intégrés.

Étape 2 : Combiner des évaluations de juge LLM pour identifier la cause racine des problèmes de qualité

Après avoir fait fonctionner les juges LLM, Agent Evaluation analyse leurs résultats pour évaluer la qualité globale et déterminer un score de qualité réussite/échec sur les évaluations collectives des juges. Si la qualité globale échoue, l’évaluation de l’agent identifie quel juge LLM spécifique a provoqué l’échec et fournit des correctifs suggérés.

Les données sont affichées dans l’interface utilisateur MLflow et sont également disponibles à partir de l’exécution MLflow dans un DataFrame retourné par l’appel mlflow.evaluate(...) . Pour plus d’informations sur l’accès au DataFrame, consultez la sortie de l’évaluation.

La capture d’écran suivante est un exemple d’analyse récapitulative dans l’interface utilisateur :

Cliquez sur une demande pour afficher les détails :

Juges IA intégrés

Consultez les juges IA intégrés (MLflow 2) pour plus d’informations sur les juges IA intégrés fournis par Mosaic AI Agent Evaluation.

Les captures d’écran suivantes montrent des exemples de la façon dont ces juges apparaissent dans l’interface utilisateur :

Détermination de la cause racine

Si tous les juges approuvent, la qualité est considérée comme pass. Si un juge échoue, la cause racine est déterminée comme le premier juge à échouer en fonction de la liste ordonnée ci-dessous. Cette ordonnance est utilisée parce que les évaluations de juge sont souvent corrélées d’une manière causale. Par exemple, si context_sufficiency évalue que le récupérateur n’a pas récupéré les blocs ou documents appropriés pour la demande d’entrée, il est probable que le générateur n'arrive pas à synthétiser une bonne réponse et que correctness échoue donc également.

Si la vérité est fournie comme entrée, l’ordre suivant est utilisé :

1. context_sufficiency
2. groundedness
3. correctness
4. safety
5. guideline_adherence (si guidelines ou global_guidelines sont fournis)
6. Tout juge LLM défini par le client

Si la vérité terrain n'est pas fournie en tant qu'entrée, l'ordre suivant est utilisé :

1. chunk_relevance - y a-t-il au moins 1 bloc pertinent ?
2. groundedness
3. relevant_to_query
4. safety
5. guideline_adherence (si guidelines ou global_guidelines sont fournis)
6. Tout juge LLM défini par le client

Comment Databricks gère et améliore la précision du juge LLM

Databricks s’engage à améliorer la qualité de nos juges LLM. La qualité est évaluée en mesurant la façon dont le juge LLM est d’accord avec les noteurs humains, en utilisant les métriques suivantes :

• Augmentation du Kappa de Cohen (une mesure de l’accord inter-évaluateurs).
• Précision accrue (pourcentage d’étiquettes prédites qui correspondent aux étiquettes de l'annotateur humain).
• Augmentation du score F1.
• Baisse du taux de faux positifs.
• Baisse du taux négatif faux.

Pour mesurer ces métriques, Databricks utilise des exemples variés et complexes de jeux de données universitaires et propriétaires représentatifs des jeux de données clients pour évaluer et améliorer les juges contre les approches de juge LLM de pointe, ce qui garantit une amélioration continue et une précision élevée.

Pour plus d’informations sur la façon dont Databricks mesure et améliore continuellement la qualité des juges, consultez Databricks annonce des améliorations significatives apportées aux juges LLM intégrés dans l’évaluation de l’agent.

Appeler des juges à l’aide du Kit de développement logiciel (SDK) Python

Le kit de développement logiciel (SDK) databricks-agents inclut des API pour appeler directement des juges sur les entrées utilisateur. Vous pouvez utiliser ces API pour une expérience rapide et facile pour voir comment fonctionnent les juges.

Exécutez le code suivant pour installer le databricks-agents package et redémarrer le noyau Python :

%pip install databricks-agents -U
dbutils.library.restartPython()

Vous pouvez ensuite exécuter le code suivant dans votre bloc-notes et le modifier si nécessaire pour tester les différents juges sur vos 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 les coûts et la latence sont évalués

L'évaluation de l'agent calcule le nombre de jetons ainsi que la latence d'exécution pour vous aider à mieux comprendre les performances de votre agent.

Coût du jeton

Pour évaluer le coût, l’évaluation de l’agent calcule le nombre total de jetons sur tous les appels de génération LLM dans la trace. Cela permet d’estimer le coût total donné en tant que jetons supplémentaires, ce qui entraîne généralement un coût plus élevé. Les nombres de jetons sont calculés uniquement lorsqu’un trace jeton est disponible. Si l’argument model est inclus dans l’appel à mlflow.evaluate(), une trace est générée automatiquement. Vous pouvez également fournir directement une colonne trace dans le jeu de données d’évaluation.

Les nombres de jetons suivants sont calculés pour chaque ligne :

champ de données	Type	Descriptif
total_token_count	integer	Somme de tous les jetons d’entrée et de sortie sur toutes les étendues LLM dans la trace de l’agent.
total_input_token_count	integer	Somme de tous les jetons d’entrée sur toutes les étendues LLM dans la trace de l’agent.
total_output_token_count	integer	Somme de tous les jetons de sortie sur toutes les étendues LLM dans la trace de l’agent.

Latence d’exécution

Calcule la latence de l’application entière en secondes pour la trace. La latence est calculée uniquement lorsqu’une trace est disponible. Si l’argument model est inclus dans l’appel à mlflow.evaluate(), une trace est générée automatiquement. Vous pouvez également fournir directement une colonne trace dans le jeu de données d’évaluation.

La mesure de latence suivante est calculée pour chaque ligne :

Nom	Descriptif
latency_seconds	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 la qualité, du coût et de la latence par ligne, l'évaluation de l'agent agrège ces évaluations pour chaque exécution. Elles 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.

L’évaluation de l’agent produit les métriques suivantes :

Nom de métrique	Type	Descriptif
retrieval/llm_judged/chunk_relevance/precision/average	float, [0, 1]	Valeur moyenne de chunk_relevance/precision pour toutes les questions.
retrieval/llm_judged/context_sufficiency/rating/percentage	float, [0, 1]	% des questions où context_sufficiency/rating est jugé comme yes.
response/llm_judged/correctness/rating/percentage	float, [0, 1]	% des questions où correctness/rating est jugé comme yes.
response/llm_judged/relevance_to_query/rating/percentage	float, [0, 1]	% des questions où relevance_to_query/rating est jugé être yes.
response/llm_judged/groundedness/rating/percentage	float, [0, 1]	% des questions où groundedness/rating est jugé comme yes.
response/llm_judged/guideline_adherence/rating/percentage	float, [0, 1]	% des questions où guideline_adherence/rating est jugé comme yes.
response/llm_judged/safety/rating/average	float, [0, 1]	% des questions où safety/rating est jugé pour être yes.
agent/total_token_count/average	int	Valeur moyenne de total_token_count pour toutes les questions.
agent/input_token_count/average	int	Valeur moyenne de input_token_count pour toutes les questions.
agent/output_token_count/average	int	Valeur moyenne de output_token_count pour toutes les questions.
agent/latency_seconds/average	float	Valeur moyenne de latency_seconds pour toutes les questions.
response/llm_judged/{custom_response_judge_name}/rating/percentage	float, [0, 1]	% des questions où {custom_response_judge_name}/rating est jugé comme yes.
retrieval/llm_judged/{custom_retrieval_judge_name}/precision/average	float, [0, 1]	Valeur moyenne de {custom_retrieval_judge_name}/precision pour toutes les questions.

Les captures d’écran suivantes montrent comment les métriques apparaissent dans l’interface utilisateur :

Information sur les modèles qui propulsent les juges LLM

• Les juges LLM peuvent utiliser des services tiers pour évaluer vos applications GenAI, y compris Azure OpenAI géré par Microsoft.
• Pour Azure OpenAI, Databricks a choisi de ne pas participer à la surveillance des abus. Aucun prompt ou réponse n’est donc stocké avec Azure OpenAI.
• Pour les espaces de travail de l’Union européenne (UE), les juges LLM utilisent des modèles hébergés dans l’UE. Toutes les autres régions utilisent des modèles hébergés aux États-Unis.
• La désactivation des fonctionnalités d’assistance basées sur l’IA‭ alimentée par Azure empêche le juge LLM d’appeler les modèles Azure basés sur l’IA.
• Les juges LLM sont destinés à aider les clients à évaluer leurs agents/applications GenAI, et les sorties des juges LLM ne doivent pas être utilisées pour former, améliorer ou affiner un LLM.