Versionsverwaltung von Prompts und Modellen: Regressionstests und Änderungskontrolle in KI

In klassischer Software „zerstört“ eine „kleine Änderung“ an einer Stelle selten eine Funktion zehn Bildschirme weiter. In KI-Systemen passiert das — und zwar oft. Du änderst einen Satz im Prompt, damit der Assistent „prägnanter“ wird, und eine Woche später stellt sich heraus, dass er keine Vorgangsnummern mehr angibt, weil er auch diese Passagen gekürzt hat. Wir behandeln Prompt und Modellkonfiguration wie Produktionscode: Wir versionieren sie, testen vor jedem Deployment auf Regression und halten einen Rückweg bereit. Ohne diese Disziplin sind Änderungen in KI ein Roulette, bei dem du den Gewinn sofort siehst, den Verlust aber erst durch Kundenbeschwerden.

Ein Prompt ist keine Konfiguration, sondern ein Programm in natürlicher Sprache, und das Modell reagiert auf dieses Programm auf nicht intuitive Weise empfindlich. Das Verschieben einer Formatierungsanweisung vom Ende an den Anfang, das Hinzufügen eines Beispiels, das Ändern des Wortes „beschreibe“ in „liste auf“ — jede dieser Änderungen kann das Verhalten des Modells in einer ganzen Klasse von Abfragen verschieben, nicht nur in der einen, die du manuell getestet hast. Du prüfst drei Fälle, sie sehen besser aus, du deployst — und weißt nicht, dass die Qualität in einer vierten Abfrageklasse gesunken ist.

Die zweite Falle ist eine Änderung, die du nicht selbst vorgenommen hast. Der Modellanbieter aktualisiert die Version unter demselben Namen, die Standardtemperatur ändert sich, die Bibliothek setzt Nachrichten anders zusammen. Das System, das du nicht angerührt hast, beginnt anders zu antworten. Deshalb sind das Festpinnen der Modellversion und die gespeicherte Konfiguration genauso wichtig wie die Versionsverwaltung des Prompts — du kontrollierst nicht nur deine eigenen Änderungen, sondern auch die anderer. Ohne Golden Set und Regressionstest erkennst du einen solchen stillen Drift erst, wenn jemand die Beschwerden zählt.

Versionsverwaltung in KI endet nicht beim Prompt-Text. Die Antwort des Modells ist eine Funktion mehrerer Dinge gleichzeitig, und jeder davon muss einen gespeicherten Wert haben, sonst kannst du nicht reproduzieren, warum es gestern funktionierte und heute nicht. Wir behandeln diesen gesamten Satz als ein Artefakt mit einer Versionsnummer: Die Änderung eines beliebigen Feldes bedeutet eine neue Version und einen neuen Testlauf.

Der Schlüssel liegt darin, all diese Felder in eine unteilbare Version zu verknüpfen. Wenn du den Prompt getrennt vom Modell versionierst, weißt du im Fehlerfall nicht, welches Paar du zurücksetzen musst. Wir vergeben der gesamten Konfiguration eine Versionsnummer und kennzeichnen jede Antwort in den Logs mit dieser Nummer — dann lässt sich aus der Produktion genau rekonstruieren, was das jeweilige Ergebnis erzeugt hat. Denselben Ansatz beschreiben wir ausführlicher bei der Auswahl des LLM für die Aufgabe.

Das Golden Set ist eine Sammlung repräsentativer Abfragen mit markierten erwarteten Ergebnissen oder Akzeptanzkriterien. Es dient als Sicherheitsnetz, das Regressionen abfängt, bevor sie den Kunden erreichen. Die Regel ist einfach: Keine Änderung am Prompt oder Modell geht in die Produktion, bis sie die Regressionstests auf dem aktuellen Golden Set bestanden hat und die Ergebnisse mit der Baseline der vorherigen Version verglichen wurden. Den Aufbau eines solchen Sets und die Auswahl der Metriken vertiefen wir im Text darüber, wie man ein RAG-System evaluiert, und die Messung der Korrektheit der Ausgaben im Artikel zur Validierung von LLM-Ausgaben.

Das Golden Set beginnen wir mit 50-100 realen Abfragen aus Logs oder Meldungen, nicht mit am Schreibtisch erfundenen Beispielen — letztere sind zu regelmäßig und spiegeln nicht die Sprache der Nutzer wider. Für jede Abfrage definieren wir, wie eine gute Antwort aussieht: Manchmal ist es ein exaktes Ergebnis, häufiger eine Reihe von Fakten, die enthalten sein müssen, und ein Format, an das man sich halten muss. Wichtig ist, dass im Set auch schwierige und Grenzfälle enthalten sind — sie regressieren als Erstes. Der Test wird bei jeder Änderung ausgeführt und der Prozentsatz der bestandenen Abfragen mit der vorherigen Version verglichen; ein Rückgang um auch nur wenige Punkte ist ein Signal, das Deployment zu stoppen.

Die Bestandszahlen reichen nicht ohne Kontext, daher verknüpfen wir das Ganze mit Observability: Jeder Durchlauf speichert die Version, das Ergebnis pro Abfragekategorie und Beispiele, die sich verschlechtert haben. Dann siehst du statt „die Qualität ist gesunken“ konkret: „Die Klasse der Fragen zu Zahlungsterminen ist nach der Template-Änderung von 88 auf 71 Prozent gefallen“ — und weißt, was du zurücksetzen musst.

