LLM Observability

Was bedeutet LLM Observability?

LLM Observability bezeichnet die strukturierte Erhebung, Korrelation und Analyse aller relevanten Signale eines Sprachmodells (LLM) im produktiven Betrieb, mit dem Ziel, dessen Verhalten erklärbar, steuerbar und überprüfbar zu machen. Sie stellt nicht nur fest, dass ein System funktioniert, sondern liefert Einsicht in, warum es sich auf bestimmte Weise verhält, und bildet damit die Grundlage für Qualitätssicherung, Risikominimierung und Kostenkontrolle.

Die Funktionsweise beruht auf der kontinuierlichen Erfassung unterschiedlicher Datenebenen: Dazu gehören Eingaben und Ausgaben, Laufzeit- und Latenzwerte, Tokenverbrauch, Modellversionen, Tool- und API-Aufrufe, Fehlermeldungen sowie Interaktionsmuster der Nutzer. Diese Daten werden zentral gesammelt, miteinander verknüpft und über Auswertungen, Dashboards und Alarme kontextualisiert, um Abweichungen, ineffiziente Abläufe oder sicherheitskritische Muster sichtbar zu machen. Ergänzend kommen Verfahren zur Qualitätsbewertung von Antworten, zum Vergleich von Prompt-Versionen oder zur Erkennung unerwünschter Ausgaben zum Einsatz.

Auf diese Weise entsteht ein belastbares Gesamtbild darüber, wie sich das System in realen Nutzungsszenarien verhält, an welchen Stellen Probleme entstehen und welche Faktoren diese beeinflussen. Da dabei nicht nur Systemzustände, sondern auch semantische und inhaltliche Aspekte der Verarbeitung einbezogen werden, geht dieses Konzept deutlich über klassische Überwachung technischer Kennzahlen hinaus und bildet die inhaltliche Grundlage für die Abgrenzung zum traditionellen Monitoring.

Unterschiede von LLM Observability und LLM-Monitoring

Während LLM Observability auf Ursachenanalyse und Systemverständnis abzielt, fokussiert sich LLM-Monitoring auf die Erkennung von Abweichungen im laufenden Betrieb. Monitoring beantwortet primär die Frage, ob ein System wie erwartet funktioniert, während Observability klärt, warum es dies tut oder eben nicht.

Monitoring basiert in der Regel auf vordefinierten Metriken, Grenzwerten und Alarmregeln, etwa für Antwortzeiten, Fehlerraten, Ressourcenverbrauch oder ungewöhnliche Zugriffsmuster. Werden diese Schwellen überschritten, löst das System eine Warnung aus. Damit eignet sich Monitoring besonders zur frühzeitigen Problemerkennung und zum operativen Betrieb, bleibt jedoch auf bekannte und messbare Symptome beschränkt.

Observability korreliert Systemdaten, Anfragen, Antworten, Konfigurationen und Kontextinformationen, um die inneren Zusammenhänge eines LLMs sichtbar zu machen. Anhand eines Chatbots ergibt sich folgende Differenzierung: Sinkt die Antwortqualität, wird dies im Monitoring durch einen Alarm gemeldet. Observability ermöglicht anschließend die Ursachenanalyse, etwa durch den Nachweis einer geänderten Prompt-Vorlage, eines veralteten Retrieval-Index, einer veränderten Modellkonfiguration oder eines gestiegenen Anteils kritischer Nutzeranfragen.

Der entscheidende Unterschied liegt damit im Einsatzfeld: Monitoring ist zustandsorientiert und reaktiv, Observability ist erklärend und analytisch. Erst das Zusammenspiel beider Konzepte erlaubt nicht nur das Erkennen von Störungen, sondern auch deren systematische Analyse und nachhaltige Behebung.

Nachfolgend finden Sie eine vollständige Übersicht über die Unterschiede zwischen Observability und Monitoring:

Arten von LLM Observability-Signalen

Es gibt drei wichtige Metriken oder Signale, die wir bei der Implementierung der Observability verwenden können: Systemleistung, Modellverhalten und Ressourcenauslastung.

Systemleistung

Bei der Analyse der Systemleistung wird überprüft, ob sich das LLM-System in der Produktionsumgebung vergleichbar verhält wie in der Entwicklungs- oder Testphase. Dazu zählt insbesondere der Abgleich wichtiger Laufzeitkennzahlen, etwa, ob die Antwortlatenz den erwarteten Werten entspricht oder ob die Zeit bis zum ersten Token (TTFT) innerhalb der in Staging-Umgebungen gemessenen Grenzen liegt. Im Folgenden sind zentrale Metriken zur Bewertung der Systemleistung aufgeführt:

