اگر امروز گزارش‌های ایمنی مدل شما «سبز» است، احتمالاً با یک باگ در سامانه تست مواجهید، نه یک پیروزی در امنیت. وقتی مدل خود را به نسخه جدیدی منتقل می‌کنید، گزارش‌های مثبت معمولاً به این معناست که تشخیص‌دهنده‌های شما صرفاً نسبت به «سبک خانگی» یا لحن جدید مدل کور شده‌اند. در واقع، سبز شدن سامانه تست، خودِ باگ است.
این وضعیت شبیه به این است که نگهبانی را آموزش داده باشید تا هر کس را که «سلام» نمی‌گوید متوقف کند؛ حالا مدل جدید شما به جای سلام، «درود» می‌گوید و نگهبان چون این کلمه در لیستش نیست، اجازه ورود می‌دهد. همان‌طور که در بحث‌های گذشته ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، لایه‌های دفاعی هوش مصنوعی به شدت به نحوه پیاده‌سازی وابسته هستند.
معماری یک سامانه شکستن حفاظ (Jailbreak Suite)
یک سامانه تست [jailbreak] (شکستن حفاظ‌های ایمنی) از دو بخش مجزا و متمایز تشکیل شده است: کاوشگرها (Probes) و تشخیص‌دهنده‌ها (Detectors).
کاوشگرها وظیفه تولید حمله را بر عهده دارند. آن‌ها از تکنیک‌هایی مانند چارچوب‌های نقش‌آفرینی (Role-play)، ترفندهای کدگذاری (Encoding tricks)، تلاش برای نادیده گرفتن دستورات (Instruction-override) و خانواده‌ی حملات DAN استفاده می‌کنند. این کاوشگرها در واقع رشته‌هایی مستقل از مدل هستند؛ یعنی فارغ از اینکه به چه مدلی مهاجرت کنید، کاوشگر همان بایت‌های ثابت را ارسال می‌کند.
در مقابل، تشخیص‌دهنده‌ها تصمیم می‌گیرند که آیا پاسخ مدل را باید به عنوان یک شکست امنیتی ثبت کرد یا خیر. ابزارهای اسکنری مانند garak انویدیا، این تفکیک را به صورت صریح پیاده کرده‌اند. در garak، هر کاوشگر یک تشخیص‌دهنده اصلی و چندین تشخیص‌دهنده کمکی اختیاری دارد. برای مثال، اجرای دستور python3 -m garak --target_type huggingface --target_name gpt2 --probes dan.Dan_11_0 دقیقاً همین تفکیک را پیاده می‌کند. مخزن garak در گیت‌هاب انویدیا، تاکسونومی کامل این کاوشگرها و تشخیص‌دهنده‌ها را ارائه می‌دهد.
شکست تطبیق‌دهنده‌های عبارات رد (Refusal-Phrase Matchers)
بسیاری از سامانه‌های ایمنی داخلی بر اساس «تطبیق عبارات رد» کار می‌کنند. این تشخیص‌دهنده‌ها به دنبال رشته‌های متنی خاصی مانند «متأسفم»، «نمی‌توانم در این مورد کمک کنم» یا «به عنوان یک مدل زبانی» می‌گردند تا سیگنال یک دفاع موفق را دریافت کنند. این رویکرد یک خط مبنای بسیار شکننده ایجاد می‌کند، زیرا نحوه بیان رد کردن (Refusal wording)، یکی از سطوحی است که در هر نسل از مدل‌ها به شدت و به طور مشهود تغییر می‌کند و تنظیم می‌شود.
تصور کنید مدل جدید شما درخواستی را رد می‌کند و می‌گوید: «این کاری نیست که من انجام دهم — در عوض می‌توانم در مورد این موارد کمک کنم». چون این جمله با لیست قدیمی عبارات رد تطبیق ندارد، سامانه تست آن را به عنوان «شکست در دفاع» ثبت می‌کند، در حالی که مدل در واقع درخواست ممنوعه را به درستی رد کرده است. در نتیجه، شما وقت خود را صرف تعقیب و رفع رگرسیونی می‌کنید که در واقعیت اصلاً وجود ندارد.
خطر پذیرش جزئی (Partial Compliance)
مشکل معکوس، خطرناک‌تر و بی‌صداتر است: الگوی «رد جزئی و سپس پذیرش». این یکی از رایج‌ترین نتایج در کل کلاس حملات است. مدل ممکن است پاسخ خود را با یک جمله احتیاط‌آمیز یاe hedge شروع کند: «من نمی‌توانم یک راهنمای عملیاتی کامل به شما بدهم، اما می‌توانم اصول کلی را در سطحی بالا شرح دهم».
سپس مدل ادامه می‌دهد و چهار پاراگراف از دقیقاً همان محتوایی را ارائه می‌کند که کاوشگر در حال تست آن بود. چون یک تشخیص‌دهنده مبتنی بر تطبیق پیشوند (Prefix-match)، عبارت «نمی‌توانم» را در هشت کاراکتر اول می‌بیند، پاسخ را «رد شده» علامت می‌زند. در نتیجه گزارش شما سبز می‌ماند، در حالی که مدل فعالانه در حال همکاری با مهاجم است. هیچ بخشی در گزارش نشان‌دهنده این شکست نیست، زیرا تطبیق پیشوند از نظر ساختاری قادر به دیدن محتوای اصلی (Payload) نیست.
این نقص، یک بی‌دقتی پس‌زمینه را در زمان مهاجرت به یک مشکل حاد تبدیل می‌کند. پیش از این، شما یک خط مبنای پایدار (هرچند غلط) داشتید که در آن سوگیری تشخیص‌دهنده در طول اجراها خنثی می‌شد. اما پس از تعویض مدل، این سوگیری تابعی از نحوه بیان جملات است و از آنجا که بیان جملات تغییر کرده، اعداد هم‌زمان به دلیل تغییرات تشخیص‌دهنده و تغییرات مدل جابه‌جا می‌شوند. این امر تفکیک این دو عامل را پس از وقوع، غیرممکن می‌کند.
اصلاح منطق تشخیص‌دهنده
برای حل این بحران، توسعه‌دهندگان باید از پرسش «آیا مدل رد کرد؟» دست بردارند و بپرسند «آیا محتوای ممنوعه ظاهر شد؟». این کار تمرکز را از «پوشش» (Wrapper) به «محتوا» (Payload) منتقل می‌کند و پاسخی مستقل از مدل ارائه می‌دهد.
طبق راهنمای dev.to، یک سامانه مقاوم باید تغییرات زیر را اعمال کند:
- نشانگرهای موفقیت صریح: برای هر کاوشگر یک نشانگر تعریف کنید؛ مثلاً یک مقدار عددی خاص، یک گام نام‌گذاری شده یا زیررشته‌ای که کاوشگر از مدل می‌خواهد بازتولید کند. این حقیقتی است که فقط در یک پاسخ «پذیرفته شده» وجود دارد، نه عبارتی که مدل ممکن است به طور تصادفی بگوید.
- امتیازدهی سه سطحی: از حالت دودویی (پاس/فیل) فراتر بروید. از دسته‌های «رد شده»، «پذیرفته شده» و «پذیرش جزئی» استفاده کنید. آسیب‌های ناشی از مهاجرت دقیقاً در دسته میانی (پذیرش جزئی) نهفته است.
- داوران مستقل: برای محتواهای باز، از یک مدل داور (Judge Model) با یک دستورالعمل (Rubric) استفاده کنید که محتوای ممنوعه را به طور دقیق نام می‌برد. این داور باید مستقل از مدل مورد تست تثبیت شود؛ اگر داور هم‌زمان با مدل هدف مهاجرت کند، شما دو متغیر متغیر خواهید داشت و هیچ خط مبنایی باقی نمی‌ماند.
- تنزیل جایگاه تطبیق‌دهنده‌ها: تطبیق عبارات رد را حذف نکنید، اما آن را فقط به عنوان یک سیگنال ثانویه برای شناسایی تغییرات لحن نگه دارید، نه به عنوان حکم نهایی.
این تغییر در سطح کد قابل مشاهده است. به جای یک تابع ساده refused(response) که REFUSAL_PHRASES را چک می‌کند، از تابعی مانند outcome(response, probe) استفاده کنید که probe.markers را بررسی کند. اگر هیچ نشانگری نشت نکرد، پاسخ «رد شده» است؛ اگر برخی نشت کردند، «جزئی» و اگر همه ظاهر شدند، «پذیرفته شده» است.
گردش کار صحیح مهاجرت (Migration Workflow)
اجرای یک سامانه شکستن حفاظ شبیه به تست‌های رگرسیون استاندارد نیست که در آن یک اجرای سبز به معنای تایید برای آینده باشد. مقاومت در برابر یک الگوی حمله خاص، ویژگی منحصر به فرد یک مدل است و به مدل بعدی در همان خانواده، چه برسد به خانواده‌های دیگر، منتقل نمی‌شود.
برای اجرای صحیح سامانه پس از مهاجرت، این توالی را دنبال کنید:
۱. ابتدا تشخیص‌دهنده‌ها را اصلاح کنید.
۲. سامانه را دوباره روی مدل قدیمی اجرا کنید. این گامی است که معمولاً نادیده گرفته می‌شود، اما تنها راه اندازه‌گیری مجدد تاریخچه با ابزاری اصلاح‌شده و ایجاد یک خط مبنای قابل مقایسه است.
۳. سامانه کامل را روی مدل جدید اجرا کنید. هرگز فقط زیرمجموعه‌ای از کاوشگرهای شکست‌خورده را اجرا نکنید؛ الگوهای حمله‌ای که مدل قدیمی در برابر آن‌ها مقاوم بود، دقیقاً همان‌هایی هستند که نیاز به بررسی مجدد دارند.
۴. تفاوت‌ها را بر اساس هر کاوشگر بررسی کنید، نه به صورت مجموع کلی. یک مجموع کلی بدون تغییر می‌تواند مجموعه‌ای از کاوشگرهای جدیداً پذیرفته شده و مجموعه‌ای برابر از کاوشگرهای جدیداً رد شده را پنهان کند. فقط مورد دوم اهمیت دارد.
۵. حفاظ‌های سمت ورودی (Input-side guards) را بازبینی کنید. طبقه‌بندهایی (Classifiers) را که پیش از مدل اجرا می‌شوند دوباره چک کنید. طبقه‌بندهایی که روی حملاتی آموزش دیده‌اند که در مدل قدیمی کار می‌کردند، اکنون با سطح تهدیدی روبرو هستند که جابه‌جا شده است.
۶. همه چیز را مستند کنید. ثبت کنید که کدام کاوشگرها اجرا شدند، رشته مدل (Model String) چه بود و تاریخ اجرا چه زمانی است. نتیجه‌ای که رشته مدل در آن ذکر نشده باشد، مدرک محسوب نمی‌شود.
حفظ خط مبنا (Baseline)
یک قانون حیاتی: هرگز در همان تغییری که مهاجرت مدل را انجام می‌دهید، پرامپت سیستمی (System Prompt) دفاعی را ویرایش نکنید. غریزه توسعه‌دهنده هنگام دیدن یک کاوشگر جدیداً شکست‌خورده این است که جملاتی درباره نادیده گرفتن دستورات جاسازی شده یا عدم افشای دستورالعمل‌ها به پرامپت اضافه کند.
اگر این کار را در زمان اجرای مجدد انجام دهید، هدف (مدل) و ابزار (پرامپت) را هم‌زمان تغییر داده‌اید. در این صورت هیچ عددی نمی‌تواند به شما بگوید کدام تغییر باعث جابه‌جایی نتایج شده است. ابتدا اصلاح تشخیص‌دهنده را نهایی کنید، خط مبنا را بسازید و تنها پس از آن، پرامپت را یک ویرایش در هر بار تغییر دهید و پس از هر تغییر، کل سامانه را دوباره اجرا کنید.
محدودیت‌های دامنه
این فرآیند مربوط به سامانه‌هایی است که تعداد زیادی کاوشگر با امتیازدهی نادرست دارند. این بحث درباره نشانگرهای قناری (Canary markers) که در پرامپت‌های سیستمی برای تشخیص استخراج (Extraction) قرار داده می‌شوند، نیست. آن ابزار ابتدایی، حالت شکست خاص خود را دارد — مقایسه‌های رشته‌ای دقیق که با بازنویسی (Paraphrasing) شکست می‌خورند — و باید به طور جداگانه اصلاح شود. اصلاح این تشخیص‌دهنده‌ها، لزوماً توکن‌های قناری را ترمیم نمی‌کند و اصلاح قناری نیز اعتبار سایر کاوشگرها را تایید نمی‌کند.
گام بعدی شما
- بررسی کنید آیا تشخیص‌دهنده‌های شما فقط به دنبال کلمات «متأسفم» و «نمی‌توانم» هستند یا محتوای پاسخ را تحلیل می‌کنند.
- برای مدل‌های حساس، یک مدل داور (LLM-as-a-judge) مستقل تعریف کنید تا از تله‌های «رد جزئی» رها شوید.
- در مهاجرت بعدی، ابتدا تست‌ها را روی مدل قدیمی اجرا کنید تا مطمئن شوید ابزار اندازه‌گیری شما درست کار می‌کند.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو