LLM-Benchmarks richtig lesen: Was Modellwerte aussagen

LLM-Benchmarks helfen dabei, die nächsten sinnvollen Tests auszuwählen. SWE-bench Verified misst die Leistung bei 500 ausgewählten Softwareproblemen. Ein hoher Wert verrät allerdings nicht, ob ein Agent die eigenen Erstattungsrichtlinien einhalten kann. Bevor das Spitzenergebnis zählt, müssen Aufgabe, Testaufbau und Bewertungsmaßstab klar sein.

Am 15. Oktober 2026 mit den Seiten der Benchmark-Autoren und Googles Modellkarte abgeglichen. Die folgenden Benchmark-Beschreibungen erläutern die jeweiligen Tests; die Werte im Praxisbeispiel stammen aus Googles veröffentlichten Ergebnissen. Die Einordnung und die Checkliste für eigene Evaluationen stammen von uns.

Bei einem Programmierassistenten sind Aufgaben im Repository oder Terminal der richtige Ausgangspunkt. Bei einem Kundenservice-Agenten zählen der Werkzeugeinsatz im Gespräch und die Einhaltung von Richtlinien. Ein Dokumentenassistent muss Informationen aus langen Kontexten verknüpfen können. Ein allgemeiner Wissenstest kann solche Entscheidungen ergänzen, aber nicht ersetzen.

Was messen LLM-Benchmarks?

Ein Benchmark misst die Leistung bei bestimmten Aufgaben unter festgelegten Regeln. Er ähnelt eher einer Sportdisziplin als einem Intelligenzzertifikat: Eine Sprintzeit ist eine nützliche Information, sagt aber wenig darüber aus, wer eine Bergrettung übernehmen sollte.

Der Datensatz enthält die Fragen oder Aufgaben. Das Evaluationsprotokoll legt fest, welche Eingaben das Modell erhält, welche Hilfsmittel es nutzen darf und wie das Ergebnis bewertet wird. Als Harness, auch Scaffold genannt, bezeichnet man die Software rund um das Modell: Prompts, Tools und Ausführungsschleife.

Diese Unterscheidung ist wichtig, wenn ein Anbieter bei einer Modellvorstellung Programmierfähigkeiten verspricht. Eine Funktion aus einem kurzen Prompt zu erzeugen ist eine andere Aufgabe, als ein Repository zu durchsuchen, Dateien zu ändern, Tests auszuführen und nach einem Fehler weiterzuarbeiten. Das Ergebnis im zweiten Fall gehört zu einem vollständigen System einschließlich seines Harness.

Die SWE-bench-Rangliste macht das sichtbar: Sie unterscheidet verschiedene Evaluationsbedingungen, darunter eine gemeinsame mini-SWE-agent-Umgebung. Das eingesetzte Programmierprodukt kann andere Tools, Anweisungen oder Grenzen haben. Bevor sich ein Wert auf den eigenen Arbeitsablauf übertragen lässt, muss deshalb klar sein, welche Software das Modell beim Test umgab.

Welche Benchmarks tauchen bei Modellvorstellungen auf?

Zuerst muss der Benchmark zur Aufgabe passen; erst dann lohnt sich der Vergleich von Ergebnissen. Die folgenden Benchmark-Familien begegnen einem 2026 bei der Vorstellung allgemeiner Modelle, Programmiermodelle und Sprachsysteme. Hinzu kommen Kontexttests, die bei der Einordnung der Aussagen helfen. Jeder Benchmark-Name verlinkt auf die Seite oder das Repository seiner Autoren.

Die Version gehört immer zum Namen. HLE-Diamond enthält 1,000 überarbeitete Fragen, die endgültige Fassung des ursprünglichen HLE dagegen 2,500. Terminal-Bench 4.0 hat Ressourcen und Aufgaben geändert. Das aktuelle tau-Repository dokumentiert sowohl neue Modalitäten als auch Korrekturen der Bewertung. Ein neuerer Wert neben einem älteren kann daher für eine veränderte Prüfung stehen, nicht für ein besseres Modell.

Welche Ergebnisse sind für den eigenen Einsatz relevant?

Entscheidend ist die Benchmark-Familie, die den zu vermeidenden Fehlern am nächsten kommt. Wer als Gründer eine KI-Funktion auswählt, als CTO einen Agenten freigibt oder im Betrieb Supportanfragen bearbeitet, sollte die Zeilen einer Ergebnistabelle unterschiedlich gewichten.

