Ein Agent kann eine überzeugende Antwort liefern und dennoch an der Aufgabe scheitern. Vielleicht hat er das falsche Tool gewählt, veraltete Dokumente abgefragt, eine fehlschlagende API bis zum Timeout wiederholt oder die richtige Richtlinie abgerufen und dann ignoriert. Ein Test der finalen Ausgabe sieht nur das letzte Symptom. Für die Fehlersuche in Produktion brauchst du den Weg dorthin.

Das ist die Prämisse von Trace-Based Evaluation: Du bewertest einen Agenten anhand eines strukturierten Protokolls dessen, was er getan hat, statt nur anhand von Eingabe und finalem Text. Dieses Protokoll ist ein Execution Trace: eine kausal zusammenhängende Folge von Operationen wie Model Calls, Retrieval, Memory-Zugriffen, Tool-Ausführungen und Orchestrierung. Der Ansatz wird auch telemetry-defined oder framework-agnostic evaluation genannt. Die Bezeichnung ist nicht standardisiert; entscheidend ist die Architekturentscheidung.

Die aktuelle Umsetzung von Amazon ist ein nützliches Signal, nicht die Definition des Konzepts. Der Dienst AgentCore Evaluations kann Agenten aus unterschiedlichen Frameworks bewerten, wenn sie kompatible OpenTelemetry- oder OpenInference-Telemetrie ausgeben. Dabei rekonstruiert er die Aktivität aus Sessions, Traces und Spans. Im Update vom 26. August nennt AWS unter anderem LangGraph, LlamaIndex, das OpenAI Agents SDK, Google ADK, Claude Agent SDK und Strands Agents als unterstützte Ökosysteme.

Einfach gesagt: Statt nur zu fragen „War diese Antwort gut?“, hältst du genug Belege fest, um zu fragen: „Was hat der Agent getan, wo ist er falsch abgebogen, und tritt dieser Fehler wieder auf?“

Warum das jetzt wichtig ist

Klassisches Softwaretesting funktioniert am besten bei klar begrenzten Eingaben und einem vorhersehbaren Vertrag. Agent-Systeme dehnen beide Annahmen. Eine Anfrage kann dazu führen, dass ein Modell zwischen Tools auswählt, eine Wissensbasis durchsucht, einen Service aufruft, Memory speichert oder abruft und anschließend beurteilt, ob das Ergebnis ausreicht. Das Modell kann Varianz einbringen, selbst wenn der umgebende Code unverändert bleibt.

Das macht herkömmliche Tests nicht überflüssig. Du brauchst weiterhin Unit Tests für die Validierung von Argumenten, Integration Tests für Service-Grenzen und End-to-End-Checks für bekannte Workflows. Doch diese Tests beschreiben nicht unbedingt den Weg, den ein Agent in einer echten Ausführung genommen hat. Die Bewertung eines Agenten muss das vollständige Verhalten abdecken—Tool-Auswahl, mehrstufiges Reasoning, Memory Retrieval und Task Completion—und nicht nur die Qualität der Antwort. Das begründet AWS in seiner Analyse von Agent Evaluation in der Praxis. Quelle

Die entscheidende Verschiebung betrifft die Schnittstellengrenze. Bei framework-spezifischer Evaluation hängt ein Bewertungssystem häufig von Callback-Objekten oder Test-APIs eines Frameworks ab. Trace-Based Evaluation verwendet stattdessen Telemetry—maschinenlesbare Betriebsdaten—als Grenze. Wenn zwei Runtimes kompatible Datensätze ausgeben, kann eine Evaluation Pipeline beide untersuchen, ohne in eine der Runtimes eingebettet zu sein.

Diese Portabilität wird wertvoller, wenn Teams Frameworks mischen, Modelle austauschen oder Agent-Aufgaben auf mehrere Services verteilen. Sie lässt Evaluation in Entwicklung und Produktion außerdem weniger wie zwei getrennte Disziplinen wirken. Dieselbe Struktur kann kuratierte Regressionstests in CI und die Analyse von Stichproben aus Live-Traffic tragen, auch wenn sich Evaluators und Datenschutzregeln unterscheiden sollten.

Wie ein Trace zur Bewertungsfläche wird

Ein Span ist eine einzelne zeitlich erfasste Operation innerhalb eines Trace. Ein Parent Span kann eine gesamte Agent Invocation darstellen; Child Spans können einen Chat Request, einen Retrieval-Schritt, einen Tool Call oder eine Memory-Operation darstellen. Eine Session bündelt zusammengehörige Interaktionen über Zeit. Diese Hierarchie liefert einem Evaluator zugleich Detail und Kontext: Ein fehlerhaftes Tool-Argument ist ein lokaler Defekt, während das Nichterfüllen der Nutzeraufgabe ein Ergebnis auf Trace- oder Session-Ebene ist.

Die Datensätze brauchen gemeinsame Bedeutungen. OpenTelemetry ist ein offenes Observability-Framework zum Erfassen und Exportieren von Traces, Metrics und Logs. Seine GenAI Semantic Conventions definieren gemeinsame Attribute für Modellinteraktionen, Token Usage, Messages, Tool Calls, Retrieval-bezogene Daten und Evaluation Scores. Sie weisen außerdem darauf hin, dass Message Content sensible Informationen enthalten kann. Spezifikation Hintergrund

Eine praktische Pipeline funktioniert in vier Schritten:

  1. Instrumentiere relevante Operationen. Gib Struktur für die Agent Invocation und jede Modell-, Retrieval-, Memory- und Tool-Aktion aus. Erhalte Parent-Child-Beziehungen, nicht nur eine zeitgestempelte Log-Zeile.
  2. Normalisiere die Bedeutung. Nutze Semantic Conventions, wo sie passen, damit nachgelagerte Systeme eine Tool-Ausführung ohne framework-spezifisches Parsing von Textgenerierung unterscheiden können.
  3. Rekonstruiere und bewerte. Der Evaluator baut die Ausführung wieder auf und wendet einen Evaluator an: deterministischen Code, menschliche Prüfung, einen LLM-basierten Judge oder eine Kombination. AWS nennt für AgentCore Evaluations integrierte Maße wie Goal Success Rate, Correctness und Helpfulness sowie eine anpassbare LLM-as-a-judge-Evaluation. Quelle
  4. Vergleiche Versionen und untersuche Fehler. Verbinde Quality Scores mit Latenz, Token Use, Fehlern, Tool Results und dem genommenen Pfad. Eine Regression wird damit untersuchbar, statt nur als rätselhafter Rückgang eines einzelnen aggregierten Scores zu erscheinen.

Einfach gesagt: Der Trace ist nicht die Note. Er ist der Beleg, anhand dessen viele unterschiedliche Bewertungsmethoden dieselbe Ausführung prüfen können.

Was das nicht ist

Trace-Based Evaluation ist nicht bloß Distributed Tracing mit einem neuen Dashboard. Distributed Tracing liefert die Struktur für verknüpfte Operationen. Evaluation ergänzt Urteile: Hat der Agent ein erlaubtes Tool genutzt, relevantes Material abgerufen, eine Richtlinie erfüllt oder die Aufgabe korrekt abgeschlossen?

Sie ist auch nicht gleichbedeutend mit LLM-as-a-judge. Das ist eine Technik, bei der ein Sprachmodell die Ausgabe eines anderen Modells anhand einer Rubrik bewertet. Sie kann für Eigenschaften nützlich sein, die sich schwer als Assertions ausdrücken lassen, etwa Helpfulness, bleibt aber modellabhängig. Derselbe Trace kann mit exakten Regeln für Tool-Argumente, referenzbasierten Prüfungen für Antworten und menschlicher Prüfung bei strittigen Fällen untersucht werden.

Ebenso wenig macht ein gemeinsames Trace Schema Ergebnisse automatisch vergleichbar. Zwei Teams können ähnliche Spans ausgeben, aber unterschiedlichen Traffic sampeln, andere Referenzen verwenden, „Erfolg“ anders definieren oder ihr Bewertungsmodell ändern. Versioniere Instrumentierung, Evaluator Prompt oder Code, Dataset, Sampling Policy und Score-Definition gemeinsam.

Ein realistisches Engineering-Beispiel

Stell dir als hypothetisches Beispiel einen internen Support-Agenten vor. Er erhält die Frage: „Kann ich dieses Feature für einen Kunden mit Enterprise-Plan aktivieren?“ Er muss den Account identifizieren, die aktuelle Entitlement Policy abrufen, den Account-Zustand über ein Tool prüfen und den erlaubten nächsten Schritt erklären. Die Änderung selbst darf er nicht vornehmen.

Ein nützlicher Trace beginnt mit der eingehenden Anfrage und einem Agent-Invocation-Span. Child Spans zeigen, wie das Modell ein Tool zur Policy-Suche wählt, welches Retrieval-Ergebnis zurückkommt, wie der Account abgefragt wird, welchen späteren Model Call es gibt und welche finale Nachricht entsteht. Ein deterministischer Evaluator kann prüfen, dass kein Tool mit Schreibrechten aufgerufen wurde und die Account-Abfrage eine gültige Kennung nutzte. Ein Retrieval Evaluator kann untersuchen, ob eine angeführte Policy tatsächlich im abgerufenen Material enthalten war. Ein Evaluator auf Task-Ebene kann bewerten, ob die finale Antwort für einen kuratierten Testfall der erwarteten Entscheidung entspricht.

