सुरक्षा से जुड़े दिशा-निर्देश

लार्ज लैंग्वेज मॉडल (एलएलएम) को क्रिएटिव टूल के तौर पर इस्तेमाल किया जा सकता है. इन टूल से, भाषा से जुड़े अलग-अलग टास्क पूरे किए जा सकते हैं. माफ़ करें, इसका मतलब यह भी है कि बड़े लैंग्वेज मॉडल ऐसे आउटपुट जनरेट कर सकते हैं जिनकी आपको उम्मीद नहीं है. इनमें आपत्तिजनक, असंवेदनशील या तथ्यों के हिसाब से गलत टेक्स्ट भी शामिल है. इसके अलावा, इन मॉडल की शानदार बहुमुखी प्रतिभा की वजह से यह अंदाज़ा लगाना मुश्किल हो जाता है कि ये मॉडल किस तरह के अनचाहे आउटपुट दे सकते हैं. Gemini API को Google के एआई (AI) के सिद्धांतों को ध्यान में रखकर डिज़ाइन किया गया है. हालांकि, इन मॉडल को ज़िम्मेदारी के साथ लागू करने की ज़िम्मेदारी डेवलपर की है. सुरक्षित और ज़िम्मेदार ऐप्लिकेशन बनाने में डेवलपर की मदद करने के लिए, Gemini API में पहले से कॉन्टेंट फ़िल्टर करने की कुछ सुविधाएं पहले से मौजूद होती हैं. साथ ही, नुकसान के चार डाइमेंशन में ज़रूरत के हिसाब से बदलाव की जा सकने वाली सुरक्षा सेटिंग भी मौजूद हैं. ज़्यादा जानने के लिए, सुरक्षा सेटिंग गाइड देखें.

इस दस्तावेज़ का मकसद, सुरक्षा से जुड़े कुछ ऐसे जोखिमों के बारे में बताना है जो एलएलएम का इस्तेमाल करते समय पैदा हो सकते हैं. साथ ही, सुरक्षा डिज़ाइन और डेवलपमेंट से जुड़े नए सुझाव भी दिए जा सकते हैं. (ध्यान दें कि नियम और कानून के हिसाब से भी पाबंदियां लागू हो सकती हैं, लेकिन इस तरह का ध्यान रखना, इस गाइड के दायरे से बाहर है.)

एलएलएम का इस्तेमाल करके ऐप्लिकेशन बनाते समय, यह तरीका अपनाने का सुझाव दिया जाता है:

  • अपने ऐप्लिकेशन से जुड़े सुरक्षा से जुड़े जोखिमों को समझना
  • सुरक्षा से जुड़े खतरों को कम करने के लिए, बदलावों को ध्यान में रखना
  • आपके इस्तेमाल के उदाहरण के हिसाब से सुरक्षा जांच की जा रही है
  • लोगों से सुझाव या राय मांगना और उनके इस्तेमाल पर नज़र रखना

बदलाव और टेस्टिंग के चरण तब तक बार-बार दोहराए जाने चाहिए, जब तक आपके ऐप्लिकेशन की परफ़ॉर्मेंस आपके ऐप्लिकेशन के हिसाब से सही न हो जाए.

मॉडल को लागू करने का साइकल

अपने ऐप्लिकेशन के सुरक्षा जोखिमों को समझना

