Observability für KI-Systeme: Man kann nicht debuggen, was man nicht sieht

Der Fehler, der keinen Alarm auslöst

Klassisches Software-Monitoring beruht auf einer beruhigenden Annahme: Wenn etwas kaputtgeht, wird es laut. Eine Exception fliegt, ein Statuscode springt auf 500, die Latenz-Kurve knickt nach oben, ein Dashboard färbt sich rot. Der ganze Werkzeugkasten der letzten zwanzig Jahre – Fehlerraten, p99-Latenz, Traces über Microservices hinweg – ist darauf gebaut, dass Ausfälle ein sichtbares Symptom haben. Man muss nur das richtige Symptom messen und beim richtigen Schwellwert piepen.

KI-Systeme brechen mit dieser Annahme. Ihr charakteristischer Fehler ist nicht der Absturz, sondern die falsch-aber-plausible Antwort – die Zusammenfassung, die einen entscheidenden Punkt weglässt, die Klassifikation, die selbstbewusst danebenliegt, die extrahierte Zahl, die um eine Größenordnung falsch ist. Und diese Antwort produziert keine Exception. Sie hat den Statuscode 200. Sie kommt in normaler Latenz. In den Logs ist sie von einer perfekten Antwort nicht zu unterscheiden. Das Modell hat nicht gemeldet, dass es unsicher war. Es hat geliefert, souverän wie immer, nur eben falsch.

Genau hier versagt klassische Observability. Sie ist gebaut, um Systeme zu überwachen, die entweder funktionieren oder abstürzen. KI-Systeme haben einen dritten Zustand, für den das ganze Instrumentarium blind ist: sie funktionieren, aber schlechter. Und weil dieser Zustand keinen Alarm auslöst, merkt ihn oft zuerst der Kunde.

Warum KI-Systeme einzigartig undurchsichtig sind

Um zu verstehen, warum KI eine eigene Observability-Disziplin braucht, muss man vier Eigenschaften ernst nehmen, die deterministische Software nicht hat.

Nicht-Determinismus. Dieselbe Eingabe zweimal geschickt ergibt zwei verschiedene Antworten. Das ist kein Bug, das ist der eingebaute Charakter probabilistischer Modelle. Damit fällt die verlässlichste Debugging-Technik der Softwaregeschichte weg: die deterministische Reproduktion. Man kann einen Fehler nicht mehr einfangen, indem man ihn erneut auslöst – beim zweiten Versuch verhält sich das System vielleicht tadellos. Wer nicht festgehalten hat, was beim ersten Mal exakt passiert ist, hat den Fehler für immer verloren.

Stille Qualitätsregression. Deterministischer Code, der gestern funktionierte, funktioniert heute – es sei denn, jemand hat ihn geändert. Bei KI-Systemen ist das nicht garantiert. Die Antwortqualität kann driften, ohne dass eine einzige Zeile Code angefasst wurde: weil sich das Modell dahinter geändert hat, weil sich die Datenverteilung der Nutzeranfragen verschoben hat, weil ein vorgelagerter Retrieval-Schritt schlechter geworden ist. Die Regression ist real, aber sie hat keinen Commit, auf den man zeigen kann.

Prompt- und Versions-Drift. Ein KI-Feature ist selten nur „das Modell". Es ist ein Prompt-Template, eine Menge Kontext, eine Reihe von Tool-Definitionen, eine Modellversion und ein Dutzend Parameter. Jedes dieser Teile kann sich unabhängig ändern – jemand feilt am System-Prompt, ein Retrieval-Index wird neu gebaut, der Anbieter rollt ein Update aus. Jede dieser Änderungen kann das Verhalten verschieben, und keine davon sieht aus wie ein klassisches Deployment.

Kein Stacktrace für „schlechte Antwort". Wenn deterministischer Code fällt, bekommt man eine Zeilennummer und einen Pfad durch den Aufrufstapel. Wenn ein Modell eine schlechte Antwort gibt, gibt es keinen Stacktrace. Es gibt keine Zeile, in der „der Fehler passiert ist". Die Antwort ist aus Milliarden Gewichten und dem gesamten Kontext entstanden, den man reingegeben hat. Debuggen heißt hier nicht „dem Fehler zur Quelle folgen", sondern „rekonstruieren, unter welchen exakten Bedingungen diese Antwort zustande kam" – und das geht nur, wenn man diese Bedingungen vorher festgehalten hat.

