گوگل با چارچوب RRSI جلوی حفظ طوطی‌وار داده‌ها در عامل‌های هوش مصنوعی را گرفت

اگر امروز یک عامل هوش مصنوعی می‌سازید که فقط به دنبال کسب بالاترین امتیاز در بنچمارک‌هاست، احتمالاً با عاملی روبه‌رو هستید که پاسخ‌ها را حفظ کرده است، نه اینکه آن‌ها را بفهمد. گوگل پژوهشی (Google Research) در ۹ اکتبر ۲۰۲۶ با معرفی منظم‌سازی بازگشتی خودبهبودی (Regularized Recursive Self-Improvement یا RRSI)، راهکاری ارائه داد که عامل‌ها را مجبور می‌کند هر بهبود را از طریق یک تحلیل سخت‌گیرانه هزینه-فایده توجیه کنند.

همان‌طور که در تحلیل قبلی ما درباره‌ی وابستگی پایداری عامل‌ها به «هارنس» اشاره کردیم، RRSI تمرکز را از مدل زبانی ثابت به زیرساخت‌های اطراف آن منتقل می‌کند. در یک پیکربندی معمولی، «هارنس» — یعنی مجموعه‌ی پرامپت‌ها، حافظه و ابزارهای عامل — ایستا است. اما RRSI با این هارنس مانند یک کد برنامه‌نویسی زنده برخورد می‌کند که عامل می‌تواند برای بهینه‌سازی عملکردش، آن را بازنویسی کند. این رویکرد تکاملی یادآور مکانیسم‌های بازنویسی کد داخلی در عامل Darwin Gödel است که پیش‌تر توانست با تغییر در ساختار خود، رکورد جدیدی در بنچمارک‌های مهندسی نرم‌افزار ثبت کند.

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

مکانیسم حلقه‌ی RRSI

به نقل از راهنمای فنی marktechpost، حلقه‌ی RRSI با استفاده از مدل Claude Opus روی پلتفرم Vertex AI پیش‌نویس‌های اصلاحی را ایجاد می‌کند. این اصلاحات سپس در محیط‌های ایزوله‌ی Docker تست می‌شوند تا از خرابی سیستم جلوگیری شود. اما نوآوری اصلی در مرحله‌ی انتخاب است؛ یعنی جایی که تصمیم گرفته می‌شود کدام اصلاحات باقی بمانند.

سیستم RRSI برای هر نسخه‌ی هارنس، دو معیار کلیدی را اندازه‌گیری می‌کند:

• S (پاداش): میانگین پاداش به‌دست‌آمده در تمام تلاش‌ها برای هر تکلیف.
• C (هزینه): میانگین تعداد توکن (Token) — تکه‌های کوچکی از متن، شبیه برش‌های یک کیک طولانی که مدل تکه‌تکه می‌خورد — که در هر تلاش مصرف شده است.

یک جزئیات حیاتی در این تخمین‌گر، نحوه‌ی برخورد با کرش‌هاست. تخمین‌گرهای ساده معمولاً تلاش‌های شکست‌خورده را حذف می‌کنند که باعث می‌شود یک کرش، به‌اشتباه به عنوان یک دستاورد دیده شود. اما RRSI هر تلاش ناموفق را با پاداش صفر محاسبه می‌کند. برای مثال، اگر یک کاندید در سخت‌ترین تکلیف کرش کند، تخمین‌گر ساده ممکن است امتیاز ۰.۷۵۰ را گزارش کند، اما RRSI امتیاز را به ۰.۵۰۰ می‌رساند. این کار مانع از آن می‌شود که عامل با حذف تکالیفی که نمی‌تواند حل کند، «بهتر» به نظر برسد.

پاداش‌های وزنی و دستورالعمل‌ها

سیستم RRSI همچنین از پاداش‌های وزنی برای مجموعه‌هایی که بر اساس دستورالعمل (Rubric) نمره می‌گیرند، مانند Harvey LAB، پشتیبانی می‌کند. در این سناریوها، پاداش S به‌جای میانگین ساده از میانگین‌های هر تکلیف، به صورت کسری از تمام معیارهای پاس‌شده در کل مجموعه محاسبه می‌شود. این رویکرد تضمین می‌کند که معیارهای با وزن بالا در طول فرآیند خودبهبودی در اولویت قرار گیرند.

