सुरक्षा और तथ्यों के सही होने से जुड़े दिशा-निर्देश

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  बेहतर सलाह

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

समस्याओं पर नज़र रखने के लिए

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

अगले चरण

• Gemini API के ज़रिए उपलब्ध, अडजस्ट की जा सकने वाली सुरक्षा सेटिंग के बारे में जानने के लिए, सुरक्षा सेटिंग गाइड पढ़ें.
• पहला प्रॉम्प्ट लिखने के लिए, प्रॉम्प्ट के बारे में जानकारी देखें.