فاز 15 · درس 8

طراحی حلقه‌های خودبهبودی مهارشده

نوع
مفهومی
زمان
حدود 60 دقیقه
زبان‌ها
Python (stdlib, bounded-loop with invariant check)
پیش‌نیاز
فاز 15 · درس 07 (RSI)، فاز 15 · درس 04 (DGM)
یک چارچوب بتنی و پایدار با چهار ستون قفل‌شده و کابل‌های فولادی مهارکننده در اطراف یک مکعب نورانی فعال
فهرست مطالب
  1. صورت مسئله
  2. مبانی نظری
  3. سازوکار بنیادین 1: پایدارهای صوری
  4. سازوکار بنیادین 2: لنگرهای هم‌راستایی
  5. سازوکار بنیادین 3: محدودیت‌های چندهدفه
  6. سازوکار بنیادین 4: تشخیص پسرفت
  7. محدودیت‌های نظریه‌ی اطلاعات
  8. یک مثال گام‌به‌گام
  9. استفاده از ابزارهای واقعی
  10. تحویل به پروداکشن
  11. تمرین‌ها
  12. اصطلاحات کلیدی
  13. برای مطالعه‌ی بیشتر

وقتی یک سیستم هوش مصنوعی این توانایی را پیدا می‌کند که کد، ابزارها یا پایگاه دانش خود را اصلاح کند، کوچک‌ترین نرخ رشد مثبت در چرخه‌های متوالی می‌تواند آن را به‌سمت توانمندی‌های پیش‌بینی‌نشده ببرد. چالش اصلی در سامانه‌های خودبهبوددهنده (self-improving systems) این نیست که چطور سرعت رشد را بیشتر کنیم؛ مسئله‌ی مهندسی حیاتی این است که چطور جلوی تقلب سیستم را بگیریم تا معیارهای سنجش خودش را تضعیف یا هک نکند.

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

در این درس چهار سازوکار بنیادین مهندسی را بررسی می‌کنیم که جامعه‌ی پژوهشی هوش مصنوعی برای مقیدسازی حلقه‌های خودبهبودی روی آن‌ها توافق دارند: پایدارهای صوری (formal invariants)، لنگرهای هم‌راستایی (alignment anchors)، بهینه‌سازی چندهدفه و مکانیزم‌های تشخیص پسرفت. یاد می‌گیرید چطور یک چرخه‌ی به‌روزرسانی کد را به پشته‌ای از فیلترهای کنترلی مجهز کنید تا هرگونه ویرایش مخرب پیش از اعمال شناسایی و رد شود.

پژوهش‌ها بر سر چهار سازوکار بنیادین (primitives) برای مهار حلقه‌ی خودبهبودی (self-improvement loop) به توافق رسیده‌اند: پایدارها (invariants) یا خواص رسمی پایداری که باید در تک‌تک تغییرات برقرار بمانند؛ لنگرهای هم‌راستایی (alignment anchors) که دستکاری آن‌ها غیرممکن است؛ محدودیت‌های چندهدفه که در آن‌ها تمام ابعاد (ایمنی، انصاف، استحکام) باید حفظ شوند و صرفاً کارایی کافی نیست؛ و در نهایت، تشخیص پسرفت که با مشاهده‌ی نشانه‌های افت قابلیت در متریک‌های تاریخی، حلقه را متوقف می‌کند. هیچ‌کدام از این موارد اثبات قطعی ایمنی نیستند؛ نتایج نظریه‌ی اطلاعات (پیچیدگی کولموگروف و قضیه‌ی لوب) دامنه‌ی آنچه را که هر سیستم می‌تواند درباره‌ی جانشین‌های خود اثبات کند محدود می‌سازند. این‌ها صرفاً تمهیدات کاهنده‌ای هستند که هزینه‌ی شکست خاموش را بالا می‌برند.

صورت مسئله

شبیه‌ساز مسابقه‌ی درس 7 نشان داد که تفاوت‌های جزئی در نرخ رشد، در گذر زمان به شکاف‌های عظیمی تبدیل می‌شوند. مطالعه‌ی موردی DGM در درس 4 هم مشخص کرد که حلقه‌ها می‌توانند ارزیاب‌های خود را دور بزنند و بازی دهند. هر دو نتیجه به یک پرسش مهندسی واحد ختم می‌شوند: چه محدودیت‌هایی می‌توان روی یک حلقه‌ی خودبهبودی اعمال کرد تا خودِ حلقه نتواند آن‌ها را به‌صورت خاموش تضعیف کند؟

