AI ऐप्लिकेशन्स को सुरक्षित करनामध्यमपाठ 1425 मिनट का पाठ

AI फ़ीचर्स में ग़लत जानकारी (misinformation) और अत्यधिक निर्भरता (overreliance)

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

पाठ वीडियो में

60 सेकंड में

AI फ़ीचर्स में ग़लत जानकारी (misinformation) और अत्यधिक निर्भरता (overreliance)

मॉडल्स पूरे आत्मविश्वास के साथ ग़लत हो सकते हैं। ख़तरा तब बढ़ जाता है जब आपका प्रॉडक्ट ग़लत जवाबों को भरोसेमंद बना देता है, या जब लोग और सिस्टम बिना जांचे-परखे उन पर अमल करने लगते…

1/5
आसान शब्दों में
क्लास में एक सहपाठी हमेशा तेज़ी से और पक्के तौर पर जवाब देता है, लेकिन कभी-कभी मनगढ़ंत बातें बना देता है। असली मुसीबत तब शुरू होती है जब पूरी क्लास बिना जांचे उसकी नकल करने लगती है।
OWASP का LLM09 Misinformation ऐसे झूठे या भ्रामक आउटपुट को कवर करता है जो देखने में सच लगता है। मॉडल तथ्य, सोर्स, नीतियां या कोड मन से गढ़ सकता है। Overreliance इसका दूसरा पहलू है: लोग या सिस्टम बिना जांचे आउटपुट पर अमल करते हैं। जब आउटपुट वास्तविक फ़ैसलों को प्रभावित करता है, तो ये दोनों मिलकर सुरक्षा और बचाव से जुड़ी समस्या बन जाते हैं।

यह कहां नुक़सान पहुंचाता है

फ़ीचरक्या ग़लत होता हैनुक़सान
कस्टमर सपोर्ट बॉटरिफंड या छूट की मनगढ़ंत नीति बना देता हैनाराज़ ग्राहक, शिकायतें, ख़र्च और संभावित क़ानूनी झंझट
HR पॉलिसी असिस्टेंटछुट्टी या नोटिस के ग़लत नियम बताता हैकर्मचारी झूठी जानकारी के आधार पर फ़ैसले लेते हैं
कोडिंग असिस्टेंटऐसी लाइब्रेरी सुझाता है जो मौजूद ही नहीं है, या असुरक्षित कोड देता हैसप्लाई-चेन अटैक, प्रोडक्शन में कमज़ोरियां (vulnerabilities)
सिक्योरिटी या IT हेल्परकिसी अलर्ट को हानिरहित बताकर समराइज़ करता है जबकि वह वैसा नहीं होताएक असली घटना अनदेखी रह जाती है
स्वास्थ्य या वित्त से जुड़ी जानकारीआत्मविश्वास से भरी लेकिन ग़लत सलाहलोगों को वास्तविक नुक़सान; पेशेवर समीक्षा की ज़रूरत

एक उदाहरण: पैकेज हैल्यूसिनेशन

कोडिंग असिस्टेंट कभी-कभी ऐसे पैकेज नाम सुझाते हैं जो असल में मौजूद ही नहीं होते। हमलावर उन नामों को सार्वजनिक पैकेज रजिस्ट्री पर रजिस्टर कर सकते हैं और उनमें मैलिशियस कोड भर सकते हैं। जो डेवलपर सुझाव पर भरोसा करके उसे इंस्टॉल करता है, वह अनजाने में हमलावर का कोड चला देता है। इसे कभी-कभी slopsquatting कहा जाता है।
  • इंस्टॉल करने से पहले जांचें कि सुझाया गया पैकेज मौजूद है, जाना-पहचाना है, और उसका एक वास्तविक इतिहास और मेंटेनर्स हैं।
  • ऐसे नामों से सावधान रहें जो लोकप्रिय पैकेजों से मिलते-जुलते हैं लेकिन उनमें थोड़ा सा फ़र्क़ है।
  • ज़रूरी प्रोजेक्ट्स के लिए लॉक फ़ाइलें, एक प्राइवेट मिरर या मंज़ूर किए गए पैकेजों की अलाउ-लिस्ट का उपयोग करें।
  • अपनी पाइपलाइन में डिपेंडेंसी स्कैनिंग चलाएं (यूनिट 4)।

