Wer prüft die Prüfer? Semi-automatische Evaluation von Sprachmodellen im Betrieb

Warum klassische Tests hier nicht greifen

Drei Eigenschaften machen Sprachmodelle für herkömmliche Testverfahren unzugänglich.

Erstens erzeugt dieselbe Eingabe nicht zuverlässig dieselbe Ausgabe. Ein Soll-Ist-Vergleich auf Zeichenebene, wie ihn klassische Tests durchführen, schlägt damit schon bei einer korrekten Antwort fehl. Zweitens gibt es selten genau eine richtige Antwort, sondern viele akzeptable Formulierungen derselben Aussage. Drittens sind die eigentlich interessanten Eigenschaften keine Messwerte, sondern Urteile. Ob eine Antwort relevant, sachlich zutreffend, im passenden Ton und rechtlich unbedenklich ist, lässt sich nicht aus der Zeichenkette ablesen.

Der naheliegende Ausweg, alles von Menschen prüfen zu lassen, scheitert an der Menge. Bei fünfhundert Anfragen am Tag und drei Minuten Prüfzeit je Antwort wären das fünfundzwanzig Stunden tägliche Arbeit. Wie weit die Gegenrichtung trägt, also die vollständig automatische Bewertung, hängt vom Anwendungsfall ab. Wo sich Qualität an eindeutigen Kriterien festmachen lässt, etwa an einem Format, an einem Rechenergebnis oder an einer Angabe, die sich gegen den eigenen Datenbestand abgleichen lässt, genügt die Automatik durchaus für sich allein. Je stärker die Beurteilung dagegen von Fachwissen, Kontext oder Abwägung abhängt und je größer der Schaden einer falschen Antwort ausfällt, desto weniger sollte man ihr unbeaufsichtigt vertrauen. Menschliche Bewertung tritt dann nicht an die Stelle der Automatik, sondern wird zur prüfenden Instanz über ihr. Aus diesem Spannungsfeld entsteht der Mittelweg, um den es hier geht.

Drei Schichten, die aufeinander aufbauen

Sinnvoll organisierte Evaluation besteht aus drei Schichten, die in dieser Reihenfolge durchlaufen werden. Der Grundgedanke ist einfach. Jede Schicht kostet mehr als die vorhergehende, also wird so weit unten geprüft wie möglich.

Die erste Schicht umfasst deterministische Prüfungen, also alles, was sich eindeutig entscheiden lässt. Hat die Antwort das erwartete Format? Sind Pflichtangaben enthalten? Taucht eine verbotene Formulierung auf? Existiert die genannte Artikelnummer tatsächlich im System? Ist der erzeugte Programmcode lauffähig? Solche Prüfungen kosten praktisch nichts, laufen in Sekunden und fangen einen überraschend großen Teil der Fehler ab, bevor irgendein Modell befragt werden muss.

Die zweite Schicht ist die automatische Bewertung durch ein Sprachmodell, im Fachjargon LLM-as-a-Judge. Ein zweites Modell erhält die Anfrage, die Antwort und eine schriftliche Bewertungsanleitung und vergibt daraufhin eine Note samt Begründung. Damit lassen sich die Eigenschaften erfassen, die Urteilskraft verlangen, also Relevanz, sachliche Richtigkeit, Vollständigkeit oder Tonalität. Der Ansatz skaliert auf viele tausend Fälle und kostet Bruchteile eines Cents je Bewertung.

Für Betriebe mit schützenswerten Daten ist dabei ein Punkt wichtig, der oft untergeht. Der bewertende Prüfer muss kein Cloud-Dienst sein. Ein lokal betriebenes Modell kann diese Aufgabe ebenfalls übernehmen, wodurch weder Kundenanfragen noch die daraus erzeugten Antworten das Haus verlassen.

