Evals für AI-Features aufbauen: vom Bauchgefühl zur Messgröße

Viele Teams beurteilen die Qualität ihrer AI-Features nach demselben Verfahren: Man probiert ein paar Eingaben aus, die Antworten wirken plausibel, das Feature geht live. Was dabei fehlt, ist eine Messgröße. Evals, also systematische Auswertungen von Modellantworten gegen definierte Erwartungen, sind für AI-Features das, was Unit-Tests für klassische Software sind. Ohne sie bleibt jede Qualitätsaussage ein Bauchgefühl.

Das rächt sich spätestens bei der ersten Änderung. Ein umformulierter Prompt, ein Modellwechsel, ein zusätzliches Kontextdokument: Jede dieser Anpassungen verändert das Verhalten des Systems, und zwar nicht an einer Stelle, sondern in der Breite. Wer keine Evals hat, merkt das erst, wenn sich Nutzer beschweren. Und dann fehlt auch noch die Grundlage, um zu sagen, was genau schlechter geworden ist.

Warum AI-Features ohne Evals Blindflug sind

Klassische Software verhält sich deterministisch: Wer eine Funktion einmal getestet hat, weiß, was sie tut. Sprachmodelle verhalten sich anders. Dieselbe Eingabe kann unterschiedlich formulierte Antworten erzeugen, und kleine Änderungen am Kontext verschieben das Verhalten über viele Fälle hinweg. Das Verhalten eines AI-Features ist keine Funktion, sondern eine Verteilung.

Ein manueller Stichprobentest tastet diese Verteilung an einer Handvoll Punkte ab, meist an den freundlichen. In der Praxis zeigt sich: Die Fälle, an denen ein Feature scheitert, sind selten die, die ein Entwickler beim Ausprobieren eingibt. Es sind die schlecht formulierten Anfragen, die widersprüchlichen Dokumente, die Grenzfälle zwischen zwei Kategorien. Wer diese Fälle nicht systematisch prüft, fliegt blind. Und wer blind fliegt, kann auch nicht verbessern, denn ohne Messgröße ist jede Prompt-Änderung ein Münzwurf.

Der Prüffall-Katalog: echte Fälle statt ausgedachter Beispiele

Der Kern jedes Eval-Systems ist ein Prüffall-Katalog: eine Sammlung von Eingaben mit definierten Erwartungen an die Ausgabe. Der häufigste Fehler beim Aufbau ist, diese Fälle am Schreibtisch zu erfinden. Ausgedachte Beispiele spiegeln die Vorstellung des Teams, nicht die Realität der Nutzer.

Besser ist es, aus echten Quellen zu schöpfen:

• Produktionsdaten: anonymisierte echte Anfragen aus Logs, sofern rechtlich sauber geregelt.
• Support-Fälle: jede Beschwerde über eine falsche Antwort ist ein fertiger Prüffall.
• Fachliche Grenzfälle: Fälle, bei denen sich auch erfahrene Mitarbeiter kurz abstimmen müssen.
• Negativfälle: Eingaben, bei denen die richtige Antwort lautet, dass das System es nicht weiß oder nicht zuständig ist.

Wichtig ist, die Erwartung präzise, aber nicht zu eng zu fassen. Bei generierten Texten prüft man Eigenschaften, nicht Wortlaut: Enthält die Antwort die drei relevanten Punkte, nennt sie die richtige Quelle, verweigert sie die Auskunft, wo sie es soll. Ein Katalog mit einigen Dutzend guten Fällen ist ein brauchbarer Start. Er wächst dann mit jedem Vorfall aus dem Betrieb weiter.

Metriken: Genauigkeit, Vollständigkeit, Format

Eine einzelne Gesamtnote sagt wenig. Sinnvoller ist es, pro Prüffall mehrere Dimensionen getrennt zu bewerten:

• Genauigkeit: Stimmen die inhaltlichen Aussagen mit der Referenz überein. Erfundene Fakten, falsche Zahlen oder verdrehte Zusammenhänge fallen hier durch.
• Vollständigkeit: Sind alle geforderten Elemente enthalten. Eine korrekte, aber halbe Antwort ist in vielen Anwendungsfällen genauso unbrauchbar wie eine falsche.
• Format: Hält die Ausgabe die vereinbarte Struktur ein. Bei maschinell weiterverarbeiteten Ausgaben ist das eine harte Anforderung, die sich vollständig deterministisch prüfen lässt.

Als Faustregel gilt: deterministisch prüfen, wo es geht, modellbasiert prüfen, wo es sein muss. Struktur, Pflichtfelder, verbotene Inhalte und Längen lassen sich mit gewöhnlichem Code verifizieren. Für offene Textqualität hat sich der Einsatz eines Modells als Prüfer etabliert. Dieser Prüfer ist aber selbst fehlbar und muss kalibriert werden: Man vergleicht seine Urteile regelmäßig mit menschlichen Bewertungen derselben Fälle und schärft die Prüfkriterien nach, bis beide hinreichend übereinstimmen.

Evals in den Entwicklungsprozess einbauen

Evals entfalten ihren Wert erst, wenn sie so selbstverständlich laufen wie Tests. Das heißt konkret: Jede Änderung an Prompt, Modellversion, Retrieval oder Werkzeugdefinition löst einen Eval-Lauf aus, idealerweise automatisiert in der CI-Pipeline, mindestens aber als fester Schritt vor jedem Release. Prompt-Versionen und Eval-Ergebnisse gehören gemeinsam versioniert, damit nachvollziehbar bleibt, welche Änderung welche Wirkung hatte.

Hilfreich ist außerdem eine definierte Schwelle: Unter welchem Ergebnis wird nicht ausgeliefert. Diese Schwelle zwingt zu einer Entscheidung, die sonst implizit und im Zweifel optimistisch getroffen wird. Wer sie einmal festgelegt hat, diskutiert nicht mehr über Eindrücke, sondern über Messwerte.

Regressionen erkennen, bevor es die Nutzer tun

Der größte praktische Nutzen von Evals liegt im Vergleich gegen eine Baseline. Jeder Lauf wird nicht isoliert betrachtet, sondern gegen den letzten freigegebenen Stand gestellt. So werden Regressionen sichtbar: Fälle, die vorher bestanden haben und jetzt scheitern. Gerade Modellwechsel verbessern oft den Durchschnitt und verschlechtern gleichzeitig eine bestimmte Fallklasse. Ein aggregierter Wert verdeckt das, eine Auswertung pro Kategorie deckt es auf.

Dazu kommt die zweite Front: der laufende Betrieb. Auch ohne eigene Änderung kann sich das Verhalten verschieben, etwa durch neue Nutzungsmuster oder aktualisierte Wissensquellen. Wer regelmäßig Stichproben aus dem echten Verkehr zieht, bewertet und in den Katalog übernimmt, hält die Evals nah an der Realität und erkennt Drift, bevor sie zum Support-Thema wird.

Fazit

Evals sind kein Forschungsluxus, sondern die Voraussetzung dafür, ein AI-Feature verantwortbar zu betreiben und gezielt zu verbessern. Der Weg dorthin ist unspektakulär: einen Prüffall-Katalog aus echten Fällen aufbauen, Genauigkeit, Vollständigkeit und Format getrennt messen, die Läufe an jede Änderung koppeln und Ergebnisse gegen eine Baseline vergleichen. Wer das etabliert hat, ersetzt die Frage, ob sich das Feature gut anfühlt, durch die Frage, welche Fälle es besteht. Das ist der Unterschied zwischen Bauchgefühl und Messgröße.