Signal und Rauschen in Coding-Evaluierungen trennen

• Die Bewertung der Coding-Fähigkeiten von AI-Modellen ist direkt mit Entscheidungen zu Deployment und Sicherheit verknüpft, doch laut OpenAIs Audit waren bei den SWE-Bench-Pro-Aufgaben schätzungsweise rund 30 % fehlerhaft
• SWE-Bench Pro zielte auf einen größeren Aufgabenumfang und realistischere Aufgaben ab, doch bei den 731 öffentlichen Aufgaben ist das Ergebnis eines Anstiegs der Erfolgsquote von 23,3 % auf 80,3 % in acht Monaten nicht mehr ohne Weiteres glaubwürdig
• Die Mängel lassen sich in übermäßig strenge Tests, unterdefinierte Prompts, Tests mit geringer Abdeckung und irreführende Prompts einteilen; dadurch können korrekte Einreichungen scheitern oder unvollständige Fixes bestehen
• Das Audit markierte auf Basis von Modellversuchen, Aufgaben-Metadaten und Fehlerverfolgung 286 potenziell problematische Aufgaben, die anschließend von einem Untersuchungsagenten und fünf erfahrenen Ingenieuren unabhängig geprüft wurden
• OpenAI hat seine Empfehlung zur Übernahme von SWE-Bench Pro zurückgezogen; Evaluierungs-Benchmarks müssen aussagekräftige Signale liefern, die die Beurteilung von Modellfähigkeiten und Sicherheit nicht verzerren

---

Probleme, die im Audit von SWE-Bench Pro sichtbar wurden

• OpenAI schätzt nach einem Audit von SWE-Bench Pro, dass etwa 30 % aller Aufgaben fehlerhaft sind
• Die genaue Messung von Modellfähigkeiten wirkt sich auch auf Deployment- und Sicherheitsentscheidungen im Rahmen des Preparedness Framework aus
• Fehlerhafte Evaluierungen können zu einem falschen Verständnis der tatsächlichen Modellfähigkeiten führen und Sicherheitsentscheidungen sowie Forschungsprioritäten verzerren

Ziel von SWE-Bench Pro und Veränderung der Erfolgsquote

• OpenAI hatte zuvor beim weit verbreiteten SWE-bench Verified Design- und Kontaminationsprobleme festgestellt und kam zu dem Schluss, dass diese Evaluierung kein aussagekräftiges Signal mehr für Softwareentwicklungsfähigkeiten liefert
• Damals empfahl OpenAI der Community den Wechsel zu SWE-Bench Pro
• SWE-Bench Pro wurde als Verbesserung von SWE-bench Verified entwickelt, um agentische Coding-Fähigkeiten anhand eines größeren Aufgabenumfangs und realistischeren Coding-Aufgaben zu verfolgen
• Die Aufgaben werden programmgesteuert aus der Historie von Funktionsänderungen in öffentlichen und nicht öffentlichen Repositories extrahiert
  • Das Modell muss eine Lösung implementieren, die neue Feature-Tests besteht, ohne bestehende Funktionalität zu beschädigen
  • In der öffentlichen Aufteilung mit 731 Aufgaben stieg die Erfolgsquote von Frontier-Modellen innerhalb von acht Monaten von 23,3 % auf 80,3 %

Qualitätssicherungs-Pipeline

• OpenAI entwickelte eine Qualitätssicherungs-Pipeline, um zu prüfen, ob jeder Datenpunkt die tatsächlichen Modellfähigkeiten widerspiegelt
• Ein anfänglicher automatischer Filter prüfte die dem Modell gegebenen Anweisungen, die Lösungsversuche des Modells und die Bewertungstests, um fehlerhafte oder verdächtige Beispiele zu markieren
• Dabei wurden 286 potenziell problematische Aufgaben markiert
• Die markierte Teilmenge wurde anschließend über zwei Wege vertieft geprüft
  • Agentenprüfung unter menschlicher Aufsicht: Ein Untersuchungsagent führt Detailprüfungen durch und durchläuft danach eine abschließende menschliche Beurteilung
  • Kampagne mit menschlicher Annotation: Erfahrene Softwareentwickler prüfen die Aufgaben direkt

