Regression Testing für KI-Agenten: Verhalten stabil halten

Idee in 30 Sekunden

Regression testing für KI-Agenten vergleicht candidate mit baseline auf denselben Cases und unter denselben Bedingungen.

Der zentrale Wert ist, dass es genau zeigt, wo sich Systemverhalten nach Änderungen an Modell, Prompts, Tools oder Runtime verändert hat.

Problem

Ohne regression testing sieht das Team oft nur ein allgemeines "besser/schlechter", versteht aber nicht, was genau gebrochen ist.

Typische Folgen:

• unauffällige Regressionen gelangen ins Release;
• kritische Szenarien verschlechtern sich, obwohl das Gesamtergebnis normal wirkt;
• es ist schwer zu erklären, ob die Ursache im Code, Modell, Prompt oder in Laufbedingungen liegt.

Am Ende wirkt ein Release sicher, aber in Production treten wiederkehrende Incidents auf.

Wann einsetzen

Regression testing ist immer dann nötig, wenn Änderungen das Agentenverhalten beeinflussen können:

• Modellversion wurde aktualisiert;
• Prompt oder Policy-Regeln wurden geändert;
• Tools wurden ergänzt oder umgebaut;
• Runtime-Einstellungen wurden geändert (timeouts, retries, limits).

Regression testing beantwortet eine Frage: was hat sich zwischen Systemversionen geändert.

Es sollte auch nach Incidents laufen, um zu prüfen, dass ein Fix keine benachbarten Szenarien beschädigt hat.

Umsetzung

In der Praxis gilt eine Regel: gleiche Cases, gleiche Laufbedingungen, plus Vergleich mit fixiertem baseline. Die Beispiele unten sind schematisch und nicht an ein konkretes Framework gebunden.

Wie es in einem Run funktioniert

Ein Regression-Run verwendet meist denselben eval harness, aber mit Ergebnisvergleich gegen baseline.

1. Baseline und Dataset-Version fixieren

regression_context = {
    "dataset_version": "golden-v1.4",
    "baseline_report": "reports/baseline-golden-v1.4.json",
    "model_version": "gpt-4o-2024-08-06",
}

baseline muss an eine konkrete Dataset-Version, ein konkretes Modell und konkrete Laufbedingungen gebunden sein.

2. Candidate unter gleichen Bedingungen ausführen

def run_candidate(agent, dataset, runtime_config):
    return run_eval_suite(
        agent=agent,
        dataset=dataset,
        timeout_sec=runtime_config["timeout_sec"],
        max_steps=runtime_config["max_steps"],
        tool_mocks=runtime_config["tool_mocks"],
    )

Ohne identische Bedingungen wird diff schnell verrauscht und verliert diagnostischen Wert.

3. Diff gegen Risikoschwellen berechnen

def compare_summary(candidate, baseline):
    deltas = {
        "task_success_drop": baseline["task_success_rate"] - candidate["task_success_rate"],
        "latency_growth": candidate["p95_latency"] - baseline["p95_latency"],
        "cost_growth": candidate["avg_token_cost"] - baseline["avg_token_cost"],
    }
    return deltas

Schwellenwerte sollten explizit gesetzt sein, damit Release-Entscheidungen deterministisch bleiben.

4. Nicht nur Summary, auch Cases prüfen

def critical_case_regressions(case_diffs):
    bad = []
    for diff in case_diffs:
        if diff["status"] == "regressed" and "critical" in diff["tags"]:
            bad.append(diff["case_id"])
    return bad

Auch wenn Summary gut aussieht, müssen Regressionen in kritischen Cases das Release blockieren.

5. Regression gate in CI ergänzen

deltas = compare_summary(candidate_summary, baseline_summary)
critical_failures = critical_case_regressions(case_diffs)

if deltas["task_success_drop"] > 0.03:
    fail("gate_failed:task_success_drop")
if deltas["latency_growth"] > 800:  # ms
    fail("gate_failed:latency_growth")
if critical_failures:
    fail(f"gate_failed:critical_cases:{critical_failures}")

Regression gate sollte verpflichtend sein für Änderungen an Modell, Prompts, Tools oder Runtime.

Hinweise für QA und Automatisierung

QA-Teams führen regression meist nach Modell- oder Prompt-Updates aus, um den Verhaltens-diff gegenüber baseline sofort zu sehen.

Praktisch bedeutet das: verpflichtender CI-Run bei Änderungen an Model/Prompt-Konfiguration und eine regelmäßige vollständige regression suite, um langsame Degradationen zu erkennen.

Typische Fehler

Automatisches Überschreiben von baseline

Das Team verliert den stabilen Vergleichspunkt, und die Regressionshistorie wird unscharf.

Typische Ursache: baseline wird automatisch ohne separate Entscheidung aktualisiert.

Unterschiedliche Laufbedingungen für baseline und candidate

Runs werden verglichen, aber mit unterschiedlichen timeouts, Modellversionen oder mocks.

Typische Ursache: kein fixiertes Runtime-Config für regression.

Nur Gesamtmetriken vergleichen

Das Gesamtergebnis sieht normal aus, aber kritische Cases degradieren.

Typische Ursache: im Report fehlt ein Case-Level-diff.

Keine klaren Schwellen für CI gate

Release-Entscheidungen werden "nach Gefühl" getroffen, und das Regressionssignal geht verloren.

Typische Ursache: Schwellenwerte sind nicht in CI-Regeln fixiert.

Instabile Cases im Regression-Set

Derselbe Case besteht mal und fällt mal, und das Team verliert Vertrauen in den Report.

Typische Ursache: flaky-Szenarien sind ohne Stabilisierung im Haupt-Regression-Set gelandet.

Kurzfassung

FAQ

Q: Worin unterscheidet sich regression testing von eval harness?
A: Eval harness führt einen standardisierten Run aus, regression testing nutzt diesen Run für den Vergleich candidate gegen baseline.

Q: Wann sollte baseline aktualisiert werden?
A: Nach einem bestätigten Release, wenn das Team das neue Verhalten bewusst als Referenz akzeptiert.

Q: Was blockiert ein Release im regression gate am häufigsten?
A: Einbruch in kritischen Cases, Rückgang von task_success_rate, starker Anstieg von latency oder token cost.

Q: Reichen synthetische Cases für regression aus?
A: Für den Start ja, ein stabileres Signal kommt aber aus der Kombination von synthetischen Cases und Replay-Szenarien aus Production.

Was als Nächstes

Nach der Einrichtung des regression gate bindet ihr stabile Cases über Golden Datasets ein und standardisierte Runs über Eval Harness. Für lokale Logikprüfungen nutzt Unit Testing, und Incidents analysiert mit Replay and Debugging.