Senior SWE-Bench: Open-Source-Benchmark zur Bewertung von Agents auf Senior-Engineer-Niveau

 (senior-swe-bench.snorkel.ai)
3 Punkte von GN⁺ 4 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Senior SWE-Bench ist ein Benchmark, der Coding Agents nicht anhand übermäßig aufbereiteter Junior-Aufgaben bewertet, sondern näher an Feature-Entwicklung, Bugfixes und Performance-Problemen, wie sie echte Senior Engineers bearbeiten
  • Feature-Aufgaben verwenden realistische Anweisungen, die sich wie natürlichsprachliche Nachrichten lesen; ein Validation Agent, der passend zur eingereichten Lösung Verhaltenstests erstellt, erhöht die Zuverlässigkeit der Bewertung
  • Bug-Aufgaben stammen aus PRs, die mit User Reports beginnen und Runtime-Untersuchungen wie das Starten von Services, Logs, Profiling-Daten und Reproduktionsschritte erfordern
  • Die Bewertung kombiniert neben Runtime-Korrektheit auch Qualitätsmetriken auf Basis der Gepflogenheiten der Codebase, um einen tasteful solve zu bewerten; auch wichtige Konventionen, die nicht in den Anweisungen stehen, können geprüft werden
  • Selbst das Spitzenmodell im Leaderboard, Claude Opus 4.8, erreicht mit der Mini-SWE-Agent-max-Konfiguration nur pass@1 24,0 %; selbst Topmodelle scheitern also in über 75 % der Fälle an Lösungen mit Senior-Niveau bei Korrektheit und Taste

Aufgabendesign nahe an echten PRs

  • Senior SWE-Bench ist ein Benchmark, der die Lücke verringern soll zwischen dem Einsatz von Coding Agents, die in der Praxis wie Senior Engineers genutzt werden, und Bewertungen, die eher Junior-Aufgaben entsprechen
  • Die Aufgaben stammen aus PRs mehrerer Repositories, von Libraries bis hin zu Multi-Service-Anwendungen, und beziehen sich auf PRs von Engineers, die im jeweiligen Repository Hunderte Commits erstellt haben
  • Die wichtigsten Aufgabentypen teilen sich in zwei Gruppen
    • Feature-PRs über mehrere Schritte und mehrere Stacks hinweg
    • Bug- und Performance-PRs, die erhebliche Runtime-Untersuchungen erforderten
  • Öffentlich verfügbar sind 50 Aufgaben, außerdem gibt es 50 private Aufgaben
  • Beispiele für enthaltene Repositories:

Feature-Aufgaben: Anweisungen nah an natürlicher Sprache

  • Feature-Aufgaben verwenden statt übermäßig kleinteiliger Anforderungen realistische Anweisungen, die sich wie natürlichsprachliche Nachrichten lesen
  • Um solche Aufgaben zuverlässig zu bewerten, wird ein Validation Agent eingeführt
    • Er nutzt ein von Experten entworfenes Rezept
    • Er schreibt passend zur eingereichten Lösung Verhaltenstests
  • Die Anweisungen spiegeln natürliche Kommunikation mit Agents wider; ihre mediane Länge liegt bei 31 % von SWE-Bench Pro

Bug-Aufgaben: vom User Report bis zur Runtime-Untersuchung

  • Bug-Aufgaben spiegeln anspruchsvolle User Reports wider und verlangen stärker Ursachenanalyse und Reproduktion als eine bloße Codeänderung
  • Die Aufgaben können unter anderem Folgendes umfassen
    • Starten von Services
    • Debugging subtiler Runtime-Probleme
    • Prüfen von Logs
    • Nutzung von Profiling-Daten
    • Nachverfolgen von Reproduktionsschritten
  • Die Quellen sind PRs, bei deren Lösung erhebliche Runtime-Untersuchungen nötig waren

Bewertungskriterien: Korrektheit und Taste gemeinsam messen

  • Senior SWE-Bench kombiniert Runtime-Korrektheitstests mit mehreren Qualitätsmetriken, um einen tasteful solve zu bewerten
  • Die Qualitätsmetriken basieren auf beobachteten Gepflogenheiten der Codebase
  • Verifier und Validation Agent können auch wichtige Gepflogenheiten der Codebase testen, selbst wenn diese nicht in den Anweisungen erwähnt wurden
  • Die Solve-Bedingungen des Leaderboards umfassen folgende Punkte
    • Verifiers pass
    • Validation pass
    • Rubric > 0.5
    • Bloat < 2×
    • Practice > 2/5
    • Rel. taste > 2/5

Leaderboard: Auch das beste Modell hat niedrige pass@1-Werte

  • Das Leaderboard zeigt Ergebnisse nach Tasteful solve rate (pass@1)
  • Die Top-Ergebnisse lauten:
    • Claude Opus 4.8, Mini-SWE-Agent max: 24,0 %
    • Claude Sonnet 5, Mini-SWE-Agent max: 19,4 %
    • GPT-5.5, Mini-SWE-Agent xhigh: 16,0 %
    • Claude Opus 4.7, Mini-SWE-Agent max: 14,1 %
    • GPT-5.4, Mini-SWE-Agent xhigh: 14,0 %
    • GLM-5.2, Mini-SWE-Agent max: 12,5 %
    • Kimi K2.6, Mini-SWE-Agent default: 8,2 %
    • Claude Sonnet 4.6, Mini-SWE-Agent high: 8,2 %
    • Gemini 3.1 Pro, Mini-SWE-Agent high: 6,1 %
    • Gemini 3.5 Flash, Mini-SWE-Agent medium: 3,0 %
  • Selbst die stärksten Frontier-Modelle schaffen über 75 % der Aufgaben mit Senior-Niveau bei Korrektheit und Taste nicht

Aufgabenumfang und Benchmark-Eigenschaften

  • Aufgabentypen werden als feature, bug, perf, migrat gekennzeichnet
  • Die Stacks umfassen Py Svc, Elixir, Go, SQL, TS Lib, Py Lib, Rust, TS FE und weitere
  • Feature-Aufgaben können sich über mehrere Services erstrecken und ändern im Schnitt 11 Dateien pro Aufgabe
  • Sie sind für lange Arbeitsabläufe ausgelegt, sodass selbst die stärksten Agents Hunderte Schritte benötigen
  • SLOC und Dateianzahl der Referenzlösungen werden in den drei Benchmarks auf dieselbe Weise gemessen
  • Die Länge der Anweisungen schließt Harness-Boilerplate aus
  • Token- und Schrittzahlen anderer Benchmarks basieren auf den von den jeweiligen Benchmarks selbst berichteten Metriken

Verwandte Beiträge

