Die Black Box enthüllen: Praktische Observabilität für LLM-Anwendungen – Eine Fallstudie

Der Aufstieg der LLM-Anwendungen und das Imperativ der Observierbarkeit

Große Sprachmodelle (LLM) haben die Entwicklung von Anwendungen revolutioniert und ermöglichen Funktionen, die zuvor der Science-Fiction vorbehalten waren. Von intelligenten Chatbots und Inhaltsgeneratoren bis hin zu ausgeklügelten Code-Assistenten und Datenanalyse-Tools treiben LLM eine neue Generation von Software voran. Diese Leistungsfähigkeit bringt jedoch auch eine Reihe einzigartiger Herausforderungen mit sich. Im Gegensatz zu traditionellen deterministischen Anwendungen sind LLM intrinsisch probabilistisch und zeigen oft nichtlineare Verhaltensweisen, subtile Vorurteile und gelegentliche „Halluzinationen“. Das Debuggen und Optimieren dieser Anwendungen kann sich anfühlen wie der Blick in eine Black Box.

Hier wird Observierbarkeit nicht nur zu einer Best Practice, sondern zu einer absoluten Notwendigkeit. Die Observierbarkeit für LLM-Anwendungen geht über traditionelle Systemmetriken (CPU, Speicher, Netzwerk) hinaus. Sie untersucht die qualitativen Aspekte der Modellleistung, die Nuancen des Anfrage-Engineerings, die Effizienz von Retrieval-augmented Generation (RAG)-Pipelines und die gesamte Benutzererfahrung. Ohne eine solide Observierbarkeit müssen Entwickler raten, warum eine Anfrage nicht das gewünschte Ergebnis liefert, warum eine RAG-Anfrage keine relevanten Dokumente zurückholt oder warum die Leistung einer Anwendung nachgelassen hat.

Fallstudie: „DocuChat“ – Eine interne LLM-Wissensdatenbankanwendung

Betrachten wir eine praktische Fallstudie: „DocuChat“, eine interne Unternehmensanwendung, die es Mitarbeitern ermöglicht, auf riesige interne Wissensdatenbanken (z. B. Richtliniendokumente, technische Handbücher, HR-Richtlinien) mithilfe natürlicher Sprache zuzugreifen. DocuChat verwendet eine ausgeklügelte RAG-Architektur, die ein LLM mit einer Vektordatenbank kombiniert, die Embeddings interner Dokumente speichert. Mitarbeiter können Fragen stellen wie: „Wie lautet die Richtlinie zu den Kosten für Remote-Arbeit?“ oder „Wie konfiguriere ich die Single Sign-On für das neue HR-System?“

Grundarchitektur von DocuChat:

• Frontend: Eine einfache Weboberfläche für die Benutzereingabe und die Anzeige von Antworten.
• Backend-API: Verwaltet Benutzersitzungen, orchestriert die Interaktionen.
• RAG-Pipeline:
  • Vorverarbeitung der Anfragen: Reinigt und potenziell umschreibt die Anfragen der Benutzer.
  • Vektordatenbank (z. B. Pinecone, Weaviate): Speichert die Embeddings der Dokumente.
  • Retrieval-Modul: Fragt die Vektordatenbank ab, um relevante Dokumententeile basierend auf der verarbeiteten Benutzeranfrage zu finden.
  • Kontext-Builder: Stellt die abgerufenen Teile zu einem kohärenten Kontext für das LLM zusammen.
• LLM-Integration (z. B. OpenAI GPT-4, Llama 2): Nimmt die Benutzeranfrage und den abgerufenen Kontext entgegen, um eine Antwort zu generieren.
• Post-Processing der Ausgabe: Formatiert die Antwort des LLM für die Anzeige.

Die Herausforderungen der Observierbarkeit in DocuChat

Zu Beginn wurde DocuChat mit einer grundlegenden Protokollierung gestartet. Als Probleme auftraten, war das Debuggen ein echtes Albtraum:

• „Die Antwort ist falsch“: War es eine falsche Anfrage? Relevante Dokumente wurden nicht abgerufen? Eine Halluzination?
• „Es ist langsam“: Wo liegt der Engpass? Suche in der Vektordatenbank? Inferenzzeit des LLM?
• „Es werden nicht die richtigen Dokumente verwendet“: Warum hat das Retrieval-Modul versagt? Schlechte Embeddings? Falsche Formulierung der Anfrage?
• „Das Modell scheint voreingenommen zu sein“: Welche Eingaben führen zu voreingenommenen Ausgaben?

