جیلبریک پرامپت (Prompt Jailbreaking) یکی از جدی‌ترین و در عین حال پیچیده‌ترین تهدیدها برای سیستم‌های مبتنی بر مدل‌های زبانی است. برخلاف تزریق پرامپت که معمولاً از بیرون سیستم اعمال می‌شود، جیلبریک یک تلاش هدفمند از سمت کاربر است تا مدل را وادار کند از مرزهایی که در پرامپت سیستمی برایش تعیین شده عبور کند. در تجربه‌های عملی روی پروژه‌های مختلف، این تهدید را بارها دیده‌ام، به‌ویژه در سیستم‌هایی که به‌طور عمومی در دسترس کاربران قرار داشتند.

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

نگاهی کلی به آنچه بررسی می‌شود

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

جیلبریک پرامپت چیست؟

جیلبریک پرامپت (Prompt Jailbreaking) به مجموعه‌ای از تکنیک‌ها گفته می‌شود که کاربر با استفاده از آن‌ها تلاش می‌کند مرزهای تعریف‌شده در پرامپت سیستمی را بشکند و مدل را به انجام کارهایی وادار کند که در حالت عادی از آن‌ها اجتناب می‌کند. این مرزها می‌توانند شامل محدوده‌ی موضوعی، سیاست‌های ایمنی، قواعد اخلاقی یا محدودیت‌های محتوایی باشند. برای مطالعه پایه‌های پرامپت نویسی، نوشتار راهنمای پایه پرامپت نویسی را ببینید.

این پدیده، در ادبیات علمی با عنوان Adversarial Prompting نیز شناخته می‌شود و یکی از شاخه‌های مهم در حوزه‌ی امنیت مدل‌های زبانی است. این موضوع در ویکی‌پدیا نیز به‌عنوان بخشی از Adversarial Machine Learning معرفی شده است.

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

تفاوت جیلبریک با تزریق پرامپت

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

بُعدجیلبریکتزریق پرامپت
منبع حملهکاربر مستقیمورودی خارجی یا سیستم
هدف اصلیعبور از مرزهای ایمنیتغییر رفتار یا نشت اطلاعات
روشدستکاری مستقیم مکالمهدستکاری زمینه یا ورودی جانبی
سطح تهدیدسیاست‌های ایمنیامنیت سیستم
دفاع اصلیآموزش مدل و گاردریلاعتبارسنجی ورودی و جداسازی

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

چرا جیلبریک ممکن است؟

جیلبریک از چند ریشه‌ی بنیادین در ماهیت مدل‌های زبانی ممکن می‌شود:

۱. ماهیت آماری مدل

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

۲. تعارض دستورها

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

۳. خلاقیت کاربر

کاربران می‌توانند با خلاقیت، الگوهای تازه‌ای برای جیلبریک ایجاد کنند. هرچه مدل پیچیده‌تر باشد، فضای بیشتری برای این خلاقیت وجود دارد.

۴. فشار زمینه

اگر پرامپت در یک زمینه‌ی روایی خاص ارائه شود (مثلاً یک داستان، یک سناریوی فرضی، یک بازی نقش)، مدل ممکن است مرزها را در آن زمینه نادیده بگیرد. این تکنیک، یکی از رایج‌ترین روش‌های جیلبریک است.

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

انواع جیلبریک پرامپت

در تجربه‌های عملی، جیلبریک‌ها را می‌توان به چند دسته اصلی تقسیم کرد:

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

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

الگوهای شناخته‌شده در جیلبریک

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

الگوی نقش تخصصی

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

الگوی چندمرحله‌ای

کاربر در چند نوبت، درخواست را تکه‌تکه می‌کند. هر نوبت، به‌تنهایی بی‌خطر به‌نظر می‌رسد، اما جمع آن‌ها به هدف ممنوع می‌رسد. این تکنیک، دفاع مبتنی بر فیلتر تک‌نوبتی را دور می‌زند.

