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

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

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

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

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

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

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

बदलाव और जांच के चरणों को तब तक बार-बार दोहराया जाना चाहिए, जब तक आप प्रदर्शन के लिहाज़ से उपयुक्त है.

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

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

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

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

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

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

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

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

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

  बेहतर सलाह

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

अगले चरण

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