Praktische Observierbarkeit für DocuChat implementieren

Um diese Herausforderungen zu meistern, hat das DocuChat-Team eine umfassende Observierbarkeitsstrategie entwickelt, die sich auf vier Schlüsselbereiche konzentriert: Protokollierung, Tracing, Metriken und Benutzerfeedback.

1. Verbesserte Protokollierung: Granulare Einblicke in jedem Schritt

Über die einfache Protokollierung von Anfragen/Antworten hinaus wurde die Protokollierung von DocuChat erweitert, um kritische Informationen in jedem Schritt der RAG-Pipeline zu erfassen.

Beispiele für erweiterte Protokolle:

• Protokoll der Benutzeranfragen:

  {
   "timestamp": "2023-10-27T10:00:01Z",
   "session_id": "sess_abc123",
   "user_id": "user_456",
   "original_query": "Wie lautet die Richtlinie zu den Kosten für Remote-Arbeit?",
   "request_id": "req_def789"
  }

• Protokoll der Vorverarbeitung der Anfragen:

  {
   "timestamp": "2023-10-27T10:00:01Z",
   "request_id": "req_def789",
   "stage": "query_preprocessing",
   "processed_query": "Richtlinie zu den Kosten für Remote-Arbeit",
   "rewritten": false,
   "latency_ms": 15
  }

• Protokoll des Retrieval-Moduls (entscheidend für RAG):

  {
   "timestamp": "2023-10-27T10:00:02Z",
   "request_id": "req_def789",
   "stage": "retrieval",
   "search_query": "Richtlinie zu den Kosten für Remote-Arbeit",
   "retrieved_chunks": [
   {
   "chunk_id": "doc_123_chunk_a",
   "document_title": "Richtlinie zur Remote-Arbeit v2.1",
   "score": 0.92,
   "content_snippet": "...Mitarbeiter sind berechtigt, die Kosten für Remote-Arbeit erstattet zu bekommen..."
   },
   {
   "chunk_id": "doc_456_chunk_b",
   "document_title": "Richtlinien zur Kostenerstattung",
   "score": 0.88,
   "content_snippet": "...Alle Kosten für Remote-Arbeit müssen vorab genehmigt werden..."
   }
   ],
   "num_chunks_retrieved": 2,
   "latency_ms": 150,
   "vector_db_query_params": {"k": 5, "metric": "cosine"}
  }

• Protokoll der LLM-Inferenz:

  {
   "timestamp": "2023-10-27T10:00:03Z",
   "request_id": "req_def789",
   "stage": "llm_inference",
   "model_name": "gpt-4",
   "input_tokens": 512,
   "output_tokens": 120,
   "prompt_template_version": "v3.1",
   "llm_api_cost": 0.005,
   "latency_ms": 1200,
   "full_prompt_hash": "abcdef123" // Hash des tatsächlich an das LLM gesendeten Prompts
  }

• Protokoll der endgültigen Antwort:

  {
   "timestamp": "2023-10-27T10:00:04Z",
   "request_id": "req_def789",
   "final_response": "Laut der Richtlinie zur Remote-Arbeit v2.1 und den Richtlinien zur Kostenerstattung sind Mitarbeiter berechtigt, die Kosten für Remote-Arbeit erstattet zu bekommen, die vorab genehmigt wurden.",
   "response_quality_score": null, // Wird durch das Feedback ausgefüllt
   "overall_latency_ms": 1400
  }

Diese Protokolle, die in einem zentralen Protokollierungssystem (z. B. Elasticsearch, Splunk) gespeichert werden, ermöglichen eine leistungsstarke Suche, Filterung und Mustererkennung. Zum Beispiel kann die Suche nach „ „score“ : < 0.7 “ in den Retrieval-Protokollen potenzielle Probleme mit der Relevanz der Dokumente signalisieren.

2. Verteiltes Tracing: Den Verlauf der Anfrage verfolgen

Während Protokolle Momentaufnahmen bieten, verbindet das Tracing diese Momentaufnahmen zu einer vollständigen Erzählung einer einzelnen Anfrage. Durch die Verwendung von OpenTelemetry hat DocuChat seine Dienste instrumentiert, um Traces zu generieren, die die gesamte RAG-Pipeline abdecken.

Schlüsselschritte des Tracings für DocuChat:

• handle_user_request (Wurzel-Schritt)
• query_preprocessing
• vector_db_lookup
• build_llm_context
• llm_api_call
• response_post_processing

