Der Evals-Leitfaden
Wie Sie herausfinden, ob Ihr KI-Feature wirklich funktioniert, und ob eine Änderung es besser gemacht hat.
Die meisten Teams, die ein LLM-Feature ausliefern, erleben dasselbe in derselben Reihenfolge. Die Demo funktioniert. Der Launch läuft gut. Dann kommen Support-Tickets. Sie beschreiben Fehler, die niemand nachstellen kann. Jemand schlägt vor, „Evals einzuführen“. Das Team baut drei Wochen lang eine Plattform ein. Am Ende steht ein Dashboard voller Zahlen. Niemand traut ihnen, und niemand handelt danach.
Diese Abfolge lässt sich vermeiden. Und das hat fast nichts damit zu tun, welches Tool Sie wählen.
In diesem Leitfaden geht es um Ihre Anwendung: die Retrieval-Pipeline, die Sie gebaut haben. Den Agenten, den Sie in Betrieb genommen haben. Den Support-Bot, der Ihren Kunden antwortet. Es geht nicht darum, Foundation-Modelle in eine Rangfolge zu bringen. Diese Unterscheidung zieht sich durch jedes Kapitel. Denn beides zu vermischen ist der teuerste Fehler in diesem Feld.
Für wen das gedacht ist
Für Entwickler und Applied Scientists, die LLM-Features in Produktion bringen: RAG-Systeme, Agenten mit Tool-Zugriff, Copiloten, Klassifikatoren, Support-Automatisierung. Ihr System ist live, oder es geht bald live. Sie müssen wissen, ob eine Änderung es besser gemacht hat.
Wir setzen voraus, dass Sie Python lesen können. Und dass Sie in Precision und Recall denken können. Vorkenntnisse aus der Evaluationsliteratur setzen wir nicht voraus.
Die drei Ebenen, und um welche es hier geht
Fast jeder Streit über Evals löst sich auf, sobald man eines bemerkt: Die Beteiligten reden über verschiedene Ebenen.
| Ebene | Was sie misst | Wer sie durchführt | Beispiel |
|---|---|---|---|
| A. Modell-Evals | Die allgemeine Fähigkeit eines Modells | Labore, Benchmark-Autoren | MMLU, GPQA, SWE-bench, LMArena |
| B. System-Evals | Ob Ihre Anwendung ihre Aufgabe erfüllt | Sie | Ihre Traces, Ihr Gold-Set, Ihre Judges |
| C. Prozess-Evals | Ob die Eval-Schleife Ihres Teams funktioniert | Sie | Fehleranalyse, Annotation, CI, Monitoring |
Das Rückgrat dieses Leitfadens sind B und C. Ebene A kommt genau einmal vor: in Modell-Benchmarks richtig lesen. Dort steht sie als das, was sie wirklich ist: eine Fähigkeit, fremde Zahlen richtig zu deuten.
Diese Gewichtung hat einen empirischen Grund. Ein Modell schneidet bei MMLU gut ab. Das sagt fast nichts darüber, ob Ihre Retrieval-Pipeline den richtigen Paragraphen findet. Viel Arbeit geht verloren, weil Teams eine Rangliste lesen, statt sich die eigenen Daten anzusehen.
Was dieser Leitfaden nicht tut
- Modelle ranken. Diese Zahlen sind nach wenigen Wochen veraltet. Mehrere Seiten tun das ohnehin schon stündlich.
- Einen Anbieter empfehlen. Die Tooling-Landschaft beschreibt nur und bewertet nicht. Das ist selten genug, um es klar zu sagen: Fast jeder gut platzierte Vergleich der „besten Eval-Tools“ stammt von einem der verglichenen Anbieter.
- Prompt Engineering vermitteln. promptingguide.ai deckt das gut ab. Dieser Leitfaden wiederholt es nicht.
- So tun, als sei etwas geklärt, wenn es das nicht ist. Wo Fachleute ernsthaft uneins sind, stehen beide Positionen da. Sie sind als Umstritten markiert.
Die Form des Arguments
Wenn Sie sonst nichts lesen, lesen Sie diese vier Aussagen. Alles Weitere ist Detail.
1. Sehen Sie sich Ihre Daten an, bevor Sie irgendetwas messen. Fehleranalyse heißt: echte Traces lesen und echte Fehler einordnen. Sie bestimmt, welche Evals sich lohnen. Teams, die sie überspringen, bauen aufwendige Messungen für Probleme, die sie gar nicht haben. Hamel Husain und Shreya Shankar unterrichten den meistbelegten Praxiskurs zu LLM-Evals. Sie haben mehr als 2.000 Ingenieure und Produktverantwortliche aus über 500 Unternehmen ausgebildet. Für diesen Schritt veranschlagen sie 60–80 % der Entwicklungszeit.
2. Nehmen Sie den billigsten Grader, den die Aufgabe zulässt. Eine Schema-Prüfung ist deterministisch, sofort fertig und kostenlos. Und sie lässt sich ihre Meinung nicht ausreden. Ein LLM-Judge ist nichts davon. Code-basierte Evals kommen zuerst. Judges sind für das, was danach wirklich übrig bleibt.
3. Ein nicht validierter Judge ist ein Zufallszahlengenerator mit guten Manieren. Diesen Schritt überspringen viele: den Judge an menschlichen Labels messen, die er nie gesehen hat. Ohne ihn haben Sie nur eines automatisiert: die Produktion von Zahlen. Nicht die Produktion von Wissen. Einen ausgerichteten Judge bauen zeigt das Wie. Wo Judges versagen zeigt, warum das wichtig ist.
4. Ihr Eval-Wert ist eine Schätzung, und Schätzungen haben Fehlerbalken. Ein Eval-Set ist eine Stichprobe. Drei Punkte Verbesserung bei 100 Beispielen sind meistens Rauschen. Statistik für kleine Eval-Sets erklärt die Rechnung. Sie ist weniger einschüchternd, als ihr Fehlen in den meisten Praxistexten vermuten lässt.
Wie man das liest
Die Kapitel folgen der Reihenfolge, in der die Arbeit tatsächlich anfällt. Nicht dem Alphabet, nicht einer Taxonomie. Lesen Sie beim ersten Mal der Reihe nach. Wenn ein Begriff neu für Sie ist, hilft das Glossar. Es erklärt jeden Begriff in einer Zeile und nennt, womit er am häufigsten verwechselt wird.
Wenn Sie es eilig haben: Ihr erstes Eval in einer Woche ist ein Weg in fünf Tagen durch den Leitfaden. Am Ende läuft eine Regressionssuite in Ihrer CI. Der Weg lässt den größten Teil des Themas bewusst aus. Trotzdem ist es die ertragreichste Woche, die die meisten LLM-Teams haben.
Wer noch nie gesehen hat, was ein Eval als Dateien ist, beginnt mit Ein Eval in fünf Dateien: drei Fälle, drei Prüfungen, ein Runner, ein Befehl und seine Ausgabe, auf einer Bildschirmseite. Jedes spätere Kapitel baut auf diesen Dateien auf und ersetzt keine davon.
Zu den Quellen
Zahlen in diesem Leitfaden gibt es in drei Sorten. Es lohnt sich zu wissen, welche Sie gerade lesen. Belegte Befunde stehen in Kästen und tragen einen Link zur Quelle. Vorgerechnetes wird im Text hergeleitet, damit Sie es nachprüfen können. Dazu gehören die Konfidenzintervalle in Statistik und die pass^k-Rechnung in Agenten. Illustrative Zahlen in Beispielen sind erfunden. Sie machen eine Form greifbar und sind als erfunden gekennzeichnet. Wo die Belege dünn sind, sagt der Text das. Er rundet nicht zu Zuversicht auf. Das Literaturverzeichnis vermerkt, wie viel Gewicht jede Quelle tragen kann. Es enthält auch datierte Korrekturen, wo frühere Fassungen dieses Leitfadens eine Zahl falsch hatten.
Das ist eine bewusste Einschränkung. Sie hat mehrere Aussagen gestrichen, die besseren Text ergeben hätten. Evaluationsinhalte ohne Quellen verlangen von Ihnen, etwas auf Treu und Glauben zu nehmen. Genau das soll dieses Feld Ihnen abgewöhnen.
Häufiger Fehler: „Wir brauchen Evals“ als Tooling-Entscheidung zu behandeln. Es ist eine Prozessentscheidung mit einem kleinen Tooling-Anteil. Teams installieren oft eine Plattform, bevor sie einen einzigen Fehlermodus ihres Systems benennen können. Dann wundern sie sich, dass sich aus dem Dashboard nichts ableiten lässt.