• Latenz: Misst die Gesamtzeit vom Senden einer Anfrage durch einen Benutzer bis zum Empfang der vollständigen Antwort. In der Produktion möchten wir im Allgemeinen, dass die Latenz innerhalb des in der Staging-Umgebung beobachteten Bereichs bleibt.
• Time to First Token (TTFT): Erfasst die Verzögerung, bevor das Modell mit der Generierung seines ersten Ausgabetokens beginnt. Diese Kennzahl steht in engem Zusammenhang mit der Latenz: Wenn die TTFT zunimmt, steigt auch die Gesamtlatenz. Die TTFT ist nützlich, um die Reaktionsfähigkeit des Modells zu bewerten, Latenzengpässe zu identifizieren und die Benutzererfahrung zu verbessern.
• Durchsatz: Misst, wie viele Anfragen das LLM-System pro Sekunde verarbeiten kann. Mit anderen Worten: Er gibt an, wie viele Abfragen das System gleichzeitig verarbeiten kann, ohne dass sich die Latenz verschlechtert. Wenn das System beispielsweise auf einer einzelnen A100-GPU in der Staging-Umgebung 60 Anfragen pro Sekunde verarbeiten kann, in der Produktion unter ähnlicher Last jedoch nur noch 30, müssen wir möglicherweise Probleme wie Autoscaling, Load Balancer oder Throttling untersuchen.
• Fehlerrate: Gibt den Prozentsatz der Benutzeranfragen an, die fehlschlagen oder eine Zeitüberschreitung verursachen. Ein gesundes System weist in der Regel eine Fehler- oder Zeitüberschreitungsrate von weniger als 0,1 % der Gesamtanfragen auf. Diese Metrik bietet einen Gesamtüberblick über die Zuverlässigkeit unseres Systems.

Modellverhalten

Die Erfassung von Metriken zum Modellverhalten dient dazu zu beurteilen, ob die generierten Antworten den fachlichen und qualitativen Anforderungen entsprechen und an welchen Stellen Optimierungspotenzial besteht. Welche Kennzahlen sinnvoll sind, hängt dabei vom jeweiligen Anwendungsfall ab.

Bei einer RAG-Anwendung (Retrieval-Augmented Generation) steht beispielsweise die inhaltliche Qualität im Vordergrund, etwa gemessen an Kontextrelevanz, Antwortrelevanz und Fundiertheit der Ausgaben. In anderen Einsatzszenarien werden eher allgemeinere Qualitätsindikatoren wie fachliche Korrektheit oder Nutzerinteraktionen herangezogen, um die Leistungsfähigkeit des Modells zu bewerten.

• Korrektheit: Dies ist die grundlegende Metrik zur Bewertung des Modellverhaltens. Sie misst, wie genau die Ausgabe des Modells mit der erwarteten Grundwahrheit übereinstimmt. In den meisten Fällen bereiten wir Grundwahrheitsdaten vor, damit wir Werte wie ROUGE, BLEU oder ähnliche Metriken berechnen können, die die Leistung des LLM einschätzen.
• Kontextrelevanz: Diese Metrik ist besonders wichtig in RAG-Pipelines und bewertet, wie relevant die abgerufenen Kontexte für die Anfrage des Benutzers sind. Der modernste Ansatz ist die Verwendung von LLM-as-a-judge, bei dem ein separates Modell einen Kontextrelevanzwert für die Anfrage des Benutzers und die abgerufenen Passagen vergibt.

• Antwortrelevanz: Diese misst, wie direkt die generierte Antwort auf die Anfrage eingeht, unabhängig von der sachlichen Richtigkeit. Ähnlich wie bei der Kontextrelevanz können wir den LLM-as-a-judge-Ansatz anwenden, indem wir beispielsweise ein Bewertungsmodell mit folgender Aufforderung versorgen:

  „Bewerten Sie auf einer Skala von 0 bis 1, wie direkt diese Antwort auf die Frage eingeht.“

• Fundiertheit: Die Fundiertheit ist ebenfalls ein wichtiger Faktor in RAG-Systemen und misst, ob die Aussagen in der endgültigen Antwort durch den abgerufenen Kontext gestützt werden. Auch hier könnten wir unter Verwendung von LLM-as-a-judge folgende Eingabe vornehmen:

  „Bewerten Sie anhand der Kontexte und der Antwort auf einer Skala von 0 bis 1, ob die Antwort aus den Kontexten abgeleitet werden kann.“