Ein Tracing-Visualisierungstool (z. B. Jaeger, Datadog APM) hat sofort die Engpässe bei der Latenz hervorgehoben. Wenn llm_api_call systematisch hohe Latenzen zeigte, deutete dies auf den LLM-Anbieter oder das Netzwerk hin. Wenn vector_db_lookup langsam war, mussten die Indizierung der Vektordatenbank oder die Anfrageparameter optimiert werden. Das Tracing half auch, die genaue Abfolge der Ereignisse zu visualisieren, was die Identifizierung erleichterte, wo eine Anfrage möglicherweise falsch formuliert war oder wo der Kontext verloren ging.

3. Metriken: Die Leistung und Gesundheit quantifizieren

Metriken bieten aggregierte und numerische Einblicke in das Verhalten des Systems im Laufe der Zeit. DocuChat hat eine breite Palette von Metriken mit Prometheus gesammelt und auf Grafana-Dashboards angezeigt.

Wesentliche Metriken für DocuChat:

• Anfragevolumen: Gesamtanzahl der Anfragen pro Minute.
• Latenz:
  • End-to-End-Anfrage-Latenz (p50, p90, p99).
  • Latenz nach Komponenten (z. B. `vector_db_lookup_latency_ms`, `llm_inference_latency_ms`).
• Fehlerquote:
  • Gesamtfehlerquote der API.
  • Spezifische Fehler (z. B. `llm_api_rate_limit_errors`, `vector_db_connection_errors`).
• Spezifische Metriken für LLM:
  • `llm_input_token_count_total` : Summe der verwendeten Eingabetokens.
  • `llm_output_token_count_total` : Summe der generierten Ausgabetokens.
  • `llm_api_cost_total` : Kumulierte Kosten der LLM-API-Aufrufe.
  • `model_usage_by_version` : Verfolgt, welche Version des LLM verwendet wird.
• Spezifische Metriken für RAG:
  • `retrieved_chunks_count_avg` : Durchschnittliche Anzahl der pro Anfrage abgerufenen Teile.
  • `retriever_max_score_avg` : Durchschnittlicher maximaler Relevanzscore der abgerufenen Teile.
  • `context_length_avg` : Durchschnittliche Länge des an das LLM gesendeten Kontexts.

Die Überwachung dieser Metriken hat Trends aufgezeigt. Ein plötzlicher Anstieg von `llm_api_cost_total` könnte auf ein Effizienzproblem beim Erstellen der Anfragen hinweisen (z. B. das Senden von zu umfangreichen Kontexten). Ein Rückgang von `retriever_max_score_avg` könnte auf ein Problem mit der Indizierung neuer Dokumente oder der Qualität der Embeddings hinweisen oder auf eine Veränderung in den Anfrage-Mustern der Nutzer.

4. Nutzerfeedback: Die qualitative Schicht

Keine Menge an technischen Daten kann die subjektive Qualität der Ausgabe eines LLM vollständig erfassen. DocuChat hat einen einfachen Feedback-Mechanismus integriert:

• Daumen hoch/runter: Nutzer konnten die Nützlichkeit einer Antwort bewerten.
• Fakultatives Freitext-Feedback: Für die Antworten „Daumen runter“ konnten Nutzer kurz erklären, warum (z. B. „nicht relevant“, „unvollständig“, „Halluzination“).

Dieses Feedback wurde mit der ursprünglichen Anfrage-ID verknüpft und zusammen mit dem endgültigen Antwortprotokoll gespeichert. Ein Dashboard zeigte einen Trend von positiven/negativen Rückmeldungen. Es ist entscheidend, dass negatives Feedback eine Warnung für das Entwicklungsteam auslöst, damit sie die vollständige Anfrageverfolgung und die Protokolle auf spezifische problematische Interaktionen überprüfen können. Dies offenbarte oft Muster:

• Viele Rückmeldungen „nicht relevant“ wiesen auf Probleme mit dem Retriever hin (z. B. die Notwendigkeit, die Embedding-Modelle zu verfeinern oder die Vektorsuchparameter anzupassen).
• Rückmeldungen „unvollständig“ deuteten manchmal darauf hin, dass das Kontextfenster des LLM zu klein war oder dass die Eingabe nicht verlangte, dass es umfassend ist.
• Rückmeldungen „Halluzination“ waren die schwierigsten, ermöglichten aber spezifische Iterationen der Prompt-Engineering oder sogar Anpassungen der Modelltemperatur.

