Das Dashboard ist grün, das System liegt falsch

Die ehrliche Antwort gleich vorweg: In einem LLM-System zählt am Ende nur die Antwortqualität — und ausgerechnet die kann Ihre Infrastruktur nicht für Sie messen. Verfügbarkeit, Latenz, Fehlerrate: Alles, was ein normaler Monitoring-Stack mitliefert, misst die Leitungen. Ein Modell, das seit drei Wochen aus einer veralteten Handbuchversion zitiert, ist aus Sicht Ihres Servers eine völlig gesunde Anfrage.

Beim KI-Monitoring geht es deshalb nicht darum, Grafana auf den richtigen Endpunkt zu richten, sondern darum, eine Referenzwahrheit bewusst herzustellen — weil sie sonst schlicht nicht entsteht. Wer diesen Schritt überspringt, landet im ungünstigsten aller Zustände: einer Wand aus grünen Kennzahlen, die Sicherheit suggeriert, während das System nachlässt. Blindflug ist überlebbar. Blindflug im Vertrauen auf die Instrumente nicht.

Die Faustregel. Wenn Ihr KI-Monitoring exakt gleich aussähe, egal ob das Modell brillant antwortet oder Unsinn produziert, überwachen Sie nicht die KI. Sie überwachen den Webserver, auf dem sie zufällig läuft.

Fünf Signale, auf die sich KI-Monitoring reduziert

Sie brauchen kein großes Observability-Programm. Sie brauchen fünf Zahlen im Zeitverlauf — und jemanden, der sie ansieht.

Qualität, gemessen an einem Golden Set

Nehmen Sie 50 bis 200 echte Fälle aus Ihrem tatsächlichen Datenverkehr, legen Sie einmal fest, was die richtige Antwort ist, und lassen Sie diese Fälle turnusmäßig und vor jeder Änderung erneut laufen. Mehr ist es nicht. Das ist unspektakulär, es funktioniert, und es ist das einzige der fünf Signale, das misst, worauf es Ihnen wirklich ankommt. Der schwierige Teil ist nicht die Technik, sondern dass sich jemand mit Fachwissen hinsetzen und für jeden Fall entscheiden muss, was „richtig“ bedeutet. Dieser Nachmittag macht niemandem Freude. Es ist der wirksamste Nachmittag im ganzen Projekt. Wie Sie so ein Set aufbauen und auswerten, ist ein Thema für sich — dazu habe ich separat geschrieben, wie sich LLM-Systeme evaluieren lassen.

Retrieval-Trefferquote — das billigste Signal, das niemand protokolliert

Wenn Sie RAG betreiben, protokollieren Sie, ob der Textabschnitt, der die Frage hätte beantworten sollen, überhaupt im Kontextfenster gelandet ist. Das lässt sich messen, ohne die Antwort bewerten zu müssen — deshalb ist es günstig, deterministisch und immun gegen die übliche Debatte, ob eine Ausgabe nun gut war. Es ist außerdem entscheidend: Wenn die richtige Passage das Modell nie erreicht hat, rettet auch die beste Prompt-Arbeit die Antwort nicht. Die meisten Teams protokollieren die Antwort und nicht das Retrieval — und suchen den Fehler dann im Modell, obwohl der Korpus schuld war.

Kosten pro Fall, Latenz und Verweigerungen

Messen Sie Kosten pro gelöstem Fall, nicht Kosten pro Token. Der Token-Preis ist eine Buchhaltungsgröße und bewegt sich kaum; ein Agent, der still angefangen hat, dreimal zu wiederholen, zeigt einen völlig normalen Token-Preis und die dreifache Rechnung. Nur die Kennzahl pro Fall fängt das ab. Bei der Latenz schauen Sie auf p95 statt auf den Mittelwert — und zwar aus einem menschlichen Grund: Wenn ein System träge wird, beschweren sich die Leute nicht, sie benutzen es nicht mehr. Oder schlimmer: Sie lesen die Ausgabe nicht mehr und klicken nur noch auf Übernehmen. Und verfolgen Sie die Verweigerungsquote, also den Anteil an Antworten, die ausweichen oder ablehnen. Steigt sie, ohne dass sich bei Ihnen etwas geändert hat, ist das oft der früheste sichtbare Fingerabdruck eines Modell-Updates beim Anbieter.

Wie Drift tatsächlich auftritt

„Drift“ klingt nach einem langsamen, natürlichen Vorgang. In der Praxis kommt sie in vier klar unterscheidbaren Varianten — und nur eine davon ist die, mit der man rechnet.

