Ground-Truth-Bewertungen
Ground Truth ist die bekannte richtige Antwort oder das erwartete Verhalten für eine bestimmte Eingabe — der „Goldstandard“, mit dem Sie die tatsächlichen Ergebnisse vergleichen. Bei der Bewertung durch Experten wandelt Ground Truth die subjektive Qualitätsbeurteilung in objektive Messungen um und ermöglicht so Regressionserkennung, Benchmark-Datensätze und domänenspezifische Korrektheit, die generische Gutachter allein nicht bieten können.
Bei Ground-Truth-Evaluationen geben Sie beim Aufrufen der Evaluate-API Referenzeingaben zusammen mit Ihren Sitzungsintervallen an. Der Service verwendet diese Referenzeingaben, um das tatsächliche Verhalten Ihres Agenten mit dem erwarteten Verhalten zu vergleichen. Gutachter, die ein bestimmtes Ground-Truth-Feld nicht verwenden, ignorieren es und geben an, welche Felder in der Antwort nicht verwendet wurden.
Integrierte Evaluatoren und Ground-Truth-Felder werden unterstützt
Die folgende Tabelle zeigt, welche integrierten Evaluatoren Ground Truth unterstützen und welche Felder sie verwenden.
| Evaluator | Level | Feld „Ground Truth“ | Description |
|---|---|---|---|
|
|
Trace |
|
Misst, wie genau die Antwort des Agenten mit der erwarteten Antwort übereinstimmt. Verwendet LLM-as-a-Judge Scoring. |
|
|
Sitzung |
|
Überprüft, ob das Verhalten des Agenten während der gesamten Sitzung den Aussagen in natürlicher Sprache entspricht. Verwendet Scoring. LLM-as-a-Judge |
|
|
Sitzung |
|
Überprüft, ob die tatsächliche Reihenfolge der Tool-Aufrufe exakt mit der erwarteten Reihenfolge übereinstimmt — dieselben Tools, dieselbe Reihenfolge, keine Extras. Programmatische Bewertung (keine LLM-Aufrufe). |
|
|
Sitzung |
|
Überprüft, ob alle erwarteten Werkzeuge in der richtigen Reihenfolge innerhalb der tatsächlichen Reihenfolge angezeigt werden, erlaubt aber zusätzliche Werkzeuge zwischen ihnen. Programmatische Bewertung. |
|
|
Sitzung |
|
Überprüft, ob alle erwarteten Tools in der tatsächlichen Reihenfolge vorhanden sind, unabhängig von der Reihenfolge. Zusätzliche Tools sind zulässig. Programmatische Bewertung. |
Anmerkung
Benutzerdefinierte Evaluatoren unterstützen auch Ground-Truth-Felder durch Platzhalter in ihren Bewertungsanweisungen. Weitere Informationen finden Sie unter Ground Truth in benutzerdefinierten Evaluatoren.
In der folgenden Tabelle werden die Ground-Truth-Felder beschrieben.
| Feld | Typ | Scope | Description |
|---|---|---|---|
|
|
Zeichenfolge |
Trace |
Die erwartete Antwort des Agenten für eine bestimmte Runde. Gültig für einen Trace, der |
|
|
Liste von Zeichenfolgen |
Sitzung |
Aussagen in natürlicher Sprache, die auf das Verhalten des Agenten während der Sitzung zutreffen sollten. |
|
|
Liste der Werkzeugnamen |
Sitzung |
Die erwartete Reihenfolge der Tool-Aufrufe für die Sitzung. |
-
Ground-Truth-Felder sind optional. Wenn Sie sie weglassen, greifen die Evaluatoren auf ihren Ground-Truth-Free-Modus zurück (funktioniert z. B.
Builtin.Correctnessimmer noch ohneexpectedResponse, er bewertet nur anhand des Kontextes). -
Sie können alle Ground-Truth-Felder in einer einzigen Anfrage bereitstellen. Der Service wählt die relevanten Felder für jeden Gutachter aus und meldet
ignoredReferenceInputFieldsin der Antwort alle Felder, die nicht verwendet wurden. -
Sie müssen nicht jeden Trace angeben
expectedResponse. Spuren ohne Ground Truth werden mit der Ground-Truth-Free-Variante des Evaluators ausgewertet.
Voraussetzungen
-
Python 3.10 und höher
-
Ein auf AgentCore Runtime bereitgestellter Agent mit aktivierter Observability oder ein Agent, der mit einem unterstützten Framework erstellt wurde, das mit Observability konfiguriert ist. AgentCore Unterstützte Frameworks:
-
Strands, Agenten
-
LangGraph mit
opentelemetry-instrumentation-langchainoderopeninference-instrumentation-langchain
-
-
Transaktionssuche aktiviert in CloudWatch — siehe Transaktionssuche aktivieren
-
AWS Anmeldeinformationen, die mit Berechtigungen für
bedrock-agentcorebedrock-agentcore-control, undlogs(CloudWatch) konfiguriert sind
Anweisungen zum Herunterladen von Sitzungsspannen finden Sie unter Erste Schritte mit der On-Demand-Evaluierung.
Informationen zu den Beispielen
Die Beispiele auf dieser Seite verwenden den Beispielagenten aus den AgentCore Evaluations-Tutorialscalculator und weather — und wird auf AgentCore Runtime mit aktivierter Observability bereitgestellt.
In den Beispielen wird von einer Sitzung mit zwei Turns ausgegangen:
-
Runde 1: „Was ergibt 15 + 27?“ — Der Agent verwendet das
calculatorTool und antwortet mit dem Ergebnis. -
Runde 2: „Wie ist das Wetter?“ — Der Agent verwendet das
weatherTool und antwortet mit dem aktuellen Wetter.
Rufen Sie Ihren Agenten auf, bevor Sie Evaluationen durchführen, und warten Sie 2—5 Minuten, CloudWatch bis die Telemetriedaten aufgenommen sind.
Die folgenden Konstanten werden in den Beispielen auf dieser Seite verwendet. Ersetzen Sie sie durch Ihre eigenen Werte:
REGION = "<region-code>" AGENT_ID = "my-agent-id" SESSION_ID = "my-session-id" TRACE_ID_1 = "<trace-id-1>" # Turn 1: "What is 15 + 27?" TRACE_ID_2 = "<trace-id-2>" # Turn 2: "What's the weather?"
Richtigkeit mit erwarteter Antwort
Builtin.Correctnessist ein Evaluator auf Trace-Ebene, der misst, wie genau die Antwort des Agenten mit der erwarteten Antwort übereinstimmt. Wenn Sie eine Antwort gebenexpectedResponse, vergleicht der Evaluator die tatsächliche Antwort des Agenten anhand der Punktezahl mit Ihrer Grundwahrheit. LLM-as-a-Judge
Beispiel
GoalSuccessRate mit Behauptungen
Builtin.GoalSuccessRateist ein Evaluator auf Sitzungsebene, der überprüft, ob das Verhalten des Agenten einer Reihe von Behauptungen in natürlicher Sprache entspricht. Assertions können die Nutzung des Tools, den Inhalt der Antwort, die Reihenfolge der Aktionen oder jedes andere beobachtbare Verhalten während der gesamten Konversation überprüfen.
Anmerkung
In den folgenden Beispielen werden Assertionen verwendet, die die Nutzung des Tools validieren, aber es handelt sich bei Assertionen um natürliche Sprache in freier Form. Sie können sie verwenden, um Aussagen zu allen Aspekten des Verhaltens von Agenten zu machen, z. B. zum Ton der Antwort, zur sachlichen Richtigkeit, zur Einhaltung von Sicherheitsbestimmungen oder zur Geschäftslogik.
Beispiel
Trajektorie stimmt mit erwarteter Trajektorie überein
Die Trajektorienauswerter vergleichen die tatsächliche Reihenfolge der Werkzeugaufrufe des Agenten mit einer erwarteten Reihenfolge von Werkzeugnamen. Drei Varianten sind verfügbar, jede mit unterschiedlicher Trefferquote. Bei allen drei Evaluatoren handelt es sich um Evaluatoren auf Sitzungsebene, die programmgesteuerte Bewertung verwenden (keine LLM-Aufrufe, daher ist die Token-Nutzung gleich Null).
| Evaluator | Passende Regel | Beispiel |
|---|---|---|
|
|
Der tatsächliche Wert muss exakt dem Erwarteten entsprechen — dieselben Tools, dieselbe Reihenfolge, keine Extras |
Erwartet: |
|
|
Die erwarteten Tools müssen in der richtigen Reihenfolge angezeigt werden, aber zusätzliche Tools sind zwischen ihnen zulässig |
Erwartet: |
|
|
Alle erwarteten Werkzeuge müssen vorhanden sein, Reihenfolge spielt keine Rolle, Extras sind erlaubt |
Erwartet: |
Beispiel
Kombiniert alle Ground-Truth-Felder in einer Anfrage
Sie können alle Ground-Truth-Felder zusammen in einem einzigen Bewertungsgespräch bestehen. Der Service leitet jedes Feld an den entsprechenden Evaluator weiter und ignoriert Felder, die ein bestimmter Evaluator nicht verwendet. Das bedeutet, dass Sie Ihre Referenzeingaben einmal erstellen und sie für verschiedene Evaluatoren wiederverwenden können, ohne die Nutzlast zu ändern.
Beispiel
Grundlegendes zu ignorierten Referenz-Eingabefeldern
Wenn Sie Ground-Truth-Felder angeben, die ein Evaluator nicht verwendet, enthält die Antwort ein ignoredReferenceInputFields Array, in dem die nicht verwendeten Felder aufgeführt sind. Das ist informativ und kein Fehler — die Auswertung wird trotzdem erfolgreich abgeschlossen.
Wenn Sie beispielsweise Builtin.Helpfulness mit „provided“ aufrufen, ignoriert der Evaluator die Grundwahrheit (Helpfulness verwendet sie nicht) und gibt expectedResponse Folgendes zurück:
{ "evaluatorId": "Builtin.Helpfulness", "value": 0.83, "label": "Very Helpful", "explanation": "...", "ignoredReferenceInputFields": ["expectedResponse"] }
Dieses Verhalten ist beabsichtigt — es ermöglicht Ihnen, einen einzigen Satz von Referenzeingaben zu erstellen und sie für mehrere Evaluatoren zu verwenden, ohne die Nutzlast für jeden einzelnen anpassen zu müssen.
Ground Truth in benutzerdefinierten Evaluatoren
Benutzerdefinierte Evaluatoren können Ground-Truth-Felder mithilfe von Platzhaltern in ihren Bewertungsanweisungen verwenden. Wenn Sie einen benutzerdefinierten Evaluator erstellen, können Sie auf die folgenden Platzhalter verweisen:
-
Session-level benutzerdefinierte Evaluatoren:
{context},,,,{available_tools}{actual_tool_trajectory}{expected_tool_trajectory}{assertions} -
Trace-level benutzerdefinierte Evaluatoren:
{context},,{assistant_turn}{expected_response}
Ein benutzerdefinierter Evaluator auf Trace-Ebene, der die Ähnlichkeit von Antworten überprüft, könnte beispielsweise Folgendes verwenden:
Compare the agent's response with the expected response. Agent response: {assistant_turn} Expected response: {expected_response} Rate how closely the agent's response matches the expected response on a scale of 0 to 1.
Wenn dieser Evaluator expectedResponse in den Referenzeingaben mit aufgerufen wird, ersetzt der Service den Platzhalter vor der Bewertung durch den tatsächlichen Ground-Truth-Wert.
Anmerkung
Benutzerdefinierte Evaluatoren, die Ground-Truth-Platzhalter ({assertions},,{expected_tool_trajectory}) verwenden{expected_response}, können in Online-Evaluierungskonfigurationen nicht verwendet werden, da Online-Evaluierungen den Live-Produktionsverkehr überwachen, bei dem keine Ground-Truth-Werte verfügbar sind.