Golden Datasets: zuverlässige Testdaten für KI-Agenten

Idee in 30 Sekunden

Golden dataset ist ein fixierter Satz von Testfällen, mit dem ein Team das Verhalten eines Agenten stabil prüft.

Der zentrale Wert: dieselbe Dataset-Version liefert vergleichbare Ergebnisse zwischen candidate und baseline.

Problem

Ohne golden dataset wird Testing schnell zufällig:

• heute wird ein Satz von Prompts geprüft;
• morgen ein anderer;
• übermorgen werden manche Cases gar nicht ausgeführt.

In diesem Modus ist schwer zu verstehen, was sich nach einem Release wirklich geändert hat: Agentenverhalten oder nur das Szenario-Set.

Häufigste Folgen:

• Regressionen werden zu spät gefunden;
• diff zwischen Versionen wirkt instabil;
• CI gate wird verrauscht und das Team vertraut ihm nicht mehr.

Kernkonzept / Modell

Golden dataset ist nicht nur eine Sammlung von Beispielen, sondern ein versioniertes Artefakt: klare Case-Struktur, Labeling-Regeln und kontrollierte Version.

Je stabiler Case-Schema, Labeling und Dataset-Version sind, desto geringer ist die Chance, dass Unterschiede zwischen Runs aus Rauschen statt aus realer Verhaltensänderung kommen.

Wie es funktioniert

In der Praxis wird golden dataset in einem separaten Prozess aktualisiert, nicht zusammen mit jedem Release. Jeder neue Case durchläuft vor Aufnahme in die Dataset-Version dieselben Schritte.

Golden dataset startet Tests nicht selbst. Es liefert die stabile Grundlage für eval harness und Regressionsvergleiche.

Umsetzung

In der Praxis basiert golden dataset auf einigen einfachen Regeln. Die Beispiele unten sind schematisch und nicht an ein konkretes Framework gebunden.

1. Kanonisches Case-Schema

expected_behavior kann sowohl harte Erwartungen für deterministische Checks als auch Kriterien für LLM-as-a-judge enthalten.

case = {
    "id": "support_refund_partial_outage",
    "input": "Refund my order #8472",
    "expected_behavior": {
        "selected_tool": "payments_api",
        "allowed_stop_reasons": ["completed", "tool_error_handled"],
    },
    "checks": ["tool_selection", "valid_output_schema"],
    "tags": ["payments", "support", "partial-outage-risk"],
}

Ein klares Schema nimmt Mehrdeutigkeit aus der Analyse problematischer Cases.

2. Deduplizierung und Rauschfilter

def is_duplicate(case, seen_signatures):
    signature = f"{case['input']}|{case['expected_behavior']}"
    return signature in seen_signatures

def is_noisy(case):
    return len(case["input"].strip()) == 0

Ein kleineres, aber stabiles Dataset ist besser als eine große Sammlung mit Duplikaten und Rauschen.

3. Labeling des erwarteten Verhaltens

def validate_case(case):
    required = ["id", "input", "expected_behavior", "checks"]
    for key in required:
        if key not in case:
            raise ValueError(f"missing_field:{key}")

Labeling muss prüfbar sein: Wenn eine Erwartung nicht validierbar ist, ist der Case nicht bereit fürs golden dataset.

4. Dataset-Versionierung

dataset_version = "golden-v1.4"
metadata = {
    "dataset_version": dataset_version,
    "created_from": "incidents_2026_q1",
    "notes": "added outage and tool-fallback cases",
}

Dataset sollte mit derselben Disziplin versioniert werden wie Code. Der Vergleich von candidate und baseline muss an eine konkrete Dataset-Version gebunden sein.

Cases ohne neue Dataset-Version zu ändern bedeutet faktisch ein anderes Testset.

5. Integration mit eval harness

run_eval_suite(
    agent=candidate_agent,
    dataset_path="datasets/golden-v1.4.json",
    baseline_report="reports/baseline-golden-v1.4.json",
)

Eine Dataset-Version muss für candidate und baseline gleich sein, sonst verliert diff seine Aussagekraft.

Hinweise für QA und Automatisierung

QA-Teams bauen automatisierte Regression-Suites meist direkt auf golden dataset: ein kurzes Smoke-Set pro PR und ein vollständiges Regressionsset für geplante Runs.

Case-Tags (payments, support, outage-risk) machen diese Sets ohne manuelle Auswahl stabil aufbaubar und helfen, die regressierte Szenarioklasse schnell zu lokalisieren.

Typische Fehler

Dataset ändert sich zwischen Runs

Cases werden ohne neue Version ergänzt oder geändert, dadurch sind zwei Run-Ergebnisse nicht mehr vergleichbar.

Typische Ursache: kein expliziter Prozess für Dataset-Versionierung.

Nur Happy-Path-Cases

Dataset deckt nur saubere Anfragen ab und enthält keine Incidents oder Edge-Cases.

Typische Ursache: Cases werden manuell hinzugefügt, ohne Analyse von Production-Traces.

Unklares Labeling von expected behavior

Cases haben Input, aber keine prüfbare Erwartung, daher können Evaluators keinen verlässlichen Verdict liefern.

Typische Ursache: Labeling wird als Freitext ohne Schema geschrieben.

Unfixierte Run-Bedingungen

Selbst korrekte Tests liefern keine vergleichbaren Ergebnisse, wenn sich Modell, Runtime oder externe Abhängigkeiten zwischen Runs ändern.

Typische Ursache: Modellalias, schwankende Runtime-Einstellungen oder instabile Umgebung.

Fehlende Coverage-Tags

Das Team sieht nicht, welche Risikoklassen im Dataset schon abgedeckt sind und welche noch leer sind.

Typische Ursache: Cases werden ohne tags und ohne Szenario-Gruppierung gespeichert.

Instabile Cases im golden dataset

Derselbe Case besteht und fällt zufällig, was das Regressionssignal verschmutzt.

Typische Ursache: instabile externe Abhängigkeiten oder nicht vollständig kontrollierte Runtime.

Kurzfassung

FAQ

Q: Worin unterscheidet sich golden dataset von einem normalen Testsatz?
A: Es ist eine stabile, versionierte Case-Basis, auf der Agentenverhalten zwischen Versionen verglichen wird.

Q: Wie oft sollte golden dataset aktualisiert werden?
A: Meist in separaten Versionen nach Sammlung neuer Incidents oder wichtiger Szenarien, nicht vor jedem kleinen Release.

Q: Darf man synthetische Cases aufnehmen?
A: Ja, aber die Basis sollte auf realen Production-Szenarien beruhen. Synthetik ergänzt die Edge-Case-Coverage gut.

Q: Was tun mit instabilen Cases?
A: Entweder Runtime und Checks stabilisieren oder den Case vorübergehend aus golden dataset entfernen, bis die Run-Bedingungen normalisiert sind.

Was als Nächstes

Nach dem Aufbau von golden dataset bindet ihr es in Eval Harness ein und steuert Versionsänderungen über Regression Testing.

Für Incidents in realen Umgebungen ergänzt Replay and Debugging. Für die Gesamtstrategie bleibt Testing Strategy die Referenz.