Systematische Evaluation von LLMs und Agenten – Von der Heuristik zur Messbarkeit

Seit der Markteinführung von ChatGPT im Jahr 2022 stehen universelle große Sprachmodelle (LLMs) einer breiten Masse zur Verfügung. Die Verarbeitung natürlicher Sprache ist damit nicht mehr nur Data Scientists und ML-Spezialisten vorbehalten. Dank ihrer Fähigkeit, vielfältige Aufgaben direkt „Out of the Box“ zu lösen, entfällt oft das aufwendige Training spezialisierter Modelle.

Da diese generativen KI-Modelle (GenAI) enorme Rechenkapazitäten erfordern, übersteigen sie oft die Grenzen klassischer Infrastrukturen. Aus diesem Grund werden sie primär in der Cloud betrieben und über REST-Schnittstellen in bestehende Softwareanwendungen integriert.

Daraus ergibt sich jedoch ein häufiger Trugschluss bei der Integration von GenAI: Die Generierung von Inhalten verläuft weitaus unvorhersehbarer als bei traditioneller Software. Dadurch wird die Überprüfbarkeit der gesamten Applikation – oder zumindest der durch LLMs gesteuerten Teilprozesse – inhärent nicht deterministisch.

In der Praxis bedeutet das: Erste manuelle Testläufe mögen exzellente Ergebnisse liefern. Doch bei einer größeren Anzahl an Nutzeranfragen kann ein Agent unerwartet fehlleiten, sich in endlosen Denkschleifen (Reasoning Loops) verfangen oder die Qualität eines RAG-Systems nach einer minimalen Prompt-Anpassung drastisch einbrechen.

Data Science liefert bereits bewährte ML-Methoden zur statistischen Evaluation. Im Folgenden zeigen wir auf, wie sich diese Ansätze erfolgreich auf das Zeitalter von GenAI übertragen lassen.

Anatomie einer AI App: Input, Kontext und Parameter

Ob es sich bei der KI-basierten Anwendung, die wir entwickeln wollen, um einen autonomen Agenten, ein Retrieval-Augmented Generation (RAG) System oder um eine komplexe Prompt-Kette handelt, ist für unsere Betrachtung zunächst zweitrangig. Im Kern lässt sich jede dieser Applikationen auf ein grundlegendes Paradigma reduzieren: Ein System, das durch spezifische Stellschrauben (Parameter) definiert ist und Eingaben (Inputs) in Ausgaben (Outputs) überführt.

Der entscheidende Unterschied zur klassischen Software liegt in der Beschaffenheit und Verarbeitung dieser Daten:

1. 1. Input Distribution: Die Inputs stammen nicht aus einem überschaubaren Set an Testfällen, sondern aus einer breiten, schwer vorhersehbaren Verteilung realer, sprachlich hochvariabler Nutzeranfragen.
   2. Dynamischer Kontext: Zu diesem primären Input gesellt sich fast immer ein dynamischer Kontext, wie etwa abgerufene Dokumente aus einer Vektordatenbank oder die bisherige Chat-Historie.
   3. Parameter: Wie und welcher Kontext herangezogen wird, diktieren die Parameter der Applikation. Dazu gehören architektonische Entscheidungen (Chunk-Größe, Retrieval-Verfahren), Hyperparameter (Temperature), das Basis-Modell und natürlich der System-Prompt.

Wenn dieses Zusammenspiel auf probabilistische Sprachmodelle trifft, offenbart sich die geradezu chaotische Natur generativer KI: Diese Systeme verhalten sich hochgradig nicht-linear und sind extrem sensitiv gegenüber ihren Anfangsbedingungen. Schon minimale Abweichungen im Input oder im dynamisch geladenen Kontext können den Output drastisch verändern.

Aus dieser hohen Sensitivität wird ersichtlich, dass stichprobenartiges Überprüfen – analog zum Vibe Coding auch als Vibe Checking bezeichnet – nicht mehr ausreicht. Ein zukunftssicherer Entwicklungs-Workflow muss die kontinuierliche, statistische Evaluation von Tag eins an als integralen Bestandteil begreifen.

Damit dieser Prozess bildlich anschaulich wird, greifen wir auf die Analogie des Baus einer Bahnverbindung zurück. Der erste PoC unserer AI Application stellt dabei das eigentliche Schienensystem dar. Hier verläuft der tägliche Anwendungsverkehr: Die Eingaben der Benutzer:innen sind vergleichbar mit den verschiedenen Zügen, die über unsere Strecke rollen.

Observability: Die Signaltechnik der KI

Um ein System kontinuierlich evaluieren zu können, müssen wir sein Verhalten zur Laufzeit erst transparent und messbar machen. Das Fundament dafür bildet das Prinzip der Observability: Wie verändern sich die Ausgaben des Systems in Abhängigkeit von den eingehenden Nutzeranfragen, dem geladenen Kontext und den gewählten Parametern?

Der operative Schalthebel hierfür ist das Zusammenspiel aus Logging und Tracing. Klassisches Logging zeichnet lediglich punktuelle Ereignisse auf – das greift bei vielschichtigen KI-Architekturen zu kurz. Tracing hingegen macht den gesamten Ausführungspfad einer Anfrage transparent. Hier werden komplexe Prozesse in eine hierarchische Baumstruktur aus einzelnen Teilschritten (Spans) aufgeschlüsselt. Erst Tracing offenbart die exakten Ursache-Wirkungs-Zusammenhänge, Latenzen und Kosten jeder einzelnen Entscheidung.

In der Analogie unseres Bahnprojektes ist neben dem Hauptgleis eine weitere Komponente unerlässlich, um Katastrophen zu verhindern: die Signaltechnik. Sie macht den Verkehr messbar und verhindert Zusammenstöße auf der Strecke – beziehungsweise Sicherheitsrisiken wie Halluzinationen, Data Leakage oder Prompt Injections, wie sie in den branchenweiten OWASP Top 10 for Large Language Model Applications definiert sind.

Ohne Signaltechnik bekommt unsere Bahnstrecke vom Eisenbahn-Bundesamt (EBA) keine Zulassung. Bei AI Applications ist das nicht zwangsläufig der Fall. Erst wenn die Applikation unter Stufe 3 (Hochrisikosystem) des EU AI Acts fällt, wird die Verwendung gewisser Observability-Mechanismen Pflicht. Während das Regularium des EBA jedoch strikte Vorgaben enthält, ist der EU AI Act eher offen gehalten. Wie setzen wir diese Anforderungen also in der Praxis um?

Tracing mit OpenTelemetry

Um die geforderte „Signaltechnik“ für unsere Bahnstrecke zu etablieren und den Anforderungen von Regulierungsbehörden sowie internen Qualitätsansprüchen gerecht zu werden, müssen wir entlang der Strecke Sensoren installieren. Diese Sensoren erfassen jede Zugbewegung, protokollieren Weichenstellungen und melden Auffälligkeiten in Echtzeit an ein zentrales Stellwerk. Übertragen auf unsere KI-Architektur bedeutet das: Wir müssen den Weg der Datenverarbeitung instrumentieren.

Technologisch greift man hierbei auf das Konzept des Tracings zurück. Der etablierte De-facto-Standard hierfür ist OpenTelemetry (OTel) – ein quelloffenes, vendor-neutrales Framework der Cloud Native Computing Foundation (CNCF). OTel definiert eine einheitliche Spezifikation, wie Telemetriedaten (Traces, Metrics, Logs) standardisiert generiert, gesammelt und exportiert werden, unabhängig von der verwendeten Programmiersprache oder dem finalen Analyse-Tool. Ein vollständiger Durchlauf einer Nutzeranfrage – die gesamte Fahrt unseres Zuges vom Start- zum Zielbahnhof – wird in diesem Standard als Trace bezeichnet. Dieser Trace setzt sich aus einzelnen Spans zusammen, welche die isolierten Teilschritte und Knotenpunkte der Informationsverarbeitung repräsentieren. Dabei gehören zu jedem Span mehrere Attributes.

Betrachten wir dies an einem konkreten Beispiel: einer Retrieval-Augmented Generation (RAG) Pipeline. Ein Nutzer stellt eine Frage, das System sucht in einer Vektordatenbank nach relevantem Kontext und übergibt diesen an das LLM, welches die finale Antwort generiert.

Um diesen Ausführungspfad transparent zu machen, instrumentieren wir den Code über das OTel-SDK:

Distributed Traces als Datenstruktur

Moderne LLM-Observability-Frameworks (wie Langfuse, Arize Phoenix, MLFlow oder spezialisierte Integrationen von Datadog, um nur ein paar zu nennen) setzen unter der Haube zunehmend exakt auf diesen OTel-Standard, integrieren jedoch entscheidende entwicklerergonomische Vereinfachungen. Statt Traces manuell zu öffnen und Attribute einzeln zuzuweisen, genügen in diesen Frameworks oft simple Decorators, die den Boilerplate-Code auf ein Minimum reduzieren und Modellspezifika – wie Token-Nutzung oder den gewählten System-Prompt – automatisch erfassen.

Doch wie gelangen diese lokalen Aufzeichnungen nun in das Dashboard der Entwickler? Hier entfaltet die standardisierte Architektur von OpenTelemetry ihre Stärke: Die durch die Code-Erweiterungen (Instrumentierung) generierten Metadaten werden nicht direkt in die Hauptanwendung geschrieben, sondern von einem sogenannten Exporter im Hintergrund (asynchron) gesendet. Dieser übermittelt die Daten an einen OTel Collector – quasi das Stellwerk – welcher die Daten empfängt, filtert und an das gewünschte Frontend weiterleitet. Dieses Frontend kann eine spezialisierte GenAI-Plattform, aber auch ein generalistisches Tool wie Grafana sein. Wichtig dabei: Der eigentliche Ablauf der KI-Anwendung wird durch diesen asynchronen Versandprozess nicht verlangsamt.

Einheitliches Vokabular: Semantic Conventions

Damit nicht nur der Transport, sondern auch die Inhalte der Daten herstellerübergreifend verstanden werden, definiert die CNCF zusätzlich sogenannte Semantic Conventions (semantische Konventionen). Diese geben ein festes Vokabular für die Telemetriedaten vor. Im GenAI-Umfeld ist das essenziell: Wenn Tool A die Eingabe-Tokens prompt_tokens  und Tool B sie input_length nennt, wird eine zentrale Auswertung unmöglich. Die Semantic Conventions legen daher fest, dass dieser Wert branchenweit einheitlich beispielsweise unter dem Schlüssel genai.usage.input_tokens protokolliert wird.

Von der Blackbox zur auditierbaren Glassbox

Was auf Code-Ebene nach einer technischen Pflichtaufgabe aussieht, liefert durch diese Standardisierung im Frontend eine immense Detailtiefe. Statt eines simplen „Status: OK“ wird ein hierarchischer Trace Tree visualisiert. Für jeden Span wird ein detaillierter Payload (meist im JSON-Format) erfasst.

Um dies greifbar zu machen, betrachten wir einen exemplarischen Payload für den LLM-Aufruf (den zweiten Span unseres Beispiels), der sich an den CNCF-Konventionen orientiert:

Anhand solcher exakt strukturierten Daten können wir ablesen:

• Welcher dynamische Kontext wurde im Retrieval-Span aus der Datenbank geladen?
• Welcher System-Prompt, welches Modell und welche Hyperparameter wurden verwendet?
• Wie hoch waren Latenz und Token-Verbrauch auf die Millisekunde und den Cent genau?

Genau hier schließt sich der Kreis zur Auditierbarkeit und Vorgaben wie dem EU AI Act: Produziert ein Agent eine Halluzination, missachtet Vorgaben oder generiert toxische Inhalte, lässt sich anhand dieser standardisierten Payloads rückwirkend lückenlos nachvollziehen, ob die Ursache ein irrelevanter Eintrag in der Vektordatenbank, eine fehlerhafte Systemanweisung oder ein Modell-Artefakt war. Die inhärente Blackbox der generativen KI wird so – zumindest auf Prozessebene – zur auditierbaren Glassbox. Damit ist die Grundvoraussetzung für den professionellen Betrieb geschaffen. 

Jedoch ist Tracing noch keine Evaluation, sondern deren notwendige Voraussetzung. Ein Trace zeigt zwar exakt, wie die KI zu einem Ergebnis kam, er verrät aber nicht, ob die finale Antwort korrekt ist. Um im Bild zu bleiben: Das Stellwerk misst die Pünktlichkeit des Zuges, kennt aber nicht die Zufriedenheit der Fahrgäste.

Die Teststrecke: Vom Produktions-Trace zum strukturierten Experiment

Um aus den gesammelten Rohdaten echte Qualitätsmetriken zu destillieren, verlassen die Daten nun die Hauptstrecke und wechseln auf unser parallel verlaufendes Messsystem. Das Fundament für belastbare Experimente sind reale Daten.

Wir greifen also auf unsere via OpenTelemetry gesammelten Produktions-Traces zurück und extrahieren daraus hunderte von echten Nutzeranfragen. Um echte Leistungsvergleiche durchführen zu können, wird dieser Datensatz oft noch mit sogenannten „Golden Answers“ – also Menschen geprüften, idealen Referenzantworten – angereichert. Dieser validierte Datensatz bildet fortan unseren Prüfstand.

Als Labor für diesen Prüfstand können wir ein beliebiges Experimentationframework nehmen. Die meisten etablierten Experimentationframeworks haben sich an die GenAI Welt von heute angepasst. In unseren Beispielen nehmen wir MLflow. 

Während OTel die Sensorik in der Produktion darstellt, ist MLflow die Orchestrierungs-Plattform für den Entwicklungszyklus. Es erlaubt uns, eine neue Konfiguration (etwa ein neues Basis-Modell, eine veränderte Chunk-Größe oder einen optimierten System-Prompt) systematisch gegen unseren historischen Datensatz antreten zu lassen.

In der Praxis lässt sich ein solcher Experimentierbaukasten mit dem richtigen Framework recht leicht aufbauen. So hat zum Beispiel MLFlow einen OTel HTTP Endpoint (/v1/traces) an den von gängigen OTel Exportern die Production Traces gesendet werden können. Sind die Traces mit GenAI Semantic Conventions angefertigt, kann MLFlow sie direkt erkennen und anzeigen. Im MLFlow UI können wir dann die gesammelten Traces filtern, annotieren und zu Evaluationsdatensätzen zusammensammeln. 

Das Ende des Vibe-Checks: Warum wir experimentieren müssen

Wer LLM-Applikationen ohne einen solchen Experimentierbaukasten entwickelt, tappt unweigerlich in die Regressions-Falle. Ein klassisches Szenario: Ein Nutzer meldet, dass der RAG-Agent eine spezifische Frage falsch beantwortet hat. Der Entwickler passt daraufhin den System-Prompt an, testet die Frage manuell und freut sich über das nun korrekte Ergebnis (der sogenannte „Vibe-Check“). Was er nicht sieht: Diese minimale Anpassung hat die Applikation für 20 andere, bisher perfekt funktionierende Anfragen unbrauchbar gemacht.

Systematische Experimente eliminieren diesen Blindflug und bieten drei entscheidende Vorteile:

• Verhinderung von Regressionen: Jede Änderung muss sich gegen den historischen Gesamtdatensatz beweisen. Sinkt die Gesamtperformance, geht das Update nicht in Produktion.
• Datengetriebene Architektur-Entscheidungen: Lohnt sich der Wechsel von gpt-4o-mini auf das teurere gpt-4o? Das Experiment liefert harte Zahlen: Sinkt die Fehlerquote signifikant oder steigen primär nur die API-Kosten?
• Lückenlose Reproduzierbarkeit: MLflow versioniert nicht nur die Ergebnisse, sondern auch den exakten Code, den Prompt und die Hyperparameter jedes Laufs. Nichts geht mehr verloren, jeder Zustand der Applikation lässt sich wiederherstellen.

Warum wir auch im Labor tracen müssen

Ein häufiger Irrglaube ist, dass Tracing (wie im vorherigen Abschnitt beschrieben) nur für das Monitoring der Live-Produktion relevant sei. Tatsächlich ist es im Experimentierlabor mindestens genauso kritisch.

Wenn uns unser Prüfstand nach einem Durchlauf meldet, dass Version B eine 15% höhere Fehlerrate aufweist als Version A, haben wir ein Symptom, aber noch keine Diagnose. Genau hier entfaltet das Tracing im Experiment seine Stärke: Es schafft Vergleichbarkeit. In der UI können wir den Trace einer fehlgeschlagenen Anfrage aus Version B direkt neben den erfolgreichen Trace aus Version A legen.

Dabei sehen wir exakt, an welchem Knotenpunkt im Graph die neue Pipeline falsch abgebogen ist. Hat das veränderte Retrieval plötzlich irrelevante Chunks aus der Vektordatenbank geladen? Oder war der Kontext korrekt, aber das LLM hat aufgrund des neuen Prompts halluziniert? Tracing im Experiment liefert die Antwort vor dem Rollout.

Zusätzlich sind viele Evaluationsmethoden heutzutage LLM-as-a-Judge Verfahren. D.h. die Ausgaben der KI Applikation werden mittels eines anderen Modells überprüft. Das macht unseren Prüfstand allerdings selbst zu einer KI Applikation. Damit wir also garantieren können, dass unsere LLM-basierter Richter auch tatsächlich positive Ergebnisse für Positiv befindet und negative für Negativ, sollten wir die Experimente selbst tracen anhand von Menschen-geprüften Referenzjudgements überprüfen.

Ausblick: Der TÜV für unsere Modelle

Um in unserer Bahn-Analogie zu bleiben: Wir haben nun ein modernes Gleissystem nebst Signaltechnik und einem modernen Prüfstand aufgebaut und beide mitfeinsten Sensoren ausgestattet. Wir können exakt messen, wie schnell der Zug fährt und wie viel Strom er verbraucht. Doch wer entscheidet eigentlich, ob die Fahrt angenehm war? Wer prüft, ob die Antworten der KI inhaltlich korrekt, sicher und relevant sind?

Die bloße Existenz von Infrastruktur beantwortet noch keine Qualitätsfragen. Die genauen Evaluierungsmethoden – von klassischen heuristischen Textmetriken (wie ROUGE oder BLEU) über RAG-spezifische Frameworks (wie RAGAS) bis hin zu modernsten Ansätzen, bei denen ein mächtiges LLM die Antworten eines anderen LLMs bewertet (LLM-as-a-Judge) – bilden die eigentliche Instanz der Qualitätskontrolle. Sie sind die TÜV-Prüfer und Fahrgastbefrager unseres Systems und werden im nächsten Artikel dieser Serie detailliert beleuchtet.