SWE-bench (benchmark) (FA)

From Systems analysis Wiki
Jump to navigation Jump to search

SWE-bench — یک benchmark گسترده (مجموعه‌ای از وظایف آزمایشی) برای ارزیابی توانایی‌های مدل‌های زبانی بزرگ (LLM) در حوزه توسعه خودکار و اشکال‌زدایی نرم‌افزار است[1]. این benchmark توسط گروهی از پژوهشگران دانشگاه پرینستون و سازمان‌های دیگر توسعه یافته و در کنفرانس ICLR 2024 معرفی شده است[2]. SWE-bench از benchmark‌های کدنویسی سنتی با استفاده از وظایف واقعی از عمل توسعه متمایز می‌شود: مجموعه آزمایشی شامل ۲۲۹۴ وظیفه است که بر اساس مشکلات بسته‌شده (issues) و اصلاحات متناظر (pull request) از ۱۲ مخزن محبوب متن‌باز Python در GitHub طراحی شده‌اند[1][3]. هر وظیفه شامل توضیح مشکل (issue) است و به مدل دسترسی به کد منبع پروژه مربوطه را می‌دهد؛ هدف مدل تولید حداقل تغییرات در پایگاه کد (patch) است که مشکل مشخص‌شده را برطرف کند[1][3].

روش‌شناسی و ویژگی‌های ارزیابی

SWE-bench فرآیند واقعی توسعه نرم‌افزار را شبیه‌سازی می‌کند. برای هر وظیفه، متن GitHub issue اصلی (توضیح مشکل) و snapshot کد مخزن در نسخه قبل از اعمال اصلاح به مدل ارائه می‌شود[4]. مدل (یا agent مبتنی بر مدل) باید کد منبع را تحلیل کند، ماهیت خطا یا تغییر موردنیاز را درک کند و تغییرات لازم را در فایل‌های کد مربوطه اعمال نماید تا مشکل را برطرف سازد[4][5]. اعتبارسنجی راه‌حل به صورت خودکار انجام می‌شود: به هر وظیفه آزمون‌های واحد واقعی از pull request که آن مشکل را بسته است متصل است. در میان آن‌ها هم آزمون‌های «شکست‌خورده-قبول‌شده» (fail-to-pass، که روی کد اصلی شکست می‌خورند اما باید پس از اعمال اصلاح صحیح قبول شوند) و هم آزمون‌های رگرسیون (pass-to-pass، که در ابتدا قبول می‌شوند و باید پس از اعمال تغییرات همچنان قبول بمانند) وجود دارند[3]. patch پیشنهادی مدل روی کد اعمال می‌شود، سپس آزمون‌های مربوطه اجرا می‌شوند: اگر همه آزمون‌های fail-to-pass شروع به قبول شدن کنند و آزمون‌های pass-to-pass نقض نشوند، وظیفه به درستی حل‌شده تلقی می‌شود[3]. این رویکرد ارزیابی امکان بررسی نه‌تنها توانایی مدل در تولید کد نحواً صحیح، بلکه توانایی حل واقعی وظیفه محول‌شده بدون نقض عملکرد موجود را فراهم می‌کند. در این فرآیند مدل باید با زمینه بزرگ (کل مخزن کد) کار کند، روابط بین اجزا را درک کند و تغییرات در چندین فایل را به‌طور همزمان هماهنگ سازد[1] — همه اینها به مراتب پیچیده‌تر از وظایف معمول نوشتن یک تابع بر اساس توضیحات است.

در ارزیابی‌های SWE-bench معمولاً نه خود LLM‌ها، بلکه سیستم‌های agent شرکت می‌کنند که مدل را با ابزارهای کمکی (مثلاً برای پیمایش فایل‌ها، اجرای کد، استفاده از debugger و غیره) احاطه می‌کنند[4][6]. چنین سیستمی چرخه واقعی توسعه را تقلید می‌کند: مدل می‌تواند به‌طور متوالی فایل‌ها را مرور کند، آزمون‌ها یا script‌ها را اجرا کند و راه‌حل را به‌تدریج بهبود بخشد تا به نتیجه موفق برسد[4]. قابل توجه است که اثربخشی حل وظایف SWE-bench تا حد زیادی به کیفیت این «scaffolding» (زیرساخت agent) بستگی دارد: مدل‌های پایه یکسان می‌توانند نتایج متفاوتی را بسته به نحوه سازمان‌دهی تعامل با مخزن و ابزارها نشان دهند[4][7]. بدین ترتیب، SWE-bench به عنوان معیاری برای قابلیت‌های مجموع مدل و استراتژی حل وظیفه آن عمل می‌کند و ارزیابی را به شرایط واقعی کار توسعه‌دهنده خودمختار هوش مصنوعی نزدیک‌تر می‌سازد[4][7].

انواع مجموعه وظایف

پدیدآورندگان SWE-bench و جامعه پژوهشی متعاقباً چندین مجموعه مشتق برای اهداف مختلف ارزیابی معرفی کردند:

  • SWE-bench Lite — نسخه سبک‌تر benchmark شامل ~۳۰۰ وظیفه[8] که به گونه‌ای انتخاب شده‌اند تا پیچیدگی و هزینه محاسباتی آزمایش مدل‌ها کاهش یابد. این زیرمجموعه برای آزمایش سریع مدل‌ها ایجاد شده و پرهزینه‌ترین اعتبارسنجی‌ها را حذف می‌کند، در حالی که نمایندگی مشکلات اصلی را حفظ می‌نماید[7]. در اصل، Lite وظایف ساده‌تر و کوتاه‌تر رفع اشکال را در بر می‌گیرد، و نتایج مدل‌ها روی Lite معمولاً بالاتر از مجموعه کامل است، زیرا سخت‌ترین موارد حذف شده‌اند[7].
  • SWE-bench Verified — زیرمجموعه‌ای که از طریق بررسی دستی فیلتر شده و در اوت ۲۰۲۴ همراه با OpenAI معرفی گردید[7]. پژوهشگران ۹۳ توسعه‌دهنده حرفه‌ای را برای تحلیل هر وظیفه از benchmark اصلی جذب کردند و مواردی که توضیح مشکل اصلی بیش از حد مبهم است یا رفتار مورد نیاز آزمون‌ها به‌وضوح از شرایط وظیفه ناشی نمی‌شود را حذف نمودند[7]. همچنین وظایفی که در عمل به دلیل مشکلات محیطی یا آزمون‌های نادرست قابل حل نیستند، حذف شدند[7]. در نهایت مجموعه‌ای از ۵۰۰ وظیفه شکل گرفت که به‌طور تضمینی قابل حل و به درستی فرمول‌بندی شده‌اند[7]. SWE-bench Verified در نظر دارد ارزیابی قابل اطمینان‌تری از قابلیت‌های مدل‌ها را با حذف مواردی که حتی راه‌حل صحیح به دلیل ناکافی بودن آزمون‌ها یا وظیفه رد می‌شود، تأمین کند[7]. این مجموعه جایگزین نمونه‌های آزمایشی اصلی SWE-bench (کامل و Lite) به عنوان مرجع اصلی مقایسه مدل‌ها شد[7]. علاوه بر این، همراه با Verified، ارزیابی‌های سختی وظایف (مثلاً وظایف «آسان» که انسان در کمتر از ۱۵ دقیقه حل می‌کند و وظایف «سخت» که بیش از ۱ ساعت نیاز دارند) منتشر شد[7]، و همچنین چارچوب ابزاری جدیدی مبتنی بر Docker برای اجرای پایدارتر و قابل تکرار آزمون‌ها عرضه گردید[7].
  • SWE-bench Multimodal — گسترش benchmark که در ژانویه ۲۰۲۵ معرفی شد و شامل وظایفی است که توضیح مشکل نه‌تنها متن، بلکه عناصر بصری (مثلاً تصاویر رابط کاربری، اسکرین‌شات‌های خطا و غیره) هم دارد[8]. این مجموعه (۵۱۷ وظیفه[8]) توانایی مدل‌ها و agent‌ها را در درک و استفاده از اطلاعات بصری در حل وظایف برنامه‌نویسی بررسی می‌کند. ارزیابی روی مجموعه چندوجهی به روش مشابه سازمان‌دهی شده، اما نیاز به قابلیت‌های multi-modal از مدل دارد (مثلاً شناسایی متن در تصاویر). بخش آزمایشی SWE-bench Multimodal بسته (پنهان) نگه داشته شده تا از تنظیم راه‌حل‌ها بر اساس پاسخ‌های شناخته‌شده جلوگیری شود؛ توسعه‌دهندگان می‌توانند راه‌حل‌های خود را برای ارزیابی مدل‌هایشان روی این وظایف به leaderboard از راه دور ارسال کنند[2].