گزارش خلاصه‌ی کارگاه RSI در ICLR 2026 (به نشانی openreview.net/pdf?id=OsPQ6zTQXV) چهار مورد از این سازوکارهای بنیادین را مشخص می‌کند. سیاست مقیاس‌پذیری مسئولانه‌ی آنتروپیک یعنی RSP v3.0 (درس 19) و چارچوب ایمنی مرزی دیپ‌مایند یعنی FSF v3 (درس 20) هر دو در تعریف آستانه‌های توانمندی به این چهار اصل ارجاع می‌دهند. پروژه‌ی HyperAgents متا و فریم‌ورک‌های جامعه‌ی کاربری مانند SAHOO (مارس 2026) بخش‌هایی از این سازوکارها را در محیط عملیاتی (پروداکشن) پیاده‌سازی کرده‌اند.

صورت‌بندی واقع‌بینانه این است: این‌ها صرفاً تمهیدات کاهنده‌ی ریسک هستند. نتایج نظریه‌ی اطلاعات، دامنه‌ی اثبات هر سیستم درباره‌ی جانشین خود را محدود می‌کنند و در حال حاضر هیچ طرحی وجود ندارد که این مسئله را به‌صورت صوری و قطعی حل کند. یک حلقه‌ی مهارشده ایمن‌تر از یک حلقه‌ی مهارنشده است، اما ایمن به‌معنای مطلق کلمه نیست.

مبانی نظری

سازوکار بنیادین 1: پایدارهای صوری

یک پایدار شرطی است که باید قبل و بعد از هر خوداصلاحی پابرجا بماند. چند نمونه:

  • توزیع خروجی همیشه مشروط به یک هدر ثابت قانون اساسی (درس 17) باشد.
  • هیچ فراخوانی ابزاری (tool call) به یک اندپوینت غیرمجاز ارسال نشود.
  • نوشتن در حافظه فقط از مسیری لاگ‌شده و دارای امضای دیجیتال انجام گیرد.
  • هش ماژول ارزیاب دقیقاً با نسخه‌ی تاییدشده مطابقت داشته باشد.

بررسی این ویژگی‌های پایدار را کدی بیرونی انجام می‌دهد که حلقه دسترسی ویرایش آن را ندارد. اگر تغییر پیشنهادی حتی یکی از پایدارها را نقض کند، رد می‌شود. این رویکرد جلوی حالت دستکاری ارزیاب به سبک DGM (درس 4) را می‌گیرد.

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

سازوکار بنیادین 2: لنگرهای هم‌راستایی

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

  • متن یک قانون اساسی (درس 17) که در هر بار فراخوانی، از مسیری فقط‌خواندنی بارگذاری می‌شود.
  • یک ارزیاب در مخزنی (repository) مجزا با کنترل دسترسی کاملاً مستقل.
  • یک مانیفستِ دسترسی به ابزارها که به امضای انسان رسیده و در هر چرخه بازبینی می‌شود.

نقش لنگر، جلوگیری از انحراف هدف (objective drift) است. حلقه می‌تواند نحوه‌ی پیگیری هدف را بهبود دهد، اما حق ندارد ماهیت خود هدف را ویرایش کند.

حالت شکست ظریف این است: حتی لنگری که حلقه دسترسی به ویرایش آن ندارد، ممکن است توسط حلقه‌ای که درک و خوانش آن دچار انحراف شده، بازتفسیر شود. هوش مصنوعی قانون‌محور (Constitutional AI در درس 17) صراحتاً استدلال‌محور طراحی شده تا با موقعیت‌های جدید روبه‌رو شود؛ همین لایه‌ی استدلال، بستر شکل‌گیری انحراف تفسیری است. بنابراین لنگرها لازم هستند، اما کافی نیستند.

سازوکار بنیادین 3: محدودیت‌های چندهدفه

حلقه‌ای که فقط یک امتیاز عددی تک‌مقداری (scalar) را بهینه می‌کند، راه‌های میان‌بر خطرناکی پیدا خواهد کرد. اما حلقه‌ای که مجبور است هم‌زمان چندین قید قطعی را برآورده کند، میان‌برهای کمتری در اختیار دارد. محورهای معمول:

  • کارایی (بنچمارک در سطح وظیفه)
  • ایمنی (ارزیابی‌های ردتیم، نرخ امتناع مدل در برابر ورودی‌های مخرب شناخته‌شده)
  • انصاف (محدوده‌های اثر نامتناسب روی زیرگروه‌های حساس)
  • استحکام (مجموعه‌داده‌های خارج از توزیع، مدیریت ورودی‌های خصمانه)