इस संदर्भ में, सुरक्षा को एलएलएम की ऐसी क्षमता के तौर पर परिभाषित किया गया है जो अपने उपयोगकर्ताओं को नुकसान पहुंचाने से रोकती है. उदाहरण के लिए, बुरे बर्ताव वाली भाषा का इस्तेमाल करना या रूढ़िवादी सोच को बढ़ावा देने वाला कॉन्टेंट बनाना. Gemini API की मदद से उपलब्ध कराए गए मॉडल, Google के एआई से जुड़े सिद्धांतों को ध्यान में रखकर डिज़ाइन किए गए हैं. साथ ही, इसका इस्तेमाल जनरेटिव एआई के इस्तेमाल पर पाबंदी की नीति के तहत किया जाता है. इस एपीआई में, भाषा के मॉडल से जुड़ी कुछ आम समस्याओं को हल करने के लिए, सुरक्षा फ़िल्टर की सुविधा पहले से मौजूद है. जैसे, नफ़रत फैलाने वाली भाषा और नफ़रत फैलाने वाली भाषा का इस्तेमाल. हालांकि, हर ऐप्लिकेशन के उपयोगकर्ताओं को अलग-अलग जोखिम हो सकते हैं. इसलिए, यह ज़रूरी है कि आप ऐप्लिकेशन के मालिक के तौर पर, अपने ऐप्लिकेशन के उपयोगकर्ताओं और उनसे होने वाले संभावित नुकसान के बारे में जानें. साथ ही, यह पक्का करें कि आपका ऐप्लिकेशन, एलएलएम का सुरक्षित और ज़िम्मेदारी के साथ इस्तेमाल करे.

इस आकलन में, आपको नुकसान होने की संभावना को ध्यान में रखना चाहिए. साथ ही, समस्या को हल करने के तरीके तय करना चाहिए. उदाहरण के लिए, तथ्यों पर आधारित घटनाओं पर निबंध जनरेट करने वाले ऐप्लिकेशन को, मनोरंजन के लिए काल्पनिक कहानियां बनाने वाले ऐप्लिकेशन के बजाय, गलत जानकारी से बचने के लिए ज़्यादा सावधानी बरतनी होगी. सुरक्षा से जुड़े संभावित खतरों का पता लगाने का एक अच्छा तरीका यह है कि आप अपने असली उपयोगकर्ताओं और उन लोगों के बारे में रिसर्च करें जिन पर आपके ऐप्लिकेशन के नतीजों का असर पड़ सकता है. इस प्रोसेस में कई तरह के काम हो सकते हैं. इनमें अपने ऐप्लिकेशन डोमेन में आर्ट स्टडी की स्थिति पर रिसर्च करना, लोगों से मिलते-जुलते ऐप्लिकेशन का इस्तेमाल करने के तरीके के बारे में जानना, उपयोगकर्ता स्टडी, सर्वे चलाना या संभावित उपयोगकर्ताओं के साथ अनौपचारिक इंटरव्यू करना शामिल है.

उन्नत युक्तियां

  • टारगेट किए गए अपने ऐप्लिकेशन और इसके मकसद के बारे में, अपनी टारगेट की गई जनसंख्या के अलग-अलग तरह के संभावित उपयोगकर्ताओं से बात करें, ताकि आपको संभावित खतरों के बारे में ज़्यादा जानकारी मिल सके. साथ ही, ज़रूरत के मुताबिक विविधता से जुड़ी शर्तों में बदलाव किया जा सके.
  • अमेरिका की सरकार के नैशनल इंस्टिट्यूट ऑफ़ स्टैंडर्ड्स ऐंड टेक्नोलॉजी (एनआईएसटी) की ओर से जारी किया गया एआई रिस्क मैनेजमेंट फ़्रेमवर्क, एआई से जुड़े जोखिम को मैनेज करने के लिए ज़्यादा जानकारी और सीखने के अतिरिक्त संसाधन उपलब्ध कराता है.
  • भाषा के मॉडल से होने वाले नुकसान के नैतिक और सामाजिक जोखिमों पर DeepMind ने पब्लिश किया है. इसमें उन तरीकों के बारे में विस्तार से बताया गया है जिनसे भाषा के मॉडल इस्तेमाल करने से लोगों को नुकसान पहुंच सकता है.

सुरक्षा से जुड़े खतरों को कम करने के लिए, बदलाव करें

अब आपको जोखिमों के बारे में पता है, तो आप इन्हें कम करने के बारे में फ़ैसला ले सकते हैं. यह तय करना एक अहम फ़ैसला है कि किन जोखिमों को प्राथमिकता देनी है और उन्हें रोकने के लिए कितनी मेहनत करनी चाहिए. यह किसी सॉफ़्टवेयर प्रोजेक्ट में बग की प्राथमिकता तय करने जैसा ही है. प्राथमिकताएं तय कर लेने के बाद, खतरों को कम करने के तरीकों के बारे में सोचें. अक्सर आसान बदलाव बदलाव ला सकते हैं और जोखिम कम कर सकते हैं.

उदाहरण के लिए, ऐप्लिकेशन डिज़ाइन करते समय, इन बातों का ध्यान रखें:

  • आपके ऐप्लिकेशन में स्वीकार किए जाने वाले कॉन्टेंट को बेहतर तरीके से दिखाने के लिए, मॉडल आउटपुट को ट्यून करें. ट्यूनिंग, मॉडल के आउटपुट को ज़्यादा अनुमान लगाने लायक और एक जैसा बना सकती है. इससे कुछ खतरों को कम करने में मदद मिल सकती है.
  • इनपुट का ऐसा तरीका उपलब्ध कराना जो सुरक्षित आउटपुट देता हो. किसी एलएलएम को सटीक इनपुट देने से, आउटपुट की क्वालिटी पर असर पड़ सकता है. इनपुट प्रॉम्प्ट की मदद से यह पता लगाने की कोशिश करें कि आपके डिवाइस के इस्तेमाल के लिए कौनसा तरीका सबसे सुरक्षित है. ऐसा इसलिए, क्योंकि ऐसा करने पर आपको ऐसा यूएक्स (UX) मिल सकता है जो आपके लिए यह काम आसान कर सके. उदाहरण के लिए, उपयोगकर्ताओं को सिर्फ़ इनपुट प्रॉम्प्ट की ड्रॉप-डाउन सूची में से चुनने के लिए सीमित किया जा सकता है. इसके अलावा, जानकारी देने वाले वाक्यांशों वाले पॉप-अप सुझाव भी दिए जा सकते हैं, जो आपके ऐप्लिकेशन में सुरक्षित तरीके से परफ़ॉर्म करते हैं.

  • उपयोगकर्ता को दिखाए जाने से पहले ही, असुरक्षित इनपुट ब्लॉक और आउटपुट फ़िल्टर करना. सामान्य स्थितियों में, ब्लॉकलिस्ट का इस्तेमाल प्रॉम्प्ट या जवाबों में असुरक्षित शब्दों या वाक्यांशों की पहचान करने और ब्लॉक करने के लिए किया जा सकता है. इसके अलावा, समीक्षा करने वाले लोगों को ऐसे कॉन्टेंट में मैन्युअल तरीके से बदलाव या ब्लॉक करने के लिए कहा जा सकता है.

  • हर सवाल को संभावित नुकसान या खतरे वाले सिग्नल से लेबल करने के लिए, ट्रेनिंग वाली कैटगरी तय करने वाले सिस्टम का इस्तेमाल करना. इसके बाद, जिस तरह के नुकसान का पता चला है उसके आधार पर, अनुरोध को हैंडल करने के तरीके के बारे में अलग-अलग रणनीतियां अपनाई जा सकती हैं. उदाहरण के लिए, अगर इनपुट ज़्यादा आपत्तिजनक है या बुरे बर्ताव वाला है, तो इसे ब्लॉक किया जा सकता है. इसकी जगह पर, पहले से स्क्रिप्ट किया गया जवाब दिया जा सकता है.

    बेहतर सलाह

    • अगर सिग्नल से यह पता चलता है कि आउटपुट में नुकसान पहुंचाने वाला कॉन्टेंट मौजूद है, तो ऐप्लिकेशन इन विकल्पों का इस्तेमाल कर सकता है:
      • गड़बड़ी का मैसेज या पहले से स्क्रिप्ट किया गया आउटपुट दें.
      • सुरक्षित तरीके से वैकल्पिक आउटपुट जनरेट होने पर, फिर से प्रॉम्प्ट जनरेट करने की कोशिश करें. ऐसा इसलिए, क्योंकि कभी-कभी एक ही प्रॉम्प्ट से अलग-अलग आउटपुट मिल सकते हैं.

  • जान-बूझकर किए गए गलत इस्तेमाल के ख़िलाफ़ सुरक्षा के उपाय लागू करना जैसे, हर उपयोगकर्ता को एक यूनीक आईडी असाइन करना और किसी तय अवधि में सबमिट की जा सकने वाली उपयोगकर्ता क्वेरी की संख्या सीमित करना. दूसरा सुरक्षा उपाय है, संभावित प्रॉम्प्ट इंजेक्शन से बचाना और कोशिश करना. एसक्यूएल इंजेक्शन की तरह ही प्रॉम्प्ट इंजेक्शन, नुकसान पहुंचाने वाले लोगों के लिए इनपुट प्रॉम्प्ट डिज़ाइन करने का एक तरीका है. इससे मॉडल के आउटपुट में हेर-फेर की जा सकती है. उदाहरण के लिए, ऐसा इनपुट प्रॉम्प्ट भेजना जो मॉडल को पिछले सभी उदाहरणों को अनदेखा करने का निर्देश देता है. जान-बूझकर गलत इस्तेमाल करने के बारे में ज़्यादा जानने के लिए, जनरेटिव एआई के इस्तेमाल पर पाबंदी की नीति देखें.

  • किसी ऐसी चीज़ के हिसाब से फ़ंक्शन में बदलाव करना जिसमें पहले से ही कम जोखिम हो. जिन टास्क का दायरा सीमित होता है (उदाहरण के लिए, टेक्स्ट के पैसेज से कीवर्ड निकालना) या जिन टास्क की समीक्षा ज़्यादा लोगों को करनी होती है (उदाहरण के लिए, ऐसा छोटा कॉन्टेंट तैयार करना जिसकी समीक्षा मैन्युअल तरीके से की जाती है), अक्सर कम जोखिम वाले होते हैं. इसलिए, शुरुआत से ईमेल जवाब लिखने के लिए ऐप्लिकेशन बनाने के बजाय, इसे आउटलाइन तय करने या वैकल्पिक वाक्यांशों का सुझाव देने तक सीमित करें.

