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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    बेहतर सलाह

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

अगले चरण