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

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

يمكن استخدام النماذج التي توفّرها Gemini API في مجموعة متنوّعة من تطبيقات الذكاء الاصطناعي التوليدي ومعالجة اللغات الطبيعية (NLP). استخدام هذه متاحة فقط من خلال Gemini API أو Google AI Studio على الويب التطبيق. يخضع استخدامك لواجهة Gemini API أيضًا للاستخدام المحظور للذكاء الاصطناعي التوليدي السياسة بنود الخدمة في Gemini API

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

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

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

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

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

دورة تنفيذ النموذج

فهم مخاطر أمان تطبيقك

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

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

نصائح متقدمة

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

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

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

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

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

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

    نصيحة متقدمة

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

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

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

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

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

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

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

    نصائح متقدمة

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

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

      نصائح متقدمة

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

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

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

نصائح متقدمة

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

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