إرشادات السلامة

أحد ما يجعل النماذج اللغوية الكبيرة (LLM) مفيدة للغاية هو أنّها أدوات إبداعية يمكنها التعامل مع العديد من المهام اللغوية المختلفة. وهذا يعني أيضًا أنّ النماذج اللغوية الكبيرة يمكن أن تنشئ مخرجات غير متوقعة، بما في ذلك النصوص المسيئة أو غير الحسّاسة أو غير الصحيحة. علاوة على ذلك، فإن التنوع المذهل لهذه النماذج هو أيضًا ما يجعل من الصعب التنبؤ بالضبط بأنواع المخرجات غير المرغوب فيها التي قد تنتجها. تم تصميم Gemini API مع وضع مبادئ الذكاء الاصطناعي في Google في الاعتبار، وتقع على عاتق المطوّرين مسؤولية تطبيق هذه النماذج بشكل مسؤول. لمساعدة المطوّرين على إنشاء تطبيقات آمنة ومسؤولة، تتضمّن واجهة برمجة التطبيقات Gemini API بعض فلاتر المحتوى المضمّنة، بالإضافة إلى إعدادات الأمان القابلة للتعديل وفقًا لأبعاد 4 من الضرر. يُرجى الاطّلاع على دليل إعدادات الأمان للحصول على مزيد من المعلومات.

يهدف هذا المستند إلى تعريفك ببعض المخاطر المتعلّقة بالسلامة التي قد تحدث عند استخدام النماذج اللغوية الكبيرة، واقتراح توصيات جديدة حول تصميم الأمان وتطويره. (لاحظ أن القوانين واللوائح قد تفرض أيضًا قيودًا، ولكن هذه الاعتبارات خارج نطاق هذا الدليل).

ننصحك باتّباع الخطوات التالية عند إنشاء تطبيقات باستخدام النماذج اللغوية الكبيرة:

• فهم المخاطر المرتبطة بالسلامة في تطبيقك
• إجراء تعديلات للتخفيف من مخاطر السلامة
• إجراء اختبار الأمان المناسب لحالة الاستخدام
• طلب الملاحظات من المستخدمين ومراقبة الاستخدام

يجب أن تكون مرحلتي التعديل والاختبار متكررة إلى أن تصل إلى الأداء المناسب لتطبيقك.

فهم المخاطر المرتبطة بالسلامة في تطبيقك

في هذا السياق، يتم تعريف الأمان على أنّه قدرة النموذج اللغوي الكبير على تجنُّب إلحاق الضرر بالمستخدمين، مثلاً من خلال إنشاء لغة مسيئة أو محتوى يروِّج للصور النمطية. تم تصميم النماذج المتوفّرة من خلال Gemini API مع مراعاة مبادئ الذكاء الاصطناعي في Google ويستند استخدامك لها إلى سياسة الاستخدام المحظور للذكاء الاصطناعي التوليدي. توفر واجهة برمجة التطبيقات فلاتر أمان مدمجة للمساعدة في معالجة بعض المشاكل الشائعة في النموذج اللغوي، مثل اللغة غير اللائقة والكلام الذي يحض على الكراهية، والسعي إلى الشمولية وتجنب الصور النمطية. ومع ذلك، يمكن أن يشكل كل تطبيق مجموعة مختلفة من المخاطر على مستخدميه. بصفتك مالك التطبيق، تقع على عاتقك مسؤولية معرفة المستخدمين والأضرار المحتملة التي قد يتسبب بها تطبيقك، وكذلك ضمان استخدام التطبيق للنماذج اللغوية الكبيرة بأمان ومسؤولية.

