Beobachtbarkeit für LLM-Apps: Eine praktische Fallstudie

Der Aufstieg von LLM-Anwendungen und die Notwendigkeit von Beobachtbarkeit

Der Bereich der Softwareentwicklung wurde durch die Revolution der großen Sprachmodelle (LLM) dramatisch umgestaltet. Von anspruchsvollen Chatbots und intelligenten Inhaltsgeneratoren bis hin zu Programmierassistenten und Datenanalysetools werden LLMs in ein ständig wachsendes Spektrum von Anwendungen integriert. Diese rasche Akzeptanz, so aufregend sie auch ist, bringt eine neue Klasse von Herausforderungen mit sich, insbesondere wenn es darum geht, diese Systeme in der Produktion zu verstehen und zu warten. Traditionelle Überwachungstools, die für deterministische, regelbasierte Software konzipiert wurden, kommen oft nicht mit den Nuancen des LLM-Verhaltens zurecht.

Hier kommt die Beobachtbarkeit ins Spiel. Beobachtbarkeit im Kontext von LLM-Anwendungen ist die Fähigkeit, den internen Zustand eines LLM-gesteuerten Systems anhand seiner externen Ausgaben zu verstehen. Sie geht über einfache Gesundheitsprüfungen hinaus und liefert tiefe Einblicke, wie das LLM Eingaben interpretiert, Antworten generiert, den Kontext verwaltet und mit externen Tools oder Datenquellen interagiert. Ohne zuverlässige Beobachtbarkeit kann das Debuggen von Leistungsproblemen, die Gewährleistung von Fairness, die Identifizierung von Halluzinationen oder die Optimierung von Kosten zu einer überwältigenden, fast unmöglichen Aufgabe werden. Dieser Artikel präsentiert eine praktische Fallstudie zur Implementierung von Beobachtbarkeit für eine LLM-Anwendung und demonstriert wichtige Prinzipien und Werkzeuge.

Fallstudie: ‘DocuChat’ – Ein interner Wissensdatenbank-Assistent

Betrachten wir eine hypothetische Anwendung namens ‘DocuChat’. DocuChat ist ein interner Wissensdatenbank-Assistent, der darauf ausgelegt ist, Mitarbeitern zu helfen, schnell Antworten aus einer umfangreichen Sammlung interner Dokumente (Confluence-Seiten, Slack-Archive, interne Wikis usw.) zu finden. Es verwendet eine Architektur zur Retrieval-unterstützten Generierung (RAG):

1. Benutzeranfrage: Ein Mitarbeiter stellt eine Frage (z. B. “Wie beantrage ich einen neuen Laptop?”).
2. Retrieval: Das System durchsucht eine Vektordatenbank (gefüllt mit Embeddings interner Dokumente), um relevante Dokumentabschnitte zu finden.
3. Erweiterung: Diese abgerufenen Abschnitte werden zusammen mit der ursprünglichen Benutzeranfrage als Kontext für ein LLM bereitgestellt.
4. Generierung: Das LLM synthetisiert eine Antwort basierend auf dem bereitgestellten Kontext und der Anfrage des Benutzers.

DocuChat nutzt OpenAI’s GPT-4 zur Generierung und ein selbst gehostetes Embedding-Modell für das Retrieval. Es wurde mit Python, LangChain und einer Vektordatenbank wie Pinecone oder Weaviate erstellt. Zu Beginn konzentrierte sich das Entwicklungsteam auf die Funktionalität, doch als die Anwendung mehr Benutzer gewann, tauchten eine Reihe 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 das pro Anfrage?
• Erreichen wir die API-Ratenlimits?
• Welche Arten von Fragen stellen die Benutzer am häufigsten?

Diese Fragen unterstreichen den dringenden Bedarf an Beobachtbarkeit.

Säulen der LLM-Beobachtbarkeit für DocuChat

Für DocuChat konzentrieren wir uns auf die drei traditionellen Säulen der Beobachtbarkeit, angepasst für LLM-Anwendungen:

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

