LLM Observability
LLM Observability ist die Praxis, produktive LLM-Anwendungen zu instrumentieren, damit Teams sehen können, was das Modell tut, Fehler debuggen, Kosten und Latenz messen, Qualitätsdrift erkennen und Ausgaben im Zeitverlauf bewerten können. Es ist das Pendant der klassischen App-Observability für die LLM-Ära, Logs, Traces und Metriken, angepasst an probabilistische Systeme, in denen dieselbe Eingabe unterschiedliche Ausgaben erzeugen kann.
LLM Observability ist die Praxis, produktive LLM-Anwendungen zu instrumentieren, damit Teams sehen können, was das Modell tut, Fehler debuggen, Kosten und Latenz messen, Qualitätsdrift erkennen und Ausgaben im Zeitverlauf bewerten können. Es ist das Pendant der klassischen App-Observability für die LLM-Ära, Logs, Traces und Metriken, angepasst an probabilistische Systeme, in denen dieselbe Eingabe unterschiedliche Ausgaben erzeugen kann.
Warum es wichtig ist
Eine klassische Webanwendung funktioniert entweder oder wirft einen Fehler. Eine LLM-Anwendung kann "funktionieren" (eine gut formatierte Antwort zurückgeben), während die Antwort falsch, themenfremd, halluziniert, voreingenommen oder einfach schlechter als gestern ist. Ohne Observability bleiben diese Fehler unsichtbar, bis sich Nutzer beschweren, zu welchem Zeitpunkt das Vertrauen bereits beschädigt ist. In den Jahren 2024 bis 2025 wurde LLM Observability zu einer eigenständigen Kategorie, wobei sich Tools wie Langfuse, LangSmith, Helicone, Arize Phoenix, Weights & Biases Weave und Braintrust jeweils einen Anteil sicherten. Für jedes Team, das LLMs in der Produktion betreibt, ist Observability inzwischen eine Grundvoraussetzung, kein nettes Extra.
Was zu instrumentieren ist
Traces: Der vollständige Ausführungspfad, jeder Prompt, jeder Abrufaufruf, jeder Tool-Aufruf und jede Antwort in einer einzigen Anfrage. Ermöglicht das Nachspielen dessen, was der Agent tatsächlich getan hat.
Eingabe-/Ausgabe-Paare: Der genau gesendete Prompt und die genau empfangene Vervollständigung, versioniert nach Prompt-Vorlage.
Kosten pro Anfrage: Token-Anzahl × Preis für Eingabe und Ausgabe, pro Modell. Aggregiert nach Funktion, Nutzer oder Mandant.
Latenz: Zeit bis zum ersten Token, gesamte Vervollständigungszeit und die in jedem Teilschritt verbrachte Zeit.
Fehler und Wiederholungen: Rate-Limit-Fehler, Zeitüberschreitungen, fehlgeschlagene Tool-Aufrufe, Parse-Fehler.
Qualitätssignale: Daumen hoch/runter von Nutzern, implizite Signale (kopierte Ausgabe, ausgeführter Code, gesendete Nachricht) und LLM-as-a-Judge-Werte für aktuelle Ausgaben.
Drift: Veränderungen im Zeitverlauf bei der Ausgabeverteilung, der Antwortqualität oder der Tool-Aufrufrate, oft das erste Signal dafür, dass ein Modell-Update oder eine Prompt-Änderung etwas kaputtgemacht hat.
Warum es sich von klassischer Observability unterscheidet
Ausgaben sind nicht deterministisch: Gleiche Eingabe, andere Ausgabe. Metriken müssen Varianz als erstrangiges Konzept behandeln.
Kosten fallen pro Token an, nicht pro Anfrage: Klassisches APM weiß nicht, was Tokens sind. LLM Observability muss es wissen.
Qualität ist subjektiv: Sie können "Ausgabe korrekt" nicht mit einem einfachen Test feststellen. Die Bewertung erfordert menschliche Prüfung, LLM-Bewerter oder Vergleiche mit der Grundwahrheit.
Prompts sind Code: Eine Prompt-Änderung ist ein Deploy. Ohne Prompt-Versionierung können Sie nicht sagen, welche Version den gestrigen Fehler erzeugt hat.
Mehrstufige Ketten sind wichtig: Die meisten LLM-Anwendungen sind Pipelines. Sie benötigen verschachtelte Traces, die den Aufrufgraphen widerspiegeln, keine flachen Logs.
Die Tooling-Landschaft (2026)
Langfuse (Open Source): Trace-zentrierte Observability mit Evaluierung, Prompt-Management und Nutzerfeedback. Beliebt bei selbst hostenden Teams.
LangSmith (LangChain): Eng in LangChain integriert. Stark für Teams, die bereits auf diesem Stack arbeiten.
Helicone: Leichtgewichtige, proxybasierte Observability. Integration mit einer Zeile, leicht zu übernehmen.
Arize Phoenix / Arize AX: Stammt aus der Welt der ML-Observability; stark bei Drift, Embeddings und Evaluierungswissenschaft.
Braintrust: Evaluierungszentrierte Plattform, nützlich für Teams, die die LLM-Entwicklung als Experimentier-Workflow behandeln wollen.
Weave (Weights & Biases): Erweitert die ML-Experimentverfolgung von WandB in den LLM-Bereich.
Datadog / New Relic LLM Monitoring: Klassische APM-Anbieter, die LLM-spezifische Dashboards hinzufügen.
OpenTelemetry GenAI Semantic Conventions: Ein herstellerübergreifender Standard für LLM-Tracing, der 2025 bis 2026 an Verbreitung gewinnt.
Worauf zu achten ist
Kosten pro Nutzersitzung: Plötzliche Spitzen bedeuten oft einen Fehler (Wiederholungsschleife, außer Kontrolle geratener Agent), bevor sie Wachstum bedeuten.
Latenz p95/p99: Lange Ausläufer zerstören die Nutzererfahrung. Der schlimmste Fall ist wichtiger als der Durchschnitt.
Drift der Evaluierungswerte: Ein wöchentlicher LLM-as-a-Judge-Wert an repräsentativen Prompts fängt stille Regressionen nach Prompt- oder Modelländerungen ab.
Häufigste Fehlerquellen: Kategorisieren Sie Fehler, verweigert, halluziniert, themenfremd, fehlerhaftes Format, damit Sie wissen, wo Sie investieren müssen.
Leistung der Prompt-Version: Vergleichen Sie Evaluierungswerte über Prompt-Versionen hinweg, um zu erkennen, ob die jüngste Änderung geholfen oder geschadet hat.
Token-Verteilung: Lange Antworten treiben die Kosten. Unerwartet lange Ausläufer deuten oft auf Prompt-Drift oder defekte Stopp-Tokens hin.
Häufige Fehler
Nur Fehler protokollieren: LLMs scheitern still. Protokollieren Sie auch Erfolge, mit genügend Metadaten, um die Qualität zu bewerten.
Keine Sampling-Strategie: 100 % der Anfragen im großen Maßstab zu protokollieren, ist teuer. Wählen Sie intelligent aus, nach Nutzersegment, Kostenstufe oder jüngster Änderung.
Traces nicht mit Nutzerfeedback verbinden: Ein Daumen runter muss auf den genauen Trace zurückverweisen, der die Ausgabe erzeugt hat.
Nach Teams abgeschottet: Produkt, ML und Infrastruktur bauen jeweils ihre eigenen Dashboards. Vereinheitlichte Observability ist der Gewinn.
Regressionstests ignorieren: "Es sieht gut aus" reicht nicht. Bauen Sie ein Regressions-Evaluierungsset auf und führen Sie es vor jeder Prompt-Änderung aus.
Herstellerbindung hinterherjagen: Die OpenTelemetry-GenAI-Konventionen ermöglichen es Ihnen, einmal zu instrumentieren und später den Observability-Anbieter zu wechseln.
Quellen: