راهنمایی ایمنی

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

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

هنگام ساخت برنامه های کاربردی با LLM، مراحل زیر توصیه می شود:

  • درک خطرات ایمنی برنامه شما
  • در نظر گرفتن تنظیمات برای کاهش خطرات ایمنی
  • انجام تست ایمنی متناسب با مورد استفاده شما
  • درخواست بازخورد از کاربران و نظارت بر استفاده

مراحل تنظیم و آزمایش باید تکرار شوند تا زمانی که به عملکرد مناسب برای برنامه خود برسید.

چرخه پیاده سازی مدل

خطرات ایمنی برنامه خود را درک کنید

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

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

نکات پیشرفته

  • با ترکیب متنوعی از کاربران بالقوه در جامعه هدف خود در مورد برنامه کاربردی خود و هدف مورد نظر خود صحبت کنید تا دیدگاه گسترده تری در مورد خطرات احتمالی بدست آورید و معیارهای تنوع را در صورت لزوم تنظیم کنید.
  • چارچوب مدیریت ریسک هوش مصنوعی که توسط موسسه ملی استانداردها و فناوری دولت ایالات متحده (NIST) منتشر شده است، راهنمایی های دقیق تر و منابع یادگیری اضافی را برای مدیریت ریسک هوش مصنوعی ارائه می دهد.
  • انتشارات DeepMind در مورد خطرات اخلاقی و اجتماعی آسیب ناشی از مدل‌های زبانی، روش‌هایی را که کاربردهای مدل زبانی می‌توانند باعث آسیب شوند به تفصیل شرح می‌دهد.

تنظیماتی را برای کاهش خطرات ایمنی در نظر بگیرید

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

به عنوان مثال، هنگام طراحی یک برنامه کاربردی:

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

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

    نکته پیشرفته

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

  • ایجاد تدابیر حفاظتی در برابر سوء استفاده عمدی مانند تخصیص شناسه منحصر به فرد به هر کاربر و اعمال محدودیت در حجم درخواست های کاربر که می توانند در یک دوره معین ارسال شوند. حفاظت دیگر، تلاش و محافظت در برابر تزریق سریع احتمالی است. تزریق سریع، بسیار شبیه تزریق SQL، راهی برای کاربران مخرب برای طراحی یک اعلان ورودی است که خروجی مدل را دستکاری می کند، به عنوان مثال، با ارسال یک اعلان ورودی که به مدل دستور می دهد هر نمونه قبلی را نادیده بگیرد. برای جزئیات بیشتر در مورد سوء استفاده عمدی، به خط مشی استفاده ممنوعه هوش مصنوعی مولد مراجعه کنید.

  • تنظیم عملکرد به چیزی که ذاتاً خطر کمتری دارد. کارهایی که دامنه محدودتری دارند (مثلاً استخراج کلمات کلیدی از قسمت‌های متن) یا نظارت انسانی بیشتری دارند (مثلاً تولید محتوای کوتاه‌مدت که توسط یک انسان بررسی می‌شود)، اغلب خطر کمتری دارند. بنابراین، به‌عنوان مثال، به‌جای ایجاد یک برنامه کاربردی برای نوشتن پاسخ ایمیل از ابتدا، ممکن است در عوض آن را به گسترش یک طرح کلی یا پیشنهاد عبارات جایگزین محدود کنید.

تست ایمنی را متناسب با مورد استفاده خود انجام دهید

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

