Wie überwacht man LLM-Anwendungen im Produktivbetrieb sinnvoll? — Kodschul Wissen
MLOps & LLMOps6 Min. Lesezeit

Wie überwacht man LLM-Anwendungen im Produktivbetrieb sinnvoll?

Direkte Antwort

Klassisches Application-Monitoring (Latenz, Fehlerrate, Verfügbarkeit) reicht bei LLM-Anwendungen nicht aus. Zusätzlich braucht es Trace-Level-Sichtbarkeit auf jeden Prompt, jede Tool-Antwort und jede Modellausgabe, laufende Qualitätsmetriken wie Faithfulness und Nutzerfeedback, sowie Kostenmonitoring pro Anfrage, weil sich Fehlverhalten bei LLM-Systemen oft nicht als klassischer technischer Fehler, sondern als plausibel klingende, aber falsche Antwort zeigt.

"

Ein Server-Log zeigt, dass eine Anfrage erfolgreich beantwortet wurde. Es zeigt nicht, ob die Antwort inhaltlich richtig war.

Ein LLM-System kann technisch fehlerfrei laufen und trotzdem systematisch falsche oder unpassende Antworten liefern — ein Zustand, den klassisches Monitoring nicht erkennt.

Warum klassisches APM bei LLM-Systemen an seine Grenzen stößt

Application Performance Monitoring misst technische Metriken wie Antwortzeit, HTTP-Statuscodes und Ressourcenverbrauch — alles Kennzahlen, die bei einer inhaltlich falschen, aber technisch erfolgreich ausgelieferten LLM-Antwort unauffällig bleiben.

Ein Halluzinieren des Modells, ein fehlerhafter Tool-Aufruf mit plausibel aussehendem, aber falschem Ergebnis oder eine unpassende Antwort auf eine mehrdeutige Frage erzeugen keinen technischen Fehler, den klassisches Monitoring erfasst.

Trace-Level-Sichtbarkeit auf die gesamte Anfrage

LLM-Observability-Tools wie LangSmith, Langfuse oder Arize protokollieren jeden Schritt einer Anfrage — den ursprünglichen Prompt, abgerufene Kontextdokumente bei RAG, jeden Tool-Aufruf mit Parametern und Ergebnis, und die finale Modellantwort.

Diese Traces erlauben es, bei einer gemeldeten Fehlantwort exakt nachzuvollziehen, an welcher Stelle der Pipeline das Problem entstanden ist — falsches Retrieval, falsche Tool-Nutzung oder eine Fehlinterpretation durch das Modell selbst.

Qualitätsmetriken und Nutzerfeedback als laufende Signale

Neben technischen Traces sollten automatisierte Qualitätschecks (Faithfulness, Relevanz) und explizites Nutzerfeedback (Daumen hoch/runter, Korrekturen) kontinuierlich erfasst und aggregiert werden.

Ein Anstieg negativer Bewertungen oder sinkender Faithfulness-Werte ist oft das erste verlässliche Signal für ein Problem, lange bevor es sich in klassischen technischen Metriken zeigt. Faithfulness wird dabei typischerweise nicht durch exakten Textabgleich gemessen, sondern indem ein zweites, günstigeres Modell prüft, ob jede Aussage der Antwort durch den bereitgestellten Kontext gedeckt ist (etwa mit RAGAS) — ein Verfahren, das selbst fehleranfällig ist und deshalb stichprobenartig gegen menschliche Bewertung kalibriert werden sollte, statt blind als Wahrheit zu gelten.

Wann passt es — wann nicht?

Passt gut

  • Die Anwendung hat produktiven Nutzerverkehr mit geschäftlicher Relevanz
  • Es soll systematisch nachvollzogen werden, warum bestimmte Antworten schlecht bewertet wurden

Passt nicht

  • Es handelt sich um ein internes Experiment mit wenigen, gut beobachtbaren Testfällen