Verfügbarkeit · Latenz · Fehlerrate: durchgehend grün Anbieter-Update gleicher Prompt, neues Verhalten → Golden Set Korpus-Drift neue Revision liegt neben der alten → Retrieval-Trefferquote Nutzer-Drift neue Formulierungen, neue Fragen → Verweigerungsquote Kosten-Drift der Agent wiederholt unbemerkt → Kosten pro Fall Jede Art von Drift hat genau ein Signal, das sie zuerst sieht.
Vier Arten von Drift, vier verschiedene Frühwarnsignale. Keines davon löst einen Infrastruktur-Alarm aus — deshalb sagt ein grünes Dashboard nichts darüber aus, ob das System noch funktioniert.

Der Anbieter liefert ein besseres Modell aus, und Ihr System wird schlechter. Diese Variante fühlt sich unfair an, und sie ist real. Sie rufen denselben Endpunkt mit demselben Prompt auf, und das Verhalten ändert sich, weil das Modell dahinter aktualisiert wurde. Der widersprüchliche Teil daran: Das neue Modell ist im Durchschnitt meist tatsächlich besser — und trotzdem schlechter für Sie. Prompt-Engineering ist zu einem guten Teil Überanpassung. Die Anweisungen, an denen Sie drei Wochen gefeilt haben, sind um die Eigenheiten genau eines Modells herumgebaut: seinen Hang zum Ausschweifen, die Formulierung, die es zuverlässig davon abhielt, eine Teilenummer zu erfinden. Behebt der Anbieter diese Eigenheiten, ist Ihre sorgsam geformte Umgehung jetzt die Umgehung eines Problems, das es nicht mehr gibt — angewandt auf ein Modell, das anders darauf reagiert. „Besser in den Benchmarks des Anbieters“ und „besser bei Ihrer Aufgabe“ sind zwei verschiedene Behauptungen, und nur eine davon prüft Ihr Golden Set.

Nutzer-Drift ist die stillste Variante: Menschen lernen, wofür das System taugt, und ändern ihre Fragen entsprechend. Ihr Testset friert derweil die Formulierungen vom Tag der Inbetriebnahme ein und misst mit jedem Monat etwas weniger von dem, was tatsächlich passiert.

Ihr eigener Korpus driftet — und meistens ist es genau das

Der Fehler, den ich am häufigsten sehe, hat mit dem Modell überhaupt nichts zu tun. Ein Maschinenbauer betreibt einen Serviceassistenten über seinen Handbüchern. Acht Monate lang ist er hervorragend. Dann werden die Antworten unmerklich schlechter — nicht falsch genug, dass jemand ein Ticket schreibt, nur eben schlechter. Kein Code wurde geändert. Kein Modell wurde geändert. Passiert ist: Jemand hat die Revision 2026 eines Handbuchs hochgeladen, ohne die Fassung von 2023 zu entfernen, und das Retrieval liefert nun in etwa der Hälfte der Fälle das überholte Drehmoment. Das Modell verhält sich einwandfrei — es fasst gewissenhaft das falsche Dokument zusammen.

Kein konventioneller Monitoring-Stack sieht das. Die Retrieval-Trefferquote sieht es am Tag des Uploads. Ein Golden Set sieht es beim nächsten turnusmäßigen Lauf. Die Verfügbarkeitsanzeige sieht es nie — und Ihre Nutzer auch nicht, bis ein Techniker etwas nach einer Spezifikation von 2023 anzieht. Die Lehre lässt sich verallgemeinern: In einem RAG-System gehört Ihre Dokumenten-Pipeline zum Produktivsystem — und sie wird von Menschen verändert, die nicht ahnen, dass sie gerade in die Produktion deployen.

Eine gepinnte Modellversion ist eine Frist, keine Lösung

Die naheliegende Antwort auf Anbieter-Drift ist, die Version festzunageln — und das sollten Sie auch: Ein Produktivsystem zeigt niemals auf einen gleitenden „latest“-Alias. Nur sollten Sie wissen, was Sie damit gekauft haben, denn Stabilität ist es nicht. Festgepinnte Modellstände werden nach dem Zeitplan des Anbieters abgekündigt, mit einer Vorlaufzeit von typischerweise einigen Monaten. Pinning beseitigt die Drift nicht, es verwandelt eine fortlaufende, kleine, beobachtbare Drift in eine einzige diskrete Migration zu einem Termin, den jemand anderes wählt. Sie qualifizieren dann alles auf einmal neu, unter Zeitdruck, vermutlich in einem Quartal, das schon verplant ist.

