DeepSWE v1.1: Was ein Patch misst, der seinen Verifizierer besteht – und wann sein pass@1 nicht mehr zeigt, dass der Agent die Aufgabe gelöst hat

Die Kennzahl gehört nicht allein dem Modell

Ein DeepSWE-v1.1-Score beschreibt keine isolierte Eigenschaft eines Sprachmodells. Er beschreibt das Ergebnis einer vollständigen Versuchskonfiguration: ein von einem Anbieter bereitgestelltes Modell, gegebenenfalls ein Niveau für den Reasoning-Aufwand, ein Agent-Harness, ein Werkzeugsatz, Kontext- und Zeitlimits, Anweisungen, eine Abbruchpolitik und ein Bewertungssystem. Die beobachtete Einheit ist der von dieser Konfiguration für eine konkrete Aufgabe commitete Patch – nicht eine Textantwort des Modells und auch keine allgemeine, außerhalb dieser Umgebung gemessene Fähigkeit.

Diese Unterscheidung ist besonders wichtig beim Lesen des DeepSWE-Leaderboards. Die offizielle Seite erklärt, dass die Modelle für Konsistenz mit mini-SWE-agent ausgeführt werden. Diese Entscheidung beseitigt jedoch nicht sämtliche Variablen. Dieselbe Modellfamilie kann mit unterschiedlichen Reasoning-Stufen oder Anbietern erscheinen; zudem kann ein Update des Harness, des Prompts, der Werkzeuge oder der Infrastruktur das Resultat verändern, obwohl das zugrunde liegende Modell unverändert ist. Ein direkter Vergleich setzt deshalb voraus, dass beide Zeilen gleichwertige Bedingungen und dieselbe Bewertungsversion verwenden.

Auch der Begriff pass@1 darf nicht als Garantie gelesen werden, dass ein Agent den nächsten Fehler im eigenen Repository lösen wird. Im Methodenpapier zu DeepSWE wird pass@1 als Durchschnitt der Erfolgsrate je Aufgabe über die Ausführungen definiert. Es handelt sich um eine Aggregation der in dieser Sammlung und unter diesem Protokoll beobachteten Leistung. Sie fasst Versuchsergebnisse zusammen, erklärt aber für sich allein weder die Ursache einzelner Erfolge oder Fehlschläge noch einer Differenz zwischen Konfigurationen.

Was DeepSWE messen soll

DeepSWE wird als Benchmark für Software-Engineering-Agenten vorgestellt, die an originären Aufgaben mit langem Bearbeitungshorizont arbeiten. Die Dokumentation der Autoren beschreibt 113 Aufgaben in 91 Repositories. Jede Aufgabe verbindet einen Repository-Kontext mit einer Änderungsanforderung und programmatischen Mechanismen zur Prüfung des erwarteten Verhaltens. Das Ziel ist nicht, eine bereits veröffentlichte Korrektur wiederzufinden, sondern eine neue Lösung für die gestellte Aufgabe zu erzeugen.

Nach Darstellung von Datacurve wurden die Referenzlösungen von Grund auf geschrieben und weder aus einem bestehenden Pull Request, Commit noch aus einem öffentlichen Patch kopiert oder angepasst. Manche Aufgaben können durch ungelöste Probleme motiviert sein, doch diese Motivation bedeutet nicht, dass es eine als Referenz nutzbare Upstream-Lösung gibt. Dies ist eine Designbehauptung der Ersteller. Sie ist relevant, weil sie Überschneidungen mit Benchmarks aus historischen Issues verringern soll; sie genügt jedoch nicht allein, um das Fehlen von Kontamination in Trainingsdaten oder externen Werkzeugen nachzuweisen.

Das öffentliche Format des offiziellen Repositorys ist für Audits nützlich, weil es Komponenten wie Metadaten, Prompt, Dockerfile, Tests oder Verifizierer und Referenzlösung dokumentiert. Dadurch lässt sich eine einzelne Aufgabe prüfen, statt ihre Schwierigkeit aus dem Namen des Repositorys abzuleiten. Die Verfügbarkeit von Artefakten macht allerdings nicht automatisch jede Schlussfolgerung reproduzierbar: Um eine Zeile zu wiederholen, benötigt man auch den verwendeten Commit, die tatsächlich eingesetzten Images oder Abhängigkeiten, Zugangsdaten und Werkzeugversionen sowie die einschlägigen Ausführungsprotokolle.

Der Patch, der saubere Container und der Verifizierer

