Suchergebnisse für: „Benchmark“

„Benchmarks are more broken than we could have imagined.“ Unter diesem Titel – die Benchmarks seien kaputter, als man es sich hätte vorstellen können – hat Horizon Analytics Labs am 21. September seinen Audit-Bericht veröffentlicht. Überraschend ist der Befund nicht: Epoch AI hatte zuvor fünfzehn Benchmarks geprüft und neun als fehlerhaft eingestuft – durchgesickerte Antworten, belohnte Abkürzungen, unvollständige Tests, versagende Prüfroutinen.

Das allein war schon unangenehm. Horizon ging trotzdem weiter und nahm sich die öffentlich einsehbaren Aufgabendatensätze großer Anbieter im Harbor-Hub vor. Die Leitfrage: Passen Anweisung, Umgebung, Referenzlösung und Bewerter zusammen? Wer sich mit KI-Evaluierung beschäftigt, kommt an dieser Frage nicht vorbei.

Eine Benchmark-Aufgabe lässt sich als Prüfung mit vier Beteiligten beschreiben: ein Aufgabenblatt, ein Prüfungsraum, eine Musterlösung und jemand, der korrigiert. Wenn das Aufgabenblatt etwas anderes verlangt, als der Korrektor bewertet, wenn die Musterlösung selbst durchfällt oder die Antwort im Prüfungsraum ausliegt, dann sagt die Note nichts mehr darüber aus, welche Fähigkeit geprüft werden sollte. Horizon hat diese vier Teile gegeneinander gehalten – und dabei Fehler gefunden.

Was Epoch AI fand und was darunter liegt

Epoch AI hat fünfzehn Benchmarks geprüft und bei neun davon Probleme gefunden. Die Bandbreite reichte von durchgesickerten Antworten über belohnte Abkürzungen bis zu Tests, die nicht messen, was sie messen sollen. Das reicht, um misstrauisch zu werden.

Horizon Analytics Labs nahm sich die öffentlich einsehbaren Aufgabendatensätze großer Anbieter vor. Für jede Aufgabe stellte das Team dieselbe Frage – passen Anweisung, Umgebung, Referenzlösung und Bewerter zusammen? So kamen zwanzig Datensätze mit 5.241 Aufgaben zusammen. Das Ergebnis: 29 bestätigt defekte Aufgaben.

Wie diese Zahl zustande kam: Das Team hat alle 5.241 Aufgaben gescannt, 239 davon genauer geprüft und 34 einzeln durchgesehen. Die 29 bestätigten Fälle stammen aus dem gesamten Verfahren, nicht nur aus der manuellen Einzelprüfung. Der Bericht ist der erste Teil einer fortlaufenden Untersuchung und Ausgangspunkt für einen Anbieter-Qualitätsindex, den Horizon aufbauen will. Dazu gehört eine Einordnung: Horizon verkauft selbst Datensatz-Audits, der Bericht wirbt also auch für die eigene Dienstleistung. Die Befunde sind allerdings einzeln belegt und mit den betroffenen Aufgaben verlinkt.

Fünf Arten von Benchmark-Fehlern

Die gefundenen Fehler waren unterschiedlich, aber nicht zufällig verteilt. Jeder bestätigte Fall ließ sich einer von fünf Kategorien zuordnen. Die erste ist die Antwortkontamination in Benchmarks: Die Umgebung enthält die Lösung. Ein Agent kann zum Beispiel den fertigen Fix aus der Git-Historie holen, statt den Fehler zu suchen.

Die zweite Kategorie sind unvollständige Tests. Der Bewerter prüft weniger, als die Anweisung verlangt. Ein Beispiel aus dem Bericht: Eine Aufgabe verlangt Änderungen an vier Teilen eines Streaming-Systems, die Tests fassen aber nur ein einziges Paket an.

Die dritte Kategorie ist die trivial spielbare Bewertung. Ein Modell punktet, ohne die Arbeit zu erledigen. Wird etwa ein editierbares Wörterbuch ausgetauscht, springt dieselbe erfundene Antwort von null auf volle Punktzahl. Die Bewertung lässt sich mit einem Handgriff umgehen.

Die vierte Kategorie ist der Spec-Test- oder Fähigkeits-Mismatch: Anweisung und Bewerter widersprechen sich, oder das Bestehen beweist nicht die Fähigkeit, die die Aufgabe zu prüfen vorgibt. In einem Fall verlangten zwei Teile der Bewertungskonfiguration unterschiedliche Finanzwerte für dieselbe Antwort.

Die fünfte Kategorie ist der Oracle-Fehler oder das instabile Grading. Die veröffentlichte Lösung scheitert, oder das Ergebnis hängt von etwas Unstabilem ab. Ein Beispiel: Die Lösung des Autors erhält null Punkte, nachdem sich eine externe Datenbank geändert hat.

