روش گوگل برای جلوگیری از حفظ‌کردن آزمون‌ها توسط عامل‌های هوش مصنوعی

بهینه‌سازی عامل‌های هوش مصنوعی، به گفته پژوهشگران گوگل، فقط به ساخت مدل‌های قوی‌تر وابسته نیست: اصلاح چارچوب اجرایی‌ای که به عامل می‌گوید چگونه وظایف را انجام دهد نیز می‌تواند مؤثر باشد. پژوهش تازه آن‌ها روشی به نام RRSI معرفی می‌کند که با محدودکردن تغییرهای خودکار، می‌کوشد از حفظ‌کردن آزمون‌های آموزشی جلوگیری کند و بهبود عملکرد را به وظایف تازه هم منتقل کند.

عامل هوش مصنوعی سامانه‌ای است که برای انجام یک کار چندمرحله‌ای، از مدل و ابزارها استفاده می‌کند. «چارچوب اجرایی» یا harness مجموعه‌ای از دستورها و سازوکارهایی است که هدایت می‌کند عامل چه فایلی را بخواند، پس از خطا چگونه بازیابی شود و نتیجه را چگونه تحویل دهد. به‌گزارش پژوهش، بخشی از پیشرفت اخیر عامل‌ها نه از تغییر خود مدل، بلکه از بهترشدن همین چارچوب‌ها ناشی شده است.

بهینه‌سازی عامل‌های هوش مصنوعی و خطر حفظ‌کردن آزمون‌ها

پیش‌تر، بررسی اجرای ناموفق عامل‌ها و اصلاح چارچوب معمولاً به‌صورت دستی انجام می‌شد. روش‌های جدیدتر این چرخه را خودکار می‌کنند: یک مدل زبانی با توجه به بازخورد وظایف آزمایشی، پیشنهادهایی برای بازنویسی چارچوب می‌دهد و سامانه این روند را بارها تکرار می‌کند. پژوهشگران این فرایند را گونه‌ای عملی از «بهبود خودبازگشتی» می‌دانند؛ سامانه از بازخورد برای اصلاح سازوکاری استفاده می‌کند که رفتار خودش را کنترل می‌کند.

اما بهینه‌سازی مکرر روی مجموعه‌ای محدود از آزمون‌ها می‌تواند نتیجه‌ای گمراه‌کننده داشته باشد. عامل در وظایف آموزشی امتیاز بیشتری می‌گیرد، اما این پیشرفت ممکن است در وظایف تازه دیده نشود. به‌گفته پژوهشگران، روند جست‌وجو گاهی الگوهایی را پیدا می‌کند که فقط با یک بنچمارک مشخص جور درمی‌آیند، تغییرهایی را برمی‌گزیند که تصادفاً امتیاز بالایی گرفته‌اند یا پیچیدگی‌های غیرضروری می‌افزاید؛ کارهایی که امتیاز آزمون را بالا می‌برند، بی‌آن‌که توانایی عمومی عامل بهتر شود.

RRSI چگونه تغییرهای چارچوب را کنترل می‌کند؟

نام روش پیشنهادی، RRSI، مخفف «بهبود خودبازگشتی تنظیم‌شده چارچوب‌های عامل» است. این روش هم هنگام پیشنهاد تغییر و هم هنگام انتخاب تغییرهایی که در چارچوب باقی می‌مانند محدودیت می‌گذارد، اما چارچوب را همچنان قابل‌ویرایش نگه می‌دارد. یکی از محدودیت‌ها سقفی برای تعداد ویرایش‌های مستقلی است که هر پیشنهاد می‌تواند در خود جمع کند.

این سقف با گذشت زمان پایین می‌آید: دورهای نخست اجازه بازنویسی‌های بزرگ‌تر می‌دهند، اما در مراحل بعد تغییرها کوچک‌تر می‌شوند تا ارتباط میان هر اصلاح و نتیجه‌اش روشن‌تر باشد. سامانه تلاش‌های پیشین را نیز ثبت می‌کند تا دوباره سراغ ایده‌های ناموفق نرود. اگر روند پیشرفت متوقف شود، بخش‌هایی از چارچوب را که پیش‌تر دست‌کاری نشده‌اند، هدف آزمایش قرار می‌دهد.

مرحله بعدی ارزیابی پیشنهادهاست. یک منتقد، هر تغییر را بررسی می‌کند و پیشنهادهایی را که نام وظایف، پاسخ‌ها یا ترفندهای ویژه یک بنچمارک را در چارچوب جا می‌دهند، کنار می‌گذارد. افزایش هزینه محاسباتی نیز تنها زمانی پذیرفته می‌شود که با بهبود قابل‌اندازه‌گیری همراه باشد؛ اجزایی که دیگر سودی ندارند حذف می‌شوند. هدف این قواعد، جلوگیری از آن است که چارچوب به‌جای یادگیری راهبردهای عمومی، برای پاسخ‌گویی به آزمون‌های شناخته‌شده دست‌کاری شود.

نتایج روی وظایف نادیده و مدل‌های دیگر

