KI-Architektur & Integration · LLMOps

Observability und Monitoring von LLMs: KI-Anwendungen im Betrieb im Blick

Eine LLM-Anwendung, die im Test überzeugt, kann im Betrieb still schlechter werden: Antworten weichen ab, Kosten steigen, Nutzer springen ab. Observability macht sichtbar, was in jeder Anfrage passiert, und liefert die Grundlage, um Qualität und Kosten zu steuern.

Aleksandra Osztynowicz 5 Minuten Lesezeit
Illustration: Ein Mann im Anzug hält zwei Lupen, über ihm schweben Frage- und Ausrufezeichen

Das Wichtigste in Kürze

  • LLM-Observability erfasst zu jeder Anfrage Eingabe, Kontext, Modellantwort, Laufzeit, Kosten und Bewertung.
  • Monitoring meldet, dass etwas nicht stimmt. Observability hilft zu verstehen, warum.
  • Gemessen werden vor allem Antwortqualität, Kosten pro Anfrage, Latenz, Fehler und Nutzerfeedback.
  • Tools wie Langfuse und LangSmith bündeln Tracing, Auswertung und Prompt-Verwaltung. Langfuse lässt sich auch selbst betreiben.

Was LLM-Observability ist

LLM-Anwendungen verhalten sich anders als klassische Software. Dieselbe Frage kann unterschiedliche Antworten erzeugen, ein neuer Prompt oder ein Modellwechsel verändert Ergebnisse, und ein Fehler zeigt sich oft erst in einer falschen Aussage statt in einer Fehlermeldung. LLM-Observability macht diese Abläufe nachvollziehbar. Sie stützt sich auf drei Arten von Daten:

  • Logs: chronologische Aufzeichnungen von Ereignissen, etwa Eingaben, Antworten und Fehler.
  • Metriken: Messwerte wie Laufzeit, Tokenverbrauch, Kosten und Fehlerraten.
  • Traces: der vollständige Weg einer Anfrage durch das System, vom Abruf der Dokumente über den Modellaufruf bis zu Werkzeugen und Agentenschritten.

Monitoring und Observability

Monitoring überwacht festgelegte Kennzahlen und schlägt Alarm, wenn Schwellenwerte überschritten werden, etwa bei steigender Laufzeit oder Kosten. Observability geht eine Ebene tiefer: Sie zeigt im einzelnen Trace, welcher Schritt die schlechte Antwort verursacht hat, zum Beispiel ein falsch gefundenes Dokument oder ein veralteter Prompt. Im Betrieb braucht es beides.

Was im Betrieb gemessen wird

BereichTypische Fragen
AntwortqualitätStimmen Antworten mit den Quellen überein? Wie oft wird etwas erfunden oder ausgelassen?
KostenWie viele Tokens verbraucht eine Anfrage, und welche Schritte treiben die Kosten?
LatenzWie lange warten Nutzer, und welcher Schritt bremst?
FehlerWo brechen Aufrufe ab, wo liefern Werkzeuge oder Schnittstellen nichts?
NutzerfeedbackWelche Antworten werden als falsch markiert, und woran liegt es?
VersionenWelcher Prompt und welches Modell haben eine Antwort erzeugt?

Für die Qualität reichen einzelne Stichproben selten. Bewährt haben sich feste Testsätze mit echten Fragen, die bei jeder Änderung an Prompt, Modell oder Datenbasis automatisch erneut bewertet werden.

Aus der Praxis

Aus der Praxis: apoQlar

Der RAG-Assistent für Sicherheitsfragebögen erfasst mit LangFuse das Feedback der Nutzer zusammen mit Prompt-Versionen, Kosten und Latenz. Markieren Nutzer eine Antwort als ungenau, zeigt das oft eine Lücke in der Dokumentation, und die Teams wissen, welche Richtlinie sie aktualisieren sollten.

Zur Referenz apoQlar

Aus der Praxis: Policy-Insider.AI

Die Plattform fasst Politikdokumente aus mehreren EU-Sprachen automatisch zusammen. Damit die Qualität im Betrieb hält, haben wir eine iterative Evaluationspipeline gebaut, die uneinheitliche Ergebnisse und das Risiko erfundener Aussagen laufend überwacht.

Zur Referenz Policy-Insider.AI

Aus der Praxis: technische Prüfbehörde

Der Prototyp des Bürger-Chatbots mit elf Fachagenten läuft auf Microsoft Azure mit Entra-ID-Anmeldung und Langfuse-Monitoring. So ist jederzeit sichtbar, wie das System arbeitet, passend zu den Sicherheitsanforderungen der Behörde.

Zur Referenz Bürger-Chatbot

Langfuse und LangSmith

Spezialisierte Werkzeuge nehmen einen großen Teil dieser Arbeit ab. Zwei verbreitete Beispiele:

  • Langfuse ist Open Source und bietet Tracing, Auswertungen und Prompt-Verwaltung. Es lässt sich als Cloud-Dienst nutzen oder per Docker oder Kubernetes in der eigenen Infrastruktur betreiben. Einzelne Zusatzfunktionen benötigen dort eine Lizenz.
  • LangSmith stammt von LangChain und deckt Tracing, Auswertung und Prompt Engineering ab. Es funktioniert auch mit anderen Frameworks und Modellanbietern und läuft in der Cloud, hybrid oder selbst betrieben.

Bei der Auswahl zählen vor allem: wo die Protokolldaten liegen dürfen, ob sich personenbezogene Daten vor dem Speichern maskieren lassen, wie gut sich das Tool in vorhandene Systeme und Frameworks einbinden lässt und ob Auswertungen automatisiert laufen können.

So führen Sie Observability ein

  1. Von Anfang an protokollieren: Tracing schon im Prototyp einbauen, damit von Beginn an Vergleichswerte vorliegen.
  2. Qualität definieren: festlegen, woran eine gute Antwort zu erkennen ist, und einen Testsatz mit echten Fragen anlegen.
  3. Kosten und Laufzeit sichtbar machen: pro Anfrage und pro Schritt, damit teure Stellen früh auffallen.
  4. Feedback einsammeln: Nutzer können Antworten einfach bewerten, und diese Bewertungen fließen in die Auswertung.
  5. Änderungen absichern: jeder neue Prompt, jedes neue Modell wird vor dem Einsatz gegen den Testsatz geprüft.

Wie der Betrieb von KI-Modellen insgesamt organisiert wird, beschreibt unser Beitrag MLOps: KI-Modelle zuverlässig und skalierbar betreiben.

Ihre LLM-Anwendung im Betrieb absichern?

Wir richten mit Ihnen Tracing, Auswertung und Kostenkontrolle ein, in der Cloud oder in Ihrer eigenen Infrastruktur.

Prozessanalyse anfragen

Häufige Fragen

Die Fähigkeit, das Verhalten einer LLM-Anwendung im Betrieb nachzuvollziehen. Dazu werden Logs, Metriken und Traces jeder Anfrage erfasst, also Eingabe, Kontext, Antwort, Laufzeit, Kosten und Bewertung.

Monitoring überwacht festgelegte Kennzahlen und meldet Abweichungen. Observability zeigt im einzelnen Ablauf, warum eine Antwort schlecht oder eine Anfrage teuer war.

Vor allem Antwortqualität, Kosten pro Anfrage, Latenz, Fehler, Nutzerfeedback und die Versionen von Prompt und Modell.

Ja. Langfuse ist Open Source und lässt sich per Docker oder Kubernetes selbst betreiben. Einzelne Zusatzfunktionen benötigen dafür eine Lizenz.

Aleksandra Osztynowicz

Über die Autorin

Aleksandra Osztynowicz

AI Engineer, theBlue.ai

Aleksandra entwickelt seit 2021 bei theBlue.ai maßgeschneiderte KI-Lösungen mit Schwerpunkt auf agentischen Implementierungen und lokalen LLM-Deployments, die passgenau auf Unternehmensanforderungen zugeschnitten sind. Als AI Engineer hilft sie Organisationen dabei, ihre Prozesse mit produktionsreifen Systemen zu automatisieren, von On-Premise-Open-Source-Modellen bis hin zu RAG-basierten internen Wissensdatenbanken für regulierte Branchen, und erweitert ihr Wissen kontinuierlich in der sich rasant wandelnden Welt der Künstlichen Intelligenz.

In ihren Artikeln teilt sie praktische Erfahrungen aus realen Enterprise-KI-Projekten und zeigt: KI im Unternehmen einzuführen muss nicht kompliziert sein.