LLM Observability Architektur 2026: 5 Auswahlfragen

Pexon Consulting | 12 Min. Lesezeit | 20.07.2026

TL;DR

Eine tragfähige LLM Observability Architektur verbindet Anwendungstraces, OpenTelemetry-Routing, APM und Qualitätsevaluation. Pexon Consulting ordnet diese Bausteine als deutscher Microsoft-Partner für Architektur- und Plattformteams herstellerneutral ein. Fünf Auswahlfragen, drei Deploymentmuster und eine gewichtbare Scorecard führen von der Tool-Demo zu einer prüfbaren Enterprise-Entscheidung.

Das Problem: Klassisches APM sieht nur einen Teil

Klassisches APM erkennt langsame Requests, Exceptions und ausgelastete Dienste. Es beantwortet aber nicht, warum ein Agent das falsche Tool aufgerufen oder ein RAG-System eine unbelegte Antwort geliefert hat. Genau diese Lücke muss eine LLM Observability Architektur schließen, ohne die vorhandene Betriebsüberwachung zu duplizieren.

Im Architekturworkshop liegen oft vier Vorschläge auf dem Tisch. Das AI-Team möchte eine Spezialplattform für Traces und Evaluationen. Das Observability-Team will die vorhandene APM-Landschaft erweitern. Security verlangt zentrale Filterung und SIEM-Anbindung. Die Cloud-Plattform bringt bereits eigene GenAI-Dashboards mit.

Jede Option kann richtig sein. Problematisch wird es, wenn ein Produkt gewählt wird, bevor die benötigten Entscheidungen feststehen. Ein technisch erfolgreicher Request kann fachlich falsch sein. Ein vollständiger Trace ist noch kein Qualitätsurteil. Und ein gespeicherter Prompt ist noch keine verwaltete Promptversion.

Unsere Position ist deshalb klar: Starten Sie mit den Fehlerbildern und Verantwortlichkeiten, nicht mit der Toolliste.

Was eine LLM Observability Architektur abdecken muss

LLM Observability umfasst drei getrennte Ebenen: technischen Betrieb, den konkreten Ausführungspfad und die fachliche Qualität. Erst ihre Verbindung macht eine Antwort untersuchbar. Ein Unternehmen sollte diese Ebenen gemeinsam anzeigen können, ihre Signale aber bewusst nicht zu einem undurchsichtigen Gesamtscore vermischen.

Zu einer vollständigen Sicht gehören außerdem Release, Umgebung, Modell-ID, Promptversion und Retrievalkonfiguration. Ohne diese Metadaten ist ein Qualitätsabfall sichtbar, aber nicht zuverlässig einer Änderung zuzuordnen.

Wichtig ist auch die zeitliche Perspektive. Ein Regressionstest vergleicht einen Release-Kandidaten auf einem stabilen Dataset mit einer Baseline. Produktionsdrift beschreibt eine Veränderung realer Eingaben oder Qualitätsverteilungen über die Zeit. Ein einzelner schlechter Output beweist keinen Drift, und ein Driftsignal erklärt noch nicht seine Ursache.

EU AI Act 2026: Unterstützung, keine automatische Compliance

LLM Observability kann Protokollierung, Monitoring, Risikomanagement und technische Nachvollziehbarkeit unterstützen. Sie macht eine Anwendung aber nicht automatisch konform. Entscheidend sind Verwendungszweck, Risikoklasse und Rolle des Unternehmens als Anbieter, Betreiber oder Anbieter eines Modells mit allgemeinem Verwendungszweck im jeweiligen organisatorischen Kontext.

Die offizielle Zeitleiste der Europäischen Kommission berücksichtigt inzwischen die Änderungen durch den Digital Omnibus on AI. Große Teile der Verordnung werden ab 2. August 2026 anwendbar. Die Hochrisikoregeln für eigenständige Systeme nach Anhang III folgen am 2. Dezember 2027, für in regulierte Produkte eingebettete Systeme am 2. August 2028.

Der Rat der EU gab dem Digital Omnibus am 29. Juni 2026 seine finale Zustimmung. Dieses Ereignis liegt weniger als 90 Tage zurück und ist für ältere AI-Act-Beiträge ein wichtiger Aktualisierungspunkt.

Für betroffene Hochrisiko-Systeme behandelt die Verordnung unter anderem Risikomanagement, technische Dokumentation, automatische Aufzeichnungen, menschliche Aufsicht und Post-Market-Monitoring. Ein Trace kann dafür Evidenz liefern. Er ersetzt weder die rechtliche Klassifizierung noch die vollständige Dokumentation oder die Governance-Prozesse.

Pexon Consulting verknüpft diese technische Perspektive mit KI Governance. Dieser Beitrag ist dennoch keine Rechtsberatung. Rollen, Termine und Pflichten müssen für den konkreten Use Case geprüft werden.

Referenzarchitektur: Standards vor Backends

Eine portable Architektur trennt Instrumentierung, Datenkontrolle, Routing und Auswertung. OpenTelemetry bietet dafür das technische Transport- und Trace-Modell. Ein Spezialbackend ergänzt LLM-spezifische Auswertung und Evaluation. APM, SIEM und Langzeitspeicher behalten jeweils eine klar begrenzte Aufgabe. Diese Trennung verhindert doppelte Datensammlung und unklare Zuständigkeiten.

Ein OpenTelemetry-natives SDK ist nicht dasselbe wie ein eigenständiger Collector. Das SDK erzeugt und exportiert Telemetrie im Prozess. Der OpenTelemetry Collector ist ein separat betriebener Dienst zum Empfangen, Verarbeiten und Weiterleiten. Die aktuelle Collector-Version v0.156.0 erschien am 7. Juli 2026.

Direkt an ein Spezialbackend

Die Anwendung exportiert direkt an eine LLM-Observability-Plattform. Das ist für ein einzelnes Produktteam einfach und schnell. Bei mehreren Anwendungen verteilen sich Masking, Sampling und Exportkonfiguration jedoch über viele Codebasen. Die Korrelation mit dem vorhandenen APM muss zusätzlich entworfen werden.

Zentrales OpenTelemetry-Routing

Ein Collector-Pfad nimmt Telemetrie zentral an und verteilt sie an APM, LLM-Backend und SIEM. Dieses Muster verbessert Portabilität und Datenkontrolle. Dafür werden Collector-Skalierung, Schema-Governance, Fehlertoleranz und ein klares Team für den Plattformbetrieb benötigt.

Gateway plus anwendungsnahe Traces

Ein LLM-Gateway sieht Provider, Modelle, Quoten, Tokens und Kosten. Die Anwendung sieht Retrieval, Agentenschritte und fachliche Tools. Erst ein gemeinsamer Trace-Kontext verbindet beide Perspektiven. Ohne ihn entstehen zwei Teilbilder, die bei einem Produktionsfehler manuell zusammengesucht werden müssen.

Toolauswahl: Fünf Fragen statt einer Rangliste

Es gibt kein universell bestes LLM-Observability-Produkt. Die passende Kombination hängt von Fehlerbildern, Deployment, vorhandenem Stack, Evaluationsbedarf und Portabilität ab. Diese fünf Fragen machen Produktversprechen vergleichbar und verhindern, dass ein einzelnes starkes Dashboard die Architekturentscheidung im späteren Betrieb und Einkauf dominiert.

1. Welche Fehler müssen Sie erkennen und entscheiden?

Beginnen Sie mit konkreten Fragen. Welcher Retriever lieferte die falsche Passage? Welcher Release erhöhte unbelegte Antworten? Hat ein Agent ein nicht erlaubtes Tool aufgerufen? Welcher Tenant verursacht Kosten? Zu jeder Frage gehören ein Signal, ein Owner und eine definierte Reaktion.

2. Wo dürfen Telemetriedaten verarbeitet werden?

Prompts und Antworten können personenbezogene Daten, Quellcode oder Geschäftsgeheimnisse enthalten. Prüfen Sie SaaS, Managed Service, Self-Hosting, Hybrid und gegebenenfalls Air-Gap nicht nur als Produktlabel. Entscheidend sind Datenfluss, Region, Administrationszugriff, Verschlüsselung, Löschung, Backup und Betriebsverantwortung.

3. Welcher bestehende Stack soll weiter genutzt werden?

Ein vorhandenes Datadog-, Dynatrace-, New-Relic- oder Cloud-Monitoring kann technische Signale bereits gut abdecken. Spezialplattformen wie Langfuse, LangSmith, Phoenix oder Braintrust ergänzen häufig tiefere Datasets, Experimente und Promptkontexte. Gateway-Lösungen liefern wiederum eine zentrale Provider- und Kostensicht.

4. Wie tief muss Evaluation integriert sein?

Ein Scorefeld allein ist noch keine Evaluationspipeline. Prüfen Sie Offline-Experimente, Online-Sampling, deterministische Checks, LLM-as-a-Judge, Human Review und CI/CD-Gates getrennt. Judge-Modell, Rubrik und Version sind Teil der Messinfrastruktur und müssen gegen menschliche Bewertungen kalibriert werden.

5. Wie wechseln Sie Backend oder Betriebsmodell?

OTLP-Unterstützung verbessert Portabilität, garantiert sie aber nicht. Exportieren Sie im Proof of Concept testweise Traces, Scores, Datasets, Promptversionen und Feedback. Prüfen Sie APIs, Schema, Rate Limits und proprietäre Evaluationsobjekte. Ein Exit-Plan ist erst belastbar, wenn ein Export tatsächlich funktioniert hat.

Bewerten Sie jeden Punkt von eins bis fünf und vergeben Sie organisationsspezifische Gewichte. Ein Ausschlusskriterium darf nicht durch einen hohen Gesamtscore kompensiert werden. Unsere Empfehlung: Verlangen Sie für jede hohe Bewertung einen Testnachweis oder eine verbindliche Vertragsaussage.

Langfuse als konkretes Implementierungsprofil

Langfuse ist eine mögliche Spezialplattform für Tracing, Datasets, Evaluation und Prompt Management. Es ist weder das Zentrum der Referenzarchitektur noch die automatische Empfehlung für jedes Unternehmen. Seine OpenTelemetry-Anbindung und Self-Hosting-Optionen machen es jedoch zu einem geeigneten Beispiel für den Weg vom Trace zum Quality Gate.

Zum Stand 20. Juli 2026 ist das Langfuse Python SDK v4.14.1 aktuell. Das öffentliche Langfuse-Repository weist zu diesem Stichtag 31.476 GitHub-Sterne aus. Solche Frischewerte helfen bei der Einordnung, müssen aber vor einer Beschaffung zusammen mit Releasepolitik, Support und Lizenzmodell erneut geprüft werden.

Abstrahiertes Python-Beispiel

Das folgende Beispiel zeigt nur das Instrumentierungsprinzip. Die Modell-ID gpt-5-mini dient als generisches Metadatenbeispiel. Manuelle Observations erfassen keine Rohfragen oder Dokumentinhalte. Der Callback kann je nach Konfiguration Prompt und Antwort erfassen und benötigt deshalb vor Produktion Redaction und Datenfreigabe. Der zugrunde liegende interne Demonstrator und sein vollständiger Quellcode sind nicht öffentlich zugänglich.

from langfuse import get_client, observe, propagate_attributes
from langfuse.langchain import CallbackHandler

client = get_client()

@observe(capture_input=False, capture_output=False)
def answer_question(question, retriever, model):
    with propagate_attributes(metadata={"model": "gpt-5-mini"}):
        with client.start_as_current_observation(name="retrieve", as_type="retriever") as span:
            documents = retriever.invoke(question)
            span.update(metadata={"document_count": len(documents)})
        context = "nn".join(doc.page_content for doc in documents)
        response = model.invoke(f"Kontext:n{context}nnFrage: {question}",
                                config={"callbacks": [CallbackHandler()]})
        return response.content

Was der interne Demonstrator belegt

In einem internen Python-RAG-Demonstrator umfasst der Root-Trace Retrieval, Promptkonstruktion und Modellaufruf. Der Demonstrator exportiert direkt an Langfuse Cloud. Ein kuratiertes Dataset bewertet Answer Relevance und Faithfulness. Konfigurationsexperimente vergleichen Chunkingvarianten gemeinsam mit Latenz, Token und Kosten.

Das ist technische Evidenz für das Muster, aber kein veröffentlichter Benchmark. Die vorhandenen älteren Ergebnisbilder zeigen keinen aktuellen vollständigen Lauf. Deshalb enthält dieser Artikel weder Qualitätswerte noch behauptete Verbesserungsprozente.

Pexon Consulting nutzt das Beispiel, um die Schnittstelle zwischen GenAI Engineering, sicherem Cloud-Betrieb und Evaluation greifbar zu machen. Ein OpenTelemetry Collector wäre eine mögliche Enterprise-Erweiterung, ist aber nicht Bestandteil des untersuchten Demonstrators.

Vom POC zum kontrollierten Produktivbetrieb

Der Production Gap entsteht selten beim ersten Modellaufruf. Er entsteht bei Datenklassifikation, SSO, Mandantentrennung, Last, Retention, Evaluationspflege und klarer Rufbereitschaft. Eine belastbare Einführung beginnt deshalb mit einem Workflow und skaliert erst, wenn Telemetrie, Qualitätsgrenzen und Ownership im Alltag gemeinsam funktionieren.

1. Definieren Sie zwei bis drei priorisierte Fehlerbilder und die zugehörigen Reaktionen.
2. Instrumentieren Sie Root-Workflow, Retrieval, Modell und Tools mit Release- und Umgebungsmetadaten.
3. Klassifizieren und maskieren Sie sensible Inhalte vor dem Export.
4. Erstellen Sie ein repräsentatives Dataset und kalibrieren Sie Judges gegen Human Reviews.
5. Vergleichen Sie Qualität, Kosten und Latenz in einem beobachtenden Quality Gate.
6. Führen Sie Sampling, Alerts, Retention und Eskalationswege erst danach breiter ein.

Häufig gestellte Fragen

Die häufigsten Fragen betreffen weniger einzelne Features als die Systemgrenzen. Unternehmen wollen wissen, was ihr bestehendes APM bereits leistet, wann eine Spezialplattform sinnvoll ist und welche laufenden Kosten entstehen. Die Antworten hängen vom Use Case ab, lassen sich aber mit klaren Kriterien eingrenzen.

Was gehört zu einer LLM Observability Architektur?

Sie umfasst Instrumentierung, Traces, Betriebsmetriken, Redaction, Routing, ein oder mehrere Backends, Evaluation und Human Review. Prompt-, Modell-, Release- und Umgebungsmetadaten verbinden diese Bausteine. Governance legt zusätzlich fest, wer Daten sehen und auf Signale reagieren darf.

Reicht unser bestehendes APM?

Für Fehler, Latenz und Infrastruktur kann es ausreichen. Prüfen Sie zusätzlich, ob Retrieval, Agentenschritte, Promptkontext, Datasets und Quality Gates in der benötigten Tiefe abgebildet werden. Häufig ist eine Ergänzung wirtschaftlicher als ein vollständiger Ersatz.

Langfuse oder Enterprise-APM: Was ist der Unterschied?

Langfuse fokussiert LLM-Traces, Promptkontext und Evaluation. Enterprise-APM korreliert Anwendung, Netzwerk, Datenbank und Infrastruktur. Wenn beide Perspektiven benötigt werden, ist eine hybride Architektur mit gemeinsamem Trace-Kontext meist sinnvoller als eine Entweder-oder-Entscheidung.

Was kostet LLM Observability im Unternehmen?

Die Kosten hängen von Trace-Volumen, gespeicherten Inhalten, Retention, Evaluatoraufrufen und Deploymentmodell ab. Bei Self-Hosting kommen Datenbank-, Backup-, Upgrade- und Betriebsaufwand hinzu. Ein belastbarer Vergleich verwendet das erwartete Lastprofil statt öffentlicher Listenpreise allein. Der Beitrag zum Tokenverbrauch und LLM-Kostenmanagement mit Langfuse vertieft diese Kostensicht.

Wie unterstützt LLM Observability die EU-AI-Act-Compliance?

Sie kann Logs, Monitoring, Nachvollziehbarkeit und Post-Market-Beobachtung technisch unterstützen. Ob und welche Pflichten gelten, hängt von Rolle, Zweck und Risikoklasse ab. Ein Observability-Backend ersetzt weder Rechtsprüfung noch Risikomanagement, technische Dokumentation oder menschliche Aufsicht.

Nächster Schritt

Wenn Sie zwischen Spezialplattform, vorhandenem APM und OpenTelemetry-Architektur entscheiden, sollte der nächste Schritt kein weiterer Produkttermin sein. Bringen Sie einen realen Workflow, seine sensiblen Daten, zwei Fehlerbilder und das erwartete Lastprofil in ein gemeinsames Architekturgespräch. Daraus entsteht eine prüfbare Shortlist.

Verwandte Themen

Die folgenden drei Beiträge vertiefen Grundlagen, Produktvergleich und ein konkretes Azure-Deployment. Sie ergänzen diesen Architekturleitfaden, ohne seine herstellerneutrale Auswahlmethodik zu wiederholen. Für Umsetzungsdetails führen sie von den Grundlagen über die Produktauswahl bis zum sicheren Azure-Betrieb in regulierten Umgebungen und vermeiden dabei eine erneute allgemeine Toolrangliste.