Praktische Beispiele für Observierbarkeit in Aktion

Szenario 1: Diagnose von „nicht relevanten Antworten“

Problem: Nutzer berichten, dass DocuChat nicht relevante Antworten auf spezifische Fragen zu HR-Richtlinien gibt.

Observierbarkeitsfluss:

1. Feedback: Mehrere Rückmeldungen „Daumen runter“ für HR-bezogene Anfragen, mit Kommentaren wie „hat meine Frage zu Urlaub nicht beantwortet.“
2. Logs (Retriever-Protokoll): Protokolle für Anfragen mit negativem Feedback filtern. Beobachten, dass für diese Anfragen `retriever_max_score_avg` niedrig ist (< 0.7), und die Tabelle `retrieved_chunks` Dokumente enthält, die nicht mit HR zu tun haben, oder nur sehr allgemeine HR-Dokumente.
3. Metriken (Retriever-Metriken): Einen Rückgang von `retriever_max_score_avg` für eine spezifische Dokumentenkategorie (z. B. ‘HR’) bemerken.
4. Tracing: Eine spezifische Anfrage mit einer nicht relevanten Antwort untersuchen. Die Verfolgung zeigt, dass `vector_db_lookup` schnell abgeschlossen wurde, aber die abgerufenen Chunks eindeutig nicht relevant waren. Das LLM versuchte dann, basierend auf diesem mageren Kontext zu antworten.
5. Ursache und Maßnahme: Die Embeddings neuer HR-Richtliniendokumente waren entweder schlecht generiert, oder der Index der Vektordatenbank musste neu aufgebaut werden. Das Reindexieren der HR-Dokumente mit einem aktualisierten Embedding-Modell oder das Anpassen der Vektorsuchparameter (z. B. durch Verwendung eines spezifischeren Filters) löste das Problem.

Szenario 2: Identifizierung von Leistungsengpässen

Problem: Die Antwortzeiten von DocuChat sind intermittierend und langsam, insbesondere während der Stoßzeiten.

Observierbarkeitsfluss:

1. Metriken (Latenz-Dashboard): Das Grafana-Dashboard zeigt, dass `end_to_end_request_latency_p99` während der Stoßzeiten signifikant ansteigt. Zudem zeigt `llm_inference_latency_ms_p99` ähnliche Spitzen, während `vector_db_lookup_latency_ms_p99` relativ stabil bleibt.
2. Logs (LLM-Inferenzprotokoll): Das Filtern langsamer Anfragen zeigt, dass `llm_api_rate_limit_errors` häufig auftreten.
3. Tracing: Die Verfolgungen für langsame Anfragen zeigen deutlich, dass der Bereich `llm_api_call` abnormal lange dauert, oft mit wiederholten Versuchen aufgrund der Rate-Limitierung.
4. Ursache und Maßnahme: Die Anwendung würde während der Spitzenzeiten die Rate-Limits des LLM-Anbieters erreichen. Das Team beschließt, eine exponentielle Rückoff-Logik zu implementieren und es erneut zu versuchen sowie höhere API-Pläne zu erkunden oder das Zusammenfassen von Anfragen in Betracht zu ziehen, wenn dies angemessen ist.

Fazit: Die observable Zukunft des LLM

Der Aufbau robuster LLM-Anwendungen erfordert, über die Black Box hinauszugehen. Wie das Beispiel von DocuChat zeigt, verwandelt eine ganzheitliche Observierbarkeitsstrategie — die detaillierte Protokollierung, verteiltes Tracing, tiefgehende Metriken und unschätzbares menschliches Feedback kombiniert — das Debugging von einer Vermutung in einen datengestützten Prozess. Dies ermöglicht es Entwicklern, nicht nur zu verstehen ob eine LLM-Anwendung funktioniert, sondern wie sie funktioniert, warum sie möglicherweise fehlschlägt und wo Verbesserungen vorgenommen werden können.

Der Bereich der LLM-Observierbarkeit entwickelt sich schnell, mit neuen Werkzeugen und Techniken, die speziell zur Behandlung von Prompt-Engineering, Halluzinationserkennung und Bias-Identifizierung auftauchen. Durch die Annahme dieser Praktiken können Unternehmen das volle Potenzial von LLM-Anwendungen ausschöpfen und sicherstellen, dass sie zuverlässig, leistungsfähig sind und echten Wert für die Nutzer bieten.

🕒 Published: March 29, 2026