23 فبراير 2026

أسباب قصور مقياس SWE-bench Verified عن تقييم القدرات البرمجية للنماذج الرائدة

يعاني مقياس SWE-bench Verified من تلوث متزايد في البيانات؛ لذا فإننا نوصي باستخدام مقياس SWE-bench Pro كبديل أكثر دقة.

جاري التحميل...

شاع استخدام مقياس SWE-bench Verified في الأوساط التقنية كأداة لقياس تطور النماذج في مهام هندسة البرمجيات المستقلة منذ صدوره في أغسطس 2024. وقد وفّر المقياس منذ إطلاقه دلالة واضحة على وتيرة نمو القدرات، ليتحول إلى معيار قياسي ثابت في تقارير إطلاق النماذج الرائدة. كما يعد رصد واستشراف تقدم هذه القدرات ركيزة أساسية في إطار الجاهزية لدى OpenAI. لقد كانت غايتنا الأساسية عند ابتكار هذا المقياس هي حل العقبات التي كانت تكتنف التقييم الأولي، والتي تسببت في جعل بعض المهام ضمن قاعدة بيانات SWE-bench⁠(يفتح في نافذة جديدة) غير قابلة للإنجاز.

عقب الطفرات التي تحققت في بادئ الأمر، خبت وتيرة التطور القياسي في مقياس SWE-bench Verified، إذ لم ترتفع⁠(يفتح في نافذة جديدة) النسبة إلا من 74.9% لتصل إلى 80.9% في غضون الأشهر الستة الأخيرة. ويثير هذا التباطؤ تساؤلًا عما إذا كانت حالات الفشل المتبقية ناتجة عن محدودية إمكانات النماذج، أم أنها مجرد انعكاس لسمات بنيوية في مجموعة البيانات نفسها.

لقد خلصنا من خلال تحليل حديث إلى وجود خللين أساسيين في مجموعة بيانات مقياس Verified، مما يدل على أنه لم يعد صالحًا لرصد التطور في قدرات هندسة البرمجيات المستقلة للإصدارات الرائدة، خاصة عند مقارنتها بمستويات الأداء المحققة اليوم:

رفض الحلول الصحيحة: أجرينا تدقيقًا على عينة بنسبة 27.6% من مجموعة البيانات (وهي المسائل التي تكرر إخفاق النماذج في حلها)، واكتشفنا أن ما لا يقل عن 59.4% من هذه المسائل المدققة تشوبها حالات اختبار مشوبة بالخلل تؤدي لرفض الحلول الصحيحة من الناحية الوظيفية؛ ويأتي هذا الاكتشاف برغم مساعينا الحثيثة لتلافي مثل هذه العيوب عند إطلاق النسخة المعتمدة (Verified) من مقياس SWE-bench.
التدريب على الحلول: تميل النماذج الرائدة الكبيرة إلى امتصاص المعلومات من بيانات التدريب، لذا تكمن الأهمية في ضمان عدم تعرضها للمسائل والحلول المخصصة للتقييم. إن هذا الوضع يماثل تسريب أسئلة اختبار مرتقب وإجاباته للطلاب؛ حيث سيتفوق من رأى الإجابات مسبقًا على زملائه حتمًا، حتى وإن لم يعتمد على الذاكرة المجردة. ولأن مسائل SWE-bench مأخوذة من مستودعات برمجية مفتوحة المصدر تُستخدم عادةً في تدريب النماذج، فقد كشف تحليلنا أن جميع النماذج الرائدة الخاضعة للاختبار استطاعت محاكاة الحلول البشرية الأصلية المستخدمة كمعيار للصحة، المعروفة باسم "المعيار الذهبي"، أو إعادة صياغة تفاصيل حرفية لنصوص المسائل في بعض المهام. وهذا يعد دليلًا قويًا على أن هذه النماذج قد مرت ببعض تلك المسائل وحلولها خلال عمليات التدريب.

توصلنا كذلك إلى قرائن تثبت أن النماذج التي تعرضت للمسائل خلال طور التدريب تمتلك فرصًا أكبر لتحقيق النجاح، نظرًا لتوافر معلومات إضافية لديها تُمكّنها من عبور الاختبارات التي تفتقر إلى التحديد الدقيق للمواصفات.

