AIME 2024: Was eine Trefferquote bei 30 Aufgaben misst – und warum zwei scheinbar gleiche Ergebnisse nicht vergleichbar sein können

Was „AIME 2024“ genau bedeutet

AIME 2024 wird oft als ein einzelner Benchmark für mathematisches Schlussfolgern dargestellt, doch die Bezeichnung verdichtet mehrere Entscheidungen. In einer dokumentierten Evaluierungsimplementierung umfasst der Satz die Aufgaben von AIME I und AIME II dieses Jahres, also insgesamt dreißig Items. Jede Aufgabe erwartet eine ganzzahlige numerische Antwort in dreistelliger Darstellung von 000 bis 999. Die Bewertung kann automatisiert erfolgen, weil sie weder von einer menschlichen Beurteilung der Formulierung noch von einem Bewertungsraster für Zwischenschritte abhängt.

Diese Zusammensetzung ist von Beginn an wichtig. Ein Ergebnis über alle dreißig Aufgaben hat keine identische Grundlage wie ein Ergebnis, das nur aus einer Prüfung mit fünfzehn Aufgaben berechnet wurde. Ebenso darf nicht vorausgesetzt werden, dass zwei als „AIME 2024“ bezeichnete Datensätze dieselben Aufgabentexte, Kennungen, Formatanpassungen oder Lösungsschlüssel verwenden. Evaluierungs-Harnesses können Aufgaben und Antwortextraktoren unterschiedlich bündeln. Das Benchmark-Label benennt eine Aufgabenfamilie, zertifiziert aber nicht automatisch ein gemeinsames Protokoll.

Eine sorgfältige Lektüre beginnt deshalb damit, die Schlagzeile in konkrete Fragen zu übersetzen: Wurde AIME I, AIME II oder beides bewertet? Wie viele Aufgaben waren enthalten? Und welche Implementierung wandelte die Textausgabe in eine bewertbare Antwort um? Fehlen diese Antworten, ist der Prozentwert eine unvollständige Beobachtung und kein abgeschlossener Vergleich.

Was ein Score misst – und was er ausblendet

AIME 2024 liefert ein nützliches Signal für das Lösen mathematischer Wettbewerbsaufgaben, deren Endantwort exakt überprüft werden kann. Das Format reduziert eine häufige Quelle von Mehrdeutigkeit: Wenn der Evaluator gemäß der festgelegten Regel die richtige ganze Zahl gewinnt, zählt das Item als korrekt; andernfalls als Fehler. Diese Eigenschaft macht den Test attraktiv, um viele Evaluationen konsistent auszuführen.

Der Endscore beobachtet jedoch nicht unmittelbar den gesamten Weg zur Antwort. Ein Modell kann korrekt argumentieren, aber mit einem Format enden, das der Extraktor nicht erkennt. Es kann ebenso durch eine fehlerhafte Schrittkette zur richtigen Zahl gelangen, ohne dass Exact Match dies prüft. Der Benchmark bewertet konstruktionsbedingt die vom Harness wiedergewonnene Endantwort, nicht die Qualität eines mathematischen Beweises.

Daraus folgt nicht, dass ein gutes Ergebnis wertlos wäre. Es zeigt Leistung bei einer abgegrenzten Aufgabe mit Aufgaben im Wettbewerbsstil und überprüfbaren ganzzahligen Antworten. Was es allein nicht belegen kann, sind allgemeine Schlussfolgerungsfähigkeit, die Fähigkeit, überprüfbare Beweise zu schreiben, Genauigkeit bei beruflichen Aufgaben, Zuverlässigkeit in Domänen mit unvollständigen Informationen oder Leistung bei neuen Problemverteilungen. Solche Aussagen erfordern zusätzliche Evaluationen und einen nachgewiesenen Zusammenhang zwischen Test und Einsatzfall.

Es lohnt sich außerdem, mathematische Kompetenz von Produkteignung zu trennen. Ein für Analysten, Wissenschaftler oder Ingenieure nützliches System muss je nach Kontext Anforderungen interpretieren, Annahmen offenlegen, externe Daten nachvollziehbar einsetzen, Unsicherheit erkennen und Grenzen kommunizieren. Keine dieser Eigenschaften wird durch dreißig ganzzahlige Antworten vollständig gemessen.

Die Mindestangaben, die jedes Ergebnis begleiten sollten

Eine veröffentlichbare Behauptung sollte es anderen ermöglichen, das Gemessene zu rekonstruieren, auch wenn sie nicht alle Berechnungen wiederholen können. Die erste Zeile einer Ergebnisakte betrifft den Datensatz: AIME I, AIME II oder beide, die Zahl der Aufgaben sowie Quelle oder Version der Aufgabentexte. Die zweite betrifft die Identität des Systems: exakter Modellname, Snapshot oder Datum, Anbieter und gegebenenfalls die Konfiguration für Schlussfolgern.

Danach muss der Generierungsmodus angegeben werden. Dazu gehören der vollständige Prompt oder eine hinreichende Beschreibung seiner Formatanweisungen, Temperatur und andere Sampling-Parameter, maximales Tokenbudget, Zeitlimits, Zahl der Aufrufe pro Aufgabe sowie Unterbrechungen oder Wiederholungsversuche. Fehlen diese Angaben, kann der Leser nicht zwischen einem Ergebnis mit einer Stichprobe und einer intensiven Suche über viele Lösungswege unterscheiden.

Die Akte sollte zudem Modell und Umgebung trennen. Waren Taschenrechner, Codeausführung, Browsing, Dokumentenabruf oder andere Tools verfügbar? Konnte das System eigene Ergebnisse prüfen? Hat ein externes Verfahren die beste Antwort ausgewählt? Solche Bedingungen können angemessen sein, wenn sie den vorgesehenen Einsatz widerspiegeln. Sie müssen jedoch neben dem Prozentwert stehen und dürfen nicht hinter dem Modellnamen verborgen bleiben.

Schließlich ist eine Beschreibung des Harness nötig. Eine dokumentierte AIME-2024-Implementierung verwendet einen Ausgabeprompt der Form „ANSWER: $ANSWER“, Exact-Match-Bewertung und Änderungen am Scorer in Bezug auf LaTeX und leere Antworten. Solche Details zeigen, warum der Parser keine bloß administrative Frage ist: Er entscheidet, welcher Text in eine ganze Zahl umgewandelt und welche Ausgabe für ungültig erklärt wird. Die Regelung für fehlende Antworten, mehrere Antworten, mehrdeutigen Text und Formatfehler muss ausdrücklich dokumentiert sein.

Eine Ausführung kann viele verschiedene Kennzahlen erzeugen

Pass@1 beantwortet eine einfache Frage: Wie viele Endantworten waren mit genau einer Stichprobe pro Aufgabe korrekt? Meist liegt diese Lesart einer einzelnen Interaktion am nächsten, sofern Prompt, Temperatur, Budget und Tools ebenfalls angegeben werden. Trotzdem ist sie nicht zwingend ein Abbild eines realen Gesprächs, denn sie kann speziell für den Benchmark entworfene Anweisungen enthalten.

Pass@k verändert die Frage. Statt einer Gelegenheit werden mehrere Antworten pro Aufgabe generiert und es wird gefragt, ob mindestens eine davon korrekt ist. Dieser Wert kann das Suchpotenzial eines Systems untersuchen, steigt jedoch mit der Zahl der Versuche und entspricht nicht der Erfolgswahrscheinlichkeit einer einzelnen Antwort an einen Nutzer. Pass@k ohne Angabe von k zu veröffentlichen, macht die Zahl nicht interpretierbar.

Mehrheitswahl oder Konsens erzeugt mehrere Antworten und wählt nach einer festgelegten Regel die am stärksten unterstützte aus. Das kann die Stabilität verbessern, wenn mehrere Lösungswege zur selben Lösung führen; Wahrheit garantiert es jedoch nicht, denn Versuche können denselben Fehler teilen. Die Leistung hängt von der Zahl der Stichproben ab, davon, wie äquivalente Antworten gruppiert werden, und davon, was bei nicht extrahierbaren Formaten geschieht.

Reranking fügt eine weitere Komponente hinzu: Nach der Erzeugung von Kandidaten wählt ein Selektor einen aus. Dieser Selektor kann das Modell selbst, ein Verifizierer, eine Heuristik, ein Tool oder ein anderes System sein. Ein Ergebnis mit Reranking misst daher eine vollständige Pipeline. Es sollte nicht automatisch dem isolierten generierenden Modell zugeschrieben werden. Eine OpenAI-Veröffentlichung unterscheidet ausdrücklich Ergebnisse mit einer Stichprobe, Konsens aus mehreren Dutzend Stichproben und Reranking mit einer deutlich größeren Zahl von Stichproben. Diese Trennung ist methodisch wesentlich.

Tools führen eine weitere Verzweigung ein. Ein Taschenrechner oder eine Codeumgebung kann Rechenfehler verringern; externe Suche kann Informationen liefern, die nicht im Prompt enthalten sind. Keine der Optionen ist an sich unzulässig, doch „mit Tools“ und „ohne Tools“ beantworten unterschiedliche Fragen. Model Cards, die beide Bedingungen ausweisen, sind informativer als ein einzelner Wert.

Warum ein scheinbar identischer Prozentwert nicht dieselbe Zahl richtiger Antworten bedeuten muss

In einer Menge von dreißig Aufgaben entspricht jede richtige Antwort einem merklichen Anteil der Gesamtheit. Wird ein Prozentwert mit Dezimalstellen berichtet, kann er aus einer einzelnen Ausführung, mehreren Wiederholungen, einem Durchschnitt über Teilmengen oder einer Aggregation über Konfigurationen stammen. Bei fünfzehn Aufgaben sind die Sprünge einer einzelnen Ausführung noch größer. Aus einem Wert wie 80 % lässt sich daher weder automatisch eine ganzzahlige Zahl korrekter Antworten noch die Zahl bewerteter Aufgaben ableiten.

Rundung ist nur ein Teil des Problems. Ein Anbieter kann den Mittelwert vieler Durchläufe berichten, ein anderer das beste Ergebnis eines Durchlaufs, ein dritter den Durchschnitt der Ergebnisse je Frage nach mehrfacher Stichprobenziehung. Diese Entscheidungen können für unterschiedliche Zwecke vertretbar sein, müssen aber benannt werden. Ein Wert ohne Nenner, Streuung oder Aggregationsverfahren sollte nicht als präzise Messung verstanden werden.

Vergleichbarkeit verlangt, dass Elemente, die die effektive Schwierigkeit beeinflussen, konstant gehalten oder zumindest offengelegt werden: Datensatz, Version der Aufgabentexte, Modell, Prompt, Tools, Generierung, Extraktion und Bewertung. Weicht eines davon ab, kann der Vergleich weiterhin orientierend sein, sollte aber nicht ohne Weiteres in ein Fähigkeitsranking überführt werden.

Vorherige Exposition, öffentliche Verfügbarkeit und Sättigung

AIME 2024 sollte auch als öffentlich verfügbarer Aufgabensatz analysiert werden. Arbeiten zur Evaluation auf nicht kontaminierten Mathematikwettbewerben behandeln diese Verfügbarkeit als berechtigten Anlass zur Sorge: Ein Modell oder ein Retrieval-System könnte während seiner Entwicklung Aufgaben, Lösungen, Diskussionen oder Varianten gesehen haben. Das beweist weder, dass ein konkretes Modell mit diesen Items trainiert wurde, noch erlaubt es, jedes gute Ergebnis auf Auswendiglernen zurückzuführen.

Die vorsichtige Formulierung ist konditional. Vorherige Exposition ist ein Validitätsrisiko, das offengelegt werden sollte, wenn ausreichende Informationen zu Trainingsdaten, Fine-Tuning-Daten, Retrieval und Stichtag fehlen. Das Fehlen eines öffentlichen Beweises für Exposition beweist umgekehrt keine Unabhängigkeit. Zwischen beiden Extremen liegt Unsicherheit, keine automatische Schlussfolgerung.

Von einem Anbieter kann man angemessene Evidenz verlangen: Stichtag der Daten, Beschreibung von Filtern für Evaluierungsdaten, Richtlinien zu Wettbewerbsunterlagen, Veröffentlichungsdatum des Modells und Details zu möglichen Retrieval-Tools. Kann er diese Angaben nicht bereitstellen, kann das Ergebnis als kontextuelle Evidenz erhalten bleiben – allerdings mit einer klaren Grenze: Es sollte nicht als alleiniger Beweis für Generalisierung auf neue Probleme dienen.

Sättigung hat zudem eine praktische Folge. Je populärer ein Benchmark wird, desto wahrscheinlicher zirkulieren Prompts, Lösungen, Strategien und Evaluierungskonfigurationen breit. Für Produktentscheidungen ist es sinnvoll, AIME 2024 als historisches Signal zu behandeln und durch eine private, aktuelle und für die reale Arbeit repräsentative Testsuite zu ergänzen. Dabei sind Nutzungs- und Reproduktionsrichtlinien für Wettbewerbsmaterialien zu beachten.

AIME 2024 verantwortungsvoll in einer Produktentscheidung einsetzen

Für technische Verantwortliche kann AIME 2024 beim Vorauswählen von Systemen als sekundäres Signal dienen, die strukturierte mathematische Probleme lösen. Sein größter Nutzen entsteht mit einem klaren Protokoll und bei Vergleichen von Ergebnissen unter denselben Bedingungen. Der Benchmark sollte nicht zu einer einzigen Schwelle für Beschaffung, Deployment oder Sicherheit werden.

Die ergänzende Evaluation hängt vom Einsatzfall ab. Wenn ein Produkt quantitative Analysen erzeugt, sind eigene Aufgaben mit Daten, Einheiten, Annahmen und rechnerischer Prüfung relevant. Soll es Ergebnisse erklären, müssen Klarheit, Nachvollziehbarkeit und Fehlererkennung bewertet werden, nicht nur die Endzahl. Arbeitet es mit Tools, muss die gesamte Pipeline gemessen werden, einschließlich Berechtigungen, Kosten, Latenz, Tool-Ausfällen und Verifikation. Geht es um Fachwissen, kann ein Benchmark wie GPQA Diamond ein anderes Signal liefern, ersetzt jedoch ebenfalls keine Tests des konkreten Arbeitsablaufs.

Effizienz und Ergebnis müssen ebenfalls getrennt werden. Zwei Systeme mit ähnlicher Genauigkeit können sehr unterschiedliche Mengen an Stichproben, Tokens, Aufrufen oder Zeit benötigen. In Produktion wirken sich diese Unterschiede auf Kosten, Latenz, Kapazität und Vorhersagbarkeit aus. Eine Benchmark-Tabelle ohne Inferenzbudget kann einen für den Einsatzfall entscheidenden Unterschied verbergen.

Leser, die eine Ergebnisakte für DeepSeek-R1, GPT-6 Astra oder andere Modelle vergleichen, sollten dieselbe Disziplin anwenden und aus einer Marke keine unveröffentlichten Bedingungen ableiten. Der Handelsname ersetzt keinen Snapshot, und ein einer Organisation zugeschriebener Wert ersetzt keine Protokolldokumentation. Das Benchmark-Verzeichnis und die spezifische AIME-2024-Seite sind der geeignete Ort, um diese Bedingungen neben jedem Ergebnis dauerhaft festzuhalten.

Weiter entdecken

Korrekturen und Transparenz

Wenn du falsche oder veraltete Angaben findest, sende uns die Seite und die zu prüfende Quelle.