Für v1.1 beschreibt Datacurve ein Verfahren, bei dem ausschließlich der commitete Patch in einem getrennten, sauberen Verifikationscontainer bewertet wird. Das offizielle Repository dokumentiert seit dieser Version ebenfalls, dass der Commit als Patch extrahiert und in einer unberührten Umgebung angewandt wird. Dieses Design soll das Endergebnis von vorübergehenden Effekten während der Agententrajektorie trennen, etwa von nicht committeten Änderungen oder Manipulationen des Testprozesses in seiner Arbeitsumgebung.

Die v1.1-Dokumentation erklärt, dass der CTRF-Bericht jeden aufgabendefinierenden Test namentlich erfasst. Nach diesem Ansatz sollten das Entfernen von Tests oder ein erzwungener vorzeitiger Abbruch als fehlende oder fehlgeschlagene Ergebnisse erscheinen und nicht als Bestehen. Außerdem werden Änderungen zur Korrektur von Dependency Drift und instabilen Tests beschrieben. Das sind nachvollziehbare Verbesserungen mit Blick auf die Bewertung eines übertragbaren Patches, doch sie sind als Implementierungsentscheidungen des Benchmarks zu lesen: Jedes Bewertungssystem enthält Annahmen darüber, welche Dateien wiederhergestellt werden, welche Befehle laufen und welche Evidenz als Ergebnis zählt.

Die Trennung zwischen Agentencontainer und Verifikationscontainer hat eine praktische Folge. Ein Patch kann während einer bestimmten Trajektorie funktionieren und beim sauberen erneuten Anwenden scheitern; in diesem Fall drückt ein Fehlschlag nach dem Protokoll eine mangelnde Reproduzierbarkeit der finalen Änderung aus. Umgekehrt kann eine Änderung, die die Absicht der Aufgabe erfüllt, scheitern, wenn die Wiederherstellung oder Ersetzung von Dateien oder die Erkennung von Ergebnissen das zu prüfende Verhalten beeinträchtigt. Beide Fälle auseinanderzuhalten erfordert ausreichend erhaltene Artefakte, um das Urteil zu überprüfen.

Was pass@1 und pass@4 bewerten – und was offengelegt werden muss

Das DeepSWE-Paper definiert pass@1 als Mittelwert der Erfolgsrate je Aufgabe und pass@4 als Anteil der Aufgaben, die in mindestens einem von vier Versuchen gelöst werden. Der Unterschied ist wichtig: pass@1 beschreibt die Leistung eines einzelnen Versuchs unter der verwendeten Ausführungsverteilung; pass@4 zeigt den Vorteil mehrerer Versuche. Die Kennzahlen sind nicht austauschbar, und eine Rangfolge nach einer von ihnen kann Konfigurationen anders ordnen als eine Rangfolge nach der anderen.

Die Autoren dokumentieren ungefähr vier Rollouts je Aufgabe sowie Konfidenzintervalle von 95 %. Solche Intervalle helfen, kleine Abstände nicht überzuinterpretieren, insbesondere wenn nahe Konfigurationen überlappen. Ein Intervall behebt jedoch keine methodische Unvereinbarkeit. Wenn zwei Ergebnisse aus unterschiedlichen Verifizierern, Wiederholungsrichtlinien, Ausführungsfristen oder Ausschlusskriterien stammen, löst ihre statistische Unsicherheit nicht die Veränderung des gemessenen Gegenstands.

Ein verantwortungsvoller Ergebnisdatensatz sollte mindestens die DeepSWE-Version, Modell und Anbieter, die mini-SWE-agent-Version, die Reasoning-Stufe, die Anzahl der Rollouts, die Abbruchpolitik, Zeit- und Kontextlimits, Datum oder Version der Infrastruktur sowie die Behandlung von Fehlern ausweisen. Er sollte außerdem den berechneten Score von ausgeschlossenen Fällen trennen. Ohne diese Angaben lässt sich nicht feststellen, ob eine Differenz auf Problemlösefähigkeit, Serviceverfügbarkeit, Budgetentscheidungen oder Änderungen des Evaluators zurückgeht.

Als Fehler zählende Ausfälle, ausgeschlossene Fehler und Selektionsverzerrung

Die von den Autoren veröffentlichte Methodik besagt, dass Timeouts als Fehlschläge zählen. Sie weist außerdem darauf hin, dass Anbieter-, Netzwerk- oder Verifiziererfehler ausgeschlossen werden können. Diese Unterscheidung ist operativ sinnvoll: Eine Unterbrechung außerhalb des Agenten entspricht nicht zwangsläufig einer Unfähigkeit, das Problem zu lösen. Der Ausschluss schafft jedoch eine Transparenzpflicht, denn die Klassifikation eines Ereignisses bestimmt, welcher Nenner im veröffentlichten Score verwendet wird.

Ein Timeout kann eine reale Beschränkung des Systems offenlegen, das eingesetzt werden soll, selbst wenn er keine semantische Beschränkung des Modells offenlegt. Eine nützliche Bewertung sollte deshalb sowohl die Hauptquote nach ihren Regeln als auch Anzahl und Art ausgeschlossener Ausführungen zeigen, zusätzlich zu den Artefakten, die jede Entscheidung begründen. Würde etwa ein reproduzierbarer Fehler bei der Aufgabenvorbereitung pauschal unter „Infrastruktur“ zusammengefasst, könnten Dritte nicht beurteilen, ob es sich um einen Benchmark-Defekt oder eine außergewöhnliche Umgebungsbedingung handelt.

Ebenso sollte gefragt werden, ob ein Ausschluss vor der Inspektion des Patches entschieden wird und ob dieselbe Regel für alle Modelle gilt. Eine rückwirkende oder unzureichend dokumentierte Politik kann unbeabsichtigt eine Konfiguration begünstigen. Die hier vorliegenden Quellen liefern keine Evidenz dafür, dass dies bei DeepSWE geschieht; es handelt sich um eine Auditbedingung, die geprüft werden sollte, bevor der Score für Beschaffung, Anbieterauswahl oder Einsatzentscheidungen verwendet wird.

Warum v1 und v1.1 nicht ohne erneute Ausführung vermischt werden sollten

Datacurve erklärt, dass v1.1 dieselben Aufgaben beibehält, aber Ausführung und Bewertung verändert. Zu den beschriebenen Änderungen gehören die Verifikation des committeten Patches in einem sauberen Container, die CTRF-Erfassung sowie Korrekturen in Bezug auf Abhängigkeitsdrift und instabile Tests. Selbst wenn die Menge der Aufgabenstellungen gleich bleibt, kann eine Änderung der Bewertungsumgebung beeinflussen, welche Patches bestehen und welche scheitern.

Deshalb darf ein Wert aus v1 und ein Wert aus v1.1 nicht ohne deutlichen Hinweis als Punkte derselben Zeitreihe behandelt werden. Es wäre nicht zulässig, jede Differenz einer Modellverbesserung oder -verschlechterung zuzuschreiben, wenn sich zugleich die Art der Rekonstruktion der Umgebung oder der Testprüfung verändert hat. Der solideste Weg zum Versionsvergleich besteht darin, dieselbe Konfiguration mit jedem Protokoll erneut auszuführen und die Ergebnisse je Aufgabe zusammen mit den geänderten Urteilen zu veröffentlichen.

Dieselbe Vorsicht gilt für Vergleiche innerhalb von v1.1, wenn das Leaderboard fortentwickelt wird. Eine öffentliche Tabelle ist ein wertvolles Protokoll deklarierter Ausführungen, aber kein hinreichender Nachweis historischer Gleichwertigkeit. Wer eine Entscheidung mit hohen Auswirkungen treffen muss, sollte einen Commit des Benchmarks und des Harness einfrieren, Container-Images erhalten und eine kontrollierte Matrix von Konfigurationen ausführen.

Der Konflikt um Teständerungen

Die unabhängige Überprüfung von Epoch AI benennt eine konkrete Einschränkung von DeepSWE v1.1. Nach dieser Überprüfung bestätigten deren Autoren manuell mindestens 23 falsch negative Befunde unter den 113 Aufgaben. Sie erklären, dass 18 dieser Fälle mit Agenten zusammenhängen, die bestehende Tests verändern, und mit einer nachfolgenden Vorbereitung des Verifizierers, welche Dateien wiederherstellt oder ersetzt. Der angeführte Befund lautet, dass ein Agent eine für die Aufgabenabsicht funktional korrekte Änderung erzeugt haben kann und dennoch aufgrund der Wechselwirkung zwischen Patch und Bewertungsprotokoll scheitert.

Dieser Befund muss Epoch AI zugeschrieben und in seinem erklärten Umfang gelesen werden. Die Überprüfung gibt an, nach Überschreiten ihrer Schwelle zur Einstufung des Benchmarks als fehlerhaft gestoppt zu haben; sie liefert daher weder eine abschließende Schätzung der gesamten Rate falsch negativer Befunde noch den Nachweis, dass jedes DeepSWE-Ergebnis ungültig ist. Aus dieser Zahl allein lässt sich auch nicht ableiten, wie stark sich die Leaderboard-Positionen ändern würden: Dazu müssten die betroffenen Fälle mit einer korrigierten Version erneut ausgeführt und die Neuzuordnung der Urteile je Konfiguration veröffentlicht werden.