يترتب على ذلك أن التطور المحرز في نتائج مقياس SWE-bench Verified لم يعد يعبر عن تقدم حقيقي في قدرات النماذج لتطوير البرمجيات في السياقات الواقعية. وعوضًا عن ذلك، باتت هذه النتائج تجسد بصورة مطردة درجة اطلاع النموذج على المقياس خلال فترة تدريبه. ومن هذا المنطلق، قررنا الكف عن الإبلاغ عن درجات SWE-bench Verified، كما ننصح زملاءنا من مطوري النماذج الآخرين بتبني النهج ذاته.

نعكف في الوقت الراهن على تطوير اختبارات تقييمية جديدة خالية من تسريب البيانات لرصد قدرات البرمجة بدقة أعلى، ونرى أن هذا التوجه يمثل ركيزة أساسية يجب أن يوليها المجتمع العلمي اهتمامًا خاصًا. وحتى يحين موعد جاهزية تلك الاختبارات، تنصح OpenAI بالاعتماد على نتائج SWE-bench Pro في التقارير الفنية.

الخلفية

تم إطلاق النسخة الأصلية من تقييم SWE-bench⁠(يفتح في نافذة جديدة) في عام 2023، حيث تُستخلص كل مسألة برمجية من مشكلة جرى حلها في GitHub ضمن 12 مستودعًا مفتوح المصدر للغة Python، مع ربطها بطلب السحب المعني بها. وبغرض التحقق من صحة التغييرات البرمجية الناتجة عن النموذج، يرافق كل مسألة مجموعتان من الاختبارات:

اختبارات تخفق عند تشغيلها على قاعدة الأكواد الأصلية قبل تعديلها، ولكنها تنجح وتجتاز الفحص إذا جرت معالجة المشكلة وإصلاحها بشكل صحيح
اختبارات التراجع التي تنجح في كلتا الحالتين، قبل الإصلاح وبعده، وذلك لضمان بقاء الوظائف الأخرى غير المتعلقة بالمشكلة سليمة دون أي خلل.

لا يطّلع النموذج على الاختبارات؛ بل يتعين عليه إجراء تعديل في الكود البرمجي استنادًا فحسب إلى النص الأصلي للمشكلة وحالة المستودع البرمجي قبل إجراء الإصلاح. ولا يُعتبر النموذج ناجحًا في حل المسألة إلا في حال اجتياز كافة الاختبارات بنجاح بعد تطبيق تعديل الكود البرمجي المقترح.

وقد رصدنا ثغرات عديدة في نظام التقييم المذكور، من شأنها أن تفضي إلى عدم إظهار كفاءة قدرات النماذج بدقة أو إظهارها بصورة أقل من حقيقتها الواقعية.

تبين أن بعض اختبارات الوحدة كانت شديدة التقييد أو تفتقر إلى الاتساق مع جوهر المهمة، الأمر الذي تسبب في رفض حلول برمجية صحيحة.
جاءت صياغة العديد من المهام غير مكتملة المواصفات، مما سمح بوجود عدة تأويلات صحيحة للمسألة، بينما اقتصرت الاختبارات البرمجية على التحقق من تأويل واحد فقط.
تبعًا لطريقة إعداد بيئة التشغيل (مثل الفوارق بين نظامي Linux وWindows أو إصدار لغة Python)، كانت بعض الاختبارات عرضة للفشل العارض وغير الحقيقي.

بهدف تلافي العيوب السابقة، استحدثنا مقياس SWE-bench Verified في عام 2024، حيث استعنا بنخبة من مهندسي البرمجيات المتخصصين لتدقيق 1,699 مسألة برمجية وتصفية المسائل التي عانت من تلك الثغرات. وقد فحص ثلاثة خبراء كل مسألة بصورة منفردة، مما أدى في النهاية إلى خروج SWE-bench Verified للنور كمجموعة بيانات مصطفاة تحتوي على 500 مسألة عالية الجودة.

حالات الاختبار الضيقة والفضفاضة

على الرغم من النقلة النوعية التي حققها مقياس SWE-bench Verified مقارنة بالإصدار الأول، إلا أن ثمة رواسب من المشكلات التقنية ظلت عالقة. ومن هذا المنطلق، باشرنا عملية فحص لـ 138 مسألة ضمن هذا المقياس، وهي المسائل التي لم يتمكن نموذج OpenAI o3 من تقديم حل مطرد لها خلال 64 محاولة تشغيل منفصلة. وقد تولى مراجعة كل حالة، وبصورة مستقلة، ما لا يقل عن ستة من مهندسي البرمجيات المتمرسين، مع إحالة أي مسألة يرصد فيها الخبير مشكلة إلى فريق فني آخر لإعادة التوثق منها.

كشف تحليلنا أن 59.4% من المسائل الـ 138 تشوبها عيوب ملموسة في بنية الاختبارات أو في وصف المسائل البرمجية، وهو ما جعل من عملية حلها مهمة شاقة للغاية أو مستحيلة، حتى عند الاستعانة بأكثر النماذج تطورًا أو بالخبراء البشر.

تبين أن 35.5% من المهام المفحوصة تعتمد حالات اختبار شديدة التقييد تُلزم النموذج باتباع جزئيات تنفيذية معينة، الأمر الذي يترتب عليه إبطال العديد من المساهمات البرمجية السليمة وظيفيًا؛ ونسمي هذا النمط 'حالات الاختبار الضيقة'.
سجلت 18.8% من المهام وجود اختبارات تفحص مزايا برمجية إضافية لم ترد في التوصيف الأساسي للمسألة، وهو ما اصطلحنا على تسميته 'حالات الاختبار الفضفاضة'.
في حين عانت نسبة 5.1% المتبقية من مشكلات متفرقة لم تكن متوافقة تمامًا مع معايير هذا التصنيف التقني.

تعتبر الحالة pylint-dev__pylint-4551⁠(يفتح في نافذة جديدة) مثالًا شارحًا لنمط الفشل الأولى، إذ يتضمن طلب السحب دالة مبتكرة تُدعى `get_annotation` ضمن الحل المتكامل. ورغم خلو توصيف المسألة من أي إشارة لاسم هذه الدالة، فإن الاختبارات تعتمد عليها عبر الاستيراد المباشر. ورغم احتمالية أن تتنبأ بعض النماذج تلقائيًا بإنشاء دالة كهذه، فإن معالجة المشكلة بدقة لا تتطلب بالضرورة تنفيذ دالة بهذا الاسم الحرفي؛ الأمر الذي يترتب عليه فشل الكثير من الحلول الوجيهة في اجتياز الاختبارات نتيجة لوقوع أخطاء في الاستيراد.

وصف المسألة

نص عادي

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)]

مقتطف من اختبار طلب السحب

Python

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

إخفاقات اختبارات طلبات السحب (مقتطعة لسهولة القراءة)

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)

