MLOps für LLM-Anwendungen: Vom Prototyp zur Produktion

Der Pilot lief drei Wochen ohne größere Probleme. Der Assistent antwortete in etwa 1–2 Sekunden, Kunden beschwerten sich nicht, die Ergebnisse des Golden Sets sahen vielversprechend aus. Dann schlug jemand ein „kleines“ Modell-Update beim Anbieter und die Änderung einiger Sätze im System-Prompt vor. Das Deployment erfolgte am Freitagnachmittag. Am Montagmorgen stellte sich heraus, dass der Anteil der an Berater eskalierten Anfragen von 8 auf 23 Prozent gestiegen war und die Token-Kosten um 40 Prozent stiegen. Niemand wusste, welche Änderung dafür verantwortlich war, da beide gleichzeitig ohne Trennung eingeführt wurden.

Das ist ein klassisches Szenario, das wir bei Cashcrown regelmäßig sehen. LLMOps, also die operative Schicht für LLM-Anwendungen, existiert genau dafür, dass es solche Freitage nicht mehr gibt.

Im Prototyp ist das Modell der Hauptakteur. Man prüft, ob es überhaupt möglich ist, die interessierenden Fragen zu beantworten, testet ein Dutzend Prompts und ist von den Ergebnissen begeistert. In der Produktion wird das Modell zu einem von vielen Elementen eines Systems, das monatelang stabil laufen, unerwartete Anfragen bearbeiten und so viel kosten muss, wie geplant.

Der Unterschied liegt nicht in der Qualität des Modells. Er liegt in der Schicht, die es verwaltet.

Jede dieser Dimensionen kann in der Pilotphase übersprungen werden. In der Produktion bedeutet jede Auslassung ein Risiko. Den detaillierten Unterschied zwischen Pilot und Produktion erläutern wir im Artikel vom KI-Pilot zur Produktion.

Der größte Fehler, den wir beobachten, ist die separate Versionierung von Prompt und Modell. Wenn sich der Prompt um zwei Sätze ändert und das Modell von gpt-4o-2024-05-13 auf eine neuere Version wechselt, hat man de facto zwei Änderungen gleichzeitig. Wenn etwas schiefgeht, weiß man nicht, was man zurücknehmen soll.

Die Lösung ist einfach: Die gesamte Konfiguration erhält eine Versionsnummer. Ändert sich irgendetwas darin, gibt es eine neue Version, einen neuen Durchlauf des Gates und eine neue menschliche Entscheidung. Das Versionsartefakt enthält:

• vollständiger Text des System-Prompts und der Templates (kein Link zur Datei, sondern der Inhalt)
• exakte Modellkennung (nicht latest, kein generischer Name)
• Generierungsparameter: Temperatur, Top-p, Token-Limit
• Ausgabeschema, falls structured output verwendet wird
• Version der Wissensdatenbank oder des RAG-Index, mit der das System arbeitet
• Routing-Regeln, falls das Modell dynamisch durch einen Inference-Router ausgewählt wird

Jede Antwort in den Produktionslogs trägt diese Versionsnummer. Das ermöglicht es, innerhalb von Minuten zu beantworten, ob die Verschlechterung vor oder nach einem bestimmten Deployment begann. Ohne diese Information wird die Frage zu einer mehrstündigen Ermittlung. Das Muster beschreiben wir detailliert im Text über Versionsverwaltung von Prompts und Modellen.

Das Golden Set ist eine Sammlung repräsentativer Anfragen mit definierten Kriterien für gute Antworten. Das Regressions-Gate ist eine Regel: Kein Versionsartefakt gelangt in die Produktion, solange es nicht dieses Set mit einem Ergebnis durchlaufen hat, das nicht schlechter ist als die vorherige Version.

Den Aufbau des Golden Sets beginnen wir mit 80–150 realen Fällen aus den Logs, nicht mit erfundenen Beispielen. Wichtig ist, dass der Set schwierige, grenzwertige und historisch problematische Fälle enthält. Diese regressieren zuerst nach einer Prompt-Änderung.

Für jeden Fall definieren wir Akzeptanzkriterien. Selten ist es eine exakte Textübereinstimmung, häufiger eine Reihe von Fakten, die enthalten sein müssen, ein Format, an das man sich halten muss, oder eine Liste von Dingen, die nicht in der Antwort vorkommen sollten. Die automatische Bewertung funktioniert nach Schema, Regex oder LLM-as-Judge, kalibriert an menschlichen Bewertungen.

