تصور کنید یک دانش‌آموز تمام پاسخ‌های امتحان را حفظ کند اما منطق ریاضی را نفهمد؛ این دقیقاً همان تله‌ای است که عامل‌های هوش مصنوعی در مسیر خودبهبودی در آن می‌افتند. برای مقابله با این «تله‌ی حفظ‌کردن»، پژوهشگران گوگل در ۴ اکتبر ۲۰۲۶ چارچوب جدیدی به نام منظم‌سازی خودبهبودی بازگشتی (Regularized Recursive Self-Improvement یا RRSI) را معرفی کردند که عامل‌ها را مجبور می‌کند مهارت‌های خود را به وظایفی که هرگز ندیده‌اند تعمیم دهند.
این مشکل از «هارنس» (Harness) یا همان سامانه‌ی ارزیابی نشأت می‌گیرد؛ سیستمی که تصمیم می‌گیرد آیا عامل پیش از تغییر یک فایل، آن را درست خوانده است یا خیر، آیا می‌تواند از اشتباهات خود بازیابی کند و آیا نتایج را به‌صورت تمیز و مرتب ارائه می‌دهد یا خیر. طبق گزارش پژوهشگران، پیشرفت‌های اخیر در هوش مصنوعی عامل‌محور (Agentic AI) از طریق خودکارسازی بازنویسی این هارنس‌ها توسط مدل‌های زبانی حاصل شده است، اما این حلقه‌ی بازگشتی اغلب منجر به بیش‌برازش (Overfitting) می‌شود. همان‌طور که در تحلیل قبلی ما درباره‌ی تأیید خارجی یادگیری فدرال در Gboard اشاره کردیم، این پژوهش اکنون تمرکز را از حریم خصوصی داده‌ها به یکپارچگی ساختاریِ نحوه‌ی یادگیری عامل‌ها از بازخوردها تغییر می‌دهد.
زمینه‌ی خودبهبودی بازگشتی
تا پیش از این، بهینه‌سازی هارنس به‌صورت دستی انجام می‌شد و انسان‌ها با بررسی اجراهای شکست‌خورده، سیستم را به‌صورت دستی وصله و اصلاح می‌کردند. متدهای جدیدتر این فرآیند را خودکار کرده‌اند؛ به‌طوری که یک مدل زبانی بر اساس بازخوردِ وظایف آزمایشی، هارنس را بازنویسی می‌کند. محققان این رویکرد را شکلی کاربردی از خودبهبودی بازگشتی می‌نامند.
با این حال، این خودبهینه‌سازی اغلب باعث می‌شود عامل‌ها الگوهایی را حفظ کنند که فقط برای یک محک (Benchmark) خاص کاربرد دارد. در واقع، فرآیند جست‌وجو ممکن است کاندیداهایی را انتخاب کند که صرفاً بر اساس شانس نمره بالایی گرفته‌اند یا پیچیدگی‌های غیرضروری را اضافه کند که نمره آزمون را بالا می‌برد اما لزوماً عامل را باهوش‌تر نمی‌کند. این موضوع در آزمون‌های ARC-AGI-3 به‌وضوح دیده شد؛ جایی که یک هارنسِ اختصاصی باعث شد مدل Opus 4.6 در محیط آشنا نمره ۹۷.۱ درصد بگیرد، اما در محیطی ناآشنا به صفر درصد سقوط کند.
RRSI برای حل این مشکل، حفاظ‌های (Guardrails) سخت‌گیرانه‌ای را در دو نقطه بحرانی حلقه بهینه‌سازی اعمال می‌کند: زمان پیشنهاد تغییرات و زمان نهایی کردن آن‌ها.
مکانیسم RRSI
- کاهش بودجه ویرایش: سیستم تعداد ویرایش‌های مستقلی را که یک کاندید می‌تواند به‌طور هم‌زمان در یک بسته اعمال کند، محدود می‌کند. در مراحل اولیه بازنویسی‌های گسترده مجاز است، اما در مراحل نهایی، تنها تغییرات کوچکی پذیرفته می‌شوند که بتوانند به‌وضوح به یک نتیجه‌ی مشخص ردیابی شوند.
- فیلتر منتقد: یک منتقد اختصاصی تمام پیشنهادها را بررسی کرده و هر تغییری که نام وظایف، راهکارهای خاص یا ترفندهای مربوط به یک محک خاص را به‌صورت سخت‌افزاری (Hardcode) وارد کند، به‌طور خودکار رد می‌کند.
- بهینگی محاسبات: هزینه‌های محاسباتی (Compute) بالاتر تنها در صورتی پذیرفته می‌شوند که منجر به بهبود قابل‌اندازه‌ی عملکرد شوند؛ در غیر این صورت، اجزای زائد و تکراری حذف می‌شوند.
- منطق اکتشاف: سیستم تلاش‌های قبلی را ردیابی می‌کند تا از تعقیب ایده‌های شکست‌خورده اجتناب کند. هنگامی که پیشرفت متوقف می‌شود، سیستم به‌طور عمدی بخش‌هایی از هارنس را که تا به حال دست‌نخورده مانده‌اند، آزمایش می‌کند.
برای آزمایش این چارچوب، تیم گوگل از مدل Claude Opus 4.8 به‌عنوان یک مدل پایه با وزن‌های ثابت در هشت محک مختلف (شامل کدنویسی، طراحی مهندسی و کارهای اداری) استفاده کرد. به نقل از گزارش the-decoder.com، متد RRSI توانست در وظایف آموزشی تا ۱۴.۱ امتیاز و به‌طور حیاتی، در پنج محک ناآشنا تا ۴.۷ امتیاز بهبود ایجاد کند.
در مقابل، سایر متدهای بهینه‌سازی در مواجهه با وظایف جدید دچار افت شدید شدند و عملکرد آن‌ها در تسک‌های جدید تغییر جهت داد، به‌طوری که برخی حتی پایین‌تر از سطح هارنس پایه قرار گرفتند. RRSI تنها متدی بود که در وظایف دیده‌نشده به‌طور قابل‌توجهی برتر بود و بیشترین رشد خود (۴.۷ امتیاز) را در JobBench ثبت کرد. علاوه بر این، هارنس RRSI در زمان اجرا حدود ۳۰٪ توکن کمتری نسبت به نسخه‌های بدون منظم‌سازی مصرف کرد.
این پژوهش همچنین نشان می‌دهد که این هارنس‌های بهینه‌شده، مستقل از مدل (Model-agnostic) هستند. برای مثال، یک هارنس کدنویسی که با Gemini 3.5 Flash بهینه شده بود، توانست صحت مدل ضعیف‌تر یعنی Gemini 3.1 Flash Lite را بدون هیچ تغییر اضافه‌ای از ۱۱.۲ به ۱۴.۶ امتیاز برساند. این یعنی مکانیسم‌های کشف‌شده توسط سیستم، به توانایی مدلِ کشف‌کننده وابسته نیستند.
برای جامعه فنی، این یافته‌ها این فرض را که خودبهبودی بازگشتی مسیری مستقیم و ساده به سوی توانمندی‌های AGI است، به چالش می‌کشد. این تحقیق ثابت می‌کند که بدون منظم‌سازی (Regularization)، «خودبهبودی» اغلب چیزی جز حفظ‌کردن داده‌ها در ابعاد بالا نیست. نتیجه یک موازنه است: RRSI کمترین رشد را در داده‌های آموزشی در میان تمام نسخه‌ها دارد، اما تنها متدی است که در دنیای واقعی کار می‌کند.
این رویکرد با روندهای فعلی صنعت برای افزایش بهره‌وری، مانند SoL-Pi انویدیا که مصرف توکن را در عامل‌های کدنویسی ۴۹٪ کاهش می‌دهد، هم‌سو است. همچنین به کارهای قبلی گوگل اشاره دارد که در آن عامل‌ها برای بهبود استراتژی بدون تغییر در خودِ مدل، درباره اجراهای جست‌وجوی گذشته «رویاپردازی» می‌کردند. این تلاش برای بهینه‌سازی استراتژی‌های عامل‌ها، در کنار توسعه لایه‌های بازیابی هوشمند در RAG که از حالت ایستا خارج شده‌اند، گامی به سوی سیستم‌های خودسازگارتر است. کد این تیم اکنون برای تأیید بیشتر در گیت‌هاب در دسترس است.
توسعه‌دهندگان باید رصد کنند که این هارنس‌های منظم‌شده در ترکیب با مدل‌هایی که دارای وزن‌های متغیر (Mutable Weights) هستند چگونه عمل می‌کنند، زیرا این مطالعه منحصراً بر روی مدل‌های ثابت متمرکز بود.
گام بعدی شما
- اگر از عامل‌های خودبهبودبخش استفاده می‌کنید، بررسی کنید که آیا مدل شما در حال یادگیری منطق است یا صرفاً الگوهای بنچمارک را حفظ می‌کند.
- برای کاهش هزینه استنتاج، از متدهای منظم‌سازی در بازنویسی هارنس‌ها استفاده کنید تا توکن‌های زائد حذف شوند. این رویکرد مشابه بهینه‌سازی‌های اخیر در خط لوله‌های DevOps است که با پیش‌بینی شکست تست‌ها، هزینه‌های ابری را کاهش داده است.
- عملکرد این هارنس‌ها را در مدل‌هایی با وزن‌های متغیر (Mutable Weights) رصد کنید، زیرا این مطالعه فقط روی مدل‌های ثابت متمرکز بود.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو