Lösung · AI Operations
Deine Prompts laufen in Produktion und niemand weiß mit Sicherheit, welche Version gerade arbeitet
Der Prompt ist das Stück, das das Verhalten deiner KI am stärksten bestimmt, und in fast jedem Unternehmen wird er von Hand editiert: ohne Review, ohne Historie, ohne Weg zurück. Wir bauen und betreiben die Funktion, die daraus ein versioniertes Artefakt macht, getestet bevor es hochgeht und in einer Minute reversibel.
Das Problem
Das Artefakt, das deine KI am stärksten steuert, ist das einzige, das niemand regiert
- Niemand kann mit Sicherheit sagen, welche Version des Prompts gerade ausgeliefert wird, wer sie zuletzt geändert hat und warum.
- Eine Änderung von einer Zeile geht direkt auf Produktion, weil es keine Umgebung gibt, in der man sie vorher an echten Fällen prüfen könnte.
- Fällt die Qualität, kommt man nicht zur Vorversion zurück: sie ist nirgends gespeichert, oder sie steckt im Verlauf irgendeines Chats.
- Derselbe Prompt liegt doppelt im Code, in einem Tool und in der Zwischenablage von jemandem, und jede Kopie driftet seit Monaten für sich weiter.
- Wenn der Anbieter das Modell aktualisiert, müssen Prompts geprüft werden, aber niemand weiß, welche es gibt, welche von diesem Modell abhängen und nach welchem Kriterium sie validiert wurden.
- Das Team fasst die Prompts nicht mehr an. Nicht weil sie gut sind: weil sie zu ändern Angst macht und niemand derjenige sein will, der an einem Donnerstag Produktion zerlegt.
Was es kostet, alles zu lassen
Du betreibst ein System, dessen wirksamstes Stück keine Änderungskontrolle hat. Die Kosten kommen von zwei Seiten gleichzeitig. Erstens die Regression, die niemand hat kommen sehen und die ein Kunde entdeckt. Und danach, teurer, die Lähmung: wenn den Prompt zu ändern eine Wette ist, fasst ihn das Team nicht mehr an und das System hört genau dann auf, besser zu werden, wenn der Markt anfängt sich zu bewegen. Dazu kommt eine dritte Front, sobald jemand von außen fragt: ohne Historie kannst du nicht rekonstruieren, welche Anweisungen dein System an dem Tag steuerten, an dem es eine konkrete Entscheidung getroffen hat.
Die Lösung
Wir bauen und betreiben das Änderungsmanagement deiner Prompts: Version, Test, stufenweiser Rollout und Weg zurück
- 1Wir inventarisieren und konsolidieren. Wir holen jeden Prompt da raus, wo er liegt —Code, Tools, Dokumente, Köpfe— und machen daraus ein Artefakt mit Kennung, Verantwortlichem, Version und Historie, mit einer einzigen Quelle der Wahrheit, aus der alle Umgebungen lesen.
- 2Wir trennen die Umgebungen und setzen ein Gate. Eine Änderung entsteht außerhalb von Produktion, läuft durch die Fallbatterie und geht nur hoch, wenn sie die vereinbarte Schwelle schafft. Dasselbe Gate für alle, keine Ausnahmen wegen Dringlichkeit: Dringlichkeit läuft über einen dokumentierten Schnellweg, nicht über das Umgehen der Kontrolle.
- 3Wir bauen die Testbatterie des Prompts: eine Sammlung echter und adversarialer Fälle, eingefroren und versioniert, die gegen jeden Kandidaten läuft und dessen Ausgabe mit der der lebenden Version vergleicht. Ohne Vergleich gegen die lebende Version bedeutet ein gutes Ergebnis nichts.
- 4Wir rollen stufenweise aus. Die neue Version geht zuerst auf einen Teil des Traffics, mit der alten parallel auf denselben Eingaben, und erst dann auf alles. Der Weg zurück ist ein Zeigerwechsel: eine Minute, ohne Code-Deployment und ohne Meeting.
- 5Wir betreiben die Funktion im Alltag: wer was ändern darf, was vor dem Hochgehen geprüft wird, was von jeder Änderung festgehalten wird, um sie später rekonstruieren zu können, und die geplante Revision jedes Mal, wenn der Anbieter das Modell darunter bewegt.
Was sich ändert
Was du nicht mehr verlierst
Die Frage, welche Version gerade läuft, wird von einer Ermittlung zu einer Abfrage: es gibt eine Kennung, eine Historie und einen Verantwortlichen pro Prompt in Produktion.
Mechanismus
Eine Änderung ist keine Wette mehr: sie wird vor dem Hochgehen an denselben Fällen gegen die lebende Version verglichen und geht stufenweise auf einen Teil des Traffics.
Mechanismus
Der Weg zurück hängt nicht mehr daran, dass sich jemand an den alten Text erinnert: es ist ein Zeigerwechsel auf eine gespeicherte Version, ohne Code-Deployment.
Mechanismus
Was wir messen: Zeit vom Erkennen einer Regression bis zum Rollback, % der Änderungen, die durch das Gate laufen, zurückgerollte Änderungen im Verhältnis zum Gesamten und Anzahl der Prompts in Produktion ohne identifizierten Verantwortlichen.
Was wir messen
Datenblatt
- Wegfallende Arbeit
- Prompts von Hand auf Produktion editieren, ohne Historie, ohne Vergleich gegen die lebende Version und ohne Weg zurück, wenn die Qualität fällt
- Übliche Einrichtung
- 4–8 Wochen
- Eingang
- ein Änderungsvorschlag an einem Prompt in Produktion: eine angepasste Anweisung, ein Modellwechsel oder eine Korrektur nach einem Vorfall
- Ausgang
- eine neue Version, gegen die Fallbatterie geprüft, mit der lebenden verglichen, stufenweise ausgerollt und in einer Minute reversibel, mit ihrem Protokoll von wer, wann und warum
- Kompatibel mit
- OpenAIAnthropicAzure OpenAIGoogle Vertex AILangSmithLangfusePromptfooBraintrustGitHub ActionsGitLab CI
- Kann sich verbinden mit
- Tu repositorio y tu circuito de revisión de códigoTus registros de producción, de donde salen los casos de pruebaTu función de evaluación continua de calidad, si ya la tienes montadaTu registro de trazabilidad y tu inventario de sistemas de IA
- Was wir messen
- Zeit vom Erkennen einer Regression bis zum Rollback% der Änderungen, die vor Produktion durch das Gate laufen% der zurückgerollten Änderungen am Gesamt der ausgerolltenPrompts in Produktion ohne identifizierten Verantwortlichen
- Geeignet für
- Unternehmen mit KI in Produktion und mehreren Personen, die Prompts anfassen —CIO, COO oder KI-Verantwortliche—, die schnell ändern können müssen, ohne etwas zu zerlegen, und belegen müssen, was das System zu welchem Zeitpunkt gesteuert hat
- Nicht geeignet für
- wer einen einzigen stabilen Prompt hat, der seit Monaten nicht angefasst wird, oder wer messen will, ob die Antwort des Agenten gut ist: das ist Qualitätsbewertung, eine andere und ergänzende Funktion
Häufig gestellte Fragen
Darin, was sie regieren. Die fortlaufende Bewertung misst, ob die Antwort deines Agenten heute gut ist: sie zieht Stichproben aus echten Gesprächen, bewertet sie gegen ein Kriterium und erkennt, dass die Qualität gefallen ist. Diese Funktion regiert die Änderung des Artefakts, das diese Antwort erzeugt: wo der Prompt lebt, wer ihn anfassen darf, welchen Test er vor dem Hochgehen bestehen muss, wie er ausgerollt wird und wie man zurückkommt. Sie ergänzen sich und funktionieren zusammen besser —Fallbatterie und Qualitätsmetriken speisen sich aus demselben—, aber sie lösen verschiedene Probleme: die eine sagt dir, dass etwas kaputtgegangen ist, die andere macht Kaputtmachen reversibel und selten.
Git ist das Fundament und wir nutzen es, aber allein löst es die Hälfte. Es gibt dir Historie und Review, und das ist schon mehr, als die meisten haben. Was es dir nicht gibt: eine Umgebung, in der du den Kandidaten vor dem Hochgehen an echten Fällen prüfst, den automatischen Vergleich gegen die Version, die live ist, den Rollout auf einen Teil des Traffics und den Weg zurück ohne Code-Deployment —genau das, was du um elf Uhr nachts brauchst—. Dazu kommt: in vielen Teams arbeitet die Person, die die besten Prompts schreibt, nicht im Repository, und sie für einen geänderten Satz durch einen Pull Request zu zwingen endet in der üblichen Parallelkopie.
Im Gegenteil: was heute bremst, ist die Angst. In Teams ohne Änderungskontrolle werden Prompts selten und mit angehaltenem Atem angefasst, weil jede Anpassung etwas zerlegen kann, das niemand bemerkt, bis sich ein Kunde beschwert. Wenn Testen Minuten kostet und Zurückgehen eine Minute, sinken die Kosten eines Fehlers so weit, dass die Leute wieder experimentieren. Das Gate ist nicht da, um Bürokratie hinzuzufügen: es ist da, damit die Änderung billig ist. Und für das wirklich Dringende gibt es einen dokumentierten Schnellweg, mit verpflichtender Nachprüfung.
Bauen wir es in deinem Betrieb?
Du hast das Problem benannt. Wir liefern die Lösung und lassen sie gemessen laufen.