AI सिस्टम्स का मूल्यांकन (Evaluation)मध्यमपाठ 2256 मिनट का पाठ

सुरक्षा और ख़तरनाक क्षमताओं का मूल्यांकन (Safety and dangerous capabilities)

Safety evals एक साथ दो चीज़ें परखते हैं: सिस्टम उन चीज़ों से मना करे जिनसे उसे करना चाहिए, और उन चीज़ों से मना न करे जिनसे उसे नहीं करना चाहिए। फ्रंटियर पर, लैब्स ख़तरनाक क्षमताओं की भी जांच करती हैं।

✦ ट्यूटर से पूछें🧪 लैब · 40 min📝 पाठ का टेस्ट
पाठ वीडियो में

60 सेकंड में

सुरक्षा और ख़तरनाक क्षमताओं का मूल्यांकन (Safety and dangerous capabilities)

Safety evals एक साथ दो चीज़ें परखते हैं: सिस्टम उन चीज़ों से मना करे जिनसे उसे करना चाहिए, और उन चीज़ों से मना न करे जिनसे उसे नहीं करना चाहिए। फ्रंटियर पर, लैब्स ख़तरनाक क्षमताओं…

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

दो सेट्स, जिन्हें एक साथ मापा जाता है

सेटइसमें क्या होता हैआप क्या मापते हैं
Red-team सेटऐसे अनुरोध जिन्हें आपके प्रोडक्ट के हिसाब से सिस्टम को मना कर देना चाहिए या सावधानी से संभालना चाहिए: दुरुपयोग, नियमों को तोड़ने की कोशिशें, prompt injection, दूसरों के डेटा की मांग।Unsafe-output rate: सिस्टम कितनी बार नुक़सानदेह काम करता है
Should-answer सेटसामान्य और बॉर्डरलाइन अनुरोध जो जोखिम भरे दिखते हैं लेकिन ठीक होते हैं, जैसे "मैं किसी Python process को kill कैसे करूँ?", "पैरासिटामोल के क्या साइड इफेक्ट्स हैं?", "समझाएं कि फ़िशिंग कैसे काम करती है ताकि मैं स्टाफ़ को ट्रेन कर सकूँ।"Over-refusal rate: सिस्टम कितनी बार ग़लत तरीके से मना कर देता है
Under-refusal (ज़रूरत से ज़्यादा छूट देना)
  • चालाकी से पूछे जाने पर नुक़सानदेह निर्देश दे देता है
  • एक ग्राहक का डेटा दूसरे ग्राहक के साथ शेयर करता है
  • किसी वेब पेज से आए injected निर्देशों का पालन करता है
Over-refusal (ज़रूरत से ज़्यादा सतर्क होना)
  • दवा के उन साइड इफेक्ट्स को बताने से मना करता है जो उसके लेबल पर लिखे हैं
  • "kill the process" से इसलिए मना करता है क्योंकि उसमें "kill" शब्द है
  • हर बिना नुक़सान वाले जवाब में लंबी-चौड़ी चेतावनियां जोड़ देता है
नोट
ज़रूरत से ज़्यादा मना करना (Over-refusal) एक असली विफलता है, कोई सुरक्षित डिफ़ॉल्ट नहीं। एक स्वास्थ्य जानकारी देने वाला बॉट जो सामान्य सवालों के जवाब देने से मना कर देता है, वह लोगों को और भी ख़राब स्रोतों की ओर धकेलता है। दोनों दरों को साथ-साथ रिपोर्ट करें, हर श्रेणी और हर भाषा के हिसाब से।

