Benchmark
Wenn mehrere Systeme dieselbe Aufgabe lösen, stellt sich die Frage: Welches liefert das beste Ergebnis? Ein Benchmark beantwortet diese Frage, indem alle Kandidaten unter identischen Bedingungen getestet und nach festgelegten Kriterien bewertet werden.
Der Begriff stammt aus der Vermessungstechnik. Eine Benchmark war ursprünglich eine Markierung an einem festen Punkt, von der aus Höhen und Entfernungen gemessen wurden. Im übertragenen Sinn bedeutet Benchmarking: einen festen Referenzpunkt setzen und alle Messungen daran ausrichten. In der Informatik und insbesondere in der KI-Forschung hat sich dieses Prinzip als zentrale Methode zur Leistungsbewertung etabliert.
Das Grundprinzip eines Benchmarks
Ein Benchmark besteht aus drei Komponenten: einem Datensatz, einer Aufgabe und einer Metrik. Der Datensatz enthält die Testfälle. Die Aufgabe definiert, was das System mit den Testfällen tun soll. Die Metrik legt fest, wie das Ergebnis gemessen wird.
Beispiel: Ein Embedding-Benchmark enthält 10.000 Textpaare. Die Aufgabe lautet: Finde zu jeder Suchanfrage das inhaltlich passendste Dokument. Die Metrik misst, wie oft das korrekte Dokument in den ersten zehn Ergebnissen auftaucht.
Beispiel: Ein Sprachmodell-Benchmark legt dem Modell 500 Multiple-Choice-Fragen zu Biologie, Physik und Geschichte vor. Die Aufgabe: die richtige Antwort auswählen. Die Metrik zählt den Anteil korrekter Antworten (Accuracy).
Die Trennung dieser drei Komponenten ist entscheidend. Ohne standardisierten Datensatz fehlt die Vergleichsbasis. Ohne definierte Aufgabe fehlt die Interpretierbarkeit. Ohne Metrik fehlt die Messbarkeit.
Metriken: Was ein Benchmark tatsächlich misst
Die Wahl der Metrik bestimmt, welche Eigenschaft eines Systems sichtbar wird. Verschiedene Metriken betonen verschiedene Aspekte der Leistung.
Beispiel: Accuracy misst den Anteil korrekter Antworten an der Gesamtzahl der Fragen. Bei einem Test mit 200 Fragen und 170 richtigen Antworten ergibt das eine Accuracy von 85 Prozent. Diese Metrik eignet sich für Aufgaben mit genau einer richtigen Antwort pro Frage.
Beispiel: Precision misst, wie viele der zurückgegebenen Ergebnisse tatsächlich relevant sind. Wenn ein Retrieval-System zehn Dokumente liefert und sieben davon relevant sind, beträgt die Precision 70 Prozent. Ein hoher Wert bedeutet wenige falsche Treffer.
Beispiel: Recall misst, wie viele der tatsächlich relevanten Dokumente gefunden wurden. Wenn die Datenbank 20 relevante Dokumente enthält und das System 14 davon findet, liegt der Recall bei 70 Prozent. Ein hoher Wert bedeutet wenige verpasste Treffer.
Beispiel: Cosine Similarity misst die Ähnlichkeit zweier Vektoren anhand ihres Winkels. Ein Wert von 1.0 bedeutet identische Richtung, 0.0 bedeutet kein Zusammenhang. Diese Metrik kommt bei Embedding-Benchmarks zum Einsatz, um zu prüfen, ob semantisch ähnliche Texte auch ähnliche Vektoren erhalten.
Weitere verbreitete Metriken sind F1-Score (harmonisches Mittel aus Precision und Recall), NDCG (bewertet, ob relevante Ergebnisse weiter oben in der Liste stehen) und Mean Reciprocal Rank (misst die Position des ersten relevanten Treffers).
Fachliche Einordnung: Die Wahl der Metrik ist nicht neutral. Ein System kann bei Precision hervorragend abschneiden und bei Recall schlecht. Benchmark-Ergebnisse sind nur im Kontext der verwendeten Metrik interpretierbar. Ranglisten, die eine einzelne Gesamtpunktzahl zeigen, aggregieren oft über verschiedene Metriken hinweg, was wesentliche Unterschiede verdecken kann.
Öffentliche Benchmarks und Ranglisten
Öffentliche Benchmarks stellen standardisierte Testdatensätze bereit, gegen die jeder sein Modell testen kann. Die Ergebnisse werden in Ranglisten (Leaderboards) veröffentlicht, sodass ein direkter Vergleich möglich ist.
Beispiel: MTEB (Massive Text Embedding Benchmark) testet Embedding-Modelle auf Dutzenden von Aufgaben in verschiedenen Sprachen. Die Aufgaben umfassen Klassifikation, Clustering, Retrieval und semantische Ähnlichkeit. Die Ergebnisse sind auf Hugging Face als Leaderboard einsehbar.
Beispiel: MMLU (Massive Multitask Language Understanding) testet Sprachmodelle auf 57 Wissensgebieten von Mathematik bis Jura. Das Testformat sind Multiple-Choice-Fragen. MMLU wird häufig herangezogen, um die allgemeine Leistungsfähigkeit großer Sprachmodelle zu vergleichen.
Weitere bekannte Benchmarks sind HumanEval (Programmieraufgaben), HellaSwag (Satzergänzung als Common-Sense-Test) und TriviaQA (Faktenwissen).
Grenzen öffentlicher Benchmarks
Öffentliche Benchmarks haben systematische Einschränkungen, die bei der Interpretation der Ergebnisse zu beachten sind.
Beispiel: Contamination bedeutet, dass Testdaten in den Trainingsdaten eines Modells enthalten waren. Das Modell hat die Antworten im Training gesehen und gibt sie aus dem Gedächtnis wieder, statt die Aufgabe zu lösen. Die gemessene Leistung liegt dann über der tatsächlichen Fähigkeit. Dieses Problem betrifft insbesondere Benchmarks, deren Datensätze öffentlich zugänglich sind.
Beispiel: Goodharts Gesetz besagt: Wenn eine Kennzahl zum Ziel wird, hört sie auf, eine gute Kennzahl zu sein. In der Praxis optimieren Modellhersteller gezielt auf Benchmark-Aufgaben, um in Ranglisten besser abzuschneiden. Das verbessert den Benchmark-Score, nicht aber zwingend die Leistung in realen Anwendungen.
Weitere Probleme sind die Veraltung von Datensätzen (Modelle werden auf neueren Daten trainiert, als der Benchmark enthält), sprachliche Verzerrung (viele Benchmarks testen primär Englisch) und die fehlende Abdeckung von Domänenwissen (ein Modell kann auf allgemeinen Benchmarks gut abschneiden und auf Fachtexten versagen).
Fachliche Einordnung: Contamination lässt sich nicht vollständig verhindern, solange Trainingsdaten aus dem offenen Internet stammen. Einige Benchmark-Anbieter rotieren deshalb regelmäßig ihre Testdatensätze oder halten sie unter Verschluss. Die Aussagekraft eines Benchmark-Ergebnisses hängt direkt davon ab, wie gut diese Trennung eingehalten wurde.
Eigene Benchmarks erstellen
Ein eigener Benchmark testet Modelle auf Daten, die für den konkreten Anwendungsfall relevant sind. Im Gegensatz zu öffentlichen Benchmarks bildet er die tatsächlichen Anforderungen ab.
Beispiel: Ein Unternehmen betreibt eine interne Wissensdatenbank mit 50.000 technischen Dokumenten. Die Suchanfragen der Mitarbeitenden werden als Testfälle gesammelt. Ein Fachexperte markiert für jede Anfrage die relevanten Dokumente. Drei Embedding-Modelle werden auf diesen Testfällen verglichen. Das Modell mit dem höchsten Recall auf diesen Domänendaten wird ausgewählt, auch wenn es auf MTEB schlechter abschneidet als die Konkurrenz.
Die Erstellung eines eigenen Benchmarks erfordert drei Schritte: Testfälle zusammenstellen, Referenzantworten (Ground Truth) definieren und eine Metrik auswählen. Der aufwendigste Schritt ist die Definition der Referenzantworten, weil dafür menschliche Fachexpertise nötig ist.
Beispiel: Für einen RAG-Benchmark werden 100 Fragen formuliert, die sich aus dem eigenen Dokumentenbestand beantworten lassen. Zu jeder Frage wird die korrekte Antwort und das Quelldokument festgehalten. Das RAG-System wird mit diesen Fragen getestet. Gemessen wird, ob das System das richtige Quelldokument findet (Retrieval-Qualität) und ob die generierte Antwort korrekt ist (Generierungsqualität).
Ergebnisse interpretieren
Benchmark-Ergebnisse sind Zahlen. Die Interpretation dieser Zahlen erfordert Kontext.
Beispiel: Modell A erreicht auf einem Retrieval-Benchmark einen Recall@10 von 92 Prozent, Modell B erreicht 88 Prozent. Die Differenz von 4 Prozentpunkten klingt gering. Bei 100.000 Suchanfragen pro Tag bedeutet das jedoch 4.000 zusätzliche Anfragen, bei denen das relevante Dokument in den Top-10-Ergebnissen fehlt. Ob diese Differenz relevant ist, hängt von der Anwendung ab.
Bei der Interpretation sind mehrere Faktoren zu berücksichtigen: die Datensatzgröße (kleine Testdatensätze erzeugen instabile Ergebnisse), die Varianz (mehrfaches Testen kann unterschiedliche Werte liefern), die Latenz (ein schnelleres Modell kann trotz leicht niedrigerer Qualität die bessere Wahl sein) und die Kosten (ein kommerzielles Modell mit Precision von 95 Prozent kann unwirtschaftlich sein, wenn ein Open-Source-Modell mit 93 Prozent ausreicht).
Beispiel: In einem Embedding-Benchmark verarbeitet Modell A 500 Dokumente pro Sekunde bei einer Cosine-Similarity-Korrelation von 0.87. Modell B verarbeitet 2.000 Dokumente pro Sekunde bei 0.84. Für eine Echtzeit-Suchanwendung mit hohem Durchsatz kann Modell B die bessere Wahl sein, obwohl Modell A den höheren Qualitätswert erreicht.
Benchmarking in der Praxis
In der Praxis kombinieren die meisten Anwender öffentliche und eigene Benchmarks. Öffentliche Ranglisten dienen als Vorauswahl: Modelle, die dort schlecht abschneiden, werden nicht weiter evaluiert. Die Spitzengruppe der öffentlichen Rangliste wird dann auf eigenen Daten getestet.
Beispiel: Ein Team evaluiert Embedding-Modelle für eine deutschsprachige Fachsuchmaschine. Aus dem MTEB-Leaderboard werden die zehn besten Modelle für die Aufgabe "Retrieval" auf Deutsch ausgewählt. Diese zehn Modelle werden auf 500 hauseigenen Suchanfragen getestet. Das Ergebnis weicht vom MTEB-Ranking ab: Das auf MTEB drittplatzierte Modell liefert auf den Fachdaten die besten Ergebnisse, weil es auf ähnlichen Domänentexten trainiert wurde.
Neben der einmaligen Modellauswahl werden Benchmarks auch fortlaufend eingesetzt. Wenn ein bestehendes System durch Fine-Tuning oder ein Modellupdate verändert wird, zeigt ein Benchmark, ob sich die Leistung verbessert, verschlechtert oder gleich geblieben ist. Dieser Vorgang heißt Regression Testing.
Grenzen und Einordnung
Benchmarks messen, was messbar ist. Nicht alles, was für die Qualität eines Systems relevant ist, lässt sich in einer Zahl ausdrücken.
Beispiel: Ein Sprachmodell kann auf einem Fakten-Benchmark hohe Accuracy erreichen und dennoch bei offenen Fragen unbrauchbare Antworten liefern, weil der Benchmark keine offenen Fragen enthält. Die Auswahl der Testfälle bestimmt, welche Fähigkeiten sichtbar werden und welche verborgen bleiben.
Subjektive Qualität, Nutzerzufriedenheit, Robustheit gegenüber ungewöhnlichen Eingaben und ethische Aspekte wie Bias werden von den meisten Benchmarks nicht oder nur am Rand erfasst. Ein gutes Benchmark-Ergebnis ist eine notwendige Bedingung für ein leistungsfähiges System, aber keine hinreichende.
Fachliche Einordnung: Die KI-Forschung arbeitet aktiv an der Erweiterung von Benchmarks um schwer messbare Dimensionen wie Fairness, Robustheit und Erklärbarkeit. Standards wie BigBench, HELM oder das Holistic Evaluation Framework versuchen, ein breiteres Bild der Modellleistung zu zeichnen. Dennoch bleibt eine Lücke zwischen dem, was ein Benchmark misst, und dem, was in einer realen Anwendung zählt.