• Benutzerinteraktion: Dies liefert eine eher subjektive Messgröße für die Antwortqualität, wobei Signale wie Daumen-hoch-/Daumen-runter-Verhältnisse, Sitzungsdauer oder die Rate der Folgeanfragen verwendet werden. Eine hohe Interaktion kann darauf hindeuten, dass die Antworten nicht nur korrekt, sondern auch nützlich und für die Benutzer zufriedenstellend sind.

Ressourcennutzung

Die Analyse von Metriken zur Ressourcennutzung zeigt, wie effizient ein LLM-System Rechenleistung und Infrastruktur einsetzt. Ziel ist es, Engpässe zu erkennen und Leistung, Stabilität sowie Kostenstruktur zu optimieren, etwa in Bezug auf Durchsatz, Latenz oder Fehlerraten.

Wird beispielsweise festgestellt, dass die GPU-Auslastung während der Inferenz deutlich unter dem möglichen Maximum liegt, deutet dies auf ungenutztes Potenzial hin. In solchen Fällen lassen sich Effizienzgewinne durch angepasste Batch-Verarbeitung, optimierte Speicherverwaltung oder parallelisierte Datenpipelines erzielen, um die verfügbare Hardware besser auszuschöpfen.

• GPU/CPU-Auslastung: Misst, wie viel der verfügbaren Rechenressourcen vom LLM genutzt werden. Eine geringe Auslastung deutet oft auf Ineffizienzen bei der Aufgabenverteilung oder dem Batching hin, während eine anhaltend hohe Auslastung auf Engpässe oder die Notwendigkeit einer Skalierung hinweisen kann.
• Speichernutzung: Verfolgt, wie effizient sowohl die GPU als auch der Systemspeicher während der Inferenz oder des Trainings genutzt werden. Die Beobachtung dieser Werte hilft, Speicherfehler zu vermeiden, Speicherlecks zu identifizieren und sicherzustellen, dass die Speicherzuweisung den Anforderungen der Arbeitslast entspricht.
• Token-Nutzung: Stellt die Anzahl der pro Anfrage (oder im Laufe der Zeit) verarbeiteten oder generierten Token dar. Da die Token-Nutzung sich direkt auf Kosten und Effizienz auswirkt, können Teams durch deren Beobachtung Prompts optimieren, die API-Nutzung verwalten und Anomalien wie ineffiziente Abfragen oder Missbrauch erkennen.
• Festplatten-E/A (Eingabe/Ausgabe): Misst die Rate der auf die Festplatte gelesenen und geschriebenen Daten, was besonders wichtig für RAG-Workflows oder bei der Verarbeitung großer Datensätze ist. Eine hohe Festplatten-E/A kann auf eine langsame Speicherleistung oder einen übermäßigen Datentransfer zwischen Komponenten hinweisen.

LLM Observability-Lösungen

Mit der zunehmenden Verbreitung von LLM-Anwendungen in unterschiedlichen Branchen gewinnt Observability für einen stabilen und zuverlässigen Betrieb produktiver Systeme zunehmend an Bedeutung. Zur Unterstützung stehen inzwischen spezialisierte Plattformen zur Verfügung, die die Analyse, Bewertung und Fehlersuche in komplexen LLM-Architekturen vereinfachen.

Nachfolgend sind einige verbreitete Observability-Plattformen für LLM-Systeme aufgeführt:

Arize AI

• Anwendungsbereich: Am besten geeignet für LLM- und Agent-Observability, Modellbewertung, Drift-Erkennung und Ursachenanalyse. Arize AI bietet außerdem umfassende Unterstützung für beliebte LLM- und Agent-Frameworks wie LangChain, LlamaIndex und DSPy.
• Stärken: Arize AI ist eine Observability-Lösung für Unternehmen, die ausgereifte ML-Observability-Funktionen wie Trace-Wiedergabe, RAG/LLM-Bewertung und Prompt-Analyse erweitert. Sie wurde für Teams entwickelt, die eine einheitliche Ansicht benötigen, um mehrere Modelle und Agenten über verschiedene Umgebungen hinweg zu beobachten.
• Einschränkungen: Arize AI folgt einem Unternehmenspreismodell, was bedeutet, dass für erweiterte Bewertungs- und Anmerkungsfunktionen ein kostenpflichtiger Tarif erforderlich ist.

Fiddler AI

