Ein LLM Judge bewertet ausgewählte oder alle passenden Agenten-Runs nach festgelegten Kriterien. Score-Trends und Alerts machen Regressionen sichtbar.
29. März 2026(zuletzt aktualisiert: 8. September 2026)10 Min. LesezeitAutor: Connic Engineering
Beim automatisierten Agenten-Scoring bewertet ein LLM jeden Agenten-Run nach festgelegten Kriterien, statt dass jemand die Antworten manuell liest. Sobald KI-Agenten echten Traffic verarbeiten, führen fehlende Messwerte zu Änderungen nach Gefühl statt anhand von Daten.
Manuelle Reviews skalieren nicht auf Hunderte oder Tausende Runs pro Tag. Automatisierte Evaluation nutzt ein LLM, das Agenten-Runs nach festgelegten Kriterien bewertet, Qualitätstrends sichtbar macht und das Team bei Verschlechterungen alarmiert.
Dieses Muster heißt LLM as a Judge. Bei Connic heißen die Bewertungen Judges. Damit lässt sich die Qualität eines Agenten messen und im Zeitverlauf verfolgen.
Warum automatisierte Evaluation wichtig ist
KI-Agenten sind nicht deterministisch. Derselbe Input kann in verschiedenen Runs zu unterschiedlichen Outputs führen. Eine Prompt-Änderung kann einen Anwendungsfall verbessern und einen anderen verschlechtern. Ohne kontinuierliche Evaluation fallen Qualitätsprobleme erst auf, wenn Beschwerden eingehen.
Die Falle des Vibe Checks
„Es scheint gut zu funktionieren“ ist keine Qualitätsmetrik. Teams mit Stichproben übersehen systematische Fehler. Ein Agent kann 90 % der Queries perfekt beantworten und in einer Kategorie regelmäßig scheitern. Ohne Messung bleibt das unbemerkt.
Die stille Regression
Ein Team aktualisiert den System-Prompt, wechselt das KI-Modell oder ändert ein Tool. Der Agent antwortet weiterhin, aber die Qualität ist um 20 % gesunken. Ohne automatisiertes Scoring bleibt diese Regression wochenlang im Produktivbetrieb, bis jemand den Rückgang der Kundenzufriedenheit bemerkt.
Die ROI-Frage
Der CTO fragt: „Wie gut funktionieren die Agenten?“ Ohne Evaluationsdaten besteht die Antwort aus Anekdoten. Mit ihnen liefert ein Dashboard Trends der Judge-Scores, Scores pro Kriterium und Vergleiche zwischen Deployments.
Bewerte jeden Agenten-Run automatisch
LLM-as-Judge-Evaluation bewertet Ausgaben von Agenten nach festgelegten Kriterien. Ein separates Evaluationstool ist nicht erforderlich.
Das Prinzip ist einfach: Ein Sprachmodell bewertet den Output eines anderen. Ein Bewertungsschema definiert die konkreten Kriterien für den Anwendungsfall. Das Judge-LLM bewertet Agenten-Runs nach diesem Schema. Studien aus dem Jahr 2025 ergänzen frühere Ergebnisse zu LLM as a Judge um wichtige Nuancen. Huang et al. (2025) stellten fest, dass feinabgestimmte Judges innerhalb ihrer Domäne gut funktionieren können, aber bei Generalisierbarkeit, Fairness und Anpassungsfähigkeit nachlassen. Dagegen zeigten Thakur et al. (2025), dass hohe Übereinstimmung relevante Score-Unterschiede und Prompt-Sensitivität verbergen kann. Die praktische Antwort lautet Kalibrierung. Wir bieten Bewertungsschemata, Filter, Stichprobenraten, gespeichertes Reasoning, einen Score-Verlauf und Warnmeldungen, um diesen Evaluationszyklus kontinuierlich zu betreiben.
Der Judge erhält den vollständigen Ausführungskontext: Input, Output, Ausführungs-Traces, Token-Nutzung und Kontext-Metadaten. Er bewertet jedes Kriterium einzeln und liefert jeweils einen Score mit Begründung.
Einen Judge einrichten
Ein Judge hat vier Bestandteile: den bewerteten Agenten, das KI-Modell für das Scoring, die Bewertungskriterien und die Auslösekonfiguration.
1. Scoring-Kriterien definieren
Das ist der wichtigste Schritt. Vage Kriterien erzeugen inkonsistente Scores. Konkrete Kriterien führen zu nützlichen, verwertbaren Evaluationen.
Vage Kriterien
• „Qualität“ (max. 10)
• „Hilfreich“ (max. 10)
• „Gute Antwort“ (max. 10)
Konkrete Kriterien
• „Alle Rechnungspositionen extrahiert“ (max. 10)
• „Richtiges Tool für die Aufgabe verwendet“ (max. 5)
• „Antwort unter 200 Wörtern“ (max. 5)
Jedes Kriterium erhält einen Namen, eine Beschreibung dessen, was der Judge genau bewerten soll, und einen maximalen Score. Der Judge bewertet alle unabhängig voneinander. So wird sichtbar, welche Leistungsaspekte stark sind und welche verbessert werden müssen.
2. Einen Auslösemodus auswählen
Automatic
Evaluiert Ausführungen nach ihrem Abschluss. Eine Stichprobenrate zwischen 1 und 100 % bringt Abdeckung und Kosten ins Gleichgewicht; Filter begrenzen die Evaluation auf den relevanten Traffic.
Manual
Die Evaluation wird für bestimmte Runs ausdrücklich gestartet. Das eignet sich zum Testen einer neuen Judge-Konfiguration, zur erneuten Evaluation nach geänderten Kriterien oder zur Stichprobe verdächtiger Runs.
Tipp: erst kalibrieren, dann automatisieren
Im manuellen Modus lässt sich zunächst eine repräsentative Auswahl von Runs mit den Erwartungen des Teams vergleichen. Nach der Kalibrierung des Bewertungsrasters kann für kontinuierliches Monitoring in den automatischen Modus gewechselt werden.
3. Optional einen System-Prompt ergänzen
Der Judge benötigt Informationen zum Fachgebiet. Wenn ein Agent Erstattungsansprüche gegenüber einer Krankenversicherung bearbeitet, sollte beschrieben sein, wie eine korrekte Entscheidung aussieht. Schreibt ein Agent Marketingtexte, gehören Markenstil und Qualitätsanspruch in den Kontext.
Example Judge System Prompt
You are evaluating a customer support agent for an e-commerceplatform. A high-quality response should:- Directly address the customer's specific question- Reference the correct order, product, or policy- Provide actionable next steps (not generic advice)- Maintain a professional, empathetic tone- Avoid making promises the company cannot keepIf the agent used tools, verify it queried the correct databefore responding.
Auch der System-Prompt des bewerteten Agenten kann in den Kontext des Judges aufgenommen werden. Damit kennt er sowohl die vorgesehene Aufgabe als auch das tatsächliche Verhalten des Agenten.
Ein vollständiges Beispiel
Ein praktisches Beispiel: die Evaluation eines Agenten, der Daten aus Rechnungen extrahiert.
Judge für Rechnungsextraktion
KI-Modell
openai/gpt-5.4 (oder ein anderes KI-Modell mit starkem Reasoning)
max. 10Vollständigkeit der Daten– Hat der Agent alle Pflichtfelder extrahiert? (Anbieter, Datum, Positionen, Summe)
max. 10Genauigkeit– Sind die extrahierten Werte korrekt? Stimmen die Summen der Positionen?
max. 5Tool-Nutzung– Hat der Agent die richtigen Tools in der richtigen Reihenfolge verwendet?
max. 5Umgang mit Unsicherheit– Hat er unklare Felder markiert, statt zu raten?
Mit diesem Setup erhält jeder Run zur Rechnungsextraktion maximal 30 Punkte. Das Dashboard zeigt sofort, ob die Genauigkeit hoch ist, aber die Vollständigkeit sinkt, oder ob der Agent rät, statt Unsicherheiten zu markieren. Jeder Score enthält die Begründung des Judges.
Run Filter: Evaluation auf relevante Fälle konzentrieren
Nicht jeder Run braucht eine Evaluation. Filter wählen den gewünschten Traffic aus:
Status Filter
Ein Filter kann nur abgeschlossene Runs auswählen und Fehler überspringen. Umgekehrt lassen sich ausschließlich fehlgeschlagene Runs untersuchen, um ihre Ursache zu verstehen.
Kontext Filter
Eigene Kontextwerte aus der Middleware können den Filter steuern, etwa für produktiven Traffic, Premiumkunden oder bestimmte Anwendungsfallkategorien.
Damit lassen sich getrennte Judges für unterschiedliche Szenarien erstellen. Ein Support-Agent, der Fragen zur Abrechnung und Technik beantwortet, braucht möglicherweise zwei Judges mit eigenen Kriterien und Filtern statt einer vermischten Evaluation.
Warnungen bei Qualitätsverlust
Scores zeigen die Qualität. Warnungen machen das Team auf Probleme aufmerksam. Ein Score-Schwellenwert sorgt dafür, dass ein Unterschreiten eine Benachrichtigung auslöst.
Schwellenwert
Ein minimaler Score wird in Prozent festgelegt. Fällt der Durchschnitt darunter, sendet Connic eine Warnung.
Durchschnittsfenster
Der Durchschnitt umfasst die letzten 1, 10, 50 oder 100 Evaluationen. Kleine Fenster reagieren schneller, große gleichen Ausreißer aus.
Filter für niedrige Scores
Ein Filter zeigt nur Ausführungen unter einem konfigurierbaren Prozentsatz und macht die schlechtesten Ergebnisse für eine Untersuchung schnell sichtbar.
Was das Dashboard zeigt
Die Detailseite des Judges bietet eine umfassende Ansicht der Qualität im Zeitverlauf:
Judge-Details mit durchschnittlichem Score, Aufschlüsselung nach Kriterien, Kostenübersicht und Bewertungseinstellungen auf einen Blick.
Durchschnittlicher Score
Gesamtmetrik der Qualität mit Trendindikator. Farbcodiert: Grün ab 80 %, Bernsteingelb von 50–80 % und Rot unter 50 %.
Durchschnitt pro Kriterium
Die Aufschlüsselung zeigt exakt, welche Bereiche stark und welche schwach sind. Liegt die Genauigkeit bei 95 %, die Tool-Nutzung aber bei 60 %, ist der schwache Bereich klar.
Evaluationsdetails
Jede Evaluation enthält das vollständige Reasoning. Der Judge erklärt jeden Score, sodass sich seine Evaluationslogik prüfen und die Kriterien verfeinern lassen.
Kostenanalyse
Gesamtzahl der Tokens, durchschnittliche Tokens pro Evaluation und kumulierte Kosten des Judges. Diese Werte zeigen die genauen Kosten der Qualitätsüberwachung.
Praktische Muster
Diese Evaluationskonfigurationen eignen sich für den Produktivbetrieb:
Deployment Canary
Das Warnfenster umfasst die letzten 10 Ausführungen einer neu bereitgestellten Agentenversion. Fällt der durchschnittliche Score in diesen ersten 10 Ausführungen unter den konfigurierten Schwellenwert, sendet Connic sofort eine Warnung. Die betroffenen Traces liefern die Grundlage für ein Rollback, bevor weitere Nutzer betroffen sind.
Qualität pro Anwendungsfall verfolgen
Ein Agent deckt mehrere Anwendungsfälle ab. Ein eigener Judge mit Kontextfilter trennt die Qualität von Fragen zur Abrechnung von technischen Fragen. Jeder Judge erhält eigene Kriterien, Schwellenwerte und Warnungen.
KI-Modell-Vergleich
Vor einem Wechsel von GPT zu Claude oder Gemini können zwei Agentenvarianten mit unterschiedlichen KI-Modellen in einem A/B-Test verglichen werden. Der Test verteilt den Traffic auf beide Varianten; ihre Judge-Scores zeigen den Qualitätsunterschied. Die Entscheidung stützt sich damit auf Daten statt auf Annahmen.
Rückkopplung für Prompt Engineering
Nach einer Aktualisierung des System-Prompts lassen sich Evaluationen nach niedrigen Scores filtern. Das Reasoning des Judges für die schlechtesten Ausführungen zeigt konkrete Fehlermuster, anhand derer der Prompt verfeinert wird, bis sich die Durchschnittswerte der Kriterien stabilisieren.
Kosten berücksichtigen
Jede erfolgreich abgeschlossene Judge-Evaluation verbraucht eine zusätzliche Run-Einheit und führt einen LLM-Aufruf aus. Der Mengenrabatt des Run-Pakets gilt für die Judge-Run-Einheit, nicht für den Modellaufruf. So bleiben die Kosten im Rahmen:
•Stichprobenraten für Agenten mit hohem Volumen nutzen. Eine passende Rate deckt den Traffic sinnvoll ab, ohne jeden Run zu evaluieren.
•Effiziente Judge-KI-Modelle benchmarken. Ein günstigerer Judge kann Kosten senken; vor dem Wechsel sollte er mit demselben annotierten Datensatz validiert werden.
•Kriterien fokussiert halten. Fünf konkrete Kriterien sind besser als zwanzig vage. Weniger Kriterien bedeuten auch kürzere Prompts und weniger Tokens.
•Rauschen mit Filtern ausschließen. Testausführungen, internes Debugging und Traffic mit geringem Wert bleiben außerhalb der Evaluation.
Erste Schritte
Einen Judge zu einem bestehenden Agenten hinzuzufügen ist unkompliziert:
1.Im Projekt Judges öffnen und einen neuen Judge erstellen
2.Den zu evaluierenden Agenten und ein KI-Modell für den Judge auswählen
3.Drei bis fünf konkrete Bewertungskriterien mit eindeutigen Beschreibungen definieren
4.Im manuellen Modus mit einer Auswahl kürzlich geprüfter Ausführungen testen
5.Das Bewertungsraster verfeinern und anschließend zum automatischen Monitoring wechseln
6.Einen Score-Schwellenwert festlegen, damit Qualitätsverluste eine Warnung auslösen
Der schwierigste Teil sind gute Beschreibungen der Kriterien, die besondere Aufmerksamkeit verdienen. Alles andere ist Konfiguration.
Der vollständige Einrichtungsleitfaden steht in der Judges-Dokumentation. Für den Einstieg in Connic zeigt der Quickstart-Leitfaden das Deployment eines ersten Agenten und die anschließende Ergänzung um einen Judge zur Qualitätsmessung.
Häufig gestellte Fragen
Bei LLM as a Judge bewertet ein Sprachmodell den Output eines anderen KI-Modells nach festgelegten Kriterien. Connic Judges können ausgewählte oder alle passenden Agenten-Runs bewerten, Scores und Reasoning pro Kriterium speichern, Trends verfolgen und automatisch Alerts auslösen.
Die Genauigkeit hängt vom Judge-Modell, Bewertungsschema und Anwendungsfall ab. Bei der ACL 2025 veröffentlichte Studien zeigen, dass starke Ergebnisse innerhalb einer Domäne nicht unbedingt generalisieren und hohe Übereinstimmung Score-Unterschiede oder Prompt-Sensitivität verbergen kann. Im manuellen Modus von Connic lässt sich ein Judge mit repräsentativen, geprüften Runs kalibrieren, bevor die kontinuierliche Evaluation aktiviert wird.
Kriterien sollten konkret und messbar statt vage sein. Statt ‚Qualität‘ oder ‚Hilfreich‘ eignen sich beispielsweise ‚alle erforderlichen Rechnungsfelder extrahiert (Anbieter, Datum, Positionen, Summe)‘, ‚richtiges Tool für die Aufgabe verwendet‘ oder ‚Antwort unter 200 Wörtern‘. Drei bis fünf fokussierte Kriterien pro Judge sind ein guter Richtwert.
Bei Agenten mit geringem Volumen oder großer Auswirkung eignet sich die Evaluation jeder passenden Ausführung. Bei höherem Volumen lassen sich Abdeckung und Kosten mit Connics Stichprobenrate von 1 bis 100 % und Filtern ausbalancieren. Der ausgewertete Traffic sollte dabei repräsentativ für die relevanten Anwendungsfälle bleiben.
Ein Score-Schwellenwert und ein Durchschnittsfenster über die letzten 1, 10, 50 oder 100 Evaluationen legen die Warnung fest. Kleine Fenster reagieren schneller, größere gleichen Ausreißer aus. Unterschreitet der Durchschnitt den Schwellenwert, benachrichtigt Connic die konfigurierten Empfänger, damit sie die betroffenen Traces prüfen können.
Jede abgeschlossene Judge-Evaluation verbraucht eine Connic-Ausführungseinheit plus den KI-Modell-Aufruf. Ausführungseinheit und connic/*-Tokens verwenden Projektguthaben zu den veröffentlichten Preisen; BYOK-Inferenz wird vom gewählten Provider berechnet. Stichprobenraten, fokussierte Filter, effiziente KI-Modelle und präzise Kriterien begrenzen die Kosten.