Die Verteilung fällt deutlich aus: 17 Aufgaben mit unvollständigen Tests, 14 mit Antwortkontamination, elf mit Spec-Test-Mismatch, acht mit spielbarer Bewertung und vier mit Oracle- oder Flaky-Problemen. Eine Aufgabe kann auf mehr als eine Weise scheitern, deshalb überschneiden sich diese Zahlen. Insgesamt ergibt das 54 Kategorie-Platzierungen.

Warum die meisten Fehler die Modelle besser aussehen lassen

Kontamination, unvollständige Tests und spielbare Bewertung machen 39 dieser 54 Platzierungen aus. Diese Fehler verschenken Punkte. Ein Modell erscheint leistungsfähiger, weil es die Antwort in der Umgebung gefunden, nur den zufällig getesteten Teil erledigt oder eine akzeptierte Abkürzung entdeckt hat.

Der Bericht nennt das Ergebnis deshalb nicht einfach Rauschen, sondern schmeichelhaftes Rauschen. Der Fehler verzerrt die Rangliste nicht in eine beliebige Richtung, sondern systematisch zugunsten der Modelle. Deshalb bleiben fehlerhafte KI-Benchmarks oft unbemerkt: Ein zu gutes Ergebnis fällt niemandem unangenehm auf.

Die Probleme waren außerdem nicht gleichmäßig verteilt. In der geprüften Stichprobe von Scale AI dominierte Kontamination, bei Terminal-Bench 2.1 häuften sich unvollständige Tests, Shortcuts und Bewertungsfehler, bei OpenThoughts fanden sich editierbare Bewerter-Eingaben und Referenzlösungen, die ihre eigenen Aufgaben nicht lösten. Das heißt nicht, dass jeder Datensatz dieser Anbieter dasselbe Problem hat. Es heißt, dass die geprüften Stichproben auf unterschiedliche Weise scheiterten – eine einzige Gesamtfehlerquote würde diesen Unterschied verwischen.

Die Autoren betonen, dass es sich um Zählungen bestätigter Befunde in den geprüften Stichproben handelt, nicht um Fehlerquoten des gesamten Anbieters. Eine leere Zelle bedeutet nur, dass dieser Fehlertyp hier nicht bestätigt wurde – nicht, dass er nicht existiert.

Fünf Beispiele

Bei Scale AI im Datensatz SWE-bench Pro sollte ein Modell einen Ansible-Fehler reparieren. Das Aufgaben-Image enthielt den fertigen Fix allerdings noch in seiner Git-Historie. Mit deaktiviertem Netzwerk ließ sich die Lösung wiederherstellen, und die echte Prüfroutine gab volle Punktzahl: 16 von 16 Tests. Die Lösung lag bereit. Einen Tag nach dem Audit hat Scale eine überarbeitete Fassung veröffentlicht, SWE-Bench Pro V2; ob sie diese Lecks schließt, prüft der Bericht nicht.

Ein zweites Beispiel aus demselben Datensatz verlangte, einen Zeitversatz durch einen kompletten Streaming-Pfad zu leiten: Cache-Schlüssel, zwei Endpunkte und die Templates. Das Team änderte eine einzige Datei, während zwei weitere relevante Pakete nicht kompilierten – und erhielt trotzdem volle Punktzahl, weil der Bewerter nur das FFmpeg-Paket ausführte. Die Aufgabe beschrieb eine systemweite Änderung, die Note maß einen Befehlsstring.

Bei OpenThoughts las der Bewerter sein Wörterbuch aus demselben Arbeitsbereich, den der Löser bearbeiten konnte. Dieselbe erfundene Antwort erhielt null Punkte mit dem Original-Wörterbuch und volle Punktzahl, nachdem das Wörterbuch ersetzt worden war. An der Antwort hatte sich nichts verbessert, nur an dem, was der Bewerter für wahr hielt.

Im Datensatz Apex Agents von Mercor erwartete ein Teil der Bewertungskonfiguration ein Sponsoren-Eigenkapital von 28.137 Dollar und eine IRR von 20,4 Prozent. Ein anderer Teil akzeptierte nur 28.517 Dollar und 20,8 Prozent. Eine Antwort konnte einer veröffentlichten Erwartung folgen und an der anderen scheitern. Das ist keine schwere Aufgabe, sondern eine Aufgabe mit zwei Definitionen von richtig.

Bei Terminal-Bench 2.1 schließlich führte das Team die Lösung des Autors fünfmal aus, dreimal gegen die vom Hub ausgelieferte Version. Sie erhielt jedes Mal null Punkte, weil sich die externen Proteindaten geändert hatten. Die Tests erwarteten weiterhin die ältere Darstellung, sodass keine gültige Sequenz Daten und Bewerter gleichzeitig erfüllen konnte. Eine Aufgabe, deren akzeptierte Antwort nicht mehr existiert, ist nicht lösbar.

Ein Shortcut, den niemand nutzt, ist trotzdem ein Defekt

