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

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

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

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

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

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

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

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

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

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

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

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

نصائح متقدمة

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

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

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

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

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

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

    نصيحة متقدمة

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

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

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

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

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

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

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

    نصائح متقدمة

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

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

      نصائح متقدمة

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

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

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

نصائح متقدمة

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

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