संदेह को ध्यान में रखकर डिज़ाइन करें

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

जोखिम के हिसाब से समीक्षा तय करें

  1. 1

    वर्गीकरण करें

    फ़ीचर के आउटपुट को इस आधार पर बांटें कि अगर वे ग़लत हुए तो क्या असर होगा।
  2. 2

    कम जोखिम

    ड्राफ़्ट, सुझाव, सर्च में मदद: ऑटोमैटिक, सोर्स के साथ।
  3. 3

    मध्यम जोखिम

    पॉलिसी से जुड़े जवाब, काम के लिए इस्तेमाल होने वाले सारांश: सोर्स ज़रूरी, साफ़ चेतावनी, आसानी से एस्केलेशन की सुविधा।
  4. 4

    ज़्यादा जोखिम

    पैसे, सेहत, क़ानून, एक्सेस में बदलाव, सुरक्षा से जुड़ी कार्रवाइयां: कुछ भी होने से पहले एक योग्य इंसान समीक्षा करे।
Grounding से मदद मिलती है: मॉडल को निर्देश दें कि वह सिर्फ़ खोजे गए दस्तावेज़ों (retrieved documents) के आधार पर जवाब दे और अगर उनमें सवाल का हल न हो तो साफ़ मना कर दे। फिर इसकी जांच करें। दावों की तुलना उद्धृत सोर्स से करने वाली ऑटोमैटिक जांचें कुछ ग़लतियां पकड़ सकती हैं, लेकिन वे भी पूरी तरह सही नहीं होतीं। ऐसे सवालों के इवैल्यूएशन सेट रखें जिनके सही जवाब पहले से पता हों, और मापें कि फ़ीचर उन्हें कितनी बार सही बताता है।
सावधान रहें
सिर्फ़ एक डिस्क्लेमर से अत्यधिक निर्भरता की समस्या हल नहीं होती। लोग उन चेतावनियों को पढ़ना बंद कर देते हैं जो हर स्क्रीन पर दिखती हैं। सोर्स दिखाने, ईमानदारी से "मुझे नहीं पता" कहने और जहां ज़रूरत हो वहां इंसानी समीक्षा पर ध्यान दें।
इसे आज़माएं। किसी चैटबॉट से एक बहुत ही विशिष्ट, असामान्य काम के लिए पायथन लाइब्रेरी सुझाने को कहें। कुछ भी इंस्टॉल करने से पहले, आधिकारिक पैकेज वेबसाइट पर हर नाम खोजें। क्या यह मौजूद है? इसे कौन मेंटेन करता है? यह कब से मौजूद है?

और देखें और पढ़ें

लैब

एक AI फ़ीचर के लिए दोबारा डिज़ाइन की गई आंसर स्क्रीन और स्टेक्स टेबल, साथ ही जांचे गए पैकेजों की एक लिस्ट।

~25 min

समस्या

भाग A (पेन और पेपर): एक दुकान के सपोर्ट बॉट ने बिना किसी सोर्स के जवाब दिया "हां, आप पूरे रिफंड के लिए 30 दिनों के भीतर कोई भी सामान वापस कर सकते हैं"। असली पॉलिसी 7 दिनों की है।

  1. एक बेहतर आंसर स्क्रीन का स्केच बनाएं: सोर्स कहां दिखता है, जब बॉट को पक्का पता न हो तो वह क्या कहता है, और यूज़र किसी इंसान तक कैसे पहुंचता है।
  2. इस बॉट को मिलने वाले पांच तरह के सवालों की एक टेबल बनाएं, जिसमें जोखिम का स्तर (कम / मध्यम / ज़्यादा) और प्रत्येक के लिए रिव्यू का नियम लिखा हो।