Darüber hinaus betrachten wir eine vierte, entscheidende Säule für LLMs: Menschliches Feedback/Evaluation.

1. Protokolle: Das ‘Was ist passiert’

Traditionelle Anwendungsprotokolle sind wichtig, aber für LLM-Anwendungen müssen sie spezifische LLM-zentrierte Details erfassen. Für DocuChat haben wir verschiedene Phasen der RAG-Pipeline instrumentiert, um strukturierte Protokolle zu erzeugen.

Beispielhafte Protokollstruktur (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": "Wie beantrage ich einen neuen 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": "Wie beantrage ich einen neuen 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": "Um einen neuen Laptop zu beantragen, besuchen Sie bitte das 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 Protokolle (z. B. unter Verwendung des ELK-Stacks, Splunk, Datadog) kann das Team:

• Nach session_id filtern, um eine gesamte Interaktion nachzuvollziehen.
• Langsame Abrufe oder LLM-Aufrufe identifizieren.
• Häufige Anfragen und deren Ergebnisse analysieren.
• Probleme debuggen, indem sie das genaue Prompt an das LLM und die abgerufenen Dokumente untersuchen.

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

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

Wichtige LLM-spezifische Metriken:

• Latency:
  • 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 auf Basis der Modellpreise)
• API-Gesundheit:
  • docuchat_llm_api_calls_total (Zähler, etikettiert nach model_name, status_code)
  • docuchat_vector_db_queries_total (Zähler, etikettiert nach status_code)
  • docuchat_llm_api_rate_limit_errors_total (Zähler)
• Abrufleistung:
  • docuchat_retrieved_documents_count_sum/_count (durchschnittlich abgerufene Dokumente pro Anfrage)
  • docuchat_retrieved_documents_avg_score (Messgerät/Zusammenfassung)
• Benutzerengagement:
  • 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 Fehlerquoten einzurichten.
• Die finanziellen Kosten der LLM-Nutzung in Echtzeit zu überwachen.
• Engpässe in der RAG-Pipeline (z. B. langsames Retrieval vs. langsames LLM) zu identifizieren.
• Die Verteilung der Punktzahlen abgerufener Dokumente zu verstehen, was auf die Effektivität des Retrievals hinweist.

3. Transaktionen: Der ‘Weg’, der eingeschlagen wurde

Transaktionen bieten eine ganzheitliche Sicht auf die Reise 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 im RAG-Prozess wird zu einem Span innerhalb einer Transaktion.

Beispielhafter Transaktionsfluss für DocuChat:

1. Span: Benutzeranfrage (Root Span)
   • Attribute: user_id, query, session_id
2. Span: Retrieval
   • Attribute: vector_db_query, k_value, retrieval_engine
   • Child Span: Vektor DB Abfrage
     • Attribute: query_vector_size, response_time_ms
   • Child Span: Dokumenten-Vorverarbeitung (falls vorhanden)
     • Attribute: num_docs_processed
   • Ereignisse: “3 Dokumente abgerufen”, “Keine relevanten Dokumente gefunden”
3. Span: LLM-Generierung
   • Attribute: model_name, temperature, prompt_tokens, completion_tokens
   • Child Span: OpenAI API Aufruf
     • Attribute: api_endpoint, status_code, request_id
   • Ereignisse: “LLM hat mit der Generierung begonnen”, “LLM hat die Generierung abgeschlossen”, “LLM-Halluzination erkannt (geringe Zuversicht)”
4. Span: Nachbearbeitung & Antwort
   • Attribute: response_length_chars, sentiment_score

Durch die Verwendung eines Tracing-Backends (wie Jaeger, Honeycomb, Datadog APM) kann das Team:

