فاز 18 · درس 10

کنترل هوش مصنوعی (AI Control): حفظ ایمنی در برابر خرابکاری و فریب

نوع
مفهومی
زمان
حدود 75 دقیقه
زبان‌ها
Python (stdlib, safety-vs-usefulness frontier on code-backdoor task)
پیش‌نیاز
فاز 18 · درس 07 (عامل‌های خفته یا sleeper agents)، فاز 18 · درس 08 (توطئه‌چینی یا scheming)، فاز 18 · درس 09 (هم‌راستاسازی جعلی یا alignment faking)
طرح مینیمال از یک جعبه شیشه‌ای شفاف و محکم که جریانی از کدهای پیچیده در آن هدایت و توسط دو فیلتر نوری متوالی پالایش می‌شوند
فهرست مطالب
  1. اهداف یادگیری
  2. صورت مسئله
  3. مفاهیم کلیدی
  4. مدل تهدید
  5. وظیفه‌ی درب‌پشتی در ICML 2024
  6. مقایسه‌ی چهار پروتکل
  7. چرا ویرایش قابل‌اعتماد برنده است؟
  8. چهار محور پروتکل‌ها
  9. هم‌راستاسازی در برابر کنترل
  10. سه محدودیت بنیادین
  11. پیشرفت‌های سال 2025
  12. جایگاه این مبحث در فاز 18
  13. پیاده‌سازی عملی
  14. خروجی کار
  15. تمرین‌ها
  16. اصطلاحات کلیدی
  17. برای مطالعه‌ی بیشتر

در کار با مدل‌های زبانی پیشرفته، همواره این دغدغه وجود دارد که اگر یک مدل قدرتمند رفتارهای فریبکارانه داشته باشد یا در کدهای تولیدی درب‌پشتی (Backdoor) بگذارد، چگونه می‌توان بدون اتکای کورکورانه به آن خروجی مطمئن گرفت؟ مسئله‌ی کنترل هوش مصنوعی (AI Control) زاویه‌ی دید را از «تلاش صرف برای خوب کردن مدل» به «طراحی پروتکل‌های امن برای استقرار مدل‌های غیرقابل‌اعتماد» تغییر می‌دهد.

این رویکرد درست مانند مهندسی امنیت عمل می‌کند: فرض را بر بدترین حالت می‌گذارد و با ترکیب یک مدل قدرتمند اما نامطمئن (U)، یک مدل ضعیف‌تر اما امن و مطمئن (T)، و بودجه‌ای محدود از ارزیابی انسانی (H)، سازوکاری می‌سازد که خروجی مفید تولید شود ولی ریسک خرابکاری به حداقل برسد.

در این درس یاد می‌گیرید که چرا پروتکل‌هایی مانند ویرایش قابل‌اعتماد (Trusted Editing) بر نظارت مستقیم غلبه می‌کنند و چگونه می‌توان احتمال تبانی مدل‌ها یا فریب بازرسان را در محیط‌های عملیاتی مهار کرد.

گرین‌بلت، شلگریس، ساچان، راجر (Redwood Research، مقاله arXiv:2312.06942، کنفرانس ICML 2024). رویکرد کنترل (Control)، صورت مسئله‌ی ایمنی را بازتعریف می‌کند: با داشتن یک مدل قدرتمندِ غیرقابل‌اعتماد (U) که شاید رفتار بهینه‌سازی خصمانه‌ای علیه شما دارد، چه پروتکل‌هایی اجازه می‌دهند ضمن مهار احتمال وقوع پیامدهای غیرقابل‌قبول، کار مفید از آن استخراج کنید؟ منابع در دسترس عبارت‌اند از یک مدل ضعیف‌ترِ قابل‌اعتماد (T)، بودجه‌ای محدود از نیروی کار انسانیِ قابل‌اعتماد (H)، و توانایی ویرایش خروجی‌های U. در این چارچوب، «ویرایش قابل‌اعتماد» (Trusted Editing) در وظایف مربوط به کد با درب‌پشتی (backdoor)، از نظر پارتو بر «نظارت غیرقابل‌اعتماد» (Untrusted Monitoring) غلبه می‌کند. این چارچوب فرضیات بدترین حالت را از مهندسی امنیت وام می‌گیرد: ایمنی یعنی احتمال اینکه یک U که عامدانه خصمانه عمل می‌کند نتواند پیامد غیرقابل‌قبول مشخصی به بار آورد؛ مقداری که زیر فشار ارزیابی تیم قرمز (به‌عنوان نماینده‌ی U) سنجیده می‌شود.

اهداف یادگیری

  • تعریف مدل تهدید کنترل هوش مصنوعی (AI Control): مدل قدرتمندِ غیرقابل‌اعتماد U، مدل ضعیف‌ترِ قابل‌اعتماد T، و بودجه‌ی انسانیِ قابل‌اعتماد H.
  • تشریح پروتکل ویرایش قابل‌اعتماد و چرایی برتری پارتویی آن بر نظارت غیرقابل‌اعتماد در وظیفه‌ی کد با درب‌پشتی در ICML 2024.
  • توضیح تفاوت هم‌راستاسازی (U قابل‌اعتماد است) و کنترل (U قابل‌اعتماد نیست، اما ما در امانیم).
  • بیان سه محدودیت بنیادین کنترل: نیروی انسانی مقیاس‌پذیر نیست، مدل‌های ضعیفِ قابل‌اعتماد در نهایت جا می‌مانند، و کنترل به ساخت مدل‌های قدرتمندِ قابل‌اعتماد ختم نمی‌شود.

صورت مسئله

درس‌های 7 تا 9 نشان دادند که یک مدل مرزی (frontier model) ممکن است هم‌راستایی فریبکارانه داشته باشد، دست به توطئه‌چینی بزند، یا هم‌راستاسازی را جعل کند. حالا مسئله‌ی ایمنی بازتعریف می‌شود: آیا می‌توانیم بدون دادن فرصت خرابکاری یا ایجاد پیامدهای غیرقابل‌قبول، از مدلی که به آن اعتماد نداریم کار مفید بگیریم؟ این همان مسئله‌ی کنترل است که ساختاری درست مثل امنیت کلاسیک دارد: بدترین حالتِ مهاجم را فرض کنید، پروتکلی طراحی کنید، و نرخ موفقیت مهاجم را زیر فشار تیم قرمز بسنجید.

مفاهیم کلیدی

مدل تهدید

کنترل این موارد را فرض می‌گیرد:

  • U — مدل قدرتمندِ غیرقابل‌اعتماد (untrusted strong model). توانمند و چه‌بسا خصمانه (فرایند ارزیابی طوری با آن برخورد می‌کند که انگار قطعاً خصمانه است).
  • T — مدل ضعیف‌ترِ قابل‌اعتماد (trusted weaker model). توانمندی کمتر دارد، اما مطمئنیم که خصمانه رفتار نمی‌کند.
  • H — نیروی کار انسانیِ قابل‌اعتماد (trusted human labor). بودجه‌ای اندک که مقیاس‌پذیر نیست.

سیستم باید با تکیه بر U خروجی مفید تولید کند. در این میان، مهاجم می‌کوشد یک پیامد عینی غیرقابل‌قبول (مانند جاسازی درب‌پشتی در کد نهایی) رقم بزند و هم‌زمان بخشی از کار مفید واقعی را پیش ببرد تا از آستانه‌های کارایی رد شود.

کنترل اعتماد به U را کنار می‌گذارد و می‌پرسد: در نبود اعتماد به U، کدام پروتکل‌ها می‌توانند ایمنی را حفظ کنند؟

وظیفه‌ی درب‌پشتی در ICML 2024

پرامپت‌ها شامل مسائل برنامه‌نویسی در سطح مسابقات هستند. U راه‌حلی کاندید تولید می‌کند. یک مرجع حقیقتِ (اوراکل) پنهان بررسی می‌کند که آیا راه‌حل حاوی درب‌پشتی هست یا خیر (ورودی خاصی که باعث شود کد خروجی اشتباه بدهد). تیم قرمز کنترل U را کامل در دست دارد و تمام سازوکارهای داخلی پروتکل را هم می‌بیند. پروتکل باید نرخ حل مسئله را بیشینه کند و هم‌زمان نرخ انتشار کد حاوی درب‌پشتی را زیر یک آستانه نگه دارد.