Manche Modelle erledigen eine kontaminierte Aufgabe vielleicht, ohne je in die Git-Historie zu schauen. Sicher ist das Paket deshalb nicht. Sobald die Antwort erreichbar ist, kann dieselbe Punktzahl zwei völlig verschiedene Dinge bedeuten: Ein Modell versteht den Code und repariert ihn, ein anderes inspiziert die Umgebung, findet den versteckten Commit und kopiert den Patch. Der Bewerter kann beide nicht auseinanderhalten.

Mit leistungsfähigeren Agenten wird dieser Punkt wichtiger. Gute Modelle erkunden ihre Umgebung, lesen Repository-Historie, prüfen Build-Artefakte und suchen den kürzesten verlässlichen Weg zum Ergebnis. Eine Abkürzung zu finden ist in echter Arbeit oft nützlich. Zum Problem wird es erst, wenn der Benchmark behauptet, die erzielte Punktzahl messe eine andere Fähigkeit.

Ein Benchmark sollte die Modelle überleben, für die er gebaut wurde. Man sollte nicht darauf hoffen müssen, dass ein Modell die Antwort übersieht. Wer fehlerhafte KI-Benchmarks erkennen will, muss deshalb nicht nur nach falschen Ergebnissen suchen, sondern nach erreichbaren Antworten und zu großzügigen Bewertern.

Harbor ist ein Format, kein Qualitätssiegel

Harbor macht solche Audits möglich. Die Plattform gibt Aufgaben eine gemeinsame Struktur: Anweisungen, Umgebungen, Lösungen und Bewerter lassen sich so verpacken, dass sie lauffähig sind und sich über Anbieter hinweg vergleichen lassen. Ohne dieses Format wäre ein Benchmark-Audit für KI-Modelle in dieser Breite kaum machbar.

Harbor entscheidet aber nicht, ob eine Anweisung vollständig ist. Das Format weiß nicht, ob die Antwort in der Git-Historie liegt. Es beweist nicht, dass der Bewerter prüft, was die Aufgabe verlangt. Harbor vereinheitlicht das Paket; der Audit sagt, ob der Inhalt Vertrauen verdient. Format und Benchmark-Qualität sind zwei verschiedene Dinge.

Für den geplanten Index will Horizon mehrere Dinge zusammen zeigen: die abgeschlossenen Urteile, also wie viele geprüfte Aufgaben sauber oder fehlerhaft waren, die Schwere der Defekte, die Breite der Fehlertypen, die Stärke der Belege und die Verlässlichkeit der Prüfung. Eine Gesamtnote bildet Horizon daraus bewusst nicht: Schwere, Fehlerbreite und Belegstärke stehen nebeneinander, statt in einer undurchsichtigen Punktzahl zu verschwinden.

Der Index startet mit Bewertungen auf Datensatzebene. Anbieter-Rankings entstehen erst, wenn die Abdeckung einen Vergleich erlaubt. Ein Anbieter, der eine Aufgabe repariert, soll dafür Anerkennung bekommen, und ein Datensatz, der sich ändert, behält nicht die Bewertung einer älteren Version. Einmal gefundene Fehler dauerhaft als Urteil zu konservieren wäre unfair.

Was heißt das für den Alltag mit LLM-Benchmarks? Eine Rangliste ist nur so viel wert wie die Aufgaben, auf denen sie beruht. Wer Modellvergleiche liest, sollte genauer hinschauen: Wurden die Bewerter ausgeführt, besteht die Referenzlösung zuverlässig, und pflegt der Anbieter seine Datensätze, wenn sich Abhängigkeiten ändern? Solange diese Fragen offen bleiben, ist jede Platzierung eine Momentaufnahme mit unbekannter Fehlertoleranz. Der Audit liefert dafür eine erste Grundlage.

Quelle: horizonanalyticslabs.com

„Current benchmarks substantially understate frontier models‘ ability to solve well-posed physics problems.“ So steht es in einer Studie, die im September 2026 unter der arXiv-Nummer 2609.13009 erschienen ist. Sie stellt die Bewertung von KI-Modellen in der Physik in Frage. Wer heute auf Ranglisten schaut, auf denen Frontier-Modelle in der Physik weit hinten landen, misst womöglich weniger die Denkfähigkeit dieser Systeme als die Mängel der Prüfungen. Der Befund trifft nicht die Modelle, sondern die Prüfungen, auf die sich Forschung und Produktentscheidungen seit Jahren stützen. Ein Blick auf die Mechanik solcher Physik-Benchmarks zeigt, was daran neu ist.

Was Physik-Benchmarks messen, wenn sie nicht Physik messen

Ein Benchmark ist im Kern eine Klausur mit automatischer Korrektur. Es gibt Aufgaben mit verifizierbaren Endantworten, ein hinterlegtes Lösungsblatt, und eine Maschine, die die Antwort des Modells mit diesem Blatt vergleicht. Solange alle drei Teile stimmen, funktioniert das gut. Sobald aber das Lösungsblatt falsch ist oder die Aufgabenstellung mehrere gültige Lesarten zulässt, produziert die Maschine Noten, die nichts über das physikalische Reasoning des Modells aussagen.

Die Autoren um Ali Ansari haben genau dort angesetzt und sechs weit verbreitete Physik-Benchmarks neu untersucht: HLE-Physics, CMT-Benchmark, CritPt, UGPhysics, PRISM-Physics und PHYBench. Beschränkt wurde sich auf rein textbasierte Aufgaben mit eindeutig prüfbarer Endantwort, weil nur dort der Vergleich zwischen Modellantwort und Referenz sinnvoll möglich ist. Anschließend saßen Fachleute aus den jeweiligen Teilgebieten vor den Aufgaben und prüften jede einzelne Bewertung von Hand. Beteiligt waren Professorinnen und Professoren ebenso wie Doktoranden, also Menschen, die das Problem selbst lösen könnten, wenn man ihnen Papier und Stift gäbe.

Die Handprüfung ist der Kern der Arbeit. Sie unterscheidet nicht nur zwischen richtig und falsch, sondern zwischen vier Kategorien: echte Fehler des Modells, Fehler des automatischen Bewerters, falsche Referenzlösungen und Fragen, die mehrdeutig oder unzureichend spezifiziert sind. Das klingt nach Buchführung, ist aber wichtig. Ohne diese Unterscheidung lässt sich nicht sagen, ob ein niedriger Physik-Score auf fehlendes Verständnis oder auf ein kaputtes Messinstrument zurückgeht.

Drei Fehlerquellen, die wie Denkfehler der KI aussehen

Das Ergebnis der Handprüfung ist unbequem für alle, die Benchmark-Zahlen für harte Fakten halten. In den meisten überprüften Fällen, die zunächst als falsche Modellantwort gewertet wurden, lag das Problem nicht beim Modell, sondern beim Benchmark selbst. Die Modelle hatten auf eine Frage geantwortet, die so nicht eindeutig beantwortbar war, oder sie hatten eine physikalisch korrekte Lösung geliefert, die von der hinterlegten Referenz abwich. In beiden Fällen schlug die automatische Korrektur zu, ohne dass damit etwas über wissenschaftliches Reasoning gesagt wäre.

Man kann sich das wie eine Prüfung vorstellen, in der die Musterlösung aus einem älteren Skript stammt und stillschweigend andere Konventionen verwendet als die Aufgabenstellung. Der Prüfling rechnet sauber, verwendet die in der Aufgabe genannten Vorzeichen, und bekommt den Punkt trotzdem nicht. Über hundert solcher Fälle hinweg entsteht der Eindruck, die Kandidaten seien schwach. Genau das verzerrt laut dieser Arbeit die öffentliche Wahrnehmung von KI-Modellen in der Physik.

Die zweite Fehlerquelle ist die Ambiguität. Physikaufgaben aus echten Lehrveranstaltungen enthalten oft stillschweigende Annahmen: welche Näherung gilt, welches Koordinatensystem gemeint ist, ob der Grenzfall eingeschlossen ist. Wer die Vorlesung besucht hat, weiß das. Ein Modell, das nur den Aufgabentext sieht, muss raten. Die dritte Quelle sind schlicht falsche Referenzlösungen, also Aufgaben, bei denen die offizielle Antwort nachweislich nicht stimmt. Dass solche Fälle über Jahre in viel zitierten Benchmarks überleben, sagt viel darüber, wie selten Evaluierungen fachlich nachgeprüft werden.

Was die Korrektur aus den Zahlen macht

Die Autoren haben die fehlerhaften Aufgaben nicht nur markiert, sondern instand gesetzt: falsche Referenzlösungen wurden korrigiert, unklare Fragen repariert oder ausgeschlossen. Danach wurde erneut gemessen. Für GPT-5.6-Sol steigt der Mittelwert über vier Läufe auf HLE-Physics von 47,3 auf 78,7 Prozent. Beim CMT-Benchmark geht es von 61,0 auf 87,2 Prozent nach oben. Bei den 54 CritPt-Aufgaben, die nach der Expertenprüfung übrig blieben, erreicht dasselbe Modell korrigiert 94,4 Prozent Pass@4.

Auch auf den überprüften Teilmengen von UGPhysics, PRISM-Physics und PHYBench steigen die Werte deutlich. Wichtig ist dabei die Formulierung „auf den verbliebenen Teilmengen“: Die korrigierten Scores gelten nur für die Aufgaben, die die Expertenprüfung überstanden haben. Das ist keine nachträgliche Schönung der Gesamtbilanz, sondern eine Messung an einem saubereren Instrument. Der Unterschied zwischen beiden Lesarten ist erheblich, und die Autoren benennen ihn selbst offen.

Die veröffentlichten Zahlen aus dem Artificial Analysis Intelligence Index 2026 und ähnlichen Zusammenstellungen unterschätzen die Fähigkeit aktueller Frontier-Modelle bei wohldefinierten Physikproblemen systematisch. Das heißt nicht, dass die Modelle die Physik beherrschen. Es heißt, dass die bisherige Messlatte zu tief hing, um das noch zu zeigen.