Die dritte Schicht ist der Mensch, allerdings nicht als Flächendeckung, sondern gezielt. Geprüft werden eine Zufallsstichprobe, alle Fälle mit schlechter Bewertung, alle Fälle, in denen sich der automatische Prüfer unsicher zeigt, und alle neu auftretenden Grenzfälle. Hinzu kommt eine Aufgabe, die sich grundsätzlich nicht automatisieren lässt, nämlich die Bewertungsanleitung überhaupt erst zu entwickeln.

Der Prüfer braucht selbst eine Eichung

An dieser Stelle wird es interessant, denn hier unterscheiden sich die Ratgeber von der Forschung.

Populär wurde die automatische Bewertung durch eine vielbeachtete Arbeit aus dem Jahr 2023. Sie zeigte, dass ein starkes Sprachmodell in über achtzig Prozent der Fälle zum selben Urteil kommt wie ein menschlicher Bewerter, und dass dies genau jener Übereinstimmung entspricht, die zwei Menschen untereinander erreichen [1]. Daraus wurde vielerorts der Schluss gezogen, die Maschine könne den Menschen ersetzen.

Dieser Schluss ist zu kurz gegriffen. Achtzig Prozent Übereinstimmung heißt eben auch, dass jede fünfte Bewertung abweicht. Für eine einzelne Antwort mag das verschmerzbar sein. Sobald man aber viele Bewertungen zu einer Qualitätskennzahl zusammenfasst, um daraus eine Entscheidung abzuleiten, mitteln sich diese Abweichungen nicht heraus. Sie verzerren das Ergebnis systematisch.

Aktuelle Arbeiten zeigen, dass die Richtung dieser Verzerrung sogar berechenbar ist [2]. Ist die tatsächliche Qualität des geprüften Systems niedrig, fällt die unbereinigte Auswertung zu gut aus. Ist sie hoch, fällt sie zu schlecht aus. Wo dieser Umschlagpunkt liegt, hängt von den Fehlerquoten des jeweiligen Prüfers ab, im Rechenbeispiel der Arbeit liegt er bei fünfundsiebzig Prozent. Anders gesagt, ein schwaches System sieht besser aus, als es ist, und ein gutes System schlechter. Wer auf dieser Grundlage zwischen zwei Varianten entscheidet, entscheidet unter Umständen falsch.

Die Lösung ist Standardhandwerk aus der Messtechnik und heißt Eichung. Man lässt Menschen eine überschaubare Stichprobe bewerten, vergleicht diese mit dem Urteil des automatischen Prüfers, bestimmt daraus dessen Fehlerquote und rechnet die Verzerrung anschließend aus dem Gesamtergebnis heraus. Statt einer nackten Zahl gibt man am Ende einen Wertebereich an, der die verbleibende Unsicherheit sichtbar macht. Die zugehörige Rechnung ist veröffentlicht und als freie Implementierung verfügbar [2], sie muss also niemand selbst herleiten.

Die praktisch wichtigste Erkenntnis daraus ist der benötigte Umfang. Rund einhundert von Menschen bewertete Beispiele je Urteilsklasse, also je hundert tatsächlich gute und tatsächlich schlechte Fälle und damit zweihundert insgesamt, genügen in der untersuchten Konstellation für einen Unsicherheitsbereich von weniger als zehn Prozentpunkten Breite [2]. Die Korrektur wirkt auch bei kleineren Stichproben, der angegebene Bereich fällt dann entsprechend breiter aus.

Für ein mittelständisches Unternehmen ist das eine gute Nachricht. Zweihundert Beispiele zu bewerten ist ein Nachmittag Arbeit für zwei Fachleute und kein Projekt.

Bekannte Fallstricke

Die Forschung hat mehrere Eigenheiten automatischer Prüfer dokumentiert, die sich in der Praxis unmittelbar auswirken und die zum Teil deutlich kontraintuitiv sind [3, 4].