• Überprüfen Sie visuell die genaue Reihenfolge der Operationen für eine gegebene Anfrage.
• Bestimmen Sie, welcher Schritt der RAG-Pipeline die meiste Zeit in Anspruch nimmt.
• Verstehen Sie den Kontext, der an das LLM (abgerufene Dokumente) für eine spezifische Spur übergeben wird.
• Identifizieren Sie Fehler oder unerwartete Verhaltensweisen innerhalb spezifischer Abschnitte.

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

LLMs sind von Natur aus probabilistisch. Während Protokolle, Metriken und Spuren uns etwas über die Mechanik des Systems erzählen, geben sie uns nicht immer Auskunft über die Qualität der Ausgabe des LLM. Hier wird menschliches Feedback und automatisierte Bewertungsmetriken entscheidend.

Für DocuChat haben wir implementiert:

1. Benutzer-Positive/Negative-Bewertungs-Buttons: Einfacher Feedback-Mechanismus für jede Antwort. Negative Bewertungen lösen eine Benachrichtigung für eine manuelle Überprüfung aus, wenn ein bestimmter Schwellenwert erreicht wird.
2. “Problem melden”-Funktion: Ermöglicht es Benutzern, Freitext-Feedback zu Halluzinationen, falschen Antworten oder irrelevanten Informationen zu geben.
3. Bewertung des Goldenen Datensatzes: Ein Satz bekannter Fragen mit von Experten verifiziertem Antworten. DocuChat regelmäßig gegen diesen Datensatz ausführen und die Antworten mithilfe von Metriken wie bewerten:
   • RAGAS: Ein Rahmenwerk speziell für die RAG-Bewertung, das Aspekte wie Treue, Relevanz der Antwort, Präzision des Kontexts und Erinnerungsvermögen des Kontexts misst.
   • Semantische Ähnlichkeit: Verwendung von Embedding-Modellen zum Vergleich der generierten Antwort mit der goldenen Antwort.
   • Überlappung von Schlüsselwörtern: 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) gegen einen Referenzwert oder spezifische Kriterien (z. B. Kürze, Tonfall) zu bewerten.

Die Integration dieses Feedbacks ermöglicht es dem Team:

• Benutzerzufriedenheit direkt zu messen und problematische Bereiche zu identifizieren.
• Die RAG-Pipeline iterativ zu verbessern (z. B. Chunking-Strategie verfeinern, Embedding-Modell verbessern, Prompt-Engineering anpassen).
• Die Leistung verschiedener LLM-Versionen oder Abrufalgorithmen über die Zeit hinweg zu verfolgen.

Praktische Implementierung und Tools

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

• Protokollierung: Pythons logging-Modul, konfiguriert, um JSON auszugeben, an Loki (das Log-Aggregationssystem von Grafana Labs) gesendet.
• Metriken: Prometheus zur Erfassung von Zeitreihendaten, über einen benutzerdefinierten FastAPI-Endpunkt mit prometheus_client bereitgestellt. Grafana für Dashboardierung und Alarmierung.
• Tracing: OpenTelemetry Python SDK für die Instrumentierung, das Spuren an Jaeger sendet. LangChain bietet integrierte Rückrufe, die für OpenTelemetry angepasst werden können.
• LLM-spezifische Plattformen: Tools wie LangSmith (für LangChain-Tracking und -Bewertung), Weights & Biases (für Experimentverfolgung und Modellauswertung) oder Arize AI (für LLM-Observability und -Überwachung) können den Prozess erheblich vereinfachen, insbesondere für fortgeschrittene Anwendungsfälle und große Teams. Für diese Fallstudie haben wir uns für einen DIY-Ansatz entschieden, der Open-Source-Komponenten verwendet, um die Grundlagen zu veranschaulichen.
• Menschliches Feedback: Benutzerdefinierte UI-Elemente, die mit einem speziellen Feedback-Service integriert sind, der an Loki protokolliert und einen Metrikzähler aktualisiert.

Vorteile und Ergebnisse für DocuChat

Die Implementierung dieser umfassenden Observability-Strategie brachte erhebliche Vorteile für das DocuChat-Team:

