Evaluation, Tracing und Observability von LLM- und Agenten-Anwendungen (LLMOps)

GenAI-Funktionen versagen leise: Antworten bleiben flüssig, werden aber nach einer Prompt-Änderung, einem Modell-Upgrade oder einer Datenänderung falsch, teuer oder regelwidrig. LLMOps-Plattformen zeichnen jeden Modellaufruf, Werkzeugaufruf und Retrieval-Schritt als Trace auf, bewerten Ausgaben offline auf Referenzdatensätzen und online im laufenden Betrieb und blockieren Releases, die schlechter werden. Das Ergebnis sind messbare Qualität, kontrollierte Kosten und die Test- und Protokollnachweise, die Aufsichtsbehörden zunehmend erwarten.

Problem & Nutzen

• Heute: Teams liefern einen Chatbot oder Agenten nach einer Handvoll manueller Stichproben aus und erfahren von Fehlern erst durch verärgerte Nutzer. Prompts liegen im Code oder in Tabellen, niemand weiß, welche Version welche Antwort erzeugt hat, und ein Modellwechsel ist ein Sprung ins Ungewisse. Klassische Unit-Tests (CODE-004) funktionieren bei nichtdeterministischem Text nicht, und Log-Werkzeuge (CODE-011) verstehen weder Prompts noch Retrieval oder Agentenverläufe.
• KI-Nutzen: reproduzierbare Qualitätsprüfungen, schnelleres Debugging mehrstufiger Agenten (welcher Werkzeugaufruf ging schief), sichere Modell- und Prompt-Änderungen, Kosten- und Latenzkontrolle je Funktion und Nachweise für Audits.
• Evidenzbasis: LLM-as-a-Judge stimmt bei vielen Aufgaben gut mit menschlichen Bewertern überein, hat aber bekannte Verzerrungen (Position, Ausführlichkeit, Eigenpräferenz); Bewerter müssen daher an menschlichen Labels kalibriert werden [5]. Hier wird keine Herstellerangabe zum ROI zitiert; messen Sie Ihre eigene Ausgangslage.

Varianten

• RAG-Evaluation: Präzision/Trefferquote des Retrievals, Kontextrelevanz, Treue zu den Quellen (siehe KNOW-002).
• Evaluation von Agentenverläufen: Korrektheit der Werkzeugwahl, Schrittzahl, Schleifenerkennung, Aufgabenerfolg.
• Test von Chatbots und Sprachagenten mit simulierten Nutzern: Vor dem Release rufen LLM-gesteuerte Personas mit Zielen, Akzenten, Unterbrechungen und Hintergrundgeräuschen den Agenten an oder chatten mit ihm in der CI/CD; Bewerter beurteilen Aufgabenerfüllung, Regeleinhaltung und Tonalität. Werkzeuge: Coval, Cekura, Hamming (SaaS mit Sitz in den USA; Hosting prüfen). Querverweise: CONV-001, CONV-002 und CONV-026.
• DSGVO-konformer Selbstbetrieb: Tracing und Evaluation vollständig in der eigenen EU-Infrastruktur betreiben, damit Prompts, die oft Kundendaten enthalten, nie bei einem SaaS-Anbieter landen (Weg C).
• Evaluation im Stil von Red-Teaming: gegnerische Testsätze für Jailbreaks und Datenabfluss, siehe SEC-014 und SEC-010.
• Private Nutzung/Hobby: lokales Phoenix oder Langfuse per Docker Compose, um Prompts und lokale Modelle zu vergleichen.

So funktioniert es

1. app instrumentation (OpenTelemetry / SDK)
2. trace store (LLM calls, tool calls, retrieval, sessions, cost, latency)
3. dataset curation (production failures
4. golden test cases)
5. offline evaluation (heuristics + LLM judge + human annotation queue)
6. regression gate in CI/CD (compare candidate prompt/model against baseline)
7. release
8. online evaluation on sampled live traces + user feedback
9. alerts and dashboards (drift, hallucination rate, cost, latency)
10. failures feed back into datasets

• Tracing: Jede Anfrage wird zu einem Baum aus Spans. Die OpenTelemetry-GenAI-Konventionen definieren Attribute für Modellaufrufe, Agentenschritte und MCP-Werkzeugaufrufe; so bleibt die Instrumentierung herstellerneutral [2].
• Bewerter: deterministische Prüfungen (JSON-Schema, Regex, exakte Übereinstimmung), Embedding-Ähnlichkeit, LLM-Bewerter mit Bewertungsrastern sowie Metrikbibliotheken wie Ragas oder DeepEval für RAG und Agenten.
• Prompt-Verwaltung: versionierte Prompts mit Labels (Staging, Produktion), entkoppelt von Code-Deployments.
• Mensch-in-der-Schleife (Human-in-the-Loop): Fachexperten labeln Stichproben in Annotationswarteschlangen; ihre Labels kalibrieren die Bewerter und überführen schwierige Fälle in den Referenzsatz. Release-Freigabe und Änderungen am Bewertungsraster bleiben bei Menschen.

Datenaufbereitung

Die Daten sind Traces, Testfälle und Labels; Aufbereitung heißt daher, eine Qualitäts-Ausgangslage aufzubauen (grob 25 bis 35 Prozent des Aufwands). Das Rohmaterial liegt in Anwendungslogs, Ticketsystemen, Chat-Verläufen, Support-Postfächern, Prompt-Tabellen und in den Köpfen der Fachexperten. Typische Lücken: keine Instrumentierung, über Code und Wikis verstreute Prompts, keine erwarteten Antworten, personenbezogene Daten in Prompts und Ausgaben und keine abgestimmte Definition einer „guten“ Antwort.

Schritte zur Aufbereitung: - Instrumentieren Sie eine Anwendung mit OpenTelemetry oder dem Hersteller-SDK und maskieren Sie personenbezogene Daten an der Quelle (PREP-022). - Sammeln Sie 50 bis 100 reale Fälle, darunter bekannte Fehler, aus Tickets und Nutzerfeedback (PREP-020, PREP-021). - Lassen Sie Fachexperten erwartete Antworten oder Bewertungsraster schreiben und mindestens 30 Stichproben labeln, um die Bewerter zu kalibrieren (PREP-018, PREP-016). - Legen Sie Kategorienschemata für Fehlertypen fest, bevor Sie diese klassifizieren (PREP-019). - Legen Sie Aufbewahrungs- und Zugriffsregeln für Trace-Daten fest (PREP-024, PREP-025). - Wo die Quelldokumente für RAG unordentlich sind, bereinigen Sie diese zuerst (PREP-013).

Der Zeitaufwand der Experten für das Labeln ist der eigentliche Engpass, nicht die Werkzeuge. Einen Reifegrad-Check finden Sie in GUIDE-003.

Umsetzungswege

Welcher Weg für wen

• smb: Weg C — Langfuse oder Phoenix laufen auf einem kleinen Server (HW1), Traces enthalten Kundendaten und bleiben in Ihrer eigenen EU-Infrastruktur, und dieselbe Plattform bedient jede KI-Funktion, die Sie später hinzufügen.
• enterprise: Weg C — eine gemeinsame interne Observability-Plattform für alle GenAI-Teams vermeidet bei hohem Volumen SaaS-Gebühren pro Trace, hält Prompts im Unternehmen und lässt sich in den vorhandenen OpenTelemetry-Stack einbinden.
• developer: Weg C — Docker Compose mit Langfuse, Phoenix oder Promptfoo bietet volle Kontrolle, keine Herstellerbindung und funktioniert mit lokalen Modellen.

Weg A — Kaufen (Standardsoftware)

