Wie Qualität, Kosten und Latenz durch die Agent-Auswertung bewertet werden
Wichtig
Dieses Feature befindet sich in der Public Preview.
In diesem Artikel wird erläutert, wie die Agent-Auswertung die Qualität, Kosten und Latenz Ihrer KI-Anwendung bewertet und Einblicke bietet, um Ihre Qualitätsverbesserungen und Kosten- und Latenzoptimierungen zu unterstützen. Er umfasst Folgendes:
- Wie Qualität von LLM-Richtern bewertet wird.
- Wie Kosten und Latenz bewertet werden.
- Wie Metriken auf der Ebene eines MLflow-Laufs für Qualität, Kosten und Latenz aggregiert werden.
Referenzinformationen zu den einzelnen integrierten LLM-Richtern finden Sie unter Mosaik AI Agent Evaluation LLM Richter.
Wie Qualität von LLM-Richtern bewertet wird
Die Agent-Bewertung bewertet die Qualität mithilfe von LLM-Richtern in zwei Schritten:
- LLM-Richter bewerten spezifische Qualitätsaspekte (z. B. Korrektheit und Erdheit) für jede Zeile. Ausführliche Informationen finden Sie in Schritt 1: LLM-Richter bewerten die Qualität der einzelnen Zeilen.
- Die Agentauswertung kombiniert die Bewertungen einzelner Richter in einer Gesamtdurchlauf-/Fehlerbewertung und der Grundursache für Fehler. Ausführliche Informationen finden Sie in Schritt 2: Kombinieren von LLM-Bewertungen, um die Ursache von Qualitätsproblemen zu identifizieren.
Informationen zu den LlM-Richtern für Vertrauens- und Sicherheitsinformationen finden Sie unter Informationen zu den Modellen, die LLM-Richter unterstützen.
Schritt 1: LLM-Richter bewerten die Qualität der einzelnen Zeilen
Für jede Eingabezeile verwendet Agent Evaluation eine Reihe von LLM-Richtern, um verschiedene Aspekte der Qualität der Ergebnisse des Agenten zu bewerten. Jeder Richter erzeugt eine Ja- oder Nein-Bewertung und einen schriftlichen Grund für diese Bewertung, wie im folgenden Beispiel gezeigt:
Ausführliche Informationen zu den verwendeten LLM-Richtern finden Sie in den verfügbaren LLM-Richtern.
Schritt 2: Kombinieren von LLM-Bewertungen zur Identifizierung der Ursache von Qualitätsproblemen
Nach der Ausführung von LLM-Richtern analysiert die Agent Evaluation ihre Ergebnisse, um die Gesamtqualität zu bewerten und eine Pass/Fail-Qualitätsbewertung für die kollektiven Bewertungen des Richters zu ermitteln. Wenn die Gesamtqualität fehlschlägt, identifiziert die Agent-Auswertung, welcher LLM-Richter den Fehler verursacht hat, und stellt vorgeschlagene Korrekturen bereit.
Die Daten werden in der MLflow-Benutzeroberfläche angezeigt und stehen auch über den MLflow-Lauf in einem DataFrame zur Verfügung, der mlflow.evaluate(...) vom Aufruf zurückgegeben wird. Details zum Zugreifen auf den DataFrame finden Sie in der Auswertungsausgabe .
Der folgende Screenshot ist ein Beispiel für eine Zusammenfassungsanalyse auf der Benutzeroberfläche:
Die Ergebnisse für jede Zeile sind in der Detailansichtsbenutzeroberfläche verfügbar:
Verfügbare LLM-Richter
Die folgende Tabelle fasst die Suite der LLM-Richter zusammen, die in der Agent-Bewertung verwendet werden, um verschiedene Aspekte der Qualität zu bewerten. Weitere Details finden Sie unter "Antwortrichter" und "Abrufrichter".
Ausführliche Informationen zu den Modellen, die die LLM-Richter unterstützen, finden Sie unter Informationen zu den Modellen, die LLM-Richter unterstützen. Referenzinformationen zu den einzelnen integrierten LLM-Richtern finden Sie unter Mosaik AI Agent Evaluation LLM Richter.
| Name des Richters | Schritt | Qualitätsaspekt, den der Richter bewertet | Erforderliche Eingaben | Erfordert Bodenwahrung? |
|---|---|---|---|---|
relevance_to_query |
Antwort | Ist die Antwortadresse (für) die Anforderung des Benutzers relevant? | - response, request |
No |
groundedness |
Antwort | Wird die generierte Antwort im abgerufenen Kontext (nicht halluzinierend) geerdet? | - response, trace[retrieved_context] |
No |
safety |
Antwort | Gibt es schädliche oder toxische Inhalte in der Antwort? | - response |
No |
correctness |
Antwort | Ist die generierte Antwort korrekt (im Vergleich zur Bodenwahrung)? | - response, expected_response |
Ja |
chunk_relevance |
Abrufen | Hat der Retriever Blöcke gefunden, die bei der Beantwortung der Anforderung des Benutzers nützlich (relevant) sind? Hinweis: Dieser Richter wird separat auf jeden abgerufenen Block angewendet und erzeugt für jeden Block eine Bewertung & Rationale. Diese Bewertungen werden in einer chunk_relevance/precision Bewertung für jede Zeile aggregiert, die die % der relevanten Blöcke darstellt. |
- retrieved_context, request |
No |
document_recall |
Abrufen | Wie viele der bekannten relevanten Dokumente hat der Retriever gefunden? | - retrieved_context, expected_retrieved_context[].doc_uri |
Ja |
context_sufficiency |
Abrufen | Hat der Retriever Dokumente mit ausreichenden Informationen gefunden, um die erwartete Antwort zu erzeugen? | - retrieved_context, expected_response |
Ja |
Die folgenden Screenshots zeigen Beispiele für die Darstellung dieser Richter auf der Benutzeroberfläche:
Wie die Ursache bestimmt wird
Wenn alle Richter bestehen, wird die Qualität berücksichtigt pass. Wenn ein Richter fehlschlägt, wird die Ursache als erster Richter bestimmt, der auf der nachstehenden geordneten Liste fehlschlägt. Diese Sortierung wird verwendet, da Bewertungen von Richtern häufig in kausaler Weise korreliert werden. Wenn context_sufficiency beispielsweise bewertet wird, dass der Retriever die richtigen Blöcke oder Dokumente für die Eingabeanforderung nicht abgerufen hat, ist es wahrscheinlich, dass der Generator keine gute Antwort synthetisiert und daher correctness auch fehlschlägt.
Wenn die Bodenwahrung als Eingabe angegeben wird, wird die folgende Reihenfolge verwendet:
context_sufficiencygroundednesscorrectnesssafety- Jeder vom Kunden definierte LLM-Richter
Wenn die Bodenwahrung nicht als Eingabe angegeben wird, wird die folgende Reihenfolge verwendet:
chunk_relevance- gibt es mindestens 1 relevante Blöcke?groundednessrelevant_to_querysafety- Jeder vom Kunden definierte LLM-Richter
Wie Databricks die LLM-Richtergenauigkeit verwaltet und verbessert
Databricks widmet sich der Verbesserung der Qualität unserer LLM-Richter. Qualität wird ausgewertet, indem gemessen wird, wie gut der LLM-Richter mit menschlichen Ratern einverstanden ist, indem die folgenden Metriken verwendet werden:
- Erhöhte Cabos Kappa (ein Maß für die Vereinbarung zwischen rater).
- Erhöhte Genauigkeit (Prozent der vorhergesagten Bezeichnungen, die mit der Bezeichnung des menschlichen Raters übereinstimmen).
- Erhöhte F1-Bewertung.
- Falsch positive Rate verringert.
- Verringerte falsch negative Rate.
Um diese Metriken zu messen, verwendet Databricks vielfältige, anspruchsvolle Beispiele aus akademischen und proprietären Datasets, die repräsentativ für Kunden-Datasets sind, um Die Richter gegen modernste LLM-Richteransätze zu vergleichen und zu verbessern, um kontinuierliche Verbesserung und hohe Genauigkeit zu gewährleisten.
Weitere Details dazu, wie Databricks misst und kontinuierlich die Bewertungsqualität verbessert, finden Sie unter Databricks wichtige Verbesserungen an den integrierten LLM-Richtern in der Agent Evaluation.
Testen Von Richtern mit dem databricks-agents SDK
Das databricks-agents SDK enthält APIs zum direkten Aufrufen von Richtern für Benutzereingaben. Sie können diese APIs für ein schnelles und einfaches Experiment verwenden, um zu sehen, wie die Richter funktionieren.
Führen Sie den folgenden Code aus, um das databricks-agents Paket zu installieren und den Python-Kernel neu zu starten:
%pip install databricks-agents -U
dbutils.library.restartPython()
Anschließend können Sie den folgenden Code in Ihrem Notizbuch ausführen und ihn bei Bedarf bearbeiten, um die verschiedenen Richter für Ihre eigenen Eingaben auszuprobieren.
from databricks.agents.eval 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."
# 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 safety, the required inputs are `request` and `response`.
judges.safety(
request=SAMPLE_REQUEST,
response=SAMPLE_RESPONSE,
)
Wie Kosten und Latenz bewertet werden
Die Agentauswertung misst die Tokenanzahl und die Ausführungslatenz, um die Leistung Ihres Agents zu verstehen.
Tokenkosten
Um die Kosten zu bewerten, berechnet die Agentauswertung die Gesamtanzahl der Token für alle AUFRUFe der LLM-Generation in der Ablaufverfolgung. Dies entspricht den Gesamtkosten, die als mehr Token angegeben werden, was in der Regel zu mehr Kosten führt. Tokenanzahlen werden nur berechnet, wenn eine trace verfügbar ist. Wenn das model-Argument in den Aufruf mlflow.evaluate() eingeschlossen ist, wird automatisch eine Ablaufverfolgung generiert. Sie können auch direkt eine trace-Spalte im Auswertungsdatensatz bereitstellen.
Die folgenden Tokenanzahlen werden für jede Zeile berechnet:
| Datenfeld | Typ | Beschreibung |
|---|---|---|
total_token_count |
integer |
Summe aller Eingabe- und Ausgabetoken über alle LLM-Abschnitte in der Ablaufverfolgung des Agents. |
total_input_token_count |
integer |
Summe aller Eingabetoken über alle LLM-Abschnitte in der Ablaufverfolgung des Agents. |
total_output_token_count |
integer |
Summe aller Ausgabetoken über alle LLM-Abschnitte in der Ablaufverfolgung des Agents. |
Ausführungslatenz
Berechnet die Latenz der gesamten Anwendung in Sekunden für die Ablaufverfolgung. Die Latenz wird nur berechnet, wenn eine Ablaufverfolgung verfügbar ist. Wenn das model-Argument in den Aufruf mlflow.evaluate() eingeschlossen ist, wird automatisch eine Ablaufverfolgung generiert. Sie können auch direkt eine trace-Spalte im Auswertungsdatensatz bereitstellen.
Die folgende Latenzmessung wird für jede Zeile berechnet:
| Name | Beschreibung |
|---|---|
latency_seconds |
End-to-End-Latenz basierend auf der Ablaufverfolgung |
Aggregierte Metriken auf der Ebene eines MLflow-Laufs für Qualität, Kosten und Latenz
Nachdem alle Bewertungen für Qualität, Kosten und Latenz pro Zeile berechnet wurden, aggregiert die Agent-Auswertung diese Asessments in Pro-Run-Metriken, die in einer MLflow-Ausführung protokolliert werden, und fassen die Qualität, Kosten und Latenz Ihres Agents in allen Eingabezeilen zusammen.
Die Agentauswertung erzeugt die folgenden Metriken:
| Metrikname | Typ | Beschreibung |
|---|---|---|
retrieval/llm_judged/chunk_relevance/precision/average |
float, [0, 1] |
Durchschnittswert von chunk_relevance/precision von allen Fragen. |
retrieval/llm_judged/context_sufficiency/rating/percentage |
float, [0, 1] |
% der Fragen, bei denen context_sufficiency/rating die Beurteilung erfolgt yes. |
response/llm_judged/correctness/rating/percentage |
float, [0, 1] |
% der Fragen, bei denen correctness/rating die Beurteilung erfolgt yes. |
response/llm_judged/relevance_to_query/rating/percentage |
float, [0, 1] |
% der Fragen, in denen relevance_to_query/rating die Beurteilung erfolgt yes. |
response/llm_judged/groundedness/rating/percentage |
float, [0, 1] |
% der Fragen, bei denen groundedness/rating die Beurteilung erfolgt yes. |
response/llm_judged/safety/rating/average |
float, [0, 1] |
% der Fragen, in denen safety/rating die Beurteilung erfolgt yes. |
agent/total_token_count/average |
int |
Durchschnittswert von total_token_count von allen Fragen. |
agent/input_token_count/average |
int |
Durchschnittswert von input_token_count von allen Fragen. |
agent/output_token_count/average |
int |
Durchschnittswert von output_token_count von allen Fragen. |
agent/latency_seconds/average |
float |
Durchschnittswert von latency_seconds von allen Fragen. |
response/llm_judged/{custom_response_judge_name}/rating/percentage |
float, [0, 1] |
% der Fragen, bei denen {custom_response_judge_name}/rating die Beurteilung erfolgt yes. |
retrieval/llm_judged/{custom_retrieval_judge_name}/precision/average |
float, [0, 1] |
Durchschnittswert von {custom_retrieval_judge_name}/precision von allen Fragen. |
Die folgenden Screenshots zeigen, wie die Metriken auf der Benutzeroberfläche angezeigt werden:
Informationen zu den Modellen, die die LLM-Richter unterstützen
- LLM-Richter verwenden möglicherweise Dienste von Drittanbietern, um Ihre GenAI-Anwendungen zu bewerten, einschließlich Azure OpenAI, betrieben von Microsoft.
- Für Azure OpenAI ist in Databricks die Missbrauchsüberwachung deaktiviert, sodass keine Prompts oder Antworten in Azure OpenAI gespeichert werden.
- Für Arbeitsbereiche der Europäischen Union (EU) verwenden LLM-Richter Modelle, die in der EU gehostet werden. Alle anderen Regionen verwenden Modelle, die in den USA gehostet werden.
- Durch die Deaktivierung von Azure KI-gesteuerten KI-Hilfsfeatures wird der LLM-Richter daran gehindert, Azure KI-gesteuerte Modelle aufzurufen.
- Daten, die an den LLM-Richter gesendet werden, werden nicht für eine Modellschulung verwendet.
- LLM-Richter sollen Kunden helfen, ihre RAG-Anwendungen zu bewerten, und LLM-Beurteilungsergebnisse sollten nicht verwendet werden, um eine LLM zu trainieren, zu verbessern oder zu optimieren.