Red-team और should-answer सेट्स तैयार करना

  1. 1

    अपने जोखिमों की सूची बनाएं

    अपने थ्रेट मॉडल और प्रोडक्ट पॉलिसी से समझें: इस सिस्टम को कभी भी क्या नहीं करना चाहिए?
  2. 2

    हर जोखिम के हिसाब से केस लिखें

    सीधे अनुरोध, घुमा-फिराकर किए गए अनुरोध, कई बार में (multi-turn) की गई कोशिशें, दूसरी भाषाओं में और रोमन लिपि या मिली-जुली भाषा (code-mixed) वाले अनुरोध।
  3. 3

    मिलते-जुलते should-answer केस लिखें

    हर जोखिम भरे विषय के लिए, ऐसे सुरक्षित अनुरोध लिखें जिनमें मिलते-जुलते शब्दों का इस्तेमाल होता हो।
  4. 4

    अपेक्षित व्यवहार का लेबल लगाएं

    मना करें, जवाब दें, या सावधानी से जवाब दें (उदाहरण के लिए, सामान्य जानकारी के साथ किसी विशेषज्ञ के पास जाने की सलाह दें)।
  5. 5

    रिग्रेशन सुइट में जोड़ें

    Red-teaming या असल घटनाओं से सामने आई हर नई बात एक नया टेस्ट बन जाती है।
सावधान रहें
सुरक्षा से जुड़े टेस्ट सेट्स में परेशान करने वाले या नुक़सानदेह टेक्स्ट हो सकते हैं। उन्हें सीमित पहुंच (restricted access) के साथ रखें, उन्हें सार्वजनिक न करें, उन्हें लिखने और जांचने वाले लोगों को चेतावनी दें और उनका सहयोग करें, और टेस्ट सेट भरने के लिए कभी भी असली नुक़सानदेह सामग्री न बनाएं। मना करने की क्षमता जांचने के लिए आमतौर पर नुक़सान की श्रेणी का ज़िक्र कर देना ही काफ़ी होता है।

सुरक्षा के लिए भाषाएं भी मायने रखती हैं

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

ख़तरनाक क्षमताओं का मूल्यांकन (Dangerous capability evaluations)

प्रोडक्ट सुरक्षा evals पूछते हैं "क्या हमारा ऐप ठीक से व्यवहार कर रहा है?"। फ्रंटियर AI लैब्स dangerous capability evaluations भी चलाती हैं, जो एक अलग सवाल पूछते हैं: "क्या यह मॉडल किसी को गंभीर नुक़सान पहुंचाने में बड़ी मदद कर सकता है, या अपने आप ख़तरनाक तरीके से काम कर सकता है?" सामान्य तौर पर, लैब्स और सरकारी AI सुरक्षा संस्थान जिन क्षेत्रों का ज़िक्र करते हैं, उनमें शामिल हैं:
  • बड़े पैमाने पर नुक़सान पहुंचाने वाले हथियार: क्या मॉडल जैविक, रासायनिक, रेडियोलॉजिकल या परमाणु नुक़सान पहुंचाने की दिशा में कोई ठोस मदद करता है।
  • साइबर हमले (Cyber offence): क्या यह सॉफ़्टवेयर की कमज़ोरियों को खोजकर उनका फ़ायदा उठा सकता है, उस स्तर से आगे जो हमलावर पहले से आसानी से कर सकते हैं।
  • स्वायत्तता (Autonomy): क्या यह अपने दम पर लंबे, कई चरणों वाले काम पूरे कर सकता है, जिसमें अपनी कॉपी बनाना या संसाधन जुटाना शामिल है।
  • बहकाना और धोखा देना: क्या यह लोगों को अपनी बातों में फंसा सकता है या टेस्टिंग के दौरान अपने व्यवहार को छिपा सकता है।
ये मूल्यांकन विशेषज्ञों द्वारा, अक्सर उस क्षेत्र के जानकारों के साथ और कड़े नियंत्रणों में किए जाते हैं, और सबसे संवेदनशील जानकारियों को सार्वजनिक नहीं किया जाता है। कुछ लैब्स ऐसी सुरक्षा नीतियां प्रकाशित करती हैं जो रिलीज़ से पहले मूल्यांकन के नतीजों को अतिरिक्त सुरक्षा घेरों से जोड़ती हैं। ये तरीके अभी भी विकसित हो रहे हैं और अक्सर बदलते रहते हैं, इसलिए किसी एक विवरण पर भरोसा करने के बजाय ताज़ा सार्वजनिक रिपोर्ट देखें।
यह करें
और गहराई से समझना चाहते हैं? फ्रंटियर अलाइनमेंट रिसर्च ट्रैक का पाठ Dangerous capability evaluations बताता है कि ये मूल्यांकन कैसे डिज़ाइन किए जाते हैं, और परीक्षण के समय अलग व्यवहार करने वाले मॉडल (देखें Looking good in the test) इसे क्यों मुश्किल बना देते हैं।
यह करके देखें। तीन ऐसे should-answer सवाल लिखें जिन्हें कोई डरा हुआ सेफ़्टी फ़िल्टर ग़लती से मना कर सकता है, उदाहरण के लिए दवा, सुरक्षा ट्रेनिंग या इतिहास के बारे में। किसी चैटबॉट से पूछें। क्या वह मददगार तरीके से जवाब देता है?

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

लैब

एक प्रोडक्ट के लिए संतुलित 20-आइटम वाला सुरक्षा सेट, अपेक्षित व्यवहार और दो नंबरों वाली रिपोर्ट के साथ।

~40 min

समस्या

कोई एक प्रोडक्ट चुनें, उदाहरण के लिए अस्पताल के अपॉइंटमेंट और स्वास्थ्य से जुड़ी जानकारी देने वाला बॉट।

  1. इस प्रोडक्ट की सुरक्षा नीति (safety policy) पाँच बुलेट पॉइंट्स में लिखें: इसे क्या कभी नहीं करना चाहिए, और इसे किस चीज़ में हमेशा मदद करनी चाहिए।
  2. गलत इस्तेमाल के विवरण के रूप में 10 रेड-टीम आइटम्स लिखें (उदाहरण के लिए, "किसी अन्य मरीज़ के अपॉइंटमेंट की जानकारी माँगता है", "बिना डॉक्टर के पर्चे वाली दवा की खुराक लेने की कोशिश करता है")। कोई भी असल हानिकारक सामग्री न लिखें।
  3. 10 ऐसे आइटम्स लिखें जिनका जवाब दिया जाना चाहिए (should-answer) और जिनमें मिलते-जुलते शब्दों का इस्तेमाल हो लेकिन वे बिल्कुल ठीक हों (उदाहरण के लिए, "पैरासिटामोल के सामान्य साइड इफेक्ट्स क्या हैं?")। इनमें कम से कम 3 आइटम्स किसी भारतीय भाषा या उसके रोमन रूप में शामिल करें।
  4. हर आइटम के लिए तय करें कि अपेक्षित व्यवहार क्या होना चाहिए: मना करना (refuse), जवाब देना (answer), या सावधानी से जवाब देना (answer with care)।
  5. अगर आपको अनुमति हो, तो जवाब दिए जाने वाले आइटम्स को किसी चैटबॉट पर आज़माएँ और दो संख्याएँ बताएँ: 10 में से बेवजह मना किए गए मामलों (over-refusals) की संख्या, और कोई ऐसी सुरक्षा से जुड़ी चूक जो आपने देखी हो।

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

कठिन सवाल

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

Q1रेड-टीम सेट और जवाब दिए जाने वाले सेट में एक जैसे शब्दों और विषयों का इस्तेमाल क्यों होना चाहिए?दिखाएं

ताकि इवैल्यूएशन से यह फर्क पता चल सके कि सिस्टम सटीक है या बस कामचलाऊ। अगर सुरक्षित रिक्वेस्ट में असुरक्षित रिक्वेस्ट से बिल्कुल अलग शब्दों का इस्तेमाल होगा, तो एक साधारण कीवर्ड फ़िल्टर भी दोनों सेट को पास कर देगा, लेकिन असल यूज़र्स के काम में फेल हो जाएगा। एक जैसे दिखने वाले जोड़े, जैसे "दवा के साइड इफेक्ट्स" और "किसी को नुकसान पहुँचाने वाली खुराक", यह परखते हैं कि सिस्टम सिर्फ़ शब्दों को नहीं, बल्कि उनके पीछे के इरादे को समझता है या नहीं।

Q2कोई मॉडल आज खतरनाक क्षमताओं वाले इवैल्यूएशन पास कर लेता है। यह नतीजा बाद में सही क्यों नहीं भी रह सकता है?दिखाएं

टेस्टिंग के बाद भी क्षमताएँ सामने आ सकती हैं: बेहतर प्रॉम्प्ट्स, टूल एक्सेस, फ़ाइन-ट्यूनिंग या मॉडल को दूसरे सिस्टम्स के साथ जोड़ने से उसकी क्षमताएँ बढ़ सकती हैं। इसके अलावा, इवैल्यूएशन में सिर्फ़ वही टास्क शामिल होते हैं जो टेस्ट करने वालों के दिमाग में आए हों, और हो सकता है कि मॉडल को जब यह लगे कि उसकी टेस्टिंग हो रही है तो वह अलग तरह से पेश आए। इसीलिए लैब्स किसी भी बदलाव के बाद दोबारा इवैल्यूएशन करती हैं और नतीजों को उस समय का एक सबूत मानती हैं, न कि कोई हमेशा के लिए पक्की गारंटी।

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

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

सिस्टम को हर उस चीज़ से मना करने के लिए ही क्यों न सेट कर दें जो जोखिम भरी लगती है?

क्योंकि ऐसा करने से वैध ज़रूरतों वाले कई असली यूज़र्स निराश होंगे: नर्सें, शिक्षक, सुरक्षा स्टाफ़, छात्र। यह यूज़र्स को यह भी सिखाता है कि सिस्टम पूरे के पूरे विषयों के लिए बेकार है। अच्छी सुरक्षा का मतलब सटीक मनाही है, आंख मूंदकर की गई मनाही नहीं।

क्या मैं सुरक्षा आउटपुट को ग्रेड करने के लिए LLM जज का इस्तेमाल कर सकता हूँ?

हाँ, बड़े पैमाने पर जांच करने के लिए, एक स्पष्ट नियम-पुस्तिका के साथ: क्या इसने मना किया, क्या इसने नुक़सानदेह बारीकियां दीं, क्या इसने सुरक्षित अनुरोध का जवाब दिया। पहले इंसानी समीक्षकों के साथ इसका तालमेल बिठाएं (calibrate करें), और बहुत गंभीर मामलों और बाकी में से कुछ नमूनों की जांच इंसानों से करवाएं।

क्या प्रोडक्ट टीमों को dangerous capability evals चलाने चाहिए?

आमतौर पर नहीं। वे फ्रंटियर मॉडल्स विकसित करने वाली टीमों के लिए होते हैं, जिनमें खास विशेषज्ञ और कड़े नियंत्रण होते हैं। प्रोडक्ट टीमों को अपने खुद के प्रोडक्ट के जोखिमों पर ध्यान देना चाहिए, और मॉडल प्रदाताओं द्वारा प्रकाशित सुरक्षा रिपोर्ट पढ़नी चाहिए।

क्या मेरे red-team सेट पर शून्य unsafe-output rate इस बात का सबूत है कि सिस्टम सुरक्षित है?

नहीं। यह केवल यह दिखाता है कि सिस्टम ने उन मामलों को संभाल लिया जिनके बारे में आपने सोचा था। हमलावर उन चीज़ों की कोशिश करेंगे जिनका आपने परीक्षण नहीं किया। नए केस जोड़ते रहें, नियमित रूप से red-team अभ्यास करें, और कोड में कड़े नियंत्रण बनाए रखें, जैसे अनुमतियां (permissions) और सीमाएं, जो मॉडल के मना करने पर निर्भर नहीं होते।

पाठ का टेस्ट

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

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