Aller au contenu principal

Comment la qualité, les coûts et la latence sont évalués par Agent Evaluation (MLflow 2)

important

Databricks recommande d’utiliser MLflow 3 pour l’évaluation et le monitoring des applications GenAI. Cette page décrit MLflow 2 Agent Evaluation.

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 :

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 :

  1. 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.
  2. 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.

remarque

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 :

Exemple de sortie du juge

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 :

vue d'ensemble de l'analyse des causes racines

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

détail de l'analyse des causes racines

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 :

Détail du juge générique

détail de la pertinence des segments

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é :

  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 entrée, l'ordre suivant est utilisé :

  1. chunk_relevance - Y a-t-il au moins 1 segment 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 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 :

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.

Python
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

total_token_count

integer

Somme de tous les jetons d'entrée et de sortie dans toutes les portées LLM de la trace de l'agent.

total_input_token_count

integer

Somme de tous les jetons d'entrée à travers tous les spans de LLM dans la trace de l'agent.

total_output_token_count

integer

Somme de tous les jetons de sortie à travers toutes les étendues LLM dans la trace de l'agent.

Champ de données

Type

Description

total_token_count

integer

Somme de tous les jetons d'entrée et de sortie dans toutes les portées LLM de la trace de l'agent.

total_input_token_count

integer

Somme de tous les jetons d'entrée à travers tous les spans de LLM dans la trace de l'agent.

total_output_token_count

integer

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

latency_seconds

Latence de bout en bout basée sur la trace

Nom

Description

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 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

retrieval/llm_judged/chunk_relevance/precision/average

float, [0, 1]

Valeur moyenne de chunk_relevance/precision sur toutes les questions.

retrieval/llm_judged/context_sufficiency/rating/percentage

float, [0, 1]

Pourcentage de questions où context_sufficiency/rating est jugé comme yes.

response/llm_judged/correctness/rating/percentage

float, [0, 1]

Pourcentage de questions où correctness/rating est jugé comme yes.

response/llm_judged/relevance_to_query/rating/percentage

float, [0, 1]

relevance_to_query/rating % des questions où est jugé yes.

response/llm_judged/groundedness/rating/percentage

float, [0, 1]

Pourcentage de questions où groundedness/rating est jugé comme yes.

response/llm_judged/guideline_adherence/rating/percentage

float, [0, 1]

Pourcentage de questions où guideline_adherence/rating est jugé comme yes.

response/llm_judged/safety/rating/average

float, [0, 1]

% de questions où safety/rating est jugé yes.

agent/total_token_count/average

int

Valeur moyenne de total_token_count sur toutes les questions.

agent/input_token_count/average

int

Valeur moyenne de input_token_count sur toutes les questions.

agent/output_token_count/average

int

Valeur moyenne de output_token_count sur toutes les questions.

agent/latency_seconds/average

float

Valeur moyenne de latency_seconds sur toutes les questions.

response/llm_judged/{custom_response_judge_name}/rating/percentage

float, [0, 1]

Pourcentage de 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 sur toutes les questions.

Nom de la métrique

Type

Description

retrieval/llm_judged/chunk_relevance/precision/average

float, [0, 1]

Valeur moyenne de chunk_relevance/precision sur toutes les questions.

retrieval/llm_judged/context_sufficiency/rating/percentage

float, [0, 1]

Pourcentage de questions où context_sufficiency/rating est jugé comme yes.

response/llm_judged/correctness/rating/percentage

float, [0, 1]

Pourcentage de questions où correctness/rating est jugé comme yes.

response/llm_judged/relevance_to_query/rating/percentage

float, [0, 1]

relevance_to_query/rating % des questions où est jugé yes.

response/llm_judged/groundedness/rating/percentage

float, [0, 1]

Pourcentage de questions où groundedness/rating est jugé comme yes.

response/llm_judged/guideline_adherence/rating/percentage

float, [0, 1]

Pourcentage de questions où guideline_adherence/rating est jugé comme yes.

response/llm_judged/safety/rating/average

float, [0, 1]

% de questions où safety/rating est jugé yes.

agent/total_token_count/average

int

Valeur moyenne de total_token_count sur toutes les questions.

agent/input_token_count/average

int

Valeur moyenne de input_token_count sur toutes les questions.

agent/output_token_count/average

int

Valeur moyenne de output_token_count sur toutes les questions.

agent/latency_seconds/average

float

Valeur moyenne de latency_seconds sur toutes les questions.

response/llm_judged/{custom_response_judge_name}/rating/percentage

float, [0, 1]

Pourcentage de 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 sur toutes les questions.

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

métriques d'évaluation, valeurs

métriques d'évaluation, graphiques.

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.