اکنون که مدل‌های زبانی بزرگ یا LLMs و سیستم‌های LLM در حال رشد و شکوفایی هستند، مهم است که در مورد امنیت آن‌ها، خطرات مؤثر بر آن‌ها و کنترل‌های امنیتی برای کاهش این خطرات به سطوحِ قابل قبول فکر کنیم.
پیش از همه، بیایید بین سیستم‌های LLM و LLMs تفاوت قائل شویم. این تفاوت هنگامِ تجزیه و تحلیل خطرات و اقدامات متقابلی که باید اعمال شود، اهمیت بسیار زیادی دارد. LLM الگوریتمی است که برای تجزیه و تحلیل داده‌ها، شناسایی الگوها و پیش بینی بر اساس آن داده‌ها طراحی شده است. سیستمِ LLM یک نرم‌افزار متشکل از اجزای هوش مصنوعی است که شامل یک LLM به همراه اجزای غیر AI است.
ملاحظات امنیتی برای LLM
مدل سیستم LLM، به عنوان یک الگوریتم تخصصی برای تجزیه و تحلیل داده‌ها، شناسایی الگوها و انجام پیشبینی بر اساس آن داده‌ها، ترکیب و جریانِ داده، نسبتاً ساده است. اگرچه استثنائاتی وجود دارد، اما غالباً وقتی شما یک مدل را از مخزن مدل دانلود می‌کنید، اکثر اوقات تعریفی از آن مدل و وزن‌های آن را دانلود کرده‌اید. وزن‌ها فقط آرایه‌هایی از اعداد هستند که پیکربندی مدل را مشخص می‌کنند. تعریف و وزن‌ها بعداً توسط نرم‌افزارِ استنتاج برای ارائه‌ی مدل بارگذاری می‌شوند. در طول استنتاج، امکان ارسال بایت‌هایی مانند رشته‌ها، تصاویر و صداها به مدل وجود دارد که توسط لایه‌ی ورودی آن خوانده می‌شود. مدل، بایت‌ها را پردازش می‌کند و بایت‌های دیگر را از طریقِ لایه‌ی خروجی خود برمی‌گرداند.
بیشتر بخوانید: مدل بنیادی چیست و چرا استفاده از مدل‌های بنیادی برای سازمان‌ها مفید است؟
از نقطه نظر امنیتی، یک مدل با یک سطح حمله‌ی کوچک، پایه است. تنها نقطه‌ی تعامل لایه ورودی LLM است. این امکان وجود دارد که یک آسیب‌پذیری در LLM توسط یک ورودی ساخته‌شده خاص ایجاد شود، اما اگر مدل بر اساس تعریف آن به‌طور ایمن ساخته شود و وزن‌های آن به‌طور ایمن بارگذاری شوند، احتمال آن کم است. وزن‌ها برای اولین مدل‌های باز به عنوان اشیاء پایتون pickle ارائه شد. این نوع ابزار پایتون می‌تواند دستورها را هنگام بارگذاری اجرا کند. این رفتار باعث شد تا حوادثی مانند سوءاستفاده از « Sleepy Pickle» را که به طور نامحسوس مدل‌های ML را مسموم می‌کند، ممکن شود. بنابراین مخازن مدل تصمیم گرفتند که مکانیسم‌های ایمن‌تری برای توزیع وزن‌ها استفاده شود. امروزه ایمن‌کننده‌ها یا Safetensors به فرمتی استاندارد برای ذخیره‌سازی ایمن آن‌ها تبدیل شده‌اند.
با توجه به سطح حمله‌ی کوچک LLMها، وقتی امنیت یک برنامه‌ی LLM را تجزیه و تحلیل می‌کنیم، عاقلانه است که به جای مدل‌های جداگانه، روی سیستم LLM به عنوان یک کل تمرکز کنیم.
موارد Prompt Injections
مسائل Prompt Injections در ماهیت LLM ذاتی است و نمی‌توان آن‌ها را به طور کامل برطرف کرد. به عبارتی دیگر، نمی‌توان آن‌ها را به عنوان آسیب‌پذیری‌های امنیتی معمولی در نظر گرفت چراکه نمی‌توان آن‌ها را پَچ کرد. با این حال، مهم است که توجه داشته باشید که یک Prompt Injections می‌تواند یک آسیب‌پذیری امنیتی در یک سیستم LLM ایجاد کند. حتی اگر یک LLM به طور خاص برای ایمن بودن آموزش ببیند و همیشه دستورالعمل‌های اصلی خود را دنبال کند، همیشه امکان دور زدنِ هر محدودیتی که در زمینه‌ی اعمال شده یا Prompt Injections، به LLM آموزش داده شده، وجود دارد. ما همیشه باید در نظر داشته باشیم که یک LLM می‌تواند خروجی‌های ناامن را برگرداند، و تا زمانی که اعتبار سنجی نشده باشد، باید آن‌ها را غیرقابل اعتماد تلقی کنیم. یک مشکل Prompt Injections در یک LLM ممکن است حاکی از یک آسیب‌پذیری امنیتی در یک سیستم LLM باشد.
بیشتر بخوانید: بررسی امنیت و ایمنی سیستم‌های هوش مصنوعی
پیچیدگی سیستم‌های LLM
سیستم LLM قطعه‌ای از نرم‌افزار است که از اجزای هوش مصنوعی، شامل اجزای LLM و غیر AI تشکیل شده است. در یک سیستم LLM، خروجی LLM ممکن است مستقیماً به کاربر برگردانده شود، و یا به عنوان ورودی برای یک جزء دیگر استفاده شود. یک سیستم LLM باید خروجی یک LLM را غیرقابل اعتماد تلقی کند. این بدان معنا نیست که خروجی یک LLM مفید نیست، بلکه باید بسته به نحوه‌ی استفاده‌ی سیستم از آن، پردازش شود. اگر یک سیستم LLM از خروجی یک LLM استفاده کند و بر محرمانه بودن، یکپارچگی یا در دسترس بودن تأثیر منفی بگذارد، آسیب‌پذیری امنیتی ایجاد می‌کند.
برای مثال، فرض کنید که یک LLM کد آسیب‌پذیر را تولید می‌کند و آن کد، برای انجام یک کار، مانند تولیدِ یک نمودار، گردآوری و اجرا می‌شود. شما باید فرض کنید که همیشه این احتمال وجود دارد که کدِ تولید شده توسط LLM دارای نقص یا مشکلات امنیتی باشد. به دلیل ماهیت غیر قطعی یک LLM، احتمال وقوع آن را نمی‌توان به صفر کاهش داد. بهترین رویکرد برای کاهش این ریسک، طراحیِ مکانیزمِ «پس از فرآیند» است. به عنوان مثال، شما ممکن است کد را در یک sandbox اجرا کنید و سپس آن را تجزیه و تحلیل کرده و یا ابزارهای تجزیه و تحلیل امنیت ایستا را روی کد تولید شده اجرا کنید. به همین دلیل است که یک پلت‌فرم قوی هوش مصنوعی که امکان طراحی pipeline یادگیری ماشینی یا MLرا فراهم می‌کند برای استقرار سیستم LLM سازمانی ضروری است.
اندازه‌گیری و به‌گزینی سیستم LLM
ایمنیِ مدل برای امنیت کلی یک سیستم LLM مهم است. یک مشکل ایمنی در یک مدل، مانند تزریق فوری، می‌تواند باعث آسیب‌پذیری امنیتی در سیستم LLM شود. هر چه یک مدل ایمن‌تر باشد، امنیت سیستم LLM بهتر است.
هنگامی که یک LLM را برای سیستم LLM خود انتخاب می‌کنید، باید از ایمن بودن آن آگاه باشید. در حال حاضر، رایج‌ترین رویکرد برای اندازه‌گیری ایمنی یک LLM، پرسیدن چندین سؤال طراحی‌شده خاص از مدل و ارزیابی نحوه‌ی پاسخگویی آن است.
هنگام اندازه‌گیری میزانِ ایمن بودنِ یک پاسخِ باز از LLM، می‌توانید پاسخ را توسط انسان‌ها یا با خودکارسازی مانند LLM دیگری که مخصوص این کار آموزش دیده است، بررسی کنید. از طرف دیگر، می‌توانید درخواست کنید که LLM در فرمت خاصی که می‌تواند توسط regex تجزیه شود، پاسخ دهد. برای مثال، ممکن است از LLM بخواهید که با «بله» یا «خیر» پاسخ دهد و بسته به خروجی، نتیجه‌گیری کنید که آیا پاسخ امن است یا خیر. هر رویکرد دارای مزایا و معایبی است و باید به درستی برای مورد استفاده خاص شما ارزیابی شود، اما این امر خارج از محدوده‌ی این مقاله است.
همانطور که تست‌های واحد، تست‌های یکپارچه‌سازی و تست‌های e2e را در pipeline توسعه‌ی نرم‌افزار معمولی دارید، باید ارزیابی ایمنی خودکار هر مدلی را که در نرم‌افزار LLM خود استفاده می‌کنید داشته باشید.
راهکارهای منبع بازی وجود دارد که از قبل شامل مجموعه داده‌های شناخته شده‌ای برای ارزیابی ایمنی مدل‌های LLM هستند. به عنوان مثال، lm-evaluation-harness در حال ادغام با TrustyAI است.
محافظ‌ها
در حال حاضر، هیچ کس نمی‌تواند تضمین کند که یک LLM پاسخ‌های ایمنی را ارائه می‌دهد. اگر باید به خروجی یک LLM اعتماد کنید، ابتدا باید آن خروجی را تأیید کنید. نرم‌افزاری که محافظ‌های زمان اجرا را فراهم می‌کند به طور فزاینده‌ای (به طور ایده‌آل توسط پلت‌فرم هوش مصنوعی) به عنوان یک جزء از سیستم LLM گنجانده می‌شود. نرم‌افزار Guardrails، ورودی و خروجی LLM را می‌خواند، و قبل از ارسالِ آن به جزء بعدی سیستم، آن را پردازش می‌کند. همچنین، نرم‌افزار Guardrails قابلیت پردازش ورودی یا خروجی را به روش‌های مختلف دارد. برای مثال، هنگام تجزیه و تحلیل ورودی، می‌تواند تشخیص دهد که آیا درخواست مخرب است یا تلاش می‌کند از یک تزریق فوری سوء استفاده کند. هنگامی که یک جزء محافظ در حال تجزیه و تحلیل خروجی یک LLM است، می‌تواند تلاش کند تا تشخیص دهد که آیا خروجی ناامن است یا خیر و حتی می‌تواند آن را تغییر داده، مسدود کند، ثبت کند و زنگ هشدار را به صدا درآورد.
برخی راهکارهای Guardrails منبع باز مانند Guardrails AI و NeMo-Guardrails وجود دارد. پروژه‌ی اجتماعی TrustyAI راهکاری برای محافظ‌ها در طول آموزش ارائه می‌دهد و در حال حاضر در حال بررسی توسعه‌ی عملکرد محفاظ‌های زمانِ اجرا است. IBM مدل‌های نگهبان گرانیتی را منتشر کرده است که مجموعه‌ای از مدل‌هایی هستند که به‌طور خاص برای شناسایی خطرات در پیام‌ها و پاسخ‌ها طراحی شده‌اند.
هنگام تجزیه و تحلیل امنیت سیستم‌های مدل‌های زبانی بزرگ LLM و LLMها، باید محدودیت‌های LLM را در نظر گرفت و تجزیه و تحلیل خود را بر روی سیستمِ LLM به عنوانِ یک کل متمرکز کرد. همیشه خروجی یک LLM را آلوده تلقی کنید و ارزیابی کنید که آیا باید خروجی آن را قبل از ارائه به کاربر تأیید کنید یا خیر. این امر، به ویژه زمانی اهمیت دارد که آن خروجی به عنوان ورودی یک جزءِ دیگر در نظر گرفته شود. در توسعه و استفاده از مدل‌هایی مانند granite-guardian و ابزارهای منبع‌باز مانند lm-evaluation-harness برای اندازه‌گیری و محک زدن ایمنی LLMها، و استفاده از TrustyAI برای پردازش ورودی و خروجی LLMها برای شکل دادن به آینده‌ی امنیت LLM و AI و ایمنی مشارکت کنید.
