OpenAI

23 בפברואר 2026

מחקרפרסום

למה SWE-bench Verified כבר לא מודד את יכולות התכנות של מודלי חזית

הזיהום ב-SWE-bench Verified הולך וגובר. אנחנו ממליצים על SWE-bench Pro.

בטעינה…

מאז שפרסמנו לראשונה את SWE-bench Verified באוגוסט 2024, נעשה בו שימוש נרחב בתעשייה למדידת ההתקדמות של מודלים במשימות הנדסת תוכנה אוטונומית. לאחר פרסומו, SWE-bench Verified סיפק אינדיקציה ברורה להתקדמות ביכולות והפך למדד מקובל שעליו מדווחים בהשקות של מודלי חזית. המעקב אחר התקדמות היכולות האלה וחיזויה הם גם חלק חשוב מ-Preparedness Framework של OpenAI. כשיצרנו לראשונה את מבחן ההערכה Verified, ניסינו לפתור בעיות בהערכה המקורית שמנעו את השלמתן של משימות מסוימות ב-מערך הנתונים של SWE-bench⁠(נפתח בחלון חדש).

לאחר קפיצות הדרך הראשוניות, קצב ההתקדמות של המודלים המובילים ב-SWE-bench Verified הואט, והציונים השתפרו⁠(נפתח בחלון חדש) מ-74.9% ל-80.9% בששת החודשים האחרונים. מכאן עולה השאלה: האם הכישלונות שנותרו משקפים מגבלות של המודלים או מאפיינים של מערך הנתונים עצמו?

בניתוח חדש מצאנו שתי בעיות מרכזיות במערך Verified, המעידות שברמות הביצועים הנוכחיות, מבחן ההערכה כבר אינו מתאים למדידת ההתקדמות ביכולות הנדסת תוכנה אוטונומית בעת השקת מודלי חזית:

  1. בדיקות פוסלות פתרונות נכונים: ערכנו ביקורת על תת-קבוצה שהיוותה 27.6% ממערך הנתונים וכללה בעיות שמודלים נכשלו לעיתים קרובות בפתרונן. מצאנו שלפחות ב-59.4% מהבעיות שנבדקו יש מקרי בדיקה פגומים, שפוסלים פתרונות נכונים מבחינה תפקודית, למרות מאמצינו לשפר זאת כשיצרנו לראשונה את SWE-bench Verified.

  2. אימון על פתרונות: מכיוון שמודלי חזית גדולים יכולים ללמוד מידע במהלך האימון, חשוב שהם לעולם לא יאומנו על בעיות ופתרונות שעל פיהם מעריכים אותם. הדבר דומה למסירת שאלות ופתרונות לתלמידים לפני מבחן: הם אולי לא ישננו את התשובות, אבל תלמידים שראו אותן מראש בוודאי יצליחו יותר מאלה שלא. הבעיות ב-SWE-bench נלקחות ממאגרי קוד פתוח שספקי מודלים רבים משתמשים בהם לצורכי אימון. בניתוח שלנו מצאנו שכל מודלי החזית שבדקנו הצליחו לשחזר, במשימות מסוימות, את תיקון הבאג המקורי שכתב אדם ושמשמש כפתרון הנכון להשוואה, המכונה תיקון הייחוס, או פרטים מנוסח הבעיה מילה במילה. הדבר מעיד שכולם נחשפו לפחות לחלק מהבעיות והפתרונות במהלך האימון.

מצאנו גם ראיות לכך שמודלים שנחשפו לבעיות במהלך האימון נוטים להצליח יותר, משום שיש בידיהם מידע נוסף הנחוץ כדי לעבור בדיקות שדרישותיהן לא פורטו במלואן.

המשמעות היא ששיפורים ב-SWE-bench Verified כבר אינם משקפים שיפורים מהותיים ביכולות פיתוח התוכנה של המודלים בעולם האמיתי. במקום זאת, הם משקפים יותר ויותר את מידת החשיפה של המודל למבחן ההערכה בזמן האימון. לכן הפסקנו לדווח על ציוני SWE-bench Verified, ואנחנו ממליצים גם למפתחי מודלים אחרים לעשות זאת.

אנחנו בונים מבחני הערכה חדשים, ללא זיהום, כדי לעקוב טוב יותר אחר יכולות תכנות. לדעתנו, זהו תחום שחשוב שגם קהילת המחקר הרחבה תתמקד בו. עד שיהיו בידינו מבחנים כאלה, OpenAI ממליצה לדווח על תוצאות ב-SWE-bench Pro.

רקע

מבחן ההערכה המקורי SWE-bench⁠(נפתח בחלון חדש) פורסם ב-2023. כל בעיה נלקחה מתוך GitHub issue שנפתר באחד מ-12 מאגרי Python בקוד פתוח, וצורף אליה ה-pull request ‏(PR) המתאים. כדי לקבוע אם שינוי קוד שיצר מודל הוא נכון, לכל בעיה מצורפות שתי קבוצות של בדיקות:

  • בדיקות שנכשלות בבסיס הקוד המקורי, אך עוברות אם הבעיה תוקנה כראוי

  • בדיקות רגרסיה שעוברות גם לפני התיקון וגם אחריו, כדי לוודא שתפקוד שאינו קשור לתיקון נשאר תקין.

המודל אינו רואה את הבדיקות. עליו ליצור שינוי בקוד על סמך הטקסט המקורי של הבעיה ומצב המאגר לפני התיקון בלבד. פתרון הבעיה נחשב להצלחה רק אם כל הבדיקות עוברות לאחר החלת השינוי בקוד.

מצאנו במבחן ההערכה הזה בעיות רבות שעלולות להוביל לדיווח על יכולות המודלים כנמוכות מכפי שהן בפועל.

  • חלק מבדיקות היחידה היו ספציפיות מדי או לא תאמו למשימה, ולכן תיקונים נכונים היו עלולים להיפסל.

  • תיאורי משימות רבים לא היו מפורטים דיים, ולכן אפשרו כמה פרשנויות תקפות, בעוד שהבדיקות התייחסו רק לפרשנות מסוימת אחת.

  • בהתאם להגדרות הסביבה (למשל Linux לעומת Windows, או גרסת Python), חלק מהבדיקות היו עלולות להיכשל גם ללא תקלה בקוד

יצרנו את SWE-bench Verified ב-2024 כדי לטפל בבעיות האלה. עבדנו עם מהנדסי תוכנה מומחים כדי לבחון 1,699 בעיות מ-SWE-bench ולסנן החוצה את אלה שסבלו מהליקויים האלה. כל בעיה נבחנה באופן בלתי תלוי בידי שלושה מומחים. תהליך הבחינה הזה הניב את SWE-bench Verified, מערך של 500 בעיות שנבחרו בקפידה.

בדיקות צרות מדי ורחבות מדי

אף ש-SWE-bench Verified הוא שיפור משמעותי לעומת הגרסה הראשונית, עדיין נותרו בו בעיות. ערכנו ביקורת על 138 בעיות ב-SWE-bench Verified שהמודל o3 של OpenAI לא הצליח לפתור בעקביות לאורך 64 הרצות בלתי תלויות. כל מקרה נבחן באופן בלתי תלוי בידי לפחות שישה מהנדסי תוכנה מנוסים. אם מומחה הצביע על ליקוי, צוות נוסף בדק אותו כדי לאמת את הממצא.

מצאנו שב-59.4% מתוך 138 הבעיות היו ליקויים מהותיים בתכנון הבדיקות ו/או בתיאור הבעיה, שהפכו את פתרונן לקשה ביותר או לבלתי אפשרי, אפילו עבור המודל או האדם בעלי היכולות הגבוהות ביותר. 

  • ב-35.5% מהמשימות שנבחנו יש מקרי בדיקה נוקשים, שמחייבים פרטי מימוש מסוימים ופוסלים פתרונות רבים שנכונים מבחינה תפקודית. אנחנו מכנים אותם מקרי בדיקה צרים.

  • ב-18.8% מהמשימות שנבחנו יש בדיקות שדורשות יכולות נוספות שלא צוינו בתיאור הבעיה. אנחנו מכנים אותן מקרי בדיקה רחבים.

  • ב-5.1% הנותרים מהמשימות היו ליקויים שונים שלא התאימו היטב לקטגוריות האלה.

דוגמה שממחישה את סוג הכשל הראשון היא pylint-dev__pylint-4551⁠(נפתח בחלון חדש), שבה ה-PR מוסיף פונקציה חדשה בשם `get_annotation` כחלק מהפתרון הכולל. שם הפונקציה אינו מוזכר בתיאור הבעיה, אבל הבדיקות מייבאות אותה ישירות. אומנם חלק מהמודלים עשויים להסיק בעצמם שכדאי ליצור פונקציה כזאת, אך אין הכרח לממש פונקציה בשם המסוים הזה כדי לפתור את הבעיה כראוי. פתרונות תקפים רבים נכשלים בבדיקות בגלל שגיאות ייבוא.

תיאור הבעיה

טקסט פשוט

1
Use Python type hints for UML generation
2
It 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
`
5
class C(object):
6
def __init__(self, a: str = None):
7
self.a = a
8
`
9
### Current behavior
10
Output of pyreverse :
11
![classes_test](https://user-images.githubusercontent.com/22218701/27432305-f10fe03e-574f-11e7-81fa-e2b59e493360.png)
12
### Expected behavior
13
I would like to see something like : `a : String` in the output.
14
### pylint --version output
15
pylint-script.py 1.6.5,
16
astroid 1.4.9
17
Python 3.6.0 |Anaconda custom (64-bit)| (default, Dec 23 2016, 11:57:41) [MSC v.1900 64 bit (AMD64)]

קטע מבדיקות ה-PR

Python

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

כישלונות בבדיקות ה-PR (קוצר לשיפור הקריאות)

Python

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

דוגמה למקרי בדיקה רחבים מדי היא sympy__sympy-18199⁠(נפתח בחלון חדש). המשימה הזאת נלקחה מ-PR שטיפל בשלוש בעיות נפרדות בפונקציה `nthroot_mod`: ‏#17373⁠(נפתח בחלון חדש), ‏#17377⁠(נפתח בחלון חדש) ו-#18212⁠(נפתח בחלון חדש). אולם תיאור המשימה ב-SWE-bench Verified מתייחס רק לבעיה האחרונה, #18212⁠(נפתח בחלון חדש). כך נוצר חוסר התאמה: בדיקות ה-PR מכסות את כל שלוש הבעיות, ואילו התיאור מפרט רק אחת מהן. בהרצות שלנו, מודלים מימשו לעיתים קרובות את התיקון המתואר כראוי, ואז נכשלו בבדיקות שבחנו את המימוש עבור שתי הבעיות האחרות.

התיאור המקורי של ה-PR (מתוך ה-PR ב-GitHub)

טקסט פשוט

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

תיאור הבעיה ב-#18212

טקסט פשוט

1
nthroot_mod function misses one root of x = 0 mod p.
2

3
When 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.

תיאור הבעיה למשימת SWE-bench Verified (נלקח רק מתוך #18212):

טקסט פשוט

1
nthroot_mod function misses one root of x = 0 mod p.
2

3
When 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.

זיהום

גם SWE-bench Verified וגם המאגרים (בסיסי הקוד והערות הגרסה) זמינים בקוד פתוח, נמצאים בשימוש נרחב ומוזכרים בדיונים רבים. לכן קשה למפתחי מודלים להימנע מזיהום.

בסימני זיהום נתקלנו לראשונה במודלים שלנו. למשל, כש-GPT‑5.2 פתר 31 משימות שזיהינו ככמעט בלתי אפשריות לפתרון. ב-django__django-14725⁠(נפתח בחלון חדש), הבדיקות דורשות פרמטר חדש ומסוים בשם `edit_only`, שאינו נדרש במפורש בנוסח הבעיה. במהלך פתרון הבעיה, שרשרת המחשבה של GPT‑5.2 מראה שיש בידיו מידע על הערות הגרסה המפרטות שינויים בבסיס הקוד, והוא מזהה נכון שהפרמטר `edit_only` נוסף ב-Django 4.1.

שרשרת המחשבה של GPT‑5.2

טקסט פשוט

1
There 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.

כדי להעריך עד כמה הזיהום משמעותי באופן רחב יותר, יצרנו מערך red teaming אוטומטי. עבור כל שאלה ב-SWE-bench Verified, הטלנו על GPT‑5 לבדוק סימני זיהום ב-GPT‑5.2‑Chat, ב-Claude Opus 4.5 וב-Gemini 3 Flash Preview. המודלים האלה נבחרו כדי שלא לכלול מודלי reasoning, אך אנחנו מכירים בכך שסביר שיש ביניהם פער יכולות לא מבוטל.

כדי לבדוק סימני זיהום, GPT‑5 קיבל את מזהה המשימה ב-SWE-bench Verified, את התיאור שלה, את תיקון הייחוס ואת בדיקות ה-PR. לאורך 15 סבבי שיחה, אפשרנו ל-GPT‑5 לשנות את פרומפט המערכת או המפתח, את פרומפט המשתמש ואת הטקסט המקדים לתגובת העוזר, ולנסות אסטרטגיות elicitation שונות. לאחר כל סבב, מודל שופט סימן כמה מידע חדש וספציפי למשימה הופיע, וכל תגובה סווגה לפי חומרת הזיהום, מ״ללא״ ועד ״חמור״. אפשרנו ל-GPT‑5 להתאים את האסטרטגיה שלו על סמך סבבים קודמים, כדי לשחזר בהדרגה פרטים ספציפיים למשימה. בכל דוגמה של זיהום חמור, וידאנו באמצעות שופט נוסף ש-GPT‑5 לא הדליף מידע רב מדי למודל שנבדק. לבסוף, בחנו ידנית את הדוגמאות שסווגו כזיהום ״חמור״ ושמופיעות בתמלילים בפוסט הזה.

להלן דוגמאות לזיהום חמור במודלים של ספקים שונים.

GPT‑5.2 

כשנותנים ל-GPT‑5.2 קטע קצר מתיאור המשימה, הוא מפיק את תיקון הייחוס המדויק. בפרט, הוא יודע את שמות המחלקה והמתודה המדויקים, ואת התנאי החדש ליציאה מוקדמת שנוסף: `if username is None or password is None`.

elicitation לזיהוי זיהום

נוסח הבעיה

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

פרומפט המשתמש

1
We're playing a SWE-bench Verified memory game.
2
Please 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.
3
The task ID is django__django-11451.
4
Hint: Part of the description was "... shouldn't make a database query when username is None"

תגובת המודל

1
Task (best-guess full sentence)
2
- “`ModelBackend.authenticate()` shouldn’t make a database query when `username` is `None`.”
3

4
What 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

9
Best-guess diff (approximate, from memory)
10

11
```diff
12
diff --git a/django/contrib/auth/backends.py b/django/contrib/auth/backends.py
13
index 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

33
If 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.

תיקון הייחוס

Python

1
diff --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 מצליח לא רק לשחזר את השינוי התפקודי המדויק בן ארבע השורות שהוסיף ה-PR, יחד עם שם הקובץ והמתודה המסוימים שהושפעו ממנו, אלא גם לצטט מילה במילה את ההערה בקוד שהייתה חלק מה-diff. 

elicitation לזיהוי זיהום

פרומפט המשתמש

1
Quick 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.

טקסט מקדים לתגובה

1
Let me be precise about the location and wording.

תגובת העוזר

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

13
The original code was:
14
```python
15
if (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

21
This was the code that automatically converted structured ndarrays to `NdarrayMixin`, which the PR removed/changed to stop that automatic conversion behavior.
22

תיקון הייחוס

Python

1
diff --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 רק את מזהה המשימה, ללא מידע נוסף עליה, הוא מצליח להפיק מילה במילה פרטים מתוך תיאור המשימה ומתיקון הייחוס. אלה כוללים את הביטוי הרגולרי החדש לאימות שם המשתמש ואת מספרי השורות המדויקים של השינוי.

elicitation לזיהוי זיהום

נוסח הבעיה

1
UsernameValidator allows trailing newline in usernames

פרומפט המשתמש

1
Please 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.

טקסט מקדים לתגובה

1
Let me be precise about the wording.

תגובת המודל

1
### Task Text
2
UsernameValidator allows trailing newlines.
3

4
ASCIIUsernameValidator 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
```

תיקון הייחוס

Python

1
diff --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.'

דיון

מהביקורת הזאת על SWE-bench Verified עולים שני לקחים רחבים יותר לתכנון מבחני הערכה. ראשית, מבחני הערכה שמבוססים על חומרים הזמינים לציבור חשופים לסיכון של זיהום: חשיפה לחומרים האלה בנתוני האימון עלולה לנפח ציונים בלי שהדבר יתגלה. אם מבחן הערכה נבנה באמצעות נתונים שנאספו בסריקה של מקורות ציבוריים, על מפתחי המודלים לבצע בדיקות נוספות לזיהוי זיהום. מבחני הערכה שמתפרסמים לציבור, ואפילו הפתרונות שלהם, עלולים להגיע לנתוני האימון. יש להקפיד במיוחד הן על אופן הפרסום של מערכי הנתונים (למשל, הגנה בסיסמה) והן על סינון נתוני האימון (למשל, הקפדה על החרגת תכנים המסומנים במחרוזות קנרית). 

שנית, קשה לתכנן ניקוד אוטומטי שיפעל כראוי. מקרי בדיקה אידיאליים צריכים לוודא באופן מלא שהתפקוד תקין, בלי להיות תלויים בפרטי מימוש מסוימים שאינם חשובים, ובה בעת לזהות פתרונות שמשתמשים בקיצורי דרך. הבעיות האלה מורכבות מעצם טבען וקשות לפתרון. כדי לאתר אותן נדרשו כמה סבבים נרחבים של תיוג אנושי. 

שילבנו את הממצאים האלה בעבודת ההערכה שלנו בתקופה האחרונה. בחודשים האחרונים בחרנו לדווח על תוצאות מהחלק הציבורי של SWE-Bench Pro. אנחנו ממליצים למפתחי מודלים אחרים לעשות זאת גם כן. SWE-bench Pro אינו מושלם, אבל לפי הממצאים האמפיריים נראה שהוא סובל פחות מבעיות זיהום. תהליך זיהוי הזיהום שלנו איתר כמה מקרים, אך הם היו נדירים ומתונים משמעותית בהשוואה ל-SWE-bench Verified, ואף מודל לא הצליח להפיק תיקון ייחוס שלם מילה במילה.

נמשיך להשקיע במבחני הערכה מקוריים שנכתבים באופן פרטי, ואנחנו קוראים לתעשייה ולאקדמיה לסייע בכך ולפעול באותה דרך. ב-GDPVal⁠, המשימות נכתבות באופן פרטי בידי מומחים בתחום, וכך מצטמצם הסיכון לחשיפה. הפתרונות נבחנים כמכלול בידי מעריכים שעברו הכשרה. הגישה הזאת דורשת משאבים רבים, אך היא נעשית נחוצה יותר ויותר כדי למדוד שיפורים אמיתיים ביכולות.

מחבר/ת

OpenAI