Agent-Eval-Datensatz erstellen: reale Aufgaben, Trajektorien und Regressionstests

Der Agent für Tagesberichte funktionierte letzte Woche noch. Nach einem Modell-Upgrade liefert er weiterhin eine final summary, die korrekt aussieht, aber in der Trajektorie fehlen Permission-Check und Data-Refresh-Tool. Ein Support-Agent antwortet am Ende richtig, ruft aber das Refund-Tool mit falschen Argumenten auf; ein öffentlicher Benchmark sieht dieses Risiko nicht. Im Incident Review liegen traceId, tool call, approvalId, state event und menschliches Urteil bereits vor, wurden aber nicht zu einem Test gemacht, der vor dem nächsten Release laufen muss.

Solche Regressionen lassen sich nicht dadurch abdecken, dass Sie das Modell wechseln oder noch einmal eine Demo starten. Ein Agent-Eval-Datensatz muss aus realer Aufgabenverteilung und Production-Failure-Trajektorien entstehen: Tool Calls, Argumentformate, Zustandsübergänge, Approval Records und Human Labels. Danach gehört er als Regression Gate in CI. Der Schwerpunkt hier liegt auf Fehlerfällen und realen Szenarien: Wie bauen Sie ein dauerhaft laufendes eval dataset, das die Qualitätsgrenze jedes Releases schützt?

1. Warum öffentliche Benchmarks nicht reichen

1.1 Die Grenzen öffentlicher Benchmarks

Öffentliche Benchmarks messen Modellfähigkeit, nicht die Qualität Ihrer Business Tasks. Evaluation Sets wie AgentBench und WebArena liefern standardisierte Aufgaben, aber sie decken weder Ihre Toolchain noch Ihr Berechtigungsmodell oder Ihre State Machine ab.

Nehmen wir an, Ihr Reporting-Agent muss check_permission, refresh_data und generate_report aufrufen, und zwar in der Reihenfolge „prüfen → aktualisieren → erzeugen“. Ein öffentlicher Benchmark testet diesen Flow nicht, weil er Ihre tool schemas und Permission-Grenzen nicht kennt.

Ein gutes Benchmark-Ergebnis heißt also nicht, dass Ihre Business Task nicht regressiert. Ein Agent-Eval-Datensatz muss Ihre reale Aufgabenverteilung prüfen, nicht nur allgemeines Reasoning.

1.2 Der Kernwert eines eigenen Datensatzes

Ein eigenes eval dataset fängt Risiken ab, die öffentliche Benchmarks nicht sehen. Typische Beispiele:

Öffentliche Benchmarks helfen bei der Modellauswahl; eigene Datensätze schützen Release-Gates. Beides ergänzt sich, kann sich aber nicht ersetzen. Wenn Sie Agent-Evaluationsbenchmarks bereits gelesen haben, wissen Sie, welche öffentlichen Evaluation Sets bei der Auswahl helfen. Hier geht es darum, Evaluationsdaten aus Ihrer eigenen Produktionsumgebung aufzubauen.

2. Kernfelder eines Agent eval dataset

2.1 Pflichtfelder

Ein Agent eval dataset speichert nicht nur Benutzereingabe und erwartete Antwort. Es muss Tool-Call-Trajektorien, Zustandsübergänge und menschliche Urteile erfassen. Diese Felder sind Pflicht:

LangSmith empfiehlt in Evaluation concepts, bei Agent-Evaluation Tool-Auswahl, Argumentformat und Ausführungstrajektorie abzudecken, statt nur die finale Antwort zu bewerten. OpenAI Agents SDK Tracing stellt Felder wie trace_id, workflow_name und span bereit, um Tool Calls und State Events zu erfassen. Diese Rohfelder müssen jedoch erst redigiert und extrahiert werden.

2.2 Optionale Felder

Ergänzen Sie diese Felder je nach Business-Anforderung:

Alibaba Cloud - Top-Wahl für Entwickler, exklusiv 15 % Rabatt auf Lighthouse-Server

15 % Rabatt sichern →Anzeige

Wenn Sie das Agent Permission Model (N157) und das Human-Approval-Design (N155) gelesen haben, wissen Sie: approval records sollten Approval Step, Approver und Ergebnis erfassen, damit High-Risk-Aktionen als approved verifiziert werden können.

2.3 Redigierung und Datenschutz

Production Traces dürfen nicht unverändert in das Evaluation Set. Die OpenAI Agents SDK Tracing-Dokumentation weist darauf hin, dass einige spans Model Inputs/Outputs oder Function Tool Inputs/Outputs erfassen können. Sie müssen steuern, ob sensible Daten enthalten sind.

Pflicht zur Redigierung: PII (Name, E-Mail, Telefonnummer), Secrets (API key, Datenbankpasswort), Kundendaten (Bestellnummer, Transaktionsbetrag).

Felder, die bleiben können: traceId, span_id für die Diagnose, workflow_name zur Kategorisierung, Tool-Name und State-Name für Assertions.

Redigierung kann durch Platzhalter wie <user_id>, Hashing oder vollständiges Löschen erfolgen. Phoenix Running Evals on Traces zeigt, dass traces zu Evaluation Inputs werden können. Sie brauchen trotzdem label, score und rubric. Vollständige Roh-Traces gehören nicht direkt in den Evaluationsdatensatz.

3. Vom Production Trace zum eval example

3.1 Datenerfassungsprozess

Aus einem Production Trace wird ein eval example über vier Schritte: Redigierung, Labeling, Schichtung und Speicherung. Das ist kein einmaliges Engineering-Projekt, sondern laufende Operational Arbeit.

Checkliste:

1. Exportieren Sie fehlgeschlagene traces aus der Monitoring-Plattform. Siehe Agent Monitoring und Failure Recovery.
2. Klassifizieren Sie Fehler: Tool-Call-Fehler, Argumentformat-Fehler, State-Transition-Fehler, Final-Answer-Fehler.
3. Redigieren Sie Daten: PII/Secrets/Kundendaten entfernen, traceId, span_id und workflow_name behalten.
4. Ergänzen Sie Human Labels: correct/wrong/partially correct + Fehlergrund.
5. Speichern Sie nach Schicht: golden set / negative cases / edge cases.

Die Phoenix-Datasets-Dokumentation beschreibt, dass examples aus production, staging, evaluations oder manual gesammelt werden können. Production liefert die reale Aufgabenverteilung, während Staging-Testfälle Boundary-Szenarien ergänzen.

3.2 Standards für die Schichtung

Labeling-Dimensionen passend zur LLM-as-judge rubric: Korrektheit der Tool-Auswahl, Korrektheit des Argumentformats, Korrektheit der Ausführungsreihenfolge, Qualität der finalen Antwort und Alignment mit menschlichen Labels.

OpenAI Evaluation best practices empfehlen Testdaten mit typical, edge und adversarial cases sowie human expert labellers. Die Schichtung hier entspricht dieser Logik, betont aber häufige Aufgaben und typische Fehlermuster, weil das Ziel Release-Gating ist, nicht vollständige Szenarioabdeckung.

4. Trajectory assertions schreiben

4.1 Typen von Trajectory Constraints

Trajectory assertions definieren Tool-Call-, Argumentformat-, State-Transition- und Approval-Regeln, die ein Agent einhalten muss. Fünf typische Constraint-Typen:

LangSmith Evaluation concepts nennen trajectory, tool selection und argument formatting als Bestandteile von Agent-Evaluation. Phoenix Running Evals on Traces nutzt span_id, um Evaluationsergebnisse an ein konkretes Ausführungssegment zu binden. So können Trajectory Assertions bis zum fehlerhaften span zurückführen.

Wenn Sie Agent Planning Evaluation (N158) und State-Machine-/Prompt-Grenzen gelesen haben, wissen Sie, dass State-Trajectory-Felder aus state, event und checkpoint stammen. Damit lässt sich prüfen, ob Zustandsübergänge in der erwarteten Reihenfolge erfolgen.

4.2 Codebeispiel

Hier ist Pseudocode für trajectory assertions in einer allgemeinen Agent-Evaluation:

# Beispiel für trajectory assertions
def assert_trajectory_correct(result):
    # Tool-Call-Liste extrahieren
    tools_called = [call.tool for call in result.tool_calls]

    # Erforderliche Tools
    required_tools = ["check_permission", "refresh_data"]
    for tool in required_tools:
        assert tool in tools_called, f"Missing required tool: {tool}"

    # Verbotene Tools
    forbidden_tools = ["delete_user"]
    for tool in forbidden_tools:
        assert tool not in tools_called, f"Called forbidden tool: {tool}"

    # Argumentformat-Constraints
    for call in result.tool_calls:
        if call.tool == "refund":
            assert isinstance(call.args["refund_amount"], (int, float)), "refund_amount must be number"
            assert len(call.args["user_id"]) == 36, "user_id must be uuid format"

    # Reihenfolge der Zustandsübergänge
    expected_states = ["init", "check", "approve", "execute"]
    actual_states = [event.state for event in result.state_events]
    assert actual_states == expected_states, "State transition order mismatch"

    # Existenz des Approval Steps
    approval_events = [e for e in result.state_events if e.type == "approval"]
    assert len(approval_events) >= 1, "Missing approval step"

Dieser Code zeigt, wie Sie erforderliche Tools, verbotene Tools, Argumentformate, Reihenfolge der Zustandsübergänge und Approval Steps prüfen. In der Praxis können Sie LangSmith trajectory assertions oder Phoenix trace eval verwenden; die Kernlogik bleibt gleich.

KiloClaw - Managed OpenClaw für Unternehmen: AI-Agent-Orchestrierung und smartes Modell-Routing

Jetzt starten →Anzeige

Wenn Sie Agent Planning Evaluation gelesen haben, wissen Sie, dass auch Planungstrajektorien zu Regression Samples werden können, um Task Decomposition und Self-Correction zu prüfen.

5. Geschichtete Rubrics für LLM-as-judge

5.1 Warum ein Gesamtscore nicht genügt

Wenn LLM-as-judge nur einen Gesamtscore liefert, ist das Ergebnis schwankend und schwer zu debuggen. 80 Punkte können bedeuten: Die Tool-Auswahl war falsch, aber die Antwort zufällig richtig. Oder die Antwort war falsch, aber das Format sah gut aus. Sie können nicht erkennen, ob das Problem in Prompt, tool schema, Retrieval oder State Machine liegt.

LangSmith Evaluation concepts empfehlen, Qualitätskriterien für zentrale Agent-Komponenten zu definieren: correct tool selection, proper argument formatting und trajectory. Wenn jede Komponente getrennt bewertet wird, lassen sich Regressionen nach Modell- oder Prompt-Änderungen deutlich schneller lokalisieren.

Wenn Sie Advanced Prompt Engineering Practices gelesen haben, kennen Sie auch DeepEvals Fokus auf geschichtete Metriken wie TaskCompletenessMetric, statt nur den finalen Output zu bewerten.

5.2 Tabelle für geschichtete Scores

Diese rubric zerlegt Agent-Evaluation in fünf Dimensionen, jeweils mit 0 bis 2 Punkten:

Beispiel für eine rubric-Konfiguration in LangSmith oder Phoenix:

rubric:
  dimensions:
    - name: tool_selection
      weight: 0.3
      criteria:
        0: "Falsches Tool aufgerufen"
        1: "Teilweise richtige Tools aufgerufen"
        2: "Tool-Auswahl vollständig korrekt"

    - name: argument_formatting
      weight: 0.2
      criteria:
        0: "Argumenttyp ist falsch"
        1: "Einige Felder haben Formatfehler"
        2: "Argumentformat vollständig korrekt"

    - name: execution_order
      weight: 0.2
      criteria:
        0: "Zustandsübergang springt oder wiederholt sich"
        1: "Ausführungsreihenfolge weicht ab"
        2: "Ausführungsreihenfolge vollständig korrekt"

    - name: final_answer_quality
      weight: 0.2
      criteria:
        0: "Erfüllt die Benutzeranfrage nicht"
        1: "Erfüllt die Anfrage teilweise"
        2: "Erfüllt die Anfrage vollständig"

    - name: human_alignment
      weight: 0.1
      criteria:
        0: "Widerspricht Expertenurteil"
        1: "Teilweise konsistent"
        2: "Stark konsistent"

Tool-Auswahl hat das höchste Gewicht (0.3), weil der Kern eines Agents darin liegt, das richtige Tool aufzurufen. Human Alignment hat das niedrigste Gewicht (0.1), weil es vor allem kalibriert, ob LLM-as-judge mit Expertenurteilen übereinstimmt.

6. Release-Gates und Regressionstests

6.1 CI-Integrationsschritte

Der Wert eines Agent eval dataset entsteht erst, wenn es in CI als Release Gate läuft. Nutzen Sie diesen Ablauf:

Checkliste:

1. Fügen Sie der CI pipeline einen Eval-Schritt hinzu, zum Beispiel pytest, LangSmith offline eval oder Phoenix experiments.
2. Konfigurieren Sie eine pass-rate-Schwelle, zum Beispiel 90%.
3. Fordern Sie, dass das golden set vollständig besteht (100%).
4. Konfigurieren Sie Alert-Regeln für negative cases. Sie können informieren, ohne zwingend zu blockieren.
5. Richten Sie einen Versionsvergleich ein, etwa improvement/regression zwischen Baseline und aktueller Version.
6. Definieren Sie den Auslösezeitpunkt des Gates: PR / merge / canary.

LangSmith Evaluation concepts erwähnen offline evaluations für regression testing, unit testing und backtesting über examples in datasets. Phoenix experiments beschreibt, dass sich Änderungen an prompt, LLM oder Application Logic vergleichen lassen, um improvement/regression zu bewerten. DeepEval beschreibt pytest-native evals, die in CI/CD oder Python scripts laufen und mit LLMTestCase und TaskCompletenessMetric Agent traces schichtweise bewerten.

