Observability für LLM-Anwendungen: Eine praktische Fallstudie

Der Aufstieg von LLM-Anwendungen und der Bedarf an Observierbarkeit

Der Bereich der Softwareentwicklung wurde durch die Revolution der großen Sprachmodelle (LLM) radikal verändert. Von ausgeklügelten Chatbots und intelligenten Inhaltsgeneratoren bis hin zu Code-Assistenten und Datenanalysetools sind LLM in einem immer breiteren Spektrum von Anwendungen integriert. Diese schnelle Akzeptanz, obwohl aufregend, bringt eine neue Klasse von Herausforderungen mit sich, insbesondere in Bezug auf das Verständnis und die Wartung dieser Systeme in der Produktion. Traditionelle Überwachungstools, die für deterministische und regelbasierte Software entwickelt wurden, haben oft Schwierigkeiten, die Feinheiten des Verhaltens von LLM zu erfassen.

Hier kommt die Observierbarkeit ins Spiel. Observierbarkeit, im Kontext von LLM-Anwendungen, ist die Fähigkeit, den internen Zustand eines von einem LLM betriebenen Systems anhand seiner externen Ausgaben zu verstehen. Sie geht über einfache Gesundheitschecks hinaus und bietet tiefere Einblicke, wie das LLM Anfragen interpretiert, Antworten generiert, den Kontext verwaltet und mit externen Tools oder Datenquellen interagiert. Ohne eine solide Observierbarkeit kann das Debuggen von Leistungsproblemen, die Gewährleistung von Fairness, die Identifizierung von Halluzinationen oder die Kostenoptimierung zu einer entmutigenden, wenn nicht gar unmöglichen Aufgabe werden. Dieser Artikel präsentiert eine praktische Fallstudie zur Implementierung von Observierbarkeit für eine LLM-Anwendung und demonstriert wichtige Prinzipien und Tools.

Fallstudie: ‘DocuChat’ – Ein interner Wissensassistent

Betrachten wir eine hypothetische Anwendung namens ‘DocuChat’. DocuChat ist ein interner Wissensassistent, der entwickelt wurde, um Mitarbeitern zu helfen, schnell Antworten innerhalb einer umfangreichen Sammlung interner Dokumente (Confluence-Seiten, Slack-Archive, interne Wikis usw.) zu finden. Er verwendet eine Architektur der durch Retrieval unterstützten Generierung (RAG):

1. Benutzeranfrage: Ein Mitarbeiter stellt eine Frage (zum Beispiel: “Wie beantrage ich einen neuen Laptop?”).
2. Retrieval: Das System durchsucht eine Vektordatenbank (gefüllt mit Embeddings interner Dokumente), um relevante Dokumententeile zu finden.
3. Erweiterung: Diese abgerufenen Teile sowie die ursprüngliche Benutzeranfrage werden als Kontext an ein LLM übergeben.
4. Generierung: Das LLM synthetisiert eine Antwort basierend auf dem bereitgestellten Kontext und der Benutzeranfrage.

DocuChat nutzt GPT-4 von OpenAI für die Generierung und ein selbstgehostetes Embedding-Modell für das Retrieval. Es wurde mit Python, LangChain und einer Vektordatenbank wie Pinecone oder Weaviate entwickelt. Zunächst konzentrierte sich das Entwicklungsteam auf die Funktionalität, aber als die Anwendung Nutzer gewann, tauchten eine Vielzahl von betrieblichen Fragen auf:

• Warum sind einige Antworten langsam?
• Halluziniert das LLM oder schlägt das Retrieval fehl?
• Sind die Benutzer mit den Antworten zufrieden?
• Wie viel kostet uns jede Anfrage?
• Erreichen wir die API-Rate-Limits?
• Welche Arten von Fragen stellen die Benutzer am häufigsten?

Diese Fragen verdeutlichen den kritischen Bedarf an Observierbarkeit.

Säulen der LLM-Observierbarkeit für DocuChat

Für DocuChat werden wir uns auf die drei traditionellen Säulen der Observierbarkeit konzentrieren, die an LLM-Anwendungen angepasst sind:

1. Logs: Strukturierte Aufzeichnungen von Ereignissen.
2. Metriken: Aggregierte numerische Messungen über die Zeit.
3. Traces: End-to-End-Ansichten von Anfragen durch verteilte Systeme.

Darüber hinaus werden wir eine vierte entscheidende Säule für LLM berücksichtigen: Feedback / Bewertung.

1. Logs: Das ‘Was ist passiert’

Traditionelle Anwendungslogs sind entscheidend, aber für LLM-Anwendungen müssen sie spezifische Details erfassen, die sich auf das LLM konzentrieren. Für DocuChat haben wir verschiedene Schritte des RAG-Pipelines instrumentiert, um strukturierte Logs zu erzeugen.

Beispiel für eine Logstruktur (JSON):

{
 "timestamp": "2023-10-27T10:30:00Z",
 "service": "docuchat-rag-api",
 "level": "INFO",
 "event_type": "user_query",
 "session_id": "abcd-1234-efgh",
 "user_id": "user_123",
 "query": "How do I request a new laptop?",
 "metadata": {
 "user_agent": "Mozilla/5.0...",
 "ip_address": "192.168.1.10"
 }
},
{
 "timestamp": "2023-10-27T10:30:01Z",
 "service": "docuchat-rag-api",
 "level": "INFO",
 "event_type": "retrieval_start",
 "session_id": "abcd-1234-efgh",
 "query": "How do I request a new laptop?",
 "vector_db_query": "laptop request policy",
 "k_value": 5
},
{
 "timestamp": "2023-10-27T10:30:02Z",
 "service": "docuchat-rag-api",
 "level": "INFO",
 "event_type": "retrieval_complete",
 "session_id": "abcd-1234-efgh",
 "retrieved_docs_count": 3,
 "retrieved_docs": [
 {"id": "doc-456", "source": "confluence/laptop-policy", "score": 0.89},
 {"id": "doc-789", "source": "slack/it-announcements", "score": 0.81}
 ],
 "retrieval_duration_ms": 1000
},
{
 "timestamp": "2023-10-27T10:30:03Z",
 "service": "docuchat-rag-api",
 "level": "INFO",
 "event_type": "llm_generation_start",
 "session_id": "abcd-1234-efgh",
 "model_name": "gpt-4",
 "temperature": 0.7,
 "prompt_tokens": 500,
 "system_prompt_hash": "abc123def456" 
},
{
 "timestamp": "2023-10-27T10:30:08Z",
 "service": "docuchat-rag-api",
 "level": "INFO",
 "event_type": "llm_generation_complete",
 "session_id": "abcd-1234-efgh",
 "response": "To request a new laptop, please visit the IT portal...",
 "completion_tokens": 150,
 "total_tokens": 650,
 "llm_duration_ms": 5000,
 "finish_reason": "stop"
},
{
 "timestamp": "2023-10-27T10:30:09Z",
 "service": "docuchat-rag-api",
 "level": "INFO",
 "event_type": "response_sent",
 "session_id": "abcd-1234-efgh",
 "total_request_duration_ms": 9000
}

Durch die Zentralisierung dieser Logs (zum Beispiel unter Verwendung von ELK Stack, Splunk, Datadog) kann das Team:

• Nach session_id filtern, um eine gesamte Interaktion nachzuvollziehen.
• Langsame Retrieval- oder LLM-Aufrufe identifizieren.
• Häufige Anfragen und deren Ergebnisse analysieren.
• Probleme debuggen, indem der genaue Prompt, der dem LLM bereitgestellt wurde, und die abgerufenen Dokumente untersucht werden.

2. Metriken: Das ‘Wie viel’ und ‘Wie schnell’

Metriken bieten aggregierte und quantifizierbare Einblicke in die Leistung und Nutzung des Systems. Für DocuChat verfolgen wir die wichtigsten Metriken mit Prometheus und visualisieren sie mit Grafana.

LLM-spezifische Schlüsselmetriken:

• Latenz:
  • docuchat_total_request_duration_seconds_sum/_count (gesamt Antwortzeit des Systems)
  • docuchat_retrieval_duration_seconds_sum/_count
  • docuchat_llm_api_duration_seconds_sum/_count
• Token-Nutzung & Kosten:
  • docuchat_llm_prompt_tokens_total (Zähler)
  • docuchat_llm_completion_tokens_total (Zähler)
  • docuchat_llm_total_tokens_cost_usd_total (berechnet basierend auf dem Modellpreis)
• API-Status:
  • docuchat_llm_api_calls_total (Zähler, gekennzeichnet mit model_name, status_code)
  • docuchat_vector_db_queries_total (Zähler, gekennzeichnet mit status_code)
  • docuchat_llm_api_rate_limit_errors_total (Zähler)
• Retrieval-Leistung:
  • docuchat_retrieved_documents_count_sum/_count (Durchschnitt der abgerufenen Dokumente pro Anfrage)
  • docuchat_retrieved_documents_avg_score (Gauge/Synthese)
• Nutzerengagement:
  • docuchat_successful_responses_total (Zähler)
  • docuchat_failed_responses_total (Zähler)

Diese Metriken ermöglichen es dem Team:

• Alarme für hohe Latenz oder steigende Fehlerraten einzurichten.
• Die finanziellen Kosten der Nutzung von LLM in Echtzeit zu überwachen.
• Engpässe im RAG-Pipeline zu identifizieren (zum Beispiel langsames Retrieval gegen langsames LLM).
• Die Verteilung der Scores der abgerufenen Dokumente zu verstehen, was die Effizienz des Retrievals anzeigt.

3. Traces: Der ‘Eingeschlagene Weg’

Traces bieten einen Überblick über den Verlauf einer einzelnen Anfrage durch ein verteiltes System. Für DocuChat wird OpenTelemetry verwendet, um die LangChain-Pipeline und alle externen API-Aufrufe zu instrumentieren. Jeder Schritt des RAG-Prozesses wird zu einem Segment innerhalb eines Traces.

Beispiel für einen Tracefluss für DocuChat:

1. Segment: Benutzeranfrage (Wurzelsegment)
   • Attribute: user_id, query, session_id
2. Bereich: Wiederherstellung
   • Attribute: vector_db_query, k_value, retrieval_engine
   • Unterbereich: Vector DB Anfrage
     • Attribute: query_vector_size, response_time_ms
   • Unterbereich: Dokumenten-Vorverarbeitung (falls zutreffend)
     • Attribute: num_docs_processed
   • Ereignisse: “3 Dokumente wiederhergestellt”, “Keine relevanten Dokumente gefunden”
3. Bereich: LLM Generierung
   • Attribute: model_name, temperature, prompt_tokens, completion_tokens
   • Unterbereich: OpenAI API Aufruf
     • Attribute: api_endpoint, status_code, request_id
   • Ereignisse: “Die LLM Generierung hat begonnen”, “Die LLM Generierung ist abgeschlossen”, “LLM Halluzination erkannt (geringe Zuversicht)”
4. Bereich: Nachverarbeitung & Antwort
   • Attribute: response_length_chars, sentiment_score

Mit einem Tracing-Backend (wie Jaeger, Honeycomb, Datadog APM) kann das Team:

• Die genaue Abfolge der Operationen für eine gegebene Anfrage visuell inspizieren.
• Identifizieren, welcher Schritt im RAG-Pipeline die meiste Zeit in Anspruch nimmt.
• Den Kontext verstehen, der an das LLM übermittelt wird (wiederhergestellte Dokumente) für einen spezifischen Trace.
• Fehler oder unerwartetes Verhalten in bestimmten Intervallen identifizieren.

4. Menschliches Feedback & Bewertung: Das ‘Wie Gut’

Die LLMs sind von Natur aus probabilistisch. Während Protokolle, Metriken und Traces uns über die Mechanismen des Systems informieren, sagen sie uns nicht immer, wie die Qualität der Ausgabe des LLM ist. Hier wird menschliches Feedback und automatisierte Bewertungsmetriken entscheidend.

Für DocuChat haben wir eingerichtet:

1. Positive/Negative Abstimmungstasten: Einfaches Feedback-Mechanismus für jede Antwort. Negative Stimmen lösen eine Warnung für eine manuelle Überprüfung aus, wenn ein bestimmter Schwellenwert erreicht wird.
2. „Problem Melden“ Funktion: Ermöglicht es den Nutzern, freitextliches Feedback zu Halluzinationen, falschen Antworten oder irrelevanten Informationen zu geben.
3. Goldene Datensatzbewertung: Ein Set von bekannten Fragen mit von Experten überprüften Antworten. DocuChat regelmäßig gegen dieses Datenset ausführen und die Antworten mit Metriken wie bewerten:
   • RAGAS: Ein Rahmen speziell für die RAG-Bewertung, der Aspekte wie Treue, Relevanz der Antworten, Kontextgenauigkeit und Kontextabruf misst.
   • Semantische Ähnlichkeit: Verwendung von Embedding-Modellen, um die generierte Antwort mit der Referenzantwort zu vergleichen.
   • Keyword-Überlappung: Einfache Überprüfungen auf das Vorhandensein von Schlüsselbegriffen.
4. LLM-Als-Richter: In einigen Fällen kann ein leistungsfähigeres LLM (z. B. GPT-4) verwendet werden, um die Ausgabe eines weniger leistungsfähigen LLM (z. B. GPT-3.5) im Vergleich zu einer Referenz oder für spezifische Kriterien (z. B. Kürze, Ton) zu bewerten.

Die Integration dieses Feedbacks ermöglicht es dem Team:

• Die Zufriedenheit der Nutzer direkt zu messen und Probleme zu identifizieren.
• Den RAG-Pipeline iterativ zu verbessern (z. B. die Segmentierungsstrategie zu verfeinern, das Embedding-Modell zu verbessern, die Prompt-Engineering anzupassen).
• Die Leistung verschiedener LLM-Versionen oder Abrufalgorithmen im Laufe der Zeit zu verfolgen.

Praktische Umsetzung und Werkzeuge

Der Observability-Stack für DocuChat verwendet eine Kombination aus Open-Source- und kommerziellen Tools:

• Protokollierung: Das logging-Modul von Python, konfiguriert, um JSON zu erzeugen, das an Loki (das Protokollaggregationssystem von Grafana Labs) gesendet wird.
• Metriken: Prometheus zur Erfassung zeitlicher Daten, bereitgestellt über einen benutzerdefinierten FastAPI-Endpunkt mit prometheus_client. Grafana zur Erstellung von Dashboards und Warnungen.
• Tracing: OpenTelemetry Python SDK zur Instrumentierung, das Traces an Jaeger sendet. LangChain bietet integrierte Rückrufe, die an OpenTelemetry angepasst werden können.
• LLM-spezifische Plattformen: Tools wie LangSmith (für Tracing und Bewertung mit LangChain), Weights & Biases (für das Experiment-Tracking und die Modellbewertung) oder Arize AI (für die Observability und Überwachung von LLM) können den Prozess erheblich vereinfachen, insbesondere für fortgeschrittene Anwendungsfälle und große Teams. Für diesen Anwendungsfall haben wir uns für einen DIY-Ansatz mit Open-Source-Komponenten entschieden, um die Grundlagen zu veranschaulichen.
• Menschliches Feedback: Benutzerdefinierte UI-Elemente, die in einen speziellen Feedback-Service integriert sind, der in Loki protokolliert und einen Metrikzähler aktualisiert.

Vorteile und Ergebnisse für DocuChat

Die Umsetzung dieser umfassenden Observability-Strategie hat für das DocuChat-Team erhebliche Vorteile gebracht:

• Schnelleres Debugging: Wenn ein Nutzer eine falsche Antwort gemeldet hat, konnten die Ingenieure die Anfrage schnell zurückverfolgen, die wiederhergestellten Dokumente, die genaue Eingabeaufforderung und die Antwort des LLM überprüfen und oft innerhalb weniger Minuten Probleme identifizieren.
• Kostensenkung: Durch die Überwachung der Token-Nutzung identifizierte das Team Möglichkeiten zur Reduzierung der Eingabeaufforderungsgröße und experimentierte mit kostengünstigeren LLM-Modellen für spezifische Anwendungsfälle, was zu einer Reduzierung der API-Kosten um 15 % führte.
• Verbesserte Leistung: Die Metriken zeigten, dass die Vektordatenbank manchmal langsam war. Dies führte zur Optimierung der Vektorisierungsstrategie und zur Vergrößerung der Datenbank, was zu einer Verbesserung der durchschnittlichen Antwortzeit um 20 % führte.
• Erhöhte Zuverlässigkeit: Warnungen bei LLM-API-Fehlern oder hohen Halluzinationsraten ermöglichten proaktive Eingriffe und verhinderten eine weit verbreitete Unzufriedenheit der Nutzer.
• Datenbasierte Iteration: Menschliches Feedback und Bewertungsmetriken lieferten konkrete Beweise für die effektivsten Änderungen, die am RAG-Pipeline oder an der Prompt-Engineering vorgenommen werden sollten, was eine kontinuierliche Verbesserung förderte.
• Transparenz: Die Stakeholder hatten eine bessere Übersicht über die Leistung des Systems und den Wert, den es lieferte.

Herausforderungen und zukünftige Arbeiten

Obwohl erfolgreich, war die Umsetzung nicht ohne Herausforderungen:

• Datenvolumen: Die Interaktionen mit den LLM können eine große Menge an Daten generieren (Eingabeaufforderungen, Antworten, Kontext). Diese Daten effizient zu verwalten und zu speichern, ist entscheidend.
• Kontextuelles Verständnis: Die Interpretation der Ausgaben der LLM erfordert oft noch menschliches Urteil. Die automatisierte Bewertung verbessert sich, ist aber nicht perfekt.
• Änderungen in der Eingabeaufforderungs-Engineering: Häufige Änderungen an den Eingabeaufforderungen erfordern sorgfältiges Versionsmanagement und die Gewährleistung, dass die Bewertungsmetriken relevant bleiben.
• Halluzinationsdetektion: Obwohl einige Metriken (wie die RAGAS-Treue) helfen, bleibt die solide und Echtzeit-Detektion von Halluzinationen ein aktives Forschungsfeld.

Zukünftige Arbeiten für DocuChat umfassen:

• Integration einer fortschrittlichen Anomaliedetektion für die Ausgaben der LLM.
• Entwicklung ausgefeilterer A/B-Testrahmen für verschiedene RAG-Konfigurationen.
• Erforschung der proaktiven Erkennung von adversarialen Eingabeaufforderungen oder Versuchen zur Eingabeaufforderungsinjektion.
• Verwendung kleinerer und angepasster Modelle für spezifische Aufgaben, um die Kosten und die Latenz weiter zu optimieren.

Fazit

Observierbarkeit ist nicht nur ein Vorteil, sondern eine grundlegende Voraussetzung für den Aufbau zuverlässiger, leistungsfähiger und kosteneffizienter LLM-Anwendungen. Wie die Fallstudie von DocuChat zeigt, liefert eine umfassende Strategie, die strukturierte Protokolle, detaillierte Metriken, End-to-End-Tracking und entscheidendes menschliches Feedback integriert, die notwendigen Einblicke, um die einzigartigen Komplexitäten von LLM-gesteuerten Systemen zu navigieren. Durch die frühzeitige Investition in Observierbarkeit können Entwicklungsteams Vertrauen in ihre LLM-Anwendungen gewinnen, Probleme schnell debuggen, die Leistung optimieren und letztendlich ein überlegenes Benutzererlebnis bieten.

🕒 Published: March 29, 2026