Konzeptkarte

LLM-Observability — Tracing, Token-Abrechnung, Halluzinationserkennung

Stand 2026-07-24T14:00:00Z

Redaktion: Cédric-Olivier Mâry, alleiniger Redakteur und verantwortlich für die Veröffentlichung — 27 Jahre im SAP-Ökosystem. Wie diese Seiten entstehen und wo Automatisierung eingesetzt wird.

Was ist LLM-Observability — Tracing, Token-Abrechnung, Halluzinationserkennung?

Klassische APM-Tools können nicht beantworten, ob die Antwort eines LLM tatsächlich richtig war — Observability-Plattformen schließen diese Lücke, indem sie 1-5 % des Traffics sowie 100 % der Antworten mit der geringsten Konfidenz gegen ein Judge-Modell prüfen.

LLM-Observability ist die Disziplin, für jeden Modellaufruf, den ein produktives System tätigt, zu sehen, was passiert ist, warum es passiert ist, was es gekostet hat und ob die Antwort tatsächlich richtig war. Konventionelles Application Performance Monitoring beantwortet die ersten beiden Fragen schlecht und die dritte und vierte gar nicht — es wurde für deterministische Codepfade gebaut, nicht für ein System, dessen Ausgabe von einem nahezu identischen Aufruf zum nächsten variiert. Eine neuere Generation zweckgebundener Plattformen ist speziell entstanden, um diese Lücke zu schließen, indem sie allgemeine Standards für verteiltes Tracing um Attribute erweitert, die für generative KI ausgelegt sind: welches Modell die Anfrage bediente, wie viele Input- und Output-Tokens es verbrauchte, was es kostete und wie lange es dauerte.

Die vier Flächen, auf die es ankommt

Verteiltes Tracing jedes Modellaufrufs ist die Grundlage. Jede Nutzeranfrage wird zu einem Baum verknüpfter Schritte — Nutzereingabe, etwaige Retrieval-Aufrufe, ein Reranking-Schritt, der Modellaufruf selbst, etwaige vom Modell ausgelöste Tool-Aufrufe und die endgültige Antwort —, erfasst als zusammenhängender Trace statt als eine Menge unzusammenhängender Log-Zeilen. Ohne diesen Trace ist das Debuggen einer falschen oder merkwürdigen Antwort in der Produktion nahezu Rätselraten, weil sich nicht erkennen lässt, welcher vorgelagerte Schritt die schlechte Eingabe tatsächlich erzeugt hat.

Warum es zählt

Vier Flächen sind nicht verhandelbar: verteiltes Tracing des vollständigen Span-Baums (Input → Retriever → Reranker → Modell → Tools → Antwort), Token-Abrechnung pro Aufruf getaggt nach Mandant/Workflow/Modell, gesampelte Qualitätsbewertung und Halluzinations-/Groundedness-Erkennung.
Die 2026er-OpenTelemetry-GenAI-Semantic-Convention-Spezifikation standardisiert Span-Attribute wie gen_ai.usage.input_tokens, übernommen von jedem ernstzunehmenden Observability-Anbieter (Langfuse, Arize Phoenix, LangSmith, Helicone).
Groundedness-Scoring erkennt RAG-spezifische Fehler (tauchen die Behauptungen der Antwort im abgerufenen Kontext auf?), während Toxizitäts-/PII-/Jailbreak-Klassifikatoren Sicherheitsfehler erkennen — zwei getrennte Fehlerklassen, die zwei getrennte Prüfungen erfordern.

Kernpunkte

OpenTelemetry-GenAI-Semantic-Conventions sind der Industriestandard 2026: `gen_ai.system`, `gen_ai.request.model`, `gen_ai.usage.input_tokens/output_tokens` usw.
Verteiltes Tracing des vollständigen Request-Span-Baums (Input → Retriever → Reranker → Modell → Tools → Antwort) ist für das Debugging nicht verhandelbar.
Token-Abrechnung pro Aufruf, getaggt mit Mandant + Workflow + Modell, ist das FinOps-Substrat (verwandtes Konzept C249).
Qualitätsbewertung: 1-5 % des Produktions-Traffics sampeln, gegen LLM-as-Judge oder Golden-Dataset erneut ausführen, den Score verfolgen, bei Drift alarmieren.
Halluzinationserkennung: Groundedness-Scoring für RAG; Toxizitäts-/PII-/Jailbreak-Klassifikatoren für Sicherheit; 100 % der Antworten mit niedriger Konfidenz sampeln.
Anbieterlandschaft: Langfuse, Arize Phoenix, LangSmith, Weights & Biases Weave, Helicone — einen auswählen und über OTLP integrieren.
LLM-Observability — Tracing, Token-Abrechnung, Halluzinationserkennung ist erst beherrscht, wenn es eine benannte Käuferentscheidung verändert.
Beginnen Sie mit dem semantischen Vertrag und dem Kontrollmodell, bevor Sie das Tool vorführen.
Nutzen Sie aktuelle SAP-, Analysten-, Studien-, KG- und News-Signale als Beleg, nicht als Dekoration.
Trennen Sie verifizierte Fakten von richtungsweisenden Trends und modellierten Annahmen.

Begriffe auf dieser Seite

OpenTelemetry GenAI: Semantic-Convention-Erweiterung des OpenTelemetry-Standards, die Standard-Span-Attribute für generative-KI-Aufrufe definiert (Modell, Tokens, Kosten, Tools).
LLM-as-judge: Evaluationsmuster, bei dem ein separates LLM die Qualität der Ausgabe eines anderen LLM anhand einer Rubrik bewertet; günstiger als menschliche Prüfung, verrauschter als menschliche Prüfung.
Groundedness: RAG-spezifische Qualitätsmetrik: Tauchen die Behauptungen in der Antwort im abgerufenen Kontext auf? Niedrige Groundedness = Halluzination.
OTLP: OpenTelemetry Protocol — das Übertragungsprotokoll zum Senden von Traces/Metriken/Logs von instrumentierten Anwendungen an Collectors und Backends.
Entscheidungsverantwortlicher: Die verantwortliche Person, die den Trade-off akzeptiert und die nächste Maßnahme finanziert.
Semantischer Vertrag: Die gemeinsame Definition von Geschäftsbegriffen, Kennzahlen, Entitäten und Zugriffsregeln, die von Tools und Teams verwendet wird.
Kontrollebene: Die Ebene, die Richtlinien, Zugriff, Herkunftsnachweis (Lineage), Monitoring und Eskalation über das Betriebsmodell hinweg durchsetzt.
Evidenzgrad: Eine Kennzeichnung, die verifizierte Fakten, richtungsweisende Signale, modellierte Annahmen und Feldbeobachtungen voneinander unterscheidet.

Quellen

Vollständige Karte für Mitglieder. Was die vollständige Karte ergänzt: den vollständigen Entscheidungsrahmen · den Vergleich SAP · Snowflake · Databricks · Fabric · die häufigen Fallstricke und ihre Behebung · die Kurzreferenz · die Architekturschemata · die Codeblöcke · die zitierfähigen Kennzahlen.

In der App öffnen →