Messen & ausrollen: Verhalten als versioniertes Artefakt

Zwei Fragen, eine Kette

„Ist die neue Fassung besser?“ und „wie bringen wir sie in Produktion?“ werden in den meisten Teams von verschiedenen Leuten zu verschiedenen Zeitpunkten beantwortet. Bei einem Agenten ist das dieselbe Frage von zwei Seiten: Ohne Messung gibt es kein Abbruchkriterium für den Rollout, und ohne Rollout gibt es kein Signal für die Messung.

Die Verbindung ist konkret. Ein Canary braucht eine Kennzahl, an der man abbricht. Diese Kennzahl kommt aus der Evaluation. Und die Evaluation braucht Fälle, die aus dem Produktionsverkehr stammen — den es nur gibt, weil vorher ausgerollt wurde.

Was eigentlich ausgerollt wird

Bei klassischer Software ist die Ausrolleinheit klar: ein Artefakt aus dem Buildprozess. Bei einem Agenten liegt das Verhalten in mehreren Dingen gleichzeitig, und jedes einzelne kann es verändern.

• Die Systemanweisung — der offensichtliche Teil, und der einzige, den die meisten Teams versionieren.
• Die Werkzeugliste samt Beschreibungen — eine geänderte Beschreibung ändert die Auswahl und damit den Pfad.
• Das Modell und seine Version — dieselbe Anweisung führt bei einem anderen Modell zu anderem Verhalten.
• Die Grenzen — Rundendeckel, Budgets, Freigabeschwellen. Sie entscheiden, welche Läufe überhaupt zu Ende kommen.
• Die Abruf- und Kontextkonfiguration — was vorab im Kontext steht und was verdrängt wird.

Verhaltensartefakt — Die gemeinsam versionierte Menge aller Determinanten des Verhaltens: Anweisung, Werkzeuge, Modell, Grenzen, Kontextkonfiguration. Nur wenn sie eine Einheit bilden, ist eine Aussage wie „Fassung 14 war besser als 13“ überhaupt sinnvoll.

Der Test, ob ein Team das umgesetzt hat, ist einfach: Kann jemand zu einem Lauf von vor drei Wochen sagen, welche Werkzeugbeschreibungen damals aktiv waren? Wenn nicht, ist jede Regressionsanalyse über diesen Zeitraum eine Erzählung.

Praktisch ist das eine Datei mit benannten Feldern, die zusammen ausgerollt und zusammen zurückgenommen werden: behavior_version, prompt_sha, tool_manifest_sha, model, limits, retrieval_config. Jeder Lauf schreibt die behavior_version in sein Protokoll. Erst damit ist die Frage „welche Fassung hat diesen Lauf erzeugt“ eine Abfrage statt einer Rekonstruktion.

Die beiden Prüfsummen sind kein Formalismus. Eine Systemanweisung, die jemand direkt in einer Konfigurationsoberfläche geändert hat, ändert das Verhalten ohne Versionswechsel — und genau dieser Fall ist die häufigste Ursache für Regressionen, die niemand erklären kann. Wer den Hash bei jedem Lauf mitschreibt, entdeckt solche Änderungen am Tag, an dem sie passieren.

Der Datensatz kommt aus dem Verkehr

Die verbreitetste Form eines Testsatzes für Agenten ist eine Liste von Fällen, die sich jemand am Whiteboard überlegt hat. Sie ist besser als nichts und sie ist systematisch falsch verteilt: Sie enthält die Fälle, an die man denkt, und nicht die, die auftreten.

• Aus echten Anfragen ziehen — nach Häufigkeit geschichtet, damit die häufigen Fälle die häufigen bleiben.
• Die Ränder ausdrücklich aufnehmen — die seltenen Formen, bei denen es schiefgeht, gehören mit bekanntem Anteil hinein statt zufällig.
• Jeden echten Vorfall aufnehmen — als dauerhafter Fall, formuliert über sein Ziel und nicht über seinen Wortlaut.
• Erwartungen ausdrücklich machen — nicht nur die richtige Antwort, sondern auch, welche Aktionen verboten sind und welches Budget gilt.

Der letzte Punkt unterscheidet einen Agenten-Testsatz von einem Antwort-Testsatz. Ein Fall besteht hier nicht aus Eingabe und erwarteter Ausgabe, sondern aus Eingabe, erwartetem Ergebnis, verbotenen Aktionen und einer Obergrenze für Aufwand. Wer nur die Ausgabe prüft, gibt einem gefährlichen Pfad mit richtigem Ergebnis die volle Punktzahl.

Verbotene Aktionen lassen sich dabei einfacher ausdrücken, als es klingt: als Liste von Werkzeugnamen mit optionalen Argumentmustern, etwa delete_* für jeden Fall, in dem nur gelesen werden sollte. Die Prüfung läuft dann gegen die aufgezeichnete Trajektorie und braucht kein Urteil — sie ist ein Vergleich.

Klein anfangen

Der naheliegende Reflex ist, erst einen großen Testsatz aufzubauen und dann zu messen. Die Erfahrung spricht dagegen: Klein anfangen — wenige, gut gewählte Fälle machen die Wirkung einer Änderung deutlicher sichtbar.

Der Grund ist arithmetisch und wird oft übersehen. In einem großen, gemischten Satz verschwindet eine Verbesserung von zehn Prozentpunkten in einem Teilbereich hinter dem Rauschen der übrigen Fälle. Bei zwanzig gezielten Fällen sieht man sie. Ein großer Satz ist die richtige Struktur für ein Gate, nicht für die Entwicklungsarbeit.

Endantwort oder Trajektorie

Die Bewertung eines Agentenlaufs kann an zwei Stellen ansetzen, und beide sind nötig. Nur die Endantwort zu prüfen ist die häufigste und teuerste Vereinfachung.

Endantwort

Stimmt das Ergebnis? Billig zu prüfen, notwendig — und blind gegenüber allem, was auf dem Weg passiert ist.

Trajektorie

Welche Aktionen wurden ausgeführt, wurden verbotene darunter, wie viele Runden und wie viel Budget? Das ist die Prüfung, die einen latenten Fehler findet.

Beides zusammen

Eine richtige Antwort über einen gefährlichen Pfad ist ein Fehlschlag, kein Erfolg. Nur wer beides bewertet, kann das ausdrücken.

Der Bewerter

Für alles, was sich nicht als exakter Vergleich prüfen lässt, braucht es ein Urteil. Ein Modell als Bewerter einzusetzen funktioniert — unter Bedingungen, die man kennen muss.

Bemerkenswert ist, welche Form sich als tragfähig erwiesen hat: ein einziger Prompt, der eine Punktzahl zwischen 0,0 und 1,0 und ein Bestanden-oder-nicht ausgibt. Diese schlichte Form war am beständigsten und lag am nächsten an menschlichen Urteilen — bemerkenswert, weil aufwendigere Bewertungsschemata mit vielen Teilkriterien naheliegen und schlechter abschnitten.

Taugt

Prüfbare Kriterien in einem Prompt, kalibriert gegen eine Menge menschlich bewerteter Fälle, mit ausgewiesener Übereinstimmungsrate.

Taugt nicht

Ein Bewerter ohne Kalibrierung. Seine Punktzahl ist dann eine Zahl ohne Bezug — sie schwankt mit Formulierung und Modellversion.

Taugt nicht

Derselbe Modellaufbau als Bewerter wie als Ausführender. Er teilt die blinden Flecken und bewertet den eigenen Fehler als richtig.

Und der Befund, der die Rolle von Menschen dauerhaft festlegt: Menschliche Tester finden Randfälle, die Auswertungen übersehen. In einem dokumentierten Fall stellten sie fest, dass frühe Agenten durchgängig suchmaschinenoptimierte Inhaltsfarmen gegenüber verlässlichen, aber schlechter platzierten Quellen bevorzugten — ein Muster, auf das keine automatische Bewertung geprüft hätte, weil niemand es vermutet hatte.

Varianz ist die Messgröße, nicht das Störgeräusch

Ein Agentenlauf ist eine Ziehung aus einer Verteilung. Damit ist eine einzelne Zahl aus einem einzelnen Durchlauf kein Messwert, sondern eine Stichprobe der Größe eins — und die Differenz zweier solcher Zahlen ist keine Verbesserung, sondern Rauschen.

• Mehrere Läufe je Fall — die Zahl folgt aus der beobachteten Streuung, nicht aus einem runden Wert.
• Streuung ausweisen — eine Erfolgsquote ohne Bandbreite lässt sich nicht mit einer anderen vergleichen.
• Gate an das Band legen — die Schwelle gilt gegen die untere Grenze des Bandes, nicht gegen den Mittelwert.
• Denselben Datensatz — ein Vergleich über zwei verschiedene Testsätze hinweg ist kein Vergleich.

Der praktische Effekt ist zunächst unangenehm: Viele Änderungen, die vorher als Verbesserung galten, sind es unter dieser Betrachtung nicht mehr nachweisbar. Das ist kein Verlust, sondern die Korrektur einer Überschätzung — und es verhindert, dass man auf Rauschen hin optimiert.

Das Gate

Ein Regressionsgate für ein nichtdeterministisches System kann nicht „alle Tests grün“ verlangen. Es braucht Schwellen, und die müssen aus der beobachteten Streuung kommen statt aus einer Zielvorstellung.

Erfolgsquote

Untere Bandgrenze über der Schwelle. Der Wert kommt aus dem Bezugslauf der aktuellen Fassung, nicht aus einer Wunschzahl.

Verbotene Aktionen

Harte Null. Diese Kennzahl braucht kein Band — ein einziger Fall genügt zum Abbruch.

Aufwand

Rundenzahl und Tokenverbrauch mit Obergrenze. Ohne diese Grenze gewinnt jede Fassung, die einfach mehr ausgibt.

Neue Fälle

Vorfälle aus der Produktion als eigene Gruppe, die dauerhaft geprüft wird — auch wenn sie längst behoben scheinen.

