22.06.2026 AI Engineering 6 Minuten Lesezeit

Eval-getriebene Entwicklung für LLM-Systeme

Demos beweisen, dass ein LLM-System einmal funktionieren kann; Evals beweisen, dass es zuverlässig funktioniert. Der Artikel definiert goldene Testsets, die vier RAGAS-Standardmetriken für RAG-Pipelines, LLM-as-Judge mit dokumentierten Verzerrungen und verifizierten Gegenmaßnahmen, Offline- versus Online-Evaluation und Regressions-Gates in der CI — dazu Trajektorien- und Tool-Call-Evaluation für Agenten, mit Zahlen aus MT-Bench, τ-bench und dem Berkeley Function-Calling Leaderboard.

Warum die Demo täuscht

Eine Demo zeigt einen einzelnen, zufällig gezogenen Pfad durch ein nicht-deterministisches System. Große Sprachmodelle erzeugen für identische Eingaben unterschiedliche Ausgaben; eine Demo beweist also Existenz — das System kann diese Antwort produzieren — nicht Zuverlässigkeit. Klassische Unit-Tests setzen deterministische Ausgaben voraus; diese Annahme gilt hier nicht. OpenAIs Evaluations-Leitfaden benennt das resultierende Anti-Pattern direkt: "vibe-based evals" — ausliefern, weil die Ausgabe gut aussieht. Evals, also strukturierte und wiederholbare Messungen gegen definierte Kriterien, sind der Ersatz.

Die Kosten des Nicht-Messens sind konkret. Das Engineering-Team von Airbnb, das generative KI im großen Maßstab evaluiert, nennt drei wiederkehrende Fehlermuster Eval-freier Entwicklung: falsche Sicherheit (eine generische Hilfreichkeits-Metrik liefert gute Werte, während der Fehlermodus, den Nutzer tatsächlich treffen, ungemessen bleibt), unentdeckte Regressionen (eine Prompt-Änderung verschlechtert still eine Dimension, die niemand verfolgt) und verschwendeter Aufwand (Pipelines für Metriken, die nicht mit Ergebnissen korrelieren). Alle drei kosten nach dem Launch mehr als davor.

Eine Änderung landet — Prompt, Modell oder Retrieval. 1/4

Goldene Testsets als Fundament

Ein goldenes Testset ist eine kuratierte Sammlung von Eingaben mit menschlich geprüften Referenzausgaben oder Labels. Es operationalisiert, was "gut" für genau diese Anwendung bedeutet. Airbnbs veröffentlichte Empfehlung: mit 50–100 von Fachexperten gelabelten Beispielen starten — und schlechte Beispiele einschließen, denn Urteilsvermögen lässt sich nicht an einem Set testen, das nur Erfolge enthält. Eine harte Regel: Widersprechen sich zwei Experten bei einem Label, klären Sie den Widerspruch, bevor Sie irgendetwas automatisieren. Ein an inkonsistenten Labels kalibrierter Judge kalibriert auf Rauschen.

Ein goldenes Set ist nicht statisch. Produktionsfehler sind die beste Quelle neuer Fälle: Jeder relevante Fehler wird zum Regressionstest, und über die Zeit wird das Set zum Protokoll der realen Qualitätsanforderungen der Anwendung. Was ein goldenes Set nicht leistet: Drift in Richtung von Traffic, den es nicht enthält, erkennt es nicht. Dafür gibt es Online-Evaluation.

Der Standard-Metriksatz für RAG

Für Retrieval-Augmented Generation hat das RAGAS-Framework (Es et al., 2023) einen De-facto-Standard aus vier Metriken etabliert, jeweils skaliert von 0 bis 1. Zwei bewerten die Generierung: Faithfulness ist der Anteil der Aussagen in der Antwort, die der abgerufene Kontext stützt; Response Relevancy rekonstruiert Fragen aus der Antwort (standardmäßig drei) und misst deren mittlere Embedding-Ähnlichkeit zur tatsächlich gestellten Frage. Zwei bewerten das Retrieval: Context Precision ist die mittlere Precision@k über die gerankten Chunks; Context Recall misst, ob die für die Referenzantwort nötigen Informationen überhaupt abgerufen wurden.

