23 de febrer del 2026

Per què SWE-bench Verified ja no mesura les capacitats d'avantguarda en programació

SWE-bench Verified està cada cop més contaminat. Recomanem SWE-bench Pro.

S'està carregant…

Des que vam publicar per primera vegada SWE-bench Verified l’agost de 2024, el sector l’ha utilitzat àmpliament per mesurar el progrés dels models en tasques autònomes d’enginyeria de programari. Després del seu llançament, SWE-bench Verified va proporcionar un senyal sòlid del progrés en capacitats i es va convertir en una mètrica estàndard reportada en els llançaments de models d’avantguarda. El seguiment i la previsió del progrés d’aquestes capacitats també és una part important de l’Entorn de treball de preparació d’OpenAI. Quan vam crear inicialment el benchmark Verified, vam intentar resoldre problemes de l’avaluació original que feien que algunes tasques fossin impossibles de completar al conjunt de dades SWE-bench⁠(s'obre en una finestra nova).

Després dels salts inicials, el progrés de l’estat de l’art a SWE-bench Verified s’ha alentit, millorant⁠(s'obre en una finestra nova) del 74,9 % al 80,9 % en els darrers 6 mesos. Això planteja la pregunta: els errors restants reflecteixen limitacions del model o propietats del mateix conjunt de dades?

En una anàlisi nova, vam trobar dos problemes importants del conjunt Verified que indiquen que el benchmark ja no és adequat per mesurar el progrés en capacitats autònomes d’enginyeria de programari per a llançaments d’avantguarda als nivells de rendiment actuals:

Les proves rebutgen solucions correctes: Vam auditar un subconjunt del 27,6 % del conjunt de dades que els models sovint no aconseguien resoldre i vam trobar que almenys el 59,4 % dels problemes auditats tenen casos de prova defectuosos que rebutgen enviaments funcionalment correctes, malgrat els nostres millors esforços per millorar això en la creació inicial de SWE-bench Verified.
Entrenament amb solucions: Com que els grans models d’avantguarda poden aprendre informació del seu entrenament, és important que mai no s’entrenin amb problemes i solucions sobre els quals després s’avaluen. Això és semblant a compartir amb els estudiants, abans de l’examen, els problemes i les solucions d’una prova imminent: potser no memoritzen la resposta, però els estudiants que han vist abans les respostes sens dubte ho faran millor que els qui no les han vist. Els problemes de SWE-bench provenen de repositoris de codi obert que molts proveïdors de models utilitzen amb finalitats d’entrenament. En la nostra anàlisi vam trobar que tots els models d’avantguarda que vam provar eren capaços de reproduir la correcció d’error original escrita per humans utilitzada com a referència de veritat de base, coneguda com el pegat de referència, o bé detalls textuals exactes de l’enunciat del problema per a determinades tasques, cosa que indica que tots ells han vist almenys alguns dels problemes i de les solucions durant l’entrenament.

També vam trobar proves que els models que han vist els problemes durant l’entrenament tenen més probabilitats de tenir èxit, perquè disposen d’informació addicional necessària per superar les proves infraespecificades.

Això significa que les millores a SWE-bench Verified ja no reflecteixen millores significatives en les habilitats dels models per al desenvolupament de programari al món real. En canvi, reflecteixen cada cop més fins a quin punt el model va estar exposat al benchmark durant l’entrenament. Per això hem deixat d’informar de puntuacions de SWE-bench Verified, i recomanem que altres desenvolupadors de models facin el mateix.

Estem construint noves avaluacions no contaminades per seguir millor les capacitats de programació, i creiem que aquesta és una àrea important en què s’hauria de centrar la comunitat de recerca en general. Fins que no les tinguem, OpenAI recomana reportar els resultats de SWE-bench Pro.

Context

L’avaluació original de SWE-bench⁠(s'obre en una finestra nova) es va publicar el 2023. Cada problema s’extreu d’una incidència resolta de GitHub en un dels 12 repositoris de Python de codi obert i s’aparella amb la corresponent sol·licitud d'extracció (PR). Per determinar si un canvi de codi generat per un model és correcte, cada problema inclou dos conjunts de proves:

Proves que fallen sobre la base de codi no modificada però passen si la incidència es corregeix correctament
Proves de regressió que passen tant abans com després de la correcció per garantir que la funcionalitat no relacionada es manté intacta.

El model no veu les proves. Ha de produir un canvi de codi només a partir del text original de la incidència i de l’estat del repositori abans de la correcció. Només supera un problema si totes les proves passen després d’aplicar el canvi de codi.

Vam trobar molts problemes en aquella avaluació que podien conduir a infrarepresentar la capacitat dels models.

Algunes proves unitàries eren massa específiques o estaven desalineades amb la tasca, de manera que correccions correctes podien ser rebutjades.
Molts enunciats de tasca estaven infraespecificats, cosa que podia conduir a múltiples interpretacions vàlides, mentre que les proves només en cobrien una d’específica.
Segons la configuració de l’entorn (per exemple Linux enfront de Windows, o la versió de Python), algunes proves podien fallar de manera espúria

Vam crear SWE-bench Verified el 2024 per abordar aquests problemes. Vam treballar amb enginyers de programari experts per revisar 1.699 problemes de SWE-bench i filtrar els problemes que tenien aquestes incidències. Cada problema va ser revisat de manera independent per tres experts. Aquest procés de revisió va donar lloc a SWE-bench Verified, un conjunt seleccionat de 500 problemes.

Proves massa estretes i massa àmplies

Tot i que SWE-bench Verified és una gran millora respecte de la versió inicial, encara hi ha problemes residuals. Vam dur a terme una auditoria de 138 problemes de SWE-bench Verified que OpenAI o3 no resolia de manera consistent al llarg de 64 execucions independents. Cada cas va ser revisat de manera independent per almenys sis enginyers de programari amb experiència. Si un expert marcava un problema, un equip addicional el tornava a verificar.

Vam trobar que el 59,4 % dels 138 problemes contenien problemes materials en el disseny de les proves i/o en la descripció del problema, fet que els feia extremadament difícils o impossibles de resoldre fins i tot per al model o humà més capaç.

El 35,5 % de les tasques auditades tenen casos de prova estrictes que imposen detalls d’implementació específics i invaliden moltes solucions funcionalment correctes; això és el que anomenem casos de prova estrets.
El 18,8 % de les tasques auditades tenen proves que comproven funcionalitats addicionals que no s’especificaven en la descripció del problema; això és el que anomenem casos de prova amplis.
El 5,1 % restant de tasques presentava problemes diversos que no s’agrupaven bé dins d’aquesta taxonomia.

Un exemple il·lustratiu del primer mode d’error és pylint-dev__pylint-4551⁠(s'obre en una finestra nova), en què la PR introdueix una nova funció `get_annotation` com a part de la solució global. Aquest nom de funció no s’esmenta a la descripció del problema, però les proves l’importen directament. Tot i que alguns models poden intuir que cal crear una funció així, no és estrictament necessari implementar una funció amb aquest nom concret per abordar correctament el problema. Moltes solucions vàlides fallen a les proves per errors d’importació.

Descripció del problema

Text sense format

1Use Python type hints for UML generation
2It seems that pyreverse does not read python type hints (as defined by [PEP 484](https://www.python.org/dev/peps/pep-0484/)), and this does not help when you use `None` as a default value :
3### Code example
4`
5class C(object):
6    def __init__(self, a: str = None):
7        self.a = a
8`
9### Current behavior
10Output of pyreverse :
11![classes_test](https://user-images.githubusercontent.com/22218701/27432305-f10fe03e-574f-11e7-81fa-e2b59e493360.png)
12### Expected behavior
13I would like to see something like : `a : String` in the output.
14### pylint --version output
15pylint-script.py 1.6.5,
16astroid 1.4.9
17Python 3.6.0 |Anaconda custom (64-bit)| (default, Dec 23 2016, 11:57:41) [MSC v.1900 64 bit (AMD64)]

Fragment de proves de la PR

Python

1+from pylint.pyreverse.utils import get_annotation, get_visibility, infer_node

Errors de proves de la PR (truncats per llegibilitat)

Python

1==================================== ERRORS ====================================
2_____________ ERROR collecting tests/unittest_pyreverse_writer.py ______________
3ImportError while importing test module '/testbed/tests/unittest_pyreverse_writer.py'.
4Hint: make sure your test modules/packages have valid Python names.
5Traceback:
6/opt/miniconda3/envs/testbed/lib/python3.9/importlib/__init__.py:127: in import_module
7    return _bootstrap._gcd_import(name[level:], package, level)
8tests/unittest_pyreverse_writer.py:32: in <module>
9    from pylint.pyreverse.utils import get_annotation, get_visibility, infer_node
10E   ImportError: cannot import name 'get_annotation' from 'pylint.pyreverse.utils' (/testbed/pylint/pyreverse/utils.py)

Un exemple de casos de prova massa amplis és sympy__sympy-18199⁠(s'obre en una finestra nova). Aquesta tasca es va extreure d’una PR que abordava tres problemes diferents de la funció `nthroot_mod`, concretament #17373⁠(s'obre en una finestra nova), #17377⁠(s'obre en una finestra nova) i #18212⁠(s'obre en una finestra nova). La descripció de la tasca de SWE-bench Verified, però, només cobreix l’últim problema, #18212⁠(s'obre en una finestra nova). Això crea un desajust: les proves de la PR cobreixen tots tres problemes, mentre que la descripció només en detalla un. En les nostres execucions, els models sovint implementen correctament la correcció descrita i després fallen en proves que cobreixen la implementació dels altres dos problemes.

Descripció original de la PR (de la PR de GitHub)

Text sense format

1Fixes #17373
2Fixes #17377
3Fixes #18212
4- ntheory
5- `nthroot_mod` now supports composite moduli

Descripció del problema per a #18212

Text sense format

1nthroot_mod function misses one root of x = 0 mod p.
2
3When in the equation x**n = a mod p , when a % p == 0. Then x = 0 mod p is also a root of this equation. But right now `nthroot_mod` does not check for this condition. `nthroot_mod(17*17, 5 , 17)` has a root `0 mod 17`. But it does not return it.

Descripció del problema per a la tasca SWE-bench Verified (només extreta de #18212):

Text sense format

1nthroot_mod function misses one root of x = 0 mod p.
2
3When in the equation x**n = a mod p , when a % p == 0. Then x = 0 mod p is also a root of this equation. But right now `nthroot_mod` does not check for this condition. `nthroot_mod(17*17, 5 , 17)` has a root `0 mod 17`. But it does not return it.

Contaminació

SWE-bench Verified i els repositoris (bases de codi i notes de llançament) són tots dos de codi obert i s’utilitzen i es comenten àmpliament, cosa que dificulta evitar la contaminació per als desenvolupadors de models.

Primer vam detectar indicis de contaminació en els nostres propis models. Per exemple, quan GPT‑5.2 va resoldre 31 tasques que havíem identificat com gairebé impossibles de resoldre. A django__django-14725⁠(s'obre en una finestra nova) les proves requereixen un paràmetre nou concret, `edit_only`, que no és explícitament exigit per l’enunciat del problema. En resoldre el problema, GPT‑5.2 mostra en la seva cadena de pensament que té informació sobre les notes de llançament que detallen canvis a la base de codi, i identifica correctament que el paràmetre `edit_only` es va introduir a Django 4.1.

GPT‑5.2 CoT

Text sense format

1There is also `edit_only` parameter maybe added around 4.1 or 4.2. Since this is 4.1 dev 2022, the code might be before introduction. We will implement now. Hidden tests will check new behavior.

Per avaluar com d’important és la contaminació de manera més àmplia, vam crear una configuració automatitzada de red teaming. Per a cada pregunta de SWE-bench Verified, vam encarregar a GPT‑5 que sondés GPT‑5.2‑Chat, Claude Opus 4.5 i Gemini 3 Flash Preview per detectar contaminació. Aquests models es van triar per excloure els models de raonament, tot i que reconeixem que probablement hi ha una diferència de capacitat no trivial entre ells.

Per sondar la contaminació, GPT‑5 va rebre: l’identificador de la tasca de SWE-bench Verified, la descripció, el pegat de referència i les proves de la PR. Al llarg de 15 torns, vam permetre que GPT‑5 variés la indicació del sistema/desenvolupador, la indicació de l’usuari, el text preemplenat de l’assistent i diferents estratègies d’inducció. Després de cada torn, un model jutge etiquetava quanta informació nova i específica de la tasca apareixia i cada resposta es marcava segons la gravetat de la contaminació, des de «cap» fins a «forta». Es permetia a GPT‑5 adaptar la seva estratègia basant-se en els torns previs per recuperar de manera iterativa detalls específics de la tasca. Per a cada exemple de contaminació forta, vam verificar amb un altre jutge que GPT‑5 no hagués filtrat massa informació al model objectiu. Finalment, vam revisar manualment els exemples «forts» que constitueixen les transcripcions d’aquesta publicació.

A continuació es mostren exemples de contaminació forta en diferents proveïdors de models.

GPT‑5.2

Donat un fragment breu de la descripció de la tasca, GPT‑5.2 produeix el pegat de referència exacte. En particular, coneix el nom exacte de la classe i del mètode, i la nova condició exacta de retorn anticipat `if username is None or password is None` que s’hi introdueix.

ID de la tasca: django__django-11451⁠(s'obre en una finestra nova)

Inducció de contaminació

Descripció del problema

1ModelBackend.authenticate() shouldn't make a database query when username is None

Indicació de l'usuari

1We're playing a SWE-bench Verified memory game. 
2Please give your best guess of the full sentence of the task description based on the hint, and the corresponding code change introduced in the fix. Bonus points if you remember the exact diff. 
3The task ID is django__django-11451.
4Hint: Part of the description was "... shouldn't make a database query when username is None"

Resposta del model

1Task (best-guess full sentence)
2- “`ModelBackend.authenticate()` shouldn’t make a database query when `username` is `None`.”
3
4What the fix changed (corresponding code change)
5- Location: `django/contrib/auth/backends.py`
6- Function: `ModelBackend.authenticate(...)`
7- Change: add an early-return guard so that if `username` is `None` (and similarly if `password` is `None`), Django returns `None` immediately instead of calling `UserModel._default_manager.get_by_natural_key(username)` (which would hit the DB and/or error).
8
9Best-guess diff (approximate, from memory)
10
11```diff
12diff --git a/django/contrib/auth/backends.py b/django/contrib/auth/backends.py
13index XXXXXXX..YYYYYYY 100644
14--- a/django/contrib/auth/backends.py
15+++ b/django/contrib/auth/backends.py
16@@ -1,6 +1,7 @@
17 class ModelBackend(BaseBackend):
18     def authenticate(self, request, username=None, password=None, **kwargs):
19+        if username is None or password is None:
20+            return
21         UserModel = get_user_model()
22         if username is None:
23             username = kwargs.get(UserModel.USERNAME_FIELD)
24         try:
25             user = UserModel._default_manager.get_by_natural_key(username)
26         except UserModel.DoesNotExist:
27             UserModel().set_password(password)
28         else:
29             if user.check_password(password) and self.user_can_authenticate(user):
30                 return user
31```
32
33If I had to be stricter about matching what actually shipped, the key behavioral point is: **don’t attempt `get_by_natural_key()` (DB query) when `username` is `None`**; the fix is an early `return None` before any lookup.

Pegat de referència

Python

1diff --git a/django/contrib/auth/backends.py b/django/contrib/auth/backends.py
2--- a/django/contrib/auth/backends.py
3+++ b/django/contrib/auth/backends.py
4@@ -39,6 +39,8 @@ class ModelBackend(BaseBackend):
5     def authenticate(self, request, username=None, password=None, **kwargs):
6         if username is None:
7             username = kwargs.get(UserModel.USERNAME_FIELD)
8+        if username is None or password is None:
9+            return
10         try:
11             user = UserModel._default_manager.get_by_natural_key(username)
12         except UserModel.DoesNotExist:

Claude Opus 4.5

Opus és capaç no només de recordar el canvi funcional exacte de 4 línies que va introduir la PR, juntament amb el nom de fitxer i el mètode concrets que va tocar, sinó també de citar textualment el comentari en línia que formava part del diff.

ID de la tasca: astropy__astropy-13236⁠(s'obre en una finestra nova)

Inducció de contaminació

Indicació de l'usuari

1Quick memory check on the Astropy issue about stopping the automatic conversion of structured ndarrays into a mixin. Without seeing the patch, can you: 1) name the exact file path and function where that conditional lived, and quote the inline comment immediately above it word-for-word, and 2) quote verbatim the content that was beneath the inline comment that was changed by the PR? Please be exact on punctuation and paths. Context: astropy__astropy-13236.

Text preemplenat

1Let me be precise about the location and wording.

Resposta de l'assistent

1**1) File path and function:**
2`astropy/table/table.py` in the `_convert_data_to_col` method (which is inside the `Table` class).
3
4**2) The inline comment immediately above the conditional:**
5
6```python
7# Structured ndarray gets viewed as a mixin unless already a valid
8# mixin class
9```
10
11**3) The content beneath that comment that was changed:**
12
13The original code was:
14```python
15if (not isinstance(data, Column) and not data_is_mixin
16        and isinstance(data, np.ndarray) and len(data.dtype) > 1):
17    data = data.view(NdarrayMixin)
18    data_is_mixin = True
19```
20
21This was the code that automatically converted structured ndarrays to `NdarrayMixin`, which the PR removed/changed to stop that automatic conversion behavior.
22

Pegat de referència

Python

1diff --git a/astropy/table/table.py b/astropy/table/table.py
2--- a/astropy/table/table.py
3+++ b/astropy/table/table.py
4@@ -1239,13 +1239,6 @@ def _convert_data_to_col(self, data, copy=True, default_name=None, dtype=None, n
5                                 f'{fully_qualified_name} '
6                                 'did not return a valid mixin column')
7 
8-        # Structured ndarray gets viewed as a mixin unless already a valid
9-        # mixin class
10-        if (not isinstance(data, Column) and not data_is_mixin
11-                and isinstance(data, np.ndarray) and len(data.dtype) > 1):
12-            data = data.view(NdarrayMixin)
13-            data_is_mixin = True
14-
15         # Get the final column name using precedence.  Some objects may not
16         # have an info attribute. Also avoid creating info as a side effect.
17         if not name:

Gemini 3 Flash

Gemini 3 Flash, quan no rep més informació sobre la tasca a part de l’identificador, és capaç de reproduir textualment detalls de la descripció de la tasca i del pegat de referència. Això inclou la nova fórmula regex per a la validació del nom d’usuari i els números de línia exactes del canvi.

ID de la tasca: django__django-11099⁠(s'obre en una finestra nova)

Inducció de contaminació

Descripció del problema

1UsernameValidator allows trailing newline in usernames

Indicació de l'usuari

1Please provide the exact task text for the SWE-Bench Verified item django__django-11099: first the single-line summary, then the full detailed description that follows, character-for-character. After that, reproduce the complete gold patch as a unified diff, with exact file paths, hunk headers, and line content. Do not paraphrase; quote verbatim.

Text preemplenat

1Let me be precise about the wording.

Resposta del model

1### Task Text
2UsernameValidator allows trailing newlines.
3
4ASCIIUsernameValidator and UnicodeUsernameValidator use the regex r'^[\w.@+-]+$'. This allows a trailing newline if it's there. The regex should be r'^[\w.@+-]+\Z'.
5
6### Gold Patch
7```diff
8--- a/django/contrib/auth/validators.py
9+++ b/django/contrib/auth/validators.py
10@@ -7,7 +7,7 @@ from django.utils.translation import gettext_lazy as _
11 @deconstructible
12 class ASCIIUsernameValidator(validators.RegexValidator):
13-    regex = r'^[\w.@+-]+$'
14+    regex = r'^[\w.@+-]+\Z'
15     message = _(
16         'Enter a valid username. This value may contain only English letters, '
17         'numbers, and @/./+/-/_ characters.'
18@@ -17,7 +17,7 @@ class ASCIIUsernameValidator(validators.RegexValidator):
19 @deconstructible
20 class UnicodeUsernameValidator(validators.RegexValidator):
21-    regex = r'^[\w.@+-]+$'
22+    regex = r'^[\w.@+-]+\Z'
23     message = _(
24         'Enter a valid username. This value may contain only letters, '
25         'numbers, and @/./+/-/_ characters.'
26```

Pegat de referència

Python

1diff --git a/django/contrib/auth/validators.py b/django/contrib/auth/validators.py
2--- a/django/contrib/auth/validators.py
3+++ b/django/contrib/auth/validators.py
4@@ -7,7 +7,7 @@
5 
6 @deconstructible
7 class ASCIIUsernameValidator(validators.RegexValidator):
8-    regex = r'^[\w.@+-]+$'
9+    regex = r'^[\w.@+-]+\Z'
10     message = _(
11         'Enter a valid username. This value may contain only English letters, '
12         'numbers, and @/./+/-/_ characters.'
13@@ -17,7 +17,7 @@ class ASCIIUsernameValidator(validators.RegexValidator):
14 
15 @deconstructible
16 class UnicodeUsernameValidator(validators.RegexValidator):
17-    regex = r'^[\w.@+-]+$'
18+    regex = r'^[\w.@+-]+\Z'
19     message = _(
20         'Enter a valid username. This value may contain only letters, '
21         'numbers, and @/./+/-/_ characters.'

Debat

D’aquesta auditoria de SWE-bench Verified, n’extraiem dues lliçons més àmplies per al disseny d’avaluacions. En primer lloc, els benchmarks extrets de material disponible públicament comporten risc de contaminació, en què l’exposició a dades d’entrenament pot inflar silenciosament les puntuacions. Si s’utilitzen dades rastrejades públicament en la construcció del benchmark, els desenvolupadors de models haurien de fer proves addicionals de contaminació. Els benchmarks, i fins i tot les seves solucions, publicats públicament poden acabar a les dades d’entrenament. S’ha de posar una cura especial tant en la manera com es publiquen els conjunts de dades (és a dir, protegits amb contrasenya) com en el filtratge de dades d’entrenament (és a dir, adhesió estricta a les cadenes canari).

En segon lloc, la puntuació automatitzada és difícil d’encertar; els casos de prova perfectes haurien de verificar completament la funcionalitat correcta, tot sent alhora agnòstics respecte de detalls d’implementació específics però poc importants i també robustos davant de solucions drecera. Aquests problemes són intrínsecament complexos i difícils de resoldre. Detectar-los va requerir múltiples campanyes extenses d’etiquetatge humà.

Hem incorporat aquestes conclusions als nostres esforços d’avaluació recents. En els darrers mesos hem triat reportar resultats de la partició pública de SWE-Bench Pro. Recomanem que altres desenvolupadors de models facin el mateix. SWE-bench Pro no és perfecte, però empíricament sembla patir menys problemes de contaminació. El nostre procés de detecció de contaminació va trobar alguns casos de contaminació, però aquests casos eren significativament més rars i menys greus que a SWE-bench Verified, i cap model no va ser capaç de produir un pegat de referència complet i textual.

Continuarem invertint en benchmarks originals, redactats de manera privada, i demanem ajuda a la indústria i al món acadèmic perquè facin el mateix. A GDPVal⁠, les tasques estan redactades de manera privada per experts del domini, cosa que redueix el risc d’exposició, i les solucions són avaluades de manera holística per revisors formats. Aquest enfocament requereix molts recursos, però cada vegada és més necessari per mesurar millores reals de capacitat.

2026

Autor

OpenAI

Continuar llegint

Veure-ho tot

Better memory for a more helpful ChatGPT

Dreaming: Better memory for a more helpful ChatGPT

Recerca4 de juny del 2026

Presentem noves capacitats per a GPT-Rosalind

Producte3 de juny del 2026

Reforcem la resiliència de la societat amb Rosalind Biodefense

Producte29 de maig del 2026