Das erste, das Teams entdecken, wenn sie eine LLM-Anwendung vom Demo zur Produktion bringen, ist, dass sie blind fliegen. Das Modell gibt eine Antwort zurück, die Antwort ist manchmal falsch, und es gibt keine offensichtliche Möglichkeit, zu wissen, warum. War der Retrieval schlecht? Ist ein Tool-Aufruf stillschweigend fehlgeschlagen und der Agent hat improvisiert? Hat eine Änderung der Eingabeaufforderung vor drei Wochen die Qualität ruhig verschlechtert? Bei einem traditionellen Webdienst würden Sie zu Logs, Metriken und Traces greifen und die Antwort in Minuten finden. Bei einer LLM-Anwendung im Jahr 2023 hatten die meisten Teams eine print-Anweisung und ein Gefühl. Bis 2026 ist diese Lücke geschlossen, und die Disziplin, die sie geschlossen hat, ist LLM Observability: die Praxis, Sprachmodell-Anwendungen zu instrumentieren, zu tracen und zu evaluieren, damit ihr Verhalten sichtbar, debuggierbar und messbar verbesserbar ist.
Dieser Leitfaden behandelt, was LLM Observability tatsächlich im Jahr 2026 bedeutet, warum es schwieriger ist als gewöhnliche Anwendungsüberwachung, und wie der Stack zusammenpasst. Der Durchhang ist ein Standard — OpenTelemetry — der ein zersplittertes Feld proprietärer SDKs in etwas Interoperables umgewandelt hat, und drei Tools, die die Ansätze exemplifizieren: Arize Phoenix, Langfuse und MLflow. Das Ziel ist, Sie in die Lage zu versetzen, zu überlegen, was Sie instrumentieren, was Sie messen und wie Sie ein Tool wählen, das Sie nicht sperrt.
Warum LLM-Apps schwer zu beobachten sind
Konventionelle Observability ruht auf drei Säulen: Logs (was ist passiert), Metriken (wie viel, wie schnell) und Traces (welchen Weg nahm eine Anfrage durch das System). LLM-Anwendungen brauchen alle drei, aber sie brechen die üblichen Annahmen auf Arten, die naive Überwachung beinahe nutzlos machen.
Das erste Problem ist Nicht-Determinismus. Die gleiche Eingabe kann unterschiedliche Ausgaben erzeugen, daher ist „es hat einmal die falsche Sache zurückgegeben" kein reproduzierbarer Fehler, den Sie unter einem Debugger erneut ausführen können. Sie müssen erfassen, was tatsächlich beim spezifischen Aufruf passiert ist, der fehlgeschlagen ist — die genaue Eingabeaufforderung, den genauen Kontext, die genaue Antwort — weil Sie es möglicherweise niemals reproduzieren. Das zweite Problem ist Opazität der Qualität. Eine Webanfrage erfolgreich oder gibt einen Fehlercode zurück; ein LLM-Aufruf „erfolgreich" fast immer, da er Text zurückgibt, während der Text subtil oder katastrophal falsch sein kann. Status-Codes sagen Ihnen nichts. Qualität ist eine semantische Eigenschaft, die separat bewertet werden muss. Das dritte Problem ist Tiefe. Ein moderner Agent ist nicht ein Modell-Aufruf; es ist ein Baum — das Modell entscheidet, ein Tool aufzurufen, das Tool gibt Daten zurück, das Modell ruft Kontext ab, argumentiert über Zwischenergebnisse, vielleicht übergibt an einen anderen Agenten, und erst dann antwortet. Wenn die endgültige Antwort falsch ist, kann die Ursache an jedem Knoten in diesem Baum sein, und ein flaches Log von „Modell aufgerufen, Antwort erhalten" versteckt genau die Struktur, die Sie zum Debuggen benötigen.
Diese drei Eigenschaften — Nicht-Determinismus, opake Qualität und tiefe Call-Bäume — sind der Grund, warum LLM Observability seine eigene Disziplin ist, anstatt einen Anstrich auf bestehende APM zu sein. Das Tooling, das wichtig ist, wird um sie herum gebaut.
Tracing: den Call-Baum sichtbar machen
Die Grundlage ist verteiltes Tracing, angepasst an LLM-Anwendungen. Ein Trace erfasst eine End-zu-End-Anfrage als einen Baum von Spans, wobei jeder Span eine Operation ist: ein LLM-Aufruf, ein Tool-Aufruf, ein Retrieval-Schritt, eine Guardrail-Prüfung. Für jeden Span zeichnen Sie die Eingaben, die Ausgaben, das Timing, die Token-Zählungen, Kosten und Fehler auf. Das Ergebnis ist, dass, wenn eine Antwort fehlgeht, Sie den Trace öffnen und den Baum durchgehen können — sehen, dass Retrieval irrelevante Dokumente zurückgab, oder dass ein Tool-Aufruf zeitüberschritten war und der Agent geraten hat, oder dass der System-Prompt nicht das war, was Sie erwartet haben.
Dies ist genau deshalb transformativ, weil das Tiefe-Problem oben. Ohne Tracing ist ein Agent eine Blackbox, die eine schlechte Antwort emittierte. Mit Tracing ist es eine Folge von inspektiven Schritten, und Debugging wird zu einer Frage des Lesens des Baums, anstatt zu raten. Die reichhaltigsten Tracing-Tools rekonstruieren auch Multi-Turn-Gespräche, daher können Sie sehen, wie sich der Kontext über eine Sitzung angesammelt hat, und sie zeigen die Token-Nutzung und Kosten pro Span, was die ewige Frage „Warum ist unsere OpenAI-Rechnung so hoch" in eine Abfrage anstelle eines Geheimnisses umwandelt.
Der praktische Rat ist, Tracing-Instrumentierung zuerst durchzuführen, vor der Evaluierungsarbeit, weil Tracing das ist, das alles andere möglich macht. Sie können Aufrufe, die Sie nicht erfasst haben, nicht evaluieren, und Sie können ein System, das Sie nicht sehen können, nicht debuggen. Jedes unten diskutierte Tool führt mit Tracing an diesem Grund.
Die OpenTelemetry-Verschiebung
Die wichtigste strukturelle Änderung in LLM Observability zwischen 2024 und 2026 ist die Konvergenz auf OpenTelemetry (OTel) als Instrumentierungs-Standard. Frühe Observability-Tools versendeten jeweils ihr eigenes SDK: Sie instrumentierten Ihren Code gegen die Bibliothek von Anbieter X, und Ihre Traces waren in die Plattform von Anbieter X gesperrt. Das Wechsel von Tools bedeutete Neuinstrumentierung von allem. OpenTelemetry — der gleiche herstellerneutrale Observability-Standard, der bereits in konventioneller Infrastruktur gewonnen hat — änderte das. Ihre Anwendung sendet Traces im Standard-OTLP-Format aus, und jedes OTel-kompatible Backend kann sie empfangen.
Für LLM-Anwendungen sind die semantischen Konventionen, die auf OTel gelegt werden, genauso wichtig wie der Transport. Eine Konvention wie OpenInference definiert wie man einen LLM-Span darstellt — wo die Eingabeaufforderung geht, wie man abgerufene Dokumente aufzeichnet, wie man einen Tool-Aufruf kennzeichnet — daher sind Traces nicht nur im Standard-Format transportiert, sondern sind bedeutsam interpretierbar über Tools. Arize Phoenix ist nativ darauf gebaut: es akzeptiert Traces über Standard-OTLP und nutzt OpenInference-Konventionen, was bedeutet, dass die Instrumentierung, die Sie hinzufügen, nicht Phoenix-spezifisch ist. Wenn Sie später die gleichen Traces anderswo senden möchten, können Sie es. Langfuse und MLflow haben ebenfalls OTel-Kompatibilität angenommen.
Die strategische Auswirkung für alle, die Tools 2026 wählen, ist OTel-native Instrumentierung zu bevorzugen. Es ist der Unterschied zwischen der Investition in einen Standard und der Investition in einen Anbieter. Instrumentieren Sie einmal gegen OTel, und Ihre Observability-Daten sind tragbar; instrumentieren Sie gegen ein proprietäres SDK, und Sie haben einen Wechselkosten gekauft. Dies ist die einzelne folgenreichste Architektur-Entscheidung im Raum, und es ist einfach, es richtig zu machen, indem Sie einfach auf OTLP bestehen.
Evaluation: Qualität messen, die Sie nicht augenzwinkern können
Tracing zeigt Ihnen, was passiert ist; Evaluation sagt Ihnen, ob das, was passiert ist, gut war. Da LLM-Ausgabequalität semantisch ist, können Sie sie nicht mit einem Status-Code behaupten, und Sie können nicht manuell jede Antwort bei Produktionsvolumen lesen. Die 2026-Antwort ist eine Kombination von Techniken, mit LLM-as-Judge im Zentrum.
LLM-as-Judge verwendet ein fähiges Modell, um Ausgaben gegen einen Rubrik zu bewerten: Ist diese Antwort treu zum abgerufenen Kontext (d.h. nicht halluziniert), ist sie relevant zur Frage, ist sie korrekt gegen eine Referenz, ist sie giftig oder unsicher? Tools wie DeepEval brachten eine große Bibliothek von forschungsgestützten Metriken zu diesem, und Observability-Plattformen falten zunehmend diese Evaluationen direkt in die Trace-Daten, daher kann ein Span ein „hallucination: detected"-Label neben seinen Ein- und Ausgängen tragen. Die Kraft dieser Integration ist, dass Sie Ihren Produktions-Traffic genau auf die Aufrufe filtern können, die schlecht bewerteten, ihre Traces öffnen und die Ursache sehen — das Schleife von „Qualität ist gefallen" zu „hier ist der spezifische kaputte Retrieval" schließen.
Evaluation läuft in zwei Modi, die unterschiedlichen Zwecken dienen. Offline-Evaluation läuft über einen kuratierten Datensatz, bevor Sie liefern: Sie stellen repräsentative Eingaben (oft von echten Traces gesammelt) zusammen, führen Ihre Pipeline aus, bewerten die Ergebnisse und vergleichen gegen die vorherige Version. Dies ist Ihr Regression-Gate — es sagt Ihnen, ob eine Eingabeaufforderung oder Modell-Änderung hilfreich oder schadlich war, bevor Benutzer es fühlen. Online-Evaluation läuft gegen Live-Produktions-Traffic, Stichproben-Real-Aufrufe und bewertet sie kontinuierlich, daher fangen Sie Drift und neu auftauchende Fehler auf, die Ihr Offline-Datensatz nicht antizipiert. Ein ausgereiftes Setup verwendet beide: Offline zum Gate-Änderungen, Online zum Monitoring der Realität. Phoenix, Langfuse und die DeepEval-basierten Plattformen unterstützen alle dieses duale Modell, und das Koppeln mit einem Tracing-Backend ist das, was die Bewertungen actionierbar macht, anstatt nur Zahlen auf einem Dashboard.
Prompt-Verwaltung und die Feedback-Schleife
Eine dritte Fähigkeit rundet den Stack ab: Prompt- und Versionsverwaltung. LLM-Verhalten wird von Eingabeaufforderungen dominiert, und Eingabeaufforderungen ändern sich ständig — oft bearbeitet von Leuten, die nicht die Ingenieure sind, die die Bereitstellung besitzen. Ohne Versionierung ist eine Qualitätsverschlechterung vor drei Wochen nicht zurückverfolgbar; mit ihr können Sie einen Rückgang in Evaluierungs-Scores zur genauen Eingabeaufforderungs-Revision korrelieren, die ihn verursacht. Langfuse ist bemerkenswert dafür, dass es Eingabeaufforderungs-Versionierung und einen eingebauten Playground als First-Class-Funktionen neben Tracing und Eval behandelt, was eine Schleife schließt, die sonst offen bleibt: ein Problem in einem Trace beobachten, eine Hypothese bilden, die Eingabeaufforderung im Playground bearbeiten, die Änderung gegen einen Datensatz evaluieren und die Version liefern, die besser bewertet — alles innerhalb eines Systems.
Diese Schleife — tracen, evaluieren, anpassen, neu-evaluieren — ist der eigentliche Punkt der LLM Observability. Die individuellen Fähigkeiten sind Mittel dazu. Ein Team, das sehen kann, was seine Anwendung tat, messen kann, ob es gut war, Änderungen zu spezifischen Überarbeitungen zuordnen kann und Fixes gegen Daten validieren kann, hat LLM-Entwicklung von Vibes-basierter Iteration in eine Ingenieur-Disziplin umgewandelt. Diese Umwandlung, mehr als jedes einzelne Feature, ist das, was der 2026-Stack liefert.
Kosten- und Token-Observability
Eine Dimension, die LLM Observability von gewöhnlicher Überwachung unterscheidet, verdient ihre eigene Behandlung: Kosten. Jeder LLM-Aufruf hat einen Preis, gemessen in Tokens, und in einem agentischen System kann eine einzige Benutzer-Anfrage in Dutzende Modell-Aufrufe auffächern — Retrieval-Umformulierungen, Tool-Nutzungs-Argumentation, Multi-Agenten-Übergabe, Wiederholung. Die Gesamtrechnung kann sich aus Gründen aufblasen, die ohne Instrumentierung unsichtbar sind, und „unsere Inferenzikosten sind diesen Monat verdreifacht" ist eine Frage, auf die Tracing direkt antwortet. Weil jeder Span Token-Zählungen und Kosten aufzeichnet, können Sie Ausgaben nicht nur einem Feature zuordnen, sondern zu einem spezifischen Schritt in einem spezifischen Agenten-Argumente. Teams entdecken routinemäßig nur nach Instrumentierung, dass eine einzige schlecht begrenzte Retrieval-Schleife oder ein übereifriger Re-Ranking-Schritt einen überproportionalen Anteil ihres Token-Verbrauchs ausmacht.
Dies verwandelt Kosten von einer monatlichen Überraschung in eine Ingenieur-Metrik, die Sie optimieren können. Sie können die Token-Kosten von zwei Eingabeaufforderungs-Versionen in der Offline-Evaluation neben ihren Qualitäts-Scores vergleichen, wodurch der Qualitäts-vs-Kosten-Tradeoff explizit anstelle von geraten wird. Sie können Warnungen auf Pro-Anfrage-Token-Budgets setzen und einen ausreißer Agenten fangen, bevor er eine Rechnung ansammelt. Und Sie können die teuren-aber-Low-Value-Aufrufe identifizieren — die, die echtes Geld kosten und selten die Antwort ändern — und sie abschneiden. Im Jahr 2026 wird Kosten-Observability als First-Class-Teil des Observability-Stacks behandelt, genau weil LLM-Wirtschaft nutzungsbasiert ist und die Nutzung ohne Traces undurchsichtig ist. Ein Team, das Qualität optimiert, während es Token-Kosten ignoriert, optimiert die Hälfte des Problems.
Ein Tool wählen
Die drei Referenz-Tools bilden unterschiedliche Ausgangspunkte ab, und die richtige Wahl folgt aus dem, wo Ihr Team bereits ist. Arize Phoenix führt mit OpenTelemetry-nativer Tracing, Evaluation und besonders Retrieval-Debugging, mit starker Unterstützung für die Inspizierung von Embeddings und RAG-Verhalten; es ist ein natürlicher Fit, wenn OTel-native Portabilität und tiefes RAG/Agent-Debugging Prioritäten sind, und es läuft bequem von einem Notebook zu einem selbst-gehosteten Server. Langfuse paart Tracing mit First-Class-Eingabeaufforderungs-Verwaltung und einer Product-Analytics-Mentalität, wodurch es stark für Teams ist, die die volle Observe-Edit-Evaluate-Schleife in einem selbst-hostbaren, MIT-lizenzierten Paket wollen. MLflow erweitert die am weitesten verbreitete ML-Plattform in LLM-Tracing und Evaluation, was es zum Weg des geringsten Widerstands für Organisationen macht, die bereits auf MLflow für den Rest ihres ML-Lebenszyklus standardisiert sind und eine Plattform für Traces und Trace-Daten-Besitz wollen.
Jenseits dieser drei umfasst die Landschaft DeepEval und Confident AI auf der Evaluation-First-Ende, Comet Opik mit OpenTelemetry-Unterstützung und andere — aber die Auswahlkriterien sind konsistent. Bestehen Sie auf OpenTelemetry-nativer Instrumentierung, damit Sie nicht gesperrt sind. Bestätigen Sie, dass das Tool selbst hosten kann, wenn Ihre Daten sensibel sind. Überprüfen Sie, dass Tracing, Evaluation und Prompt-Verwaltung zusammenarbeiten, anstatt als angebrachte Silos, da der Wert in der Schleife liegt, nicht in den Teilen. Und starten Sie mit dem Tool, das die Reibung bei Ihrem bestehenden Stack minimiert, da die Observability, die Sie tatsächlich einsetzen, die ideale Observability schlägt, die Sie ständig einstellen möchten.
The Bottom Line
LLM Observability wurde 2026 zu einer echten Disziplin, weil Produktions-LLM-Anwendungen nicht-deterministisch, semantisch undurchsichtig und strukturell tief sind — drei Eigenschaften, die konventionelle Überwachung zu Fall bringen. Der Stack, der auf sie antwortet, tracet, um den Agenten-Call-Baum sichtbar zu machen, evaluation (LLM-as-Judge, Offline und Online), um Qualität zu messen, die Sie nicht augenzwinkern können, und Prompt-Versionierung, um Änderungen zu Ursachen zu attribuieren. OpenTelemetry ist das Bindewebe, das das Ganze interoperabel machte, und wählen Sie OTel-native Tools wie Phoenix, Langfuse oder MLflow ist wie Sie in einen Standard statt einen Anbieter investieren. Instrumentieren Sie Tracing zuerst, lagern Sie Evaluation oben auf, schließen Sie die Schleife mit Prompt-Verwaltung, und Sie verwandeln eine LLM-App von einer Blackbox, die manchmal misbehaves, in ein System, das Sie tatsächlich engineeren können.
Referenzen und Ressourcen
Tools
- Arize Phoenix — GitHub and docs
- Langfuse — observability overview
- MLflow and its agent observability guide
- DeepEval and OpenTelemetry
Background and analysis
- Top Open Source LLM Observability Tools in 2026 — OpenObserve
- Best LLM Observability Tools in 2026 — Firecrawl
- LLM Observability Tools — LangChain
Related 1337skills cheatsheets