Angenommen, eine Prompt-Änderung erhöht die scheinbare Helpfulness der Antworten, senkt aber die Entitlement Correctness. Der Trace kann erklären, warum: Das Modell hat das Policy Retrieval übersprungen und aus allgemeinem Sprachwissen geantwortet. Diese Diagnose ist deutlich handlungsnäher als „Die Qualität ist gesunken“. Du kannst Retrieval für diese Anfrageklasse verlangen, das Routing anpassen oder einen Regressionstest ergänzen, der die Retrieval-Operation fordert.

Führe für CI die kuratierten Fälle aus und behalte ihre Traces. Sample für Produktion Ausführungen und suche nach Verhalten, das keine bekannte Referenz benötigt: nicht erlaubte Tool-Nutzung, wiederholte Retries, fehlendes Retrieval in regulierten Abläufen, Latenz-Ausreißer oder niedrige Judge Scores. AgentCore Evaluations unterstützt sowohl On-Demand Evaluation für Entwicklung und CI/CD als auch Online Evaluation von gesampeltem Production Traffic. Quelle

Wo es scheitert

Die Qualität der Instrumentierung setzt die Obergrenze. Fehlende Spans, falsche Parent-Child-Verknüpfungen oder framework-spezifische Felder, die andere Consumer nicht interpretieren können, erzeugen unvollständige Geschichten und irreführende Scores. Ein Trace, der nur die finale Antwort enthält, reicht nicht aus, um Tool-Auswahl, Retrieval-Qualität, Retries oder die Ursache von Latenz zu bewerten.

Datenschutz ist ebenso grundlegend. Prompts, Completions, Tool Arguments, Ergebnisse und Conversation History können personenbezogene oder vertrauliche Daten enthalten. Erfasse nur, was Evaluators brauchen; wende Filtering, Truncation, Zugriffskontrollen und Aufbewahrungsregeln an, bevor du Traces als Analytics-Dataset behandelst. Gehe nicht davon aus, dass ein Observability Store automatisch ein geeigneter Ort für rohe Kundendaten ist.

Live-Traffic hat noch eine harte Grenze: Oft gibt es keine Ground Truth. Eine Online Evaluation kann manche Signale ohne Referenzantwort messen, aber referenzbasierte Correctness und Assertion Checks benötigen Erwartungen, die über einen passenden Workflow bereitgestellt werden. AWS weist ausdrücklich auf diese Einschränkung bei Online Evaluation hin. Quelle

Schließlich bewegt sich der Vertrag noch. OpenTelemetry beschreibt seine GenAI Semantic Conventions als in aktiver Entwicklung. Behandle Attribute und Migrationen als versionierte Abhängigkeiten, nicht als feststehende Infrastruktur. Quelle

Einfach gesagt: Portierbare Evaluation funktioniert nur, wenn die aufgezeichnete Ausführung vollständig genug, sicher genug für die Aufbewahrung und stabil genug für deine Evaluators ist.

Was du in diesem Quartal tun kannst

Beginne mit einem Workflow mit hohem Wert, nicht mit allen Agenten. Notiere die Qualitätsfragen, die die finale Antwort nicht beantworten kann: Wurde ein eingeschränktes Tool aufgerufen? War Retrieval erforderlich und wurde es genutzt? Ist der Agent in einer Schleife gelandet? Hat er die Aufgabe innerhalb eines Latenzbudgets abgeschlossen?

Definiere danach einen minimalen Trace Contract. Nimm Operationstyp, Parent-Child-Beziehungen, stabile Versionskennungen, Timing, Outcome Status und sorgfältig ausgewählte Metadaten zu Ein- und Ausgaben auf. Übernimm passende OpenTelemetry GenAI Conventions und halte für alles Anwendungsspezifische ein explizites Mapping fest.

Baue eine kleine Evaluation Matrix. Nutze deterministische Checks für Sicherheit und Tool Contracts. Verwende kuratierte Referenzfälle für Correctness. Setze einen LLM Judge nur dort ein, wo eine Rubrik wirklich subjektiv ist, und kalibriere ihn anhand menschlicher Prüfung, bevor er ein Release Gate wird. Bewahre Trace Samples mit Fehlern auf, damit eine spätere Regression das Ausführungsmuster reproduziert und nicht nur den finalen Text.

Am wichtigsten ist: Mache den Trace zu einer Produkt-Schnittstelle. Frameworks, Modelle, Prompts und Tools werden sich ändern. Ein gut versioniertes Ausführungsprotokoll gibt deinem Evaluation-System die Chance, diese Änderungen zu überstehen.