6.2 Tabelle für Schwellenwerte

Beispiel für CI-Konfiguration:

evaluation:
  triggers:
    - pull_request
    - merge_to_main
    - canary_deployment

  conditions:
    pass_rate: 0.9
    golden_set: 1.0
    no_regression: true

  notifications:
    on_failure: ["team-lead", "on-call"]
    on_negative_alert: ["team-lead"]

Gate-Trigger sind PRs, damit problematischer Code nicht in main landet; merge, damit der gemergte Stand weiterhin die Bedingungen erfüllt; und canary, um vor Production Traffic zu validieren. Wenn Sie Cost Control und Model Routing (N156) gelesen haben, wissen Sie, dass auch Kostenschwellen zu Gate Conditions werden können. Hier bleiben wir bei Evaluationsschwellen.

7. Realer Fall als Review

7.1 Szenario

Der Tagesbericht-Agent hat letzte Woche korrekt gearbeitet: check_permission prüfte die Berechtigung, refresh_data aktualisierte die Daten, danach erzeugte generate_report den Bericht. Nach einem Modell-Upgrade liefert der Agent weiterhin eine final summary, die korrekt aussieht, aber in der Trajektorie fehlen check_permission und refresh_data.

Vultr - Hochleistungs-NVMe-Cloud-Server mit 32 Standorten weltweit, Docker per Klick

Preise ansehen →Anzeige

Der Nutzer erhält einen Bericht ohne Permission-Check und mit veralteten Daten. Oberflächlich ist das nicht sichtbar. Ein öffentlicher Benchmark erkennt dieses Risiko nicht, weil er weder Ihr tool schema noch Ihre State Machine besitzt.

7.2 Problemlokalisierung

Exportieren Sie den fehlgeschlagenen trace aus der Monitoring-Plattform. Siehe Agent Monitoring und Failure Recovery. Die Trajektorienanalyse zeigt: In der Tool-Call-Liste fehlen check_permission und refresh_data, der State springt von init direkt nach execute, check und approve fehlen, und die finale Antwort sieht korrekt aus, obwohl die Datenquelle nicht aktualisiert wurde.

Label: Tool-Selection-Fehler + State-Transition-Sprung.

7.3 Dataset-Update

Fügen Sie den Fehlerfall zu negative cases hinzu. Ergänzen Sie zugleich das golden set: Finden Sie den erfolgreichen Tagesbericht-Task der Vorwoche, inklusive vollständiger Tool-Call-Sequenz, und labeln Sie ihn als korrekten Fall.

Aktualisieren Sie die trajectory assertions: check_permission und refresh_data kommen in die required tool list, und die Assertion für die State-Reihenfolge wird ["init", "check", "approve", "execute"].

7.4 Abfangen durch das CI-Gate

Der nächste PR löst einen Eval-Lauf aus. Der negative case meldet einen Alert: check_permission fehlt. Das golden set besteht vollständig, also ist die Erfolgsbasis weiterhin intakt.

Die Ursache liegt im Prompt. Nach dem Modell-Upgrade interpretiert das Modell „Bericht erzeugen“ stärker als direkte Ausführung und ignoriert die vorgelagerten Prüf- und Aktualisierungsschritte.

7.5 Fix und Regression

Passen Sie den Prompt an und machen Sie explizit: Vor dem Erzeugen eines Berichts müssen Berechtigungen geprüft und Daten aktualisiert werden. Danach läuft eval erneut: Die pass rate steigt von 85% auf 95%, der negative case besteht ohne Alert, das golden set besteht vollständig, und version comparison zeigt improvement ohne regression.

Mergen und releasen. Das CI-Gate hat diese Regression vor Production abgefangen.

7.6 Feld-Mapping-Tabelle

Diese Schleife zeigt den vollständigen Weg vom Production Failure zum Regressionstest. Nach jedem Incident Review werden traceId, tool call, approvalId, state event und menschliches Urteil zu einem eval example. So stolpert das nächste Release nicht über denselben Fehler.

8. Was Sie als Nächstes lesen sollten

• Agent State Machines und Prompt-Grenzen: Herkunft von State-Transition-Constraints und Trajectory-Assertion-Feldern verstehen
• Agent Permission Model: Approval-Record-Felder und Regeln für High-Risk Tool Calls verstehen
• Human Approval Design: approval records und Approval Flows dauerhaft in Tests überführen
• Cost Control und Model Routing: Kostenschwellen als Gate Conditions verstehen
• Agent Monitoring und Failure Recovery: Failed Traces exportieren und Incident-Review-Schleifen aufbauen