Produktionsqualität, Drift & Feedback
Fehlerrate und Latenz sind grün, doch Nutzer beschweren sich über schlechtere Antworten. Ohne Referenzfenster, Laufzeit-Provenienz und eine gezielte Stichprobe bleiben Input-Drift, Modellwechsel und echte Regression ununterscheidbar.
Lehrtext · 12 Abschnitte · zuletzt geprüft: 2026-09-04
Das Grundproblem: Betrieb ohne Ground-Truth
Beim Bauen eines LLM-Systems misst du Qualität gegen ein Eval-Set mit bekannten richtigen Antworten. In Produktion hast du das fast nie: Niemand labelt jede Live-Antwort auf Korrektheit. Du siehst Millionen Ausgaben — und weißt bei keiner sicher, ob sie stimmt.
Trotzdem kann die Qualität jederzeit kippen: Nutzer fragen plötzlich anders, ein Index veraltet, ein Deploy rutscht durch, der Provider tauscht still das Modell. Deine Aufgabe im Betrieb ist nicht, Korrektheit zu messen — das kannst du live nicht —, sondern Degradation früh zu erkennen und ihre Ursache einzugrenzen.
Betriebsprobe: PROXY-METRICS
Szenario
Euer LLM-Feature extrahiert aus eingehenden E-Mails strukturierte Felder als JSON und schreibt sie in ein Ticketsystem. Rund 20.000 Aufrufe pro Tag. In Produktion prüft niemand die Antworten auf Korrektheit — es gibt keine Labels. Ihr wollt ein Frühwarnsignal, das ausschlägt, wenn die Qualität kippt, bevor die Fachabteilung es merkt.
Anforderungen
- Worauf setzt ihr als primäres Monitoring?
- Bewerte Ursache, wirksame Grenze und den Preis der tragfähigen Maßnahme getrennt.
Schritte
- Tragfähiger Ansatz: Ein Bündel label-freier Proxys als Dashboard mit Alarmen: Anteil schema-valider JSON-Antworten, Refusal-/Abstain-Rate, Antwortlänge-Verteilung, Retrieval-Leerquote. Richtig. Diese Signale sind billig, deterministisch, brauchen kein Label und kein zweites Modell — und sie kippen messbar, bevor Beschwerden eintreffen. Ein Einbruch im Format-Valid-Anteil oder ein Refusal-Spike zeigt eine Störung, ohne dass ihr Korrektheit kennen müsst.
- Plausibler Fehlweg: Nur klassische Service-Metriken: Latenz, HTTP-Fehlerrate, Verfügbarkeit. Nötig, aber blind für inhaltliche Qualität. Ein zu 100 % verfügbarer, schneller Dienst kann trotzdem still schlechteres oder falsch strukturiertes JSON liefern — die Service-Ebene bemerkt das nie.
- Plausibler Fehlweg: Die Beschwerde-/Ticket-Rate der Fachabteilung als Qualitätssignal. Ein nachlaufendes und verzerrtes Signal: Die meisten unzufriedenen Fälle werden nie gemeldet, und wenn doch, erfahrt ihr es Tage später. Als Frühwarnung ungeeignet — genau das, was ihr vermeiden wollt.
- Plausibler Fehlweg: Jede Live-Antwort von einem zweiten LLM als Judge auf Korrektheit scoren lassen. Teuer und langsam als Always-on-Signal: ein zweiter Modell-Aufruf pro Request, und der Judge ist selbst ein ungelabelter, driftender Proxy, der erst validiert werden müsste. Judge-Design gehört in den Eval-Track — nicht die billige erste Beobachtungslinie im Betrieb.
Merksatz: In Produktion fehlt Ground-Truth. Qualität misst man dort nicht direkt, sondern über billige, deterministische Signale, die mit ihr korrelieren und kippen, bevor Labels je entstünden. Ein Proxy ersetzt keine Korrektheit — er warnt. + Always-on, kostengünstig, kein Label und kein zweites Modell nötig. − Proxys korrelieren nur mit Qualität: Sie können ausschlagen ohne echtes Problem (Fehlalarm) oder eine Regression verpassen, die Format und Länge nicht berührt — bestätigt wird ein Verdacht mit einer Stichprobe oder im Eval-Track.
Proxy-Signale: Qualität ohne Labels beobachten
Ein Proxy ist ein billiges, deterministisches Signal, das mit Qualität korreliert — ohne selbst Korrektheit zu sein. Es kippt oft, bevor Beschwerden eintreffen, und braucht kein Label und kein zweites Modell.
- Refusal-/Abstain-Rate
- Anteil Antworten, die verweigern oder ausweichen — steigt bei ungedecktem Scope
- Format-Valid-Anteil
- Anteil schema-/formatkonformer Antworten (z. B. valides JSON) — bricht bei Generierungs-Störung ein
- Antwortlänge-Verteilung
- sprunghaft kürzer/länger = etwas hat sich am Generierungs-Pfad verschoben
- Retrieval-Leerquote
- Anteil Anfragen ohne brauchbaren Treffer — Frühindikator für ungedeckte Themen
- Latenz / Fehlerrate
- klassische Service-Signale — nötig, aber blind für inhaltliche Qualität
Proxys sind Frühwarnung, kein Urteil: Sie können ausschlagen ohne echtes Problem (Fehlalarm) oder eine Regression verpassen, die Format und Länge gar nicht berührt. Bestätigt wird ein Verdacht mit einer Stichprobe oder im Eval-Track — nicht vom Proxy allein.
Betriebsprobe: BASELINE-REFERENCE
Szenario
Ihr wollt „auf Drift alarmieren“. In der Runde stehen mehrere Vorschläge, wie der Alarm definiert wird. Das System hat spürbare Wochen-Saisonalität (werktags anders als am Wochenende), und ihr wollt sowohl plötzliche Sprünge als auch schleichende Verschlechterung fangen.
Anforderungen
- Wie definiert ihr den Drift-Alarm?
- Bewerte Ursache, wirksame Grenze und den Preis der tragfähigen Maßnahme getrennt.
Schritte
- Tragfähiger Ansatz: Eine feste, repräsentative Referenzverteilung bestimmen (historisches Fenster, saisonal berücksichtigt) und die aktuelle Verteilung dagegen vergleichen; Alarm bei signifikanter Abweichung. Richtig. Drift ist ein Vergleichsbegriff — erst der stabile, repräsentative Anker macht „aktuell vs. normal“ definiert und den Alarm reproduzierbar und system-spezifisch. Er fängt sowohl Sprünge als auch schleichende Abweichung, weil die Referenz nicht mitwandert.
- Plausibler Fehlweg: Eine feste absolute Schwelle setzen, z. B. Refusal-Rate > 10 % — anschließend ohne Kontrollgruppe als automatisches Freigabe- und Rollbacksignal verwendet und ohne getrennte Prüfung von Saisonalität, Datenänderung oder Laufzeitversion dauerhaft beibehalten. Eine absolute Grenze ignoriert, was für *euer* System normal ist: 10 % können Baseline-Normalzustand oder Katastrophe sein. Ihr bekommt Dauer-Fehlalarm oder blinde Flecken — und eine Drift unterhalb der Schwelle seht ihr nie.
- Plausibler Fehlweg: Immer die aktuelle Woche gegen die Vorwoche vergleichen. Ein mitlaufendes Kurzfenster übersieht schleichende Drift: Verschlechtert sich das System langsam, wandert die Referenz mit — der Frosch merkt das langsame Kochen nicht. Zudem erbt der Vergleich die Wochen-Saisonalität als Rauschen.
- Plausibler Fehlweg: Alarmieren, wenn eine Kennzahl im Dashboard „ungewöhnlich aussieht“, und sonst manuell draufschauen. Nicht reproduzierbar und nicht always-on: Ohne definiertes Normal gewöhnt ihr euch an kriechende Drift und überseht sie. „Sieht komisch aus“ ist kein Alarm, sondern ein Zufallsfund.
Merksatz: „Drift“ ist ohne fixierte Referenzverteilung undefiniert — es ist ein Vergleich. Der Anker muss repräsentativ und stabil sein: Ein mitlaufendes Fenster übersieht schleichende Drift, eine absolute Schwelle ignoriert, was für dein System normal ist. + Macht Alarme reproduzierbar und system-spezifisch und fängt auch langsame Verschlechterung. − Die Baseline muss gepflegt werden — repräsentativ bleiben, Saisonalität abbilden, nach einer gewollten Änderung bewusst neu gesetzt werden; eine veraltete oder verzerrte Referenz erzeugt Dauer-Fehlalarm oder blinde Flecken.
Baseline: ohne Referenz ist „Drift“ undefiniert
Drift heißt: Die aktuelle Verteilung weicht von einem früheren Normalzustand ab. Das ist ein Vergleichsbegriff — ohne festgelegte Referenzverteilung gibt es kein „Drift“, nur eine Zahl ohne Bedeutung.
- Referenz = ein repräsentatives historisches Fenster (saisonal bereinigt) oder ein Shadow-/Holdout-Lauf, gegen das du die Gegenwart vergleichst.
- Absolute Schwelle allein (z. B. „Refusal > 10 %“) ignoriert, was für *dein* System normal ist — mal Dauer-Fehlalarm, mal blinder Fleck.
- Mitlaufendes Kurzfenster (heute vs. gestern) übersieht schleichende Drift: Die Referenz wandert mit der Degradation mit — der Frosch merkt das langsame Kochen nicht.
Betriebsprobe: INPUT-DRIFT
Szenario
Euer Support-Bot (RAG über einen Produkt-Wissensbestand) läuft seit Monaten stabil. Über zwei Wochen steigt die Refusal-Rate von 4 % auf 12 %, die Retrieval-Leerquote zieht mit. Kein Deploy, Prompt, Modell und Retrieval-Config sind unverändert. Vor drei Wochen hat das Unternehmen ein neues Produkt gelauncht.
Anforderungen
- Was ist der nächste Schritt, um die Ursache einzugrenzen?
- Bewerte Ursache, wirksame Grenze und den Preis der tragfähigen Maßnahme getrennt.
Schritte
- Tragfähiger Ansatz: Die aktuelle Eingabe-Verteilung gegen ein historisches Baseline-Fenster halten — Themencluster, Sprachmix, Query-Länge. Richtig. Bei nachweislich unverändertem System ist eine verschobene Eingabe-Verteilung die wahrscheinlichste Ursache. Der Vergleich deckt vermutlich einen Schwung Anfragen zum neuen Produkt auf, das der Wissensbestand noch nicht abdeckt — genau das treibt Refusals und Leerquote.
- Plausibler Fehlweg: Prompt und Modell anpassen, bis die Refusal-Rate wieder sinkt — anschließend ohne Kontrollgruppe als automatisches Freigabe- und Rollbacksignal verwendet. Das System hat sich nicht geändert — blindes Nachschrauben behandelt ein Symptom, dessen Ursache in den Eingaben liegt, und riskiert, die 88 % zu verschlechtern, die weiterhin funktionieren.
- Plausibler Fehlweg: Einen stillen Provider-Modellwechsel vermuten und beim Provider eskalieren. Möglich, aber die falsche Reihenfolge: Ihr überspringt die billigere, wahrscheinlichere lokale Erklärung. Ohne die Eingaben oder eine Output-Baseline auf stabilen Inputs geprüft zu haben, ist die Eskalation ein Ratespiel.
- Plausibler Fehlweg: Den Wissensbestand pauschal vergrößern und mehr Quellen crawlen. Aktionismus ohne Diagnose: Solange ihr nicht wisst, welche Anfragen gedriftet sind, trefft ihr das eigentliche neue Thema vielleicht gar nicht — und verrauscht den Index für die Fälle, die heute laufen.
Merksatz: Sinkt die Qualität, während System (Prompt, Modell, Config) unverändert ist, hat sich meist die Welt geändert, nicht das Modell — die Eingabe-Verteilung ist erste Verdächtige. Und Drift erkennt man nur gegen eine Baseline, nie an einer nackten Zahl. + Findet die häufigste Ursache ohne riskante Systemänderung und ist billig zu prüfen. − Input-Drift zu erkennen sagt noch nicht, was zu tun ist — Wissensbestand erweitern, Routing, Scope-Grenze kommunizieren; und die Detektion braucht gepflegte Baseline-Fenster und Schwellen, sonst drohen Fehlalarme.
Input-Drift: meist ändert sich die Welt, nicht dein Modell
Wenn die Qualität sinkt, aber Prompt, Modell und Config unverändert sind und kein Deploy lief, hat sich meist die Eingabe-Verteilung verschoben — nicht das System. Neue Themen (ein frisch gelaunchtes Feature), eine neue Sprache, deutlich längere oder kürzere Anfragen: Das Modell wird mit etwas konfrontiert, wofür Wissensbestand oder Prompt nicht ausgelegt sind.
Erkannt wird Input-Drift, indem du die aktuelle Eingabe-Verteilung gegen die Baseline hältst: Themencluster, Sprachmix, Query-Länge. Ein steigender Refusal- oder Retrieval-Leerquoten-Proxy zeigt oft genau hierhin.
Output-Drift: das Symptom auf der Ausgabe-Seite
Output-Drift ist die Kehrseite: die Ausgabe-Verteilung verschiebt sich — Refusal-Spike, Tonwechsel, Längensprung, weniger valides Format. Entscheidend ist die Kombination mit den Inputs: Verschiebt sich der Output, während die Eingaben nachweislich stabil sind, liegt die Änderung im Generierungs-Pfad.
Output-Drift ist ein Symptom, keine Ursache. Sie sagt dir *dass* sich etwas geändert hat, nicht *was*. Und nicht jede Output-Drift ist schlecht — ein gewollter Prompt-Fix verschiebt die Verteilung ebenfalls. Deshalb: gegen eine Output-Baseline quantifizieren und mit der eigenen Change-Historie verknüpfen.
Stiller Modellwechsel: was du nicht pinnst, kontrolliert ein anderer
Ein Sonderfall der Output-Drift ohne eigenen Deploy: Der Provider aktualisiert das Modell hinter derselben API-Bezeichnung. Gleiche Schnittstelle, anderes Verhalten — dein Produktionsverhalten ändert sich, ohne dass du etwas ausgerollt hast. Dass sich das Verhalten gehosteter Modelle über die Zeit messbar verschiebt, ist dokumentiert.
- Erkennen: eine Output-Baseline auf stabilen Referenz-Inputs laufen lassen — springt sie ohne eigenen Change, ist ein externer Wechsel die naheliegende Erklärung.
- Begegnen: die Modell-Version pinnen statt auf einem
latest-Alias zu fahren. Pinning kauft dir Kontrolle über den Zeitpunkt der Änderung. - Preis: gepinnte Versionen werden irgendwann deprecatet — du musst ohnehin migrieren, nur zu *deinem* Zeitpunkt; und Verbesserungen/Fixes ziehst du bewusst nach, statt sie geschenkt zu bekommen.
Regressions-Triage: „seit gestern schlechter“ — ohne Labels
Der häufigste Alltag: Jemand leitet zwei schlechte Antworten weiter und sagt „der Bot ist schlechter geworden“. Ohne Labels triagierst du in zwei Schritten — erst ob, dann was.
Abgrenzung & gleich im Check
Dieses Modul ist reine Laufzeit-Beobachtung: Signale und Drift im laufenden Betrieb erkennen und triagieren. Wie du ein Eval-Set baust, einen LLM-Judge entwirfst, Metriken auswählst oder Offline gegen Online abwägst, lehrt der Track `llmops/evaluation` — hier wird das nicht gedoppelt. Ein Proxy warnt; bestätigt wird eine Regression dort.
Du kennst jetzt die Achsen: Proxy-Metriken, Baseline als Alarm-Voraussetzung, Input-Drift, Output-Drift, stiller Modellwechsel und Regressions-Triage.
Warum der Kreis geschlossen werden muss
Alle vorherigen Module erzeugen Signale: Traces, Proxymetriken, Vorfälle, Rückmeldungen. Ohne einen Rückweg in die Verbesserung bleiben sie Beobachtung. Der Rückweg ist zugleich die einzige Quelle für Testfälle, die wirklich vorkommen — kein ausgedachtes Testset trifft die Verteilung echter Nutzeranfragen.
llmops im Evaluations-Modul. Hier geht es um den Betriebspfad: aus Produktionsverkehr Material gewinnen, es rechtssicher halten und es dauerhaft pflegen.Welche Fälle wertvoll sind
Zufällig gezogener Verkehr besteht überwiegend aus einfachen, gelungenen Fällen — er bestätigt, was ohnehin funktioniert. Wertvoll für eine Regressionssuite ist gezielt das Gegenteil.
- Fälle aus Vorfällen: jede Regression, die in Produktion durchkam, gehört als Testfall zurück.
- Negative Rückmeldungen und abgebrochene Sitzungen.
- Formal ungültige oder verweigerte Antworten.
- Anfragen mit leerem oder schwachem Retrieval-Ergebnis.
- Seltene, aber geschäftskritische Anfrageklassen, die im Zufallsverkehr untergehen.
Bewertungsarbeit ist die knappe Ressource
Aus Verkehr wird erst dann ein Testfall, wenn eine erwartete Eigenschaft festgehalten ist. Diese Arbeit ist menschlich und teuer, also muss sie priorisiert werden — nach Häufigkeit der Anfrageklasse, nach Schadenspotenzial und nach Unsicherheit des aktuellen Verhaltens.
Nicht jeder Testfall braucht eine perfekte Musterantwort. Oft genügt eine überprüfbare Eigenschaft: Diese Antwort muss ein bestimmtes Feld enthalten, darf keine Zusage machen, muss auf die richtige Quelle verweisen. Solche Eigenschaften sind billiger festzuhalten und altern langsamer als eine wörtliche Referenz.
Aufbewahrung, Einwilligung, Zweckbindung
Produktionsverkehr enthält personenbezogene und vertrauliche Kundendaten. Sobald du daraus ein dauerhaftes Testset baust, verlässt du die Aufbewahrungsfrist des Betriebssystems und schaffst eine zweite, langlebige Kopie — das ist eine eigene Verarbeitung mit eigenem Zweck und eigener Rechtsgrundlage.
- Aufbewahrung
- Testfälle überdauern Trace-Fristen. Das muss ausdrücklich geregelt und begrenzt sein.
- Zweck
- Beobachtung und dauerhafte Weiterverwendung sind nicht derselbe Zweck.
- Löschverlangen
- Ein Löschauftrag muss auch die abgeleiteten Testfälle erreichen — also braucht jeder Fall eine Herkunftskennung.
- Mandantengrenze
- Inhalte eines Kunden dürfen nicht zur Grundlage einer Verbesserung für alle werden, wenn das nicht vereinbart ist.
Eine Regressionssuite verliert ohne Pflege ihren Wert: Testfälle veralten mit dem Produkt, Erwartungen werden durch bewusste Änderungen ungültig, und eine Suite, die dauernd rot ist, wird ignoriert — genau wie ein verrauschter Alarm.
- Fehlschläge müssen unterschieden werden: echte Regression oder überholte Erwartung.
- Jede bewusste Produktänderung erzeugt Pflegeaufwand an der Suite — das gehört in die Aufwandsschätzung.
- Die Suite spiegelt die Verteilung von gestern; sie braucht regelmäßigen Nachschub aus aktuellem Verkehr.
- Ein Testfall, dessen Erwartung niemand mehr begründen kann, gehört entfernt, nicht angepasst, bis er grün wird.
Jetzt anwenden
Diesen Stoff gibt es als Modul mit bewerteten Entscheidungs-Checks — dieselbe Einführung, danach die Übungen.
Zum Modul →