• Observability- und Evaluations-SaaS: LangSmith (LangChain), Braintrust, Arize AX, Weights & Biases Weave, Datadog LLM Observability, Langfuse Cloud (EU-Datenregion; Langfuse GmbH, Berlin, inzwischen Teil von ClickHouse), Helicone, Maxim. Optionen der Hyperscaler: Azure AI Foundry Evaluations, Amazon Bedrock Evaluations.
• Sprach-/Chat-Simulation: Coval, Cekura, Hamming.
• Wählen Sie A, wenn: kleines Team, keine sensiblen Prompts, Ergebnisse in Tagen nötig. Prüfen Sie Datenregion, Aufbewahrung, PII-Maskierung, Unterauftragsverarbeiter und AVV.

Weg B — Auf Cloud-KI-Diensten aufbauen

• Bewertermodelle: ein starkes Spitzenmodell (Claude, GPT, Gemini, Mistral Large) über Endpunkte in EU-Regionen als Bewerter, mit strukturierten Ausgaben für Bewertungen samt Begründung. Verwenden Sie eine andere Modellfamilie als die getestete, um Eigenpräferenz zu verringern.
• Verbindungsschicht: OpenTelemetry-SDK oder OpenLLMetry-/OpenInference-Instrumentierung in ein beliebiges OTLP-Backend, Evaluations-Skripte in der CI (GitHub Actions, GitLab CI).
• Wählen Sie B, wenn: Sie bereits einen Observability-Stack betreiben und nur die Evaluationsschicht brauchen.

Weg C — Selbst betreiben (Open Source; empfohlen für DSGVO-sensible Teams)

• Plattformen: Langfuse (Docker Compose für Tests; Helm/Kubernetes, Terraform-Module für AWS, Azure, GCP im Produktivbetrieb; Komponenten Postgres, ClickHouse, Redis/Valkey, S3) [1]; Arize Phoenix (OpenTelemetry-nativ, einzelner Container); Opik (Comet); Promptfoo und DeepEval für CI-Testsuiten; Ragas für RAG-Metriken.
• EU-Hosting: Betrieb in souveränen EU-Clouds oder Clouds von EU-Anbietern (z. B. Hetzner, IONOS, OVHcloud, STACKIT, Scaleway) oder On-Premises.
• Bewerter: Open-Weight-Modelle (z. B. die Familien Qwen3, Llama, Mistral, gpt-oss) über vLLM oder Ollama; kleinere Bewerter brauchen mehr Kalibrierung. Der Observability-Stack selbst braucht nur CPU (HW1); ergänzen Sie eine GPU (HW2/HW3) nur, wenn Bewerter lokal laufen.
• Betriebsaufwand: Dimensionierung von ClickHouse und Speicher, Aufbewahrungsjobs, Updates; etwa einige Tage Plattformarbeit.

Weg D — Eigenes Training

Trainieren Sie einen kleinen Bewerter oder ein Reward-Modell auf Ihren eigenen menschlichen Labels per Feintuning, wenn die Bewerterkosten bei hohem Volumen hoch sind oder fachliche Bewertungsraster (rechtliche Tonalität, medizinische Sicherheit) von allgemeinen Modellen nicht abgedeckt werden. Nötig sind hunderte bis einige tausend konsistent gelabelte Beispiele und eine Prüfung der Übereinstimmung zwischen den Annotatoren.

Stand der Technik (2026)

• Standardisierung: Die OpenTelemetry-GenAI-Konventionen (Modellaufrufe, Agenten-Spans, MCP) wachsen zusammen, und die meisten Plattformen nehmen OTLP entgegen, was die Herstellerbindung verringert [2].
• Evaluation auf Agentenebene (Verlauf, Werkzeugnutzung und mehrstufige simulierte Dialoge) hat die Bewertung einzelner Prompts als Schwerpunkt abgelöst; Benchmark-Suiten wie tau-bench testen werkzeugnutzende Agenten gegen simulierte Nutzer [6].
• Online-Evaluationen und Annotationswarteschlangen laufen auf Stichproben von Produktions-Traces, Fehler werden automatisch in Datensätze überführt.
• Grenzen: Bewerter sind verzerrt und lassen sich austricksen; Ergebnisse mit synthetischen Personas entsprechen nicht dem Verhalten echter Nutzer; Nichtdeterminismus erfordert wiederholte Läufe und Konfidenzintervalle; Trace-Speicher wächst schnell und enthält personenbezogene Daten; Metriken wie „Treue zur Quelle“ sind Näherungswerte, keine Wahrheit.