Nahezu Sättigung: Wenn 94 Prozent normal werden, misst der Test kaum noch etwas

Damit kommt ein zweites Problem dazu, das die Autoren Near-Saturation nennen. Wenn ein Modell auf einer geprüften Aufgabenmenge 94 Prozent erreicht, unterscheidet dieser Test kaum noch zwischen guten und sehr guten Systemen. Er ist dann kein Thermometer mehr, sondern ein Lichtschalter: Die Nadel schlägt aus, aber die Feinheiten verschwinden. Für Physik-Benchmarks, die als anspruchsvoll galten, ist das ein bemerkenswerter Zustand.

Die naheliegende Reaktion wäre, einfach schwerere Aufgaben zu schreiben. Genau hier liegt die Falle, die diese Studie sichtbar macht. Schwieriger heißt nicht automatisch besser; es heißt oft nur unklarer. Wer Aufgaben entwirft, die selbst Fachleute nicht eindeutig lösen können, erzeugt wieder jene Mehrdeutigkeit, die schon die alten Benchmarks verzerrt hat. Ein schwieriger Benchmark ohne Expertenvalidierung produziert am Ende dieselbe Art von Rauschen, nur mit niedrigeren Zahlen.

Die Autoren fordern deshalb aufwändigere, von Fachleuten geprüfte Evaluierungen. Das ist teuer und langsam, und es lässt sich nicht nebenbei automatisieren. Aber es ist der einzige Weg, auf dem ein Benchmark noch etwas bedeutet. Die Alternative wäre eine Landschaft, in der alle Modelle auf allen Listen irgendwann bei fast 100 Prozent stehen und niemand daraus noch etwas ableiten kann.

Was das für den Umgang mit KI-Modellen in der Forschung heißt

Für dich heißt das zunächst: Sei misstrauisch gegenüber einzelnen Benchmark-Zahlen, besonders wenn sie als Beleg für grundsätzliche Unfähigkeit dienen. Die Aussage „Modell X scheitert an Fortgeschrittener Physik“ ist nur so belastbar wie die Aufgaben, auf denen sie beruht. Das gilt in beide Richtungen, denn auch ein auffällig hoher Score sagt wenig, wenn die Aufgaben schlecht gestellt waren.

Zweitens zeigt die Arbeit, warum Expertenbewertung in der Evaluierung von KI-Modellen kein Luxus ist. Automatische Auswertung skaliert hervorragend, aber sie kann nicht erkennen, ob eine Antwort physikalisch richtig ist und nur anders aussieht als die Musterlösung. Dafür braucht es Menschen mit Fachwissen, die bereit sind, hunderte Einzelfälle durchzusehen. Diese Arbeit hat genau das getan, und allein der Aufwand erklärt, warum es so lange niemand flächendeckend gemacht hat.

Drittens verschiebt sich die relevante Frage. Nicht mehr „Wie viele Physikaufgaben löst ein Modell?“ steht im Zentrum, sondern „Wie gut sind die Aufgaben, an denen wir es messen?“. Solange die zweite Frage offen ist, bleibt die erste eine Zahl ohne Aussage. Das betrifft jede Disziplin, in der KI-Modelle gemessen werden, nicht nur die Physik.

Quelle: arxiv.org

Ein Benchmark-Sieg klingt nach einem eindeutigen Ergebnis. Der Bericht „Agents on Rails“ vom 2. September 2026 zeigt etwas anderes: einen Gleichstand an der Spitze. Die Entscheidung fällt an einer Stelle, die beim Modellvergleich meist übersehen wird. Svyatoslav Kryukov und Artur Petrov haben 17 Modelle auf 21 Rails-Aufgaben geschickt, jede Aufgabe dreimal. Heraus kam kein Sieg der reinen Rechenleistung, sondern eine Frage von Werkzeug, Preis und Zeit.

Wer ein Modell für Ruby-on-Rails-Aufgaben auswählt, schaut meist auf die oberste Zeile des Leaderboards. Dort steht jetzt ein Unentschieden. Zwei Modelle erreichen 92 Prozent. Darunter liegt ein Kandidat, der für fünf Cent pro Lauf fast dasselbe leistet. Interessanter als der Spitzenwert ist der Abstand zwischen Preis und Ergebnis.

Ein KI-Coding-Agent arbeitet wie ein Geselle in einer gut sortierten Werkstatt. Es reicht nicht, dass am Ende ein Bauteil passt. Er muss auch das richtige Werkzeug von der Wand nehmen, statt sich mit Klebeband eine Eigenlösung zu biegen. Beides hält erstmal. Der Unterschied zeigt sich, wenn jemand die Konstruktion später anfassen muss.

Gleichstand an der Spitze: Claude Fable 5.1 zieht mit Claude Opus 5 nach

Claude Fable 5.1 ist einen Tag vor dem Bericht erschienen und landet direkt auf Augenhöhe mit dem bisherigen alleinigen Spitzenreiter. Beide Modelle lösen 58 von 63 Durchläufen, das sind 92 Prozent, und beide schaffen mindestens 20 der 21 Aufgaben wenigstens einmal. Der Unterschied liegt nicht in der Trefferquote, sondern im Aufwand dahinter. Fable 5.1 kostet 75 Dollar für alle 63 Läufe, Claude Opus 5 verlangt 120 Dollar. Auch bei der Zeit liegt das neue Modell vorn: 5,4 Minuten im Median gegen 9,7 Minuten.

Claude Fable 5 kam auf 57 von 63 Läufen, kostete 146 Dollar und brauchte 6,8 Minuten pro Durchlauf. Die Rechnung ist also rund 50 Prozent günstiger als beim Vorgänger und rund 40 Prozent günstiger als bei Opus 5. In der Spitzengruppe ist Fable 5.1 damit das schnellste Modell, auf Augenhöhe mit GPT-5.6 Sol. Ein Benchmark ist allerdings ein Prüfstand und keine Landstraße: Die Autoren betonen selbst, dass 63 Läufe eine kleine Stichprobe sind. In den Vorläufen lag Fable 5.1 bei etwa 95 Prozent, im offiziellen Durchlauf hatte es schlicht Pech.

Ein Detail abseits der Punktzahl ist wichtiger, als es aussieht. In der ersten Runde scheiterte Fable 5 an einer Aufgabe, die wie ein Pen-Test-Bericht formuliert war, und zwar in allen drei Versuchen. Fable 5.1 liest denselben Bericht und behebt jeden Befund. Ein Modell, das eine Sicherheitsaufgabe nicht mit einem Sicherheitsproblem verwechselt, ist im Alltag mehr wert als ein Prozentpunkt auf dem Leaderboard.

Rails API Recall: 41 Prozent und der Fall quote_column_name

Der Rails API Recall Benchmark misst etwas anderes als das reine Lösen von Aufgaben. Jede Aufgabe verweist auf eine bestimmte Rails-API, die eine ideale Lösung verwenden sollte. Eine selbst gebaute Ersatzlösung kann die Tests bestehen, aber sie ist nicht der Weg, den das Framework vorsieht. Hier liegt der Unterschied zwischen Code, der funktioniert, und Code, den das nächste Teammitglied ohne Zorn lesen kann. Bisher lagen die Werte in diesem Benchmark zwischen 8 und 35 Prozent.

Claude Fable 5.1 erreicht 41 Prozent. In Zahlen heißt das: In 26 der 63 Läufe erinnerte sich das Modell unaufgefordert an die passende API, 9 Mal fand sie sich in der Ausgabe, 20 Mal wurde sie übergangen, 8 Mal baute das Modell eine Eigenlösung. Claude Opus 5 kam auf 20 Treffer aus dem Stand, also 32 Prozent, dazu 14 gefundene APIs, 15 übergangene und 14 Eigenlösungen. Claude Fable 5 lag bei 21 unaufgeforderten Treffern, im Bericht mit 35 Prozent angegeben, dazu 6 gefundene APIs, 21 übergangene und 12 Eigenlösungen; drei Läufe endeten ohne Patch.

Die Verbesserung liegt nicht daran, dass ein neueres Modell neuere APIs kennt. quote_column_name ist fast so alt wie Active Record selbst, und kein vorheriges Modell hatte diese Methode unaufgefordert erwähnt. Es geht also nicht um frisches Trainingswissen, sondern um die Frage, ob ein Modell nachsieht, was an der Wand hängt, bevor es improvisiert. Für Teams, die KI-Modelle für Rails einsetzen, zählt am Ende diese Zahl: Der Agent schreibt Code, den später Menschen warten müssen.

GLM 5.3 Flash: Der Stealth-Kandidat aus der letzten Runde hat jetzt einen Namen

Das Modell, das in der vorigen Runde unter dem Codenamen ox-alpha antrat, ist enttarnt. Es handelt sich um GLM 5.3 Flash von Z.ai. Die Autoren haben den Stealth-Namen beerdigt und alle 63 Versuche unter dem echten Namen und dem echten Preis erneut laufen lassen. Das Ergebnis deckt sich mit den Vorabwerten: 52 von 63 Läufen, also 83 Prozent, bei Gesamtkosten von 3,31 Dollar. Das sind rund fünf Cent pro Durchlauf.

Damit liegt GLM 5.3 Flash auf demselben Niveau wie Grok 4.6, das ebenfalls 83 Prozent erreicht, aber zum Fünfzehnfachen des Preises. In der Rangliste steht Flash hinter Kimi K3 mit 90 Prozent und GPT-5.6 Sol mit 84 Prozent, auf Augenhöhe mit Grok 4.6 und vor dem großen GLM 5.3 mit 79 Prozent. Die Preis-Leistung von GLM 5.3 Flash ist hier keine Marketingfloskel, sondern eine Rechnung. Wer viele kleinere Rails-Aufgaben automatisiert, für den ist der Cent-Betrag pro Lauf relevanter als die letzten Prozentpunkte.

Wie der Agents-on-Rails-Benchmark aufgebaut ist

Alle Zahlen stammen aus dem üblichen Aufbau. Der Harness heißt lemans, es gelten Standard-Effort-Stufen, und jede der 21 atomaren Writebook-Aufgaben wird dreimal versucht. Die Prüfung ist versteckt, die Rohdaten liegen im Repository rails/ai-evals, die aktuellen Werte stehen auf der Agents-on-Rails-Seite. Jede Zahl lässt sich bis zum einzelnen Lauf zurückverfolgen.

Zwei kleinere Änderungen betreffen die Darstellung. Die Standard-Effort-Stufen, mit denen die Läufe stattgefunden haben, sind jetzt auf der Seite dokumentiert. Die Diagramme wurden zusätzlich überarbeitet, nach einer Anregung von Nate Berkopec: Egal was du vergleichst, die besseren Modelle erscheinen nun in der oberen rechten Ecke. Das klingt nach Kosmetik, macht aber den Vergleich zwischen zwei Kenngrößen auf einen Blick lesbar.

Der wichtigste Vorbehalt steht im Kleingedruckten. Drei Läufe pro Aufgabe sind ein Kompromiss zwischen Laufzeit und Aussagekraft, nicht mehr. An der Spitze steht ein Unentschieden, und beide Modelle wurden von derselben Aufgabe gestoppt. Der atomare Aufgabenkatalog wird langsam zu klein, weshalb die Autoren größere und realistischere Aufgaben für eine zweite Stufe vorbereiten.

Was das für die Auswahl eines KI-Coding-Agenten bedeutet

Drei Punkte bleiben für die Auswahl. Erstens: Der Spitzenplatz im Agents-on-Rails-Leaderboard ist derzeit geteilt, und die Entscheidung zwischen den beiden 92-Prozent-Modellen fällt über Preis und Laufzeit, nicht über Qualität. Claude Fable 5.1 liefert dieselbe Trefferquote für deutlich weniger Geld und in etwa der halben Zeit. Zweitens: Für Aufgaben, bei denen es nicht um Sekunden oder Centbeträge geht, ist GLM 5.3 Flash mit 83 Prozent für fünf Cent pro Lauf eine ernsthafte Option, nicht bloß eine Notlösung.

Drittens, und das wird beim Blick auf die reine Punktzahl übersehen: Der Rails API Recall entscheidet darüber, wie lange der erzeugte Code lebt. Ein Modell, das 92 Prozent der Aufgaben löst, aber regelmäßig an der Werkzeugwand vorbeigeht und Eigenlösungen baut, produziert Arbeit für später. Ein Modell mit etwas niedrigerer Trefferquote, das die vorhandenen Rails-APIs kennt, liefert dagegen Code, der sich in eine bestehende Anwendung einfügt, ohne sie zu verbiegen. Wer Claude Fable 5.1 für Rails-Aufgaben in einem gewachsenen Projekt einsetzt, sollte deshalb beide Zahlen nebeneinander lesen.

Die 41 Prozent von Claude Fable 5.1 sind kein Endstand, sondern eine Zwischenmarke. Sie zeigen, dass sich die Erinnerung an Framework-APIs messbar verbessern lässt. Bis die größeren Aufgaben der zweiten Stufe kommen, bleibt der Prüfstand ein kontrollierter Raum mit 21 Aufgaben und drei Versuchen. Was dort funktioniert, funktioniert noch nicht automatisch in deiner Anwendung.

Quelle: rubyonrails.org

Was kann GPT-6 Astra? Eine neue Auswertung von Artificial Analysis liefert Antworten. Wir gehen die Zahlen durch und erklären, was sie konkret bedeuten. Token-Effizienz und Kosten stehen für den Verbrauch, Benchmark-Scores für die Leistung.

Coding-Agent-Index: Gleichauf mit der Konkurrenz

Der Coding Agent Index von Artificial Analysis misst, wie gut Modelle autonom Code schreiben. GPT-6 Astra kommt auf 67 Punkte – gleichauf mit Claude Opus 5 und Fable 5 im Claude-Code-Modus sowie mit Muse Spark 1.3. Nur Fable 5.1 liegt mit 70 Punkten klar vorne.

Die Token-Effizienz sticht heraus. Astra verbraucht nur ein Drittel der Tokens von GPT-5.6 Sol im gleichen Setup. Gegenüber Claude Opus 5 auf hoher Denkstufe ist es sogar fünfmal sparsamer. Heißt: Für dieselbe Coding-Aufgabe produziert das Modell deutlich weniger Text – in großen Projekten spart das Zeit und Geld.

Auch die Kosten pro Aufgabe haben sich verschoben. Im Max-Effort-Modus kostet Astra ungefähr so viel wie GPT-5.6 Sol, schneidet im Index aber zwei Punkte besser ab. Gegenüber Claude Fable 5, das eine ähnliche Punktzahl erreicht, halbiert sich der Preis pro Coding-Aufgabe. Effizienz plus Wettbewerbspreis machen Astra zu einer ernsten Option für automatisierte Softwareentwicklung.