Die Ergebnisse des Gates sind nicht nur eine Gesamtzahl. Der Bericht zeigt das Ergebnis pro Anfragekategorie, Beispiele, die sich im Vergleich zur vorherigen Version verschlechtert haben, und die Delta zur Baseline. Ein Rückgang um 3–4 Prozentpunkte in einer Kategorie kann auf eine echte Verschlechterung für Kunden dieser Gruppe hinweisen, selbst wenn das Gesamtergebnis stabil erscheint.

Die Methode zum Aufbau des Golden Sets und zur Auswahl der Metriken beschreiben wir ausführlicher im Artikel wie man ein RAG-System evaluiert. Die Regeln sind identisch für agentenbasierte Systeme.

Die menschliche Entscheidung ist in dieser Phase verpflichtend. Das automatische Gate sagt „die Ergebnisse sind nicht schlechter“, aber es bewertet nicht, ob die inhaltlichen Änderungen im Prompt mit der Produktintention übereinstimmen. Das ist eine menschliche Entscheidung, keine Regel.

Der Offline-Regressionstest ist notwendig, aber nicht ausreichend. Der reale Traffic hat Verteilungen, die das Golden Set nicht vollständig abbildet. Daher durchlaufen große Änderungen – also Modell-Updates oder Umstrukturierungen des Prompts – einen Shadow- oder Canary-Prozess.

Shadow bedeutet, dass die neue Version parallel zur alten im realen Traffic läuft. Der Kunde erhält die Antwort von der alten Version, die neue generiert nur zum Vergleich. Keine Exposition, volle Daten über das Verhalten bei echten Anfragen. Shadow lassen wir mindestens 500–1000 Anfragen oder einige Tage laufen, abhängig vom Traffic-Volumen.

Canary leitet einen Teil des Traffics (meist 5–10 Prozent) auf die neue Version und vergleicht Qualitäts- und Business-Metriken zwischen beiden Gruppen. Die Durchlaufschwellen definieren wir im Voraus: Die neue Version übernimmt den gesamten Traffic nur, wenn sie die Schlüsselmetriken innerhalb eines definierten Zeitfensters nicht verschlechtert. Die Entscheidung trifft ein Mensch, kein Skript.

Beide Methoden kosten, weil man doppelte Aufrufe generiert. Für kleine Prompt-Anpassungen reicht meist der Offline-Regressionstest; Shadow und Canary behalten wir für Änderungen vor, bei denen das Risiko einer stillen Verschlechterung real ist. Dieselbe Logik gilt für Guardrails: Änderungen an Sicherheitsregeln sollten ebenfalls Shadow durchlaufen, bevor sie vollständig ausgerollt werden, da Nebenwirkungen offline schwer vorhersehbar sind.

Nach dem Deployment beginnt die kontinuierliche Überwachung. Drei Dimensionen, die gemeinsam gemessen werden, weil jede für sich unvollständig ist.

Qualität ist der Anteil der Antworten, die die Kriterien aus dem Golden Set erfüllen, übertragen auf eine Produktionsstichprobe, plus indirekte Signale: Eskalationsrate zum Menschen, Anteil der Anfragen, auf die das System mit „weiß ich nicht“ antwortet, und Nutzerbewertungen, wo sie erhoben werden. Ein Anstieg der Eskalationsrate um einige Prozentpunkte ist meist das erste Signal für Drift, bevor andere Indikatoren ein Problem anzeigen.

Kosten misst man pro bearbeitetem Ereignis, nicht als aggregierte Monatsrechnung. Die Monatsrechnung steigt mit dem Traffic und sagt nichts darüber aus, ob ein Kanal plötzlich doppelt so teure Antworten generiert, ohne Mehrwert. Die Kosten pro Ereignis sind die Zahl, bei der Anomalien sofort sichtbar werden. Einen detaillierten Ansatz zur Optimierung der LLM-Kosten beschreiben wir im Artikel über Monitoring von LLM-Kosten.