كجزء من هذا التقييم، يجب أن تفكر في احتمالية حدوث الضرر وتحدد خطورته وخطوات التخفيف منه. على سبيل المثال، يجب أن يكون التطبيق الذي ينشئ مقالات استنادًا إلى أحداث واقعية أكثر حرصًا بشأن تجنب المعلومات الخاطئة، مقارنةً بالتطبيقات التي تنشئ قصصًا خيالية للترفيه. هناك طريقة جيدة لبدء استكشاف مخاطر السلامة المحتملة وهي البحث عن المستخدمين النهائيين وغيرهم من الذين قد يتأثرون بنتائج تطبيقك. يمكن أن يتخذ ذلك أشكالاً عديدة، بما في ذلك البحث عن أحدث الدراسات الفنية في نطاق تطبيقك، أو مراقبة كيفية استخدام الأشخاص للتطبيقات المماثلة، أو إجراء دراسة حول المستخدمين، أو استبيان، أو إجراء مقابلات غير رسمية مع المستخدمين المحتملين.

إجراء تعديلات للحدّ من مخاطر السلامة

الآن بعد أن فهمت المخاطر، يمكنك أن تقرر كيفية تخفيفها. يعد تحديد المخاطر التي يجب تحديد أولوياتها ومقدار ما يجب عليك القيام به لمحاولة منعها قرارًا مهمًا، مثل فرز الأخطاء في مشروع برمجي. بمجرد تحديد الأولويات، يمكنك البدء في التفكير في أنواع إجراءات التخفيف التي ستكون أكثر ملاءمة. غالبًا ما يمكن أن تحدث التغييرات البسيطة فرقًا وتقلل من المخاطر.

على سبيل المثال، عند تصميم تطبيق ضع في اعتبارك ما يلي:

• ضبط ناتج النموذج ليعكس بشكل أفضل ما هو مقبول في سياق تطبيقك يمكن أن يجعل الضبط مخرجات النموذج أكثر قابلية للتنبؤ واتساقًا وبالتالي يمكن أن يساعد في التخفيف من بعض المخاطر.
• توفير طريقة إدخال تسهّل إخراج مخرجات أكثر أمانًا إنّ الإدخال الدقيق الذي تقدّمه النموذج اللغوي الكبير يمكن أن يُحدث فرقًا في جودة المخرجات. إن تجربة مطالبات الإدخال للعثور على ما يعمل بشكل أكثر أمانًا في حالة الاستخدام يستحق الجهد المبذول، حيث يمكنك بعد ذلك توفير تجربة مستخدم تسهله. على سبيل المثال، يمكنك تقييد المستخدمين ليختاروا فقط من قائمة منسدلة لمطالبات الإدخال، أو تقديم اقتراحات منبثقة تحتوي على عبارات وصفية وجدت أنها تؤدي بأمان في سياق تطبيقك.

• حظر الإدخالات غير الآمنة وفلترة المخرجات قبل عرضها للمستخدم: في الحالات البسيطة، يمكن استخدام القوائم المحظورة لتحديد الكلمات أو العبارات غير الآمنة وحظرها في الطلبات أو الردود، أو الطلب من المراجعين تعديل هذا المحتوى أو حظره يدويًا.

• استخدام مصنِّفات مدرَّبة لتصنيف كل طلب بالأضرار المحتملة أو الإشارات التنافسية ويمكن بعد ذلك استخدام استراتيجيات مختلفة لكيفية التعامل مع الطلب استنادًا إلى نوع الضرر الذي تم اكتشافه. على سبيل المثال، إذا كان المُدخل مسيئًا أو عدائيًا بشكل صريح بطبيعته، يمكن حظره وإنشاء ردّ مذكور بدلاً من ذلك.

  نصيحة متقدمة

  • إذا حدّدت الإشارات أن الإخراج ضار، يمكن أن يستخدم التطبيق الخيارات التالية:
    • قدِّم رسالة خطأ أو مخرجات مكتوبة مسبقًا.
    • جرِّب الطلب مرة أخرى في حال إنشاء نتيجة آمنة بديلة، لأنّ الطلب نفسه يؤدي أحيانًا إلى مخرجات مختلفة.

