Auf dieser Seite
Eine Antwort zu einer retournierten Bestellung wirkt versandfertig: grammatisch sauber, freundlich und kurz. In diesem beispielhaften Fall gibt eine automatische Bewertung volle Punktzahl. Der Assistent schreibt aber auch, die Erstattung sei erfolgt, obwohl niemand das Zahlungssystem geprüft hat.
Der Fehler liegt nicht im Satz. Er liegt in einer schlechten Definition von gut.
In einer aufgezeichneten Demonstration zur Evaluation entwickelt ein Team Bewertungen für einen Agenten, der Softwaredokumentation schreibt. Interessant wird es, wenn die Person mit Aufgabenwissen Qualität beschreibt und ein Tool diese Beschreibung in Kriterien übersetzt. Später löst ein niedriger Wert die richtige Frage aus: Braucht der Agent eine Korrektur, oder liegt das Problem in der Bewertung?
Das Raster ist eine Theorie über die Aufgabe. Prüfe diese Theorie.
Beginne mit dem Ausschlussfehler
Teams beginnen oft mit leicht bewertbaren Eigenschaften: Klarheit, Ton, Struktur und Vollständigkeit. Sie sind nützlich. Meist reichen sie nicht.
Bei der beispielhaften Erstattungsantwort steht „Keine erfolgte Erstattung behaupten ohne Zahlungsbeleg“ über der Textqualität. Bei einem Daten-Sync ist „Die Rechnungs-E-Mail nicht mit der E-Mail der Kontoinhaberin verwechseln“ wichtiger als eine elegante Erklärung der Feldzuordnung.
Bitte die Fachperson um drei Arten von Fällen: eindeutig gut, eindeutig falsch und einen Fall, bei dem sachkundige Personen uneinig sein könnten. Bewahre die Quelldatensätze und den Grund jeder Bewertung auf. Hängt ein Fall von einer veränderlichen Regel ab, versioniere die Regel mit dem Label.
Der erste Durchgang darf klein sein. Unbestimmt darf er nicht sein.
- Fachlich verantwortliche Person
gute, schlechte und strittige Fälle
- Exakte Prüfungen Identität · Berechtigung · Zielzustand
Code prüft Tatsachen
- Semantisches Raster
nur urteilen lassen, wo Auslegung nötig ist
- Abweichungen prüfen
Labels und Kriterien korrigieren
| Prüfung | Bessere Zuständigkeit | Warum |
|---|---|---|
| Nötige Berechtigung liegt vor | Code und maßgebliche Datensätze | Die Tatsache ist exakt und folgenreich |
| Zielkennung passt zur Quellidentität | Code und Testdatensatz | Ein Modell sollte keine Kennung erraten |
| Antwort behandelt die Kundenfrage | Von Menschen geprüftes Raster, eventuell Modell-Judge | Bedeutung verlangt Auslegung |
| Ton passt zur Situation | Von Menschen geprüftes Raster, eventuell Modell-Judge | Mehrere Formen können passen |
Unser Leitfaden zur KI in bestehenden Abläufen trennt enge Modellaufgaben von festen Regeln und menschlicher Prüfung bei Risiko. Code sollte Originalwerte kopieren und Bedingungen prüfen, nachdem ein Modell eine Auswahl getroffen hat. Modellkonfidenz wird dadurch keine Berechtigung.
Ein Wert erbt die blinden Flecken des Rasters
Der Einwand ist berechtigt: „Ein Mensch kann nicht jeden Agentenlauf prüfen. Wir brauchen einen skalierbaren Judge.“ Ja. Entscheidend ist, was dieser Judge vervielfacht.
Belohnt das Raster eine glatte Antwort, prüft aber nie, ob die Bestellung wirklich erstattet wurde, skaliert die Automatisierung genau diese Lücke. Eine Zahl mit zwei Nachkommastellen sieht präzise aus. Sie kann trotzdem das Falsche messen.
Die Dokumentation von Google Cloud zur Judge-Evaluation beschreibt eine praktische Prüfung: Bereite Fälle mit menschlichen Bewertungen vor, lasse die modellbasierte Metrik laufen und vergleiche die Ergebnisse. Das bedeutet nicht, dass eine Person unfehlbar ist. Das Modell braucht aber einen äußeren Maßstab, bevor sein Wert Gewicht bekommt.
Untersuche Abweichungen, nicht nur die durchschnittliche Übereinstimmung. Wenn der Judge eine Antwort akzeptiert, die die Supportleitung abgelehnt hat, suche das fehlende Kriterium. Sind zwei Fachpersonen uneinig, behalte beide Bewertungen und finde die Regel, die sie unterschiedlich auslegen. Glätte den Streit nicht still durch einen Durchschnitt.
Die Auswahl der Fälle zählt genauso wie die Formulierung der Kriterien. Eine Sammlung einfacher Erfolge lässt den Judge verlässlich aussehen und überspringt die schwierigen Fälle. Nimm unvollständige Datensätze, widersprüchliche Anweisungen und Fälle auf, in denen die richtige Antwort „anhalten und nachfragen“ lautet. Halte Fälle getrennt, auf die die Verfasser:innen des Rasters nicht optimiert haben. So muss sich eine Verbesserung an unbekannten Beispielen bewähren. Ändert sich die Geschäftsregel, aktualisiere Labels und erwartete Ergebnisse. Ein eingefrorener Testsatz kann die Regeln von gestern belohnen.
Verbinde die Bewertung mit dem Ergebnis
Ein Raster für einen Sync-Agenten sollte bis zum Kundenergebnis reichen. Wurde der richtige Kontakt geändert? Wurde die Einwilligung beachtet? Lässt sich ein fehlgeschlagener Datensatz erneut verarbeiten, ohne eine folgenreiche Aktion zu wiederholen?
Der Brevo-Connector-Leitfaden erklärt, warum ein erfolgreicher API-Aufruf und ein fehlendes Attribut gleichzeitig möglich sind. Prüft die Evaluation nur den Aufruf, verfehlt sie das Ergebnis. Prüft sie nur den Zielzustand, kann sie einen verbotenen Weg übersehen, der zufällig zum richtigen Wert führte. Bei riskanten Wegen zählt beides.
Beginne mit einer engen Aufgabe und wenigen Fehlerarten. Lass die verantwortliche Fachperson die Fälle bewerten. Prüfe exakte Fakten mit Code und setze einen Modell-Judge nur ein, wo Sprache oder Urteil ihn erfordern. Führe dieselben Fälle nach Änderungen an Prompt, Modell oder Tool erneut aus. Halte fest, was spätere Fehler über das Raster verraten.
Die Kosten sind Fachzeit am Anfang. Der Gewinn ist, dass jeder spätere Wert eine Bedeutung hat, die jemand begründen kann.
Ein Dashboard zeigt einen Wert. Erst das Raster sagt, was gezählt wurde.
Häufig gestellte Fragen
Wer sollte die Bewertungskriterien eines KI-Agenten festlegen?
Die Personen, die Aufgabe und Folgen kennen, definieren akzeptable Ergebnisse und Ausschlussfehler. Entwickler:innen können daraus wiederholbare Prüfungen machen und testen, ob ein Modell-Judge mit menschlichen Bewertungen übereinstimmt.
Beweist ein hoher Judge-Wert, dass ein Agent funktioniert?
Nein. Der Wert misst die Übereinstimmung mit einem Raster bei den getesteten Fällen. Ein schwaches Raster, untypische Fälle oder ein schlecht kalibrierter Judge können schädliche Ergebnisse hoch bewerten.
Was sollte Code statt eines Modell-Judges prüfen?
Exakte Berechtigungen, Datensatzkennungen, erforderliche Tool-Aufrufe und den Zustand im Zielsystem prüfst du möglichst mit Code. Ein Modell-Judge hilft bei semantischen Eigenschaften, die feste Regeln nicht klären.