غیرعادی نیست که قبل از اینکه مطمئن شوید که آماده راه اندازی هستید، چندین بار انجام تغییرات و آزمایش انجام دهید، حتی برای برنامه هایی که ریسک نسبتاً پایینی دارند. دو نوع تست به ویژه برای کاربردهای هوش مصنوعی مفید است:

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

    نکات پیشرفته

    • مراقب باشید که بیش از حد به رویکردهای "خارج از قفسه" تکیه کنید زیرا به احتمال زیاد باید مجموعه داده های آزمایشی خود را با استفاده از ارزیابی کننده های انسانی بسازید تا کاملاً با زمینه برنامه خود مطابقت داشته باشد.
    • اگر بیش از یک معیار دارید، باید تصمیم بگیرید که اگر تغییری منجر به بهبود یک معیار به ضرر دیگری شود، چگونه معامله کنید. مانند سایر مهندسی عملکرد، ممکن است بخواهید به جای عملکرد متوسط، روی عملکرد بدترین حالت در مجموعه ارزیابی خود تمرکز کنید.
  • تست خصمانه شامل تلاش پیشگیرانه برای شکستن برنامه شما است. هدف این است که نقاط ضعف را شناسایی کنید تا بتوانید اقدامات لازم را برای رفع آنها انجام دهید. آزمایش خصومت‌آمیز می‌تواند زمان/تلاش قابل توجهی را از ارزیاب‌های متخصص در برنامه‌تان بگیرد - اما هرچه بیشتر این کار را انجام دهید، شانس بیشتری برای شناسایی مشکلات دارید، به‌ویژه آن‌هایی که به ندرت یا فقط پس از اجرای مکرر برنامه رخ می‌دهند.

    • تست خصمانه روشی برای ارزیابی سیستماتیک یک مدل ML با هدف یادگیری نحوه رفتار آن در صورت ارائه ورودی های مخرب یا سهوا مضر است:
      • وقتی ورودی به وضوح برای تولید خروجی ناامن یا مضر طراحی شده باشد، یک ورودی ممکن است مخرب باشد - برای مثال، درخواست از یک مدل تولید متن برای ایجاد یک ناسزای نفرت‌انگیز در مورد یک مذهب خاص.
      • یک ورودی به طور ناخواسته مضر است زمانی که خود ورودی ممکن است بی ضرر باشد، اما خروجی مضر ایجاد کند - برای مثال، درخواست از یک مدل تولید متن برای توصیف فردی از یک قومیت خاص و دریافت یک خروجی نژادپرستانه.
    • چیزی که یک آزمون مخالف را از یک ارزیابی استاندارد متمایز می کند، ترکیب داده های مورد استفاده برای آزمایش است. برای آزمایش‌های متخاصم، داده‌های آزمایشی را انتخاب کنید که به احتمال زیاد خروجی مشکل‌ساز را از مدل استخراج کند. این به معنای بررسی رفتار مدل برای همه انواع آسیب‌های ممکن است، از جمله نمونه‌های نادر یا غیرمعمول و موارد لبه‌ای که مربوط به سیاست‌های ایمنی هستند. همچنین باید شامل تنوع در ابعاد مختلف جمله مانند ساختار، معنا و طول باشد. برای جزئیات بیشتر در مورد مواردی که هنگام ساخت مجموعه داده آزمایشی باید در نظر بگیرید، می‌توانید عادلانه به شیوه‌های هوش مصنوعی مسئول Google مراجعه کنید.

      نکات پیشرفته

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

نظارت بر مشکلات

مهم نیست که چقدر آزمایش و کاهش می دهید، هرگز نمی توانید کمال را تضمین کنید، بنابراین از قبل برنامه ریزی کنید که چگونه مشکلاتی را که به وجود می آیند را تشخیص داده و با آنها مقابله کنید. رویکردهای متداول شامل راه اندازی یک کانال نظارت شده برای کاربران برای به اشتراک گذاشتن بازخورد (به عنوان مثال، رتبه بندی با شست بالا/پایین) و اجرای یک مطالعه کاربر برای درخواست فعالانه بازخورد از ترکیب متنوعی از کاربران است - به ویژه اگر الگوهای استفاده با انتظارات متفاوت باشد.

نکات پیشرفته

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

مراحل بعدی

  • برای آشنایی با تنظیمات ایمنی قابل تنظیم موجود از طریق Gemini API، به راهنمای تنظیمات ایمنی مراجعه کنید.
  • مقدمه درخواست برای شروع نوشتن اولین درخواست های خود را ببینید.