Benchmark in der künstlichen Intelligenz: Was er misst und was ein Ergebnis aussagt

Definition eines Benchmarks in der künstlichen Intelligenz

Ein Benchmark in der künstlichen Intelligenz ist eine festgelegte Evaluation. Sie kombiniert eine oder mehrere Aufgaben, Daten, ein Ausführungsprotokoll und eine oder mehrere Metriken, um zu beschreiben, wie sich ein System unter diesen Bedingungen verhält. Mit „Benchmark“ ist manchmal auch das gesamte Evaluationspaket gemeint. In diesem Glossareintrag bezeichnet der Begriff das Evaluationsdesign – nicht nur die Daten oder die Zahl in einer Ergebnistabelle.

Diese praktische Definition ist wichtig, weil jedes Ergebnis nur eine bestimmte Aussagekraft hat. Es kann zum Beispiel angeben, welchen Anteil der Probleme einer Sammlung ein Modell mit einer bestimmten Ausführungsmethode gelöst hat. Daraus folgt jedoch nicht ohne weitere Tests, dass das System allgemein gut in Mathematik ist, allen Nutzern korrekte Antworten gibt oder innerhalb eines Produkts sicher und zuverlässig funktioniert.

Ein Benchmark ist nützlich, wenn die Leistung strukturiert beobachtet, Systeme unter gemeinsamen Bedingungen verglichen oder Stärken und Schwächen ermittelt werden sollen. Um ein Ergebnis einzuordnen, muss zunächst klar sein, welche Aufgabe es abbildet und welche Festlegungen das Protokoll enthält. Die Bezeichnung „Benchmark“ garantiert für sich genommen nicht, dass eine Evaluation repräsentativ, unparteiisch, reproduzierbar oder für eine bestimmte Entscheidung geeignet ist.

So funktioniert ein Benchmark: Aufgabe, Daten, Protokoll und Metrik

Die Aufgabe beschreibt, was das System tun soll: eine Frage beantworten, Informationen finden, Code ändern oder eine andere klar umrissene Tätigkeit ausführen. Die Daten enthalten die konkreten Fälle, anhand derer diese Aufgabe geprüft wird. Ein Benchmark kann auch Trainings- oder Entwicklungsbeispiele festlegen. Diese sind jedoch von den Fällen zu unterscheiden, die für die abschließende Evaluation zurückgehalten werden: Werden Letztere zum Anpassen des Systems verwendet, kann sich dadurch verändern, was der Test eigentlich misst.

Das Protokoll legt fest, wie die Evaluation ausgeführt wird. Es kann das Eingabe- und Antwortformat, verfügbare Werkzeuge, Anweisungen, Zeit- oder Rechenlimits, die Zahl der Versuche und die Bewertungsmethode bestimmen. Bei Systemen mit Werkzeugen gehören auch die Umgebung und das Harness zu den Bedingungen. Ein Harness ist der Code, der das Modell mit den Aufgaben verbindet, Aktionen ausführt und Ergebnisse erfasst. Ändern sich diese Bedingungen, kann sich auch das Ergebnis ändern, obwohl dasselbe Modell verwendet wird.

Die Metrik überführt die beobachteten Antworten in ein Maß. Manche Metriken zählen richtige Antworten, andere bewerten Eigenschaften wie Qualität oder Sicherheit. Ein aggregiertes Ergebnis kann viele Fälle zu einem einzelnen Wert zusammenfassen. Ein Durchschnitt verdeckt dabei möglicherweise Unterschiede zwischen Aufgabentypen oder einzelnen Beispielen. Deshalb sollte man, sofern verfügbar, auch aufgeschlüsselte Resultate, die Zahl der Fälle, die Variabilität und die Regeln für den Umgang mit uneindeutigen Antworten prüfen.

Schließlich beschreibt die Modellkonfiguration, welches System evaluiert wurde und wie es ausgeführt wurde: Version, Anweisungen, Werkzeuge und relevante Einstellungen. Eine Modellbezeichnung ohne diese Angaben reicht nicht aus, um den Test nachzuvollziehen. Eine klare methodische Beschreibung ermöglicht es, das Ergebnis einzuordnen und zu prüfen, ob eine andere Evaluation tatsächlich unter denselben Bedingungen durchgeführt wurde.

Drei Beispiele aus unterschiedlichen Bereichen

Die Beispiele betreffen Aufgaben mit unterschiedlichen Antwort- und Bewertungskriterien. Sie sind nicht austauschbar und decken für sich genommen nicht alle Fähigkeiten eines Systems ab. Auch eine bekannte Sammlung von Problemen oder Code-Issues wird durch ihre Bekanntheit nicht zu einem universellen Maß.

AIME 2024 gehört zum Bereich akademisches Wissen und mathematisches Problemlösen. Die Prüfung besteht aus mathematischen Aufgaben; die offiziellen Lösungen bieten eine Referenz, anhand derer sich Antworten überprüfen lassen. Wird ein System mit diesen Aufgaben evaluiert, hängt die Interpretation davon ab, welche Aufgaben einbezogen wurden, welche Anweisungen galten, ob Werkzeuge zugelassen waren und wie Antworten bewertet wurden. Das Ergebnis beschreibt das konkrete Protokoll und die verwendete Aufgabensammlung – nicht mathematische Kompetenz insgesamt.

BrowseComp wurde entwickelt, um Agenten zu bewerten, die im Web navigieren und schwer auffindbare Informationen suchen. Bei einer solchen Evaluation kommt es nicht nur auf die endgültige Antwort an: Auch die Bedingungen der Websuche, die verfügbaren Werkzeuge und die Überprüfung der gefundenen Informationen spielen eine Rolle. Ein gutes Ergebnis bei BrowseComp belegt nicht, dass das System beliebige Webinformationen mit beliebigen Quellen oder unter beliebigen Aktualisierungsbedingungen korrekt findet.

SWE-bench konzentriert sich auf reale Issues aus Software-Repositories: Das System soll Änderungen vorschlagen, die auf GitHub beschriebene Probleme beheben. SWE-bench Verified ist eine ausgewählte und überprüfte Version des Benchmarks. Die Projektdokumentation beschreibt eine Sammlung von 500 Fällen, die durch menschliche Annotation und Tests überprüft wurden. Sie weist außerdem darauf hin, dass Konfiguration der Umgebung, Datenkontamination und Abdeckung der Sammlung die möglichen Schlussfolgerungen begrenzen. Ein Ergebnis hängt somit vom verwendeten Datensatz und Harness ab und ist keine Garantie dafür, dass das System beliebigen Code im Produktivbetrieb warten kann.

Ein Ergebnis lesen und wissen, wann ein Vergleich sinnvoll ist

Bevor zwei Ergebnisse verglichen werden, sollte man bestätigen, dass sie dieselbe Aufgabe, Datenversion, Aufteilung, Metrik und Bewertungsregeln betreffen. Auch Modellkonfiguration, Anweisungen, Werkzeuge, Budget und Umgebung müssen berücksichtigt werden. Ein höherer Wert bedeutet nicht zwangsläufig eine bessere Leistung, wenn sich eines dieser Elemente geändert hat. Selbst bei ähnlichen Bedingungen können Unterschiede innerhalb der Ausführungsvariabilität liegen oder von einer kleinen Zahl von Fällen abhängen.

Der Nenner hilft dabei, die Aussagekraft eines Ergebnisses einzuschätzen: Eine Quote auf Grundlage weniger Beispiele ist etwas anderes als eine Quote auf Grundlage vieler Beispiele. Ebenso sollte bekannt sein, welche Fälle ausgeschlossen und wie unvollständige oder uneindeutige Antworten behandelt wurden. Wird nur ein aggregierter Wert berichtet, sollte man vor der Auswahl eines Systems nach Ergebnissen für einzelne Aufgaben oder Kategorien fragen.

Ein Vergleich ist am besten begründbar, wenn die Systeme mit einem gemeinsamen Protokoll ausgeführt werden und die Details dokumentiert sind, die das Ergebnis verändern können. BetterBench untersucht bei der Bewertung von Benchmarks unter anderem deren Zweck, Geltungsbereich, Dokumentation, Kontamination, Reproduzierbarkeit und Vergleichbarkeit. HELM wiederum stellt Modellbewertungen über mehrere Szenarien und Metriken hinweg dar und dokumentiert Evaluationsbedingungen. Diese Ansätze zeigen, warum eine Rangliste ohne methodischen Kontext nur eine unvollständige Grundlage bietet.

Benchmark, Dataset, Metrik, Leaderboard und eigene Evaluation

Ein Dataset ist eine Sammlung von Daten oder Beispielen. Es kann Teil eines Benchmarks sein, legt für sich genommen aber weder die Aufgabe noch das vollständige Protokoll oder die Bewertungsmethode fest. Dieselbe Sammlung kann für verschiedene Evaluationen verwendet werden. Der Name des Datensatzes allein verrät daher nicht, was genau gemessen wurde.

Eine Metrik ist eine Regel, nach der Ergebnisse zusammengefasst oder bewertet werden, beispielsweise eine auf bestimmte Weise definierte Trefferquote. Sie ist nicht der gesamte Benchmark: Verschiedene Metriken auf denselben Daten können unterschiedliche Fragen beantworten. Ein Leaderboard ist eine Tabelle oder ein Rankingsystem, das Ergebnisse von Teilnehmenden nach bestimmten Regeln darstellt. Es ist eine Form der Ergebnispräsentation, aber kein Beleg dafür, dass alle Einträge unter vergleichbaren Bedingungen entstanden sind.

Eine eigene Evaluation passt Fälle und Bedingungen an einen konkreten Bedarf an, etwa an die Anfragen, die ein Supportassistent einer Organisation erhält. Sie kann einem Benchmark ähneln, sollte aber genauso sorgfältig dokumentiert werden: Auswahlkriterien, Daten, Protokoll, Metriken und Grenzen. Ein Abnahmetest wiederum prüft vereinbarte Anforderungen an ein Produkt oder System in einem festgelegten Kontext. Er kann Teil einer Evaluation sein, ist aber nicht automatisch ein allgemeiner Benchmark.

Diese Unterscheidungen helfen, Abkürzungen in der Argumentation zu vermeiden: Eine Tabelle mit vielen Ergebnissen ist nicht automatisch eine vollständige Evaluation; ein populäres Dataset ist nicht zwangsläufig repräsentativ für die tatsächliche Nutzung; und ein bekannter Metrikname erklärt für sich genommen noch nicht, was als Erfolg gilt.

Grenzen: Kontamination, Overfitting und externe Validität

Kontamination liegt vor, wenn Informationen aus den Evaluationsfällen – oder sehr ähnliche Antworten – in den Daten enthalten sind, die zum Trainieren oder Anpassen eines Systems verwendet wurden. In diesem Fall kann eine richtige Antwort auf vorherige Vertrautheit mit dem Material zurückgehen und nicht nur auf die Fähigkeit, die eigentlich gemessen werden sollte. Kontamination lässt sich nicht immer einfach erkennen: Trainingsdaten sind möglicherweise nicht öffentlich, und eine Suche nach wörtlichen Übereinstimmungen erfasst nicht alle Formen der Überschneidung.

Overfitting auf einen Benchmark kann entstehen, wenn Entwickler wiederholt auf gute Ergebnisse bei einem bekannten Test hin optimieren. Diese Anpassung kann den Messwert verbessern, ohne die Leistung bei neuen Aufgaben im gleichen Maß zu steigern. Zurückgehaltene Evaluationssets, die Dokumentation von Änderungen und zusätzliche, andersartige Fälle können das Risiko verringern, aber nicht vollständig beseitigen.

Die externe Validität fragt, inwieweit ein Ergebnis Auskunft über Situationen außerhalb des Benchmarks gibt: über andere Nutzer, Fachgebiete, Sprachen, Werkzeuge, Softwareversionen oder Produktionsbedingungen. Eine kontrollierte Sammlung erleichtert Vergleiche, kann aber wichtige Anforderungen aus der Praxis auslassen – etwa Latenz, Kosten, Datenschutz, längere Interaktionen, Fehlerbehebung oder menschliche Aufsicht.

Auch die Ausführung kann variieren. Ein System kann bei wiederholten Versuchen unterschiedliche Antworten erzeugen; Umgebungen können ausfallen; und bei automatischen oder menschlichen Bewertenden wirken sich Regeln und unterschiedliche Urteile auf das Ergebnis aus. Deshalb sollte die Evaluationsmethode dokumentiert werden, ebenso Anweisungen und Umgebung und, wenn möglich, Beispiele für Eingaben und Ausgaben. Eine einzelne gerundete Zahl kann Unsicherheit, ungleiche Ergebnisse zwischen Untergruppen oder schwerwiegende Fehler in Einzelfällen verdecken.

Aggregierte Werte vereinfachen die Darstellung, verdichten aber zugleich Entscheidungen: Welche Aufgaben zählen, wie stark sie gewichtet werden und wie Fehler behandelt werden. Ein hoher Durchschnitt kann mit schwachen Ergebnissen in einer wichtigen Kategorie einhergehen. Für eine praktische Entscheidung sollte man daher die Verteilung der Ergebnisse und die folgenreichsten Fehler prüfen, nicht nur den Gesamtplatz.

Wann ein Benchmark nützlich ist – und wann nicht

Ein Benchmark eignet sich dazu, Systeme unter festgelegten Bedingungen zu vergleichen, Veränderungen zwischen Versionen zu verfolgen, Schwachstellen zu erkennen und für eine klar umrissene Aufgabe eine gemeinsame Referenz zu schaffen. Er kann auch helfen, Anschlussfragen zu formulieren: Bei welchen Falltypen häufen sich Fehler? Welche Ressourcen wurden benötigt? Wiederholt sich eine Verbesserung auch in mehr als einer Evaluation?

Als einziges Argument für den Einsatz eines Systems, als Vorhersage seiner Qualität in einem nicht abgebildeten Kontext oder als Beleg für eine allgemeine Fähigkeit reicht ein Benchmark nicht aus. Dafür sind ergänzende Evaluationen nötig: Tests mit passenden Daten und Nutzern, Fehleranalysen, Prüfungen von Sicherheit und Datenschutz sowie – je nach Zweck – operative Messungen wie Kosten oder Latenz.

Vor der Auswahl eines Benchmarks sollte feststehen, welche Entscheidung er unterstützen soll. Ist die Frage konkret – zum Beispiel, ob ein Assistent die Vorfälle eines Dienstes korrekt klassifiziert –, kann eine gut konzipierte und dokumentierte eigene Evaluation relevanter sein als ein öffentliches Ranking. Sie lässt sich mit etablierten Benchmarks kombinieren, sollte aber nicht mit ihnen verwechselt werden.

Verwandte Begriffe

Zur Vertiefung eignen sich die Glossareinträge zu Benchmark, Evaluation, Reproduzierbarkeit und Datenkontamination sowie das allgemeine Glossar. Diese Begriffe helfen dabei, genauer zu bestimmen, was gemessen wurde, ob andere die Prüfung wiederholen können und ob das Ergebnis durch vorherigen Kontakt mit den Fällen überhöht sein könnte.

Die praktische Schlussfolgerung ist einfach: Fragen Sie, welche Aufgabe mit welchen Daten, nach welchem Protokoll und anhand welcher Kriterien bearbeitet wurde. Sind diese Punkte unklar, bietet das Ergebnis keine ausreichende Grundlage, um Systeme zu vergleichen oder ihre Leistung in einer anderen Umgebung vorherzusagen.

Verwandte Begriffe