Die Bewertung macht aus einem Benchmark statt „das JSON per Augenmaß prüfen“ eine objektive Zahl. Das Ergebnis jedes Modells wird anhand einer Gold-Referenz — der erwarteten Ausgabe — benotet und ergibt Vollständigkeit, Korrektheit und einen Gesamtqualitätswert, nach dem Sie sortieren können.
Die Bewertung braucht etwas, wogegen sie bewerten kann. Jedes Szenario enthält eine Referenzausgabe: die korrekte Antwort für seine eine feste Entität. Erstellen Sie sie, indem Sie mit starken Modellen generieren (Websuche + ein Source-of-Truth-Dokument), ein bekanntermaßen gutes Ergebnis einfügen und es anschließend von Hand bearbeiten — und markieren Sie sie als verifiziert, sobald Sie ihr vertrauen. Eine verifizierte Referenz ist überhaupt erforderlich, um das Szenario zu benchmarken, sodass es immer etwas zum Benoten gibt. Wenn Sie die Referenz später bearbeiten — oder die Bewertungskonfiguration des Szenarios ändern — werden bestehende Bewertungen als veraltet markiert, bis Sie neu bewerten.
Das Kernproblem: zwei korrekte Antworten können unterschiedlich geschrieben sein. Ein Modell, das einen Schauspieler „R. Downey Jr.“ statt „Robert Downey Jr.“ nennt, liegt nicht falsch. Daher wird jedes Feld mit einer gestuften Leiter verglichen — zuerst am günstigsten und sichersten, und nur bei Bedarf eskalierend:
Identische Werte stimmen überein. Ebenso Werte, die sich nur in Groß-/Kleinschreibung, umgebendem Leerraum oder numerischer Genauigkeit unterscheiden ("Acme" = "ACME", 4.0 = 4). Kostenlos und vollständig deterministisch.
Bei Text werden Kandidat und Referenz eingebettet und über die Kosinus-Ähnlichkeit verglichen. Oberhalb des Schwellenwerts gelten sie als identisch – eine gültige alternative Schreibweise wie „R. Downey Jr.“ gegenüber „Robert Downey Jr.“ ist also ein Treffer und kein Fehler. Datumsangaben bilden die Ausnahme: Sie werden als Kalenderwerte verglichen, niemals über Ähnlichkeit, sodass ein knapp falsches Datum („1972-03-14“ gegenüber „1972-03-24“) eine klare Abweichung ist statt eines trügerisch hohen Kosinuswerts. Boolesche Werte sind ebenfalls exakt oder gar nicht.
Werte, die sich anhand der Ähnlichkeit nicht eindeutig bestimmen lassen – alle Freitextfelder wie Zusammenfassungen und Beschreibungen sowie jede nicht identische Zahl – werden an ein Bewertungsmodell (Judge) gesendet, das auf einer Skala von 0–100 bewertet, wie gut die Antwort die Bedeutung der Referenz erfasst. Es belohnt eine korrekte, anders oder knapper formulierte Antwort und vergibt einer Zahl Teilpunkte, wenn das Feld dies zulässt (ein Molekulargewicht von 273,37 vs. 273,35, eine Halbwertszeit von 12 vs. 15), während es sie dort weiterhin als falsch wertet, wo Genauigkeit zählt (ein Erscheinungsjahr von 2020 vs. 2023). Ohne Bewertungsmodell greift Freitext auf einen kontinuierlichen Ähnlichkeitswert zurück, und eine nicht identische Zahl ist schlicht eine Abweichung.
Die Einstellung Strenge steuert den Embedding-Schwellenwert: Je höher der Wert, desto ähnlicher müssen zwei unterschiedlich geschriebene Werte sein, um als gleich zu gelten. Die Strenge, das optionale Bewertungsmodell und das Embedding-Modell werden alle im Szenario festgelegt – nicht bei jeder Bewertung neu gewählt –, sodass jedes Modell identisch bewertet wird und die Ergebnisse vergleichbar bleiben.
Listen – die Besetzung eines Films, die Nebenwirkungen eines Medikaments – sind der Bereich, in dem sich Modelle am stärksten unterscheiden: Ein kleines Modell findet vielleicht 4 Schauspieler, wo ein starkes 15 findet. Die Reihenfolge spielt keine Rolle, und mehr korrekte Einträge zu finden sollte gewinnen. Deshalb werden Arrays als Menge bewertet, nicht Position für Position:
Erweitern Sie eine Ergebniszeile, um genau zu sehen, welche Einträge übereinstimmten, verfehlt wurden oder halluziniert waren.
Eine einzelne Zahl verbirgt zu viel, daher enthält jedes Ergebnis Teilbewertungen:
Die aufklappbare Zeile zeigt die Aufschlüsselung pro Feld: Kandidat vs. Referenz, welche Stufe der Leiter entschieden hat und – sofern relevant – die Ähnlichkeit.
Qualität ist nur ein Drittel der Wahrheit. Wenn ein Benchmark als Bewertungsquelle in die Modellauswahl einfließt, ergibt sich die Position eines Modells aus der Mischung von Qualität, Geschwindigkeit und Kosten – und dieses Verhältnis bestimmen Sie: Legen Sie es je Szenariotyp unter Einstellungen → Organisation → Standardwerte fest; die Werte ergeben jeweils in Summe 100 und sind standardmäßig gleichmäßig verteilt. Gewichten Sie die Kosten stark, schlägt ein günstiges, solides Modell ein exzellentes teures – für manche Workloads ist das die richtige Antwort, für andere die falsche. Deshalb trifft die Plattform diese Entscheidung nicht für Sie.
Wenn ein Szenario ein Modell mehr als einmal ausführt (Wiederholungen), wird jeder Durchlauf einzeln bewertet, und die Zeile zeigt die mittlere Qualität sowie eine Konsistenzspanne (niedrigster–höchster der Durchläufe) — so ist ein Modell, das im Durchschnitt richtig, aber unbeständig ist, leicht zu erkennen. Die angezeigte Ausgabe ist der nach Qualität mittlere Durchlauf.
Benchmarks sind nicht auf Enrichment beschränkt: Ein Szenario kann auch Sample generation (jedes Modell erfindet ein Beispiel-JSON für einen Entity-Typ) oder Schema generation (jedes Modell wandelt ein festes Sample in ein Schema um) testen. Jede Variante hat ihre eigenen Bewertungsregeln:
In beiden Fällen behalten die gewohnten Spalten ihre Bedeutung – fahren Sie mit der Maus über eine Spaltenüberschrift für die typspezifische Definition und erweitern Sie eine Zeile für die vollständige Aufschlüsselung.
Die Bewertung ist ein separater Durchlauf über bereits gespeicherte Ergebnisse – sie führt niemals eine erneute Anreicherung durch, sodass die getesteten Modelle nie erneut bezahlt werden. Sie bettet jedoch Text ein, um Werte zu vergleichen (und den Judge auszuführen, sofern das Szenario einen besitzt), was Credits basierend auf der Nutzung abzieht. Dies geschieht automatisch bei jedem Durchlauf – jedes Modell wird bewertet, sobald seine Durchläufe abgeschlossen sind – und erneut, wann immer Sie neu bewerten. Wenn Ihre Organisation kein Embedding-Modell konfiguriert hat (und das Szenario keine Überschreibung festlegt), läuft die Bewertung dennoch, greift aber nur auf exakten Abgleich zurück (alternative Schreibweisen zählen dann als Nichtübereinstimmungen) und weist darauf hin. Ein defekter Judge ist etwas anderes: Wenn ein Judge-Aufruf fehlschlägt, stoppt die Bewertung mit einem expliziten Fehler und das betroffene Modell behält keine Teilbewertungen – ein Ergebnis ist entweder vollständig bewertet oder gar nicht, und bleibt später neu bewertbar. Beachten Sie bei der Auswahl des Judges, dass LLM-Judges ihre eigene Modellfamilie bevorzugen können – bevorzugen Sie einen Judge von einem Provider, den Sie nicht benchmarken.
Legen Sie unter Modellverwaltung → Benchmarks eine Referenz im Szenario-Editor fest und überprüfen Sie sie (und wählen Sie dort das Judge-Modell, das Embedding-Modell und die Strenge). Von da an bewertet jeder Lauf automatisch seine erfolgreichen Ergebnisse – eine sortierbare Spalte Qualität füllt sich ohne zusätzlichen Schritt. Verwenden Sie Ergebnisse neu bewerten (die Schaltfläche in der Kopfzeile oder das Menü ···), um nach dem Bearbeiten der Referenz oder der Bewertungskonfiguration neu zu bewerten.