• Reihenfolgeneffekt. Vergleicht ein Prüfer zwei Antworten miteinander, kann sich sein Urteil allein dadurch umkehren, dass man die beiden Antworten vertauscht. Das Gegenmittel ist einfach, nämlich jede Bewertung in beiden Reihenfolgen durchzuführen und nur das übereinstimmende Ergebnis zu werten.
• Längenvorliebe. Längere Antworten werden systematisch besser bewertet, auch wenn sie nachweislich keinen zusätzlichen Inhalt enthalten [1]. Wer das nicht ausgleicht, optimiert seine Anwendung unbemerkt in Richtung Geschwätzigkeit.
• Selbstbevorzugung. Ein Modell bewertet Texte höher, die seinem eigenen Stil nahekommen. Die Ursache liegt dabei offenbar in der Vertrautheit mit der Formulierung und nicht in der Urheberschaft [5]. Wie stark der Effekt ausfällt, ist in der Forschung umstritten und hängt vom Anwendungsfall ab. Die Betriebsregel daraus ist trotzdem eindeutig. Wer zwei Anbieter gegeneinander vergleicht, sollte keinen der beiden als Schiedsrichter einsetzen.

Hinzu kommt ein Befund, der weniger technisch als organisatorisch ist und der erklärt, warum sich der Mensch aus dem Verfahren nicht herausrationalisieren lässt. Eine Untersuchung aus dem Jahr 2024 beschreibt das Phänomen der Kriterienverschiebung [6]. Man braucht Bewertungskriterien, um Antworten zu beurteilen, aber man erkennt erst beim Beurteilen konkreter Antworten, welche Kriterien man eigentlich meint. Die Bewertungsanleitung entsteht also im Prozess und lässt sich nicht vorab am Schreibtisch formulieren. Sie ist ein lebendes Dokument, das mit jeder Prüfrunde schärfer wird.

Was das im Betrieb bedeutet

Aus diesen Bausteinen wird erst dann ein Betriebsprozess, wenn drei Dinge zusammenkommen.

Erstens braucht es einen festen Bestand an Prüffällen, in der Fachsprache ein goldener Datensatz. Er besteht aus echten Anfragen aus dem Tagesgeschäft, ergänzt um die wichtigsten Grenzfälle und um jeden Fehler, der in der Vergangenheit einmal aufgetreten ist. Dieser Bestand wächst mit jedem Vorfall und wird damit über die Zeit zum eigentlichen Qualitätsgedächtnis des Unternehmens.

Zweitens muss die Prüfung an Veränderungen gekoppelt sein, und zwar an alle. Dazu gehören nicht nur Änderungen am eigenen Programmcode, sondern auch Anpassungen der Anweisungen an das Modell und, besonders wichtig, Modellwechsel auf Seiten des Anbieters. Der eingangs geschilderte Fall wäre genau daran aufgefallen.

Drittens braucht es einen Rückkanal aus dem laufenden Betrieb. Auffällige Fälle aus der Produktion wandern in den goldenen Datensatz, und die Kennzahlen aus der Entwicklung werden zu Überwachungskennzahlen im Betrieb. Damit schließt sich der Kreis zwischen Entwicklung und Betrieb, der den Kern des MLOps-Gedankens ausmacht (MLOps steht für Machine Learning Operations und bezeichnet den geregelten Dauerbetrieb von KI-Systemen mit laufender Überwachung und wiederholbaren Abläufen, vergleichbar mit dem, was DevOps für die klassische Softwareentwicklung leistet).

Eigene Beispiele statt fremder Bestenlisten

Naheliegend wäre es, sich die Arbeit zu sparen und stattdessen auf öffentliche Ranglisten zu vertrauen. Diese beantworten jedoch eine andere Frage als die, die im Betrieb ansteht.

Ranglisten bewerten Modelle. Im Unternehmen läuft aber kein Modell, sondern ein System aus Modell, Anweisungen, angebundenen Datenquellen, vorgelagerten Prüfungen und einer Oberfläche. Der Anteil des Modells am Ergebnis ist dabei kleiner, als die Aufmerksamkeit für Modellnamen vermuten lässt. Zwei Betriebe mit demselben Modell können völlig unterschiedliche Qualität erreichen, weil sich ihre Anweisungen und Datenanbindungen unterscheiden. Eine Rangliste kann darüber nichts aussagen.