باند نویز کالیبره شده

یکی از بزرگ‌ترین موانع در خودبهبودی هوش مصنوعی، «شانس» است. ممکن است یک هارنس در یک اجرا فقط به‌دلیل ماهیت تصادفی مدل‌های زبانی امتیاز بیشتری بگیرد. RRSI این مشکل را با یک باند نویز کالیبره شده (delta) حل می‌کند.

سیستم با ارزیابی چندین‌باره‌ی یک هارنس بدون تغییر، میزان نوسان طبیعی امتیاز را می‌سنجد. در یک شبیه‌سازی با ۴۰ تکلیف و ۲ تلاش برای هر کدام، پراکندگی امتیاز یک هارنس ثابت ۰.۱۱۳ بود. تابع calibrate() این ارزیابی‌های تکراری را به یک مقدار delta تبدیل می‌کند که به صورت z ضربدر انحراف معیار تفاوت تهی (که در آن z یک هایپرپارامتر به نام delta_z است) تعریف می‌شود.

اگر بهبود جدید کوچک‌تر از این delta باشد، سیستم آن را «مساوی» تلقی می‌کند تا منابع محاسباتی روی بهبودهایی که از نظر آماری با نویز تفاوتی ندارند، تلف نشود. طبق گزارش‌ها، این باند برای کارهای کدنویسی ۰.۰۱۷، برای فضای کاری (workspace) ۰.۰۰۴ و برای مهندسی ۰.۰۲۰ است.

منطق انتخاب در الگوریتم ۲

برای پذیرش یک هارنس کاندید، RRSI سه قانون سخت‌گیرانه را اجرا می‌کند:

۱. کف عملکرد: یک کاندید رد می‌شود اگر امتیاز آن کمتر از بهترین امتیاز ثبت‌شده در تاریخچه (S*) منهای باند نویز (delta) باشد. این کار باعث می‌شود عملکرد به جای اینکه به نسخه‌ی فعلی وابسته باشد، به اوج تاریخی متصل شود.
۲. قانون هزینه: هر بهبودی بزرگ‌تر از delta باید هزینه‌ی توکن‌های اضافی‌اش را بپردازد. تغییر هزینه نسبی (dC) باید طبق فرمول dC <= 0.10 + 40 * dS باشد. مثلاً افزایش ۶ امتیازی با ۲۰٪ توکن بیشتر پذیرفته می‌شود، اما افزایش ۳ امتیازی با ۱۵۰٪ توکن بیشتر رد می‌شود.
۳. ترجیح نهایی: در محدوده باند نویز، امتیازها مساوی تلقی می‌شوند. سیستم در این حالت هارنس ارزان‌تر را با استفاده از یک امتیاز شکل‌یافته (۱۰۰ ضربدر بهبود منهای ۱۵ ضربدر تغییر هزینه) ترجیح می‌دهد. همچنین پاداش کوچکی به «نوآوری ساختاری» — یعنی اجزایی که عامل قبلاً هرگز با موفقیت استفاده نکرده — داده می‌شود.

این منطق باعث تصمیمات غیرمنتظری می‌شود. RRSI ممکن است هارنسی را بپذیرد که امتیاز کمی کمتر از نسخه‌ی فعلی دارد، اما هزینه‌ی توکن را به‌شدت کاهش داده است، به شرطی که بالاتر از کف مطلق باقی بماند. همچنین یک «نگهبان دامنه» (domain guard) می‌تواند بدون توجه به امتیاز، هر کاندیدی را که یک الزام امنیتی یا خروجی خاص را نقض کند، وتو کند.

جلوگیری از حفظ طوطی‌وار و نشت داده