• وضع تدابير وقائية ضد إساءة الاستخدام المتعمَّدة، مثل تخصيص معرّف فريد لكل مستخدم وفرض حدّ أقصى لعدد طلبات بحث المستخدمين التي يمكن إرسالها خلال فترة زمنية معيّنة وهناك وسيلة وقائية أخرى وهي محاولة الحماية من الحقن الفوري المحتمل. يشبه حقن المطالبة، إلى حد كبير إدخال SQL، طريقة يستخدمها المستخدمون الضارون لتصميم طلب إدخال يتلاعب بمخرجات النموذج، على سبيل المثال، من خلال إرسال موجه إدخال يوجِّه النموذج إلى تجاهل أي أمثلة سابقة. يمكنك الاطّلاع على سياسة الاستخدام المحظور للذكاء الاصطناعي التوليدي للحصول على تفاصيل حول إساءة الاستخدام المتعمَّدة.

• تعديل الوظائف وفقًا لآلية تنطوي على مخاطر أقل بطبيعتها غالبًا ما يكون هناك خطر أقل في المهام الأضيق النطاق (مثل استخراج الكلمات الرئيسية من فقرات النص) أو التي يراقبها المستخدمون بشكل أكبر (مثل إنشاء محتوى قصير ليراجعه أحد المراجعين). لذلك على سبيل المثال، بدلاً من إنشاء تطبيق لكتابة رد بالبريد الإلكتروني من البداية، يمكنك بدلاً من ذلك قصره على التوسع في مخطط تفصيلي أو اقتراح صياغة بديلة.

إجراء اختبار الأمان المناسب لحالة الاستخدام

يُعد الاختبار جزءًا أساسيًا من إنشاء تطبيقات قوية وآمنة، ولكن يختلف نطاق الاختبار واستراتيجياته. على سبيل المثال، من المرجح أن يشكل مولّد هايكو للمرح فقط مخاطرة أقل شدة من التطبيق المصمم للاستخدام من قبل شركات المحاماة لتلخيص الوثائق القانونية والمساعدة في صياغة العقود. ولكن قد يستخدم مجموعة متنوعة من المستخدمين أداة إنشاء الهايكو، ما يعني زيادة احتمالية حدوث محاولات عدائية أو حتى المدخلات الضارة غير المقصودة. سياق التنفيذ مهم أيضًا. على سبيل المثال، إنّ التطبيق الذي يتضمّن مخرجات يراجعها خبراء فعليّون قبل أي إجراء يتم اتّخاذه قد يُعتبَر أقل احتمالاً أن يؤدي إلى مخرجات ضارة من التطبيق المتطابق الذي لا يتم الإشراف عليه.

ليس من غير المألوف إجراء تكرارات عديدة لإجراء التغييرات والاختبار قبل الشعور بالثقة في استعدادك للإطلاق، حتى مع التطبيقات المخاطرة نسبيًا. هناك نوعان من الاختبارات مفيدان بشكل خاص لتطبيقات الذكاء الاصطناعي:

• يتضمن مقاييس الأداء الأمني تصميم مقاييس للأمان تعكس الطرق التي قد يكون بها تطبيقك غير آمن في سياق احتمالية استخدامه، ثم اختبار مستوى أدائه وفقًا للمقاييس باستخدام مجموعات بيانات التقييم. من الممارسات الجيدة التفكير في الحد الأدنى من المستويات المقبولة لمقاييس السلامة قبل الاختبار، حتى 1) يمكنك تقييم نتائج الاختبار وفقًا لتلك التوقعات و2) يمكنك جمع مجموعة بيانات التقييم بناءً على الاختبارات التي تقيّم المقاييس التي تهمك كثيرًا.

  نصائح متقدمة

  • يجب توخّي الحذر من الاعتماد الزائد على المناهج "الجاهزة"، إذ أنّه من المحتمل أن تحتاج إلى إنشاء مجموعات بيانات اختبار خاصة بك بالاستعانة بمصنِّفين لتناسب سياق تطبيقك بالكامل.
  • إذا كان لديك أكثر من مقياس، عليك تحديد الطريقة التي سيتم بها المقايضة إذا كان التغيير يؤدي إلى تحسينات في أحد المقاييس يضر بمقياس آخر. كما هي الحال في هندسة الأداء الأخرى، قد تحتاج إلى التركيز على الأداء الأسوأ على مستوى مجموعة التقييم بدلاً من التركيز على الأداء المتوسط.

