Kapitel 10 — Führende Evaluations-Frameworks

Zehnter Beitrag der kapitelweisen Tour durch LLM Primer III: Enhancing Enterprise AI with RAG. Darin: Die Triade bekommt ein Werkzeugset — acht Frameworks in zwei Geschmacksrichtungen — und ein ehrliches Eingeständnis darüber, welchen Teil der Evaluation noch keine löst.

Warum dieses Kapitel existiert

Die Triade aus Kapitel 9 sagte, was zu messen ist. Sie sagte nichts darüber, wie man diese Messungen in Produktion tatsächlich fährt. Die Metriken sind Konzepte. Ihre Implementierungen sind Prompts für den Judge, Zerlegungslogik für Behauptungen, Embedding-Wahl für Ähnlichkeit, Sampling-Strategien für Kosten, Dashboards, Alerts und Human-Review-Schleifen. Kein Team baut das alles von Grund auf.

Die Frameworks haben sich entlang einer erkennbaren Achse aufgespalten. Auf der einen Seite die metrik-zuerst-Bibliotheken — RAGAS, TruLens, DeepEval — die die Triade mit dokumentierter, reproduzierbarer Methodik berechnen. Auf der anderen die Observability-Plattformen — Braintrust, LangSmith, Phoenix, Galileo, Opik — die von Produktions-Traces ausgehen und Evaluation als eines unter mehreren Features in einem größeren Workflow integrieren. Die Wahl ist weniger ein Feature-Vergleich als die Frage, was das Team am Tag nach dem Launch vom System braucht.

10.1 Die metrik-zuerst-Bibliotheken — RAGAS, TruLens, DeepEval

RAGAS ist dem Feld das nächste an einer Referenzimplementierung der Triade. Konservatives Metrik-Set, dokumentierte Prompts, jeder LLM-Aufruf exponiert. Die Faithfulness-Pipeline ist eine zweistufige Kette — Antwort in Behauptungen zerlegen, jede Behauptung gegen den Kontext prüfen — und die Zwischen-Behauptungsliste kommt im Ergebnis zurück, sodass eine Ingenieurin auf die spezifische Behauptung zeigen kann, die das Framework als ungestützt einstufte. Für Forschung, regulierte Industrien oder jedes Team, das seine Methodik verteidigen muss, ist RAGAS die Voreinstellung. Der Preis ist, dass es akademisch wirkt. Es berechnet Metriken; es liefert kein Dashboard.

TruLens sitzt zwischen Metrik-Bibliothek und Observability-Plattform. Der Schwerpunkt liegt auf Instrumentierung: Das Framework umhüllt die Anwendung auf Funktionsebene, fängt jeden Retrieval-Aufruf und jede Modellantwort in einen strukturierten Trace ein und lässt dann die Triade gegen die Traces laufen. Die Triade-Metriken sind als Feedback-Funktionen exponiert — kleine, komponierbare Einheiten, eigene leicht zu schreiben. TruLens ist die richtige Wahl, wenn die Evaluationsbedürfnisse des Teams das Standardset übersteigen oder der Workflow sich auf die Inspektion einzelner Fehlfälle statt auf aggregierte Dashboards stützt.

DeepEval nimmt eine dritte Haltung ein: Evaluation als pytest. Testfälle werden geschrieben und mit einer pytest-artigen CLI ausgeführt; Versagen blockieren den PR; das Metrik-Set ist das breiteste der drei und enthält neben der Triade Bias-, Toxizitäts- und Halluzinations-Checks. Der Tradeoff: Die Breite kommt mit ungleichmäßiger Strenge. Greift man blind eine Metrik vom Buffet, kann man Zahlen melden, die nicht bedeuten, was man denkt. Die richtige Disziplin ist, ein kleines Set auszuwählen, die Prompts zu lesen, gegen Handlabels zu kalibrieren und den Rest als Inspiration zu behandeln.

10.2 Die Observability-Plattformen — Braintrust, LangSmith, Phoenix, Galileo, Opik

Die metrik-zuerst-Bibliotheken beantworten "wie berechne ich die Triade". Die Observability-Plattformen beantworten "wie betreibe ich ein RAG-System in Produktion". Sie gehen davon aus, dass das Team auf absehbare Zeit Prompts schreibt, Modellversionen vergleicht, Traces aufnimmt und Dashboards beobachtet. Evaluation ist ein Feature; Prompt-Versionierung, Trace-Exploration, A/B-Tests und Alerting gehören gleichberechtigt zum Wert.

Braintrust führt mit Developer Experience — das Experiment, ein versionierter Datensatz von Modellverhalten auf einem Datensatz, mit Side-by-Side-Score-Diffs in einem UI, das tatsächlich angenehm zu benutzen ist. LangSmith ist die natürliche Wahl für Teams, die tief in LangChain stecken; es erwartet, im Zentrum der Anwendungsinstrumentierung zu sitzen, und belohnt das Bekenntnis mit Tiefe. Phoenix, von Arize, ist die Open-Source-Option, ausgezeichnet durch Embedding-Drift- und Cluster-Analyse, die die anderen untergewichten — gangbar für Teams, die keine Traces an einen SaaS-Endpunkt schicken dürfen. Galileo ist die enterprise-fokussierte Plattform, mit einem proprietären Correctness-Score und On-Prem-Deployment für regulierte Industrien. Opik, von Comet, ist der jüngste Neuzugang, Open-Source-first wie Phoenix, poliert wie Braintrust, mit dem zusätzlichen Vorteil, LLM- und klassische ML-Observability auf einer Plattform zu vereinen.

