در کار با مدلهای زبانی پیشرفته، همواره این دغدغه وجود دارد که اگر یک مدل قدرتمند رفتارهای فریبکارانه داشته باشد یا در کدهای تولیدی دربپشتی (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 است که گاهی به رد کردن بیمورد کدها یا ندیدن دربپشتیهای ظریف میانجامد.
چهار محور پروتکلها
- نقش U در سیستم: فقط تولیدکننده، ناظر، یا هر دو.
- نقش T در سیستم: ویرایشگر، ناظر، یا نمونهگیر مجدد.
- نحوهی تخصیص H: بازرسی یکنواخت، بازرسی تصادفی، یا بازرسی با هدایت پرچمها.
- میزان توان محاسباتی که پروتکل برای مقاومسازی در برابر تبانی هزینه میکند.
همراستاسازی در برابر کنترل
- همراستاسازی: «آیا میتوان به 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 با نظارت مقیاسپذیر).
پیادهسازی عملی
اسکریپت code/main.py چهار پروتکل بالا را روی یک وظیفهی سادهشدهی دربپشتی شبیهسازی میکند. مدل U خروجیها را تولید میکند که بخشی از آنها (طبق سیاست تیم قرمز) آلوده به دربپشتی هستند. مدل T خروجی را تأیید یا ویرایش میکند. انسان (H) نیز تا سقف بودجه فراخوانی میشود. میتوانید بودجه و پارامتر تبانی را تغییر دهید تا مرز پارتو در شکل 2 مقالهی گرینبلت و همکاران (2024) بازتولید شود (فرم کلی نمودار، نه ارقام دقیق).
خروجی کار
این درس فایل outputs/skill-control-protocol-audit.md را تولید میکند. این گزارش با گرفتن شرح یک پروتکل استقرار، نقشهای U ،T و H را معین میکند، مسیرهای تبانی را برمیشمارد، و جایگاه پروتکل را روی مرز کارایی-ایمنی زیر فشار تیم قرمز برآورد میکند.
تمرینها
-
اسکریپت
code/main.pyرا اجرا کنید. مرز کارایی-ایمنی را برای مقایسهی «ویرایش قابلاعتماد» و «نظارت غیرقابلاعتماد» بازتولید کنید. بازهی بودجهای را بیابید که در آن، فرضِ تبانی در نظارت غیرقابلاعتماد نقشی سرنوشتساز پیدا میکند. -
پروتکل جدیدی اضافه کنید: «T با دمای (temperature) پایین دوباره نمونهگیری کند، سپس U خروجی T را ویرایش کند.» جایگاه آن را روی مرز پارتو بسنجید. چرا شکست این روش به مراتب فاجعهبارتر از ویرایش قابلاعتماد خواهد بود؟
-
مقالهی سال 2024 فرض میکند U به سازوکار پروتکل اشراف دارد. پروتکلی طراحی کنید که مشخص نباشد کدام خروجیها دارند بازرسی میشوند. چنین پروتکلی چه نیازمندیهایی را به زیرساخت استقرار تحمیل میکند؟
-
بخش 7 مقالهی گرینبلت و همکاران (2024) دربارهی تبانی را بخوانید. راهکاری برای مقاومسازی در برابر تبانی پیشنهاد دهید و افت کاراییِ موردانتظار ناشی از آن را تبیین کنید.
-
یک کیس ایمنی کنترل برای سناریویی بنویسید که در آن 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 مهار میکند |
برای مطالعهی بیشتر
- گرینبلت، شلگریس، ساچان، راجر — AI Control (arXiv:2312.06942) — مقالهی پایهای در ICML 2024
- Redwood Research — نمایهی مقالات اخیر AI Control — پژوهشهای مکمل در سالهای 2024 و 2025
- UK AISI + METR — کیسهای ایمنی کنترل — پیادهسازی عملیاتی برای آزمایشگاههای پیشرو
- هوبینگر و همکاران — Sleeper Agents (درس 7، arXiv:2401.05566) — همان مدل تهدیدی که رویکرد کنترل بر پایهی آن بنا شده است
