Wer einen Chatbot, einen RAG-Assistenten oder einen KI-Agenten in Produktion bringt, steht vor einer unbequemen Frage: Wie gut antwortet das System eigentlich? Ein menschliches Review-Team skaliert nicht. Klassische Metriken greifen bei freien Texten zu kurz. Die Antwort der Branche: LLM-as-a-Judge – ein Sprachmodell bewertet die Ausgaben eines anderen Sprachmodells.

Das klingt erst einmal paradox. Wenn ein LLM fehleranfällig ist, warum sollte ausgerechnet ein LLM der richtige Prüfer sein? Die Antwort ist pragmatisch: Weil die Alternativen entweder nicht skalieren (Menschen) oder an der Aufgabe vorbeigehen. Jahrelang waren BLEU und ROUGE die Standard-Metriken für Textqualität – BLEU zählt, wie viele Wortfolgen einer KI-Antwort wortwörtlich in einer Referenzantwort vorkommen; ROUGE misst dasselbe für Zusammenfassungen. Das funktioniert bei Übersetzungen halbwegs, scheitert aber sobald eine Frage mehrere richtige Antworten zulässt. Zwei inhaltlich identische Antworten mit unterschiedlicher Wortwahl bekommen einen schlechten Score. Für heutige KI-Assistenten ist das unbrauchbar.

Ein gut instruiertes Judge-Modell dagegen kann die Relevanz einer Antwort, die Grundlage in einem Kontextdokument oder die Einhaltung von Stilrichtlinien in Sekunden bewerten – und das für tausende Anfragen pro Tag. Seit MLflow 3 ist dieser Ansatz fester Bestandteil einer offenen Evaluierungsplattform mit vorgefertigten Judges für die drei wichtigsten Anwendungsfälle: Antwortqualität, RAG-Pipelines und Tool-Nutzung in Agenten.

Was ein LLM-Judge eigentlich prüft

Die vorgefertigten Judges in MLflow adressieren die typischen Schwachstellen produktiver KI-Systeme. Bei der Antwortqualität prüft der Judge RelevanceToQuery, ob die Antwort überhaupt zur Frage passt – ein häufiges Problem bei Modellen, die gerne ausweichend oder zu breit antworten. Correctness vergleicht die Antwort gegen hinterlegte Fakten, Safety filtert toxische Inhalte heraus, Fluency prüft Grammatik und Sprachfluss.

Bei RAG-Systemen – also Retrieval-Augmented-Generation-Anwendungen, die auf Unternehmensdokumente zugreifen – wird es interessanter. Hier gibt es drei dedizierte Judges: RetrievalRelevance prüft, ob die abgerufenen Dokumente zur Nutzerfrage passen. RetrievalGroundedness kontrolliert, ob die Antwort tatsächlich in den Dokumenten steht und nicht halluziniert wurde. RetrievalSufficiency bewertet, ob die Dokumente überhaupt genug Information enthielten. Für regulierte Branchen – Banken, Versicherungen, Gesundheit – ist vor allem die Groundedness-Prüfung entscheidend: Sie ist der technische Mechanismus, mit dem man Halluzinationen systematisch eindämmt.

Wie das in der Praxis aussieht

In MLflow reicht eine einzige Funktion, um Judges auf einen Testdatensatz anzuwenden. Man definiert Eingaben, erwartete Fakten und optional einen Trace – also die Aufzeichnung dessen, was das System intern getan hat, inklusive abgerufener Dokumente und Tool-Aufrufe. Dann übergibt man eine Liste von Judges an die mlflow.genai.evaluate()-Funktion. Das Ergebnis: ein strukturiertes Scoring pro Antwort, nachvollziehbar und reproduzierbar.

Besonders nützlich für Agenten sind die Tool-Call-Judges: ToolCallCorrectness prüft, ob das Modell die richtigen Werkzeuge mit den richtigen Argumenten aufgerufen hat. ToolCallEfficiency bewertet, ob unnötige oder redundante Aufrufe stattgefunden haben – ein echter Kostenfaktor, wenn jeder Tool-Call API-Gebühren und Latenz verursacht.

Wo die Grenzen liegen

So praktisch das Konzept ist – blindes Vertrauen wäre naiv. Ein Judge ist selbst ein Sprachmodell und hat eigene Biases. Er kann höfliche Antworten besser bewerten als harte, er kann lange Antworten für gründlicher halten, er kann dieselben Halluzinationen übersehen, die er eigentlich finden soll. Genau deshalb sieht MLflow vor, Judges mit menschlichem Feedback zu kalibrieren – ein Workflow, der in der Dokumentation als Alignment bezeichnet wird.

Für Unternehmen heißt das: Ein Judge-System ist keine Einmal-Konfiguration, sondern ein eigener Evaluierungs-Prozess. Man startet mit den Built-in-Judges, ergänzt domänenspezifische Custom-Judges für das Geschäftsmodell (zum Beispiel: Hält die Antwort Compliance-Vorgaben ein? Stimmt die fachliche Terminologie?), misst die Übereinstimmung mit menschlichen Bewertungen und justiert nach. Das ist kein Hexenwerk, aber es ist Arbeit – und die wird in vielen KI-Projekten heute noch unterschätzt.

Was das für Unternehmen bedeutet

Wer eine KI-Anwendung produktiv einsetzt, braucht zwei Dinge: Observability – also Traces und Logs, die zeigen, was das Modell getan hat – und eine Evaluierungs-Pipeline, die Qualität kontinuierlich misst. MLflow bringt beides unter einen Hut, offen und ohne Vendor-Lock-in. Das senkt die Einstiegshürde für strukturierte KI-Evaluation erheblich.

In meinen Projekten sehe ich immer wieder denselben Fehler – besonders deutlich im Kontext von Microsoft Copilot und ähnlichen Enterprise-Rollouts: Teams aktivieren den Copilot-Tenant, rollen ihn über hunderte Nutzer aus und beginnen dann, mit Bauchgefühl zu diskutieren, ob die Antworten auf internen SharePoint-Dokumenten „gut genug" sind. Es gibt keine Baseline, keine Testdatensätze, keine Groundedness-Prüfung. Fachbereiche melden zurück „manchmal halluziniert er halt" – und niemand kann systematisch sagen, ob das in 2 % oder 20 % der Fälle passiert.

Ein LLM-Judge-Setup drei Wochen früher einzuziehen, verändert diese Diskussion grundlegend. Man hat Zahlen, man hat Regressions-Tests für Prompts, man kann Änderungen verantworten. Genau das ist die Arbeit, die ich in Projekten begleite – von der Frage, welche Judges relevant sind, bis zur Integration in die bestehende ML- oder Microsoft-Plattform.