Zum Hauptinhalt springen

KI-Qualität bewerten (Evals)

Experte
What you'll learn
  • Baue das kleinste nützliche Eval — ein Golden Set aus 20–100 echten Eingaben mit klaren Pass-Kriterien
  • Wähle die richtige Metrik pro Aufgabe: deterministische Prüfungen, LLM-as-Judge oder menschliche Überprüfung
  • Führe Evals als Gate aus — vor/nach jeder Prompt-Änderung, jedem Modellwechsel und in CI
  • Bewerte jede Stufe (Retrieval, Tool-Call, finale Antwort), nicht nur die letzte, um Regressionen zu lokalisieren

Wenn du irgendetwas auslieferst, das auf KI basiert, sind Evals der Weg, mit dem du weißt, dass es funktioniert — und wie du weißt, dass eine Änderung es besser gemacht hat und nicht schlechter. Ohne sie fliegst du blind: Eine Prompt-Anpassung, die einen Fall verbessert, kann unbemerkt zehn andere kaputt machen. Evals verwandeln "gefühlsbasierte" Iteration in eine messbare Schleife.

Das Minimal-Eval​

Du brauchst kein Framework, um zu starten. Die gesamte Schleife hat vier Schritte:

Guided walkthrough1 of 4
  1. 20–100 echte Eingaben mit den korrekten oder akzeptablen Ausgaben (oder klaren Kriterien dafür, was als Pass zählt). Decke die einfachen Fälle, die kniffligen und die Randfälle ab, die dich bereits in der Produktion gebissen haben.

Metriken auswählen​

Nicht jede Frage verdient denselben Test. Passe die Metrik an die Aufgabe an:

AufgabentypMetrikKostenVertrauenswürdigkeit
Strukturierte Ausgabe (JSON, SQL)Schemavalidierung, exakte ÜbereinstimmungGratisHoch
CodegenerierungFühre die Tests aus, die er geschrieben hatGünstigHoch
Extraktion (Daten, Entitäten)String contains / RegexGratisHoch
KlassifikationAccuracy, Precision, RecallGratisHoch
Zusammenfassungen, Entwürfe, TonfallLLM-as-Judge mit einer RubrikMittelMittel — muss kalibriert werden
Hochriskante Texte, SicherheitMenschliche Überprüfung einer StichprobeTeuerAm höchsten

Drei Faustregeln:

  • Deterministische Prüfungen wo möglich. Wenn die Antwort "valides JSON, das zu diesem Schema passt" oder "der Code besteht diese Tests" ist, frag kein LLM — prüf es einfach.
  • LLM-as-Judge für unscharfe Qualität. Hilfsbereitschaft, Tonfall, Faktentreue-vs-Quelle. Günstig, schnell, aber mit Verzerrungen (Länge, Position, Selbstbevorzugung). Validiere den Judge an menschlichen Bewertungen auf einer Stichprobe, bevor du seinen Zahlen vertraust.
  • Menschen für die höchstriskante Stichprobe. Selbst 10 von Menschen bewertete Fälle pro Release schlagen 0.

Starter-Rubrik für LLM-as-Judge

You are grading assistant responses against a source document.

For each response, output a JSON object with these fields:
- grounded: true if every factual claim is supported by the source, else false
- complete: true if the response answers all parts of the question, else false
- concise: true if the response contains no filler or repetition, else false
- overall_score: 1-5 (1 = unusable, 5 = ship it)
- reasoning: one sentence explaining the score

Do not consider length. Do not consider whether the response comes first or second.

<source>{{SOURCE}}</source>
<question>{{QUESTION}}</question>
<response>{{RESPONSE}}</response>

Return only the JSON, no preamble.

Wann man sie ausführt​

  • Vor/nach jeder Prompt- oder Modelländerung. Keine Ausnahmen. Der ganze Sinn des Golden Sets besteht darin, die Änderung zu erwischen, die du für sicher gehalten hast.
  • Bei einer Modellmigration. Neue Modelle verschieben das Verhalten — manchmal unbemerkt. Führe Evals aus, bevor du die Modell-ID umlegst. Siehe Fehler & Migration.
  • In CI, für Produktivsysteme. Verwandle ein grünes Eval in ein Merge-Gate. Regressionen werden abgefangen, bevor die Nutzer sie sehen.
  • Nach jedem gemeldeten Bug. Füge den fehlgeschlagenen Fall zum Golden Set hinzu. Das Set wächst, wie es das System tut.

Bewerte jede Stufe, nicht nur die finale Antwort​

Bei RAG und Agenten verdeckt eine einzige "finale Antwort"-Bewertung, wo es kaputtgeht. Bewerte jede Stufe separat, damit Regressionen an einer Stelle landen:

StufeWas zu prüfen ist
RetrievalEnthielt das Top-k das Dokument mit der Antwort?
Tool-AuswahlHat der Agent das richtige Tool für diese Runde gewählt?
Tool-ArgumenteWaren die Argumente wohlgeformt und korrekt?
Finale AntwortEntspricht sie den Golden-Kriterien?

Wenn der Retrieval-Score fällt, aber der Score der finalen Antwort stabil bleibt, weißt du: Es ist eine Retrieval-Regression — kein Prompt-Problem. Genau diese Lokalisierung macht Evals nützlich fürs Debugging, nicht nur zum Punkten.

Häufige Fehler​

  • Mit demselben Modell bewerten, das die Antwort erzeugt hat. Selbstbevorzugungs-Bias bläht die Werte auf. Nimm ein anderes Modell — oder besser: eine andere Familie — als Judge.
  • Judge-Prompts, die die "richtige" Antwort verraten. Wenn der Judge die Gold-Antwort sieht, findet er Gründe, ihre Übereinstimmung zu belohnen. Bewerte nach Kriterien, nicht nach Ähnlichkeit.
  • Golden Sets, die am Tag eins eingefroren wurden. Das Set sollte jedes Mal wachsen, wenn dich die Produktion überrascht. Ein veraltetes Set misst die Vergangenheit.
  • Auf das Eval hin optimieren statt auf die Aufgabe. Wenn du Prompts gegen ein kleines Set tunst, bis jeder Fall besteht, hast du möglicherweise überangepasst. Halte ~20 % der Fälle als Validierungs-Slice zurück, den du während der Iteration niemals ansiehst.

Prüfe dich selbst

0/4
  1. Was ist das Minimal-Eval?
  2. Wann solltest du eine deterministische Prüfung einem LLM-as-Judge vorziehen?
  3. Warum bei einem RAG-Agenten jede Stufe separat bewerten?
  4. Was ist ein Warnzeichen, dass du auf dein Eval-Set überangepasst hast?
Key takeaways
  • 20–100 echte Eingaben + Pass-Kriterien + eine Variable auf einmal = eine funktionierende Eval-Schleife.
  • Deterministisch > LLM-Judge > Mensch — nimm die günstigste Metrik, die die Aufgabe erlaubt.
  • Bewerte jede Stufe einer Pipeline, nicht nur die finale Antwort.
  • Das Golden Set wächst mit jedem gemeldeten Bug. Ein veraltetes Set misst die Vergangenheit.

Weiter​