1 Kommentare

 
GN⁺ 4 시간 전
Hacker-News-Kommentare

  • Soweit ich auf Twitter gesehen habe, gab es in einem Machine-Learning-Kurs an der Tsinghua University eine Prüfung, bei der Studierende Quizfragen erstellen sollten, an denen möglichst viele LLMs scheitern
    Ich frage mich, ob man aus so etwas nicht einen Benchmark bauen und ELO-Werte vergeben könnte. Die Modelle würden gegeneinander antreten, indem sie Fragen, Bugs und unvollständige Implementierungen vorlegen und die Gegenseite antworten, beheben oder fertigstellen muss

    • Das könnte man dann ein Generative Adversarial Network (GAN) nennen :)
      https://en.wikipedia.org/wiki/Generative_adversarial_network
    • Die Frage ist, wie man Degenerationsstrategien verhindert. Man könnte zum Beispiel einfach einen SHA256-Hash vorgeben und verlangen, die ursprüngliche Eingabe zu erraten — so lassen sich allzu leicht unlösbare Probleme erzeugen
      Im Kurs könnte man als Regel festlegen, dass wenigstens ein LLM die Antwort finden können muss, aber ich weiß nicht, wie man das in einem Eins-gegen-eins-Duell lösen sollte
    • Ich glaube, das war nicht Tsinghua, sondern Fudan

  • Ich frage mich, wie dieser Benchmark auf Dauer relevant bleiben soll
    Wenn der Benchmark aus Feature-Implementierungen in Open-Source-Projekten besteht, könnten LLMs diese Änderungen bereits in ihren Trainingsdaten haben und die Antwort unverändert oder leicht abgewandelt ausgeben
    Wenn man umgekehrt nur Codeänderungen nach dem Knowledge Cutoff eines Modells in den Benchmark aufnimmt, unterscheiden sich die Probleme zu Zeitpunkt T und T+1, sodass Vergleiche über die Zeit schlechter möglich sind

  • Bei einem Staff SWE Bench würde das LLM wohl erst einmal infrage stellen, ob es das überhaupt tun sollte, das ganze Projekt problematisieren, Merges ablehnen, aber Löschungen gern durchführen

    • Klingt wie ein Witz, aber ich halte Ablehnung tatsächlich für einen Kern der Arbeit. Nicht einfach nur „nein, weg damit“, sondern einen Schritt zurückzutreten, das große Ganze einzufordern und zu prüfen, ob die Organisation dieses Projekt langfristig wirklich braucht und tragen kann — das ist fast schon ein Mindestschritt, bevor man überhaupt anfängt
      Ein LLM könnte das durchaus, vielleicht sogar besser als wir, aber dafür müsste es separat trainiert werden. Mir fällt nur nicht ein, woher man solche Trainingsdaten nehmen sollte
    • Die Principal-Version ist ähnlich, sagt aber zusätzlich, der einzig zulässige Ansatz sei die Methode aus der vorherigen Firma

  • Das erklärt also, warum ich immer das Gefühl hatte, dass Opus 4.8 GPT 5.5 deutlich voraus ist. Es ist wirklich gut darin, unvollständige Anforderungen zu nehmen und die Lücken auf eine vernünftige, zum Projekt passende Weise zu füllen

    • Ich verstehe schon nicht, warum man überhaupt unvollständige Anforderungen vorgibt. Beide Modelle sind gut darin, Annahmen und Edge Cases zu hinterfragen und Rückfragen zur Klärung zu stellen, aber anscheinend nur dann, wenn man sie ausdrücklich darum bittet, etwa mit einer Technik wie „Brainstorming“
      Ich finde, beide Bewertungsansätze animieren die Modelle nicht stark genug dazu, wirklich alle Annahmen zu hinterfragen und Fragen zu stellen. Vielleicht, weil Nutzer das lästig finden, aber ich halte diesen Schritt für fast unverzichtbar
      Die GPT-5-Familie ist insgesamt sehr gründlich, was sie für Code Review und Mathematik nützlich macht. Für meine Arbeit ist das wichtig, scheint aber bei „ästhetischem“ Code eher hinderlich zu sein — etwa wenn jedes noch so unwahrscheinliche Edge Case abgesichert werden soll
      Es scheint auch einen Trade-off zwischen Flexibilität und Befolgen von Anweisungen zu geben. Nach meiner Erfahrung ignoriert Opus manchmal Anweisungen, füllt dafür aber Lücken besser aus, während GPT-5.5 Anweisungen besser befolgt, dadurch jedoch starrer wirkt
    • Der beste Benchmark ist ein selbst gebauter Benchmark
      Meiner Erfahrung nach war Opus weder haushoch überlegen noch generell besser. Außerdem gibt es bei GPT 5.5 Instant, Medium, High, Extra High und Pro; in der Tabelle scheint mit Extra High verglichen zu werden, also müsste man dann nicht mit Pro vergleichen?
    • Vielleicht lebe ich in einer seltsamen Bubble, aber für mich ist GPT 5.5 viel besser als Opus 4.8. Ich frage mich wirklich, wie du bewertest und woran du arbeitest
      Es gibt bestimmte Aufgaben, etwa Frontend-Entwicklung und Design, in denen Opus besser ist, aber sonst dominiert 5.5 einfach
    • Für Vibe-Coder, die immer weniger explizit sind, könnte das besser sein. Die Frage ist nur, ab welchem Punkt das Modell entscheidet, dass „die Anforderungen weniger explizit sind“, und dann Implementierungen liefert, die über eine eigentlich ausreichend spezifizierte Vorgabe hinausgehen
    • Ich habe dieselbe Beobachtung gemacht. Opus 4.8 wirkte viel reifer und hat bei fragwürdigen Anforderungen nachgehakt oder widersprochen. GPT 5.5 hingegen stimmt bereitwillig zu und macht einfach, was man sagt, braucht dafür aber oft mehrere Anläufe
      Auch 4.8 braucht manchmal mehr als einen Prompt, aber die Qualität der Ausgabe ist deutlich höher und liefert mehr Einsichten
      Fable 5 ist allerdings noch einmal eine ganz andere Hausnummer

  • Die aktuelle beste Erfolgsquote liegt bei 24 % mit Opus 4.8 — welche Punktzahl sollte dann ein kompetenter Mensch ungefähr erreichen?

    • Vermutlich mehr, denn ein Mensch könnte ja auch das nutzen, was das beste Modell verwendet
      Umgekehrt frage ich mich, ob ein Modell eine noch höhere Punktzahl erreichen würde, wenn es Menschen nach Belieben steuern könnte
    • Wenn man annimmt, dass diese Probleme alle bereits einmal gelöst wurden, dann wohl 100 %. Natürlich hat nicht dieselbe Person sie alle gelöst, aber während ein Modell in vielen unterschiedlichen Codebases gut sein muss, kann ein Mensch sich auf ein Produkt spezialisieren und dazulernen
      Den Vergleich mit einer Person, die in der Produktarbeit erfahren ist, halte ich für fair
      Mich interessiert eher, wie Fable abschneiden wird

  • Der Wert einer Senior-Rolle liegt darin, bekannte Lösungen und Strategien auf neue Probleme anzuwenden. Ich weiß nicht, ob ein Benchmark, der sich nie verändert, lange eine neue Herausforderung bleiben kann
    Ein brauchbarer Benchmark müsste erst mit dem gesamten TRIZ einen riesigen Problemraum erzeugen und dann prüfen, ob die AI die optimale Lösung herleitet

  • Schön, dass es von Snorkel einen neuen öffentlichen Benchmark gibt. Dort macht man ziemlich ausgefeilte Arbeit

  • Interessant ist, dass Sonnet 5 ziemlich nah an Opus 4.8 herankommt

  • Wenn so etwas funktioniert, heißt das dann nicht, dass man auch technische Interviews automatisieren könnte?

  • Ein Ansatz, bei dem man das LLM mit etwas wie „You are a senior SWE-Bench reviewer, make no mistakes.“ zu subjektiven Urteilen bringen will, wirkt grundsätzlich fehlerhaft
    Ich weiß allerdings nicht, was bei vertretbarem Aufwand ein besserer Ansatz wäre

    • Noch wichtiger ist, dass das die Arbeit real behindern kann. Wenn ein LLM Fehler macht, könnte es eher dazu verleitet werden, sie kleinzureden und weiterzugehen, statt sie einzugestehen und zu korrigieren
    • Im Grunde pflanzt man dem LLM damit Kontext dafür ein, wie es sich verhalten soll. „senior reviewer“ ist der gewünschte Antwortstil, „SWE-Bench“ der Kontext und die Domäne, in der das LLM arbeiten soll
      Das ist in System Prompts üblich und rahmt die Antwort ein
      Wenn man zum Beispiel sagt „ein Pirat, der ein Shanty über Programmierung schreibt“, „ein Nachrichtenreporter, der einen Artikel über Physik schreibt“ oder „ein Senior-Software-Ingenieur, der PostgreSQL perfekt kennt“, bekommt man jeweils andere Antworten
      Im ersten Fall käme vielleicht etwas im Stil von Wellerman heraus, etwa „There once was a program that was set to C ...“
      Der Teil „make no mistakes“ erscheint mir allerdings fragwürdig. Es wäre interessant, die Ergebnisse mit und ohne diese Formulierung zu vergleichen und auch andere Wege zu testen, um dasselbe gewünschte Verhalten zu erreichen
    • Die Ermahnung „make no mistakes“ wirkt ziemlich lächerlich. Auf YouTube wurde das auch schon oft verspottet, aber man kann sich leicht vorstellen, wie es trotzdem funktionieren könnte. Vielleicht wird es schlicht als „überprüfe die Arbeit“ interpretiert
      Es scheint nur niemand zu geben, der solche Vergleichsmessungen öffentlich durchführt und damit zu einer vernünftigen Schlussfolgerung beiträgt