پژوهشگران RRSI را روی هشت بنچمارک در سه حوزه برنامه‌نویسی، کارهای اداریِ عامل‌محور و طراحی مهندسی آزمودند. در آزمایش اصلی، مدل Claude Opus 4.8 در تمام مدت ثابت ماند؛ یعنی وزن‌های مدل تغییر نکرد و اصلاح‌ها فقط در چارچوب اجرایی اعمال شدند. پژوهش با چارچوب پایه و چهار روش بهینه‌سازی دیگر نیز مقایسه شد.

طبق مقاله، RRSI در وظایف آموزشی تا ۱۴٫۱ امتیاز و در پنج بنچمارکی که هنگام بهینه‌سازی در اختیار سامانه نبودند تا ۴٫۷ امتیاز بهبود ایجاد کرد. عملکرد این روش در هیچ‌یک از بنچمارک‌های نادیده از چارچوب پایه پایین‌تر نیامد؛ نتیجه‌ای که پژوهشگران در روش‌های مستعد حفظ‌کردن آزمون‌ها معمولاً شاهد آن نیستند. RRSI همچنین در زمان اجرا حدود ۳۰ درصد توکن کم‌تری از نسخه بدون تنظیم مصرف کرد.

در مقایسه روش‌ها، همه گزینه‌ها روی وظایف آموزشی نتیجه خوبی داشتند، اما عملکردشان روی آزمون‌های تازه یکسان نبود و دو روش حتی از چارچوب پایه پایین‌تر رفتند. RRSI کم‌ترین افزایش را در وظایف آموزشی داشت، اما تنها روشی بود که در آزمون‌های نادیده به‌وضوح از خط پایه بهتر عمل کرد. با این حال، پژوهشگران یادآور می‌شوند که چارچوب پایه از نظر مصرف توکن هنوز بهینه‌تر است؛ بنابراین بهبود RRSI در تعمیم و کارایی نسبت به نسخه بهینه‌سازی‌نشده، به معنای کم‌مصرف‌ترین گزینه در کل نیست.

آزمایش دیگری نشان داد برخی سازوکارهای کشف‌شده می‌توانند از مدلی به مدل دیگر منتقل شوند. چارچوبی که با Gemini 3.5 Flash برای برنامه‌نویسی بهینه شده بود، بدون تغییر در خود چارچوب، دقت Gemini 3.1 Flash Lite را از ۱۱٫۲ به ۱۴٫۶ امتیاز رساند. پژوهشگران می‌گویند سازوکارهای به‌دست‌آمده الزاماً به توانایی مدلی که آن‌ها را کشف کرده محدود نیستند.

محدودیت پژوهش و زمینه گسترده‌تر

دامنه نتیجه‌گیری پژوهش محدود است: بررسی فقط چارچوب‌هایی را پوشش می‌دهد که روی مدل‌های ثابت ساخته شده‌اند و درباره حالتی که وزن‌های خود مدل نیز تغییر می‌کنند پاسخی نمی‌دهد. نویسندگان نتیجه می‌گیرند که بازخورد تکرارشونده زمانی می‌تواند توانایی عامل را به‌شکلی قابل‌اتکا افزایش دهد که به تغییرهای ماندگار در شیوه اجرای وظایف تبدیل شود.

این پژوهش در زمینه‌ای انجام شده که تعمیم‌پذیری چارچوب‌ها محل توجه است. گزارش به آزمون‌هایی روی ARC-AGI-3 اشاره می‌کند که در آن‌ها چارچوبی ویژه به Opus 4.6 کمک کرد در محیط آشنا به ۹۷٫۱ درصد برسد، اما در محیط ناآشنا امتیازش صفر بود. همچنین به روش SoL-Pi از NVIDIA اشاره شده که چارچوب عامل‌های برنامه‌نویسی را خودکار بازسازی می‌کند و بنا بر گزارش، مصرف توکن را تا ۴۹ درصد کاهش می‌دهد، بدون افت محسوس عملکرد. این نمونه‌ها نشان می‌دهند که سنجش عامل‌ها فقط با امتیاز در وظایف آشنا، تصویر کاملی از توانایی آن‌ها نمی‌دهد.

این خبر برای چه کسانی اهمیت دارد

نتایج برای پژوهشگران عامل‌های هوش مصنوعی و تیم‌هایی که سامانه‌های خودکار را ارزیابی می‌کنند مهم است، چون نشان می‌دهد شیوه تنظیم چارچوب می‌تواند هم بر امتیاز و هم بر انتقال توانایی به وظایف نادیده اثر بگذارد. برای توسعه‌دهندگان نیز پیام عملی پژوهش این است که بهبود روی آزمون‌های تکراری به‌تنهایی کافی نیست و باید هزینه اجرا و عملکرد در بنچمارک‌های تازه هم سنجیده شود. در عین حال، این یافته‌ها هنوز به مدل‌های ثابت و مجموعه آزمون‌های بررسی‌شده محدودند و به‌تنهایی تضمین نمی‌کنند که روش در هر عامل یا وظیفه‌ای نتیجه مشابهی داشته باشد.