SWE-bench: آیا مدلهای زبانی میتوانند مسائل واقعی گیتهاب را حل کنند؟
مقاله CodeAct استدلال قانعکنندهای ارائه کرد که پایتون فرمت اقدام (action format) مناسبی برای عاملهای LLM است. اما انتخاب فرمت اقدام صحیح تنها نیمی از مشکل است — شما همچنین باید نشان دهید که عاملها میتوانند از پس پیچیدگی وظایف دنیای واقعی برآیند، نه فقط بنچمارکهای دستچین شده. SWE-bench (arXiv:2310.06770) که توسط کارلوس خیمنز، جان یانگ، الکساندر وتیگ، شونیو یائو، ککسین پی، اوفیر پرس و کارتیک ناراسیمهان از پرینستون منتشر و در ICLR 2024 ارائه شد، مقالهای است که این حوزه را وادار کرد مستقیماً با این شکاف روبرو شود.
مقاله
"SWE-bench: آیا مدلهای زبانی میتوانند مسائل واقعی گیتهاب را حل کنند؟" بنچمارکی متشکل از ۲,۲۹۴ مورد وظیفه را ایجاد میکند که از پولریکوئستهای (PR) واقعی ادغام شده در ۱۲ مخزن محبوب پایتون استخراج شدهاند — astropy، django، flask، matplotlib، pylint، pytest، requests، scikit-learn، seaborn، sphinx، sympy و xarray. هر مورد، تصویری از کدبرنامه (codebase snapshot) و توضیحات یک مسئله گیتهاب را به مدل ارائه میدهد؛ مدل باید وصلهای (patch) تولید کند که مجموعهای از تستهای قبلاً شکستخورده را بدون خراب کردن تستهای موجود، با موفقیت پاس کند. این بنچمارک با استخراج حدود ۹۰,۰۰۰ PR، فیلتر کردن مواردی که هم یک مسئله لینکشده را حل کرده و هم تستهای جدید اضافه کرده بودند، و سپس تأیید انتقالهای قبولی/شکست مبتنی بر اجرا ساخته شده است. این ساختار منضبط از مشکل رایج بنچمارکها یعنی حقیقت زمینی (ground truth) مبهم یا به راحتی قابل تقلب جلوگیری میکند.
ایدههای کلیدی
- Claude 2، بهترین مدل در زمان انتشار، تنها ۱.۹۶٪ از مسائل را با استفاده از بازیابی پراکنده BM25 حل میکند — تنظیمات استقرار واقعگرایانه که در آن مدل باید فایلهای مرتبط را خودش پیدا کند.
- با بازیابی اوراکل (oracle retrieval) — جایی که دقیقاً فایلهای مورد نیاز به مدل داده میشود — نرخ موفقیت Claude 2 به ۴.۸۰٪ بهبود مییابد، که تأیید میکند گلوگاه بخشی مربوط به بازیابی اما عمدتاً مربوط به ویرایش است: حتی با کانتکست کامل، نرخ موفقیت زیر ۵٪ باقی میماند.
- GPT-4 حدود ۰.۰۰٪ از مسائل را با بازیابی BM25 (که به دلایل بودجه روی یک زیرمجموعه ۲۵ درصدی ارزیابی شد) و ۱.۷۴٪ را با اوراکل حل میکند. افت از اوراکل به BM25 برای Claude 2 شدید است؛ برای GPT-4 این افت مطلق است.
- وصلههای تولید شده به طور سیستماتیک بیش از حد کوتاه هستند: وصلههای موفق Claude 2 به طور متوسط ۱۹.۶ خط هستند، در حالی که وصلههای طلایی انسانی ۷۴.۵ خط هستند. مدلها راهحلهای محلی ساده پیدا میکنند؛ انسانها راهحلهای جامع چند-فایلی مینویسند.
- کانتکست بیشتر عملاً آسیب میزند. BM25 در ۵۰ هزار توکن فایلهای اوراکل بیشتری نسبت به ۱۳ هزار توکن بازیابی میکند، با این حال نرخ حل مسائل اغلب کاهش مییابد. اثر "گمشدن در میانه" (lost in the middle) — نادیده گرفتن شواهد مرتبط دفن شده در کانتکستهای طولانی توسط مدلها — یک حالت شکست واقعی و مستند در اینجا است.
- SWE-Llama 13b، که روی کانتکستهای بازیابی شده توسط اوراکل تنظیم دقیق (fine-tune) شده است، به ۴.۰۰٪ با اوراکل اما تنها ۰.۷۰٪ با BM25 دست مییابد. آموزش روی کانتکست بینقص، عاملهای شکنندهای ایجاد میکند که در مواجهه با بازیابی واقعی فرو میپاشند.
چه چیزی پابرجا میماند — و چه چیزی نه
ساختار بنچمارک دقیق است. ارزیابی مبتنی بر اجرا — تستهایی که واقعاً اجرا میشوند، پاس میشوند یا شکست میخورند — حقیقت زمینی درستی برای وظایف ویرایش کد است. این روش عینی، خودکار و به سختی قابل تقلب است. تصمیم برای الزام به انتقال از شکست به قبولی (نه فقط اعمال موفقیتآمیز پچ) بسیار مهم است: این کار از وصلههای به ظاهر درستی که کاری انجام نمیدهند یا کد را حذف میکنند جلوگیری میکند.
نتایج به خوبی پابرجا ماندهاند. SWE-bench در اکتبر ۲۰۲۳ منتشر شد و به سرعت به ارزیابی استاندارد برای عاملهای کدنویسی تبدیل شد. خط پایه اولیه ۱.۹۶٪ واقعاً آموزنده است و دستچین شده نیست. SWE-agent که در سال ۲۰۲۴ توسط یک گروه مرتبط منتشر شد، با بازطراحی رابط عامل-کامپیوتر، عدد را به ۱۲.۴۷٪ رساند — یک بهبود ۶ برابری که خود تأیید میکند خط پایه اصلی چقدر از پتانسیل موجود را نادیده گرفته بود.
دو موردی که مقاله به خوبی از پس آنها بر نمیآید: اول، بنچمارک فقط مخصوص پایتون است. این یک ضرورت عملی است، اما خطر واقعی بیشبرازش (overfitting) به قراردادهای پایتون را ایجاد میکند. دوم، مقاله فقط خط پایههای تولید تقویتشده با بازیابی (RAG) را پیشنهاد میکند و صراحتاً رویکردهای مبتنی بر عامل را به کارهای آینده واگذار میکند. این واگذاری در سال ۲۰۲۳ مناسب بود، اما به این معنی است که خود مقاله هیچ سیگنالی در مورد اینکه چه معماریهای عاملی کمک میکنند، ارائه نمیدهد.
تنظیمات "اوراکل" نیز یک حد بالای ضعیفتر از آنچه به نظر میرسد است. ارائه کانتکست کامل فایل، مشکل مکانیابی کد در آن فایلها را حل نمیکند و به استدلال چند-فایلی درباره تعاملات بین ماژولها کمکی نمیکند. Claude 2 با نرخ ۴.۸٪ در اوراکل به این معنی است که حتی با داشتن فایلهای درست در کانتکست، مدل در ۹۵٪ مواقع شکست میخورد. مشکل اساساً بازیابی نیست.
چرا این موضوع برای هوش مصنوعی مالی اهمیت دارد
Beancount یک پروژه پایتونی است که در گیتهاب میزبانی میشود. یک عامل بازنویسی (write-back) برای Beancount، در اصل عاملی است که باید وظایفی به سبک SWE-bench را انجام دهد: با داشتن یک فایل دفتر کل و یک دستور ("این تراکنش را اضافه کن"، "این اختلاف موجودی را برطرف کن")، ویرایشی تولید کند که bean-check را پاس کند بدون اینکه گزارههای (assertions) موجود را خراب کند.
شکست در بازیابی مستقیماً با مشکل مکانیابی در دفتر کل (ledger) قابل مقایسه است. وقتی کاربری میگوید "بیشاظهاری در ملزومات اداری سه ماهه سوم را اصلاح کن"، عامل باید ابتدا ورودیهای مرتبط را در فایلی پیدا کند که ممکن است شامل هزاران خط باشد — همان وظیفه مکانیابی فایل که در آن BM25 برای ۴۰-۵۰٪ از موارد SWE-bench شکست میخورد. افت کیفیت ناشی از "گمشدن در میانه" به طور مشابه برای فایلهای طولانی .beancount صدق میکند، جایی که ورودیهای با تاریخ قدیمیتر به همان اندازه احتمال دارد نادیده گرفته شوند.
عدم تقارن طول وصله یک هشدار عملی است. مدلها وصلهها را بیش از حد محدود اعمال میکنند. در حسابداری، این به معنای اصلاح یک ورودی در حالی که ورودی متقابل (offsetting entry) نادیده گرفته شده، یا بهروزرسانی خط هزینه در حالی که موجودی جاری (running balance) قدیمی مانده است، ترجمه میشود. یک عامل Beancount عملیاتی به یک لایه اعتبارسنجی نیاز دارد — bean-check ، گزارههای موجودی، یا یک مرحله تطبیق صریح — که عامل را مجبور کند پیامد کامل ویرایش خود را ببیند، نه فقط معقول بودن محلی آن را.
شکاف بین اوراکل و BM25 همچنین یادآوری است که کیفیت بازیابی از کیفیت عامل جدا نیست. عاملی که نتواند به طور قابل اعتماد تشخیص دهد کدام حسابها یا فایلها به سوال کاربر مرتبط هستند، در مرحله ناوبری دفتر کل، حتی قبل از اینکه برای ویرایش تلاش کند، شکست خواهد خورد.
آنچه باید در ادامه بخوانید
- SWE-agent (arXiv:2405.15793, NeurIPS 2024) — دنباله مستقیم؛ با بازطراحی رابط عامل-کامپیوتر از ۱.۹۶٪ به ۱۲.۴۷٪ میرسد. اصول طراحی برای ناوبری فایل و جستجوی کد مستقیماً در ابزارهای عامل Beancount قابل اجرا هستند.
- Agentless: Demystifying LLM-based Software Engineering Agents (arXiv:2407.01489) — پیچیدگی عامل را حذف کرده و نشان میدهد که یک خط لوله ساده مکانیابی + تعمیر بدون ساختارهای پیچیده میتواند رقابتی باشد؛ یک دیدگاه متقابل مفید برای رویکردهای سنگین در رابط کاربری.
- MemGPT: Towards LLMs as Operating Systems (arXiv:2310.08560) — با مدیریت حافظه چندلایه مستقیماً به مشکل کانتکست طولانی میپردازد؛ برای عاملهایی که باید روی دفترهای کل Beancount چندساله استدلال کنند، کاملاً مرتبط است.