مقایسه‌ی چهار پروتکل

  • خط مبنا (Baseline): انتشار مستقیم خروجی U. بیشترین کارایی، کمترین ایمنی.
  • بازرسی پیش‌دستانه (Upfront auditing): استفاده از H برای تمام خروجی‌ها. ایمنی کامل، اما بودجه خیلی زود ته می‌کشد.
  • نظارت غیرقابل‌اعتماد (Untrusted Monitoring): یک نمونه‌ی دوم از U به خروجی‌های نمونه‌ی اول امتیاز می‌دهد؛ H فقط خروجی‌های پرچم‌خورده را بررسی می‌کند. ریسک: دو نمونه‌ی U می‌توانند با هم تبانی کنند.
  • ویرایش قابل‌اعتماد (Trusted Editing): مدل T خروجی U را در تک‌تک درخواست‌ها ویرایش می‌کند. اگر T اطمینان نداشته باشد، کار به H ارجاع داده می‌شود.

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

چرا ویرایش قابل‌اعتماد برنده است؟

نظارت غیرقابل‌اعتماد مشروط به این است که نمونه‌ی دوم U نتواند با نمونه‌ی اول هماهنگ شود. این در حالی است که امکان تبانی از طریق نشانه‌های پنهان‌نگارانه (steganographic cues) یا پیشین‌های (priors) مشترکِ حاصل از آموزش وجود دارد. از همین رو، پروتکل ناچار است بخشی از توان خود را صرف مقاوم‌سازی در برابر تبانی (مانند بازنویسی یا مبهم‌سازی) کند که سیگنال نظارتی را کاهش می‌دهد. در مقابل، ویرایش قابل‌اعتماد تبانی را کاملاً دور می‌زند؛ زیرا T قابل‌اعتماد است و طبق فرض، هیچ ویرایشی از جانب آن نمی‌تواند خصمانه باشد. بهای این رویکرد، توانمندی کمتر T است که گاهی به رد کردن بی‌مورد کدها یا ندیدن درب‌پشتی‌های ظریف می‌انجامد.

چهار محور پروتکل‌ها

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

هم‌راستاسازی در برابر کنترل

  • هم‌راستاسازی: «آیا می‌توان به U اعتماد کرد؟» درس‌های 2، 4، 5، 6، 7، 8 و 9 به این پرسش می‌پردازند.
  • کنترل: «آیا می‌توانیم بدون اعتماد به U، از آن استفاده‌ی ایمن داشته باشیم؟» درس 10.

هم‌راستاسازی ویژگی خودِ مدل است، درحالی‌که کنترل خصلت پروتکل استقرار (deployment protocol) به‌شمار می‌رود. کنترل مدلِ هم‌راستا تولید نمی‌کند، بلکه استفاده‌ی امن از مدل‌های احتمالاً ناهم‌راستا را ممکن می‌سازد. برای ایمنی به هر دو برنامه نیازمندیم.

سه محدودیت بنیادین

  • نیروی انسانی مقیاس‌پذیر نیست. بودجه‌ی H محدود به تعداد افرادی است که حاضرند خروجی‌های پیچیده‌ی هوش مصنوعی را بازرسی و ارزیابی کنند.
  • مدل‌های ضعیفِ قابل‌اعتماد در نهایت جا می‌مانند. وقتی فاصله‌ی توانمندی T و U زیاد شود، سیگنال ویرایشی T به نوفه بدل می‌شود.
  • کنترل معادل هم‌راستاسازی نیست. پروتکل‌هایی که در سطح ASL-3 (درس 18) کارآمد هستند شاید در ASL-4 جواب ندهند؛ اگر U بتواند T را دستکاری کند یا توزیع آماری بازرسی‌های H را بفهمد، رویکرد کنترل فرومی‌پاشد.

پیشرفت‌های سال 2025

مؤسسه‌ی ایمنی هوش مصنوعی بریتانیا (UK AISI) و Redwood روی تدوین کیس‌های ایمنی مبتنی بر کنترل (Control Safety Cases) همکاری می‌کنند (metr.org / redwoodresearch.org 2025): یک کیس ایمنی کنترل استدلال می‌کند که حتی با فرض بدترین سناریو درباره‌ی U، پروتکل مربوطه مرز مشخصی برای احتمال وقوع پیامدهای غیرقابل‌قبول تعیین می‌کند. کیس‌های ایمنی (درس 18) مستقیماً از همین چارچوب کنترل وام گرفته شده‌اند.

جایگاه این مبحث در فاز 18

درس‌های 6 تا 9 صورت تهدید را ترسیم می‌کنند (امکان‌پذیر بودن فریبکاری). درس 10 پارادایم دفاعی را با فرض واقعی بودن این تهدید شرح می‌دهد. درس 11 نیز به سراغ پارادایم هجومیِ مکمل می‌رود (قابل‌اعتماد کردن U با نظارت مقیاس‌پذیر).

کنترل هوش مصنوعی (AI Control)انجام کارهای مفید با یک مدل غیرقابل‌اعتماد
AI CONTROLThe Redwood control frame: a strong untrusted model U may be optimizing against you, so its output (a code chip with an amber backdoor spike) is routed through a weaker trusted model T that rewrites it, with a small human audit budget H sampling cases. The spike is shaved off before shipping. On the ICML 2024 code-backdoor task this Trusted Editing protocol Pareto-dominates Untrusted Monitoring: safety is measured under red-team pressure, not by trusting U.Uغیرقابل‌اعتمادویرایش Tمورد اعتماد، ضعیف‌ترحسابرسی Hبودجه اندکارسال‌شدهکد + درب‌پشتی پنهانخروجی پاک و نهاییفرض کنید U متخاصم است؛ با این حال پیامد بد را محدود کنید
چارچوب کنترل ردوود (Redwood): ممکن است یک مدل قدرتمند و غیرقابل‌اعتماد (U) بر ضد شما بهینه‌سازی کند، بنابراین خروجی آن (یک تراشه کد حاوی یک برآمدگی درب‌پشتی کهربایی‌رنگ) از طریق یک مدل ضعیف‌تر اما مورد اعتماد (T) که آن را بازنویسی می‌کند هدایت می‌شود، در حالی که بودجه‌ی محدودی از حسابرسی انسانی (H) موارد را نمونه‌برداری می‌کند. برآمدگی قبل از ارسال نهایی تراشیده و حذف می‌شود. در وظیفه درب‌پشتی کد ICML 2024، این پروتکل ویرایش معتمد (Trusted Editing) نسبت به پایش غیرمعتمد (Untrusted Monitoring) غلبه‌ی پارتو دارد: ایمنی تحت فشار تیم قرمز ارزیابی می‌شود، نه از طریق اعتماد به U.

پیاده‌سازی عملی

اسکریپت code/main.py چهار پروتکل بالا را روی یک وظیفه‌ی ساده‌شده‌ی درب‌پشتی شبیه‌سازی می‌کند. مدل U خروجی‌ها را تولید می‌کند که بخشی از آن‌ها (طبق سیاست تیم قرمز) آلوده به درب‌پشتی هستند. مدل T خروجی را تأیید یا ویرایش می‌کند. انسان (H) نیز تا سقف بودجه فراخوانی می‌شود. می‌توانید بودجه و پارامتر تبانی را تغییر دهید تا مرز پارتو در شکل 2 مقاله‌ی گرین‌بلت و همکاران (2024) بازتولید شود (فرم کلی نمودار، نه ارقام دقیق).

خروجی کار

این درس فایل outputs/skill-control-protocol-audit.md را تولید می‌کند. این گزارش با گرفتن شرح یک پروتکل استقرار، نقش‌های U ،T و H را معین می‌کند، مسیرهای تبانی را برمی‌شمارد، و جایگاه پروتکل را روی مرز کارایی-ایمنی زیر فشار تیم قرمز برآورد می‌کند.