Zugleich besteht ein echter Zielkonflikt. Der Evaluator will verhindern, dass ein Agent durch die Veränderung der Aufgabentests ein Bestehen erreicht. Eine Regel, die Dateien wiederherstellt oder ersetzt, muss jedoch zwischen einer Manipulation zur Umgehung der Prüfung und einer Teständerung unterscheiden, die Teil einer legitimen Änderung ist oder unerwartet mit dem Verifizierer interagiert. Die offizielle v1.1-Dokumentation erklärt, dass der Testbericht fehlende Ergebnisse und frühe Abbrüche erkennt. Das Audit legt nahe, dass diese Schutzmaßnahme nicht alle identifizierten falsch negativen Befunde verhindert. Mit den verfügbaren Quellen beschreiben beide Aussagen unterschiedliche Ebenen: das beabsichtigte Design und eine Menge im Review beobachteter Verhaltensweisen.

Was ein hoher Score erkennen lässt

Ein hoher DeepSWE-v1.1-Score ist Evidenz dafür, dass eine konkrete Konfiguration Patches erzeugen konnte, die das Protokoll in einer Sammlung originärer Software-Engineering-Aufgaben akzeptierte. Wenn das Ergebnis von Artefakten und reproduzierbaren Bedingungen begleitet wird, bietet es ein nützliches Signal für die Vorauswahl von Agenten für autonome Reparatur- und Entwicklungsaufgaben mit Repositories, Befehlen und Tests.

Das Signal ist aussagekräftiger als eine Bewertung, die auf isolierte Codefragmente begrenzt ist, weil es Navigation in einem Repository, Änderungen in mehreren Dateien, Werkzeugnutzung und eine funktionale Verifikation umfasst. Es kann auch helfen, praktische Unterschiede zwischen Konfigurationen zu erkennen, die in stärker gesättigten Benchmarks ähnlich wirken. Sein Wert ist jedoch bedingt: Er hängt davon ab, dass Aufgabenpopulation, Harness-Beschränkungen und Verifizierer dem Anwendungsfall ähneln, über den entschieden werden soll.

Die vorsichtige Schlussfolgerung lautet nicht, der Agent „kann Software in Produktion warten“, sondern: Er hat eine gemessene Fähigkeit gezeigt, einen Teil der Aufgaben dieses Benchmarks unter einem festgelegten Protokoll zu lösen. Diese Formulierung bewahrt nützliche Information und vermeidet, ein Versuchsergebnis auf Bereiche zu übertragen, die DeepSWE nicht unmittelbar beobachtet.

Was der Score nicht erkennen lässt – und wie eine Leaderboard-Zeile zu lesen ist

Der Benchmark belegt für sich allein weder Zuverlässigkeit im eigenen Repository noch die Sicherheit von Änderungen, die Qualität einer Designprüfung, die Vereinbarkeit mit internen Richtlinien oder die Fähigkeit, mit der Produktion verbundene Systeme zu debuggen. Auch die Betriebskosten misst er nicht vollständig: Ein vergleichbarer Score kann unterschiedliche Tokenmengen, Wall-Clock-Zeit, Wiederholungen oder menschliche Aufsicht erfordern. Unternehmensautonomie verlangt darüber hinaus Berechtigungen, Isolierung, Abhängigkeitskontrolle, Review, Observability und Rückrollverfahren.

Eine Zeile beweist auch nicht, dass der Agent keine Lösung gefunden hat, die eine Lücke des Verifizierers ausnutzt, und ebenso wenig, dass jeder Fehlschlag eine Unfähigkeit zur Erfüllung der Anforderung darstellt. Die Überprüfung von Epoch AI macht diesen zweiten Vorbehalt in den von ihr untersuchten Fällen besonders relevant. Umgekehrt erlaubt ein teilweises Audit falsch negativer Befunde nicht den Schluss, dass der Benchmark wertlos sei. Die richtige Einordnung lautet, dass Messfehler und die Abweichung zwischen Absicht und Urteil Teil der Risikoanalyse sein müssen.

Um Grok 4.6, DeepSeek V4.1 Flash oder andere Systeme in DeepSWE zu vergleichen, sollte ein technischer Einkäufer zunächst Zeilen nach gleicher Version, gleichem Harness und gleichwertigen Inferenzbedingungen filtern. Danach sollten Intervalle, ausgeschlossene Fehler und Artefakte von Grenzfällen geprüft werden. Abschließend sollte die Vorauswahl durch eine interne Bewertung in repräsentativen Repositories ergänzt werden, mit Sicherheitsrichtlinien und Kosten, die dem vorgesehenen Einsatz nahekommen. DeepSWE kann ein Input für diese Entscheidung sein, nicht ihr Ersatz.

Weiter entdecken

Korrekturen und Transparenz

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