Überwachbarkeit für Unternehmens-AI-Agenten mit Langfuse und OCI
Warum Logs, Metriken und Spuren für GenAI-Agenten unzureichend sind und wie man Anfragen, Toolaufrufe, Tokens sowie Sitzungen mit dem Open-Source-Tool Langfuse auf OCI Agents nachverfolgen kann.
Quellen: Observability for Enterprise AI Agents: an open-source solution
Protokolle, Metriken und Spuren verraten Ihnen nicht, warum ein Unternehmens-AI-Agent eine schlechte Antwort gibt. Um diese Systeme zu verstehen, müssen Sie auch die Anfragen, den dem Modell übergebenen Kontext, die Tool-Aufrufe, die Token-Nutzung, die Reaktionszeiten sowie die Qualität der Ausgabe betrachten. Dieser Artikel erläutert, warum generative KI einem anderen Ansatz bei der Überwachbarkeit bedarf, und zeigt anschließend eine konkrete Einrichtung mit Langfuse, die durch ihre Kompatibilität mit der OpenAI Responses API in OCI Enterprise AI Agents integriert werden kann.
Warum das wichtig ist
Der Begriff „Agent“ wird für jeden Workflow verwendet, der ein oder mehrere große Sprachmodelle aufruft, um ein Ergebnis zu erzeugen. Dadurch verschwimmt eine echte Unterscheidung. Ein echter Agent verfügt über Autonomie, die Fähigkeit zur Nutzung von Tools sowie zur Verwaltung von Kontexten – was wiederum eine weitaus höhere betriebliche Komplexität mit sich bringt.
Ein weiteres Problem ist in Unternehmen noch dringender. Die Aufmerksamkeit richtet sich auf die „Magie“ der KI, während die Arbeit, die nötig ist, um diese Systeme zuverlässig, kontrolliert und in guter Qualität laufen zu lassen, vernachlässigt wird. Die Beobachtbarkeit steht ganz oben auf dieser Liste. Bei einem komplexen GenAI-Agenten handelt es sich dabei nicht um eine technische Feinheit – sie ermöglicht es vielmehr, das Verhalten zu verstehen, Fehler zu analysieren, die Qualität der Antworten zu beurteilen sowie Kosten und Latenz in Schach zu halten.
Der erste Teil unten definiert die Beobachtbarkeit und ihre Bedeutung für generative KI. Der zweite Teil zeigt eine auf Open Source basierende Konfiguration, die leicht auf OCI lauffähig ist, samt Beispielen dafür, welche Daten gesammelt werden und warum diese Daten hilfreich sind.
Was Beobachtbarkeit bedeutet
Beobachtbarkeit ist eine Eigenschaft komplexer Systeme. Einfach ausgedrückt ist ein System beobachtbar, wenn man sein internes Verhalten anhand der von ihm ausgesendeten Signale ermitteln kann, die man außerdem sammeln und analysieren kann. Formeller ausgedrückt müssen zwei verschiedene interne Zustände anhand der äußeren Signale unterschieden werden können. Was das System aussendet, muss zuverlässig Aufschluss darüber geben, was im Inneren vor sich geht.
Daraus ergeben sich zwei Folgen. Beobachtbarkeit ist besonders wichtig dort, wo es viele Komponenten, Abhängigkeiten und Interaktionen gibt. Zudem reicht es nicht aus, das System nur von außen zu beobachten, denn es muss so konzipiert und ausgestattet werden, dass nützliche Informationen erzeugt werden. Die ordnungsgemäße Nutzung eines Unternehmens-AI-Agenten bedeutet beispielsweise, Telemetriedaten zu sammeln, die seinen Zustand, sein Verhalten, Anomalien sowie seine Leistung offenbaren.
Darin unterscheidet sich die Beobachtbarkeit vom klassischen Monitoring. Das Monitoring beantwortet Fragen, die man im Voraus bedacht hat, wie zum Beispiel, wie viel CPU ein Service verwendet oder wie langsam eine Anfrage war. Die Beobachtbarkeit muss es außerdem ermöglichen, unerwartete Probleme sowie Fragen zu untersuchen, die niemand zur Zeit der Konzeption vorhergesehen hat – oft als „unbekannte Unbekannte“ bezeichnet.
Beobachtbarkeit vor der generativen KI
„Traditionelle Systeme“ bezeichnen hier Anwendungen, die vor dem Durchbruch der generativen KI, grob gesagt vor 2023, entwickelt wurden. Ihre Beobachtbarkeit beruhte auf drei Arten von Daten: Logs, Metriken und Spuren.
Logs und Metriken sind uns vertraut. Ein Trace ist die end-to-end-Aufzeichnung einer einzelnen Anfrage oder Interaktion und setzt sich aus Spans zusammen, die die einzelnen Schritte beschreiben. In einer Microservices-Architektur kann ein Trace eine ganze Anwendungstransaktion umfassen, mit Spans für eine API-Anfrage, eine Datenbankabfrage oder einen Aufruf an einen externen Dienst. Um wirksam zu sein, muss dieser Ansatz der Anfrage überallhin folgen, wo sie vorkommt.
Für GenAI-Agenten reicht dieses klassische Modell allein nicht aus. Neben Logs, Metriken und Traces muss man auch beobachten, was das Modell tut, welchen Kontext es erhalten hat, welche Tools es aufgerufen hat und wie gut seine Antworten tatsächlich waren.
Was ändert sich mit GenAI
Herkömmliche Software ist recht vorhersehbar. Auf generativer KI basierende Systeme sind weniger vorhersehbar, insbesondere dann, wenn sie eine gewisse Entscheidungsfreiheit haben. Die Ausgabe eines LLM hängt von weitaus mehr Faktoren ab als von der Eingabe des Benutzers, und all diese Faktoren müssen sichtbar sein.
Eine Überwachungsstruktur für ein LLM-System sollte mindestens vier Aspekte erfassen:
- das Modell sowie die Parameter der Anfrage
- die Anweisungen und der tatsächlich gesendete Prompt
- der bereitgestellte Kontext, einschließlich früherer Gesprächshistorien
- die Ausführung des Systems, einschließlich Toolaufrufe, Zwischenergebnisse, Latenzzeit und Tokenverbrauch
Es reicht nicht aus, nur auf die endgültige Antwort zu schauen. Um ein GenAI-System zu verstehen, sollte man in der Lage sein, für jede Spur alles wiederzugeben, was zur Antwort beigetragen hat.
Das gilt umso mehr, wenn das Modell operative Freiheit hat. Wenn es selbst entscheiden kann, welche Tools es aufrufen soll, in welcher Reihenfolge Aktionen ausgeführt werden, welche Quellen konsultiert werden oder wann es aufhören soll, reichen Anfragen und Ausgaben nicht aus. Man muss den Entscheidungsprozess selbst sehen, einschließlich der Abfolge der Toolaufrufe, der Zeitpunkte sowie der Zwischenergebnisse.
Selbst eine vollständige Protokollierung kann oft nicht beantworten, ob das Ergebnis gut ist. Dafür benötigt jede Protokollierung in der Regel Bewertungen. Diese können aus herkömmlicher Logik stammen oder von einem anderen LLM, der heute gängigen Technik „LLM-as-a-judge“, abgeleitet werden.
Bedenken Sie die Beurteilung einer RAG-Antwort. Sie kann teilweise richtig sein oder plausibel erscheinen, ohne von den abgerufenen Quellen gestützt zu werden. Dann müssen Sie mindestens zwei Aspekte unterscheiden: die Ursache, wie z. B. die Informationsabfrage, die Neubewertung oder die Generierung, sowie die Grundlage, d. h. ob die Antwort tatsächlich auf den abgerufenen Dokumenten beruht. Die Überprüfung der Grundlage zeigt unbegründete Behauptungen und somit mögliche Halluzinationen auf.
All das bedeutet, dass eine allgemeine Überwachungsplattform für GenAI nicht ausreicht. Sie benötigen ein Tool, das diese Informationen nativ erfassen kann und dabei die Aufwand für die Instrumentierung gering hält. Der eigentliche Unterschied liegt im Umfang. Bei GenAI überwachen Sie weiterhin Infrastruktur und Geschwindigkeit wie bisher, zusätzlich jedoch den Kontext, den das Modell gesehen hat, die von ihm getroffenen Entscheidungen, die Qualität dessen, was es erzeugt, sowie die Konstanz seines Verhaltens.
Von der Theorie zur funktionsfähigen Einrichtung
Die Überwachbarkeit für Unternehmensagenten muss neben den klassischen Signalen auch Anfragen, Kontextinformationen, Toolaufrufe, Reaktionszeiten, Tokenverbrauch, Ausgabequalität sowie die wahrscheinlichen Ursachen für Fehler oder schlechte Antworten umfassen. Die praktische Frage ist, wie all das auf einfache und effektive Weise in einem Unternehmensumfeld umgesetzt werden kann. Die unten genannte Lösung ist eine Open-Source-Lösung, die sich leicht in OCI einbinden lässt.
Langfuse
Unter den Open-Source-Tools für die Überwachbarkeit von LLMs und Agenten ragt Langfuse hervor. Es handelt sich um eine Plattform zur Verfolgung, Überwachung und Bewertung (Bewertungsskoring) an LLMs basierender Anwendungen, die den größten Teil der oben erwähnten Daten abdeckt: Anfragen, Ausgaben, Verfolgungsdaten, Metadaten, Reaktionszeiten, Tokenverbrauch, Toolaufrufe sowie Bewertungsscores. Es ist mehr als nur ein Protokollierungsdienst – es bietet Ihnen einen strukturierten Überblick darüber, wie sich eine GenAI-Anwendung tatsächlich verhält, und organisiert diese Informationen um Verfolgungsdaten und Sitzungen herum anstelle eines flachen Stroms von Textzeilen, durch den man sich durchkämpfen muss.
Warum OCI die Integration erleichtert
OCI Enterprise AI Agents stellt eine API bereit, die vollständig mit der OpenAI Responses API kompatibel ist. Das ist nicht nur aus praktischen Gründen wichtig, da es Ihnen ermöglicht, die Tools, Bibliotheken sowie Entwicklungsansätze des umfangreichen OpenAI-kompatiblen Ökosystems erneut zu nutzen. Bei Langfuse reduziert dies erheblich die Arbeit beim Sammeln von Telemetriedaten aus Modellaufrufen sowie beim Aufbau der Überwachungsschicht, sodass mehr Zeit für die Analyse und weniger für technische Umsetzungen zur Verfügung steht. Das ist ein wesentlicher Grund dafür, warum OCI und Langfuse in einem Unternehmensumfeld gut zusammenarbeiten.
Eine schnelle Proof-of-Concept-Einsatzumgebung
Zur Erstellung eines PoC lässt sich Langfuse problemlos auf OCI installieren, beispielsweise auf einer Linux-Virtuellen Maschine, unter Verwendung der offiziellen Docker Compose-Deployment-Datei aus dem Langfuse-Repository. Das ist jedoch nicht unbedingt die endgültige Architektur für ein produktionsreifes Unternehmensumfeld. Sie reicht aus, um die Idee zu überprüfen, echte Telemetriedaten zu sammeln und zu erkennen, welche Analysen nach der Integration möglich sind. In der Praxis wurde so schnell eine funktionierende Plattform erstellt, die über einen Browser erreichbar ist und bereit ist, Spuren von Python-LLM-Anwendungen entgegenzunehmen.
Verbindung des Codes herstellen
Sobald eine Langfuse-Instanz läuft, besteht der nächste Schritt darin, die Anwendung so zu instrumentieren, dass Telemetriedaten der Modellaufrufe automatisch übertragen werden. Aufgrund der Kompatibilität mit der Responses-API ist dies für bereits in OpenAI-ähnlicher Weise geschriebene Python-Anwendungen einfach. Die Anwendung ruft das Modell weiterhin auf wie bisher, und Langfuse erfasst die wichtigen Details.
Die Änderungen sind gering:
- Setzen Sie einige Umgebungsvariablen fest.
- Verwenden Sie den von der Langfuse-Bibliothek bereitgestellten Client, der bereits so instrumentiert ist, dass er Spuren sammelt und sendet.
- Übergeben Sie den
conversation_idalssession_id, damit Anfragen innerhalb derselben Konversation in derselben Sitzung verbunden bleiben. - Optional zwingen Sie zu einem sofortigen Senden der Spur. Andernfalls wird sie nach einigen Sekunden automatisch gesendet.
Was wird erfasst
Nach der Integration sammelt Langfuse automatisch viele nützliche Informationen. Für Agenten umfasst das mehr als nur Eingaben und Ausgaben des Modells. Es umfasst auch den Ausführungsfluss mit Zwischenschritten, Toolaufrufen und Zeitangaben, die dabei helfen, nachzuvollziehen, wie ein Ergebnis entstanden ist.
Die relevantesten Elemente sind:
- das Modell und seine Version
- die gesendete Anfrage
- die erzeugte Ausgabe
- Metadaten, die mit dem Aufruf verbunden sind
- die Trace-Struktur sowie alle Zwischenschritte
- Verzögerungsmessungen, einschließlich solcher, die für den Benutzer sichtbar sind wie die Zeit bis zum ersten Token
- die Anzahl der Eingangs- und Ausgabetokens, die für die Kostenanalyse verwendet werden
- Toolaufrufe und ihre Details
- Werte und Bewertungen, die mit der Trace verbunden sind
Nicht alles Nützliche kommt automatisch – und das ist beabsichtigt, da die Plattform nicht wissen kann, was Ihr Unternehmen als gute Antwort betrachtet. Domänenbezogene Bewertungen, individuelle Indikatoren sowie Geschäftsmetadaten müssen von der Anwendung hinzugefügt werden, manchmal sogar unbedingt. Die Kombination aus automatischer Erfassung und bewusster Erweiterung macht das Tool effektiv.
Sessions
Langfuse kann mehrere Spuren aus einer Benutzersession über einen session_id verknüpfen. In dieser Konfiguration wird das Gespräch durch den standardmäßigen conversation_id der Responses API identifiziert; daher korreliert das Setzen von session_id auf diesen Wert alle Anfragen derselben Konversation. Die Sessions können anschließend in der Benutzeroberfläche durchgesehen werden, wobei jede Session mehrere Spuren enthält.
Einblick in eine Spur
Die Ergebnisse werden während der Analyse sichtbar. Die Langfuse-Schnittstelle ermöglicht es Ihnen, jede Interaktion im Detail zu untersuchen und Dinge aufzudecken, die sonst in Anwendungsprotokollen, verstreuten Metadaten und Code verloren gingen. Für eine einzelne Spur können Sie den tatsächlich gesendeten Prompt, das Modell, seine Parameter, Ausführungzeiten, verbrauchte Tokens, die Reihenfolge aller Aufrufe sowie die Ausgaben in jeder Phase einsehen. Das ist besonders wichtig, wenn Sie seltsames Verhalten, Latenzprobleme, steigende Kosten oder Antworten von unzufriedenstellender Qualität untersuchen. Eine langsame Reaktion kann beispielsweise auf eine lange Kette von Tool-Aufrufen, einen überlangen Prompt oder einen langsam generierten ersten Token zurückzuführen sein – und für jedes dieser Probleme gibt es eine andere Lösung. Ohne die zeitlichen Angaben auf Span-Ebene sowie die Token-Zählungen nebeneinander müssten Sie raten, welches Problem vorliegt.
Eine praktische Gewohnheit, die sich daraus ergibt, ist, jedes Gespräch als etwas zu betrachten, das man später noch einmal abspielen kann. Wenn ein Benutzer eine Woche später eine schlechte Antwort meldet, ermöglicht die Sitzungsansicht es, die genauen Protokolle zu öffnen, die ursprüngliche Anfrage sowie den Kontext einzusehen und festzustellen, welches Tool welche Ausgabe geliefert hat, anstatt versuchen zu müssen, die Situation aus dem Gedächtnis nachzustellen.
Einzuhaltende Grenzen
Durch die Einführung von Langfuse werden nicht alle Herausforderungen im Bereich Beobachtbarkeit und Bewertung in einem GenAI-System gelöst. Umfangreiche, mit Kontext angereicherte Protokolle sind zwar notwendig, reichen aber nicht immer aus. Die nützlichsten Bewertungskriterien hängen in der Regel vom Anwendungsbereich ab und müssen gezielt entworfen werden. Zudem erfordern echte Unternehmensumgebungen sorgfältige Überlegungen zu Sicherheit, sensiblen Daten, der Aufbewahrung von Telemetriedaten, Zugriffskontrollen sowie der Bereitstellungsarchitektur.
Trotzdem bietet eine Open-Source-Plattform in Kombination mit der vollständigen API-Kompatibilität von OCI einen soliden Ausgangspunkt für eine konkrete Lösung zur Überwachbarkeit von Unternehmens-Agenten.
Zusammenfassung
Für Unternehmens-KI-Agenten ist die Überwachbarkeit kein technisches Detail oder ein optionales Extra. Sie ist eine Voraussetzung, um das Verhalten zu verstehen, Fehler zu analysieren, die Qualität der Antworten zu bewerten sowie Reaktionszeiten und Betriebskosten zu senken. Die Überwachung der Infrastruktur, Anwendungsprotokolle und Standardmetriken reicht nicht aus. Man benötigt außerdem Daten, die viel näher am Handeln des Agenten liegen: Anfragen, Kontext, Toolaufrufe, Tokenverbrauch, von den Nutzern wahrgenommene Latenzzeiten sowie Bewertungsscores.
Langfuse ist eine besonders interessante Open-Source-Lösung, da sie einen großen Teil dieser Telemetriedaten erfasst und organisiert, und die mit OpenAI kompatible API in OCI Enterprise AI Agents die Integration erleichtert. Keine Plattform löst jedoch alles allein – Sicherheit, Governance, die Verarbeitung sensibler Daten sowie die Erstellung domänenspezifischer Bewertungen bleiben weiterhin unverzichtbar.
Falls diese Agenten über Demo-Versionen hinausgehen und zu zuverlässigen Bestandteilen echter Systeme werden sollen, darf die Beobachtbarkeit nicht nachrangig behandelt werden. Ihre Komplexität lässt sich zwar nicht beseitigen, aber sie kann und sollte sichtbar gemacht werden.
Eine natürliche Weiterentwicklung besteht darin, Spuren durch Bewertungen zu bereichern, die die Qualität systematischer messen – insbesondere Bewertungen, die von einem LLM als Urteilsinstanz erzeugt werden – sodass jede Spur neben den technischen Ausführungsdaten auch Bewertungen zur Qualität der Antwort enthält.
Verwandte Artikel
- Wie der Browser-Speicher heimlich Benutzerdaten zerstört und wie man dies verhindert — Verlorene Updates, veraltete Snapshots, Schema-Änderungen sowie Datenlecks auf geteilten Geräten können die localStorage-Daten ohne jeglichen Fehler beschädigen. Muster für Eigentumsverhältnisse, Versionierung und Validierung.
- Praktische Hinweise: RAG-Systeme: Der umfassende Leitfaden von Anfänger bis Experte (2026-Ausgabe) — Detaillierte Anleitung zu Practical notes: RAG-Systeme: Der umfassende Leitfaden von Anfänger bis Experte (2026-Ausgabe): Verträge, Überprüfungen sowie Code-Blöcke für Teams, die dieses Muster einsetzen.