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.
Die Referenz aktualisiert sich auch selbst. Eine verifizierte Referenz ist weiterhin ein handkorrigierter Entwurf, und die Modelle, die Sie benchmarken, sind ihre Prüfer: Überall dort, wo der Judge die Antwort eines Kandidaten besser findet als die der Referenz (oder die der Referenz für falsch hält), wo die eigenen Stichproben des Szenarios die Referenz widerlegen und wo ein Modell einen Wert füllt, den die Referenz leer gelassen hat, und der Judge dies bestätigt, hält das Ergebnis einen Befund fest. Am Ende jedes Bewertungsdurchlaufs werden die Befunde aller bewerteten Modelle zusammengeführt — zuerst das, was die Stichproben belegen, dann die Antwort, die die meisten Modelle gegeben haben — und in die Referenz geschrieben. Eine Änderung, die ein Durchlauf bereits vorgenommen hat, wird nur durch stärkere Belege ersetzt (die Stichproben, ein Urteil, dass der Wert falsch ist, oder mehr übereinstimmende Modelle — über Durchläufe hinweg gezählt), niemals durch die Meinung eines weiteren Modells. So kann das Benchmarken einzelner Modelle nacheinander die Referenz nicht in Richtung des zuletzt bewerteten Modells verschieben. Diese automatischen Änderungen lassen Bewertungen nie veralten (das tun nur Ihre eigenen Speicherungen), und jede von ihnen wird protokolliert — mit dem ersetzten Wert und den Modellen, die sie ausgelöst haben.
Prüfen Sie sie wie nachverfolgte Änderungen: Die Ansicht Referenz des Szenarios zeigt neben dessen Ergebnissen die Referenz selbst, wobei jede automatische Änderung an Ort und Stelle hervorgehoben ist — der vorherige Wert durchgestrichen, der neue Wert, wie viele Modelle dahinterstehen und warum. Alles gilt als akzeptiert, sofern Sie es nicht ablehnen; eine Ablehnung stellt den vorherigen Wert wieder her und schließt diesen Pfad von künftigen Durchläufen aus. Filtern Sie nach Attribut oder Beleg (Änderungen aus nur einem Modell lohnen einen Blick), wählen Sie das Angezeigte aus und lehnen Sie es gesammelt ab.
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 per Ähnlichkeit nicht eindeutig entscheiden lassen – alle Freitextfelder wie Zusammenfassungen und Beschreibungen, jede nicht identische Zahl sowie ein deutlich abweichender Wert, den Ihre Dokumente oder die meisten anderen Modelle stützen –, werden an ein Judge-Modell geschickt. Das Judge-Modell urteilt blind: Es sieht die beiden Werte als A und B, dazu die Position des Feldes im Schema (seine übergeordneten Felder und deren Beschreibungen, seinen Typ, zu welchem Listeneintrag es gehört) sowie Ihre Quelldokumente, sofern das Szenario welche enthält, und gibt an, welcher Wert das Feld besser abbildet, ob beide korrekt sind oder ob einer falsch ist. Ein Kandidat, der als gleichwertig oder besser als die Referenz bewertet wird – oder eine Referenz, die als falsch bewertet wird –, erhält die volle Punktzahl; eine schwächere Antwort erhält Teilpunkte, eine falsche wenig bis gar keine. Eine Zahl erhält Teilpunkte, wenn das Feld dies zulässt (ein Molekulargewicht von 273,37 statt 273,35, eine Halbwertszeit von 12 statt 15), und fällt dort durch, wo Exaktheit zählt (ein Erscheinungsjahr 2020 statt 2023). Ein Wert, den die Referenz leer gelassen hat, wird für sich allein geprüft: Wird er als korrekt bestätigt, zählt er als Wert, den die Referenz hätte enthalten sollen und den das Modell gefunden hat – die Punktzahl steigt also, statt nur nicht bestraft zu werden – und die Referenz übernimmt ihn.
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 Geschichte. Wenn ein Benchmark in die Modellauswahl einfließt — als Bewertungsquelle —, ergibt sich die Platzierung 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 zusammen 100 und sind standardmäßig gleichmäßig verteilt. Gewichten Sie die Kosten stark, schlägt ein günstiges, brauchbares Modell ein exzellentes teures — für manche Workloads die richtige Antwort, für andere die falsche; deshalb entscheidet die Plattform das nicht für Sie. Geschwindigkeit und Kosten werden auf einer logarithmischen Skala an den übrigen Ergebnissen des Szenarios gemessen: Das schnellste bzw. günstigste Modell erreicht 100, ein zehnmal langsameres oder teureres 0. Ein eng beieinanderliegendes Feld wird jedoch nie über die gesamte Skala gestreckt — zwei Modelle mit 10 $ und 12 $ landen bei 100 und 92, nicht bei 100 und 0.
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 die Anreicherung beschränkt: Ein Szenario kann auch die Beispielgenerierung testen (jedes Modell erfindet ein Beispiel-JSON für dieselbe Freitext-Anfrage) oder die Schemagenerierung (jedes Modell wandelt ein festes Beispiel in ein Schema um). Jede 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.
Das Scoring ist ein eigener Durchlauf über bereits gespeicherte Ergebnisse — es reichert nie erneut an und zahlt daher nie erneut für die getesteten Modelle. Es erzeugt jedoch Embeddings, um Werte zu vergleichen (und führt den Judge aus, falls das Szenario einen hat), was nutzungsabhängig Credits abzieht. Das geschieht automatisch bei jedem Lauf — jedes Modell wird bewertet, sobald seine Läufe abgeschlossen sind — und erneut bei jeder Neubewertung. Wenn in Ihrer Organisation kein Embedding-Modell konfiguriert ist (und das Szenario keines überschreibt), läuft das Scoring trotzdem, greift aber nur auf den exakten Abgleich zurück (abweichende Schreibweisen gelten dann als Nichtübereinstimmung) und weist darauf hin. Ein defekter Judge ist etwas anderes: Schlägt ein Judge-Aufruf fehl, bricht das Scoring mit einem expliziten Fehler ab und für das betroffene Modell bleiben keine Teil-Scores erhalten — ein Ergebnis ist entweder vollständig bewertet oder gar nicht und kann später weiterhin neu bewertet werden. Judge-Antworten werden pro Szenario zwischengespeichert, und zwar anhand ihres Inhalts: Dieselbe Frage, die von einem anderen Modell, einer Wiederholung oder einem weiteren Durchlauf gestellt wird, wird nie doppelt bezahlt, und eine Neubewertung nach einer Selbstaktualisierung der Referenz stellt nur die Fragen zu den geänderten Feldern erneut. Nichts, was der Judge tut, bleibt verborgen: Jeder Bewertungsdurchlauf über ein Modell hinterlässt einen Bewertungsdatensatz im Verlauf – eine Zeile pro Judge-Aufruf mit Prompt, Antwort, Tokens und Kosten, fehlgeschlagene Aufrufe inbegriffen, dazu die Anzahl der Fragen, die der Cache kostenlos beantwortet hat – und die Ergebnistabelle zeigt für jedes Modell Judge-Kosten, Aufrufanzahl und Bewertungsdauer samt Link darauf. 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 im Szenario-Editor eine Referenz fest und prüfen Sie sie (und wählen Sie dort Judge-Modell, Embedding-Modell und Strenge). Ab dann bewertet jeder Lauf automatisch seine erfolgreichen Ergebnisse — eine sortierbare Spalte Qualität füllt sich ohne weiteres Zutun. Verwenden Sie Ergebnisse neu bewerten (Schaltfläche in der Kopfzeile oder das ···-Menü), um nach dem Bearbeiten der Referenz oder der Scoring-Konfiguration neu zu bewerten. Das Badge Referenzaktualisierungen neben dem Referenzstatus öffnet das Protokoll der Änderungen aus den Scoring-Durchläufen, mit einer Zurücksetzen-Option je Eintrag.