Die drei Ebenen der Evaluation

Zwei Entwickler können eine Stunde lang über Evaluation streiten und sind sich dabei in nichts uneinig. Der eine meint: „Schlägt GPT-5 Claude beim Schlussfolgern?“ Der andere meint: „Hört unser Support-Bot auf, sich Erstattungsrichtlinien auszudenken?“ Beide nennen das Evals. Fast jede verworrene Diskussion in diesem Feld geht auf diese Verwechslung zurück.

Die Lösung: Man gibt den Ebenen Namen.

Die drei Ebenen

Ebene A: Modell-Evals. Sie messen, was ein Modell allgemein kann, unabhängig von jedem Produkt. Beispiele: MMLU, GPQA, SWE-bench, ARC-AGI, LMArena. Labore und Benchmark-Autoren führen sie durch. Die Ergebnisse erscheinen als Ranglisten (Leaderboards), und alle lesen sie.

Ebene B: System-Evals. Sie messen, ob Ihre Anwendung ihre Aufgabe erfüllt. Ihre Traces, Ihr Gold-Set, Ihre Judges, Ihre Definition einer guten Antwort. Niemand sonst kann diese Evals durchführen. Denn niemand sonst hat Ihre Daten oder Ihre Definition von „richtig“.

Ebene C: Prozess-Evals. Sie messen, ob die Evaluationsschleife Ihres Teams überhaupt funktioniert. Lesen noch Menschen Traces? Stimmt der Judge noch mit ihnen überein? Bildet das Eval-Set noch den echten Verkehr ab? Ebene C ist die Ebene, die still verfällt.

Befund: Die Aufteilung ist nicht unsere Erfindung. Nur die Bezeichnungen A/B/C sind es. Towards More Standardized AI Evaluation: From Models to Agents (2026) beschreibt denselben Bruch als zwei Epochen. Die erste ist modellzentriert und baut auf „static benchmarks, aggregate scores, and one-off success criteria“. Die zweite ist agentenzentriert. In ihr wird Evaluation zu „a core control function“ für nichtdeterministische Systeme. Der Vorwurf an die gängige Praxis ist deutlich: „high benchmark scores routinely mislead teams“. Evaluation werde als „performance theater“ betrieben, nicht als Messdisziplin.

Die Bezeichnungen Ebene A / B / C sind die Kurzform dieses Leitfadens und kein Standardvokabular. Die Unterscheidung dahinter treffen viele. Die Namen stammen von uns.

Quelle: Towards More Standardized AI Evaluation, 2026

Warum die Unterscheidung teuer ist, wenn man sie übersieht

Ein Wert auf Ebene A ist eine grobe erste Schätzung für die Leistung auf Ebene B. Und eine schwache. Ein Modell kann eine Coding-Rangliste anführen und trotzdem die falsche Wahl für Ihr Produkt sein. Vielleicht liegt Ihr Engpass bei der Suche, bei der Latenz oder bei einem Tool-Schema, mit dem das Modell schlecht umgeht. Der Zusammenhang ist real. Aber er ist viel lockerer, als Beschaffungsentscheidungen üblicherweise annehmen.

Der umgekehrte Fehler ist schlimmer und häufiger: Teams nehmen eine Rangliste als Ersatz für den Blick in die eigenen Daten. Ein Modell auszuwählen ist eine Entscheidung. Sie treffen sie an einem Nachmittag. Zu wissen, ob Ihr System funktioniert, ist eine Disziplin. Sie halten sie über die gesamte Lebensdauer des Produkts durch. Das sind zwei verschiedene Tätigkeiten. Die erste kann die zweite nicht ersetzen.

Häufiger Fehler: Die Frage „Wie gut ist unser KI-Feature?“ mit einem Modell-Benchmark beantworten. Die ehrliche Antwort braucht Daten aus Ebene B. Vielleicht haben Sie die noch gar nicht erhoben. Das offen zu sagen ist besser, als eine Zahl einzusetzen, die etwas anderes bedeutet.

Vokabular, das sich tatsächlich durchgesetzt hat

Die folgenden Begriffe werden in der Fachliteratur einheitlich genug verwendet. Sie können sie gefahrlos benutzen. Begriffe ohne feste Bedeutung sind dort markiert, wo sie auftauchen. Das Glossar führt sie alle auf, jeweils mit der Verwechslung, die der Begriff nahelegt.

Offline vs. online. Offline läuft gegen einen festen Datensatz, vor dem Livegang. Online bewertet echten Verkehr, nach dem Livegang. Beides ist Ebene B. Die beiden beantworten verschiedene Fragen und widersprechen sich regelmäßig. Offline: die 200 gespeicherten Support-Tickets, die Sie bei jedem Release erneut durchlaufen lassen. Online: die Gespräche, die gestern tatsächlich stattgefunden haben. Siehe Online- und Produktions-Evaluation.

Komponente vs. Ende-zu-Ende. Komponenten-Evals bewerten eine einzelne Stufe: die Suche, den Klassifikator, den Formatierer für Tool-Aufrufe. Ende-zu-Ende-Evals bewerten die Ausgabe des Gesamtsystems. Komponente: Hat der Suchschritt den richtigen Hilfeartikel gefunden? Ende-zu-Ende: War die Antwort gut, die der Nutzer bekam? Das eine kann bestehen, während das andere durchfällt. Etwa eine perfekte Suche, deren Ergebnis das Modell dann ignoriert. Oder eine gute Antwort, obwohl die Suche das falsche Dokument geliefert hat. Komponenten-Evals grenzen einen Fehler ein. Ende-zu-Ende-Evals sagen Ihnen, ob er eine Rolle spielte. Sie brauchen beides. Bei der RAG-Evaluation tut das am meisten weh.

Code-bewertet vs. LLM-bewertet vs. menschlich bewertet. Sortiert nach Kosten und nach Vertrauenswürdigkeit. Beides steigt von links nach rechts. Code-bewertet, wo die Aufgabe es zulässt. LLM-Judges für den Rest. Menschen prüfen die Judges.

Punktweise vs. paarweise. Punktweise bewertet eine Ausgabe für sich allein. Paarweise wählt die bessere von zwei Ausgaben. Punktweise: „Ist diese Zusammenfassung akzeptabel, ja oder nein?“ Paarweise: „Hier sind zwei Zusammenfassungen. Welche ist besser?“ Menschen sind bei der zweiten Frage viel konsistenter als bei der ersten. Judges auch. Deshalb ist paarweise bei subjektiven Qualitäten verlässlicher. Punktweise brauchen Sie aber immer dann, wenn Sie einen absoluten Schwellwert benötigen. Das gilt für jedes CI-Gate. „Besser als die andere“ sagt Ihnen nicht, ob eine von beiden gut genug zum Ausliefern ist.

Referenzbasiert vs. referenzfrei. Referenzbasiert vergleicht die Ausgabe mit einer Gold-Antwort. Referenzfrei bewertet die Ausgabe aus sich heraus. Referenzbasiert: Sie haben die korrekte Erstattungsrichtlinie vorab aufgeschrieben und prüfen die Antwort dagegen. Referenzfrei: Sie fragen einen Judge „Nennt diese Antwort eine echte Richtlinie?“, ohne selbst eine geschrieben zu haben. Die meisten Anwendungs-Evals starten referenzfrei, weil Gold-Antworten teuer sind. Später kommen Referenzen für die Teilmenge dazu, auf die es am meisten ankommt.

Trajektorie vs. Endergebnis. Das gilt nur für Agenten. Das Endergebnis kann richtig sein, obwohl der Weg dorthin falsch, teuer oder unsicher war. Der Agent hat dem Kunden das richtige Lieferdatum genannt. Vorher hat er zweimal das Erstattungs-Werkzeug aufgerufen und die Bestellung eines anderen Kunden gelesen. Die Antwort besteht. Die Trajektorie darf nicht bestehen. Siehe Agenten-Evaluation.

Produktmetriken vs. Proxy-Metriken. Eine Produktmetrik ist etwas, das das Unternehmen ohnehin interessiert: Lösungsquote, Eskalationsrate, Zeit bis zur ersten korrekten Antwort. Eine Proxy-Metrik haben Sie selbst erfunden. Sie hoffen, dass sie der Produktmetrik folgt. Evals sind Proxys. Ihr Wert hängt ganz davon ab, wie gut sie der Produktmetrik folgen. Diese Beziehung sollte man prüfen, nicht unterstellen.

Wo dieser Leitfaden steht

Die Kapitel 2 bis 14 und 16 behandeln Ebene B und C. Kapitel 15 ist das einzige Kapitel zu Ebene A. Es erklärt, wie man diese Zahlen liest, nicht wie man sie erzeugt.

Diese Gewichtung ist Absicht. Ebene A ist gut abgedeckt und gut finanziert. Leute, deren Vollzeitjob das ist, aktualisieren sie stündlich. Auf Ebene B und C verlieren Teams tatsächlich Monate. Und diese Ebenen decken vor allem Hersteller-Dokumentationen ab. Die haben ein Interesse daran, dass die Antwort „Kaufen Sie unsere Plattform“ lautet.