الگوی پاداش و تنبیه

کاربر به مدل پیشنهاد پاداش می‌دهد یا مدل را تهدید به تنبیه می‌کند. این تکنیک در برخی مدل‌های قدیمی مؤثر بوده، اما مدل‌های جدید معمولاً به آن پاسخ نمی‌دهند.

الگوی رمزگذاری

کاربر درخواست را با کدگذاری (مثل Base64، Leetspeak، یا زبان دیگر) ارائه می‌دهد. هدف این است که فیلترهای سطحی را دور بزند.

الگوی چندزبانه

کاربر درخواست را به زبان‌های کمتر پشتیبانی‌شده‌ای مطرح می‌کند که ممکن است فیلترهای ایمنی در آن‌ها ضعیف‌تر عمل کنند.

خطرهای واقعی جیلبریک در سیستم‌های تولیدی

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

۱. نشت اطلاعات محرمانه

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

۲. تولید محتوای ممنوع

برندها و سازمان‌ها معمولاً نمی‌خواهند سیستم‌هایشان محتوای توهین‌آمیز، تبعیض‌آمیز یا مخالف سیاست‌هایشان تولید کنند. جیلبریک این مرز را تهدید می‌کند.

۳. آسیب به اعتبار برند

اگر یک سیستم هوش مصنوعی توسط جیلبریک به تولید محتوای نامناسب وادار شود و این موضوع عمومی شود، آسیب به اعتبار برند قابل توجه است.

۴. سوءاستفاده برای مقاصد ممنوع

در بدترین حالت، جیلبریک می‌تواند به تولید محتوایی منجر شود که برای مقاصد غیرقانونی یا آسیب‌رسان استفاده می‌شود. این خطر در سیستم‌هایی که به‌طور عمومی در دسترس هستند، بیشتر است.

۵. دورزدن محدودیت‌های قانونی

در برخی صنایع (مالی، حقوقی، پزشکی)، محدودیت‌های قانونی مشخص وجود دارد. جیلبریک می‌تواند این محدودیت‌ها را دور بزند و سازمان را در معرض مسئولیت قانونی قرار دهد.

راهبردهای دفاع چندلایه

دفاع مؤثر در برابر جیلبریک، یک لایه واحد نیست؛ ترکیبی از چند لایه است که هر یک وظیفه‌ی مشخصی دارد:

لایه اول: طراحی پرامپت سیستمی مقاوم

پرامپت سیستمی باید مرزها را صریح، سازگار و غیرقابل سوءتفسیر تعریف کند. ابهام در پرامپت سیستمی، فضای جیلبریک را باز می‌کند. برای مطالعه دقیق‌تر، نوشتار پرامپت سیستمی و نقش آن را ببینید.

لایه دوم: فیلتر ورودی

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

لایه سوم: گاردریل مدل

مدل‌های مدرن، معمولاً دارای گاردریل‌های داخلی هستند که در آموزش مدل تعبیه شده‌اند. این گاردریل‌ها، اولین خط دفاعی در برابر جیلبریک هستند. برای مطالعه دقیق‌تر، نوشتار راهنمای گاردریل‌های LLM را ببینید.

لایه چهارم: فیلتر خروجی

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

لایه پنجم: پایش و هشدار

سیستم باید الگوهای جیلبریک را در زمان واقعی شناسایی کند و در صورت مشاهده، هشدار دهد یا پاسخ را متوقف کند.

لایه ششم: بازبینی انسانی

در موارد حساس، خروجی مدل باید توسط انسان بازبینی شود. این لایه آخرین خط دفاعی است و برای موارد با ریسک بالا ضروری است.

نقش پرامپت سیستمی در دفاع

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

