🔥💻 حتی بهترین Coding Agentها هم در نرمافزارهای علمی به ۵۰٪ موفقیت نمیرسند!
یک Benchmark جدید با نام SWE-bench Science سراغ سؤالی مهم رفته است:
آیا Agentهای برنامهنویسی واقعاً میتوانند باگهای نرمافزارهای علمی را حل کنند، یا فقط در پروژههای نرمافزاری معمولی خوب هستند؟
پژوهشگران برای پاسخ، ۱۱۹ مسئله واقعی تعمیر نرمافزار را از ۹۸ مخزن GitHub و در ۲۰ حوزه علمی مختلف جمعآوری کردهاند.
این مسائل فقط چند خط کد خراب نیستند؛ برخی از آنها به درک مفاهیم علمی، پیدا کردن Root Cause و سپس هماهنگکردن اصلاح با بخشهای دیگر یک Pipeline تحقیقاتی نیاز دارند.
🧠 وظایف Benchmark در سه گروه طراحی شدهاند:
Issue-driven —
مشکلات واقعی ثبتشده در پروژهها
Expert-exploratory —
مسائلی که از بحث و بررسی متخصصان حوزه استخراج شدهاند
Engineering-integration —
تعمیراتی که باید در یک سیستم یا Pipeline بزرگتر نیز درست کار کنند
🔥 نتیجه کمی نگرانکننده است:
حتی قویترین Agent آزمایششده، یعنی Claude Code با Opus 5 در تنظیم Max، نتوانسته در معیار pass@1 به ۵۰٪ موفقیت برسد.
یعنی حتی Frontier Coding Agentها هنوز در بیش از نیمی از این مسائل علمی نمیتوانند در اولین تلاش Patch کاملاً صحیحی تولید کنند.
اما بخش جذاب مقاله فقط Benchmark نیست؛ پژوهشگران بررسی کردهاند که Agentها دقیقاً چرا شکست میخورند.
چهار الگوی اصلی پیدا شده است:
1️⃣ کمبود دانش یا درک علمی
اینکه Agent ممکن است کد را بفهمد، اما فیزیک، زیستشناسی، ریاضیات یا مفهوم علمی پشت آن را بهاندازه کافی درک نکند.
2️⃣ جستجوی اشتباه برای علت مشکل
مدل روی علائم ظاهری Bug تمرکز میکند و بهجای Root Cause، یک اصلاح سطحی انجام میدهد.
3️⃣ تعمیر ناقص
یک بخش درست میشود اما تغییر جدید با قسمت دیگری از سیستم ناسازگار است.
4️⃣ ضعف در تعمیم مفهوم علمی
حتی اگر Agent یک اصل علمی را از مثالها استخراج کند، الزاماً نمیتواند همان مفهوم را در شرایط جدید درست اعمال کند.
🤯 اما شاید مهمترین آزمایش مقاله درباره دادن دانش علمی به Agent باشد.
پژوهشگران اطلاعاتی مثل:
📄 مقاله علمی
📚 مستندات API
🧪 اطلاعات تخصصی حوزه
را در اختیار Agent قرار دادند و سپس همان آزمایش را با حذف این Guidance تکرار کردند.
نتیجه جالب بود:
دانش بیشتر همیشه Agent را بهتر نمیکند.
اگر اطلاعات علمی دقیقاً مرتبط باشند، فضای جستجوی Agent محدودتر میشود، احتمال موفقیت افزایش پیدا میکند و حتی مصرف Token کاهش مییابد.
اما اگر اطلاعات اضافی نامرتبط یا مبهم باشند، پدیدهای شبیه Anchoring اتفاق میافتد؛ Agent به همان اطلاعات میچسبد و ممکن است مسیر اشتباهی را با اعتماد بیشتری ادامه دهد.
💡 این نتیجه برای آینده AI Scientistها بسیار مهم است.
اصلاح یک نرمافزار علمی فقط مسئله Coding نیست:
💻 درک کد + 🧠 درک علم + 🔍 تشخیص Root Cause + 🧪 آزمایش + 🔗 Integration
همه باید با هم انجام شوند.
یک Agent ممکن است Python را فوقالعاده بنویسد، اما اگر نداند یک الگوریتم پردازش MRI، شبیهسازی سیالات یا محاسبه آماری از نظر علمی چه خروجیای باید تولید کند، کدی تحویل میدهد که Compile میشود و حتی ممکن است Test را پاس کند، ولی از نظر علمی اشتباه باشد.
و این شاید خطرناکترین نوع Bug باشد:
کدی که Crash نمیکند؛ اما نتیجه علمی غلط تولید میکند. 🧪⚠️
🔥 پیام SWE-bench Science روشن است:
مرحله بعدی Coding Agentها فقط افزایش توانایی تولید کد نیست.
آنها باید یاد بگیرند:
«چرا این کد از نظر علمی باید اینگونه کار کند؟»
و احتمالاً همین نقطه، مرز میان یک Coding Agent قدرتمند و یک AI Research Engineer واقعی خواهد بود.
[مقاله SWE-bench Science در arXiv]
(https://arxiv.org/abs/2608.19799
[صفحه رسمی SWE-bench Science]
(https://swescience.github.io
@rss_ai_ir
❤️ حمایت از کانال:
https://daramet.com/Virsun
#هوش_مصنوعی #برنامه_نویسی #پژوهش #عامل_هوشمند #نرم_افزار_علمی #SWEbenchScience #CodingAgents #ScientificAI #SoftwareEngineering #ClaudeCode #AIAgents #LLM #AI
یک Benchmark جدید با نام SWE-bench Science سراغ سؤالی مهم رفته است:
آیا Agentهای برنامهنویسی واقعاً میتوانند باگهای نرمافزارهای علمی را حل کنند، یا فقط در پروژههای نرمافزاری معمولی خوب هستند؟
پژوهشگران برای پاسخ، ۱۱۹ مسئله واقعی تعمیر نرمافزار را از ۹۸ مخزن GitHub و در ۲۰ حوزه علمی مختلف جمعآوری کردهاند.
این مسائل فقط چند خط کد خراب نیستند؛ برخی از آنها به درک مفاهیم علمی، پیدا کردن Root Cause و سپس هماهنگکردن اصلاح با بخشهای دیگر یک Pipeline تحقیقاتی نیاز دارند.
🧠 وظایف Benchmark در سه گروه طراحی شدهاند:
Issue-driven —
مشکلات واقعی ثبتشده در پروژهها
Expert-exploratory —
مسائلی که از بحث و بررسی متخصصان حوزه استخراج شدهاند
Engineering-integration —
تعمیراتی که باید در یک سیستم یا Pipeline بزرگتر نیز درست کار کنند
🔥 نتیجه کمی نگرانکننده است:
حتی قویترین Agent آزمایششده، یعنی Claude Code با Opus 5 در تنظیم Max، نتوانسته در معیار pass@1 به ۵۰٪ موفقیت برسد.
یعنی حتی Frontier Coding Agentها هنوز در بیش از نیمی از این مسائل علمی نمیتوانند در اولین تلاش Patch کاملاً صحیحی تولید کنند.
اما بخش جذاب مقاله فقط Benchmark نیست؛ پژوهشگران بررسی کردهاند که Agentها دقیقاً چرا شکست میخورند.
چهار الگوی اصلی پیدا شده است:
1️⃣ کمبود دانش یا درک علمی
اینکه Agent ممکن است کد را بفهمد، اما فیزیک، زیستشناسی، ریاضیات یا مفهوم علمی پشت آن را بهاندازه کافی درک نکند.
2️⃣ جستجوی اشتباه برای علت مشکل
مدل روی علائم ظاهری Bug تمرکز میکند و بهجای Root Cause، یک اصلاح سطحی انجام میدهد.
3️⃣ تعمیر ناقص
یک بخش درست میشود اما تغییر جدید با قسمت دیگری از سیستم ناسازگار است.
4️⃣ ضعف در تعمیم مفهوم علمی
حتی اگر Agent یک اصل علمی را از مثالها استخراج کند، الزاماً نمیتواند همان مفهوم را در شرایط جدید درست اعمال کند.
🤯 اما شاید مهمترین آزمایش مقاله درباره دادن دانش علمی به Agent باشد.
پژوهشگران اطلاعاتی مثل:
📄 مقاله علمی
📚 مستندات API
🧪 اطلاعات تخصصی حوزه
را در اختیار Agent قرار دادند و سپس همان آزمایش را با حذف این Guidance تکرار کردند.
نتیجه جالب بود:
دانش بیشتر همیشه Agent را بهتر نمیکند.
اگر اطلاعات علمی دقیقاً مرتبط باشند، فضای جستجوی Agent محدودتر میشود، احتمال موفقیت افزایش پیدا میکند و حتی مصرف Token کاهش مییابد.
اما اگر اطلاعات اضافی نامرتبط یا مبهم باشند، پدیدهای شبیه Anchoring اتفاق میافتد؛ Agent به همان اطلاعات میچسبد و ممکن است مسیر اشتباهی را با اعتماد بیشتری ادامه دهد.
💡 این نتیجه برای آینده AI Scientistها بسیار مهم است.
اصلاح یک نرمافزار علمی فقط مسئله Coding نیست:
💻 درک کد + 🧠 درک علم + 🔍 تشخیص Root Cause + 🧪 آزمایش + 🔗 Integration
همه باید با هم انجام شوند.
یک Agent ممکن است Python را فوقالعاده بنویسد، اما اگر نداند یک الگوریتم پردازش MRI، شبیهسازی سیالات یا محاسبه آماری از نظر علمی چه خروجیای باید تولید کند، کدی تحویل میدهد که Compile میشود و حتی ممکن است Test را پاس کند، ولی از نظر علمی اشتباه باشد.
و این شاید خطرناکترین نوع Bug باشد:
کدی که Crash نمیکند؛ اما نتیجه علمی غلط تولید میکند. 🧪⚠️
🔥 پیام SWE-bench Science روشن است:
مرحله بعدی Coding Agentها فقط افزایش توانایی تولید کد نیست.
آنها باید یاد بگیرند:
«چرا این کد از نظر علمی باید اینگونه کار کند؟»
و احتمالاً همین نقطه، مرز میان یک Coding Agent قدرتمند و یک AI Research Engineer واقعی خواهد بود.
[مقاله SWE-bench Science در arXiv]
(https://arxiv.org/abs/2608.19799
[صفحه رسمی SWE-bench Science]
(https://swescience.github.io
@rss_ai_ir
❤️ حمایت از کانال:
https://daramet.com/Virsun
#هوش_مصنوعی #برنامه_نویسی #پژوهش #عامل_هوشمند #نرم_افزار_علمی #SWEbenchScience #CodingAgents #ScientificAI #SoftwareEngineering #ClaudeCode #AIAgents #LLM #AI