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

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

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 के ज़रिए उपलब्ध, अडजस्ट की जा सकने वाली सुरक्षा सेटिंग के बारे में जानने के लिए, सुरक्षा सेटिंग गाइड देखें.
• पहला प्रॉम्प्ट लिखने के लिए, प्रॉम्प्ट के बारे में जानकारी देखें.