अपने इस्तेमाल के उदाहरण के हिसाब से सुरक्षा जांच करें

मज़बूत और सुरक्षित ऐप्लिकेशन बनाने का परीक्षण एक अहम हिस्सा है, लेकिन जांच का दायरा और रणनीतियां अलग-अलग होंगी. उदाहरण के लिए, मजे़ में काम करने वाले हाइकू जनरेटर से, कानूनी दस्तावेज़ों की खास जानकारी देने और अनुबंधों के ड्राफ़्ट तैयार करने में मदद करने के लिए बनाए गए ऐप्लिकेशन की तुलना में कम गंभीर जोखिम हो सकता है. हालांकि, हाइकू जनरेटर का इस्तेमाल ज़्यादा से ज़्यादा तरह के उपयोगकर्ता कर सकते हैं. इसका मतलब है कि इस तरह के मुश्किल काम या अनजाने में नुकसान पहुंचाने वाले इनपुट की संभावना बढ़ सकती है. इसे लागू करने का तरीका भी मायने रखता है. उदाहरण के लिए, किसी भी कार्रवाई से पहले, ऐसे आउटपुट वाले ऐप्लिकेशन की समीक्षा एक जैसे ऐप्लिकेशन के मुकाबले, नुकसान पहुंचाने वाले आउटपुट देने की कम संभावना होती है.

आप लॉन्च के लिए तैयार हैं या नहीं, इस बारे में भरोसा होने से पहले बदलाव करने और टेस्टिंग करने को बार-बार दोहराना पड़ता है. यहां तक कि कम जोखिम वाले ऐप्लिकेशन के लिए भी ऐसा किया जाता है. दो तरह की टेस्टिंग, खास तौर पर एआई ऐप्लिकेशन के लिए काम की है:

  • सुरक्षा मानदंड में सुरक्षा मेट्रिक डिज़ाइन की जाती हैं. इनसे यह पता चलता है कि आपका ऐप्लिकेशन किस तरह इस्तेमाल किया जा सकता है और उसे असुरक्षित तरीके से माना जा सकता है. इसके बाद, आकलन से जुड़े डेटासेट का इस्तेमाल करके यह जांच की जाती है कि मेट्रिक में ऐप्लिकेशन की परफ़ॉर्मेंस कैसी है. जांच करने से पहले सुरक्षा मेट्रिक के कम से कम स्वीकार किए जाने वाले लेवल के बारे में सोच लेना अच्छा होता है, ताकि 1) आप उन उम्मीदों के मुताबिक जांच के नतीजों का आकलन कर सकें और 2) उन जांचों के आधार पर मूल्यांकन का डेटासेट इकट्ठा कर सकें जो आपकी सबसे ज़रूरी मेट्रिक का आकलन करते हैं.

    उन्नत युक्तियां

    • “शेल्फ़ के अलावा” अन्य तरीकों पर ज़रूरत से ज़्यादा भरोसा न करें. ऐसा हो सकता है कि आपको अपने ऐप्लिकेशन के कॉन्टेक्स्ट के हिसाब से, रेटिंग देने वाले लोगों की मदद से, टेस्टिंग के लिए खुद के डेटासेट बनाने पड़ें.
    • अगर आपके पास एक से ज़्यादा मेट्रिक हैं, तो आपको यह तय करना होगा कि अगर किसी मेट्रिक में बदलाव करने से एक मेट्रिक में सुधार होता है, तो दूसरी मेट्रिक को नुकसान होने पर आपको कैसे ट्रेड करना होगा. दूसरी परफ़ॉर्मेंस इंजीनियरिंग की तरह, हो सकता है कि आप औसत परफ़ॉर्मेंस के बजाय, आकलन के सेट में सबसे खराब परफ़ॉर्मेंस पर फ़ोकस करना चाहें.

  • मुश्किल परिस्थितियों में मदद करने वाली जांच में, आपके आवेदन को तोड़ने की कोशिश करने की कोशिश की जाती है. कोशिश करें कि कमज़ोरी वाली चीज़ों का पता लगाया जाए, ताकि आप उन्हें ठीक करने के लिए ज़रूरी कदम उठा सकें. मुश्किल परिस्थितियों में जांच करने में जिन समीक्षकों को आपके ऐप्लिकेशन की विशेषज्ञता होती है, उन्हें समझने में बहुत ज़्यादा समय/प्रोसेस लगता है. लेकिन आप जितना ज़्यादा काम करेंगे, समस्याओं का पता लगाने की संभावना उतनी ज़्यादा होगी खास तौर पर, उन समस्याओं के बारे में पता लगाने की संभावना बढ़ जाती है जो बहुत कम बार या बार-बार ऐप्लिकेशन का बार-बार देखने पर होते हैं.

    • ऐडवर्सल टेस्टिंग एक ऐसा तरीका है जिसका इस्तेमाल एमएल मॉडल का व्यवस्थित तरीके से आकलन करने के लिए किया जाता है. इसका मकसद यह जानना है कि नुकसान पहुंचाने वाला या अनजाने में नुकसान पहुंचाने वाले इनपुट दिखने पर वह कैसे काम करता है:
      • जब इनपुट साफ़ तौर पर कोई असुरक्षित या नुकसान पहुंचाने वाला आउटपुट बनाने के लिए डिज़ाइन किया गया हो, तो वह नुकसान पहुंचाने वाला हो सकता है. उदाहरण के लिए, टेक्स्ट जनरेट करने वाले मॉडल से किसी खास धर्म के बारे में नफ़रत फैलाने वाली भाषा का इस्तेमाल करने के लिए कहना.
      • इनपुट तब अनजाने में नुकसान पहुंचाता है, जब इनपुट खुद से नुकसान पहुंचाने वाला हो सकता है, लेकिन उससे नुकसान हो सकता है. उदाहरण के लिए, टेक्स्ट जनरेट करने वाले मॉडल से किसी खास जाति के व्यक्ति के बारे में बताने और नस्लवादी जानकारी पाने के लिए कहना.
    • टेस्ट करने के लिए इस्तेमाल किए गए डेटा का कंपोज़िशन, स्टैंडर्ड आकलन और प्रतिरोधक जांच के बीच फ़र्क़ करता है. मुश्किल परिस्थितियों का पता लगाने के लिए, ऐसे टेस्ट डेटा को चुनें जिसमें मॉडल से समस्या वाला आउटपुट मिलने की संभावना सबसे ज़्यादा हो. इसका मतलब है कि हर तरह के संभावित नुकसानों के लिए, मॉडल के व्यवहार की जांच करना. इनमें, सुरक्षा नीतियों के लिहाज़ से ज़रूरी कभी-कभार होने वाले या असामान्य उदाहरण और ऐसे गंभीर मामले शामिल हैं. साथ ही, वाक्य के अलग-अलग डाइमेंशन में भी विविधता होनी चाहिए, जैसे कि स्ट्रक्चर, मतलब, और लंबाई. टेस्ट डेटासेट बनाते समय, किन बातों का ध्यान रखना चाहिए, इस बारे में ज़्यादा जानकारी के लिए, भरोसेमंद तरीके से काम करने वाले Google के एआई मॉडल देखें.

      उन्नत युक्तियां

      • अपने ऐप्लिकेशन का गलत इस्तेमाल करने के लिए, 'रेड टीम' में लोगों को शामिल करने के पारंपरिक तरीके के बजाय, ऑटोमेटेड टेस्टिंग का इस्तेमाल करें. अपने-आप होने वाली जांच में, 'रेड टीम' एक और भाषा का मॉडल है, जो जांच किए जा रहे मॉडल से नुकसान पहुंचाने वाले आउटपुट देता है.