Die Wahl unter den fünf hängt weniger an Features als an organisatorischer Passung. Ein LangChain-Shop greift zu LangSmith. Ein Greenfield-Produkt-Engineering-Team zu Braintrust. Ein Open-Source-first-Team zu Phoenix. Ein reguliertes Enterprise zu Galileo. Ein Comet-Shop zu Opik. Die Metrik-Qualität ist über alle fünf vergleichbar — sie implementieren alle die Triade, nutzen alle LLM-as-Judge, tragen alle dieselben fundamentalen Beschränkungen, die Kapitel 9 benannt hat. Die Unterschiede sind Workflow, nicht Messung.

10.3 Die Evaluation Gap und das Drei-Schleifen-Muster

Hier ist die unangenehme Tatsache, über die der Framework-Rundgang hinweggegangen ist. Fast jedes Werkzeug oben evaluiert auf der Inferenz-Schicht: Angenommen, das Retrieval ist passiert, hat das Modell die Chunks geehrt, passt die Antwort zur Frage, waren die Chunks themengerecht. Keines sagt dir, in einem tieferen Sinn, ob das Retrieval die richtigen Chunks überhaupt gefunden hat. Der Output des Retrievers ist der Input der Inferenz-Schicht, und die Metriken der Inferenz-Schicht messen den Output, aber nicht den Input. Wenn das Retrieval ein wichtiges Dokument konsistent verfehlt, bleibt Faithfulness hoch (das Modell ehrte, was es bekam), bleibt Answer Relevance hoch (die Antwort passte zur Frageform), und die Nutzer bekommen trotzdem die falsche Antwort.

Das ist die Evaluation Gap. Der strukturelle Grund ist, dass Inferenz-Schicht-Evaluation referenzfrei ist, während rigorose Kontext-Schicht-Evaluation wissen muss, welche Chunks die richtigen waren — was entweder ein gelabeltes Set oder ein synthetisches verlangt. Die Workarounds — synthetische Fragegenerierung, Needle-in-a-Haystack-Sonden, Downstream-Impact-Proxies, query-konditioniertes Retrieval-Auditing, Retrieval-gegen-sich-selbst — sind alle nützlich und alle unvollständig. Die ehrliche Zusammenfassung: Kontext-Schicht-Evaluation ist die offene Frontier, und Teams sollten erwarten, einen Teil ihres eigenen Engineerings direkt in Retrieval-Qualität zu investieren. Die Frameworks helfen mit der Inferenz-Schleife; die Retrieval-Schleife überlassen sie meist dem Team.

Das Muster, auf das gereifte Teams zulaufen, sind drei Schleifen, nicht eine. Innere Schleife: eine metrik-zuerst-Bibliothek (typisch RAGAS oder DeepEval) fährt die Triade auf einem festen Regressions-Set bei jeder bedeutsamen Änderung, schnell und deterministisch, ausgerichtet aufs Einfangen von Regressionen. Äußere Schleife: eine Observability-Plattform übernimmt Produktions-Trace-Speicherung, Online-Metriken auf gesampeltem Traffic, Dashboards und Alerts — ausgerichtet auf Drift, den das Regressions-Set verfehlt. Langsame Schleife: eine kleine Human-Review-Funktion kalibriert die LLM-Judges, auditiert markierte Traces und pflegt das Regressions-Set, während das Produkt sich entwickelt. Ein Team mit nur der inneren Schleife shipt driftende Produktion. Ein Team mit nur der äußeren sieht den Drift, kann ihn aber nicht debuggen. Ein Team mit beiden, aber ohne Human Review, vertraut Judges, die still falsch werden. Alle drei sind nötig, und der Wert der Frameworks liegt darin, wie viel von jeder Schleife sie leicht machen.

Was Kapitel 10 vorbereitet

Zwischen der Triade aus Kapitel 9 und den Frameworks aus Kapitel 10 hat ein Team, was es braucht, um ein RAG-System zu messen: ein Vokabular, eine ehrliche Buchführung darüber, was das Vokabular verfehlt, und ein kleines Set Werkzeuge, das die Messungen in Dashboards verwandelt. Das System wird lesbar. Aber Messung ist nur die Hälfte der Produktionsgeschichte. Ein System, das gemessen, aber nicht gewartet wird, wird trotzdem abdriften, denn die Dokumente ändern sich, die Nutzer ändern sich, die zugrundeliegenden Modelle ändern sich. Zu wissen, dass die Qualität gefallen ist, ist nicht dasselbe wie sie wiederherstellen zu können.

Als Nächstes — Kapitel 11: Kontinuierliche Updates und Pipeline-Optimierung. CDC und inkrementelle Indizierung, semantisches Caching und Model-Tiering und die vierstufige Feedback-Schleife, die Produktions-Telemetrie in die Art System verwandelt, das tatsächlich besser wird, je länger es läuft.