اگر امروز از عاملهای هوش مصنوعی برای اصلاح باگهای نرمافزاری استفاده میکنید، احتمالاً با حجم زیادی از کدهای تکراری و زائد در مخزن کد خود مواجه شدهاید. این «مالیات پنهان» که منجر به افزایش بدهی فنی میشود، اکنون هدف یک سیستم ارزیابی جدید است.
پروژه Parsimony در ۱۳ اکتبر ۲۰۲۶ چارچوبی را معرفی کرد که بهجای تمرکز صرف بر نرخ حل مسئله، کدنویسی بهینه را ملاک قرار میدهد. طبق گزارش این پروژه، هدف اصلی جریمه کردن کدهای اضافی در وصلههای (Patches) تولیدشده توسط هوش مصنوعی است تا تمرکز صنعت به سمت کارایی کد تغییر کند.
محکهای سنتی مانند SWE-bench Verified تنها بررسی میکنند که آیا مدل مسئله را حل کرده است یا خیر، اما تفاوتی بین راهکاری که با ۵ خط کد اجرا میشود و راهکاری که ۱۰۰ خط کد اضافه میکند، قائل نمیشوند. این رویکرد باعث میشود مدلها به سمت «مهندسی بیش از حد» (Over-engineering) سوق داده شوند. این تمایل به تولید پاسخهای حجیم حتی در موارد شکست مدلها نیز دیده میشود؛ چنانکه پژوهشهای اخیر نشان دادهاند برخی عاملهای هوش مصنوعی در انجام وظایف مستقل شکست خورده و نتایج را جعل کردهاند.
همانطور که در تحلیلهای قبلی ما دربارهی امنیت مدلهای بازمتن اشاره کردیم، هر خط کد اضافی، سطح حمله و احتمال خطا را افزایش میدهد. بر اساس مستندات parsimony.lasu.dev، این چارچوب برای جلوگیری از تقلب مدلها، بهجای شمارش سادهی خطوط، «واحدهای خالص» (Net Units) را محاسبه میکند. این واحدها شامل عناصر نحو (Syntax) مانند دستورات، فراخوانیها و لیترالها هستند.
فرآیند ارزیابی در این سیستم شامل مراحل زیر است:
- تجزیه (Parsing) هر دو نسخه از فایلهای تغییریافته در یک وصله.
- تفریق واحدهای حذفشده از واحدهای اضافه شده برای یافتن تغییر خالص.
- حذف تستها، مستندات و فایلهای تولیدشده از شمارش نهایی.
در حال حاضر، این محک تنها کدهای پایتون را با استفاده از mini-SWE-agent اندازهگیری میکند. طبق یافتههای این گزارش، یک همبستگی مستقیم بین پرگویی (Verbosity) و توانایی مدلها وجود دارد؛ بهطوری که مدلهایی که کدهای طولانیتری مینویسند، تمایل بیشتری به حل مسائل پیچیده دارند (همبستگی اسپیرمن بین ۰.۳۳ تا ۰.۶۰).
این تغییر در معیار اندازهگیری، این فرض رایج را به چالش میکشد که «حل شدن» مسئله تنها متغیری است که اهمیت دارد. با کمیسازی «هزینه نگهداری» از طریق واحدهای خالص، Parsimony مدلها را مجبور میکند بین نرخ حل خام و توانایی تولید کد تمیز و قابل نگهداری، موازنه برقرار کنند. این رویکرد در واقع پاسخی به چالشهای بنیادین مدلها در مواجهه با مسائل دشوار است، جایی که اجبار به پاسخدهی میتواند منجر به ایجاد توهمات در مدلهای زبانی شود.
گام بعدی شما
- اگر توسعهدهنده هستید، فایل JSON نمونهی این پروژه را دانلود کنید تا کارایی عاملهای خود را با لیدربورد فعلی مقایسه کنید.
- در پرامپتهای خود برای مدلهای کدنویس، صراحتاً محدودیت در تعداد تغییرات (Minimal Changes) را به عنوان یک معیار کیفیت تعریف کنید.
- خروجیهای مدلهای استدلالی را با ابزارهای تحلیل استاتیک بررسی کنید تا حجم کدهای تکراری را شناسایی کنید.
اما تأثیر این رویکرد بر مدلهای کوچکتر که محدودیت حافظه دارند حتی حیاتیتر است — به بررسی ما دربارهی مدلهای زبانی کوچک (SLM) مراجعه کنید.




گفتگو