भाग B (सिर्फ़ ब्राउज़र, कुछ भी इंस्टॉल नहीं करना है): किसी चैटबॉट से किसी असामान्य काम के लिए तीन पायथन लाइब्रेरीज़ पूछें। हर नाम के लिए, आधिकारिक पैकेज वेबसाइट पर जांचें और लिखें: मौजूद है? जानी-पहचानी है? मेंटेनर्स हैं? रिलीज़ की पहली तारीख क्या है?

आपका काम तब पूरा होगा जब

कठिन सवाल

उत्तर देखने से पहले ख़ुद जवाब देने की कोशिश करें। अगर आप इनके जवाब दे सकते हैं, तो आप पाठ समझ गए हैं।

Q1आपका बॉट एक वास्तविक पॉलिसी दस्तावेज़ का हवाला देता है, लेकिन जवाब में फिर भी उसे ग़लत बताता है। आप इसे अपने आप (ऑटोमैटिकली) कैसे पकड़ सकते हैं, और इसकी सीमाएं क्या हैं?दिखाएं

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

Q2हर जवाब के आगे कॉन्फ़िडेंस पर्सेंटेज (प्रतिशत) दिखाना फ़ायदे से ज़्यादा नुक़सानदेह क्यों हो सकता है?दिखाएं

मॉडल्स भरोसेमंद रूप से कैलिब्रेटेड नहीं होते हैं, इसलिए वह संख्या वास्तविक सटीकता से मेल नहीं खा सकती है। "92%" जैसी सटीक दिखने वाली संख्या जवाबों को अधिक वैज्ञानिक बना देती है और भरोसा बढ़ा देती है। ईमानदार संकेत, जैसे कि क्या कोई सोर्स मिला था और क्या दावा उसमें से उद्धृत किया गया है, आमतौर पर अधिक उपयोगी होते हैं।

जारी रखने के लिए कृपया साइन इन करें।

अक्सर पूछे जाने वाले सवाल

क्या हम हैल्यूसिनेशन को पूरी तरह ख़त्म कर सकते हैं?

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

क्या ग़लत जानकारी रोकने के लिए RAG काफ़ी है?

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

अत्यधिक निर्भरता सिर्फ़ क्वालिटी की नहीं, बल्कि एक सुरक्षा समस्या क्यों है?

क्योंकि हमलावर इसका फ़ायदा उठा सकते हैं। वे मॉडल द्वारा दोहराए जाने के लिए झूठी जानकारी डाल सकते हैं, मनगढ़ंत पैकेज नामों को रजिस्टर कर सकते हैं, या इस बात पर भरोसा कर सकते हैं कि स्टाफ़ AI की समरी पर आंख मूंदकर भरोसा कर लेगा। कोई भी ऐसा आउटपुट जिस पर लोग बिना जांचे अमल करते हैं, वह हमले का रास्ता बन जाता है।

यह कौन तय करता है कि क्या "ज़्यादा जोखिम" वाला है?

प्रॉडक्ट ओनर, सुरक्षा, क़ानूनी और डोमेन विशेषज्ञों के साथ मिलकर यह तय करता है। हर फ़ीचर के लिए इस फ़ैसले को लिखकर रखें। जब भी शक हो, और ख़ास तौर पर स्वास्थ्य, क़ानूनी या वित्तीय मामलों में, किसी योग्य पेशेवर से समीक्षा ज़रूर कराएं।

पाठ का टेस्ट

5 सवाल। पास होने और इस पाठ को पूरा करने के लिए 3 सही होने चाहिए (60%)।

टेस्ट देने और अपनी प्रोग्रेस सेव करने के लिए साइन इन करें