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

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

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

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

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

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

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

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

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

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

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

مراعاة التعديلات اللازمة للتخفيف من المخاطر المتعلقة بالسلامة والدقة

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

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

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

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

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

  نصيحة متقدّمة

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

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

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

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

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

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

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

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

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

  نصائح متقدمة

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

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

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

    نصائح متقدمة

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

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

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

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

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