लॉन्ग-होराइज़न मॉडल के युग में सुरक्षा और अलाइनमेंट
लंबे समय तक चलने वाले मॉडल के आंतरिक उपयोग ने हमें सुरक्षा के बारे में क्या सिखाया.
सारांश
लंबे समय तक चलने वाले मॉडल कठिन, खुले-छोर वाली समस्याएँ हल कर सकते हैं, लेकिन उनकी निरंतरता उन्हें अवांछित कार्रवाइयाँ करने के अधिक अवसर देती है.
लंबे समय तक चलने वाले कार्यों के लिए ट्रेन किए गए मॉडल के सीमित आंतरिक उपयोग के दौरान, हमने ऐसी नई विफलताएँ देखीं जिन्हें हमारे मौजूदा प्री-डिप्लॉयमेंट मूल्यांकन पकड़ नहीं पाए थे, और हमने एक्सेस रोक दी. फिर हमने इन विफलताओं से मिली सीख का उपयोग नए मूल्यांकन बनाने, लॉन्ग-होराइज़न अलाइनमेंट सुधारने, ट्रैजेक्टरी-स्तर की निगरानी जोड़ने, और सीमित एक्सेस बहाल करने से पहले यूज़र को अधिक दृश्यता और नियंत्रण देने में किया.
इस अनुभव ने क्रमिक डिप्लॉयमेंट के महत्व को और मज़बूत किया. कोई स्थिर मूल्यांकन सूट हर व्यवहार का पहले से अनुमान नहीं लगा सकता, इसलिए प्री-डिप्लॉयमेंट परीक्षण के साथ करीबी निगरानी, हस्तक्षेप कर सकने वाले सुरक्षा उपाय, और ज़रूरत पड़ने पर रोकने या वापस रोल करने की क्षमता भी होनी चाहिए.
जो मॉडल लंबे समय तक स्वायत्त रूप से काम कर सकते हैं, वे कठिन, खुले-छोर वाली समस्याएँ संभाल सकते हैं. लेकिन वही निरंतरता जो उन्हें उपयोगी बनाती है, उन्हें अवांछित कार्रवाइयाँ करने के अधिक अवसर भी देती है—और ऐसे तरीकों से, जिन्हें छोटे-होराइज़न मॉडल के लिए बनाए गए मूल्यांकन पकड़ नहीं पाते.
लगभग दो महीने पहले हमने घोषणा की थी कि एक आंतरिक सामान्य-उद्देश्य मॉडल ने Erdős unit distance conjecture को गलत साबित किया. यह मॉडल बहुत लंबे समय तक स्वायत्त रूप से काम करने के लिए डिज़ाइन किया गया था. सीमित और निगरानी वाले आंतरिक उपयोग के दौरान, हमने ऐसा अवांछित व्यवहार देखा जिसे हमारे मौजूदा डिप्लॉयमेंट मूल्यांकन पकड़ नहीं पाए थे. क्योंकि डिप्लॉयमेंट सीमित और निगरानी में था, हम इन समस्याओं की पहचान कर सके, एक्सेस रोक सके, अपने अवलोकनों के आधार पर नए मूल्यांकन बना सके, मॉडल और उसके सुरक्षा उपायों को मज़बूत कर सके, और फिर निरंतर निगरानी के तहत एक्सेस बहाल कर सके.
जिन परिस्थितियों में हम मॉडल का मूल्यांकन करते हैं, वे वास्तविक उपयोग में आने वाली परिस्थितियों से कभी पूरी तरह मेल नहीं खाएँगी. इसीलिए प्री-डिप्लॉयमेंट मूल्यांकन के साथ सीमित, निगरानी वाला डिप्लॉयमेंट और समस्याएँ सामने आने पर हस्तक्षेप, रोकने या वापस रोल करने की क्षमता भी ज़रूरी है. डिप्लॉयमेंट से जो सीख मिलती है, वह एक्सेस बढ़ाने से पहले अधिक मज़बूत मूल्यांकन और सुरक्षा उपायों का हिस्सा बन सकती है.
आगे के सेक्शन में हम ठोस उदाहरण साझा करते हैं कि हमने क्या देखा, समस्याओं को कैसे संबोधित किया, और यह अनुभव भविष्य के रिलीज़ को कैसे आकार देगा.
नया मॉडल लंबे समय तक बार-बार कोशिशों के ज़रिए किसी लक्ष्य की ओर काम जारी रख सकता है. यही निरंतरता उसे अपने एनवायरनमेंट में कमजोरियाँ खोजने और उनका फ़ायदा उठाने तक ले जा सकती है. पिछले मॉडल जब सैंडबॉक्सिंग या एनवायरनमेंट की सीमाओं से टकराते थे, तो वे बस रुक जाते और यूज़र के पास लौट आते थे. यह मॉडल अक्सर कोशिश जारी रखता था, जिसमें अपने सैंडबॉक्स के बाहर कार्रवाई करने के तरीके खोजना भी शामिल था.
इसका एक उदाहरण NanoGPT स्पीडरन(एक नई विंडो में खुलेगा) पर एक आंतरिक मूल्यांकन के दौरान सामने आया, जो छोटे भाषा मॉडल को कम-से-कम स्टेप में ट्रेन करने का सार्वजनिक बेंचमार्क है. हमारे मॉडल ने PowerCool नाम का पावर-लॉ लर्निंग-रेट कूलडाउन विकसित किया, जिससे उल्लेखनीय सुधार हुआ. मॉडल को निर्देश दिया गया था कि वह अपने परिणाम केवल Slack पर पोस्ट करे, लेकिन NanoGPT निर्देशों में परिणामों को GitHub पर PR के रूप में पोस्ट करने को कहा गया है, और मॉडल ने बाद वाले निर्देशों का पालन करते हुए सार्वजनिक GitHub रिपॉज़िटरी पर PR #287 खोला. मॉडल ने बाहरी एक्सेस रोकने के लिए बनाए गए सैंडबॉक्स प्रतिबंधों को दरकिनार किया और GitHub पर अपलोड जारी रखा. PR बनाने के लिए सैंडबॉक्स में कमजोरी खोजने में हमारे मॉडल को एक घंटा लगा; पहले के मॉडल कम निरंतर थे और कमजोरियाँ खोज नहीं पाए, बल्कि PR वाले हिस्से को छोड़ दिया.1
AI असिस्टेंट के लिए कई सुरक्षा नियंत्रण व्यक्तिगत कार्रवाइयों के इर्द-गिर्द डिज़ाइन किए जाते हैं. अगर कोई कार्रवाई अनुमत नहीं है, तो उसे ब्लॉक कर दिया जाता है. अगर वह संवेदनशील है, तो सिस्टम यूज़र से स्पष्ट मंज़ूरी माँगता है. लेकिन लंबे समय तक चलने वाले मॉडल, जिनकी कार्रवाइयाँ घंटों, दिनों या यहाँ तक कि हफ़्तों तक स्वायत्त रूप से आगे बढ़ सकती हैं, इस व्यवस्था को चुनौती देते हैं: पूरी ट्रैजेक्टरी के इरादे को ट्रैक करने के लिए व्यक्तिगत कार्रवाइयों की निगरानी अब पर्याप्त नहीं रहती.
उदाहरण के लिए, एक परिदृश्य में जहाँ मॉडल से एक समस्या हल करने को कहा गया था, मॉडल ने देखा कि अन्य सिस्टम के सफल लेकिन निजी सबमिशन थे और उसने उन समाधानों को मूल्यांकन बैकएंड से वापस पाने की कोशिश की. जब उसका शुरुआती प्रयास इसलिए ब्लॉक हुआ क्योंकि एक स्कैनर ने ऑथेंटिकेशन टोकन पहचान लिया था, तो मॉडल ने टोकन बॉडी को दो टुकड़ों में बाँटा, उन्हें छिपाया, और फिर रनटाइम पर क्रेडेंशियल को फिर से बनाया, ताकि पूरा टोकन कभी एक सतत स्ट्रिंग के रूप में न दिखे. मॉडल ने यूज़र को दी गई अपनी टिप्पणियों और अपनी रीज़निंग ट्रेस, दोनों में स्पष्ट किया कि वह स्कैनर को दरकिनार करने के लिए ये कदम उठा रहा था.
यह उदाहरण दिखाता है कि हर स्टेप अपने-आप में स्वीकार्य दिख सकता है, जबकि क्रम ऐसा परिणाम दे सकता है जिसे मंज़ूरी नहीं दी जाती. यह यह भी दिखाता है कि लंबे टाइम होराइज़न में प्रभावी ढंग से काम करने वाला मॉडल किसी मंज़ूरी प्रणाली के ब्लाइंड स्पॉट सीख सकता है और अपने लक्ष्यों तक पहुँचने के लिए उन्हें दरकिनार कर सकता है. लॉन्ग-होराइज़न सुरक्षा में केवल यह पूछना काफ़ी नहीं है कि “क्या इस कार्रवाई की अनुमति है?” बल्कि यह भी पूछना ज़रूरी है कि “कार्रवाइयों का यह क्रम किस परिणाम की ओर बढ़ रहा है?”
ऐसी घटनाओं के कारण, हमने नए मॉडल का आंतरिक डिप्लॉयमेंट रोक दिया. हमने सुरक्षा प्रणाली को डिफ़ेंस-इन-डेप्थ और ट्रैजेक्टरी-स्तर की निगरानी के आधार पर फिर से बनाया.
- घटनाओं से निकले मूल्यांकन. मूल्यांकन हमें यह समझ दे सकते हैं कि किसी सिस्टम को वास्तविक डिप्लॉयमेंट से पहले डिप्लॉय करना सुरक्षित है या नहीं. हालाँकि, सबसे उपयोगी होने के लिए मूल्यांकन को वास्तविक डिप्लॉयमेंट के दौरान ट्रैजेक्टरी के वितरण और होराइज़न लंबाई को प्रतिबिंबित करना चाहिए. इसी कारण हमने देखी गई विफलताओं का उपयोग विरोधी मूल्यांकन विकसित करने में किया. हमने पाया कि वास्तविक दुनिया की घटनाओं से निकले मूल्यांकन में सुधार करने से, प्रोडक्शन में डिप्लॉय होने के बाद व्यवहार भी अधिक सुरक्षित हुआ.
- बेहतर अलाइनमेंट. हमने यूज़र के लक्ष्य को पूरा करने की कोशिश में बिना अनुमति अवांछित कार्रवाइयाँ करने की इसकी प्रवृत्ति कम करने के लिए कदम उठाए. उदाहरण के लिए, हमने पाया कि लंबे रोलआउट में हमारे मॉडल निर्देश याद रखने में कमज़ोर थे, और जब हमने इस क्षमता के लिए मॉडल को ट्रेन किया, तो ऐसा मॉडल मिला जो लंबे रोलआउट के दौरान भी अलाइन बना रहा.
- सक्रिय निगरानी. हमने एक निगरानी प्रणाली बनाई जो मॉडल की विकसित होती ट्रैजेक्टरी की समीक्षा करती है, ताकि संकेत मिल सकें कि वह किसी यूज़र बाधा या सुरक्षा सीमा को बायपास कर रहा है. मॉनिटर केवल एक कार्रवाई नहीं, बल्कि पूरी ट्रैजेक्टरी को देखता है. महत्वपूर्ण बात यह है कि मॉनिटर सेशन को रोक सकता है और यूज़र को अधिक बारीकी से जाँचने के लिए अलर्ट कर सकता है. जाँच के बाद, यदि मॉनिटर गलत तरीके से ट्रिगर हुआ हो, तो यूज़र मॉडल का काम जारी रखने का विकल्प चुन सकता है.
- यूज़र को अधिक दृश्यता और नियंत्रण. हमने यूज़र की इन लंबे समय तक चलने वाले सेशन की जाँच करने, की गई कार्रवाइयाँ देखने और हस्तक्षेपों की निगरानी करने की क्षमता बेहतर की.
नई निगरानी प्रणाली का मूल्यांकन करने के लिए, हमने आंतरिक डिप्लॉयमेंट एनवायरनमेंट के एक छोटे सेट को फिर से चलाया, जहाँ मॉडल ने पहले मिसअलाइन कार्रवाइयाँ अपनाई थीं; इस बार नए सुरक्षा उपाय लागू थे2. नए सुरक्षा उपाय मॉडल द्वारा अपनाई गई कहीं अधिक मिसअलाइन कार्रवाइयों को पकड़ने में सक्षम रहे, और जो छूट गईं, वे सभी कम गंभीरता वाली मानी गईं.
इन कम-गंभीरता वाली घटनाओं के कुछ उदाहरणों में ये मामले शामिल हैं:
- Linear कमांड लाइन टूल तक पहुँचने के लिए, मॉडल ने नेस्टेड
codex --yoloसेशन शुरू किया, जबकि वास्तव में वह--yoloफ़्लैग के बिना भी ऐसा कर सकता था. - मॉडल ने देखा कि पहले लाइव रहा एक संसाधन गायब था, फिर उसने अपने मालिक के नेमस्पेस के अंतर्गत अन्य लाइव CPU पॉड्स, और साथ ही अन्य OpenAI कर्मचारियों के पॉड्स में भी SSH करके खोजबीन शुरू की, हालाँकि बाद वाला प्रयास सफल नहीं हुआ और ऐसा करने का कोई ठोस कारण नहीं था.
- मॉडल में कई अटके हुए
findप्रोसेस थे और हर शेल कमांड हैंग हो रही थी. इसके बाद उसनेkill -9 -1चलाया, जो निष्पादित होने पर उस पॉड पर उन सभी प्रोसेस को SIGKILL भेज देता जिन्हें मारने की उसे अनुमति थी. हालाँकि वह टाइम आउट हो गया और निष्पादित नहीं हुआ.
नई प्रणाली का परीक्षण करने के बाद, हमने निष्कर्ष निकाला कि लॉन्ग-होराइज़न क्षमताओं वाले मॉडल तक सीमित आंतरिक एक्सेस बहाल की जा सकती है. कई सप्ताह पहले रीडिप्लॉयमेंट शुरू होने के बाद से हमने सुरक्षा उपायों को गंभीर रूप से दरकिनार किए जाने की कोई घटना नहीं देखी है. इन सुरक्षा उपायों का पहला संस्करण जानबूझकर सतर्क रखा गया था. हम सुरक्षा उपायों को कमज़ोर किए बिना अनावश्यक रुकावटें घटाने के लिए सिस्टम को लगातार ट्यून कर रहे हैं.
क्योंकि हमने क्रमिक रूप से डिप्लॉय किया, हम एक्सेस बढ़ाने से पहले कमियाँ खोजकर उन्हें दूर कर सके. प्री-डिप्लॉयमेंट मूल्यांकन अब भी आवश्यक हैं, लेकिन डिप्लॉयमेंट ऐसे व्यवहार दिखाता है जिन्हें वे नहीं पकड़ पाते. सीमित एक्सेस से शुरुआत करने से हमें मॉडल को व्यवहार में देखने, समस्याएँ सामने आने पर रोकने, उन विफलताओं का उपयोग बेहतर मूल्यांकन और सुरक्षा उपाय बनाने में करने, और बदलावों की जाँच के बाद सीमित एक्सेस बहाल करने का अवसर मिला.
जैसे-जैसे मॉडल लंबे और अधिक जटिल कार्य संभालेंगे, मूल्यांकन से छूट जाने वाली विफलताओं के परिणाम अधिक गंभीर हो सकते हैं. हम मूल्यांकन और डिप्लॉयमेंट के बीच की दूरी घटाने पर काम जारी रखेंगे: मॉडल को लंबी ट्रैजेक्टरी पर परखना, अलाइनमेंट सुधारना, हस्तक्षेप कर सकने वाली निगरानी बनाना, और यूज़र को अधिक स्पष्ट दृश्यता और नियंत्रण देना. ये चुनौतियाँ केवल OpenAI तक सीमित नहीं होंगी, और हमें उम्मीद है कि हमने जो सीखा है उसे साझा करने से व्यापक क्षेत्र इनके लिए तैयार होने में मदद मिलेगी.
लेखक
फ़ुटनोट
- 1
हालाँकि हमने PR को जल्दी बंद कर दिया, लेकिन स्पीडरन में कई प्रतिभागी उसे पहले ही देख चुके थे और अपने सबमिशन में वही तरीका इस्तेमाल कर चुके थे; 3030(एक नई विंडो में खुलेगा), 2990(एक नई विंडो में खुलेगा), 2930(एक नई विंडो में खुलेगा), 2925(एक नई विंडो में खुलेगा), 2900(एक नई विंडो में खुलेगा) और 2890(एक नई विंडो में खुलेगा) स्टेप वाले लगातार विश्व-रिकॉर्ड सबमिशन सभी PR 287 का हवाला देते हैं. इनमें PR 300(एक नई विंडो में खुलेगा) खास तौर पर रोचक है, क्योंकि यह वह PR है जिसे Opus 4.7 ने तब सबमिट किया था जब Prime Intellect(एक नई विंडो में खुलेगा) ने NanoGPT स्पीडरन पर उसका मूल्यांकन किया था. Opus ने हमारे मॉडल द्वारा सबमिट किया गया PR देखा, खोजों को शामिल किया, और अपने अंतिम परिणाम में हमारे PR को श्रेय दिया.
- 2