Vorgehen bei Agentenprüfung und menschlicher Prüfung

• Die markierten Probleme wurden von einem Codex-basierten Untersuchungsagenten auditiert
  • Der Agent hat Zugriff auf das Aufgaben-Repository und die Ausführungsumgebung
  • Er kann Tests ausführen, Repository-Dateien untersuchen sowie Modellversuche und typische Fehlermuster analysieren
  • Das wurde genutzt, um vernünftige Mehrdeutigkeiten, die sich aus umgebendem Code und Repository-Konventionen auflösen lassen, von echter Unterdefiniertheit zu unterscheiden
• Nach mehreren unabhängigen Tiefen-Audits prüften Forschende die Zusammenfassungen und vergaben die finale Beurteilung sowie Problemlabels
• Parallel dazu prüften in einer Kampagne mit menschlicher Annotation erfahrene Softwareingenieure die Aufgaben, nachdem sie in Benchmark-Zielen, Problemklassifikation und Grenzfällen geschult worden waren
• Jede Aufgabe wurde von fünf Ingenieuren geprüft
  • Die Prüfer trafen zunächst eine unabhängige Einschätzung auf Basis der sichtbaren Problembeschreibung, der Testfälle und der Gold-Patch-Referenzlösung
  • Anschließend nutzten sie Pipeline-Analysen oder Protokolle als zusätzlichen Kontext
  • Auf Grundlage konkreter Belege vergaben sie Labels und Schweregrade; Fälle mit Uneinigkeit oder geringer Sicherheit wurden zur weiteren Prüfung eskaliert

Vier Fehlertypen

• Die im Audit identifizierten Probleme lassen sich hauptsächlich in vier Kategorien einteilen
  • Übermäßig strenge Tests: Sie erzwingen bestimmte Implementierungsdetails, die im Prompt nicht genannt werden, und disqualifizieren damit funktional korrekte Einreichungen
  • Unterdefinierte Prompts: Sie lassen Anforderungen aus, die von versteckten Tests verlangt werden, aber vernünftigerweise kaum ableitbar sind
  • Tests mit geringer Abdeckung: Sie prüfen die angeforderte Funktionalität nicht ausreichend, sodass auch unvollständige Fixes bestehen können
  • Irreführende Prompts: Sie lenken das Modell zu falschem Verhalten oder widersprechen den Testanforderungen
• Bei einigen Aufgaben verlangte der Prompt eine bestimmte Implementierung, während versteckte Testfälle ein anderes Verhalten erwarteten

Unterschiede zwischen menschlicher und agentischer Prüfung

• Menschliche Prüfer markierten Aufgaben eher als fehlerhaft als der Untersuchungsagent
• Zwischen beiden Prüfpfaden gab es Unterschiede bei der Kategorisierung, aber unter den markierten Aufgaben war bei menschlichen Labels „nicht fehlerhaft“ nie das häufigste Label
• Die vom Agenten markierten Kategorien und die Einschätzungen menschlicher Prüfer überschnitten sich in 74 % der Fälle
• Menschliche Prüfer vergaben auch häufiger mehrere Labels für eine einzelne Aufgabe
  • Das ist ein Signal dafür, dass Aufgaben auf mehrere Arten fehlerhaft waren oder sich nicht sauber in eine einzelne Kategorie einordnen ließen
  • Eine Pipeline, die Agent und Prüfer gemeinsam nutzt, erfasste die von Menschen gefundenen breiten Fehlermuster, zählte zusätzliche oder überlappende Probleme jedoch konservativ eher seltener
• Der größte Unterschied zeigte sich bei Tests mit geringer Abdeckung
  • Menschen stuften dies bei 9,4 % des Benchmarks als häufigstes Problem ein
  • Die Agenten-Pipeline markierte 4,1 %

Warum der Aufbau von Benchmarks schwierig ist

• Die Beispiele von SWE-Bench Pro und SWE-bench Verified zeigen, dass Benchmarks streng validiert werden müssen
• Issues und Pull Requests in Open-Source-Repositories werden ursprünglich nicht für Modellevaluierung, sondern für menschliche Zusammenarbeit erstellt
• In Umgebungen mit vielen langen Rückkopplungsschleifen zwischen Maintainern und Beitragenden bilden Problembeschreibungen, gemergter Code und Unit-Tests nicht immer saubere und unabhängige Aufgaben für die Modellevaluierung
• In Pull Requests enthaltene Tests werden oft geschrieben, um eine bestimmte Änderung zu verifizieren, und können deshalb bestimmte Implementierungen erzwingen statt implementierungsunabhängiger Lösungskriterien

Künftige Richtung von Evaluierungen

• Mit steigenden Modellfähigkeiten lassen sich auch Fehler in Evaluierungen leichter finden als früher
• Verbesserte Modelle können Prompts, Tests, Patches, Ausführungsspuren und Grenzfälle tiefer und konsistenter prüfen und so Benchmark-Probleme aufdecken, die früher in großem Maßstab schwer auffindbar oder teuer waren
• OpenAI hofft, dass die breitere Evaluierungs-Community neue Benchmarks entwickelt, die von erfahrenen Softwareentwicklern gezielt zum Testen von Modellfähigkeiten erstellt werden
• Dieser Ansatz kann den angestrebten hohen Schwierigkeitsgrad und Realismus erhalten und zugleich über den gesamten Prozess hinweg bessere menschliche Aufsicht ermöglichen
• Wegen der in dieser Analyse sichtbar gewordenen Probleme zieht OpenAI seine frühere Empfehlung zur Übernahme von SWE-Bench Pro zurück
• Evaluierungen müssen schwer manipulierbar, leicht vertrauenswürdig und in der Lage sein, aussagekräftige Signale zu liefern, die die tatsächlichen Modellfähigkeiten oder den Alignment-Status widerspiegeln

[GN⁺]

Hacker-News-Kommentare

• Es braucht einen neuen Benchmark. Gut wäre ein Ansatz, der misst, wie viel ein Modell mit 100 Dollar API-Kosten über ein Benchmark-Bündel hinweg leisten kann.
  Man sollte Effizienz und Intelligenz zusammen messen. Kleine Modelle könnten Strategien nutzen wie das Testen von Ergebnissen über Computernutzung oder das längere Bearbeiten eines Problems mit Ausgabeverifikation, während große Modelle möglicherweise nicht genug Budget für eigene Tests haben, was zu interessanten taktischen Unterschieden führen könnte
  • Gemeint ist vermutlich der Benchmark Intelligence vs Cost von Artificial Analysis.
    https://artificialanalysis.ai/?cost=intelligence-vs-cost-per...
  • Das Problem ist, nach wessen Preisgestaltung gerechnet werden soll
  • Das ist die grundlegende Frage, und ich finde interessant, dass es auf der OpenAI-Website kein sauberes Dashboard gibt, das zeigt, wie sich diese Kennzahl über die einzelnen Releases verändert hat.
    Toby Ord hat mit öffentlichen Daten getan, was möglich war, aber das Ergebnis sieht nicht besonders gut aus.
    https://www.tobyord.com/writing/hourly-costs-for-ai-agents
• Bei Terminal Bench 2 gibt es aus verschiedenen Gründen ziemlich viele Fake-Ergebnisse. Ryan, Alex und andere hervorragende Teams haben zuletzt zwar viele verdächtige Einreichungen bereinigt, aber viele Labore haben Ergebnisse veröffentlicht, die durch Änderungen an Zeitlimits oder Hardware-Konfigurationen das umgehen, was bei bestimmten Aufgaben eigentlich gemessen werden soll.
  Dazu kommen Betrug auf Ebene des Execution-Harness, Reward Hacking durch Modelle und Ähnliches. Was mich auch nach Monaten noch stört, ist die offizielle Einreichung von gpt-5.5, insbesondere diese Aufgabe: https://www.tbench.ai/leaderboard/terminal-bench/2.0/codex/0...
  Das Zeitlimit der Aufgabe liegt laut https://github.com/harbor-framework/terminal-bench-2/blob/ma... bei 1200 Sekunden für den Verifier, 1200 Sekunden für den Agenten und 600 Sekunden für den Environment-Build, also sollte kein Agent über 3000 Sekunden kommen. In den 5 Versuchen unter dem obigen Link lagen jedoch 2 deutlich über 3000 Sekunden und dauerten 75 beziehungsweise 80 Minuten. Selbst wenn sie gescheitert sind, ist es verdächtig, dass sie so lange liefen. Ein Fall, in dem Goodharts Gesetz wirkt
  • Selbst wenn niemand nach einer bestimmten Definition „betrogen“ hat, steckt der Benchmark bereits irgendwo in einem riesigen strukturellen Gradient Descent. Modelle sind auf irgendeiner Ebene Maschinen zur Maximierung von Benchmark-Scores, daher wirkt der Benchmark selbst im Kern etwas nutzlos.
    Schon das Benchmarking von Menschen funktioniert nicht besonders gut. Programmierfähigkeit lässt sich einigermaßen zuverlässig nur durch direkte Interaktion messen. Wenn Modelle im Grunde Menschensimulatoren sind, dann ist es eher seltsam zu erwarten, dass Benchmarks dauerhaft nützlich bleiben, je genauer die Simulation wird. Das ist letztlich nur eine ausführlichere Version des oben genannten „Goodharts Gesetzes“, und es funktioniert wirklich wie ein Gesetz
• Im Kern läuft es wohl auf die Schlussfolgerung hinaus, dass Aufgaben für Softwareentwickler, egal ob Menschen oder Modelle, oft unvollständig oder widersprüchlich oder noch schlimmer sind. Dieses Werkzeug muss genau in so einer Welt funktionieren, daher habe ich wenig Mitleid
  • Stimme zu. Unzureichende Prompts als Versagen des Werkzeugs aufzulisten, ist wenig überzeugend. Selbst ein Praktikant versteht mit etwas Hilfe vage Anfragen und weiß, wann er innehalten und nachfragen sollte, statt einfach weiterzumachen. Oft kann er noch vor Ende des Praktikums ziemlich eigenständig mit mehrdeutigen Aufgaben umgehen.
    Heißt die Logik also, dass ein State-of-the-Art-Modell nicht einmal ein Junior Engineer ist, sondern ein Praktikant im ersten Monat, der dieses Niveau nicht übertreffen kann?
  • In echter Arbeit kann man fehlgeschlagene Testfälle ansehen und den Code korrigieren oder, was noch wahrscheinlicher ist, schlecht geschriebene Tests reparieren. Würde man aktuellen LLMs schon nur diesen ersten Schritt erlauben, würden sie bei genau diesem Benchmark überwältigend gut abschneiden.
    Interessant ist eher, wie LLMs bei solchen Benchmarks überhaupt über 70 % kommen oder manche miserabel formulierten Fragen richtig beantworten. Haben sie implizit den Stil der Tester gelernt? Ist die Lösung in die Trainingsdaten durchgesickert?
    Trotzdem ist es beruhigend, dass selbst Fable bei etwa 72 % auf einem versteckten Set stehen bleibt, auf dem OpenAI diese Analyse nicht ausgeführt hat. Es scheint also nicht so, als hätte es den Benchmark selbst gelernt, außer vielleicht auf sehr indirekte Weise.
    Kleine Open-Modelle können solche eigentümlichen Marotten niemals lernen, daher ist eine gute Methode zur fairen Beurteilung von Modellen wirklich wichtig. Zusätzlich verwässert OpenAI die Sache etwas: Nur etwa 20 % der Probleme sind in einer für Agenten unfairen Weise kaputt, und 4 bis 10 % sind in eine vorteilhafte Richtung kaputt, daher liegt die Benchmark-Obergrenze vermutlich eher bei 80–85 %
  • Der subtilere Kernpunkt ist die Lücke zwischen Aufgabe und Verifikation. Bei offenen oder unzureichend spezifizierten Prompts müsste der Verifier zum Beispiel alle möglichen Lösungen abdecken können.
    Deshalb sind sehr enge Aufgaben-Prompts leicht zu verifizieren, aber als Herausforderung womöglich zu simpel. Umgekehrt sind realistischere Aufgaben-Prompts viel schwerer zu verifizieren, und robuste Verifier zu bauen und günstig auszuführen ist ebenfalls schwierig
  • Ich hatte denselben Gedanken, und das gilt meiner Meinung nach besonders für unsichtbare Anforderungen, die anfangs nicht ausdrücklich genannt werden und nur in den Tests stecken. Man soll die Lösung also noch einmal überarbeiten, um Anforderungen zu erfüllen, die einem niemand gesagt hat? Das mache ich in der Praxis tatsächlich auch.
    Natürlich testet man damit etwas anderes als das, was der Benchmark behauptet, aber manchmal wird dadurch zufällig etwas getestet, das näher an der Realität ist als ein sauberer Benchmark, und das hat dann auf seine Weise auch Wert.
    Das gilt allerdings nur, wenn der Agent fehlgeschlagene Tests sehen und iterieren darf. Andernfalls ist es einfach ein Problem. Und noch schlechter ist es, wenn Tests Implementierungsdetails einer bestimmten Lösung fest verdrahten und damit irgendeine beliebige interne Struktur verlangen. So etwas kommt in der Realität nicht vor
• Den Zahlen hier nach zu urteilen scheint der gesamte Benchmark aus weniger als 800 Aufgaben zu bestehen. Das ist eine Größenordnung, die ein paar Engineers in einer Woche durchgehen könnten, und genau das hat OpenAI letztlich wohl getan

Einerseits ist es lobenswert, dass die Arbeit tatsächlich gemacht wurde. Andererseits ist es buchstäblich ein Fall von „garbage in, garbage out“. Es ist etwas peinlich, dass die ursprünglichen Autoren das nicht selbst überprüft haben, und ebenso peinlich, dass niemand downstream es überprüft hat. Aus dem Text geht außerdem hervor, dass das LLM zwar Probleme gefunden hat, aber dazu neigte, die von professionellen Softwareingenieuren gefundenen Probleme zu unterschätzen.

• Wenn man genauer hinschaut, sind Benchmarks meistens ziemlich schlecht
  Als Hintergrund: Um die vielen umständlichen Schritte zu ersetzen, die bei der Nutzung von Codex/Claude Code anfallen, optimiere ich iterativ einen Supervisor-Agenten und habe diesen Agenten kürzlich auf Terminal Bench 2.1 laufen lassen.
  Zunächst war ich erfreut, weil der spezifikationsbasierte Supervisor bei mehreren Aufgaben besser abschnitt als das Standard-Codex. Doch bei näherem Hinsehen stellte sich heraus, dass mit den Aufgaben selbst sehr viel nicht stimmte.
  Der Kern des Problems ist, dass die Anweisungen oft mehrdeutig sind, während die Testfälle übermäßig konkret sind. Bei configure-git-webserver verwischt zum Beispiel eine Formulierung wie „so that I can run“ die Grenze dessen, was der Agent bereitstellen und was er entfernen soll. Ein Agent, der zu viel nachdenkt, richtet den Server ein und entfernt dann die exakten Dateien, die der Validator prüft, weil er annimmt, dass es zu einem Konflikt kommen würde, wenn der Nutzer denselben Befehl ausführt.
  Bei make-mips-interpreter interpretiert der Supervisor wegen der Formulierung „I will check that you booted doom correctly“ dies so, dass der Nutzer nicht prüft, ob Doom unabhängig bootet, sondern das vom Agenten gestartete Ergebnis überprüft, und lässt deshalb das erzeugte /tmp/frame.bmp liegen. Der Validator bricht ab, wenn bereits ein /tmp/frame.bmp existiert, kann Doom also nicht starten und prüft auch nicht, ob die Datei während des Bootvorgangs neu erzeugt wird[0].
  Bei mcmc-sampling-stan kam der Supervisor-Agent oft auf den richtigen Wert, gab aber statt einfacher Dezimalzahlen eine domänenspezifische numerische Ausgabe in wissenschaftlicher Notation aus. Der Validator hat das Ergebnis falsch geparst und deshalb als Fehlschlag gewertet[1].
  Diese Inkonsistenzen sind nur einige Beispiele; deshalb halte ich Terminal Bench 2.1 bereits für gesättigt, und die Ergebnisse von GPT-5.6 und Mythos mit jeweils 88,8 % bzw. 88 % scheinen die erwartbare Obergrenze fast zu erreichen. Das größte Problem ist, dass die meisten Benchmarks einmalige Ausführungen sind und Modell+Harness in langen iterativen Abläufen, also in der hauptsächlichen realen Nutzungsweise solcher Tools, kaum testen.
  [0] https://github.com/harbor-framework/terminal-bench-2-1/issue...
  [1] https://github.com/harbor-framework/terminal-bench-2-1/issue...

• War nicht von Anfang an allen klar, dass SWE-Bench insgesamt fehlerhaft ist? Sogar die Autoren haben die Grenzen eingeräumt und sind längst zum nächsten Schritt übergegangen.

  • SWE-Bench Pro wurde geschaffen, um SWE-Bench zu ersetzen und diese Probleme zu beheben.

• Ich verstehe, warum das zu schlechten Benchmarks führen kann, aber wenn es darum geht, dass zu strenge Tests bestimmte Implementierungsdetails erzwingen, die im Prompt nicht explizit genannt werden, und dadurch funktional korrekte Einreichungen ungültig machen; dass unzureichende Prompts Anforderungen auslassen, die von versteckten Tests erzwungen werden, aber nicht vernünftig ableitbar sind; dass Tests mit geringer Abdeckung die angeforderte Funktionalität nur unzureichend prüfen, sodass unvollständige Fixes durchkommen; und dass irreführende Prompts Modelle zu falschem Verhalten verleiten oder mit den Testanforderungen kollidieren — dann ist das, wenn das Ziel der Vergleich realer Softwareingenieure mit Modellen ist, eine ziemlich realistische Situation.
  Es ist ein bisschen so, als würde man eine Krankenpflegeprüfung erstellen und dann einige Fragen markieren, weil man zusätzliche Informationen hätte beim zuständigen Arzt erfragen müssen, die nicht in der Akte standen, oder weil Angehörige die Krankengeschichte einer alten Großmutter nicht ausreichend erklärt haben. Man kann sich einen strengeren Benchmark wünschen, aber wenn OpenAI Modelle als Ersatz für echte Arbeitskräfte verspricht, ist das kein gutes Bild. Eigentlich sollte man genau solche Dinge testen wollen.

• Es liest sich wie: „Wir haben die ganze Arbeit gemacht, die nötig wäre, um den Benchmark zu reparieren, und haben dann beschlossen, ihn stattdessen wegzuwerfen.“ Ist die zugrunde liegende Datenbasis so wertvoll, dass man sie nicht patchen kann? Am Ende wird zwar für einen etwas selektiveren Ansatz bei der Benchmark-Erstellung plädiert, aber auch ein faires Patchen von unordentlichen, unvollständigen Tests aus realen Daten wirkt auf mich wie ein ziemlich solider Weg.

  • Für mich klingt es so, als gäbe es noch einen anderen Grund, sich von SWE Bench Pro abzuwenden, über den man nicht sprechen möchte. Ganz am Anfang des Textes heißt es, „etwa 30 % der Aufgaben waren kaputt“, aber das bedeutet auch, dass etwa 70 % nicht kaputt waren, und das klingt eigentlich ziemlich gut.
    Es wäre schön gewesen zu sagen: „Hier ist die Liste der defekten Instanzen“ oder „Das ist die Teilmenge von SWE Bench Pro, die wir künftig verwenden werden“. Man lässt Perfektion dem Guten im Weg stehen.
  • Auf Probleme hinzuweisen, etwa dass versteckte Tests enge Implementierungsdetails voraussetzen, ist viel einfacher, als Tests zu schreiben, die unabhängig von der jeweiligen Implementierungsentscheidung funktionieren.
  • Wenn man das repariert, ist es dann überhaupt noch SWE-Bench Pro? Es wäre dann wohl „SWE-Bench-Pro-Fixed-OpenAI“. Wenn man das Bild der Unabhängigkeit des Benchmarks bedenkt, scheint es besser, wenn eine dritte Partei die Korrekturen vornimmt und eine verbesserte Version veröffentlicht, statt dass das OpenAI-Team selbst sie direkt macht.
    Allerdings hat OpenAI bei SWE-Bench Verified genau so etwas bereits getan, also rede ich vielleicht Unsinn.

• Was gilt derzeit als State of the Art bei SWE-Benchmarks?

  • Je nach persönlichen Zielen und Anforderungen würde ich DeepSWE[0] oder FrontierCode[1] nennen. Letzteres finde ich persönlich interessanter, weil es stark darauf ausgelegt ist, die Mergeability zu bewerten — also ob die gelieferte Ausgabe leicht zu reviewen ist und ob ein ernsthafter Entwickler sie schnell verstehen und bereitwillig mergen würde.
    Nach meiner Auffassung und persönlichen Einschätzung schon seit geraumer Zeit ist der Wert begrenzt, wenn ich nicht wirklich bereit wäre, den Code abzuzeichnen, selbst wenn die potenzielle Obergrenze eines Modells höher sein mag.
    [0] https://deepswe.datacurve.ai/
    [1] https://cognition.com/blog/frontier-code-1.1
  • Insgesamt fand ich, dass DeepSWE[0] ziemlich gut mit der Realität übereinstimmt.
    [0]: https://deepswe.datacurve.ai/

• Es gibt https://cognition.ai/blog/frontier-code. Zur Offenlegung: Ich war in diesem Team, aber dort wurden auch swebench pro/deepswe-Probleme behandelt.

  • FrontierBench

• Das Erreichen von AGI müsste mehr sein als das Bestehen aller Benchmarks und auch unbekannte Probleme berücksichtigen.

  • Wenn es in einem Forschungslabor nicht gerade etwas gibt, das stark vom aktuellen Produkt abweicht, ist AGI kein sinnvolles Diskussionsthema und kommt reinem Marketing-Hype nahe.
  • AGI ist noch sehr weit entfernt. Es sei denn, es gibt irgendeinen mir unbekannten LLM-Marketingbegriff, der als „AGI“ bezeichnet wird. Künstliche allgemeine Intelligenz unterscheidet sich so stark von LLMs oder Bild-KI, dass ein Vergleich kaum möglich ist, abgesehen davon, dass alles künstliche Artefakte sind. AGI muss weit mehr leisten als Token-Vorhersage.
  • Das hängt mit dem bei Nicht-LLM-Modellen häufigen Bias-Variance-Trade-off(https://en.wikipedia.org/wiki/Bias%E2%80%93variance_tradeoff) zusammen.
    Die Lösung wäre nur, a) LLMs bei ähnlicher Leistung kleiner zu machen, damit sie nicht auswendig lernen oder gezielt Benchmarks optimieren können, oder b) Benchmarks zu erstellen, die die gesamten Daten der realen Welt abdecken; Letzteres ist jedoch nicht umsetzbar.