Hinzu kommt, dass Ranglisten allgemeine Fähigkeiten messen und nicht die konkrete Aufgabe. Ob ein Modell eine Reklamation nach den Regeln des eigenen Hauses bearbeitet, ob es die Fachsprache der Branche trifft und ob es weiß, wann es besser an einen Menschen übergibt, steht dort nicht. Diese Fragen lassen sich nur an eigenen Fällen beantworten.

Der dritte Punkt schließt an den Kerngedanken dieses Beitrags an. Eine Rangliste ist eine Momentaufnahme zu einem Stichtag. Das betriebliche Problem ist aber nicht der Stichtag, sondern die Veränderung danach. Genau dafür ist eine Rangliste nicht gebaut.

Die zweihundert Eichbeispiele aus dem vorigen Abschnitt sind deshalb kein Zusatzaufwand neben der eigentlichen Messung. Sie sind die Messung.

Fazit: In fünf Schritten anfangen

Der Einstieg ist kleiner, als der Umfang des Themas vermuten lässt. Fünf Schritte genügen für den Anfang.

1. Fünfzig echte Fälle aus dem Tagesgeschäft sammeln, jeweils mit der Antwort, die das System tatsächlich geliefert hat.
2. Diese Fälle von zwei Fachleuten unabhängig voneinander bewerten lassen und anschließend die Abweichungen durchsprechen. Aus dieser Diskussion entsteht die erste Fassung der Bewertungsanleitung.
3. Für alles, was sich eindeutig entscheiden lässt, deterministische Prüfungen einrichten.
4. Einen automatischen Prüfer auf dieselbe Anleitung ansetzen und ihn gegen die menschlichen Bewertungen eichen.
5. Den gesamten Durchlauf an jede Änderung koppeln und die Ergebnisse festhalten.

Die zentrale Botschaft lautet also: Über den Erfolg einer KI-Anwendung entscheidet nicht die anfängliche Modellwahl, sondern die Fähigkeit zu bemerken, wann sie schlechter wird. Eine vollständig automatische Bewertung liefert diese Fähigkeit nicht, weil der automatische Prüfer eigene systematische Fehler mitbringt. Eine vollständig manuelle Bewertung liefert sie ebenso wenig, weil sie im Tagesgeschäft nicht durchzuhalten ist. Erst die Verbindung aus beidem, bei der die Maschine misst und der Mensch das Messgerät eicht, macht aus Qualität etwas Überprüfbares.

In unseren Workshops und Veranstaltungen zeigen wir regelmäßig, wie der praktische Einstieg in solche Verfahren gelingen kann. Abonnieren Sie gerne unseren Newsletter, um über aktuelle Formate informiert zu bleiben!

Quellen und weiterführende Links

[1] Zheng, L. et al. (2023): Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena. NeurIPS 2023, Datasets and Benchmarks Track. arxiv.org/abs/2306.05685

[2] Lee, C., Zeng, T., Jeong, J., Sohn, J.-y., Lee, K. (2025): How to Correctly Report LLM-as-a-Judge Evaluations. ICML 2026. arxiv.org/abs/2511.21140 (freie Implementierung: github.com/UW-Madison-Lee-Lab/LLM-judge-reporting)

[3] Gu, J. et al. (2024): A Survey on LLM-as-a-Judge. arxiv.org/abs/2411.15594

[4] Li, H. et al. (2024): LLMs-as-Judges: A Comprehensive Survey on LLM-based Evaluation Methods. arxiv.org/abs/2412.05579

[5] Wataoka, K., Takahashi, T., Ri, R. (2024): Self-Preference Bias in LLM-as-a-Judge. arxiv.org/abs/2410.21819

[6] Shankar, S. et al. (2024): Who Validates the Validators? Aligning LLM-Assisted Evaluation of LLM Outputs with Human Preferences. UIST 2024. https://arxiv.org/abs/2404.12272
Hinweis: Dieser Beitrag wurde mit Unterstützung von KI erstellt.