• Anwendungsbereich: Fiddler AI ist eine Unternehmensplattform für die Beobachtbarkeit und Überwachung von LLM, ähnlich wie Arize AI. Sie eignet sich besonders für Unternehmensumgebungen, in denen Sicherheit, Richtlinienkonformität und Governance innerhalb ihrer MLOps-Workflows im Vordergrund stehen.
• Stärken: Fiddler AI bietet ausgereifte ML-Beobachtbarkeitsfunktionen, die für LLMs angepasst sind. Dank seines starken Fokus auf die Integration von Richtlinien und Governance ist es besonders wertvoll für Unternehmen, die in regulierten Branchen tätig sind.
• Einschränkungen: Wie Arize AI verwendet auch Fiddler AI Unternehmenspreise, sodass für den Zugriff auf erweiterte Funktionen ein kostenpflichtiges Abonnement erforderlich ist.

LangSmith

• Anwendungsbereich: LangSmith ist eine Closed-Source-Observability-Plattform, die umfassende Tracing- und Evaluierungsfunktionen für LLM- und KI-Systeme bietet. Sie wurde vom LangChain-Team entwickelt und lässt sich nahtlos in LangChain-basierte Anwendungen integrieren.
• Stärken: LangSmith ist eng mit LangChain integriert und daher eine ausgezeichnete Wahl, wenn Ihr LLM- oder Agent-Workflow mit LangChain oder LangGraph erstellt wurde. Es wurde speziell für die Verfolgung mehrstufiger Agenten entwickelt, einschließlich Aktionen, Tool-Aufrufen und detaillierten Schritt-für-Schritt-Verfolgungen.
• Einschränkungen: Als Closed-Source-Produkt erfordert das Selbsthosting eine kommerzielle Lizenz. Wenn Sie LangSmith selbst hosten, sind die empfohlenen Mindestressourcen recht hoch: z. B. 16 GB RAM + 4 CPUs für die App. Dies macht das Selbsthosting teuer und für kleinere Teams möglicherweise schwierig.

Helicone

• Anwendungsbereich: Helicone ist eine Open-Source-basierte, proxybasierte Observability-Plattform, die wichtige LLM-Anbieter wie OpenAI, Anthropic und Google Gemini unterstützt. Der Schwerpunkt liegt auf Einfachheit und einfacher Einrichtung, sodass Benutzer LLM-Ausgaben protokollieren und analysieren sowie Benutzer-Feedback über die Helicone Feedback API sammeln können.
• Stärken: Helicone ist auf Einfachheit und schnelle Bereitstellung ausgelegt. Das proxybasierte Design ermöglicht Funktionen wie Caching, Sicherheitsüberprüfungen und API-Schlüsselverwaltung. Da es sich um Open Source handelt, kann es für mehr Kontrolle und Kosteneffizienz selbst gehostet werden.
• Einschränkungen: Aufgrund seiner Open-Source-Natur erfordert das Selbsthosting von Helicone aufgrund seiner verteilten Architektur eine fortgeschrittene Einrichtung. Einige erweiterte Funktionen (wie benutzerdefinierte Ratenbegrenzung, Caching) erfordern eine tiefere Integration, was für unerfahrene Teams möglicherweise nicht einfach einzurichten ist.

LangFuse

• Anwendungsbereich: LangFuse bietet umfassende Funktionen für die Verfolgung, Analyse, Bewertung, Prüfung und Kommentierung von LLM- und KI-Systemen, ähnlich wie LangSmith. Im Gegensatz zu LangSmith ist es jedoch Open Source.
• Stärken: LangFuse bietet die meisten Vorteile von LangSmith, einschließlich der LangChain-Integration, und unterstützt gleichzeitig andere LLM-Frameworks. Da es sich um Open Source handelt, kann LangFuse ohne Lizenzgebühren selbst gehostet werden, was Teams mehr Flexibilität und Kontrolle gibt.
• Einschränkungen: Das Open-Source-Modell bedeutet, dass wir als Nutzer selbst für die Skalierung und Verwaltung der Bereitstellung verantwortlich sind. Einige Funktionen auf Unternehmensebene sind nur in der kostenpflichtigen Version verfügbar.

Fazit

Die Implementierung der LLM Observability ist nicht mehr optional, sondern ein notwendiger Prozess, um sicherzustellen, dass LLM-basierte Systeme in der Produktion zuverlässig, effizient und vertrauenswürdig bleiben. Da Unternehmen zunehmend auf LLMs setzen, um kundenorientierte Anwendungen zu betreiben, wird die Fähigkeit, das Modellverhalten zu verfolgen, zu analysieren und zu verstehen, entscheidend für die Aufrechterhaltung der Qualität und die Vermeidung kostspieliger Fehler.

Die Beobachtbarkeit liefert Einblicke in die Gründe für bestimmte Ereignisse und gibt Teams die nötige Transparenz, um komplexe, nicht deterministische Workflows von LLM-basierten Systemen zu debuggen.