اگست 2024 میں جب سے ہم نے پہلی بار SWE-bench Verified شائع کیا، صنعت نے اسے خود مختار سافٹ ویئر انجینئرنگ ٹاسکس پر ماڈل کی پیش رفت کی پیمائش کرنے کے لیے بڑے پیمانے پر استعمال کیا ہے. اس کی ریلیز کے بعد، SWE-bench Verified نے صلاحیت میں پیش رفت کا ایک مضبوط اشارہ فراہم کیا اور جدید ترین ماڈل ریلیزز میں رپورٹ کیا جانے والا ایک معیاری میٹرک بن گیا. ان صلاحیتوں کی پیش رفت کی نگرانی اور پیش گوئی کرنا بھی OpenAI کے پریفرنس فائن-ٹیوننگ کا ایک اہم حصہ ہے. جب ہم نے ابتدا میں Verified بینچ مارک بنایا، تو ہم نے اصل تشخیص میں موجود اُن مسائل کو حل کرنے کی کوشش کی جن کی وجہ سے SWE-بینچ ڈیٹاسیٹ(نئی ونڈو میں کھلتا ہے) میں بعض کاموں کو انجام دینا ناممکن ہو جاتا تھا.
ابتدائی چھلانگوں کے بعد، SWE-بینچ تصدیق شدہ پر اعلٰی ترین پیش رفت سست ہو گئی ہے، گزشتہ 6 ماہ میں 74.9% سے 80.9% تک بہتری(نئی ونڈو میں کھلتا ہے) کے ساتھ. اس سے یہ سوال پیدا ہوتا ہے: کیا باقی ناکامیاں ماڈل کی حدود کی عکاسی کرتی ہیں یا خود ڈیٹاسیٹ کی خصوصیات؟
ایک نئے تجزیے میں، ہمیں Verified سیٹ کے ساتھ دو بڑے مسائل ملے جو اس بات کی نشاندہی کرتے ہیں کہ آج کی کارکردگی کی سطحوں پر جدید ترین لانچز کے لیے خودمختار سافٹ ویئر انجینئرنگ کی صلاحیتوں میں پیش رفت کی پیمائش کے لیے یہ بینچ مارک اب موزوں نہیں رہا.
- ٹیسٹ درست حلوں کو مسترد کرتے ہیں: ہم نے ڈیٹاسیٹ کے 27.6% ذیلی حصے کا آڈٹ کیا جسے ماڈل اکثر حل کرنے میں ناکام رہے اور پایا کہ کم از کم 59.4% آڈٹ کیے گئے مسائل میں ناقص ٹیسٹ کیسز ہیں جو فعالی طور پر درست سبمشنز کو مسترد کرتے ہیں، SWE-bench Verified کی ابتدائی تخلیق میں اس کو بہتر بنانے کی ہماری بھرپور کوششوں کے باوجود.
- حلوں پر تربیت: چونکہ بڑے جدید ترین ماڈلز اپنی تربیت سے معلومات سیکھ سکتے ہیں، اس لیے یہ اہم ہے کہ انہیں کبھی بھی ان مسائل اور حلوں پر تربیت نہ دی جائے جن پر ان کی جانچ کی جاتی ہے. یہ امتحان سے پہلے طلباء کے ساتھ آنے والے امتحان کے مسائل اور حل بتانے کے مترادف ہے - ہو سکتا ہے وہ جواب یاد نہ رکھیں لیکن جن طلباء نے پہلے جوابات دیکھے ہوں وہ یقیناً ان سے بہتر کارکردگی کا مظاہرہ کریں گے۔ SWE-bench مسائل اوپن سورس ریپوزٹریز سے لیے گئے ہیں جنہیں بہت سے ماڈل فراہم کنندگان تربیتی مقاصد کے لیے استعمال کرتے ہیں. ہمارے تجزیے میں ہم نے پایا کہ جن تمام جدید ترین ماڈلز کا ہم نے ٹیسٹ کیا وہ اصل، انسان کے لکھے ہوئے بگ فکس کو دوبارہ پیش کرنے کے قابل تھے جسے گراؤنڈ ٹروتھ ریفرنس کے طور پر استعمال کیا گیا تھا، جسے گولڈ پیچ کہا جاتا ہے، یا بعض کاموں کے لیے مسئلے کے بیان کی لفظ بہ لفظ مخصوص تفصیلات، جو اس بات کی نشاندہی کرتا ہے کہ ان سب نے تربیت کے دوران کم از کم کچھ مسائل اور حل دیکھے ہیں.
ہمیں یہ بھی شواہد ملے کہ جن ماڈلز نے تربیت کے دوران مسائل دیکھے ہوتے ہیں، ان کے کامیاب ہونے کا امکان زیادہ ہوتا ہے، کیونکہ ان کے پاس وضاحت ناکافی ٹیسٹ پاس کرنے کے لیے درکار اضافی معلومات ہوتی ہیں.
اس کا مطلب یہ ہے کہ SWE-bench Verified پر بہتریاں اب ماڈل کی حقیقی دنیا میں سافٹ ویئر ڈیولپمنٹ کی صلاحیتوں میں بامعنی بہتری کی عکاسی نہیں کرتیں. اس کے بجائے، وہ بڑھتے ہوئے طور پر اس بات کی عکاسی کرتے ہیں کہ تربیت کے وقت ماڈل کو بینچ مارک کے سامنے کتنا رکھا گیا تھا. اسی لیے ہم نے SWE-bench Verified اسکورز کی رپورٹنگ بند کر دی ہے اور ہم تجویز کرتے ہیں کہ دوسرے ماڈل ڈویلپرز بھی ایسا ہی کریں.
ہم کوڈنگ کی صلاحیتوں کو بہتر طور پر ٹریک کرنے کے لیے نئی، غیر آلودہ تشخیصات تیار کر رہے ہیں اور ہمیں لگتا ہے کہ وسیع تر تحقیقی کمیونٹی کے لیے یہ توجہ مرکوز کرنے کا ایک اہم شعبہ ہے. جب تک ہمارے پاس وہ نہیں ہوتے، OpenAI SWE-bench Pro کے لیے نتائج رپورٹ کرنے کی سفارش کرتا ہے.
اصل SWE-بینچ(نئی ونڈو میں کھلتا ہے) تشخیص 2023 میں جاری کی گئی تھی. ہر مسئلہ 12 اوپن سورس Python ریپوزٹریز میں سے کسی ایک میں حل شدہ GitHub issue سے ماخوذ ہے اور متعلقہ پل ریکوئسٹ (PR) کے ساتھ جوڑا گیا ہے. یہ تعین کرنے کے لیے کہ آیا ماڈل کے ذریعے تیار کردہ کوڈ میں تبدیلی درست ہے، ہر مسئلے کے ساتھ ٹیسٹ کے دو سیٹ آتے ہیں:
- وہ ٹیسٹ جو غیر ترمیم شدہ کوڈ بیس پر ناکام ہوتے ہیں لیکن اگر مسئلہ درست طور پر حل کر دیا جائے تو پاس ہو جاتے ہیں
- ریگریشن ٹیسٹ جو اصلاح سے پہلے اور بعد دونوں میں پاس ہوں تاکہ غیر متعلقہ فعالیت برقرار رہے.
ماڈل ٹیسٹ نہیں دیکھتا ہے۔ اسے درست کرنے سے پہلے صرف اصل ایشو ٹیکسٹ اور ریپوزٹری کی حالت کو دیکھتے ہوئے کوڈ میں تبدیلی پیدا کرنی ہوگی۔ یہ ایک مسئلہ صرف اس صورت میں گزرتا ہے جب کوڈ کی تبدیلی کے لاگو ہونے کے بعد تمام ٹیسٹ پاس ہوجاتے ہیں۔
ہمیں اس تشخیص کے ساتھ بہت سے مسائل ملے جو ماڈلز کی صلاحیت کو کم کرنے کا باعث بن سکتے ہیں۔
- کچھ یونٹ ٹیسٹ حد سے زیادہ مخصوص تھے یا کام کے ساتھ غلط طریقے سے منسلک تھے تاکہ درست اصلاحات کو مسترد کیا جا سکے۔
- بہت سے کام کے بیانات کو کم بیان کیا گیا تھا، جو متعدد درست تشریحات کا باعث بن سکتے ہیں - جبکہ ٹیسٹس میں صرف ایک مخصوص کا احاطہ کیا گیا تھا۔
- ماحول کی سیٹ اپ کے لحاظ سے (مثال کے طور پر Linux بمقابلہ Windows، یا python ورژن)، کچھ ٹیسٹ غلط طور پر ناکام ہو سکتے ہیں
ہم نے 2024 میں ان مسائل کو حل کرنے کے لیے SWE-bench تصدیق شدہ بنایا. ہم نے ماہر سافٹ ویئر انجینئروں کے ساتھ مل کر 1,699 SWE-bench مسائل کا جائزہ لیا اور ان مسائل کو چھانٹ کر الگ کر دیا جن میں یہ مسائل تھے. ہر مسئلے کا تین ماہرین نے آزادانہ طور پر جائزہ لیا. اس جائزہ عمل کے نتیجے میں SWE-bench تصدیق شدہ سامنے آیا، جو 500 مسائل کا ایک منتخب مجموعہ ہے.
اگرچہ SWE-bench Verified ابتدائی ورژن کے مقابلے میں ایک بڑی بہتری ہے، لیکن کچھ باقی ماندہ مسائل اب بھی موجود ہیں. ہم نے 138 SWE-bench Verified مسائل کا آڈٹ کیا جنہیں OpenAI o3 نے 64 آزادانہ رنز کے دوران مستقل طور پر حل نہیں کیا. ہر کیس کا کم از کم چھ تجربہ کار سافٹ ویئر انجینئرز نے آزادانہ طور پر جائزہ لیا. اگر کسی ماہر نے کسی مسئلے کی نشاندہی کی، تو اس کی ایک اضافی ٹیم نے دوبارہ تصدیق کی.
ہم نے پایا کہ 138 مسائل میں سے 59.4% میں ٹیسٹ ڈیزائن اور/یا مسئلے کی وضاحت میں بنیادی نوعیت کے مسائل موجود تھے، جس کی وجہ سے وہ انتہائی قابل ماڈل یا انسان کے لیے بھی حل کرنا نہایت مشکل یا ناممکن ہو گئے.
- آڈٹ کردہ ٹاسکس میں سے 35.5% میں سخت ٹیسٹ کیسز ہوتے ہیں جو نفاذ کی مخصوص تفصیلات نافذ کرتے ہیں، جس سے بہت سی فعالی طور پر درست جمع کرائی گئی سبمشنز غلط قرار پاتی ہیں، جنہیں ہم تنگ ٹیسٹ کیسزکہتے ہیں.
- آڈٹ کیے گئے ٹاسکس میں سے 18.8% کے پاس ایسے ٹیسٹس ہیں جو اضافی فعالیت کی جانچ کرتے ہیں جو مسئلے کی وضاحت میں بیان نہیں کی گئی تھی، جنہیں ہم وسیع ٹیسٹ کیسزکہتے ہیں.
- باقی 5.1% ٹاسکس میں متفرق مسائل تھے جن کی اس ٹیکسانومی کے ساتھ اچھی طرح گروپ بندی نہیں کی گئی تھی.
پہلے ناکامی کے موڈ کی ایک توضیحی مثال pylint-dev__pylint-4551(نئی ونڈو میں کھلتا ہے) ہے، جہاں PR مجموعی حل کے حصے کے طور پر ایک نیا فنکشن `get_annotation` متعارف کراتا ہے. اس فنکشن کا نام مسئلے کی وضاحت میں ذکر نہیں کیا گیا، لیکن ٹیسٹس کے ذریعے براہِ راست امپورٹ کیا جاتا ہے. اگرچہ کچھ ماڈلز بدیہی طور پر ایسا فنکشن بنانے کی طرف مائل ہو سکتے ہیں، لیکن مسئلے کو درست طریقے سے حل کرنے کے لیے اس مخصوص نام کے ساتھ فنکشن نافذ کرنا سختی سے ضروری نہیں ہے. بہت سے درست حل امپورٹ کی خرابیوں کی وجہ سے ٹیسٹس میں ناکام ہو جاتے ہیں.
مسئلے کی تفصیل
PR ٹیسٹ اسنیپٹ
PR ٹیسٹ فیلئرز (پڑھنے میں آسانی کے لیے مختصر کردہ)
بہت زیادہ وسیع ٹیسٹ کیسز کی ایک مثال sympy__sympy-18199(نئی ونڈو میں کھلتا ہے) ہے. یہ ٹاسک ایک PR سے لیا گیا تھا جس نے `nthroot_mod` فنکشن کے ساتھ تین الگ مسائل کو حل کیا تھا، خاص طور پر #17373(نئی ونڈو میں کھلتا ہے), #17377(نئی ونڈو میں کھلتا ہے) اور #18212(نئی ونڈو میں کھلتا ہے). تاہم، SWE-bench Verified ٹاسک کی وضاحت صرف آخری مسئلے #18212(نئی ونڈو میں کھلتا ہے) کا احاطہ کرتی ہے. اس سے عدم مطابقت پیدا ہوتی ہے: PR ٹیسٹس تینوں مسائل کا احاطہ کرتے ہیں، جبکہ تفصیل میں صرف ایک کی وضاحت ہے. ہمارے رنز میں، ماڈلز اکثر بیان کردہ درستگی کو صحیح طور پر نافذ کرتے ہیں اور پھر ان ٹیسٹس میں ناکام ہو جاتے ہیں جو باقی دو مسائل کے لیے امپلیمینٹیشن کو کور کرتے ہیں.
اصل PR کی تفصیل (GitHub PR سے)
#18212 کے مسئلے کی تفصیل
SWE-bench تصدیق شدہ ٹاسک کے لیے مسئلے کی تفصیل (صرف #18212 سے لی گئی):
SWE-bench Verified اور ریپوزٹریز (کوڈ بیسز اور ریلیز نوٹس) دونوں اوپن سورس ہیں اور وسیع پیمانے پر استعمال اور زیرِ بحث ہیں، جس کی وجہ سے ماڈل ڈویلپرز کے لیے آلودگی سے بچنا مشکل ہو جاتا ہے.
ہم نے سب سے پہلے آلودگی کی علامات اپنے ہی ماڈلز میں دیکھی تھیں. مثال کے طور پر، جب GPT‑5.2 نے 31 ایسے ٹاسک حل کیے جنہیں ہم نے تقریباً ناممکن قرار دیا تھا. django__django-14725(نئی ونڈو میں کھلتا ہے) میں ٹیسٹس کے لیے ایک مخصوص نیا پیرامیٹر `edit_only` درکار ہے، جو مسئلے کے بیان میں واضح طور پر ضروری نہیں ہے. مسئلہ حل کرتے وقت، GPT‑5.2 اپنے چین آف تھاٹ میں دکھاتا ہے کہ اس کے پاس ریلیز نوٹس کے بارے میں معلومات ہیں جو کوڈبیس میں تبدیلیوں کی تفصیل دیتے ہیں اور درست طور پر شناخت کرتا ہے کہ `edit_only` پیرامیٹر Django 4.1 میں متعارف کرایا گیا تھا.
GPT‑5.2 CoT
آلودگی کی مجموعی اہمیت کا اندازہ لگانے کے لیے، ہم نے ایک خودکار ریڈ ٹیمنگ سیٹ اپ بنایا. SWE-bench Verified کے ہر سوال کے لیے، ہم نے GPT‑5 کو GPT‑5.2‑Chat کی جانچ کا کام سونپا، Claude Opus 4.5 اور Gemini 3 Flash Preview آلودگی کے لیے. ان ماڈلز کا انتخاب استدلال ماڈلز کو خارج کرنے کے لیے کیا گیا تھا، لیکن ہم تسلیم کرتے ہیں کہ ان کے درمیان غالباً ایک غیر معمولی صلاحیت کا فرق موجود ہے.
آلودگی کی جانچ کے لیے، GPT‑5 کو یہ موصول ہوا: SWE-bench Verified ٹاسک کی ID، تفصیل، گولڈ پیچ اور PR ٹیسٹس. 15 سے زیادہ باریوں کے دوران، ہم نے GPT‑5 کو سسٹم/ڈیولپر پرومپٹ، صارف پرومپٹ اور اسسٹنٹ پری فل کو مختلف کرنے اور مختلف استخراجی حکمتِ عملیاں آزمانے کی اجازت دی. ہر ٹرن کے بعد، ایک جج ماڈل نے یہ لیبل کیا کہ کتنا نیا ٹاسک-مخصوص معلومات ظاہر ہوئی اور ہر جواب کو آلودگی کی شدت کے لیے “none” سے “strong” تک لیبل کیا گیا. GPT‑5 کو یہ اجازت دی گئی کہ وہ پچھلے ٹرنز کی بنیاد پر اپنی حکمتِ عملی کو ڈھالے تاکہ ٹاسک سے متعلق مخصوص تفصیلات کو مرحلہ وار بازیافت کر سکے. مضبوط آلودگی کی ہر مثال کے لیے، ہم نے ایک دوسرے جج کے ساتھ تصدیق کی کہ GPT‑5 نے ہدف ماڈل کو بہت زیادہ معلومات لیک نہیں کیں. آخر میں، پھر ہم نے اس پوسٹ میں موجود ٹرانسکرپٹس پر مشتمل “strong” مثالوں کا دستی طور پر جائزہ لیا.
ذیل میں مختلف ماڈل فراہم کنندگان کے درمیان شدید آلودگی کی مثالیں دی گئی ہیں.
ٹاسک کی تفصیل سے ایک مختصر اقتباس دیئے جانے پر، GPT‑5.2 بالکل وہی گولڈ پیچ آؤٹ پٹ کرتا ہے. خاص طور پر، یہ بالکل درست کلاس اور طریقہ کا نام جانتا ہے، اور نئی ابتدائی واپسی کی شرط `اگر صارف نام کوئی نہیں ہے یا پاس ورڈ کوئی نہیں ہے` متعارف کرایا گیا ہے۔
ٹاسک آئی ڈی: django__django-11451(نئی ونڈو میں کھلتا ہے)
آلودگی کا خاتمہ
گولڈ پیچ
Opus نہ صرف PR کی متعارف کردہ عین 4 لائنوں کی فنکشنل تبدیلی کو، اس کے ساتھ مخصوص فائل نام اور اس میتھڈ سمیت جسے اس نے چھوا تھا، یاد کر سکتا ہے، بلکہ diff کا حصہ ہونے والے ان لائن کمینٹ کو بھی لفظ بہ لفظ نقل کرتا ہے.
ٹاسک آئی ڈی: astropy__astropy-13236(نئی ونڈو میں کھلتا ہے)
آلودگی کا خاتمہ
گولڈ پیچ
Gemini 3 Flash، جب اسے ID کے علاوہ ٹاسک کے بارے میں مزید کوئی معلومات نہیں دی جاتی، تو یہ ٹاسک کی تفصیل اور گولڈ پیچ سے لفظ بہ لفظ تفصیلات آؤٹ پٹ کرنے کے قابل ہوتا ہے. اس میں یوزر نیم کی توثیق کے لیے نیا regex فارمولا اور تبدیلی کے لیے عین لائن نمبرز شامل ہیں.
آلودگی کا خاتمہ
گولڈ پیچ
SWE-bench Verified کے اس آڈٹ سے، ہم تشخیص کے ڈیزائن کے لیے دو وسیع تر اسباق دیکھتے ہیں. سب سے پہلے، عوامی طور پر دستیاب مواد سے حاصل کردہ بینچ مارکس میں آلودگی کا خطرہ ہوتا ہے، جہاں تربیتی ڈیٹا کی نمائش خاموشی سے اسکورز کو بڑھا سکتی ہے. اگر عوامی طور پر کرال کیے گئے ڈیٹا کو بینچ مارک کی تشکیل میں استعمال کیا جائے، تو ماڈل ڈیولپرز کو آلودگی کے لیے اضافی ٹیسٹ کرنے چاہئیں. بینچ مارکس اور حتیٰ کہ ان کے حل بھی، اگر عوامی طور پر پوسٹ کیے جائیں تو ٹریننگ ڈیٹا میں شامل ہو سکتے ہیں. ڈیٹاسیٹس کو پوسٹ کرنے کے طریقے میں بھی اضافی احتیاط برتنی چاہیے (یعنی پاس ورڈ سے محفوظ) اور تربیتی ڈیٹا کو فلٹر کرنا (یعنی کینری اسٹرنگز کی سخت پابندی).
دوسرا، خودکار اسکورنگ کو درست کرنا مشکل ہے؛ بہترین ٹیسٹ کیسز کو درست فعالیت کی مکمل تصدیق کرنی چاہیے، اس طرح کہ وہ مخصوص غیر اہم نفاذی تفصیلات سے غیر وابستہ بھی ہوں اور شارٹ کٹ حلوں کے خلاف مضبوط بھی. یہ مسائل فطری طور پر پیچیدہ ہیں اور حل کرنا مشکل ہے. ان مسائل کو پکڑنے کے لیے متعدد وسیع انسانی لیبلنگ مہمات درکار تھیں.
ہم نے ان نتائج کو اپنی حالیہ تشخیصی کوششوں میں شامل کیا ہے. گزشتہ مہینوں میں ہم نے SWE-Bench Pro کے پبلک اسپلٹ سے نتائج رپورٹ کرنے کا انتخاب کیا ہے. ہم تجویز کرتے ہیں کہ دوسرے ماڈل ڈویلپرز بھی ایسا ہی کریں. SWE-bench Pro کامل نہیں ہے، لیکن تجرباتی طور پر لگتا ہے کہ یہ آلودگی کے مسائل سے کم متاثر ہوتا ہے. ہماری آلودگی کی پائپ لائن نے آلودگی کے کچھ معاملات پائے، لیکن یہ معاملات SWE-bench Verified کے مقابلے میں نمایاں طور پر زیادہ نایاب اور کم سنگین تھے اور کوئی بھی ماڈل مکمل لفظ بہ لفظ گولڈ پیچ تیار کرنے کے قابل نہیں تھا.
ہم اصل، نجی طور پر تحریر کردہ بینچ مارکس میں سرمایہ کاری جاری رکھیں گے اور صنعت اور اکیڈمیا سے بھی یہی کرنے کے لیے مدد طلب کریں گے. In GDPVal، ٹاسک نجی طور پر شعبہ ماہرین کے ذریعہ تحریر کیے جاتے ہیں، جس سے ایکسپوژر کے خطرے میں کمی آتی ہے اور حل تربیت یافتہ ریویورز کے ذریعہ مجموعی طور پر گریڈ کیے جاتے ہیں. یہ طریقہ کار وسائل کے لحاظ سے بھاری ہے، لیکن حقیقی صلاحیتوں میں بہتری کی پیمائش کرنے کے لیے تیزی سے ضروری ہوتا جا رہا ہے.


