AI Operations · 12 Min.
Synthetic Data für Agent Evals: Wie du KI-Agenten testest, bevor echte Kunden betroffen sind
Echte Kundendaten sind nicht immer der richtige Start für Evals. Synthetische Testfälle machen Agenten sicherer, bevor sie produktiv werden.
SYSTEMS Grafik zu Synthetic Data Agent Evals: Trace -> Metric -> Decision. Fokus: Wie Unternehmen synthetische Daten für sichere und nützliche Agenten-Evals einsetzen.
Kurzfassung
Synthetische Daten helfen, Agenten ohne Kundendaten zu testen. Gute Evals brauchen Normalfälle, Edge Cases und Angriffe. Synthetische Tests müssen später mit realen Fehlern ergänzt werden.
Strategischer Lesepfad
Baue das Thema im passenden Cluster weiter aus und verknüpfe es mit den nächsten Architekturentscheidungen.
Warum synthetische Daten nützlich sind Viele Teams wollen Agenten testen, dürfen aber keine echten Kundendaten verwenden. Synthetische Daten schaffen realistische Fälle ohne direkte Datenschutzlast.
Sie sind ein Startpunkt für Sicherheit.
Stand Mai 2026: Agent Evals sind Trace-, Tool- und Output-Tests OpenAI empfiehlt für Fehler auf Workflow-Ebene Trace Grading. Dabei werden nicht nur finale Antworten bewertet, sondern der Ablauf: Entscheidungen, Tool Calls und Zwischenschritte. Google unterscheidet in der dokumentierten Agent-Evaluation ebenfalls Final Response Evaluation und Trajectory Evaluation, also Antwortqualität und Weg des Agenten durch Tool Calls. Anthropic erlaubt im Eval-Tool ausserdem Testfälle zu generieren und die Generierungslogik anzupassen.
Das ist entscheidend: Ein Agent kann am Ende nett klingen und trotzdem das falsche Tool genutzt, zu viele Daten gelesen oder einen riskanten Zwischenschritt gemacht haben. Synthetische Daten müssen deshalb nicht nur Prompts enthalten. Sie müssen erwartete Tool-Pfade, verbotene Aktionen, Datenklassen und Freigabegrenzen abbilden.
Was synthetische Daten abdecken sollten Testdaten sollten gute Fälle, schlechte Fälle, unvollständige Inputs, widersprüchliche Angaben und Missbrauch enthalten. Sonst testet man nur den Happy Path.
Gerade Agenten mit Tools brauchen bösartige und verwirrende Szenarien.
Ein brauchbares synthetisches Eval-Set enthält:
Die besten synthetischen Tests sehen aus wie echte Arbeit, enthalten aber bewusst eingebaute Fallen.
Normalfälle: typische Kundenanfragen, normale Daten, erwarteter Tool-Pfad. Edge Cases: fehlende Felder, widersprüchliche Angaben, doppelte Datensätze. Rechtefälle: User darf lesen, aber nicht schreiben; Mandant A darf nie Mandant B sehen. Tool-Fallen: ähnliche Tools, falsche Reihenfolge, zu breite Suche. Prompt Injection: untrusted Content versucht, Regeln oder Tool-Auswahl zu manipulieren. Sicherheitsfälle: PII, Zahlungsdaten, vertrauliche Dokumente, rechtliche oder finanzielle Aussagen. Regressionen: alte Produktionsfehler als anonymisierte oder synthetisch nachgebaute Fälle. Kostenfälle: Agent soll nicht zehn Tools nutzen, wenn ein gezielter Abruf reicht. Das Eval-Schema Jeder Testfall sollte maschinenlesbar und reviewbar sein:
So wird ein Eval kein Bauchgeführ, sondern ein Vertrag.
`scenario`: Was passiert? `input`: Was sieht der Agent? `user_role`: Welche Rechte gelten? `data_class`: public, intern, vertraulich, personenbezogen, kundenspezifisch. `allowed_tools`: Welche Tools sind erlaubt? `forbidden_tools`: Welche Tools wären ein Fehler? `expected_trajectory`: Welche Tool-Schritte sind richtig? `expected_output`: Was soll der Agent sagen oder vorbereiten? `approval_required`: Wo muss ein Mensch bestätigen? `grader`: Welche Regel entscheidet bestanden/nicht bestanden? Was gemessen werden sollte Für Agenten reichen klassische Textmetriken nicht. Wichtiger sind:
Google nennt bei Agent-Evals unter anderem trajectory exact match, in-order match, any-order match, precision und recall für Tool-Pfade. Das ist ein guter Denkrahmen für alle Plattformen.
Final Response Quality: Ist die Antwort korrekt und hilfreich? Tool Use Quality: Wurden die richtigen Tools genutzt? Trajectory Match: Entspricht der Ablauf dem erlaubten Pfad? Hallucination: Wurden nicht belegte Informationen erfunden? Safety: Hat der Agent sensible Grenzen respektiert? Failure Rate: Bricht der Agent sauber ab? Latency und Kosten: Ist der Ablauf betrieblich tragbar? Grenzen synthetischer Tests Synthetische Daten sind nie die ganze Wirklichkeit. Sobald ein Agent produktiv läuft, müssen echte Fehler anonymisiert in den Eval-Satz wandern.
So bleibt der Test lebendig.
Wichtig: Synthetische Daten sind nicht automatisch datenschutzfrei oder vollständig. OpenAI nennt synthetische Eval-Daten als eine mögliche Quelle, aber belastbare Sets sollten mit Domain-Fällen, historischen Fehlern, Produktionssignalen und menschlich kuratierten Beispielen kombiniert werden. Wenn synthetische Daten aus echten Kundendaten abgeleitet sind, müssen Re-Identifikation, seltene Merkmale und sensible Kombinationen bedacht werden. NIST beschreibt im Generative-AI-Profil Risiken rund um synthetische Inhalte und Evaluation. Deshalb gehören synthetische Testdaten genauso in ein Daten- und Governance-Konzept wie Produktionsdaten.
Der Eval-Flywheel Produktive Agenten brauchen einen Lernkreislauf:
1. Synthetische Baseline erstellen. 2. Agent gegen Normal-, Edge- und Angriffsszenarien laufen lassen. 3. Trace und Output graden. 4. Fehlerklasse bestimmen: Prompt, Tool, Rechte, Kontext, Daten, Modell. 5. Fix bauen. 6. Testfall dauerhaft in Regression übernehmen. 7. Produktionsvorfälle anonymisiert nachmodellieren.
So entsteht ein wachsendes Schutzsystem statt ein einmaliger Testlauf.
Der SYSTEMS-Blick Wir bauen Evals zuerst synthetisch, dann lernend. Erst prüfen wir Risiken kontrolliert, danach verbessern echte Korrekturen das System.
Das macht Agenten robuster, bevor Kunden betroffen sind: klare Testfälle, nachvollziehbare Traces, messbare Tool-Pfade und Regressionen, die jeden Fehler in bessere Architektur übersetzen.