Latenz ist die Verteilung von p50 und p95, nicht der Durchschnitt. Der Durchschnitt verbirgt den langen Schwanz langsamer Antworten, die das Erlebnis von Kunden mit schwierigen Fragen beeinträchtigen. Observability in einem LLM-System bedeutet, jeden Aufruf mit Zeitstempel, Modell, Anzahl der Eingabe- und Ausgabetokens sowie der Versionsnummer des Artefakts zu loggen.

Wie man Metriken und Alarm-Schwellen wählt, um nicht in falschen Alarmen zu ertrinken, beschreiben wir in einem separaten Text über Monitoring der Qualität eines KI-Agenten.

Rollback ist kein Notfallplan. Er ist ein verpflichtender Bestandteil jedes Deployments. Bevor eine neue Version in die Produktion geht, hat man eine klare Antwort auf die Frage: „Was tun wir, wenn die Metriken in einer Stunde unter die Schwelle fallen?“

Die Antwort ist einfach, weil das Versionsartefakt ein Paket ist. Das Zurücksetzen bedeutet, den Zeiger auf die vorherige Version umzustellen, nicht den Prompt aus dem Gedächtnis neu zu schreiben. Es dauert weniger als eine Minute. Die vorherige Version muss einsatzbereit sein, nicht nur in der Git-Historie gespeichert.

Drei Auslösesignale für Rollback definieren wir im Voraus:

• die Eskalationsrate überschreitet die Schwelle um mehr als N Prozentpunkte für M Minuten
• die Kosten pro Ereignis steigen über das Limit für ein definiertes Zeitfenster
• die Latenz p95 überschreitet die SLA-Schwelle für eine kontinuierliche Zeit

Wenn eines dieser Signale aufleuchtet, trifft ein Mensch die Rollback-Entscheidung, aber der Mechanismus ist bereit. Es gibt keine stillen Modellwechsel, keine Deployments ohne Gate, kein „mal sehen, wie es läuft“. Jede Änderung hat einen Verantwortlichen und einen Rückweg.

Klassisches DevOps überwacht die Korrektheit des Codes: Unit-Tests, Integrationstests, Code-Reviews. MLOps für LLM überwacht die Korrektheit des Modellverhaltens, die sich nicht direkt aus dem Code ergibt. Der Prompt ist syntaktisch korrekt, kann sich aber nach einer kleinen Änderung anders verhalten. Deshalb braucht man neben Code-Tests ein Evaluierungs-Gate mit Golden Set, Shadow und Canary statt einfachem Deployment und kontinuierliches Qualitätsmonitoring im Produktions-Traffic.

Wir beginnen mit 80–150 Fällen aus realen Logs oder Meldungen, nicht mit erfundenen Beispielen. Wichtiger als die Anzahl ist die Repräsentativität: Der Set soll die Hauptklassen von Fragen, Grenzfälle und historisch problematische Fälle abdecken. Jeder neue Vorfall in der Produktion ist ein Kandidat für die Aufnahme ins Golden Set. Der Set wächst mit dem System.

Ja. Die Basisversion besteht aus Versionsverwaltung der Artefakte in Git oder einem einfachen Register, einem Testskript für das Golden Set in CI, Logs der Aufrufe in PostgreSQL oder einer JSONL-Datei und einem Dashboard mit einigen Diagrammen. Kommerzielle MLOps-Plattformen beschleunigen den Prozess, sind aber keine Voraussetzung. Entscheidend ist die Prozessdisziplin: Gate vor dem Deployment, menschliche Entscheidung, vorbereiteter Rollback.

Verwende die exakte Versionskennung des Modells statt eines generischen Namens oder des latest-Tags. Wenn der Anbieter keine Kennung bereitstellt, führe das Golden Set regelmäßig aus, auch ohne eigene Änderungen. Stiller Drift seitens des Anbieters ist eine der häufigsten Ursachen für Regressionen, die wochenlang unentdeckt bleiben.

Für kleine Prompt-Änderungen, bei denen Format oder Ton angepasst werden, reicht meist der Offline-Regressionstest mit dem Golden Set. Shadow und Canary behalten wir für Modellwechsel, Umstrukturierungen des Prompts oder Aktualisierungen der Wissensdatenbank in großem Umfang vor. Regel: Je größer der Umfang der Änderung und je schwieriger die Nebenwirkungen vorhersehbar sind, desto eher ist ein kostspieliges Shadow statt eines einfachen Offline-Gates gerechtfertigt.