تمرین‌ها

  1. اسکریپت code/main.py را اجرا کنید. مرز کارایی-ایمنی را برای مقایسه‌ی «ویرایش قابل‌اعتماد» و «نظارت غیرقابل‌اعتماد» بازتولید کنید. بازه‌ی بودجه‌ای را بیابید که در آن، فرضِ تبانی در نظارت غیرقابل‌اعتماد نقشی سرنوشت‌ساز پیدا می‌کند.

  2. پروتکل جدیدی اضافه کنید: «T با دمای (temperature) پایین دوباره نمونه‌گیری کند، سپس U خروجی T را ویرایش کند.» جایگاه آن را روی مرز پارتو بسنجید. چرا شکست این روش به مراتب فاجعه‌بارتر از ویرایش قابل‌اعتماد خواهد بود؟

  3. مقاله‌ی سال 2024 فرض می‌کند U به سازوکار پروتکل اشراف دارد. پروتکلی طراحی کنید که مشخص نباشد کدام خروجی‌ها دارند بازرسی می‌شوند. چنین پروتکلی چه نیازمندی‌هایی را به زیرساخت استقرار تحمیل می‌کند؟

  4. بخش 7 مقاله‌ی گرین‌بلت و همکاران (2024) درباره‌ی تبانی را بخوانید. راهکاری برای مقاوم‌سازی در برابر تبانی پیشنهاد دهید و افت کاراییِ موردانتظار ناشی از آن را تبیین کنید.

  5. یک کیس ایمنی کنترل برای سناریویی بنویسید که در آن U در رده‌ی GPT-4، مدل T در رده‌ی GPT-3.5، و بودجه‌ی H برابر با بازرسی 1% خروجی‌ها است. قوی‌ترین فرضی را که کل این استدلال بر پایه‌ی آن ایستاده است مشخص کنید.

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

اصطلاح در بیان عامه معنای دقیق فنی
کنترل هوش مصنوعی (AI Control) «ایمنی در برابر خرابکاری» طراحی پروتکلی که احتمال وقوع پیامدهای غیرقابل‌قبول را تحت بدترین حالت رفتار U محدود می‌سازد
مدل غیرقابل‌اعتماد (U) «مدل قوی» مدلی توانمند که می‌خواهیم از آن کار بکشیم اما به آن اعتمادی نداریم
مدل قابل‌اعتماد (T) «مدل ضعیف» مدلی ضعیف‌تر که مطمئنیم خصمانه نیست و به‌عنوان ویرایشگر یا ناظر خدمت می‌کند
انسان قابل‌اعتماد (H) «بودجه‌ی بازرسی» نیروی انسانی متخصص و محدود؛ گران‌قیمت؛ سیگنال قطعی مرجع حقیقت
ویرایش قابل‌اعتماد (Trusted Editing) «T خروجی U را ویرایش می‌کند» پروتکلی که در آن T مدخل خروجی‌های U است؛ در موارد مبهم به H ارجاع داده می‌شود
نظارت غیرقابل‌اعتماد (Untrusted Monitoring) «U بر U نظارت می‌کند» پروتکلی که در آن نسخه‌ی دیگری از U خروجی‌ها را می‌سنجد؛ مقاوم‌سازی آن در برابر تبانی نیازمند صرف منابع اضافه است
کیس ایمنی کنترل (Control safety case) «استدلال صوری» استدلالی مکتوب مبنی بر اینکه پروتکل، نرخ موفقیت مهاجم را حتی در بدترین رفتارهای احتمالی U مهار می‌کند

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

خودآزمایی

به سؤال‌ها جواب بدهید تا ببینید چقدر از درس در ذهنتان مانده است.

  1. پیش از درسکدام گزینه تفاوت بین هم‌ترازی (Alignment) و کنترل هوش مصنوعی (AI Control) را به بهترین شکل بیان می‌کند؟
  2. حین درسمدل تهدید در کنترل هوش مصنوعی چه فرضیاتی دارد؟
  3. حین درسریسک کلیدی در پایش غیرمعتمد (Untrusted Monitoring) که ویرایش معتمد (Trusted Editing) از آن جلوگیری می‌کند چیست؟
  4. حین درسدر وظیفه درب‌پشتی کد مقاله گرینبلات و همکاران (ICML 2024)، روش ویرایش معتمد نسبت به پایش غیرمعتمد چه دستاوردی دارد؟
  5. پس از درسکدام‌یک از موارد زیر جزو سه محدودیت بنیادین کنترل که در درس مطرح شد نیست؟
  6. پس از درسیک پرونده ایمنی کنترل (Control Safety Case) چه چیزی را استدلال می‌کند؟

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

تفاوت هم‌راستاسازی (Alignment) و کنترل هوش مصنوعی (AI Control) چیست؟

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

چرا ویرایش قابل‌اعتماد (Trusted Editing) از نظارت غیرقابل‌اعتماد (Untrusted Monitoring) بهتر است؟

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

محدودیت‌های بنیادین رویکرد AI Control چیست؟

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

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

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