علاوه بر این انواع اصلی، اکوسیستمی از ابزارها پیرامون SWE-bench شکل گرفته است: SWE-agent — یک «agent»-حل‌کننده نرم‌افزاری متن‌باز که نتایج پیشرفته‌ای روی وظایف benchmark نشان می‌دهد[2]؛ SWE-smith — چارچوبی برای آموزش مدل‌های توسعه‌دهنده اختصاصی؛ SWE-REX — ابزاری برای استخراج و پردازش پیشرفته اطلاعات از مخازن و غیره. این پروژه‌ها با هدف ساده‌سازی بازتولید نتایج و پیشبرد تحقیقات در حوزه سیستم‌های برنامه‌نویسی خودمختار طراحی شده‌اند.

نتایج و پیشرفت مدل‌ها

در بدو ظهور SWE-bench، شکاف قابل توجهی بین LLM‌های مدرن و مهارت‌های برنامه‌نویسان مجرب آشکار شد. نویسندگان گزارش دادند که حتی قدرتمندترین مدل‌های اوایل ۲۰۲۳ تنها در چند درصد از وظایف موفق می‌شدند: برای مثال، مدل Claude 2 شرکت Anthropic کمتر از ۲٪ از وظایف مجموعه کامل را با موفقیت حل می‌کرد[1]. مدلی که نویسندگان benchmark به‌طور اختصاصی آموزش دادند (مبتنی بر LLaMA، که SWE-Llama نام گرفت) و مدل‌های اختصاصی مانند GPT-4 عمدتاً فقط ساده‌ترین خطاها را می‌توانستند حل کنند[1]. این معیارهای اولیه پایین، پیچیدگی SWE-bench را نشان داد و انگیزه‌ای برای توسعه رویکردهای جدید شد.

در طول سال ۲۰۲۴، با ظهور مدل‌های پیشرفته‌تر و طرح‌های agent‌محور، نتایج به‌طور قابل توجهی بهبود یافت. پژوهشگران Princeton سیستم SWE-agent را معرفی کردند که GPT-4 را با جستجو در کد، برنامه‌ریزی و سایر ابزارها ترکیب می‌کند؛ این سیستم به حدود ۱۲٫۵٪ وظایف حل‌شده در مجموعه کامل دست یافت و معیار جدیدی برای مدل‌های آکادمیک تعیین کرد[5]. تا اواسط ۲۰۲۴، بهترین راه‌حل‌ها در leaderboard رسمی SWE-bench (از جمله راه‌حل‌های اختصاصی) به حدود ۲۰٪ حل موفق روی benchmark کامل و تا ۴۳٪ روی مجموعه ساده‌شده Lite رسیدند[7]. این رشد با بهبود مدل‌ها (مثلاً ظهور GPT-4، Claude 2 و 3) و به‌ویژه با توسعه «scaffolding» — استراتژی‌های خارجی که به مدل امکان می‌دهد وظیفه را به مراحل تقسیم کند، مستندات را بخواند، جلسات اشکال‌زدایی را اجرا کند و غیره — مرتبط است[7].

پس از معرفی مجموعه Verified در اواخر ۲۰۲۴ (پاک‌شده از وظایف نادرست)، عملکرد قابل اندازه‌گیری حتی بیشتر افزایش یافت. مدل GPT-4 (نوع GPT-4o) بلافاصله حدود ۳۳٪ حل موفق روی Verified در مقابل ~۱۶٪ قبلی روی مجموعه اصلی نشان داد[7]. بهترین چارچوب‌های agent متن‌باز (مثلاً Agentless) نتیجه خود را از ~۱۶٪ به ۳۲٪ روی Verified دو برابر کردند[7]. این موضوع تأیید کرد که benchmark اصلی به دلیل وجود موارد غیرقابل حل، شاخص‌ها را تا حدی دست‌کم می‌گرفت[7]. در عین حال، بهبود نتایج روی Verified در مقایسه با Lite چندان چشمگیر نیست (بهترین مدل‌ها از قبل به ~۴۳٪ روی Lite رسیده بودند)، که منطقی است: Lite در ابتدا نمونه‌های آسان‌تر را انتخاب کرده بود، در حالی که Verified موارد غیرقابل انجام را حذف کرد اما وظایف سخت را نگه داشت[7]. مهم است توجه کنیم که رشد شاخص‌ها در گذار به Verified در همه دسته‌بندی‌های سختی وظایف رخ داد، نه فقط با حذف سخت‌ترین‌ها — یعنی فیلتراسیون مجموعه را از موارد پنهاناً غیرقابل انجام در میان وظایف نسبتاً ساده نیز پاک کرد[7].

در ابتدای سال ۲۰۲۵، سیستم‌های پیشرو هوش مصنوعی عملکردی نزدیک به انسانی روی مجموعه وظایف تأییدشده از خود نشان می‌دهند، هرچند سقف ۱۰۰٪ هنوز دور است. در ژانویه ۲۰۲۵، شرکت Anthropic اعلام کرد که مدل جدید Claude 3.5 Sonnet در ترکیب با agent بهبودیافته ۴۹٪ وظایف SWE-bench Verified را حل کرد[4] و به‌طور موقت در جایگاه اول قرار گرفت. شرکت‌های فناوری بزرگ و تیم‌های مستقل نیز به‌طور فعال در رقابت‌های غیررسمی روی این benchmark شرکت می‌کنند. به عنوان مثال، تیم CodeStory رویکرد چندمدلی با امتحان انواع روش‌ها («Midwit Agent») را توسعه داد که به رکورد ۶۲٫۲٪ وظایف حل‌شده روی Verified رسید (داده‌های اوایل ۲۰۲۵)[5][9]. گزارش شد که برای این کار لازم بود منابع محاسباتی در مرحله استنتاج مدل (به اصطلاح inference time scaling) به‌طور قابل توجهی افزایش یابد، با اجرای تلاش‌های حل متعدد و انتخاب بهترین نتیجه[5]. از سوی دیگر، در مواد OpenAI از سیستم آزمایشی GPT-03 یاد شده که گفته می‌شود با مقیاس‌بندی کافی محاسبات موفق به عبور از آستانه ۷۰٪ روی Verified شده است (داده‌های غیررسمی)[5]. با این حال، تأیید مستقل این نتایج وجود ندارد، و چنین شاخص بالایی بیشتر یک راهنمای برای تحقیقات آینده است تا سطحی که به آن رسیده شده باشد.

بر اساس تحقیق Microsoft Research (2025)، حتی جدیدترین مدل‌ها با مجهز شدن به ابزارهای اشکال‌زدایی همچنان سقف ۵۰٪ رفع موفق باگ‌ها از SWE-bench Lite را پشت سر نگذاشته‌اند[6]. در این آزمایش، بهترین نتیجه را Claude 3.7 Sonnet با ~۴۸٫۴٪ وظایف حل‌شده کسب کرد، در حالی که سیستم مبتنی بر GPT-4 (OpenAI 01) حدود ۳۰٪ را حل کرد و مدل سبک‌تر 03-mini تنها ۲۲٪[6]. این نتایج تأکید می‌کنند که علی‌رغم پیشرفت سریع، هوش مصنوعی مدرن هنوز از برنامه‌نویسان مجرب عقب است: برای انسان حل چنین وظایفی (با درک کد) دشوار نیست، در حالی که مدل اغلب نمی‌تواند ابزارهای اشکال‌زدایی را به‌طور مؤثر به‌کار گیرد یا از کمبود داده‌های آموزشی که فرآیند چندمرحله‌ای رفع اشکال را منعکس کنند رنج می‌برد[6].

محدودیت‌ها و چشم‌اندازها

SWE-bench به یک بستر استاندارد برای ارزیابی agent‌های کدنویسی هوشمند تبدیل شده است، اما تحقیقات محدودیت‌هایی را نیز در آن آشکار کرده‌اند. مشکل اصلی — ناکامل بودن آزمون‌ها است: مجموعه آزمون‌های بررسی‌کننده برای هر وظیفه از یک pull request خاص گرفته می‌شود و معمولاً فقط شامل آن آزمون‌های واحد می‌شود که در هنگام رفع اشکال تغییر کرده‌اند[3]. همان‌طور که تحلیل گروهی از دانشمندان دانشگاه Zhejiang و دانشگاه اشتوتگارت (Wang et al. 2025) نشان داد، نادیده گرفتن سایر آزمون‌های پروژه می‌تواند نادرستی برخی راه‌حل‌ها را پنهان کند[3]. بررسی مجدد راه‌حل‌ها روی مجموعه کامل آزمون‌های مخزن نشان داد که به‌طور میانگین ۷٫۸٪ از patch‌هایی که در SWE-bench موفق علامت‌گذاری شده‌اند، در واقع سایر آزمون‌های پروژه را نمی‌گذرانند[3]. این امر منجر به بیش‌برآوردی معیار «وظایف حل‌شده» به اندازه حدود ۴-۶ واحد درصد می‌شود[3]. مورد ظریف‌تر زمانی است که patch تولیدشده همه آزمون‌های اصلی را می‌گذراند، اما معادل راه‌حل توسعه‌دهنده نیست و رفتار برنامه را به شکل غیرمنتظره تغییر می‌دهد. با استفاده از تولید موارد آزمایشی اضافی (روش‌شناسی PatchDiff)، پژوهشگران دریافتند که تقریباً ۳۰٪ اصلاحات پیشنهادی هوش مصنوعی رفتاری متفاوت از patch‌های مرجع دارند و حدود ۱۱٪ آنها به‌وضوح اشتباه هستند، هرچند آزمون‌های موجود آنها را تشخیص نمی‌دهند[3]. بنابراین، توانایی‌های واقعی مدل‌ها ممکن است بیش از حد ارزیابی شود اگر تنها به گذراندن مجموعه محدود آزمون‌ها اتکا شود. سازندگان SWE-bench این آسیب‌پذیری را می‌پذیرند و تأکید می‌کنند که benchmark باید در طول زمان تکامل یابد: پوشش آزمون‌ها بهبود یابد، بررسی‌هایی برای عدم وجود اثرات جانبی ناخواسته اضافه شود و انواع وظایف گسترش یابد[7]. توسعه چنین ابزارهای ارزیابی بخش مهمی از آمادگی برای ظهور توسعه‌دهندگان هوش مصنوعی روزافزون خودمختار و قدرتمند است، و تجربه با SWE-bench نشان می‌دهد که توجه دقیق به کیفیت benchmark‌ها ضروری است[7].

SWE-bench، با اینکه صرفاً یک مجموعه ایستا از وظایف است، همه جنبه‌های برنامه‌نویسی را پوشش نمی‌دهد، اما پیش از این به استاندارد de facto برای تحلیل مقایسه‌ای مدل‌های کدنویسی تبدیل شده است[3]. در مقالات علمی برای نمایش روش‌ها و الگوریتم‌های جدید استفاده می‌شود، و همچنین توسط گروه‌های تحقیقاتی صنعتی برای ارزیابی پتانسیل سیستم‌هایی که هدفشان خودکارسازی برنامه‌نویسی است[3]. رشد مستمر نتایج در SWE-bench طی سال‌های ۲۰۲۳-۲۰۲۵ به‌خوبی بهبود سریع قابلیت‌های LLM در حل وظایف عملی توسعه را نشان می‌دهد. در عین حال این benchmark به عنوان سنجه سختی عمل می‌کند: حتی با نزدیک شدن به ۵۰-۶۰٪ وظایف حل‌شده، مدل‌ها همچنان از جایگزینی کامل انسان فاصله دارند، به‌ویژه در شرایط اطلاعات محدود و ضرورت درک ظریف از الزامات[4][7]. با این حال، پیشرفت متوقف نمی‌شود — به لطف ابتکاراتی مانند SWE-bench، جامعه پژوهشی به‌وضوح اهداف و محدودیت‌های خود را می‌بیند و به‌سوی خلق یک توسعه‌دهنده هوش مصنوعی تمام‌عیار که قادر باشد کد را به‌طور خودمختار در سطح متخصص انسانی درک و اصلاح کند، پیش می‌رود[4][7].

پیوندها

  • SWE-bench در GitHub
  • Leaderboard رسمی SWE-bench

منابع

  • Liang, P. et al. (2022). Holistic Evaluation of Language Models (HELM). arXiv:2211.09110.
  • Chang, Y. et al. (2023). A Survey on Evaluation of Large Language Models. arXiv:2307.03109.
  • Ni, S. et al. (2025). A Survey on Large Language Model Benchmarks. arXiv:2508.15361.
  • Biderman, S. et al. (2024). The Language Model Evaluation Harness (lm-eval): Guidance and Lessons Learned. arXiv:2405.14782.
  • Kiela, D. et al. (2021). Dynabench: Rethinking Benchmarking in NLP. arXiv:2104.14337.
  • Ma, Z. et al. (2021). Dynaboard: An Evaluation‑As‑A‑Service Platform for Holistic Next‑Generation Benchmarking. arXiv:2106.06052.
  • Goel, K. et al. (2021). Robustness Gym: Unifying the NLP Evaluation Landscape. arXiv:2101.04840.
  • Xu, C. et al. (2024). Benchmark Data Contamination of Large Language Models: A Survey. arXiv:2406.04244.
  • Liu, S. et al. (2025). A Comprehensive Survey on Safety Evaluation of LLMs. arXiv:2506.11094.
  • Chiang, W.-L. et al. (2024). Chatbot Arena: An Open Platform for Evaluating LLMs by Human Preference. arXiv:2403.04132.
  • Boubdir, M. et al. (2023). Elo Uncovered: Robustness and Best Practices in Language Model Evaluation. arXiv:2311.17295.
  • Huang, L. et al. (2023). A Survey on Hallucination in Large Language Models. arXiv:2311.05232.

یادداشت‌ها

  1. ↑ 1.0 1.1 1.2 1.3 1.4 1.5 Jimenez, Carlos E. et al. «SWE-bench: Can Language Models Resolve Real-World GitHub Issues?». arXiv. [۱]
  2. ↑ 2.0 2.1 2.2 «SWE-bench/SWE-bench». GitHub. [۲]
  3. ↑ 3.00 3.01 3.02 3.03 3.04 3.05 3.06 3.07 3.08 3.09 3.10 Wang, Shuyang et al. «Are "Solved Issues" in SWE-bench Really Solved Correctly? An Empirical Study». arXiv. [۳]
  4. ↑ 4.0 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 «Claude SWE-Bench Performance». Anthropic. [۴]
  5. ↑ 5.0 5.1 5.2 5.3 5.4 Jain, Sulbha. «SWE Benchmark: LLM evaluation in Software Engineering Setting». Medium. [۵]
  6. ↑ 6.0 6.1 6.2 6.3 Hatmaker, Taylor. «AI models still struggle to debug software, Microsoft study shows». TechCrunch. [۶]
  7. ↑ 7.00 7.01 7.02 7.03 7.04 7.05 7.06 7.07 7.08 7.09 7.10 7.11 7.12 7.13 7.14 7.15 7.16 7.17 7.18 7.19 7.20 7.21 7.22 «Introducing SWE-bench Verified». OpenAI. [۷]
  8. ↑ 8.0 8.1 8.2 «SWE-bench Leaderboard». [۸]
  9. ↑ «SOTA on swebench-verified: relearning the bitter lesson». Hacker News (Y Combinator). [۹]
Retrieved from "https://systems-analysis.info/int/index.php?title=SWE-bench_(benchmark)_(FA)&oldid=6521"