برای اینکه عامل‌ها پاسخ‌ها را به‌صورت سخت‌افزاری (Hard-code) در حافظه ذخیره نکنند، RRSI یک منتقد دو لایه دارد. لایه‌ی اول یک غربال قطعی است که با الگوهای regex تشخیص می‌دهد آیا عامل در حال خواندن فایل‌های نمره‌دهی یا حفظ شناسه‌ی تکالیف است یا خیر.

جزئیات غربال قطعی:

• تشخیص ID تکلیف: الگوهایی مثل \btask_\d{3}\b برای شناسایی تلاش‌های کدنویسی شناسه‌ی تکالیف مجموعه‌ی تکامل (evolve-set).
• دسترسی به نمره‌دهنده: جست‌وجوی کلماتی مثل expected_output یا grader یا rubric[ برای شناسایی تلاش برای دیدن پاسخ‌ها.
• نشت اعتبارنامه‌ها: بررسی برای یافتن API keyها یا اعتبارنامه‌های لو رفته.

اگر تغییری حاوی خطی مثل memory.remember('task_007', cached_patch) باشد، منتقد فوراً آن را رد می‌کند بدون اینکه توکنی برای ارزیابی هزینه شود. تنها تغییرات پاک، به لایه‌ی دوم یعنی بررسی قصد (Intent Review) توسط مدل Claude می‌روند.

برچسب‌گذاری و نرمال‌سازی اجزا

برای جلوگیری از دروغ گفتن عامل درباره‌ی تغییراتش برای گرفتن پاداش نوآوری، تابع normalize تغییرات را بررسی می‌کند. این تابع diff را برای یافتن شواهدی از جزء اعلام شده چک می‌کند. مثلاً یک تغییر تنها زمانی به عنوان control_flow برچسب می‌خورد که سیگنال‌هایی مثل retry( یا max_attempts در کد باشد. اگر عامل یک تغییر ساده در پرامپت را به عنوان «مهارت جدید» معرفی کند بدون اینکه شواهدی وجود داشته باشد، برچسب به تغییر واقعی شناسایی شده در diff بازمی‌گردد.

مدیریت بودجه‌ی ویرایش

عامل اجازه ندارد همه‌چیز را یک‌باره تغییر دهد. RRSI از یک بودجه L0 با زمان‌بندی کسینوسی استفاده می‌کند: b_t = ceil(b_min + (b_max - b_min) * (1 + cos(pi * t / T)) / 2).

در ابتدای مسیر، عامل می‌تواند تا ۴ ویرایش هماهنگ را اعمال کند (b_max=4). اما با پیشرفت فرآیند، این بودجه به ۱ ویرایش در هر کاندید کاهش می‌یابد (b_min=1). به‌دلیل استفاده از تابع ceil()، بودجه تنها در لحظه‌ی t = T (یک گام بعد از پایان اجرا) به حداقل خود یعنی یک می‌رسد.

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

تاریخچه ویرایش و هرس کردن

سیستم یک تاریخچه‌ی دقیق در قالب JSONL نگه می‌دارد که نتیجه‌ی هر کاندید را ثبت می‌کند. این تاریخچه برای استخراج چهار خلاصه کلیدی استفاده می‌شود:

• مجموعه‌ی امتحان‌شده (Tried Set): تمام اجزایی که اندازه‌گیری شده‌اند (به جز مواردی که توسط منتقد رد شده‌اند).
• بازده اخیر (g_t): بهترین بهبود اندازه‌گیری شده برای هر جزء در n_prune دور اخیر.
• مجموعه‌ی هرس (B_t): اجزایی که بازده اخیر آن‌ها مثبت نیست. این‌ها برای حذف علامت‌گذاری می‌شوند، حتی اگر در حال حاضر در نسخه‌ی فعال باشند.
• پرچم توقف (sigma_t): زمانی فعال می‌شود که امتیاز در w دور اخیر کمتر از مقدار delta تغییر کرده باشد.

در صورت توقف، مکانیسم exploration دستوراتی را به پیشنهاددهنده می‌فرستد تا یک جایگاه کاندید را برای اجزایی رزرو کند که در طول اجرا هرگز امتحان نشده‌اند. این کار از تکرار فرضیات غلط جلوگیری می‌کند.

نتایج ممیزی داده‌های مرجع

بر اساس نتایج شبیه‌سازی در محیطی که اثر واقعی هر ویرایش مشخص بود، RRSI برتری واضحی نسبت به جست‌وجوی «حریصانه» (Greedy Search) داشت. در حالی که جست‌وجوی حریصانه اغلب امتیازات خام بالاتری در مجموعه‌ی آموزش گرفت، اما این کار را با حفظ پاسخ‌ها و تقریباً سه برابر کردن هزینه‌ی توکن‌ها (۲.۹۷ برابر در مقابل ۱.۵۳ برابر در RRSI) انجام داد.

در مقابل، RRSI هیچ پاسخ حفظ‌شده‌ای نداشت و از ارزیابی‌های یک‌سوم کمتری استفاده کرد. با افزایش دقت محیط ارزیابی — از طریق افزایش تعداد تکالیف و تلاش‌ها — باند نویز از 0.096 به 0.025 کاهش یافت و امتیاز RRSI در داده‌های خارج از آموزش (Held-out) از 0.616 به 0.759 افزایش یافت.

تحلیل: موازنه منظم‌سازی

برای توسعه‌دهندگان، RRSI این فرض را تغییر می‌دهد که «امتیاز بالاتر یعنی عامل بهتر». در دنیایی که توکن‌ها گران هستند و نشت داده یک ریسک امنیتی است، بهترین عامل کسی است که بیشترین قابلیت اطمینان را با کمترین هزینه فراهم کند.

این چارچوب ثابت می‌کند که منظم‌سازی (Regularization) — شبیه به گذاشتن یک ترمز برای جلوگیری از تند رفتن ماشین در پیچ‌ها — فقط برای وزن‌های مدل نیست، بلکه برای جلوگیری از Overfitting (بیش‌برازش) در رفتار عامل است. این رویکرد در واقع تکامل‌یافته‌ی استراتژی‌های امتیازدهی و بازآموزی است که پیش‌تر برای تبدیل چت‌بات‌های ساده به عامل‌های عملیاتی به کار می‌رفت. با متصل کردن «کف عملکرد» به بهترین امتیاز تاریخی به جای نسخه‌ی فعلی، RRSI تضمین می‌کند که عامل نمی‌تواند با یک سری جایگزینی‌های ارزان اما کمی ضعیف‌تر، عملکرد خود را به‌تدریج پایین بیاورد.

آینده‌ی هوش مصنوعی عامل‌محور احتمالاً نه در مدل‌های بزرگ‌تر، بلکه در «متا-هارنس‌های» پیچیده‌تری است که می‌توانند منطق خود را در لحظه ممیزی و هرس کنند. ارزش منظم‌سازی RRSI به هزینه توکن‌ها و ریسک نشت پاسخ‌ها بستگی دارد که هر دو با ابزارهای ارائه شده قابل اندازه‌گیری هستند.

برای شروع پیاده‌سازی، توسعه‌دهندگان می‌توانند به مخزن رسمی در گیت‌هاب دسترسی پیدا کنند و رابط rrsi.domain.Domain را پیاده کنند تا محیط‌های خود را به حلقه‌ی RRSI متصل کنند. این کار شامل تعریف متدهای evolve_ids و heldout_ids و run() برای مدیریت درخت کاری و نتایج تلاش‌ها است.

گام بعدی شما

• اگر از عامل‌های خودبهبود استفاده می‌کنید، یک «کف عملکرد» (Performance Floor) بر اساس بهترین رکورد تاریخی تعریف کنید تا از افت کیفیت تدریجی جلوگیری شود.
• برای کاهش هزینه‌ها، معیار پذیرش تغییرات را به جای «فقط افزایش امتیاز»، به «نسبت افزایش امتیاز به افزایش توکن» تغییر دهید.
• از الگوهای Regex برای ممیزی تغییرات عامل‌ها استفاده کنید تا مطمئن شوید مدل در حال حفظ پاسخ‌ها یا دسترسی به فایل‌های تست نیست.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.