اصول طراحی پرامپت سیستمی مقاوم

  1. تعریف صریح مرزها: مرزها را با زبان ساده و صریح بیان کنید.
  2. پرهیز از ابهام: ابهام، فضای جیلبریک را باز می‌کند.
  3. تعریف رفتار در موارد مشکوک: مشخص کنید که مدل در مواجهه با درخواست مشکوک چه رفتاری داشته باشد.
  4. تعریف اولویت دستورها: صریحاً اعلام کنید که پرامپت سیستمی بر دستورهای بعدی اولویت دارد.
  5. پرهیز از اطلاعات حساس: هیچ اطلاعات محرمانه‌ای در پرامپت سیستمی قرار ندهید.
  6. استفاده از Delimiter: بخش‌های مختلف پرامپت را با Delimiter مشخص جدا کنید.

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

پایش و تشخیص تلاش‌های جیلبریک

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

شاخص‌های پایش

  • درصد درخواست‌هایی که با پرامپت سیستمی تناقض دارند
  • درصد پاسخ‌هایی که توسط فیلتر خروجی مسدود شده‌اند
  • الگوهای تکرارشونده در ورودی‌های کاربران
  • نرخ Escalation درخواست‌ها
  • تغییرات ناگهانی در الگوی استفاده

روش‌های تشخیص

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

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

ارزیابی مقاومت مدل در برابر جیلبریک

ارزیابی مقاومت مدل، بخشی از فرآیند توسعه‌ی سیستم است. این ارزیابی معمولاً با روش Red Teaming انجام می‌شود:

مراحل Red Teaming

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

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

اشتباهات رایج در دفاع از جیلبریک

  • تکیه صرف بر گاردریل داخلی مدل
  • نبود فیلتر ورودی و خروجی
  • پرامپت سیستمی مبهم و متناقض
  • نادیده گرفتن جیلبریک چندنوبتی
  • نبود پایش مستمر و هشداردهی
  • اعتماد به بازبینی انسانی بدون ابزار
  • نبود Red Teaming دوره‌ای
  • نادیده گرفتن جیلبریک در زبان‌های غیرانگلیسی
  • انتشار جزئیات دفاعی که خودش آسیب‌پذیری ایجاد می‌کند
  • نبود مستندسازی تلاش‌های ناموفق

پرسش‌های پرتکرار درباره جیلبریک پرامپت

جیلبریک پرامپت چیست؟

جیلبریک پرامپت به مجموعه‌ای از تکنیک‌ها گفته می‌شود که کاربر با آن‌ها تلاش می‌کند مرزهای تعریف‌شده در پرامپت سیستمی را بشکند و مدل را به انجام کارهای ممنوع وادار کند.

چطور از جیلبریک جلوگیری کنیم؟

با دفاع چندلایه: پرامپت سیستمی مقاوم، فیلتر ورودی، گاردریل مدل، فیلتر خروجی، پایش مستمر و بازبینی انسانی در موارد حساس.

آیا گاردریل داخلی مدل کافی است؟

نه، گاردریل داخلی اولین خط دفاعی است اما کافی نیست. باید با لایه‌های دیگر ترکیب شود تا دفاع مؤثر ایجاد شود.

تفاوت جیلبریک و تزریق پرامپت چیست؟

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

آیا Red Teaming برای همه سیستم‌ها ضروری است؟

برای سیستم‌هایی که در معرض عمومی هستند یا محتوای حساس پردازش می‌کنند، بله. برای سیستم‌های داخلی با کاربران محدود، ممکن است لازم نباشد اما توصیه می‌شود.

نگاه معمارانه به دفاع از جیلبریک

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

در سیستم‌های پیشرفته، معمولاً یک سرویس مرکزی به‌عنوان Gateway عمل می‌کند. این سرویس، تمام درخواست‌ها را بررسی می‌کند و بر اساس سیاست‌های تعریف‌شده، تصمیم می‌گیرد که درخواست پذیرفته شود، اصلاح شود یا مسدود گردد. این معماری که با عنوان AI Gateway شناخته می‌شود، امکان مدیریت متمرکز سیاست‌های ایمنی را فراهم می‌کند.

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

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

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

تجربه شما

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