Intelligence Index: Effizienz teuer erkauft

Im Intelligence Index bleibt GPT-6 Astra auf dem Niveau des Vorgängers. 61 Punkte, genau wie GPT-5.6 Sol. Fünf Punkte hinter Claude Fable 5.1 (max mit Fallback) und auch hinter Meta Muse Spark 1.3. Die allgemeine Denkfähigkeit hat sich nicht messbar verbessert.

Verbessert hat sich die Token-Nutzung. Etwa zehn Prozent weniger Ausgabe-Tokens pro Aufgabe im Max-Effort-Modus gegenüber GPT-5.6 Sol. Dieser Effizienzgewinn geht aber in der Preiserhöhung unter. GPT-6 Astra ist in der Preisgestaltung 2,5-mal teurer – pro Aufgabe zahlst du am Ende rund 75 Prozent mehr als beim Vorgänger.

Die OpenAI-Preisliste erklärt den Sprung. Pro Million Eingabe-Tokens verlangt das Unternehmen zehn Dollar statt vier, für Ausgabe-Tokens fünfzig statt zwanzig Dollar. Cache-Reads behalten den Rabatt von 90 Prozent, Cache-Writes erhalten einen Aufschlag von 25 Prozent. Damit ist GPT-6 Astra deutlich teurer als GPT-5.6 Sol – der Token-Vorteil verpufft auf der Rechnung.

Halluzinationen halbiert: Die Omniscience-Wende

Im AA-Omniscience-Benchmark, der Wissen und Halluzinationsneigung testet, senkt GPT-6 Astra die Halluzinationsrate im Max-Effort-Modus von 92 Prozent (Vorgänger) auf 51 Prozent. Fast eine Halbierung.

Dabei leidet die Genauigkeit nicht. Die Accuracy steigt gleichzeitig um vier Punkte. Viele Modelle reduzieren Halluzinationen, indem sie häufiger ganz schweigen. Astra schafft beides – mehr Präzision und mehr Zurückhaltung bei Unsicherheit.

Für faktenkritische Anwendungen zählt das. Recherche oder Code-Dokumentation profitieren direkt von niedrigen Halluzinationsraten. Offen bleibt, ob das Ergebnis in der Praxis mit langen Kontexten stabil bleibt.

Langzeitaufgaben: Fortschritt mit Nebenwirkungen

Im AA-Briefcase-Benchmark, der mehrwöchige Projekte mit Tausenden Quelldateien simuliert, gewinnt GPT-6 Astra etwa 80 Elo-Punkte gegenüber GPT-5.6 Sol. Der Zuwachs liegt vor allem bei den Rubrik-Scores und der analytischen Qualität. Die Präsentationsqualität dagegen nimmt ab – hier führt weiterhin GPT-5.6 Sol.

Anderswo sieht es gemischt aus. Bei Humanity’s Last Exam (Mathematik, Naturwissenschaften, Geisteswissenschaften) legt Astra sechs Punkte zu. Dafür verliert es rund 80 Elo im GDPval-AA v2, einem Benchmark für wirtschaftlich relevante Aufgaben aus 44 Berufen. Auch bei τ³-Banking, SciCode und AA-LCR sinken die Werte um zwei bis drei Punkte.

Solche Regressionen sind bei neuen Modellgenerationen normal. Ein Bereich verbessert sich, ein anderer leidet. Entscheidend ist, ob die gemischten Resultate für deinen konkreten Einsatz relevant sind.

Was das für deine Projekte heißt

Der GPT-6 Astra Benchmark zeigt eine ungleiche Entwicklung. Codierung: dank hoher Token-Effizienz ein starkes Paket aus Preis und Leistung. Allgemeine Intelligenz: knapp hinter den Spitzenmodellen – und der höhere Preis frisst die Token-Ersparnis auf.

Der größte Fortschritt ist die Halluzinationsreduktion. Dass ein Modell gleichzeitig genauer wird, ist bei aktuellen Systemen keine Selbstverständlichkeit. Dieser Punkt wiegt schwerer als die kleinen Schwankungen in einzelnen Benchmark-Kategorien.

Für Entwickler und Power-User heißt das: Einsatz genau abwägen. Bei Agenten-Projekten mit Code-Ausführung ist Astra eine ernsthafte Alternative, besonders wenn die Kosten pro Aufgabe im Fokus stehen. Für reine Denkaufgaben oder Textgenerierung bleibt GPT-5.6 Sol wirtschaftlicher.

GPT-6 Astra glänzt nicht überall, aber an den richtigen Stellen. Damit ist es ein nützlicher Baustein im aktuellen KI-Ökosystem. Bleibt abzuwarten, wie OpenAI die Preise in den nächsten Monaten anpasst.

Quelle: artificialanalysis.ai