تعتبر الحالة sympy__sympy-18199⁠(يفتح في نافذة جديدة) مثالًا على حالات الاختبار الفضفاضة. فقد أُخذت هذه المهمة من طلب سحب كان يستهدف معالجة ثلاث ثغرات منفصلة في الدالة `nthroot_mod` (تحديدًا المشكلات 17373#⁠(يفتح في نافذة جديدة) و17377#⁠(يفتح في نافذة جديدة) و18212#⁠(يفتح في نافذة جديدة)). غير أن الوصف المقدم للمهمة ضمن مقياس SWE-bench Verified لا يتناول سوى المشكلة الأخيرة 18212#⁠(يفتح في نافذة جديدة). ويؤدي هذا إلى تضارب واضح: فاختبارات طلب السحب تشمل الإصلاحات الثلاثة معًا، في حين يسرد التوصيف تفاصيل إصلاح واحد فقط. وخلال تجاربنا، نجد أن النماذج تنجح غالبًا في تطبيق الإصلاح المطلوب، لكنها تتعثر في الاختبارات التي تفحص الجوانب المتعلقة بالمشكلتين غير المذكورتين.

وصف طلب السحب الأصلي (من GitHub PR)

نص عادي

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

وصف المشكلة 18212#

نص عادي

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.

وصف المسألة لمهمة SWE-bench Verified (مأخوذ فقط من #18212):

نص عادي

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.

تلوث البيانات

"نظراً لأن SWE-bench Verified والمستودعات المرتبطة به (بما تتضمنه من قواعد برمجية وملاحظات إصدار) تندرج ضمن المصادر المفتوحة شائعة الاستخدام والتداول، فإن ذلك يضع مطوري النماذج أمام تحدٍ كبير في تفادي تلوث بيانات التدريب.

وقد بدأنا في ملاحظة بوادر هذا التلوث في نماذجنا؛ حيث تمكن نموذج GPT‑5.2 من اجتياز 31 مهمة كنا قد حددنا استحالة حلها تقريبًا. وفي المسألة المتعلقة بـ django__django-14725⁠(يفتح في نافذة جديدة) تشترط الاختبارات استخدام مُعامل جديد ومحدد يُدعى `edit_only` رغم غياب أي نص صريح يوجب ذلك في بيان المسألة. وخلال محاولة الحل، كشف نموذج GPT‑5.2 عما يدور في سلسلة أفكاره، مبينًا اطلاعه على ملاحظات الإصدار التي تشرح التعديلات البرمجية، بل وحدد بدقة أن المُعامل `edit_only` قد جرى تقديمه لأول مرة في إصدار Django 4.1.

تسلسل التفكير لنموذج GPT‑5.2

نص عادي

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.

ولتقييم مدى خطورة تلوث البيانات بشكل أوسع، أنشأنا اختبار تقييم مخاطر آليًا؛ حيث كلفنا نموذج GPT‑5 بمهمة فحص واستقصاء كل من GPT‑5.2‑Chat وClaude Opus 4.5 وGemini 3 Flash Preview بحثًا عن مؤشرات على تلوث البيانات في كل سؤال من أسئلة SWE-bench Verified. وقد تم اختيار هذه النماذج تحديدًا لاستبعاد نماذج الاستدلال، مع إقرارنا بوجود فجوة ملموسة وغير ضئيلة في القدرات فيما بينها.

وللكشف عن تلوث البيانات، تم تزويد GPT‑5 بمعرف المهمة ووصفها والمعيار الذهبي واختبارات طلب السحب المعنية. وخلال 15 جولة، أُتيح لنموذج GPT‑5 تغيير صيغ مطالبات المطور والمستخدم، واستخدام تقنية التعبئة المسبقة لرد المساعد، واتباع أساليب استنطاق متنوعة. وعقب كل جولة، تولى نموذج تقييم تحديد حجم المعلومات المستجدة والمتعلقة بالمهمة، وصُنفت شدة التلوث في كل رد من 'لا يوجد' إلى 'تلوث شديد'. كما مُنح نموذج GPT‑5 القدرة على تعديل منهجيته استنادًا إلى نتائج الجولات السابقة لاسترداد التفاصيل الدقيقة للمهمة بصورة تراكمية. وفي حالات التلوث الشديد، جرى التوثق عبر نموذج تقييم إضافي لضمان عدم قيام نموذج GPT‑5 بتسريب معلومات جوهرية للنموذج الخاضع للاختبار، ليتْبَع ذلك مراجعة بشرية لحالات 'التلوث الشديد' التي نُشرت محاضرها هنا.

فيما يلي أمثلة على التلوث الشديد عبر مزوّدي نماذج مختلفة.

GPT‑5.2

عند تزويده بفقرة موجزة من وصف المهمة، يخرج نموذج GPT‑5.2 مخرجات تطابق المعيار الذهبي حرفيًا. ويتجلى ذلك بوضوح في معرفته بالأسماء المحددة للفئة والدالة، فضلًا عن شرط العودة المسبقة الجديد `if username is None or password is None` الذي تم إدراجه في الكود.

معرّف المهمة: django__django-11451⁠(يفتح في نافذة جديدة)

استنباط تلوث البيانات

بيان المسألة

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

مطالبة المستخدم

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"

استجابة النموذج

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.

المعيار الذهبي

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 استحضار التغيير الوظيفي الدقيق ذي الأسطر الأربعة الذي أُدخل عبر طلب السحب، مع تحديد اسم الملف والمنهج البرمجي المعني، بل ويتجاوز ذلك ليقتبس لفظيًا التعليق المضمن الذي ورد ضمن ملف مقارنة التعديلات (الفروقات).

معرّف المهمة: astropy__astropy-13236⁠(يفتح في نافذة جديدة)

استنباط تلوث البيانات

مطالبة المستخدم

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.

التعبئة المسبقة

1Let 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
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

المعيار الذهبي

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 قدرة على استرجاع تفاصيل لفظية مطابقة للنص من كل من وصف المهمة والمعيار الذهبي. وتشمل هذه البيانات صيغة regex الجديدة المستحدثة لتدقيق أسماء المستخدمين، مع تحديد أرقام الأسطر الفعلية التي أُجري عليها التغيير البرمجي بكل دقة.

معرّف المهمة: django__django-11099⁠(يفتح في نافذة جديدة)

استنباط تلوث البيانات

بيان المسألة

1UsernameValidator allows trailing newline in usernames

مطالبة المستخدم

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.

التعبئة المسبقة

1Let me be precise about the wording.

استجابة النموذج

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

المعيار الذهبي

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

النقاش

يسلط هذا الفحص الشامل لمقياس SWE-bench Verified الضوء على درسين جوهريين في هندسة التقييم. الأول هو أن المقاييس المستقاة من مصادر عامة تظل عرضة لمخاطر تلوث البيانات، حيث يتسبب انكشاف النماذج على بيانات التدريب في رفع النتائج صوريًا وبصمت. وفي حال الاعتماد على بيانات تم جمعها من الويب في تشييد هذه المقاييس، يتحتم على مطوري النماذج تنفيذ فحوصات إضافية لتلوث البيانات. فالمقاييس المرجعية وحلولها المدرجة في الفضاء العام غالبًا ما تتسرب إلى بيانات التدريب؛ مما يستدعي عناية فائقة في أسلوب نشر مجموعات البيانات (كاستخدام الحماية بكلمة مرور) وفي آليات تنقية بيانات التدريب (مثل الامتثال الحرفي لوسوم سلاسل Canary).

يتمثل الدرس الثاني في أن الوصول لآلية تقييم آلي دقيقة هو أمر محفوف بالتحديات؛ إذ ينبغي لحالات الاختبار النموذجية أن توثق سلامة الوظائف البرمجية بالكامل، مع اتصافها بالحياد تجاه جزئيات التنفيذ الثانوية، والحصانة ضد الحلول المختصرة. وبما أن هذه المشكلات متأصلة في التعقيد ويصعب تلافيها، فقد تطلب الكشف عنها تنفيذ حملات مراجعة وتصنيف بشرية واسعة النطاق وعلى مراحل متعددة.

لقد دمجنا هذه الاستنتاجات ضمن مساعينا الأخيرة في عمليات التقييم، حيث اعتمدنا في الأشهر الأخيرة الإعلان عن نتائج القسم المتاح للجمهور من مقياس SWE-bench Pro، كما نحث مطوري النماذج الآخرين على اتباع هذا النهج. ومع أن SWE-bench Pro لا يخلو من العيوب، إلا أن المؤشرات العملية تشير إلى تراجع حدة مشكلات تلوث البيانات فيه. وبالفعل، كشف مسار فحص تلوث البيانات لدينا عن بعض الحالات، إلا أنها كانت أقل تكرارًا وأقل جسامة بمراحل من تلك الموجودة في SWE-bench Verified، كما لم يستطع أي نموذج استحضار المعيار الذهبي حرفيًا وبشكل كامل.

وسوف نمضي قدمًا في تخصيص الموارد لابتكار مقاييس مرجعية حصرية ومعدة خصيصًا، مع دعوة المجتمع التقني والبحثي للمشاركة في هذا المسعى. وتعتمد منهجية GDPVal⁠ على صياغة المهام من قِبل خبراء متمرسين بعيدًا عن الفضاء العام لتلافي مخاطر تلوث البيانات، كما تُمنح الدرجات للحلول بناءً على نظرة شمولية من مراجعين مختصين. ورغم الكلفة العالية لهذا النهج من حيث الموارد، إلا أن أهميته تتضاعف كونه السبيل الوحيد لرصد القفزات الحقيقية في كفاءة الاستدلال.

2026

المؤلف

OpenAI

متابعة القراءة

عرض الكل

Better memory for a more helpful ChatGPT

أساس أقوى لذاكرة ChatGPT

البحث4 يونيو 2026

تقديم قدرات جديدة إلى GPT-Rosalind

المنتج3 يونيو 2026

تعزيز المرونة المجتمعية عبر Rosalind Biodefense

المنتج29 مايو 2026