Gemeinsame Bausteine & Kombinationen

• Qualitätsprüfung für CONV-001/002/026 (Chat und Sprache), KNOW-002 (RAG), AGENT-002 und AGENT-013 (Agenten), CODE-002 (Coding-Agenten).
• Angrenzend: CODE-004 (deterministische Tests), CODE-011 und CODE-010 (Logs, AIOps; gemeinsamer OTel-Collector und ClickHouse/Grafana), SEC-010 (Guardrails laufen inline, Evaluationen messen sie), SEC-014 (Red-Teaming).
• Gemeinsame Infrastruktur: Ein selbst betriebener vLLM-Bewerterserver kann mehrere Teams bedienen; ein Trace-Speicher für alle Anwendungen.

Aufwand, Kosten & Kennzahlen

• Weg A: Tage; Preis pro Trace/Ereignis oder Arbeitsplatz. Weg B: 2-6 Wochen. Weg C: 2-6 Wochen inkl. Absicherung; Kosten sind Infrastruktur plus Betrieb. Bewerteraufrufe dominieren oft die Kosten: Stichproben im Online-Verkehr ziehen.
• Kennzahlen: Evaluations-Bestehensquote gegenüber der Ausgangslage, Halluzinations-/Faktentreue-Rate, Übereinstimmung Bewerter-Mensch, Regressionen, die in die Produktion gelangen, mittlere Zeit bis zur Diagnose von Fehlern, Kosten und p95-Latenz pro Anfrage, Anteil der Produktionsfehler, die in Testfälle umgewandelt wurden.

Menschen & Veränderung

• Einbinden: Geschäftsleitung (Qualität und Risikobereitschaft), die Verantwortlichen jeder GenAI-Funktion, Entwickler und Fachexperten, die Stichproben labeln, die IT für das Hosting, die IT-Sicherheit für Zugriffskontrolle und Geheimnisse in Traces sowie den/die Datenschutzbeauftragte(n), weil Traces Prompts mit personenbezogenen Daten enthalten.
• Betriebsrat: ja. Traces interner Assistenten zeichnen auf, was Beschäftigte wann fragen; nach § 87 Abs. 1 Nr. 6 BetrVG genügt die objektive Eignung zur Überwachung (BAG), daher ist eine Betriebsvereinbarung ratsam. Legen Sie den Zweck fest (Qualität, nicht Leistungsbeurteilung), pseudonymisierte Nutzerkennungen, kurze Aufbewahrung und wer Traces öffnen darf. Die Hinzuziehung eines KI-Sachverständigen ist nach § 80 Abs. 3 BetrVG möglich.
• Datenschutz: Rechtsgrundlage und Datenminimierung für Traces, AVV (Art. 28 DSGVO) mit jedem SaaS-Anbieter, DSFA, wenn Gespräche von Beschäftigten oder Kunden systematisch und in großem Umfang ausgewertet werden (Art. 35 DSGVO). Annotatoren sehen personenbezogene Daten, beschränken Sie daher den Zugriff.
• KI-Kompetenz: Unterstützen Sie Annotatoren und Entwickler mit Schulungen zu Bewerter-Verzerrungen und zum Lesen von Evaluationsergebnissen (Art. 4 KI-Verordnung in der geänderten Fassung).
• Pilot und Kommunikation: Beginnen Sie mit einem Chatbot und einem kleinen Expertengremium; erklären Sie, dass das System die KI bewertet, nicht die Nutzer.
• Bedenken: „Das ist Überwachung“ — begegnen Sie dem mit der Betriebsvereinbarung und Pseudonymisierung.
• Menschen behalten die Kontrolle: Release-Freigabe und Bewertungsraster bleiben bei Menschen.