Was man tatsächlich erfassen muss

Wenn der Fehler keinen Stacktrace hinterlässt, muss die Observability den Kontext liefern, den der Stacktrace sonst geliefert hätte. Das bedeutet, deutlich mehr zu erfassen als bei klassischer Software – und zwar gezielt. Was ein instrumentiertes KI-System pro Request festhalten sollte:

• Der vollständige Trace: Prompt, Kontext, Antwort. Nicht nur die Nutzereingabe, sondern der gesamte zusammengebaute Prompt – System-Prompt, eingefügter Kontext, Retrieval-Ergebnisse, Few-Shot-Beispiele – und die rohe Modellantwort. Das ist das eine, das man nicht rekonstruieren kann, wenn man es nicht mitschreibt. Ohne den exakten Prompt hat man beim nicht-deterministischen System keine Chance, eine schlechte Antwort zu verstehen.
• Token-Verbrauch und Kosten pro Request. Input-Tokens, Output-Tokens, der daraus resultierende Preis – auf Request-Ebene, nicht als aggregierte Monatssumme. Warum, dazu unten ein eigener Abschnitt.
• Die Tool-Call-Kette. Bei agentischen Systemen: welche Werkzeuge in welcher Reihenfolge mit welchen Argumenten aufgerufen wurden, und was sie zurückgaben. Ein Agent, der in die Irre läuft, tut das fast immer über eine nachvollziehbare Kette schlechter Werkzeug-Entscheidungen – aber nur, wenn man die Kette aufgezeichnet hat.
• Die Latenz-Aufschlüsselung. Nicht „der Request dauerte 4 Sekunden", sondern wo die 4 Sekunden lagen: Retrieval, erster Modellaufruf, drei Tool-Calls, zweiter Modellaufruf. Bei mehrstufigen KI-Pipelines ist die Gesamtlatenz eine Summe, deren Summanden man einzeln sehen muss.
• Nutzer-Feedback-Signale. Der Daumen hoch/runter, das „Antwort neu generieren", das stille Abbrechen, das Kopieren des Ergebnisses. Das sind die einzigen Korrektheitssignale, die in Echtzeit und in Produktion anfallen. Sie sind grob, aber sie sind Gold, wenn man sie an den zugehörigen Trace hängt.
• Eval-Scores über die Zeit. Die Verbindung zwischen Observability und einer echten Bewertungs-Suite. Observability sagt einem, dass sich das Verhalten verändert hat; Evals sagen einem, ob es schlechter geworden ist. Wer noch keine Eval-Kultur hat, findet den Einstieg in unserem Artikel „Evals statt Bauchgefühl" – Observability ist die Verkabelung, die diese Evals kontinuierlich mit Produktionsdaten füttert.

Der Werkzeugkasten dafür wächst schnell. LLM-Tracing-Plattformen im Stil von LangSmith sind darauf spezialisiert, ganze Prompt-Kontext-Antwort-Traces und Agenten-Läufe darzustellen; parallel entsteht mit den OpenTelemetry-Konventionen für LLMs ein offener Standard, der KI-Spans in dieselbe Tracing-Welt einbettet, in der auch der Rest des Systems schon lebt. Welches Werkzeug man wählt, ist zweitrangig. Die Entscheidung, die zählt, ist, den vollen Trace überhaupt festzuhalten – bevor man ihn braucht.

Die stille Regression: drei Wege, auf denen es leise schlechter wird

Der gefährlichste Fall ist der, bei dem sich nichts an deinem System ändert und es trotzdem schlechter wird. Drei Muster tauchen immer wieder auf.

Gleicher Modellname, anderes Verhalten. Ein Anbieter aktualisiert das Modell hinter einem stabilen Namen. Du rufst weiter denselben Endpunkt auf, dieselbe Kennung, und bekommst plötzlich subtil andere Antworten – vorsichtiger, geschwätziger, anders formatiert, an einer Stelle stark und an anderer schwächer. Kein Deployment auf deiner Seite, keine Codeänderung, kein Alarm. Nur ein Feature, das nach dem Wochenende ein bisschen anders tickt. Ohne Trace-Historie, an der man das Vorher-Nachher vergleichen kann, ist das schlicht unsichtbar – man merkt es erst an den Beschwerden.

Das Prompt-Template ändert sich. Jemand im Team verbessert den System-Prompt, um einen Randfall zu fixen. Der Fix wirkt lokal, verschiebt aber das Verhalten in einem anderen, ungetesteten Bereich. Das ist kein böser Zufall, das ist die Natur von Prompts: Sie sind global gekoppelt, eine Änderung an einer Stelle wirkt überall. Ohne versionierte Prompts, die in jedem Trace mitgeschrieben werden, weiß später niemand mehr, welche Formulierung an dem Tag lief, an dem die Qualität kippte.

Die Retrieval-Qualität degradiert. Bei RAG-Systemen ist das Modell oft gar nicht das Problem – der Kontext ist es. Der Vektor-Index wird neu gebaut und eine Embedding-Version wandert, ein Dokumentenbestand wächst und verwässert die Treffer, ein Chunking-Parameter ändert sich. Das Modell bekommt schlechteren Kontext und gibt entsprechend schlechtere Antworten – aber es sieht aus, als sei das Modell schlechter geworden. Nur wer den Retrieval-Schritt separat instrumentiert, sieht, dass die Ursache eine Ebene vorher liegt.

Allen drei Mustern ist eines gemeinsam: Sie hinterlassen in klassischen Metriken keine Spur. Fehlerrate stabil, Latenz stabil, Verfügbarkeit grün. Der einzige Weg, sie zu fangen, ist, die inhaltliche Qualität über die Zeit zu beobachten – und das setzt voraus, dass man die Traces und Eval-Scores von gestern noch hat, um sie mit denen von heute zu vergleichen.

Kosten als erstklassige Metrik

Bei deterministischer Software sind die Kosten pro Request meist eine Nachkommastelle, um die sich niemand kümmert. Bei KI-Systemen sind sie eine erstklassige Betriebsmetrik – manchmal die, die zuerst brennt.

Der Grund ist, dass KI-Kosten explosiv und leise zugleich sein können. Zwei Muster stechen heraus.

Der durchdrehende Agent. Ein agentisches System gerät in eine Schleife: Es ruft ein Werkzeug auf, ist mit dem Ergebnis unzufrieden, ruft es leicht anders wieder auf, wieder und wieder. Jede Runde verbrennt Tokens. Funktional sieht das oft nicht mal wie ein Fehler aus – der Agent „arbeitet ja". Aber ein einzelner Request, der in einer Schleife hängt, kann das Hundertfache eines normalen kosten, und wenn das unter Last passiert, ist die Rechnung am Monatsende ein Schock, den niemand kommen sah. Nur eine aufgezeichnete Tool-Call-Kette mit Token-Zählung pro Schritt macht so eine Schleife sichtbar – im Idealfall in Echtzeit, mit einem harten Limit, das sie abwürgt.

Kontext-Blähung. Es ist verführerisch, dem Modell mehr Kontext zu geben – mehr Retrieval-Ergebnisse, mehr Historie, mehr Beispiele. Jeder Zuwachs verbessert vielleicht die Qualität ein bisschen und erhöht die Kosten jedes einzelnen Requests garantiert. Ohne Kosten-Transparenz auf Request-Ebene schleicht sich diese Blähung ein, ein Feld hier, ein Dokument da, bis die Kosten pro Request sich verdoppelt haben und niemand den Moment benennen kann, an dem es passierte.

Kosten pro Request zu instrumentieren macht diese Dynamik sichtbar, solange sie noch billig zu beheben ist. Es erlaubt außerdem die Frage, die jedes ernsthafte KI-Produkt irgendwann stellen muss: Was kostet uns dieses Feature pro Nutzer, und trägt es sich? Diese Frage lässt sich nicht rückwirkend aus einer aggregierten Cloud-Rechnung beantworten. Sie braucht die Kosten am einzelnen Request, festgehalten von Anfang an.

