Kapitel 5 — LLM-Anwendungen evaluieren

Fünfter Beitrag der kapitelweisen Tour durch LLM Primer V: Building Real-World LLM Applications. Das Kapitel räumt ein, dass assertEqual für LLM-Outputs tot ist, und baut die Testdisziplin neu um verankerte Judges, die RAG-Triade und Trajectory-Tests auf.

Warum dieses Kapitel existiert

Klassisches Software-Testing ruht auf der Annahme, dass ein korrekter Output ein spezifischer Output ist — die Funktion gibt 42 zurück, der String ist gleich „Hello, world“, das JSON passt zum Fixture. LLM-Systeme produzieren Paraphrasen, die bedeutungsäquivalent, aber zeichenverschieden sind, und die Exakt-Match-Assertion, die das Software-Testing fünfzig Jahre lang verankert hat, klappt beim ersten Neu-Generieren zusammen. Teams greifen dann nach BLEU, ROUGE oder Embedding-Cosinus-Ähnlichkeit und entdecken, dass diese Metriken schwach mit menschlichem Urteil zu dem korrelieren, worauf es ankommt — ist die Antwort richtig, ist sie geerdet, adressiert sie die Frage. Kapitel 5 baut die Testdisziplin um das herum neu, was wirklich funktioniert: verankerte LLM-as-Judge-Rubriken, die RAG-Triade, Trajectory-Tests für Agenten und eine kontinuierliche Schleife, in der Produktions-Traces die Evaluationsmenge speisen, die das nächste Release durchlässt.

5.1 Die Evaluationslücke und LLM-as-a-Judge

Die Evaluationslücke ist die Distanz zwischen dem, was ein klassischer Test messen kann, und dem, was ein LLM-Output tatsächlich gemessen haben will. Exakt-Match und Referenzstring-Metriken fangen bei paraphrasenreichen Aufgaben nichts von den interessanten Fehlern. LLM-as-a-Judge ist der Arbeitsesel, der die Lücke schließt, mit zwei Disziplinen, die ihn vom Partytrick trennen. Erstens ist die Rubrik des Judges verankert: Jeder Punktwert hat eine schriftliche Definition, idealerweise mit Beispiel, sodass der Judge keine Zahl frei assoziiert. Zweitens produziert der Judge Begründung vor dem Score, weil ein Judge, der seine Begründung ausschreiben muss, ein Judge ist, der konsistenter bewertet. Programmatische Checks ergänzen den Judge für das, was deterministisch verifizierbar ist — JSON parst, benötigte Felder vorhanden, keine verbotenen Strings, Antwortlänge in Grenzen. Der Judge ist nicht universell; er ist das, was das Terrain abdeckt, das die deterministischen Checks nicht können.

5.2 Die RAG-Triade — Kontext, Groundedness, Antwortrelevanz

Für Retrieval-Systeme hat sich das Muster durchgesetzt, drei Ecken unabhängig zu bewerten. Kontextrelevanz fragt, ob die abgerufenen Chunks wirklich relevant für die Query sind, und isoliert Retrieval-Fehler von Generierungs-Fehlern. Groundedness fragt, ob die erzeugte Antwort aus dem abgerufenen Kontext folgt, und fängt Halluzinationen, die die Formvalidierung passieren. Antwortrelevanz fragt, ob die Antwort die Frage adressiert, die der Nutzer tatsächlich gestellt hat. Unabhängig bewertet lokalisieren die drei Ecken Fehler: Ein niedriger Kontextrelevanz-Score deutet auf Retrieval, ein niedriger Groundedness-Score auf den Generator, ein niedriger Antwortrelevanz-Score auf entweder den Router oder ein System, das eine benachbarte Frage beantwortet. RAGAS operationalisiert die Triade als Batch-Pipeline; die Qualität des Judge-Modells dominiert die Qualität der Scores, sodass der Judge selbst eine Komponente ist, die das Team evaluiert.

5.3 Framework-Nischen und Agenten-Regression

Drei Frameworks besetzen distinkte Nischen. RAGAS lässt die RAG-Triade im Batch gegen eine Datenmenge aus Frage-Antwort-Paaren laufen und ist das richtige Werkzeug für periodische Datensatz-Evaluation. TruLens hängt Feedback-Funktionen an Live-Produktions-Traffic und rechnet die Triade auf den Traces selbst aus, wodurch die Schleife zwischen Produktion und Evaluation geschlossen wird. DeepEval läuft LLM-Tests als CI-Gates so, wie pytest Unit-Tests laufen lässt, mit Schwellen pro Metrik. Agenten dehnen all das in drei Richtungen aus: Trajectory-Snapshot-Tests behaupten die Form der Tool-Call-Sequenz für einen fixen Input und fangen strukturelles Driften; Invariant-Assertions verifizieren, dass der Agent kein verbotenes Werkzeug aufgerufen und keine benötigte Freigabe übersprungen hat; Rubrik-Tests bewerten die Trajectory selbst darauf, ob der Weg vernünftig war. Ein Agent, der die richtige Antwort auf dem falschen Weg gibt, ist eine Prompt-Änderung von der falschen Antwort auf demselben Weg entfernt, und der Trajectory-Test ist die Disziplin, die das fängt.

Was Kapitel 5 vorbereitet

Evaluationen brauchen Produktions-Traces zum Sampeln. CI-Gates brauchen echte Regressionen, gegen die sie schützen. Die kontinuierliche Verbesserungsschleife funktioniert nur, wenn eine Observability-Schicht jeden Schritt jedes Aufrufs erfasst — die Modellaufrufe, die Tool-Aufrufe, die Retrieval-Ergebnisse, die Sub-Agenten-Sprünge, die Kosten, die Latenz, das Nutzer-Feedback. Kapitel 6 ist diese Schicht. Es schreitet OpenTelemetry mit GenAI-Semantik-Konventionen ab, die Metriken, auf die es bei LLM-Systemen wirklich ankommt, die Plattformentscheidungen und — am wichtigsten — die Export-Pipeline, die niedrig bewertete Traces zurück in die Eval-Menge routet, die das nächste Release durchlässt.

Als Nächstes — Kapitel 6: KI-Observability und Tracing. Das Substrat, das sowohl Evaluation als auch Debugging möglich macht — ein geschachtelter Trace pro Aufruf, mit Kosten und Qualität als erstklassige Attribute daran.