Siehe GUIDE-004, GUIDE-005 und GUIDE-011.

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): Das Werkzeug selbst hat minimales Risiko. Es unterstützt Pflichten für die überwachten Systeme: Hochrisiko-Systeme brauchen automatische Protokollierung (Art. 12), Tests auf Genauigkeit und Robustheit (Art. 15) und Beobachtung nach dem Inverkehrbringen (Art. 72); Chatbots brauchen Transparenz (Art. 50) [3]. Tests mit simulierten Nutzern dürfen bei der Evaluation von Assistenten am Arbeitsplatz oder in der Bildung keine Emotionserkennung bei Beschäftigten oder Lernenden enthalten (Verbot nach Art. 5).
• DSGVO: Traces enthalten Prompts und Ausgaben mit personenbezogenen Daten (Kunden, Beschäftigte). Nötig sind eine Rechtsgrundlage, Datenminimierung, PII-Maskierung vor der Speicherung, Aufbewahrungsfristen, AVV mit SaaS-Anbietern, Garantien für Übermittlungen bei US-Anbietern und keine Nutzung von Trace-Daten für das Modelltraining der Anbieter [4]. Der Selbstbetrieb in der EU ist die einfachste Antwort. Menschliche Annotatoren sehen personenbezogene Daten: Zugriff beschränken.
• Risiken und Gegenmaßnahmen: Bewerter-Verzerrung (an Menschen kalibrieren, Bewertermodelle wechseln); Preisgabe von Geheimnissen in Traces (Schwärzung auf SDK-Ebene); Herstellerbindung (OTLP); Goodhart-Effekte, wenn Teams auf den Evaluationssatz optimieren (privaten Testsatz zurückhalten, mit Produktionsdaten auffrischen).

Erste Schritte

1. Instrumentieren Sie eine Anwendung mit OpenTelemetry oder dem Langfuse-/Phoenix-SDK; maskieren Sie PII an der Quelle.
2. Sammeln Sie 50-100 reale Fälle (inkl. bekannter Fehler) in einem Referenzdatensatz mit erwartetem Verhalten.
3. Schreiben Sie 3-5 Bewerter: Schema-/Formatprüfungen, einen Bewerter für Faktentreue, einen für Regelkonformität; labeln Sie 30 Stichproben von Hand und messen Sie die Übereinstimmung der Bewerter.
4. Fügen Sie die Suite (z. B. Promptfoo) zur CI hinzu und blockieren Sie Merges, die die Werte senken; verlagern Sie Prompts in eine Registry.
5. Schalten Sie stichprobenbasierte Online-Evaluation, Kosten-/Latenzalarme und eine wöchentliche Durchsicht fehlgeschlagener Traces ein.

Quellen

1. Langfuse - self-hosting documentation - https://langfuse.com/self-hosting
2. OpenTelemetry - Semantic conventions for generative AI - https://opentelemetry.io/docs/specs/semconv/gen-ai/
3. Regulation (EU) 2024/1689 (AI Act) - https://eur-lex.europa.eu/eli/reg/2024/1689/oj
4. Regulation (EU) 2016/679 (GDPR) - https://eur-lex.europa.eu/eli/reg/2016/679/oj
5. Zheng et al. - Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena - https://arxiv.org/abs/2306.05685
6. Yao et al. - tau-bench: tool-agent-user interaction benchmark - https://arxiv.org/abs/2406.12045
7. Arize Phoenix - open-source LLM tracing and evaluation - https://github.com/Arize-ai/phoenix
8. Promptfoo - LLM evaluation and red-teaming - https://github.com/promptfoo/promptfoo