AI Evals

Aktualisiert 2026-04-08

Automatisierte Tests für KI-Systeme — kein Unit-Test für Code, sondern ein Testfall für das Verhalten eines Sprachmodells. Evals beantworten die Frage: “Hat das Modell das Richtige getan?” Für deterministische Software reicht es, den Output zu prüfen. Bei LLMs ist “korrekt” oft eine Frage des Urteils — und das muss man formalisieren, bevor man es messen kann.

Der Begriff stammt aus der ML-Forschung (dort: golden datasets mit Input/Output-Paaren für Klassifikatoren). Teresa Torres hat ihn für LLM-Produkte weiterentwickelt, nachdem sie beim Bau ihres Interview Coach-Tools in eine klassische Prompt-Engineering-Falle gelaufen ist: Ein Fehler beheben, zwei neue entstehen. Ohne Evals kein verlässlicher Feedback-Loop.

Drei Typen von Evals

Dataset-Evals (Golden Dataset)
Der ML-Klassiker: Inputs mit erwarteten Outputs in einer Tabelle. Man füttert alle Inputs durch das Modell und vergleicht mit den Soll-Outputs — das ergibt einen Score. Gut für einen ersten Überblick. Schwäche: Die Testfälle decken nur bekannte Szenarien ab, und bei LLMs ist “gewünschter Output” selten ein eindeutiger String.

Code-basierte Evals
Regelbasiert, schnell, reproduzierbar. Beispiel aus Teresa’s Interview Coach: Die Eval-Pipeline extrahiert alle Fragen aus der Coach-Antwort und prüft per String-Matching, ob eine davon die Wörter typically, usually, generally enthält. Wenn ja: Fehler. Keine KI nötig, kein Ermessen — einfach Code. Gut geeignet, wenn der Fehler einen klar definierten sprachlichen Fingerabdruck hat.

LLM-as-Judge
Ein zweites Sprachmodell bewertet den Output des ersten. Beispiel: Die Liste aller Fragen aus der Coach-Antwort wird einem Judge-LLM übergeben — ist eine davon eine Suggestivfrage (leading question)? Das lässt sich nicht per Regex erkennen, weil es semantisches Urteil erfordert. LLM-as-Judge klingt circular, funktioniert aber überraschend gut — vorausgesetzt, die Bewertungskriterien sind explizit formuliert und stabil. Das eigentliche Risiko heißt Criteria Drift.

Das konkrete Setup bei Teresa’s Interview Coach

Der Coach besteht aus 8 LLM-Aufrufen (orchestriert), die jeweils eine andere Dimension einer Customer-Interview-Führung bewerten (z.B. Szene setzen, Timeline aufbauen, Fragen-Qualität). Für jeden dieser 8 Calls hat Teresa:

  1. Echte Traces gesammelt (100 Interview-Transkripte durch den Coach laufen lassen)
  2. Die Traces manuell annotiert: Was war gut, was nicht?
  3. Wiederkehrende Fehlermuster identifiziert (Error Mode Analysis)
  4. Für jeden persistenten Fehler entweder einen Code-Eval oder einen LLM-as-Judge-Eval geschrieben

Das Ergebnis: Ein Eval-Set pro LLM-Call, das beim nächsten Prompt-Experiment automatisch prüft, ob sich die Fehlerrate verbessert oder verschlechtert hat.

Evals vs. Guardrails

Evals laufen nach der Antwort — sie messen, ob ein Fehler passiert ist. Guardrails laufen vor der Antwort an den Nutzer — sie verhindern, dass ein Fehler den Nutzer erreicht. Technisch sind Guardrails Evals, die in Production ausgeführt werden.

Nicht alle Evals eignen sich als Guardrails: Jeder zusätzliche LLM-Call kostet Latenz und Geld. Typischerweise laufen Evals auf einem Prozentsatz der Traces — nicht auf 100%.

Evals brauchen eigene Maintenance

Evals sind kein “einmal schreiben, fertig”-Artefakt. Drei Gründe:

  1. Neue Fehlermodi entstehen — mit mehr Nutzung kommen Edge Cases, die man nicht antizipiert hat.
  2. Criteria Drift — LLM-Judges können sich von der menschlichen Erwartung weg bewegen, ohne dass der Score es anzeigt.
  3. Modell-Updates — wenn das Modell sich ändert, können bestehende Prompt-Tricks nicht mehr greifen.

Teresa benutzt die Metapher eines Gartens: Man ist nie fertig. Die Frage ist, ob man einen Pflegeprozess hat.

Evals und Discovery sind dasselbe Problem

Evals sind nur so gut wie das Verständnis der Nutzer. Konkret:

  • Ein golden dataset repräsentiert nur, was man sich als Nutzungsszenarien vorstellen kann — nicht was Nutzer wirklich tun.
  • Menschliche Annotators können nur gut urteilen, wenn sie wissen, was ein Nutzer erwartet.
  • Synthetische Daten sind nur so realistisch wie die Dimensionen, aus denen man sie generiert — und die Dimensionen kommen aus Discovery.

Die Qualität von Evals ist also direkt abhängig von der Qualität des Kundenwissens. Das ist kein Zufall: Es ist dasselbe epistemische Problem wie bei Product Discovery.

Verbindungen

Quellen