Benchmarks für Programmieragenten

Bei der Pflege eines bestehenden Produkts sind Repository-Reparaturen und Terminalaufgaben der richtige Einstieg. SWE-bench liefert nützliche Hinweise zur Lösung von Softwareproblemen, Terminal-Bench zur Arbeit in einer Shell. LiveCodeBench und HumanEval beantworten enger gefasste Programmierfragen. Keiner dieser Tests misst allein, ob eine Änderung in der eigenen Codebasis gut wartbar ist.

Ein Beispiel: Ein Solo-Entwickler beauftragt einen Agenten, die Kontolöschung zu ändern. Eine korrekte Hilfsfunktion ist dabei nur ein Teil der Arbeit. Der Agent muss sämtliche betroffenen Aufrufstellen finden, Berechtigungen wahren, Tests aktualisieren und widersprüchliche Kundendatensätze vermeiden. Die eigene Evaluation sollte die vollständige Änderung umfassen, mit demselben Repository-Zugriff und denselben Tools wie im geplanten Einsatz.

Entscheidungsregel: Wenn eine Aufgabe mehrere Dateien und Ausführungsschritte umfasst, sind vor der Aufnahme in die engere Auswahl Ergebnisse aus Agentenaufgaben nötig. Werte auf Funktionsebene dienen als Ergänzung. Code-Reviews bleiben Teil der Abnahme, bis eigene Fälle einen geringeren Prüfaufwand rechtfertigen.

Benchmarks für das Schlussfolgern von LLMs

GPQA, HLE, MMLU-Pro, AIME und ARC-AGI prüfen unterschiedliche Formen des Schlussfolgerns. Sie geben Hinweise darauf, was eine nähere Untersuchung lohnt, insbesondere bei schwierigen naturwissenschaftlichen oder mathematischen Aufgaben. Als Ersatz für direkte Nachweise zur Einhaltung betrieblicher Regeln sind sie wenig geeignet.

Die 198 Fragen von GPQA Diamond bilden eine gezielt ausgewählte naturwissenschaftliche Sammlung. Ein CTO kann damit eine Vorauswahl für einen internen Rechercheassistenten treffen. Anschließend muss sich der Assistent an Fragen bewähren, deren Antworten von unternehmenseigenen Unterlagen abhängen. Für eine Supportleitung sind dagegen richtliniengebundener Werkzeugeinsatz und die Weitergabe an zuständige Stellen wichtiger.

Bei Humanity's Last Exam sollte der große Anspruch des Namens von der tatsächlichen Messung getrennt bleiben. Die Autoren unterscheiden ausdrücklich zwischen akademischen Aufgaben mit feststehenden Antworten und autonomer Forschung. Eine schwierige Frage mit bekannter Lösung zu beantworten zeigt noch nicht, dass ein System ein lohnendes Problem auswählen, verlässliche Belege sammeln und eigene Irrtümer erkennen kann.

Lange Kontexte und Sprachsysteme brauchen eigene Nachweise

Ein Kontextfenster beschreibt die Kapazität: wie viel Eingabe ein System aufnehmen kann. Tests mit langen Kontexten untersuchen, was es mit dieser Eingabe anfangen kann. Abrufaufgaben verlangen, Informationen zu finden; Denkaufgaben verlangen, sie zu verknüpfen. Die Autoren von RULER zeigen, weshalb das Finden einer versteckten Information nicht stellvertretend für die gesamte Leistung bei langen Kontexten stehen sollte.

Bei der Vertragsprüfung ist beispielsweise entscheidend, ob ein Assistent eine Ausnahme im Anhang mit einer Klausel im Hauptvertrag verbindet und beide korrekt belegt. Dazu gehören auch Dokumente, in denen die Antwort fehlt, überholt ist oder durch andere Angaben widerlegt wird. Ein System, das unvereinbare Fassungen selbstsicher zusammenführt, ist gescheitert, selbst wenn es jede einzelne Passage gefunden hat.

Bei Sprachsystemen sind Hören, Schlussfolgern, Sprechen und Gesprächssteuerung getrennt zu betrachten. FLEURS kann zur Bewertung der Transkription beitragen; Big Bench Audio untersucht das Schlussfolgern aus gesprochenen Fragen; VoiceBench deckt Aufgaben mit gesprochenen Anweisungen ab. Die aktuelle tau-Familie bewertet ebenfalls Sprachinteraktionen. Das sind unterschiedliche Messungen.

Ein Pilotprojekt für telefonischen Support sollte Hintergrundgeräusche, Namen, Unterbrechungen, Korrekturen und die Übergabe an einen Menschen enthalten. Die Interaktion muss angehört und die abschließende Aktion überprüft werden. Eine Transkription kann korrekt aussehen, obwohl das Gespräch frustriert oder das falsche Konto geändert wird.

Benchmarks zur LLM-Leistung

Für die Einführung zählt erfolgreich abgenommene Arbeit innerhalb der Grenzen des eigenen Arbeitsablaufs. Antwortqualität, zuverlässiger Abschluss und Reaktionszeit sind eigenständige Anforderungen. Ein Benchmark mit umfangreichem Reasoning kann für eine Untersuchung über Nacht relevant sein und zugleich schlecht zu einer laufenden Supportinteraktion passen.

Bei der Beschaffung sind Ergebnisse für die benötigten Aufgabengruppen und die tatsächliche Produktkonfiguration gefragt. Im Betrieb müssen Fehler und die Wiederaufnahme nach Fehlern geprüft werden. In der Entwicklung sollten sich die Einstellungen reproduzieren lassen. Kann ein Anbieter die getestete Konfiguration nicht benennen, reicht der Wert als Grundlage für einen verbindlichen Produktiveinsatz nicht aus.

Eine Ergebnistabelle in fünf Minuten einordnen

Dieser Fünf-Minuten-Check hilft zu entscheiden, ob eine Modellvorstellung eine gründlichere Evaluation verdient. Er ist eine Lesehilfe; die Zeit reicht nicht aus, um die Sicherheit oder den Nutzen eines Modells für die eigene Anwendung nachzuweisen.

1. 1

   Minute 1: Die eigene Aufgabe benennen

   Das benötigte Ergebnis festhalten: Probleme im Repository beheben, Supportanfragen lösen, Fragen anhand von Dokumenten beantworten oder Telefongespräche führen. Anschließend die passenden Zeilen markieren. Siege bei unpassenden Aufgaben sollten die Einführungsentscheidung nicht beeinflussen.

2. 2

   Minute 2: Die genaue Prüfung bestimmen

   Benchmark-Ausgabe, Teilmenge, Sprache und Aufgabenzeitraum notieren. Auf Zusätze wie Diamond, Verified, offline, text-only oder with tools achten. Ist die Bezeichnung unvollständig, hilft die Seite des Benchmarks weiter.

3. 3

   Minute 3: Den Testaufbau prüfen

   Harness, Tools, Reasoning-Einstellung, Zeitbudget und Regeln für Versuche ermitteln. Dann prüfen, ob das eigene Produkt unter denselben Bedingungen arbeiten wird. Suchzugriff, Codeausführung oder zusätzliche Wiederholungsversuche können verändern, was ein Ergebnis aussagt.

4. 4

   Minute 4: Die Metrik verstehen

   Accuracy ist der Anteil der als richtig bewerteten Antworten. F1 berücksichtigt sowohl den Anteil korrekter Elemente unter den ausgegebenen Ergebnissen als auch den Anteil gefundener Elemente unter allen gesuchten. Teilpunkte können Fortschritt belohnen, ohne dass eine Aufgabe abgeschlossen wurde. Bei einer Fehlerrate ist ein niedrigerer Wert besser. Erst die Definition lesen, bevor ein Prozentwert als Anteil erledigter Aufgaben gilt.

5. 5

   Minute 5: Den Urheber des Ergebnisses ermitteln

   Feststellen, wer den Test durchgeführt hat: der Hersteller, der Benchmark-Veranstalter oder eine andere Prüfstelle. Die Fußnote der jeweiligen Zeile lesen, statt ein einheitliches Verfahren für die gesamte Tabelle anzunehmen. Quelle und Einstellungen sichern und anschließend einen Kandidaten für eigene Tests auswählen.

Am Ende sollte eine kurze Entscheidungsnotiz stehen: „Relevante Aufgabenfamilie, aktuelle Version, Testaufbau verstanden, Prüfung an eigenen Fällen sinnvoll.“ Lassen sich diese Punkte nicht ausfüllen, wird zunächst die fehlende Information festgehalten, bevor ein funktionierendes System geändert wird.

Praxisbeispiel: Googles Ergebnistabelle zu Gemini 4 Argon