समस्याओं की निगरानी करना

चाहे आप कितनी भी जांच-पड़ताल करें और कम से कम काम करें, आप कभी भी एकदम सही होने की गारंटी नहीं दे सकते, इसलिए पहले से ही इस बात की योजना बना लें कि आप समस्याओं का पता कैसे लगाएं और उनसे कैसे निपटें. इसके सामान्य तरीकों में, उपयोगकर्ताओं के लिए निगरानी वाला चैनल सेट अप करना (जैसे, पसंद/नापसंद रेटिंग) और अलग-अलग तरह के उपयोगकर्ताओं से सक्रिय तौर पर सुझाव पाने के लिए उपयोगकर्ता स्टडी चलाना शामिल है — खास तौर पर तब, जब इस्तेमाल करने के पैटर्न उम्मीद से अलग हों.

उन्नत युक्तियां

  • जब उपयोगकर्ता, एआई वाले प्रॉडक्ट के बारे में सुझाव या राय देते हैं, तब समय के साथ एआई की परफ़ॉर्मेंस और उपयोगकर्ता अनुभव को काफ़ी बेहतर बनाया जा सकता है. उदाहरण के लिए, इससे प्रॉम्प्ट ट्यूनिंग के लिए बेहतर उदाहरण चुनने में मदद मिलती है. Google की लोग और एआई (AI) गाइडबुक में मौजूद, सुझाव और कंट्रोल चैप्टर में बताया गया है कि सुझाव या राय देने या शिकायत करने के तरीके तय करते समय, किन बातों का ध्यान रखना चाहिए.

अगले चरण