Die Gegenseite: nicht in Telemetrie ertrinken

Bis hierhin könnte man die Lehre ziehen: alles loggen, jeden Prompt, jede Antwort, jeden Zwischenschritt, für immer. Das wäre ein Fehler – und zwar ein teurer und riskanter.

Jeden vollständigen Prompt und jede Antwort mitzuschreiben hat drei unangenehme Konsequenzen. Datenschutz und PII: Nutzereingaben an ein KI-System enthalten oft genau die sensiblen Daten, die man am wenigsten in einem Log-Store gespiegelt haben will – Namen, E-Mails, Gesundheits- oder Finanzdaten. Ein vollständiges Prompt-Log ist ein zweiter, schlechter gesicherter Datensee, ein Compliance-Problem und ein Angriffsziel. Kosten: Trace-Speicher ist nicht gratis; ganze Kontextfenster – bei modernen Modellen zehntausende Tokens pro Request – dauerhaft aufzubewahren, kann selbst zum Kostenposten werden. Rauschen: Ein Log, in dem alles steht, ist ein Log, in dem man nichts findet. Vollständigkeit ohne Struktur ist keine Observability, sondern ein Heuhaufen.

Die Antwort ist nicht „weniger loggen", sondern klüger loggen. Sampling: Nicht jeder Request muss den vollen Trace bekommen; ein repräsentativer Anteil plus die vollständige Erfassung aller Fehlerfälle und Nutzer-Negativsignale liefert das meiste Wissen zu einem Bruchteil des Volumens. Redaction: PII lässt sich vor dem Persistieren aus Prompts und Antworten entfernen oder maskieren – man behält die Struktur des Traces, ohne den sensiblen Inhalt zu horten. Für die Fälle instrumentieren, die wirklich wehtun, nicht für alle gleich.

Und die wichtigste Grenze überhaupt: Observability ersetzt keine Evals. Sie sagt dir, dass sich etwas verändert hat – der Ton ist anders, die Latenz stieg, die Kosten verdoppelten sich. Sie sagt dir nicht, ob die Antwort korrekt ist. Ein Trace kann tadellos aussehen und trotzdem eine falsche Antwort enthalten; die Metriken sind alle grün, und das Ergebnis ist trotzdem Unsinn. Korrektheit zu beurteilen ist die Aufgabe von Evals – einer Suite, die gegen bekannte Erwartungen prüft. Observability und Evals sind zwei Hälften desselben Systems: Die eine erkennt die Veränderung, die andere bewertet sie. Wer nur das eine baut, hat entweder ein Frühwarnsystem ohne Urteil oder ein Urteil ohne Frühwarnung.

Fazit

Klassische Observability wurde für Software gebaut, die entweder läuft oder fällt. KI-Systeme haben einen dritten Zustand – läuft, aber schlechter –, und genau für diesen Zustand ist das alte Instrumentarium blind. Eine falsch-aber-plausible Antwort hat den Statuscode 200, kommt in normaler Latenz und ist im Log von einer richtigen nicht zu unterscheiden. Wer nur Fehlerraten und Latenz misst, wird die stille Degradation nicht kommen sehen – der Kunde sieht sie zuerst.

Die Disziplin, die daraus folgt, ist neu, aber sie ist erlernbar: den vollständigen Trace festhalten, bevor man ihn braucht; Kosten pro Request wie eine erstklassige Metrik behandeln; die inhaltliche Qualität über die Zeit beobachten, statt nur die Infrastruktur; und das Ganze mit Sampling, Redaction und einer echten Eval-Suite ausbalancieren, damit man weder in Telemetrie ertrinkt noch Veränderung mit Korrektheit verwechselt.

Genau so gehen wir bei NH Labs mit KI-Features um: Wir instrumentieren sie wie Produktionssysteme – volle Traces, Kosten pro Request, Eval-Trends über die Zeit –, damit stille Degradation schnell auffällt und nicht erst, wenn sich die Beschwerden häufen. Man kann nicht debuggen, was man nicht sieht. Also sorgen wir dafür, dass wir es sehen.