یک تغییر تنها در صورتی تایید می‌شود که تمام قیود برقرار باشند. کنترل‌کننده‌ی هزینه در درس 13 این سازوکار را با قیود مالی ترکیب می‌کند. ابزار Llama Guard در درس 18 نیز دقیقاً در نقش یکی از همین محورهای ایمنی عمل می‌کند.

سازوکار بنیادین 4: تشخیص پسرفت

امتیازهای هر چرخه با توزیع‌های تاریخی مقایسه می‌شوند. هرگونه افت فراتر از رواداریِ (tolerance) تعیین‌شده، حلقه را متوقف می‌کند. این کار مانع از افت پنهان قابلیت‌ها می‌شود؛ افتی که در غیر این صورت، هم‌زمان با «پیشرفت و گذرِ» حلقه از آن، جذب میانگین متحرک می‌شد.

یک روش پیاده‌سازی کاربردی: امتیازهای هر وظیفه را برای N چرخه‌ی گذشته ذخیره کنید. در هر چرخه‌ی جدید، اختلاف کارایی (دلتا) به‌ازای هر وظیفه محاسبه می‌شود. اگر این اختلاف در هر وظیفه‌ای از یک آستانه پایین‌تر رفت، کل چرخه رد شده و پرونده برای بررسی به ناظر انسانی ارجاع داده می‌شود.

محدودیت‌های نظریه‌ی اطلاعات

پیچیدگی کولموگروف و قضیه‌ی لوب حد بالایی را برای آنچه یک سیستم می‌تواند درباره‌ی خودش اثبات کند تعیین می‌کنند. ماشین گودلِ صوری اشمیدهوبر (درس 4) در پی دستیابی به بالاترین حد ممکن از چنین اثباتی بود، اما تاکنون هیچ‌کس اثباتی غیربدیهی در این زمینه ارائه نکرده است. بر اساس قضیه‌ی لوب: اگر سیستمی بتواند به‌صورت اثبات‌پذیر باور داشته باشد که «اگر اثبات کنم باید X را انجام دهم، X را انجام خواهم داد»، بدون اینکه لزوماً لزوم آن را اثبات کرده باشد X را انجام می‌دهد؛ این همان خطای مشهور خودارجاعی است.

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

یک مثال گام‌به‌گام

فرض کنید یک ایجنت تغییری را پیشنهاد می‌دهد. پشته‌ی فیلترهای کنترلی (gating stack):

  1. بررسی پایدارهای صوری: هش ماژول‌ها، مانیفست مجوزهای ابزار، هدر قانون اساسی.
  2. بررسی لنگر: تطابق گزاره‌ی هدف با نسخه‌ی تاییدشده (به‌صورت بایتی یا معنایی).
  3. ارزیابی چندهدفه: بررسی محورهای کارایی، ایمنی، انصاف و استحکام.
  4. تشخیص پسرفت: اطمینان از اینکه هیچ محوری بیش از حد مجاز افت نکرده باشد.

برای اعمال نهایی تغییر، قبولی در هر چهار مرحله الزامی است. شکست در هر یک از آن‌ها حلقه را متوقف می‌کند.

خودبهبودبخشی مقیدتغییر باید از همه درگاه‌ها عبور کند
BOUNDED SELF-IMPROVEMENTA bounded loop checks each proposed self-modification against external invariants the loop cannot edit: formal invariants, an immutable alignment anchor, every safety objective, and a regression check. An edit is accepted only if it clears all of them; one that violates any gate is bounced. None of this is a proof of safety — it raises the cost of silent failure.پایدارهالنگر هم‌راستاییچندهregدفپسرفتویرایش×پذیرفته شد: همه پایدارها برقرارند
یک حلقه مقید، هر خوداصلاحیِ پیشنهادی را در برابر پایدار‌های خارجی که حلقه توانایی ویرایش آن‌ها را ندارد می‌سنجد: پایدار‌های صوری، لنگر هم‌راستایی تغییرناپذیر، تمام اهداف ایمنی و بررسی پسرفت. ویرایش تنها زمانی پذیرفته می‌شود که از همه آن‌ها عبور کند؛ تخطی از هر درگاه باعث رد آن می‌شود. هیچ‌کدام از این‌ها اثبات ایمنی نیست — بلکه هزینه خرابی خاموش را بالا می‌برد.

استفاده از ابزارهای واقعی