• Schnellere Fehlersuche: Wenn ein Benutzer eine falsche Antwort meldete, konnten die Ingenieure die Anfrage schnell zurückverfolgen, die abgerufenen Dokumente, das genaue Prompt und die Antwort des LLM prüfen und oft innerhalb von Minuten Probleme identifizieren.
• Kostenoptimierung: Durch die Überwachung der Token-Nutzung identifizierte das Team Möglichkeiten, die Prompt-Größe zu reduzieren und mit kostengünstigeren LLM-Modellen für spezifische Anwendungsfälle zu experimentieren, was zu einer Reduzierung der API-Kosten um 15 % führte.
• Verbesserte Leistung: Metriken zeigten, dass die Vektordatenbank gelegentlich langsam war. Dies führte zur Optimierung der Vektorindizierungsstrategie und zum Hochskalieren der Datenbank, was zu einer Verbesserung der durchschnittlichen Antwortzeit um 20 % führte.
• Erhöhte Zuverlässigkeit: Benachrichtigungen bei LLM-API-Fehlern oder hohen Halluzinationsraten ermöglichten proaktive Eingriffe und verhinderten weit verbreitete Benutzerunzufriedenheit.
• Datengetriebene Iteration: Menschliches Feedback und Bewertungsmetriken lieferten konkrete Beweise dafür, welche Änderungen an der RAG-Pipeline oder dem Prompt-Engineering am effektivsten waren und so eine kontinuierliche Verbesserung vorantreiben.
• Transparenz: Die Stakeholder erhielten bessere Einblicke in die Leistung des Systems und den Wert, den es lieferte.

Herausforderungen und zukünftige Arbeit

Obwohl erfolgreich, war die Implementierung nicht ohne Herausforderungen:

• Datenvolumen: LLM-Interaktionen können eine Menge Daten generieren (Prompts, Antworten, Kontext). Das effiziente Management und die Speicherung dieser Daten sind entscheidend.
• Kontextuelles Verständnis: Die Interpretation von LLM-Ausgaben erfordert oft noch menschliches Urteilsvermögen. Automatisierte Bewertungen verbessern sich, sind aber noch nicht perfekt.
• Änderungen im Prompt-Engineering: Häufige Änderungen an Prompts erfordern sorgfältige Versionierung und gewährleisten, dass die Bewertungsmetriken relevant bleiben.
• Halluzinationserkennung: Während einige Metriken (wie RAGAS-Treue) helfen, bleibt eine solide, Echtzeit-Halluzinationserkennung ein aktives Forschungsgebiet.

Die zukünftige Arbeit für DocuChat umfasst:

• Integration fortschrittlicher Anomalieerkennung für LLM-Ausgaben.
• Entwicklung komplexerer A/B-Testing-Rahmen für verschiedene RAG-Konfigurationen.
• Proaktive Erkennung von adversarialen Prompts oder Versuchen zur Prompt-Injektion zu erkunden.
• Verwendung von feinabgestimmten kleineren Modellen für spezifische Aufgaben, um Kosten und Latenz weiter zu optimieren.

Fazit

Observability ist nicht nur eine nette Ergänzung, sondern eine grundlegende Voraussetzung für den Aufbau zuverlässiger, leistungsfähiger und kosteneffektiver LLM-Anwendungen. Wie die Fallstudie zu DocuChat zeigt, bietet eine gründliche Strategie, die strukturierte Protokolle, detaillierte Metriken, End-to-End-Spuren und entscheidendes menschliches Feedback umfasst, die nötigen Einblicke, um die einzigartigen Komplexitäten von LLM-gesteuerten Systemen zu navigieren. Durch Investitionen in Observability von Beginn an können Entwicklungsteams Vertrauen in ihre LLM-Anwendungen gewinnen, Probleme schnell beheben, die Leistung optimieren und letztendlich ein überlegenswertes Benutzererlebnis bieten.

🕒 Published: March 28, 2026