Dieser Tausch lohnt sich meistens trotzdem. Aber er bedeutet, dass das gepinnte System das Golden Set dringender braucht als das ungepinnte, nicht weniger dringend — es ist das Einzige, was aus der erzwungenen Migration statt zwei Wochen nervösem Stichprobenprüfen einen Nachmittag Testlauf und Diff-Lesen macht. Das ist übrigens auch das stärkste betriebliche Argument dafür, ein offenes Modell selbst zu hosten — und es ist ein anderes Argument als das zum Datenschutz, zu dem sonst immer gegriffen wird: Ein Modell auf Ihrer eigenen Hardware kann Ihnen niemand unter den Füßen wegabkündigen. Der Preis dafür: Die Entscheidung über jedes Upgrade gehört ab sofort dauerhaft Ihnen, einschließlich der Entscheidung, nicht zu aktualisieren und langsam den Anschluss zu verlieren. Das ist ein echter Preis. Nur bestimmen Sie den Zeitpunkt selbst.

Was ich nicht bauen würde. Ein LLM-as-Judge, das jeden Produktivaufruf in Echtzeit bewertet. Es legt einen zweiten Modellaufruf auf jede Anfrage, kostet zusätzliche Latenz — und, das ist der eigentliche K.-o.: Der Judge ist selbst ein Modell und driftet mit. Sie würden mit einem Instrument messen, das Sie nicht überwachen. Nehmen Sie stattdessen eine Stichprobe, bewerten Sie sie offline, und behalten Sie das von Menschen geprüfte Golden Set als das, worauf Sie sich tatsächlich verlassen.

Wie ein ehrliches Wartungsbudget aussieht

Wartung ist bei einem KI-System keine Rückstellung für den Notfall. Sie ist ein fester monatlicher Posten, und die nützliche Frage lautet nicht „wie viel Prozent legen wir zurück?“, sondern: „Wessen Name steht darauf, und ist die Zeit wirklich in seiner Woche eingeplant?“ Ein Budget mit Geld, aber ohne benannte Person, ist ein System, das planmäßig verfällt.

Konkret besteht ein Wartungsmonat bei einem sauber gebauten System aus: Golden Set erneut laufen lassen (automatisiert, Minuten); eine Stichprobe echter Anfragen lesen (etwa eine Stunde — der Teil, den alle auslassen, und der Teil, aus dem Sie am meisten lernen, weil dort die Fragen auftauchen, mit denen niemand gerechnet hat); Retrieval-Fehltreffer sichten; Abhängigkeiten und Modellstände aktualisieren. Dazu eine Reserve für die erzwungene Migration, wenn ein gepinntes Modell abgekündigt wird — die ist weder optional noch klein. Das ist die Betriebskostenseite dessen, was ich unter was KI wirklich kostet beschreibe, und es ist der Posten, der darüber entscheidet, ob sich die Sache über drei Jahre rechnet statt über drei Monate.

Zwei Dinge machen das billiger, als es klingt. Instrumentieren Sie von Tag eins mit OpenTelemetry, statt es nach dem ersten Vorfall nachzurüsten: Dank der GenAI-Konventionen landen Traces von Prompts, Tool-Aufrufen und Token-Zahlen in Werkzeugen, die Sie vielleicht ohnehin betreiben, statt in einer Eigenbau-Logschicht, die Sie fortan selbst pflegen. Und falls Ihr System unter die Hochrisiko-Regeln des EU AI Act fällt: Protokollierung und Beobachtung nach dem Inverkehrbringen sind dann keine Engineering-Vorlieben, die man vertagen kann, sondern Pflichten — und der Gesetzestext wird dabei konkreter, als die meisten Teams erwarten. Das Monitoring gleich einzubauen ist günstiger, als es für ein Audit nachzurüsten.

Wo Tippel ins Spiel kommt

Der größte Teil der beschriebenen Monitoring-Arbeit entscheidet sich beim Bauen, nicht danach. Ob Sie die Retrieval-Trefferquote überhaupt messen können, hängt davon ab, wie die Pipeline zusammengesetzt wurde; ob ein Golden Set existiert, hängt daran, ob jemand vor dem Start darauf bestanden hat. Observability in ein System nachzurüsten, das ohne sie ausgeliefert wurde, geht — der günstige Weg ist es nie.

Wenn bei Ihnen ein KI-System produktiv läuft, bei dem niemand mehr sicher sagen kann, ob es noch richtig arbeitet, ist das eine konkrete und beantwortbare Frage. Der KI-Readiness-Check ist ein sinnvoller Weg dorthin: ein zeitlich begrenzter Blick zum Festpreis darauf, was das System auf Ihrem echten Datenverkehr tatsächlich tut, mit einer klaren Einschätzung am Ende statt eines Dashboards, das niemand liest. Wenn Sie noch bauen, ist es günstiger, die fünf Signale jetzt einzuplanen. So oder so: nehmen Sie Kontakt auf.