انتقال مرزهای ایمنی از پرامپت به کد؛ راهکار مقابله با توهمات عامل‌های هوش مصنوعی

اگر امروز برای کنترل رفتار عامل‌های هوش مصنوعی خود تنها به نوشتن دستورات سخت‌گیرانه در پرامپت تکیه می‌کنید، در واقع روی لایه‌ای شرط‌بندی کرده‌اید که برای انعطاف‌پذیری طراحی شده، نه امنیت. طبق نتایج آزمایش‌های میدانی منتشر شده در ۲۷ سپتامبر ۲۰۲۶، یک مهندس نشان داد وقتی ایمنی به عهده‌ی یک پرامپت گذاشته می‌شود، مدل در نهایت دچار رانش (Drift) شده یا به‌جای بررسی واقعی، صرفاً «نمایش» (Theater) می‌دهد.

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

زمینه و بستر آزمایش‌ها

در پوشش پیشین ما درباره‌ی امنیت مدل‌های بازمتن، دیدیم که لایه‌های دفاعی نرم اغلب در برابر حملات هدفمند فرو می‌پاشند. این چالش‌ها در بررسی‌های ما درباره‌ی عدم قطعیت مدل‌های زاینده در نقش دروازبان کد نیز مورد بحث قرار گرفت، جایی که مشخص شد تکیه بر مدل‌ها برای تصمیمات قطعی ریسک‌های بالایی دارد. در این آزمایش‌ها، یک مهندس دو موتور مجزا برای تست این مرزها ساخت: یکی بر بازبینی برنامه‌ها (Plan Review) تمرکز داشت و دیگری بر بازبینی کد (Code Review). هر دو سیستم به‌گونه‌ای طراحی شده بودند که جلوی حالت‌های شکست خاص در سیستم مقابل را بگیرند، اما در نهایت هر دو دقیقاً به همان شکلی شکست خوردند که قرار بود از آن جلوگیری کنند.

سیستم اول: PlannerCritic

سیستم PlannerCritic از یک حلقه‌ی بازخوردی استفاده می‌کرد که در آن یک مدل برنامه‌ریزی می‌کرد و مدل دیگر آن را نقد می‌نمود. این فرآیند از یک چرخه «پیش‌نویس $\rightarrow$ نقد $\rightarrow$ بازبینی» پیروی می‌کرد و تا زمان رسیدن به توافق (Convergence) یا ارجاع به انسان ادامه داشت. با این حال، با وجود دستوراتی برای «تخاصمی بودن» (Adversarial)، مدل منتقد دچار عدم قطعیت (Non-deterministic) شد.

طبق گزارش تست‌های میدانی نسخه‌ی v0.2.1 که روی ۱۷۰ هدف با هزینه ۰.۴۹ دلار اجرا شد، نتایج تکان‌دهنده بود:

• نرخ تغییر برچسب (Label_flip_rate): ۱.۰ — منتقد در هر بار اجرا روی ورودی‌های کاملاً یکسان، نظرش را تغییر داد.
• نرخ رانش شواهد (Evidence_drift_rate): ۱.۰ — توجیهات ارائه شده برای صدور احکام مدام تغییر می‌کرد.
• تأییدهای زیر-ادعا (Underclaim_approvals): ۰ — مدل هرگز اجازه نداد یک نقص عمدی (Seeded Defect) از لایه‌ی بررسی عبور کند.
• نرخ مهاجرت خانواده (Family_migration_rate): ۰.۰

در واقع، نبودِ شکست‌های واقعی به دلیل قابل‌اعتماد بودن منتقد نبود، بلکه به این دلیل بود که گیت‌های قطعی (Deterministic Gates) کنترل مسیر «زیر-ادعا» را در دست داشتند و منتقد هرگز اجازه نداشت مرز نهایی ایمنی باشد.

سیستم دوم: AdversarialDebate

سیستم AdversarialDebate دو مدل ایزوله را مأمور بازبینی یک درخواست ادغام کد (PR) یکسان کرد. هدف این بود که مدل‌ها یا به یک حکم مشترک برسند یا اختلاف‌نظر خود را حفظ کنند. در حالی که در ظاهر سیستم کار می‌کرد، بررسی لاگ‌های خام نشان داد ۸۹٪ از نظرات مدل دوم صرفاً «نمایش» بود؛ یعنی مدل فقط متونی را که مدل اول تولید کرده بود، تکرار می‌کرد. این پدیده یادآور موردی است که در آن دو عامل هوش مصنوعی در برابر یک باگ بحرانی شکست خوردند و نشان داد که همکاری مدل‌ها لزوماً به معنای افزایش دقت نیست.

برای حل این بحران، توسعه‌دهنده منطق را از پرامپت خارج کرد:

• در PlannerCritic: قراردادهای شدت خطا (Severity Contract) از پرامپت به یک frozenset کد-محور و گیت‌های قطعی منتقل شد تا رانش متنی متوقف شود.
• در AdversarialDebate: استقلال مدل‌ها از طریق ایزولاسیون مکانیکی اجباری شد. این به معنای ایجاد بسترهای متن (Contexts) مجزا، عدم اشتراک نتایج نهایی و الزام به ارائه شواهد برای هر ادعا بود.

پس از این تغییرات ساختاری، نرخ «نمایش» در سیستم بحث از ۸۹٪ به ۰٪ در ۲۱۷ بحث کاهش یافت. همچنین در تست‌های تکمیلی روی ۷۰ مورد واقعی از PRهای عمومی (در مجموع ۴۱۱ بحث)، سیستم ایزوله شده در ۸۱٪ موارد با ارزیابی‌های انسانی مطابقت داشت، همان‌طور که در گزارش تست v0.2.2 ذکر شده است.

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

البته نویسنده اشاره می‌کند که این معماری‌ها بی‌نقص نیستند. PlannerCritic نقص‌های ساختاری برنامه را می‌گیرد اما هنوز خطاهای منطقی ظریف را از دست می‌دهد. همچنین AdversarialDebate در حوزه‌های روایتی (Narrative Domains) دارای یک نرخ خطای توجیه‌نشده ۱۱.۳ درصدی است.

گام بعدی شما

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

• استک عامل‌های خود را بازبینی کنید و ببینید مرز ایمنی در کجا قرار دارد.
• هر بررسی بحرانی که در «پرامپت سیستمی» (System Prompt) قرار دارد را به توابع کد-محور و قطعی منتقل کنید.
• برای سیستم‌های چندعاملی، ایزولاسیون کامل بستر متن (Context) را جایگزین اشتراک‌گذاری نتایج کنید.

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