Die dritte Zeile ist der Punkt, an dem sich Evaluation und Kosten treffen. Bei Agenten erklärt der Tokenverbrauch einen großen Teil der Leistungsunterschiede — in einer dokumentierten Messung erklärte er allein 80 Prozent der Varianz. Eine Qualitätsverbesserung ohne Kostenangabe ist deshalb keine Aussage: Sie könnte schlicht daher kommen, dass die neue Fassung mehr Arbeit hineinsteckt.

Die Reihenfolge ist nicht beliebig. Die harte Prüfung kommt vor dem Bandvergleich, weil sie billig ist und ihr Ergebnis eindeutig: Ein Kandidat, der eine verbotene Aktion ausgeführt hat, muss nicht mehr auf Qualität verglichen werden. Wer sie hinten anstellt, diskutiert über Prozentpunkte, während der eigentliche Befund weiter unten in der Auswertung steht.

Schatten vor Canary, wenn es Nebenwirkungen gibt

Ein Canary schickt einen Anteil des echten Verkehrs auf die neue Fassung — mit echter Wirkung. Bei einem Agenten, der schreibt, heißt das: Fünf Prozent Canary sind fünf Prozent echte, möglicherweise falsche Aktionen.

Schattenbetrieb

Die neue Fassung läuft mit, ihre Aktionen werden nicht ausgeführt, sondern nur aufgezeichnet und verglichen. Kein Wirkungsrisiko, volle Verkehrsverteilung.

Canary

Ein Anteil des Verkehrs läuft echt auf der neuen Fassung. Notwendig für alles, was sich nur an echter Wirkung zeigt — und mit Wirkungsrisiko.

Reihenfolge

Bei schreibenden Agenten erst Schatten, dann Canary. Der Schatten filtert die groben Abweichungen heraus, bevor sie jemanden treffen.

Der Schattenbetrieb hat eine Grenze, die man kennen muss: Er zeigt Abweichungen im Vorschlag, nicht in der Wirkung. Ein Agent, der im Schatten dieselbe Aktion vorschlägt wie die alte Fassung, kann bei echter Ausführung an einer Stelle scheitern, die im Schatten nie erreicht wurde. Und er kostet die volle Rechnung für einen Lauf, dessen Ergebnis verworfen wird.

Canary ohne feste Kennzahl

Der schwierigste Canary ist der, bei dem die eigentliche Qualität erst nach Tagen sichtbar wird — etwa bei einem Agenten, dessen Fehler sich in einer Widerspruchsquote drei Wochen später zeigt. Ein Abbruchkriterium braucht man trotzdem, und zwar vorher.

• Ersatzsignale — Kennzahlen, die früh reagieren und mit der Zielgröße korrelieren: Abbruchquote, Eskalationsrate, Rundenzahl, Anteil der Enthaltungen.
• Formfehler — Anteil der Läufe mit Schemaverstoß oder ungültiger Aktion. Reagiert sofort und ist eindeutig.
• Menschliche Korrekturen — wie oft eine Freigabe abgelehnt oder eine Aktion nachträglich zurückgenommen wurde.
• Ein Zeitfenster mit Vorabfestlegung — wenn kein Signal früh reagiert, gilt eine feste Beobachtungsdauer bei kleinem Anteil, vorher vereinbart.

Rollback heißt Kompensation

Bei zustandsloser Software ist Rollback vollständig: Die alte Fassung läuft wieder, und nichts erinnert an die neue. Bei einem Agenten, der gehandelt hat, ist das nur die halbe Wahrheit.

Praktisch heißt das: Ein Rollback-Plan für einen schreibenden Agenten besteht aus zwei Teilen. Der erste ist der Fassungswechsel und dauert Sekunden. Der zweite ist die Liste der Aktionsarten mit ihrer jeweiligen Gegenmaßnahme — und die gehört geschrieben, bevor der Canary startet, nicht während er brennt.

Was der Check prüft

• Die Schritte eines Rollouts in die Reihenfolge bringen, in der jeder auf dem vorherigen aufbaut.
• Einen Testsatz aus dem Verkehr statt aus der Vorstellung aufbauen.
• Eine Versionsangabe lesen und die Verhaltensdeterminante finden, die darin fehlt.
• Ein Gate für ein nichtdeterministisches System formulieren, das nicht an einem Einzellauf hängt.
• Eine Auswertung von der Endantwort auf die Trajektorie erweitern.
• Einen Modellbewerter so einsetzen, dass seine Punktzahl einen Bezug hat.
• Zwischen Schattenbetrieb und Canary entscheiden — abhängig davon, ob Aktionen wirken.
• Ein Abbruchkriterium formulieren, wenn die Zielkennzahl erst spät reagiert.
• Einen Rollback planen, der eingetretene Wirkungen mitbehandelt.

Der gemeinsame Nenner: Bei einem Agenten wird nicht Code ausgerollt, sondern Verhalten. Verhalten kann man nur vergleichen, wenn es versioniert ist, nur bewerten, wenn man den Pfad mitprüft, und nur zurücknehmen, wenn man seine Wirkungen kennt.