اگر امروز به نمرات خیره‌کننده مدل‌های هوش مصنوعی در حل باگ‌های واقعی اعتماد می‌کنید، باید بدانید که این اعداد احتمالاً حاصل استدلال نیستند، بلکه نتیجه‌ی یک «تقلب» ناخواسته در داده‌های آموزشی‌اند. بنچمارک SWE-bench که معیار اصلی سنجش عامل‌های (Agents) کدنویسی در صنعت است، با یک حفره‌ی امنیتی عظیم در داده‌ها روبروست.
طبق یک تحلیل فنی که در مجله‌ی SILICON SCIENCE منتشر شده است، ۹۷.۸٪ از فایل‌های آزمون مورد استفاده در این محک، در زمان ثبت یا پیش از آن در مخازن عمومی گیت‌هاب موجود بوده‌اند. این یک نقص بحرانی در مواجهه با داده‌هاست؛ در حالی که این بنچمارک از نشت کلمه-به-کلمه صورت‌مسئله‌ها جلوگیری می‌کند، اما معیارهای پذیرش (Pass/Fail) که در واقع همان «کلید پاسخ» هستند، در مخازن عمومی قرار داشتند تا مدل‌ها در طول مرحله‌ی پیش‌آموزش آن‌ها را ببلعند. این چالش با رویکردهای گوگل برای ایجاد سامانه‌های ارزیابی صادقانه و دوبل‌بلایند در تضاد است که تلاش می‌کنند نشت داده‌ها را به حداقل برسانند.
این یافته در زمانی منتشر می‌شود که آزمایشگاه‌های هوش مصنوعی به‌طور فزاینده‌ای بر عامل‌های خودمختار برای حل Issueهای واقعی گیت‌هاب تکیه می‌کنند. تنش اصلی بر سر این است که آیا یک مدل واقعاً در حال استدلال برای رفع یک باگ است یا صرفاً فایلی را که در تریلیون‌ها توکن داده‌های آموزشی دیده، بازخوانی می‌کند. برای تیم‌های فنی، این موضوع بحث «آلودگی داده» (Contamination) را از یک بحث متنی ساده به یک بحث سیگنال معنایی تبدیل می‌کند.
متدولوژی و بررسی فارنزیک
پژوهشگران در این تحلیل که در مجله‌ی SILICON SCIENCE (یک مجله‌ی داوری‌شده که توسط عامل‌های خودمختار اداره می‌شود) منتشر شده، تلاش کردند تا از حدس و گمان یا «حس کلی» (Vibes) عبور کرده و به یک اندازه‌گیری فارنزیک از آلودگی دست یابند. آن‌ها یک خط لوله‌ی قطعی و بازتولیدپذیر به‌صورت آفلاین برای بررسی ۵۰۰ مورد از SWE-Bench-Verified طراحی کردند.
این خط لوله از ۵۰۰ رکورد JSON برای هر نمونه استفاده کرد. این رکوردها به اسنپ‌شات‌های خاصی متصل (Pinned) شده‌اند که اجازه می‌دهد یک اسکریپت reproduce.sh خروجی‌های استاندارد را به‌صورت بیت-به-بیت و بدون نیاز به دسترسی به شبکه بازسازی کند. این ساختار تضمین می‌کند که هر ادعای مطرح شده در گزارش، مستقیماً به یک اسنپ‌شات مستند از شواهد متصل است.
جزئیات فنی نشت
بر اساس مستندات این پژوهش، چهار کانال مختلف در تاریخچه‌ی عمومی گیت‌هاب بررسی شد تا مشخص شود مدل‌ها چگونه ممکن است به پاسخ‌ها دسترسی پیدا کرده باشند:
- در دسترس بودن Issueها (C1a): ۱۰۰٪ (۵۰۰ از ۵۰۰ مورد) از Issueها عمومی و از طریق REST قابل بازیابی بودند.
- نشت کلمه-به-کلمه (C1b): ۰٪ از نمونه‌ها حاوی متن دقیق و کلمه-به-کلمه صورت‌مسئله بودند.
- قرارگیری فایل‌های آزمون (C2): ۹۷.۸٪ (۴۸۹ از ۵۰۰ مورد) از تست‌ها در زمان کامیت پایه یا پیش از آن در مخزن موجود بودند.
- قابلیت کشف اصلاحیه (C3): ۹۲.۸٪ (۴۶۴ از ۵۰۰ مورد) از کامیت‌های حل‌کننده از طریق جست‌وجوی شماره‌ی Issue قابل دسترسی بودند.
پژوهشگران برای تایید اینکه خودِ متن‌ها تکراری نیستند، از تحلیل توکن-ژاکارد (Token-Jaccard) روی بدنه Issueها استفاده کردند. نتایج نشان داد که میانه این مقدار ۰.۰۹۶، مقدار p90 برابر با ۰.۲۰۳ و حداکثر مقدار ۰.۶۴۷ است. این نتایج تایید می‌کند که در حالی که نثر و متن‌ها پاک هستند، اما مجموعه‌های آزمون (Test Suites) که از نظر معنایی بسیار متراکم هستند، هرگز محافظت نشدند.
این یعنی مدلی که بتواند یک دامپ از مخزن را بخواند، پیش از تلاش برای حل مسئله، عملاً «کلید پاسخ» را دیده است. اگر صورت‌مسئله بخواهد «تابعی بنویسید که X را انجام دهد»، مخزن از قبل حاوی فایلی مانند test_X.py است که دقیقاً تعریف می‌کند X به چه معناست و چه خروجی‌ای باید داشته باشد. این موضوع تأییدی بر این است که تست‌های داخلی مخزن کد می‌توانند مانعی ناکارآمد برای اعتبارسنجی واقعی وصله‌های AI باشند.
این تغییر در درک ما نشان می‌دهد که معیار «عدم نشت متنی» (Verbatim-leakage null) که بسیاری از آزمایشگاه‌ها به آن تکیه می‌کنند، معیار غلطی است. کانال واقعی آلودگی، خودِ درختِ مخزن (Repository Tree) است. اگر مجموعه آزمون عمومی باشد، بنچمارک به‌جای سنجش توانایی واقعی مهندسی نرم‌افزار، در واقع «بازیابی» (Retrieval) و «تطبیق الگو» (Pattern Matching) را اندازه می‌گیرد.
برای رفع این مشکل، گزارش استدلال می‌کند که سازندگان بنچمارک باید تاریخچه‌ی انتشار فایل‌های آزمون را به عنوان یک کانال درجه‌یک آلودگی در نظر بگیرند. این کار مستلزم اسنپ‌شات گرفتن از مخازن در زمان کامیت پایه و ثبت دقیق زمان ورود فایل‌های تست به درخت مخزن است تا پنجره‌ی واقعی مواجهه (Exposure Window) افشا شود.
به‌طور عملی، این تحلیل سه تغییر فوری برای حفظ اعتبار لیدربوردها پیشنهاد می‌دهد:
- تثبیت سخت‌گیرانه‌تر (Pin harder): پاک بودن یک نمونه باید بر اساس اولین نقطه‌ی مواجهه سنجیده شود، نه صرفاً بر اساس کامیت پایه (base_commit).
- چرخش تست‌ها: ارزیابی باید شامل تغییرات (Mutations) یا افزودن تست‌های خصوصی باشد، نه فقط تکیه بر مجموعه‌های عمومی.
- گزارش نرخ مواجهه: لیدربوردها باید درصد فایل‌های آزمون عمومی را در کنار امتیازات چاپ کنند.
این مطالعه توسط عامل‌های خودمختار داوری شده و به‌طور کامل از طریق یک اسنپ‌شات شواهد در گیت‌هاب در آدرس https://github.com/argszero/silicon-science-cs (بخش papers/issue-36/) قابل بازتولید است.
گام بعدی شما
- اگر از SWE-bench برای ارزیابی مدل‌های داخلی خود استفاده می‌کنید، نتایج را با دیده‌ی تردید بررسی کنید و تست‌های خصوصی (Private Test Suites) را جایگزین کنید.
- در گزارش‌های ارزیابی مدل‌ها، به‌جای تکیه بر نمرات کلی، به دنبال «نرخ مواجهه» (Exposure Ratio) داده‌ها بگردید.
- برای سنجش واقعی توانایی کدنویسی، از متدولوژی «تغییر در ورودی» (Input Mutation) استفاده کنید تا مدل نتواند بر اساس حافظه پاسخ دهد.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو