Eine KI-Funktion, die im Test überzeugt, kann im Betrieb still schlechter werden. Das Modell wird vom Anbieter aktualisiert, die Dokumente in der Wissensbasis ändern sich, Nutzer stellen andere Fragen als erwartet. Klassisches Monitoring zeigt dann grüne Ampeln: Die Schnittstelle antwortet, keine Fehler, normale Antwortzeiten. Dass die Antworten inhaltlich nachlassen, sieht man dort nicht. KI-Observability schliesst diese Lücke.
Was protokolliert werden sollte
Für jede Modellanfrage lohnt es sich, einen strukturierten Eintrag zu schreiben: Funktion, Workspace, Modell und Version, Prompt-Version, Anzahl Eingabe- und Ausgabe-Tokens, Antwortzeit bis zum ersten und bis zum letzten Token, Ergebnisstatus und gegebenenfalls Fehlerart. Bei Funktionen mit Suche kommen die gefundenen Dokumente und ihre Relevanzwerte hinzu. Diese Daten beantworten im Ernstfall die Frage, was genau passiert ist, und bilden die Grundlage für Kostenauswertungen.
Traces über mehrstufige Abläufe
Viele KI-Funktionen bestehen aus mehreren Schritten: eine Anfrage wird umformuliert, eine Suche ausgeführt, Ergebnisse neu gewichtet, eine Antwort erzeugt, das Ergebnis geprüft. Bei Agenten kommen Werkzeugaufrufe hinzu. Ein Trace verbindet alle Schritte einer Nutzeranfrage zu einem Ablauf, sodass sichtbar wird, wo Zeit verloren geht, wo Kosten entstehen und an welcher Stelle ein falsches Ergebnis seinen Ursprung hat. Ohne Traces endet Fehlersuche in mehrstufigen Systemen oft im Raten.
Etablierte Standards für verteiltes Tracing lassen sich auch für KI-Abläufe nutzen. Wichtig ist, dass jeder Schritt dieselbe Kennung der ursprünglichen Anfrage trägt.
Betriebskennzahlen
Neben klassischen Werten wie Fehlerquote und Verfügbarkeit sind für KI-Funktionen einige Kennzahlen besonders wichtig. Die Zeit bis zum ersten sichtbaren Token bestimmt, wie schnell sich eine Funktion anfühlt. Die Anzahl Tokens pro Anfrage zeigt, ob der Kontext unbemerkt wächst. Die Quote von Antworten, die eine Prüfung nicht bestehen — etwa ungültiges Format oder fehlende Quelle —, ist ein früher Hinweis auf Qualitätsprobleme. Und Abbrüche durch Nutzer während der Erzeugung sagen viel über die Geduld, die eine Funktion ihnen abverlangt.
Qualitätssignale im Betrieb
Qualität lässt sich im Betrieb nicht direkt messen, aber über Signale annähern. Explizite Rückmeldungen wie eine Bewertung sind wertvoll, aber selten. Implizite Signale sind häufiger: Übernimmt der Nutzer das Ergebnis, bearbeitet er es stark, erzeugt er es neu, bricht er ab? Eine steigende Quote von Neu-Erzeugungen bei einer Funktion ist oft der erste Hinweis, dass etwas nicht mehr stimmt.
Ergänzend lohnt sich eine regelmässige Stichprobe echter Anfragen, die gegen die Kriterien des Bewertungsdatensatzes geprüft wird — automatisch durch ein Bewertermodell und in kleinem Umfang durch Menschen.
Drift erkennen
Drift bedeutet, dass sich die Bedingungen ändern, unter denen eine Funktion arbeitet. Eingabedrift entsteht, wenn Nutzer neue Themen, Sprachen oder Formate verwenden. Datendrift entsteht, wenn sich die Dokumente in einer Wissensbasis verändern. Modelldrift entsteht, wenn der Anbieter ein Modell aktualisiert oder ein bisher genutztes Modell abkündigt. Feste Modellversionen statt «immer die neueste» und ein Lauf des Bewertungsdatensatzes vor jedem Versionswechsel sind der wirksamste Schutz gegen unbemerkte Modelldrift.
Datenschutz in den Protokollen
Prompts und Antworten enthalten oft Personendaten. Protokolle müssen deshalb denselben Regeln folgen wie die Daten selbst: Zweckbindung, begrenzte Aufbewahrung, Zugriffsbeschränkung. Bewährt hat sich, Metadaten wie Tokenzahlen und Antwortzeiten dauerhaft zu speichern, vollständige Inhalte aber nur kurz und pseudonymisiert. Wer externe Observability-Dienste einsetzt, nimmt sie in die Liste der Unterauftragsverarbeiter auf und prüft den Speicherort.
Alarme, die nützen
Alarme sollten auf Veränderungen reagieren, nicht auf Einzelfälle: eine deutlich gestiegene Quote fehlgeschlagener Prüfungen, sprunghaft mehr Tokens pro Anfrage, eine längere Zeit bis zum ersten Token, ein ungewöhnlicher Verbrauch einzelner Workspaces. Zu viele Alarme werden ignoriert; wenige, gut gewählte werden ernst genommen.
Wie wir vorgehen
Innopulse richtet bei KI-Funktionen von Beginn an strukturierte Protokolle, Traces und eine kleine Zahl aussagekräftiger Alarme ein und verbindet sie mit dem Bewertungsdatensatz. So zeigt sich eine Verschlechterung im Dashboard, bevor sie sich in Supportanfragen zeigt.