KI-Observability

Was ist KI-Observability?

KI-Observability ist die Praxis, KI-Systeme in Produktion zu instrumentieren und dabei Traces, Prompts, Tool-Aufrufe, Token-Kosten, Latenz und Qualitätssignale zu erfassen, damit Teams sehen können, was ein Modell oder ein Agent tatsächlich getan hat und warum. Sie erweitert klassische Observability auf Systeme, deren Verhalten probabilistisch ist und deren Fehler selten eine Exception auslösen. Die Branche hat dieses Argument weitgehend akzeptiert: Fast 89 Prozent der Organisationen, die Agenten bauen, haben dafür Observability implementiert, so LangChains Umfrage unter mehr als 1.300 Fachleuten Ende 2025 [1].

Die wichtigsten Punkte

• KI-Systeme versagen lautlos. Eine falsche Antwort liefert HTTP 200 zurück, sodass Fehlerraten- und Uptime-Dashboards alles im grünen Bereich zeigen, während die Qualität im Hintergrund verbrennt.
• Die zentrale Einheit ist der Trace: eine einzelne Nutzeranfrage, aufgeschlüsselt in jeden Modellaufruf, Prompt, jede Retrieval-Operation, jeden Tool-Aufruf und jede Zwischenentscheidung auf dem Weg, samt Kosten und Latenz pro Schritt.
• Observability schließt den Kreis zur Evaluierung. Produktions-Traces decken echte Fehler auf, Fehler werden zu Eval-Fällen, und Evals verhindern anschließend deren Wiederkehr.
• Kosten sind ein Signal erster Klasse. Der Token-Verbrauch pro Anfrage variiert um Größenordnungen, und eine fehlerhafte Agentenschleife kann Ihre Rechnung still und leise vervielfachen.
• Standardisierung ist angekommen: OpenTelemetry-Konventionen für generative KI bedeuten, dass Traces in dieselben Backends fließen können wie der Rest Ihrer Telemetrie.

So funktioniert es

Die Grundlage ist Tracing. Jede Anfrage, die durch eine KI-Funktion läuft, erzeugt einen strukturierten Trace: die eingehende Eingabe, den exakt gerenderten Prompt (der zählt, weil Templates plus abgerufener Kontext etwas ganz anderes ergeben können, als der Entwickler sich vorgestellt hat), jeden Modellaufruf mit seinen Parametern und Token-Zahlen, jeden Tool-Aufruf eines Agenten mit Argumenten und Ergebnissen sowie die finale Ausgabe. Bei einer einfachen RAG-Anfrage sind das eine Handvoll Spans, bei einem Agenten kann es ein Baum mit Dutzenden Knoten sein. Plattformen in diesem Bereich – LangSmith, Langfuse, Braintrust, Arize und die LLM-Funktionen allgemeiner Observability-Anbieter – unterscheiden sich vor allem darin, wie gut sie das Navigieren und Abfragen dieser Bäume erlauben.

Auf den Traces bauen Metriken und Qualitätssignale auf. Die operative Ebene wirkt vertraut: Latenz-Perzentile, Fehler- und Retry-Raten, Token-Kosten pro Anfrage, pro Feature, pro Kunde. Die Qualitätsebene ist das, was diese Disziplin ausmacht. Da sich Korrektheit nicht an einem Statuscode ablesen lässt, ziehen Teams Stichproben aus dem Produktionsverkehr und bewerten sie – mit LLM-as-a-Judge-Gradern für Faithfulness oder Aufgabenerfüllung, deterministischen Prüfungen für Format und Policy sowie Nutzersignalen wie Daumen-runter, Wiederholungen und Abbrüchen als schwachen Labels. Alarme lösen bei Rückgängen dieser Scores aus, nicht nur bei 500ern – so entdeckt man Model Drift und Regressionen durch anbieterseitige Modell-Updates. Diese Qualitätsebene bleibt die weniger verbreitete Hälfte der Disziplin: Dieselbe LangChain-Umfrage fand, dass Online-Echtzeit-Evaluierungsmonitoring insgesamt nur bei 37,3 Prozent der Organisationen läuft; bei jenen mit Agenten bereits in Produktion steigt der Wert auf 44,8 Prozent [2].

Das letzte Puzzlestück ist die Rückkopplung in die Entwicklung. Findet ein Bereitschafts-Engineer einen schlechten Trace, wird dieser zu einem dauerhaften Eval-Fall; geht eine Prompt-Änderung live, lassen sich ihre Eval-Scores und Produktions-Scores auf gleicher Grundlage vergleichen. Reife Teams behandeln Observability und Evaluierung als ein System mit zwei Enden: Evals sagen das Verhalten vor dem Deployment voraus, Observability überprüft es danach.

Beispiel

Ein Legal-Tech-Unternehmen betreibt einen Agenten, der Vertragszusammenfassungen entwirft. In einer Woche beginnen Nutzer zu klagen, die Zusammenfassungen wirkten dünn, während jedes Dashboard grün zeigt: keine Fehler, normale Latenz. Das Team öffnet seinen Trace-Explorer und filtert die Traces der vergangenen Woche nach einem Faithfulness-Score, den ein nächtlicher Judge einer 5-Prozent-Stichprobe zuweist. Die Scores sind vor vier Tagen eingebrochen. Beim Untersuchen der niedrig bewerteten Traces sehen sie, dass der Retrieval-Schritt nur noch die halbe übliche Anzahl an Passagen liefert, und der Diff zeigt auf eine Änderung am Document-Chunking, die das Parsing für ein Vertragsformat unbemerkt zerstört hat – das Modell fasste also aus unvollständigem Kontext zusammen. Es wurde nie eine Exception geworfen; das Modell hat sein Bestes mit dem gegeben, was es bekam. Sie reparieren den Parser, spielen die betroffenen Traces erneut ab, um die Erholung der Scores zu bestätigen, und fügen die zwölf schlechtesten Traces ihrer Eval-Suite hinzu, damit dieser Fehlermodus nie wieder unbemerkt in Produktion geht. Zeit von der Beschwerde bis zur Ursache: unter einer Stunde – einzig, weil die Traces existierten.

Häufige Missverständnisse

Der verbreitete Fehler ist die Annahme, bestehendes APM decke das bereits ab. Teams richten ihr Standard-Monitoring auf den KI-Dienst, sehen gesunde Latenz und null Fehler und schließen daraus, das Feature funktioniere. Klassische Observability beantwortet „läuft es und ist es schnell", KI-Observability beantwortet „ist es richtig und lohnt sich der Preis" – das sind unterschiedliche Instrumente. Ohne Traces auf Prompt-Ebene und Qualitätsbewertung ist das erste Anzeichen eines degradierten Modells, eines defekten Retrieval-Schritts oder einer außer Kontrolle geratenen Agentenschleife eine Kunden-E-Mail oder eine Rechnung. Wenn Ihre Dashboards Ihnen nicht den exakten Kontext zeigen können, den ein Modell für eine bestimmte schlechte Antwort gesehen hat, haben Sie Monitoring, nicht Observability.

FAQ

Was ist der Unterschied zwischen KI-Observability und LLM-Observability? Vor allem der Umfang. LLM-Observability bezeichnet die Instrumentierung der Modellaufrufe selbst: Prompts, Completions, Token, Latenz. KI-Observability ist der breitere Oberbegriff, der das gesamte System um diese Aufrufe herum abdeckt – Retrieval-Pipelines, Tool-Nutzung von Agenten, mehrstufige Trajektorien und Qualitätsbewertung. Im Marketing der Anbieter verschwimmen die Begriffe, die darunterliegende Trace-zentrierte Architektur ist jedoch dieselbe.

Was sollte man aus einem KI-System loggen? Mindestens: vollständige Prompts und Completions (unter Anwendung von PII-Richtlinien), Modell und Version, Token-Zahlen und Kosten, Latenz pro Aufruf, Tool-Aufrufe mit Argumenten und Ergebnissen, Retrieval-Eingaben und zurückgegebene Dokumente sowie Nutzer-Feedback-Ereignisse, alles korreliert unter einer Trace-ID pro Anfrage. Das Feld für die Modellversion zahlt sich spätestens dann aus, wenn ein Update des Anbieters Ihr Verhalten verändert und Sie das belegen müssen.

Brauchen kleine Teams dafür dediziertes Tooling? Früher, als sie denken. Ein Feature mit einem einzelnen Modell kann mit strukturierten Logs starten, aber sobald eine Agentenschleife oder ein Retrieval-Schritt ins System kommt, kann selbstgebautes Logging die Frage „warum war diese Antwort falsch" nicht mehr beantworten. Open-Source-Optionen machen die Trace-Explorer-Fähigkeit günstig, und die OpenTelemetry-GenAI-Konventionen sorgen dafür, dass frühe Instrumentierung weiterverwendet werden kann, statt verworfen zu werden.

Quellen

1. LangChain. „State of Agent Engineering": Umfrage unter mehr als 1.300 Fachleuten – fast 89 % der Organisationen, die Agenten bauen, haben dafür Observability implementiert. https://www.langchain.com/state-of-agent-engineering. Abgerufen im August 2026.
2. LangChain. „State of Agent Engineering": Online-Evaluierungsmonitoring läuft bei 37,3 % der Organisationen insgesamt und bei 44,8 % derjenigen mit Agenten in Produktion. https://www.langchain.com/state-of-agent-engineering. Abgerufen im August 2026.