Grenzen Sie ehrlich ab: Faithfulness ist nicht faktische Korrektheit. Eine Antwort kann einem falschen oder veralteten Kontext vollkommen treu sein — und trotzdem falsch. Alle vier Metriken nutzen zudem selbst ein LLM oder Embeddings und erben damit Judge-Rauschen. Behandeln Sie sie als Trendindikatoren über einem festen Datensatz, nicht als absolute Wahrheiten.

Metrik	Bewertet	Beantwortete Frage	Typischer erkannter Fehler
Faithfulness	Generierung	Werden alle Aussagen der Antwort durch den abgerufenen Kontext gestützt?	Halluzination jenseits des Kontexts
Response Relevancy	Generierung	Beantwortet die Antwort die tatsächlich gestellte Frage?	Ausweichende oder themenfremde Antworten
Context Precision	Retrieval	Stehen relevante Chunks im Ranking vor irrelevanten?	Verrauschtes Ranking
Context Recall	Retrieval	Wurden alle für die Referenzantwort nötigen Informationen abgerufen?	Fehlende Belege

LLM-as-Judge und seine Verzerrungen

LLM-as-Judge bedeutet, ein starkes Modell die Ausgabe eines anderen Modells gegen eine Rubrik bewerten zu lassen. Die validierende Studie ist Zheng et al. (2023): Auf MT-Bench stimmten die Urteile von GPT-4 in über 80 % der Fälle mit menschlichen Präferenzen überein — derselbe Wert, mit dem die menschlichen Bewerter untereinander übereinstimmten. Dieselbe Arbeit dokumentiert, warum man Judges nicht blind vertrauen darf.

Drei Verzerrungen sind gut repliziert. Positionsbias: Urteile kippen, wenn die Reihenfolge der verglichenen Antworten getauscht wird. Verbosity-Bias: Im "Repetitive-List"-Angriff von Zheng et al. wurden Antworten, die mit umformulierten Duplikaten aufgebläht waren, höher bewertet; alle getesteten Judges waren in gewissem Maß anfällig, GPT-4 widerstand deutlich besser als die übrigen. Self-Preference: Eine Studie von 2024 (arXiv 2410.21819) führt sie auf Perplexität zurück — Judges bewerten Text, der ihnen statistisch vertraut ist, höher als menschliche Bewerter, unabhängig davon, wer ihn tatsächlich geschrieben hat.

Die verifizierten Gegenmaßnahmen: Positionen tauschen und beide Urteile mitteln; Chain-of-Thought vor der Bewertung erzwingen; referenzgeführtes Urteilen einsetzen, bei dem der Judge zuerst eine eigene Antwort erzeugt — im Mathe-Bewertungstest von Zheng et al. sanken die Fehlurteile damit von 14/20 auf 3/20. Vor allem: kalibrieren. Messen Sie die Übereinstimmung mit menschlichen Labels (Cohens Kappa) auf dem goldenen Set, zielen Sie auf Werte in den hohen 80ern bis 90ern und rekalibrieren Sie regelmäßig. Ein unkalibrierter Judge erzeugt falsche Sicherheit — schlimmer als gar keiner.

Offline- und Online-Evaluation

Offline-Evaluation läuft vor der Auslieferung einer Änderung auf kuratierten Datensätzen; Online-Evaluation läuft danach auf gesampelten Produktions-Traces. Jede fängt, was die andere verpasst. Offline-Gates erkennen Regressionen gegen bekannte Fälle, veralten aber, wenn sich der Traffic verschiebt. Online-Evaluation erkennt Drift, unerwartete Eingaben und neue Fehlermodi, hat aber keine Ground Truth; Nutzerfeedback ist spärlich und verrauscht. Guardrails sind der synchrone Spezialfall der Online-Evaluation: Prüfungen im Request-Pfad, die eine Ausgabe blockieren, bevor sie den Nutzer erreicht.

Beide Modi bilden eine Schleife. Offline-Experimente validieren eine Änderung vor dem Deployment; Online-Sampling findet die Fälle, die der Datensatz nicht abdeckt; diese Fälle fließen zurück ins goldene Set, sodass der nächste Offline-Lauf sie erfasst. Teams, die nur eine Hälfte der Schleife betreiben, messen nur die Hälfte ihres Systems.

Regressions-Gates in der CI

Ein Regressions-Gate führt die Eval-Suite in der CI gegen jede vorgeschlagene Änderung aus und lässt den Build fehlschlagen, wenn Scores fallen. Das Tooling ist ausgereift: Die experiment-action von Langfuse für GitHub Actions etwa bricht den Job ab und postet die Scores in den Pull Request, sobald ein Score unter den Schwellwert fällt.

Judge-basierte Metriken rauschen; ein naiver Einzelschwellwert flattert. Vier Regeln für ein Gate, das hält: 1. Deterministische Prüfungen hart gaten — Schema-Validität, Ausgabeformat und Tool-Call-Syntax mit Null-Toleranz. 2. Judge-Metriken über Deltas zur Baseline gaten, mit Wiederholungsläufen oder Konfidenzintervallen, nie über einen Einzellauf. 3. Nie ein Aggregat einen kritischen Fall verdecken lassen: sicherheits- und richtlinienkritische Beispiele müssen einzeln bestehen. 4. Neu fehlschlagende Beispiele von Hand prüfen, bevor ein rotes Gate übersteuert wird; ein Override ohne Diagnose löscht Information.

Agenten jenseits der finalen Antwort bewerten

Die Ausgabe eines Agenten ist eine Trajektorie: eine Folge aus Reasoning-Schritten, Tool-Calls und Zustandsänderungen. Nur die finale Antwort zu bewerten reicht nicht — eine korrekte Antwort kann falsche Tool-Argumente oder einen kaputten Pfad verdecken, und ein plausibles Transkript kann das dahinterliegende System im falschen Zustand hinterlassen. Tool-Call-Evaluation zerfällt daher in Schichten: Schema-Validität, Argument-Korrektheit (das Berkeley Function-Calling Leaderboard bewertet sie per AST-Vergleich gegen akzeptierte Antworten), Aufrufreihenfolge und Endzustand.

τ-bench (Yao et al., 2024) ist die Referenz für zustandsbasierte Agenten-Evaluation: Es vergleicht die Datenbank am Ende einer simulierten Kundenkonversation mit einem annotierten Zielzustand; jede Trajektorie, die den korrekten Zustand erzeugt, besteht. Zusätzlich misst es Zuverlässigkeit mit pass^k — der Wahrscheinlichkeit, dass alle k unabhängigen Versuche gelingen. GPT-4o mit Function Calling erreichte rund 61 % pass^1 in der Retail-Domäne, fiel bei pass^8 aber unter 25 %. Genau diese Lücke zwischen einem Lauf und acht verbirgt eine Demo.

Nehmen Sie Negativfälle auf. BFCLs Relevance Detection testet Eingaben, bei denen die korrekte Aktion gar kein Tool-Call ist. Ein Agent, der nur an Positivfällen bewertet wird, lernt, dass irgendein Aufruf immer besser ist als keiner — eine Lektion, die er in Produktion anwenden wird.

Ausblick: Evals als Spezifikation

Drei Entwicklungen zeichnen sich ab. Erstens werden Evals zur Spezifikation: Ein goldenes Set plus Evaluator-Definitionen beschreibt den Vertrag eines Systems präziser als ein Prosa-Anforderungsdokument, und Modell-, Prompt- und Orchestrierungsänderungen werden nur gegen diesen Vertrag beurteilt. Zweitens macht Trace-Standardisierung — etwa die GenAI Semantic Conventions von OpenTelemetry — Trajektorien-Evals über Frameworks hinweg portabel statt an einen Anbieter gebunden. Drittens wandert simulationsbasierte Evaluation, bei der Agenten wie in τ-bench gegen simulierte Nutzer und Sandbox-Umgebungen laufen, aus Forschungs-Benchmarks in die alltägliche CI.

Für unsere eigene Ingenieurspraxis bei Blue IT Systems folgt daraus eine einzige Betriebsregel: Ein Verhalten, das nicht in einem Eval kodiert ist, existiert nicht als Anforderung — und eine Metrik, auf die niemand reagieren würde, ist die Berechnung nicht wert. Alles andere ist eine Demo. Teams, die das verinnerlichen, liefern am ersten Tag langsamer aus — und jede Woche danach schneller.