Der Offline-Regressionstest fängt vieles ab, aber nicht alles — der reale Traffic hat Verteilungen, die du im Golden Set nicht abbildest. Deshalb führen wir Änderungen am Modell oder größere Prompt-Versionen schrittweise ein. Shadow-Modus bedeutet, die neue Version parallel zur alten laufen zu lassen: Der Kunde sieht weiterhin die Antwort der bisherigen Version, und die neue generiert das Ergebnis „im Schatten“, nur zum Vergleich. Null Risiko für den Nutzer, und du sammelst Daten darüber, wie sich die neue Version im echten Traffic verhält, bevor du etwas umschaltest.

A/B geht einen Schritt weiter: Du leitest einen Teil des Traffics, zum Beispiel 5-10 Prozent, auf die neue Version und vergleichst Qualitäts- und Business-Metriken zwischen beiden Gruppen. Das ist die Phase, in der Dinge sichtbar werden, die offline unsichtbar sind — Antwortzeit, Kosten, Nutzerreaktionen. Die Übergangsschwelle definieren wir im Voraus: Die neue Version übernimmt den gesamten Traffic nur, wenn sie die Schlüsselmetriken im Vergleich zur alten nicht verschlechtert. Dieselbe Logik wenden wir beim Routing von Anfragen an, wo eine Änderung der Klassifizierungsschwelle das Verhalten ebenfalls still verschieben kann.

Fairer Hinweis: Shadow und A/B kosten, weil du Antworten doppelt generierst oder zwei Pfade betreibst. Für kleine Prompt-Änderungen reicht meist der Offline-Regressionstest; Shadow und A/B reservieren wir für Modelländerungen und größere Prompt-Umbauten, wo das Risiko real ist. Es ist ein Kompromiss zwischen Sicherheit und Kosten, keine Prozedur für jeden Tippfehler.

Der letzte Pfeiler ist die Spur und der Rückweg. Das Änderungsprotokoll beantwortet die Frage „was und wann hat sich geändert“: Versionsnummer, Datum, Autor, welche Felder betroffen waren, Ergebnis des Regressionstests und die Entscheidung zum Deployment. Ohne das beginnt die Diagnose eines Fehlers mit Archäologie — wer, was und warum vor drei Wochen geändert hat. Mit dem Protokoll beginnt sie mit einer Frage: „Welche Version wurde kurz vor dem Metrikabfall deployed“, und die Antwort liegt auf der Hand.

Der Rollback muss vorbereitet sein, bevor du ihn brauchst. Da die gesamte Konfiguration eine Versionsnummer hat, ist das Zurücksetzen das Umschalten auf die vorherige, geprüfte Version — Sekunden, nicht Stunden des Prompt-Neuschreibens aus dem Gedächtnis. Wir halten die vorherige Version einsatzbereit und definieren klar, was den Rollback auslöst: Qualitätsmetrik unter Schwelle, Kostensprung oder Anstieg der Beschwerden. Dasselbe Denken wenden wir im laufenden Monitoring der Agentenqualität an, wo ein Alert mit einem vorbereiteten Rollback verknüpft ist. Das Ziel ist eins: Jede Änderung im KI-System muss umkehrbar und dokumentiert sein, damit eine „kleine Änderung“ nie eine Einbahnstraße wird.

Ja, und aus demselben Grund wie Code: Der Prompt steuert das Verhalten eines Produktionssystems, und seine Änderung hat reale Auswirkungen. Der Unterschied ist, dass der Prompt empfindlicher ist — das Verschieben eines Satzes kann Antworten in einer ganzen Abfrageklasse ändern. Ohne Versionsnummer und Protokoll lässt sich nicht rekonstruieren, was und wann das Verhalten geändert hat, und die Fehlerdiagnose wird zum Ratespiel.

Wir beginnen meist mit 50-100 realen Abfragen und erweitern es, sobald neue Fehlertypen aus der Produktion auftauchen. Wichtiger als die Anzahl ist die Repräsentativität: Das Set soll die Hauptklassen von Fragen sowie schwierige und Grenzfälle abdecken, denn diese regressieren zuerst. Jeder neue Vorfall in der Produktion ist ein Kandidat für die Aufnahme ins Golden Set, damit derselbe Fehler nicht unbemerkt wiederkehrt.

Weil der Offline-Test auf einem Set misst, das du selbst definiert hast, während der reale Traffic Verteilungen und Formulierungen enthält, die darin nicht vorkommen. Shadow lässt die neue Version im echten Traffic laufen, ohne den Kunden zu exponieren, und fängt so Drifts ab, die im Golden Set unsichtbar sind, bevor du etwas umschaltest. Es ist eine Ergänzung zum Regressionstest, kein Ersatz — der eine schützt vor bekannten Fehlern, der andere vor unbekannten.

Ja, und das ist eine der häufigsten stillen Quellen für Regressionen. Der Anbieter kann das Modell unter demselben Namen ändern, und das System, das du nicht angerührt hast, beginnt anders zu antworten. Deshalb pinnen wir die genaue Modellversion statt des Labels „latest“ und führen regelmäßig das Golden Set aus, um Drifts zu erkennen, auf die wir keinen direkten Einfluss haben.

Die Rückkehr zur vorherigen Version sollte eine Frage von Sekunden sein, nicht von Stunden — deshalb hat die gesamte Konfiguration eine Versionsnummer, und die vorherige, geprüfte Version wird einsatzbereit gehalten. Wir definieren im Voraus, was den Rollback auslöst: Qualitätsmetrik unter Schwelle, Kostensprung oder Anstieg der Beschwerden. Je früher du diese Bedingungen festlegst, desto weniger Entscheidungen triffst du unter Druck während eines Ausfalls.