فایل code/main.py یک حلقه‌ی مهارشده‌ی خودبهبودی را روی نمونه‌ی آزمایشی سبک DGM از درس 4 اجرا می‌کند، با این تفاوت که چهار سازوکار بنیادین روی آن سوار شده‌اند. هر سازوکار را می‌توانید به‌طور جداگانه فعال یا غیرفعال کنید. هدف این سناریو نشان دادن این نکته است که هر سازوکار مانع دسته‌ای مشخص از شکست‌ها می‌شود و حذف هر کدام، راه را برای نفوذ همان دسته‌ی خاص باز می‌گذارد.

تحویل به پروداکشن

مستند outputs/skill-bounded-loop-review.md یک حلقه‌ی مهارشده‌ی پیشنهادی را ممیزی می‌کند و امتیاز می‌دهد که چه تعداد از این چهار سازوکار بنیادین را واقعاً پیاده‌سازی کرده و چه مواردی صرفاً در حد ادعا باقی مانده‌اند.

تمرین‌ها

  1. اسکریپت code/main.py را در حالتی که همه‌ی سازوکارها فعال هستند اجرا کنید. بررسی کنید که آیا حلقه بدون تسلیم شدن به رفتارهای دورزننده، روی متریک اصلی پیشرفت می‌کند یا نه.

  2. سیستم تشخیص پسرفت را غیرفعال کنید. ورودی‌ای بسازید که منجر به پذیرش افتی خاموش در قابلیت‌های سیستم شود.

  3. قید چندهدفه را غیرفعال کنید. نشان دهید حلقه چطور در محور کارایی همگرا می‌شود، در حالی که یکی از محورهای ایمنی دچار افت شدید شده است.

  4. یک لنگر هم‌راستایی برای یک ایجنت کدنویسی طراحی کنید. این لنگر شامل چه متنی است، در کجا ذخیره می‌شود و اعتبارسنجی آن چگونه انجام می‌گیرد؟

  5. خلاصه‌ی کارگاه RSI در ICLR 2026 را مطالعه کنید. یکی از چهار سازوکار بنیادین را انتخاب کرده و راهکاری عینی برای بهبود وضعیت فعلی آن پیشنهاد دهید.

اصطلاحات کلیدی

اصطلاح در گفتار عامیانه معنای دقیق فنی
پایدار (Invariant) «شرطی که همیشه درسته» ویژگی خاصی که توسط کدی بیرونی، قبل و بعد از هر ویرایش بررسی می‌شود
لنگر هم‌راستایی (Alignment anchor) «هدفِ فیکس‌شده» بازنمایی تغییرناپذیرِ هدف اصلی، بیرون از محدوده‌ی دسترسی ویرایشی حلقه
قید چندهدفه (Multi-objective constraint) «باید تو همه چی خوب باشه» الزام هم‌زمان به حفظ کارایی، ایمنی، انصاف و استحکام
تشخیص پسرفت (Regression detection) «افت کرد استپ کن» توقف حلقه زمانی که تغییرات متریک‌های تاریخی نشان‌دهنده‌ی افت توانمندی باشند
کران کولموگروف (Kolmogorov bound) «محدودیت تئوری اطلاعات» محدودیت در آنچه یک سیستم می‌تواند درباره‌ی جانشین خود اثبات کند
قضیه‌ی لوب (Lob's theorem) «تله‌ی خودارجاعی» سیستمی که می‌تواند بر اساس گزاره‌ی «باید انجام دهم» عمل کند، بدون آنکه انجام آن را اثبات کرده باشد
پشته‌ی گیت (Gate stack) «چک‌های چندلایه» ترکیب چند سازوکار بنیادین با هم؛ هر خطا باعث رد شدن ویرایش می‌شود
خودبهبودی مهارشده (Bounded improvement) «کاهش ریسک، نه اثبات» بالا بردن هزینه‌ی خطای خاموش، بدون بستن صوری مسئله‌ی ایمنی

برای مطالعه‌ی بیشتر

سؤالات متداول

آیا سازوکارهای مهار حلقه‌ی خودبهبودی ایمنی کامل را اثبات می‌کنند؟

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

لنگر هم‌راستایی (alignment anchor) چطور از تغییر اهداف جلوگیری می‌کند؟

لنگر هم‌راستایی بازنمایی تغییرناپذیری از مأموریت و هدف اصلی مدل است که خارج از محیط ویرایشی حلقه (مثلاً در یک مخزن مجزا با دسترسی فقط‌خواندنی) نگهداری و بازبینی می‌شود؛ به‌طوری‌که سیستم بتواند روش رسیدن به هدف را تغییر دهد ولی نتواند خود هدف را دستکاری کند.

چرا در حلقه‌های خودبهبودی به قید چندهدفه نیاز داریم؟

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

ما رو توی گوگل بیشتر ببین

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