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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    बेहतर सलाह

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

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

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

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

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

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

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

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

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

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

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

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

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

समस्याओं पर नज़र रखना

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

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

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

अगले चरण