• يتضمّن الاختبار العدائي محاولة اختراق تطبيقك بشكل استباقي. الهدف هو تحديد نقاط الضعف حتى تتمكن من اتخاذ خطوات لمعالجتها حسب الحاجة. قد يستغرق الاختبار العدائي وقتًا أو جهدًا كبيرًا من المقيّمين ذوي الخبرة في طلبك، ولكن كلما ازدادت فرصتك في اكتشاف المشاكل، خاصة تلك التي تحدث نادرًا أو بعد تكرار عمليات التطبيق.

  • الاختبار العدائي هو طريقة لإجراء تقييم منهجي لنموذج تعلُّم الآلة بهدف معرفة طريقة عمله عند تزويده بمدخلات ضارة أو ضارة بدون قصد:
    • قد يكون أحد الإدخالات ضارًا عندما يكون المُدخل مصممًا بوضوح لإنتاج مخرجات غير آمنة أو ضارة، مثل الطلب من نموذج لإنشاء النص نشر كلام يحضّ على الكراهية حول ديانة معيّنة.
    • يكون الإدخال ضارًا من غير قصد إذا كان المُدخل نفسه غير ضارّ، ولكنه ينتج مخرجات ضارّة، مثل طلب وصف شخص من عرق معيّن وتلقّي مخرجات عنصرية على سبيل المثال.
  • ما يميز الاختبار المخادع عن التقييم القياسي هو تكوين البيانات المستخدمة للاختبار. بالنسبة إلى الاختبارات الخادعة، اختر بيانات الاختبار التي يُرجح أن تستدعي مخرجات تتضمّن مشاكل من النموذج. وهذا يعني التحقق من سلوك النموذج لجميع أنواع الضرر المحتملة، بما في ذلك الأمثلة النادرة أو غير المعتادة والحالات الهامشية ذات الصلة بسياسات السلامة. يجب أن تتضمن أيضًا التنوع في الأبعاد المختلفة للجملة مثل البنية والمعنى والطول. يمكنك الرجوع إلى الممارسات المسؤولة عن الذكاء الاصطناعي من Google في النزاهة للحصول على مزيد من التفاصيل حول النقاط التي يجب مراعاتها عند إنشاء مجموعة بيانات اختبار.

    نصائح متقدمة

    • استخدِم الاختبار المبرمَج بدلاً من الطريقة التقليدية لتوظيف أشخاص ضمن "الفِرق الحمراء" لمحاولة إيقاف طلبك. وفي الاختبارات المبرمَجة، يكون "الفريق الأحمر" هو نموذج لغوي آخر يعثر على نص تم إدخاله، وبالتالي ينتج عنه مخرجات ضارة من النموذج الذي يتم اختباره.

مراقبة المشاكل

بغض النظر عن مقدار الاختبار والتخفيف، لا يمكنك أبدًا ضمان الكمال، لذا خطط مقدمًا لكيفية اكتشاف المشكلات التي تنشأ والتعامل معها. تشمل الأساليب الشائعة إعداد قناة خاضعة للمراقبة تتيح للمستخدمين مشاركة ملاحظاتهم (على سبيل المثال، تقييم الإعجاب أو عدم الإعجاب) وإجراء دراسة مستخدم لطلب الملاحظات من مزيج متنوع من المستخدمين بشكل استباقي، خاصةً إذا كانت أنماط الاستخدام مختلفة عن التوقعات.

الخطوات التالية

• ويمكنك الرجوع إلى دليل إعدادات الأمان لمعرفة المزيد عن إعدادات الأمان القابلة للتعديل والمتوفّرة من خلال Gemini API.
• راجِع مقدمة حول المطالبة للبدء في كتابة الطلبات الأولى.