Regressionstests für KI-Agenten: nicht eines reparieren und drei zerstören
Warum ein Golden Dataset und CI-Gates die einzige verlässliche Abwehr gegen stille Agenten-Regressionen sind, wenn Modelle, Prompts und Tools sich darunter ändern.
Definition
Agenten-Regressionstests führen ein festes Set repräsentativer Fälle — ein Golden Dataset — bei jeder Änderung aus, um zu erkennen, wann eine Korrektur oder ein Update das Verhalten anderswo verschlechtert. In CI mit Schwellen verdrahtet, machen sie stille Regressionen zu sichtbaren Build-Fehlern.
Sie ändern einen Prompt, um einen lästigen Fall zu beheben. Es klappt. Drei andere Fälle scheitern nun still, und Sie erfahren es in Produktion. Das ist das Agenten-Regressionsproblem, und ein in CI verdrahtetes Golden Dataset ist die einzige verlässliche Heilung.
Warum regredieren Agenten?
Alles unter einem Agenten bewegt sich: Prompts werden angepasst, Modelle aktualisiert, Tools ändern ihre Ausgaben. Jede Änderung wirkt durch ein nicht-deterministisches System auf eine Weise, die man per Inspektion nicht durchdenken kann. Eine Korrektur, die einen Fall hebt, versenkt oft andere — und weil es keinen Compiler-Fehler gibt, ist die Regression still, bis ein Nutzer auf sie trifft.
Das Golden Dataset
Die Heilung ist ein Golden Dataset: ein festes, kuratiertes Set repräsentativer Fälle, das Sie bei jeder Änderung scoren. Bauen Sie es aus zwei Quellen:
- Reale, vielfältige Nutzung — Fälle, die abbilden, wie der Agent tatsächlich genutzt wird, nicht nur der Happy Path.
- Jeder vergangene Fehler — wenn Sie einen Produktionsfehler beheben, fügen Sie ihn als dauerhaften Fall hinzu, damit er nie still zurückkehrt.
Jeder Fall braucht eine Eingabe und eine Methode, das Ergebnis zu bewerten — exakter Abgleich wo möglich, ein kalibrierter LLM-Judge bei offenen Ausgaben, plus stichprobenartige menschliche Prüfung.
In CI verdrahten
Ein Golden Dataset schützt nur, wenn es automatisch läuft. Behandeln Sie es wie eine Testsuite:
- Bei jeder Änderung an Prompts, Modellen oder Tools ausführen.
- Schwellen setzen — Completion-Rate, Faithfulness, Kosten pro Aufgabe.
- Den Build fehlschlagen lassen, wenn eine Schwelle fällt. Eine Prompt-Änderung, die einen Fall hebt, aber die Suite absacken lässt, sollte nicht ausgeliefert werden.
Das ist Eval-Driven Development: Sie ändern den Agenten gegen eine messbare Latte, und die Latte fängt, was die Intuition verfehlt.
| Aspekt | Einmaliges Eval | Regressionstests |
|---|---|---|
| Wann es läuft | Einmal, auf Abruf | Bei jeder Änderung, automatisch |
| Beantwortet | Wie gut ist er heute? | Ist heute schlechter als gestern? |
| Fängt stille Regressionen | Nein | Ja |
| Rolle | Momentaufnahme | Leitplanke |
Die Suite ehrlich halten
- Kontinuierlich erweitern. Jeder neue Fehler wird ein Fall; die Suite wird mit jedem Vorfall stärker.
- Gegen Drift auffrischen. Wenn Modelle sich ändern, neu validieren, dass Ihr Judge weiterhin mit menschlichen Labels übereinstimmt.
- Auf Overfitting achten. Stimmen Sie auf bestimmte Fälle ab statt auf gutes Verhalten, ergänzen Sie frische Fälle, die der Agent nicht gesehen hat.
Eine Demo beweist, dass ein Agent einmal funktionieren kann. Regressionstests beweisen, dass er nach der hundertsten Änderung noch funktioniert. Das erlaubt, Autonomie zu erhöhen und mit Evidenz statt Hoffnung auszuliefern. Begriffe stehen im Glossar.
Häufige Fragen
Warum regredieren Agenten so leicht?
Weil sich alles unter einem Agenten bewegt, und jede Änderung wirkt durch ein nicht-deterministisches System auf eine Weise, die man nicht durch Lesen des Diffs vorhersagen kann. Eine Prompt-Änderung, ein Modell-Update, ein Tool, das sein Ausgabeformat ändert — jedes davon kann das Verhalten über Fälle verschieben, die mit Ihrer Änderung scheinbar nichts zu tun haben. Die konkrete Falle ist, dass eine Korrektur, die einen Fall verbessert, sehr oft mehrere andere verschlechtert, weil derselbe Prompt oder dasselbe Modell sie alle zugleich regiert und Sie faktisch das gesamte Verhalten neu gewichten, sooft Sie daran stellen. Bei klassischer Software wirft eine brechende Änderung meist einen Compiler- oder Testfehler; bei einem Agenten gibt es kein solches Signal, also ist die Regression still, bis ein Nutzer in Produktion auf sie trifft. Nicht-Determinismus verstärkt das, denn der Fehler reproduziert sich womöglich nicht bei jedem Lauf. Der einzige verlässliche Weg, Regressionen zu sehen, ist, ein festes, repräsentatives Set von Fällen bei jeder Änderung zu messen, damit ein Rückgang als Zahl erscheint und nicht als Support-Ticket Wochen später.
Was kommt in ein Golden Dataset?
Zwei Arten von Fällen, aus der Realität geschöpft, nicht aus der Vorstellung. Erstens reale und vielfältige Nutzung: Beispiele, die abbilden, wie der Agent tatsächlich über die volle Bandbreite seiner Eingaben genutzt wird, einschließlich der unsauberen und ungewöhnlichen, nicht nur der Happy Path, der in einer Demo gut aussieht. Zweitens jeder bisher behobene Fehler: Wenn Sie einen Produktionsfehler lösen, fügen Sie ihn als dauerhaften Fall hinzu, damit genau dieser Fehler nie still zurückkehrt, und das lässt die Suite über die Zeit an Wert gewinnen. Jeder Fall braucht eine Eingabe und eine Methode, das Ergebnis zu bewerten — exakter Abgleich, wo die Antwort wohldefiniert ist, ein kalibrierter LLM-Judge bei offenen Ausgaben und stichprobenartige menschliche Prüfung bei den wichtigsten Fällen. Halten Sie es repräsentativ statt erschöpfend: Einige hundert gut gewählte Fälle, die abdecken, wie der Agent wirklich gelingt und scheitert, schützen Sie besser als Tausende Beinahe-Duplikate, und das Set sollte bewusst wachsen, ein Fall pro neuem Fehlermodus, damit es genau dort stärker wird, wo Sie sich verbrannt haben.
Wie unterscheidet sich das von einmaligen Evals?
Ein einmaliges Eval ist eine Momentaufnahme: Es sagt, wie der Agent heute abschneidet, was für eine Go-oder-No-Go-Entscheidung zu einem Zeitpunkt nützlich ist, aber nichts über morgen aussagt. Regressionstests sind eine Leitplanke: Sie führen dasselbe feste Set von Fällen bei jeder Änderung automatisch aus und sagen, ob heute schlechter ist als gestern auf genau diesen Fällen. Dieser Wechsel von der Momentaufnahme zum kontinuierlichen Vergleich ist der ganze Sinn, denn das Agenten-Regressionsproblem dreht sich grundsätzlich um Veränderung über die Zeit — eine Korrektur, die still etwas anderes bricht — und das fängt nur eine stabile, wiederholte Messung. Beide sind komplementär statt konkurrierend: Sie könnten ein breites einmaliges Eval bei der Modellwahl fahren und dann einen repräsentativen Ausschnitt in eine Regressionssuite destillieren, die jede weitere Änderung gatet. Die bestimmenden Merkmale von Regressionstests sind, dass sie fix sind (dieselben Fälle pro Lauf), automatisch (in CI verdrahtet) und gatend (ein Rückgang lässt den Build fehlschlagen), was zusammen eine Qualitätsprüfung von einem gelegentlichen Ereignis in eine stehende Verteidigung verwandelt.
Ist es nicht zu langsam oder teuer, Evals bei jeder Änderung auszuführen?
Es ist eine reale Sorge, aber ein Tuning-Problem und kein Grund, die Suite wegzulassen, und die Kosten, sie nicht zu haben — eine stille Regression an Nutzer auszuliefern — sind fast immer höher. Der Hebel ist Größe und Zusammensetzung des Golden Sets: Halten Sie es klein und repräsentativ statt erschöpfend, sodass ein voller Lauf Minuten dauert, nicht Stunden, und Sie nicht dafür zahlen, bei jedem Commit Tausende Beinahe-Duplikate neu zu scoren. Sie können die Läufe auch staffeln: eine schnelle Kernsuite bei jeder Änderung für das Gate und eine größere, langsamere Suite nachts oder vor einem Release für tiefere Abdeckung. Wo ein LLM-Judge die Kosten dominiert, nutzen Sie ein günstigeres Modell fürs Routine-Scoring und reservieren einen stärkeren Judge für die knappen Fälle, und cachen Sie Ergebnisse für unveränderte Fälle. Die Ökonomie spricht meist mit großem Abstand für die Suite, denn ein verhinderter Produktionsvorfall — das vergeudete Debugging, das Nutzervertrauen, der Rollback — bezahlt sehr viel Eval-Compute. Behandeln Sie die Laufkosten als Budget zum Steuern, nicht als Grund, blind zu fliegen.