Gemini 4 Argon, Googles universell einsetzbares KI-Modell, eignet sich als Beispiel, weil die Tabelle Aufgabenfamilien und Bewertungsregeln mischt. Die folgenden Zeilen geben Googles Ergebnisse aus der Modellkarte vom Oktober wieder, abgeglichen am 15. Oktober 2026. Es handelt sich um Ergebnisse von Google, nicht um Messungen für diesen Artikel.

Zu jedem Wert gehören die Zeilenbezeichnung und die zugehörigen Hinweise. Diese Prozentwerte haben weder einen gemeinsamen Nenner noch dieselbe Bedeutung.

BFS steht für breadth-first search, auf Deutsch Breitensuche: Graphverbindungen werden nach ihrer Tiefe durchlaufen. Tokens sind die Einheiten, mit denen der Modellkontext gemessen wird; sie entsprechen nicht Wörtern.

Erst die Fußnoten lesen, dann Schlüsse ziehen

Laut Googles Evaluationsmethodik verwendet Argon grundsätzlich die höchste Thinking-Einstellung und pass@1, mit Ausnahmen. Das DeepSWE-Ergebnis nutzt einen mini-swe-Harness. Das Terminal-Bench-Ergebnis wurde selbst berechnet, die Vergleichswerte stammen dagegen aus der offiziellen Rangliste. Bei GraphWalks wurden die Ergebnisse für alle Modelle selbst berechnet. OSWorld verwendet den Höchstwert aus drei Durchläufen und weist Teilpunkte für die Offline-Aufgaben aus.

Hier kommen verschiedene Evaluationsverfahren zusammen; es ist kein Beleg dafür, dass sämtliche Tabellenwerte aus einem einzigen kontrollierten Experiment stammen. Für die Entwicklung lautet die nächste Frage, ob der Programmier-Harness dem geplanten Agenten ähnelt. Bei der Beschaffung zählt, ob die vorgeschlagene Anwendungskonfiguration zu den Nachweisen passt. Im Betrieb ist entscheidend, ob die Metrik das vollständig erreichte Ergebnis belohnt.

Unsere Rechnung: 99.7 minus 84.2 ergibt zwischen den veröffentlichten GraphWalks-F1-Werten einen Abstand von 15.5 Prozentpunkten. Die Zeilen beziehen sich auf unterschiedliche Längenteilmengen. Die Subtraktion isoliert daher nicht den kausalen Einfluss der Länge auf identische Fragen. Sie zeigt aber, weshalb die alleinige Nennung des Werts für kürzere Kontexte relevante Informationen für die Arbeit mit langen Dokumenten auslassen würde.

Ebenso konkret ist die Einordnung der Computerbedienung: Aus der Teilpunktwertung lässt sich nicht ableiten, dass „der Agent diesen Anteil unserer Desktop-Aufgaben vollständig erledigt“. Teilfortschritte können bei einem Assistenten nützlich sein, der die Arbeit an einen Menschen zurückgibt. Ein unbeaufsichtigter Prozess braucht Nachweise für vollständige, korrekte Ergebnisse.

Weitere Einordnung zum Einsatz des Modells bieten Gemini 4 Argon erklärt und der separate Vergleich von Gemini 4 Argon und Opus 5.5.

Warum ein hoher Wert in die Irre führen kann

Ein hoher Wert kann korrekt sein und trotzdem die falsche betriebliche Frage beantworten. Sinnvoll ist, zunächst die Einschränkung zu benennen und dann festzulegen, welcher Nachweis sie ausräumen würde.

Kontamination und Optimierung auf den Test

Von Kontamination spricht man, wenn Evaluationsfragen oder ihre Antworten in das Trainingsmaterial gelangen. Das Modell kann dann von bereits Bekanntem profitieren, statt ein unbekanntes Problem zu lösen. Auch öffentliche Tests können zu Optimierungszielen werden: Wer Prompts oder Scaffolds wiederholt an denselben Aufgaben ausrichtet, mindert deren Aussagekraft als unabhängige Prüfung.

LiveCodeBench verwendet datierte Aufgaben. So lassen sich Probleme auswählen, die nach dem Wissensstichtag des Trainings veröffentlicht wurden. Das ist ein nützliches Merkmal des Testdesigns, aber keine Erlaubnis, jedes Ergebnis mit „Live“ im Namen als frei von Kontamination anzusehen. Maßgeblich ist der tatsächliche Aufgabenzeitraum. Ein auffällig großer Leistungssprung ist Anlass, das Protokoll zu prüfen, und kein Beweis für Fehlverhalten.

Für die eigene Evaluation sollte ein zurückgehaltener Testsatz bestehen bleiben, der nicht zur Prompt-Optimierung dient. Wird ein Fehlerfall zum Entwicklungsbeispiel, müssen neue Fälle in diesen Testsatz aufgenommen werden. Sonst kann das System die vertrauten Beispiele hervorragend lösen und außerhalb davon weiterhin anfällig sein.

Das Scaffolding kann das verglichene System verändern

Die Ausführungsumgebung zählt. Ein Modell mit Suche, Dateitools, Wiederholungsversuchen und sorgfältig formulierten Anweisungen bildet ein anderes Einsatzsystem als dasselbe Modell, das auf einen einzelnen Prompt antwortet. Besseres Scaffolding kann ein wertvoller technischer Fortschritt sein. Der Fehler liegt darin, das gesamte Ergebnis dem zugrunde liegenden Modell zuzuschreiben.

Soll der Einfluss eines Modellwechsels isoliert werden, braucht es einen gemeinsamen Harness. Bei der Auswahl zwischen vollständigen Produkten muss dagegen das gesamte Produkt bewertet werden. Diese unterschiedlichen Fragen dürfen zu unterschiedlichen Ergebnissen führen.

Herstellerergebnisse richtig einordnen

Ein Herstellerergebnis ist nützlich, wenn die Methode klar ist. Ein Ergebnis des Benchmark-Veranstalters ist nützlich, wenn seine Konfiguration zum Vergleich passt. Keine dieser Herkunftsangaben ersetzt die Lektüre des Protokolls. Es muss erkennbar sein, ob ein Ergebnis lediglich bei einer Rangliste eingereicht oder unabhängig unter einheitlichen Bedingungen reproduziert wurde.

Wichtig sind Prompt, Modellkennung, Harness, Bewertungsmethode, Ausschlüsse und Unsicherheit. Ein kleiner Abstand sollte keine Migration auslösen, wenn ausreichende Informationen zur Streuung fehlen. Ein ausgelassenes Ergebnis ist ein fehlender Nachweis und nicht automatisch eine Null.

Auch die Zusammenfassung der Ergebnisse verdient Aufmerksamkeit. In einem Gesamtdurchschnitt stecken die Aufgabenwahl und Gewichtung der Prüfstelle. Die eigene Supportwarteschlange kann viele Ausnahmefälle enthalten, die diesen Durchschnitt kaum beeinflussen. Prozentwerte aus sachlich verschiedenen Benchmarks sollten nicht zu einem eigenen Intelligenzwert gemittelt werden.

Auch eine gute Bewertung kann das falsche Ergebnis messen

Unit-Tests, Musterlösungen, bewertende Modelle und menschliche Präferenzen belohnen unterschiedliche Dinge. Die Testabdeckung kann einen Defekt übersehen, eine Musterlösung kann fehlerhaft sein und ein bewertendes Modell kann eine gewandte Erklärung einer korrekten Aktion vorziehen. Ein Sieg bei einer Präferenzabfrage misst, was die Befragten unter diesem Verfahren bevorzugt haben.

Das aktuelle tau-Repository dokumentiert Korrekturen an Aufgaben und Bewertungen. Solche Änderungen verbessern die Evaluation und machen es zugleich unverzichtbar, die Version nachzuhalten. Ein Test ist ein laufend gepflegtes Messsystem, keine unfehlbare Wahrheitsquelle.

Wann sind eigene Evaluationen nötig?

Eigene Evaluationen sind nötig, sobald eine Entscheidung von den eigenen Daten, Richtlinien, Tools, Nutzern oder tolerierbaren Fehlern abhängt. Öffentliche Werte reichen aus, um plausible Kandidaten zu finden. Sie reichen nicht aus, um einen Agenten freizugeben, der Kundendatensätze ändert oder Antworten aus internen Dokumenten liefert.

Jetzt handeln, wenn eine Verbesserung in einem relevanten Benchmark einen bekannten Fehler des aktuellen Systems betrifft: Dann lohnt sich ein kontrollierter Vergleich für genau diese Fehlerklasse. Mit der Migration warten, wenn die Verbesserung andere Aufgaben betrifft oder der veröffentlichte Testaufbau im eigenen Produkt nicht verfügbar ist. Beim aktuellen System bleiben, wenn es die Abnahmekriterien bereits erfüllt und der neue Kandidat keine relevante Verbesserung gezeigt hat.

Für das Supportteam eines mittelständischen Unternehmens könnte ein erster Pilot 50 Fälle umfassen: 20 Routineanfragen, 10 Ausnahmen von Richtlinien, 10 Fälle mit fehlenden oder widersprüchlichen Angaben und 10 Berechtigungs- oder Eskalationsfälle. Das sind Vorschläge für die Testgestaltung, keine Behauptung, dass diese Stichprobe statistisch für eine Einsatzfreigabe ausreicht. Die endgültige Größe richtet sich nach den Fehlerraten und Unterschieden, die erkannt werden müssen.

Das gewünschte Ergebnis wird vor dem Test der Kandidaten festgelegt. Bei einer Erstattung können dazu die korrekte Anspruchsprüfung, das richtige Konto und der richtige Betrag, der Ausschluss unbefugter Aktionen und eine verständliche Erklärung gehören. Ein Eskalationsfall sollte als bestanden gelten, wenn der Agent korrekt übergibt, auch wenn er die Anfrage nicht selbst löst.

Jeder Kandidat muss mit den vorgesehenen Prompts, Abrufverfahren, Tools und Berechtigungen laufen. Zu prüfen sind der abschließende Datensatz und das Aktionsprotokoll, nicht nur die letzte Nachricht. Instabile Fälle werden wiederholt, Latenzen separat erfasst und abweichende Bewertungen geklärt, bevor eine Verbesserung festgestellt wird. Ein separater Testsatz bleibt für die endgültige Entscheidung reserviert.

Promptfoo ist ein Evaluationstool, das Prompts, Modelle und Anwendungen anhand von Testfällen und festgelegten Prüfbedingungen vergleicht. Die Dokumentation erläutert das Ausführungsmodell; unser Promptfoo-Testbericht zeigt, wo das Tool passt und welche Verantwortung beim eigenen Team bleibt.

Für direkt überprüfbare Sachverhalte eignen sich deterministische Prüfungen, etwa für das ausgewählte Konto oder eine verbotene Aktion. Eigenschaften, die eine Beurteilung erfordern, brauchen einen Bewertungsleitfaden, der an menschlichen Bewertungen kalibriert wird. Das gilt etwa für die Frage, ob eine Erklärung vollständig und durch Belege gestützt ist. Der Leitfaden zu LLM-as-a-Judge behandelt diese Bewertungsebene und ihre Fehlerquellen.

Der nächste Schritt am Montag: Einen Arbeitsablauf auswählen, Abnahmekriterien formulieren, aktuelle Fälle sammeln und das bestehende System unter gleichen Bedingungen mit einem Kandidaten vergleichen. Die Entscheidung über den Einsatz folgt aus den Ergebnissen und Fehlern, die für die Nutzer zählen.

Häufige Fragen zu Benchmark-Tabellen

Welche LLM-Benchmarks sind besonders verbreitet?

Zuerst zählen die Familien: SWE-bench und Terminal-Bench für Programmieragenten, GPQA und Humanity's Last Exam für akademische Fragen, die tau-Familie für den Werkzeugeinsatz in Gesprächen sowie eigene Tests für lange Kontexte und Sprachverarbeitung. Zu jedem Ergebnis gehören Ausgabe und Einstellungen.

Welcher LLM-Benchmark eignet sich am besten fürs Programmieren?

Der passende Benchmark liegt möglichst nah an der tatsächlichen Aufgabe. SWE-bench untersucht die Lösung von Softwareproblemen in Repositories, Terminal-Bench die Arbeit im Terminal, HumanEval die Erzeugung von Funktionen. LiveCodeBench enthält datierte Wettbewerbsaufgaben. Ob sich die Ergebnisse übertragen lassen, entscheidet sich an Änderungen im eigenen Repository.

Was ist ein LLM-Benchmark-Datensatz?

Ein Datensatz liefert die Fragen oder Aufgaben. Für ein vergleichbares Benchmark-Ergebnis braucht es außerdem das Protokoll: Prompts, Tools, Grenzen, Versuche und Bewertung. Derselbe Datensatzname allein belegt nicht, dass zwei Ergebnisse vergleichbar sind.

Für praktische Orientierung zur Bewertung und Einführung von KI den Newsletter abonnieren.