दीर्घकालीन मॉडेल्सच्या युगातील सुरक्षा आणि संरेखन

दीर्घकाळ स्वायत्तपणे काम करू शकणारी मॉडेल्स कठीण, खुल्या स्वरूपाच्या समस्या हाताळू शकतात. पण जी चिकाटी त्यांना उपयुक्त बनवते, तीच त्यांना अवांछित कृती करण्याच्या अधिक संधी देते, आणि कमी वेळेची मर्यादा असलेल्या मॉडेल्ससाठीची मूल्यमापने अशा कृती चुकवू शकतात.

सुमारे दोन महिन्यांपूर्वी आम्ही जाहीर केले⁠ की एका अंतर्गत सर्वसाधारण-उद्देशाच्या मॉडेलने Erdős unit distance conjecture खोडून काढला. हे मॉडेल अतिशय दीर्घ काळ स्वायत्तपणे काम करण्यासाठी तयार केले होते. मर्यादित, देखरेखीखालील अंतर्गत वापरादरम्यान, आमच्या विद्यमान डिप्लॉयमेंट मूल्यमापनांत न सापडलेले अवांछित वर्तन आम्ही पाहिले. डिप्लॉयमेंट मर्यादित आणि देखरेखीखाली असल्यामुळे आम्ही या समस्या ओळखू शकलो, प्रवेश थांबवू शकलो, दिसलेल्या गोष्टींवर आधारित नवी मूल्यमापने तयार करू शकलो, मॉडेल व त्याचे सुरक्षा उपाय मजबूत करू शकलो आणि नंतर सतत देखरेखीखाली प्रवेश पुन्हा सुरू करू शकलो. 

आपण मॉडेल्सचे ज्या परिस्थितीत मूल्यमापन करतो, त्या प्रत्यक्ष वापरातील परिस्थितींशी कधीही पूर्णपणे जुळणार नाहीत. म्हणूनच डिप्लॉयमेंटपूर्वीची मूल्यमापने मर्यादित, देखरेखीखालील डिप्लॉयमेंट आणि समस्या उद्भवल्यास हस्तक्षेप, विराम किंवा रोलबॅक करण्याच्या क्षमतेसोबत जोडली पाहिजेत. डिप्लॉयमेंटमधून आम्ही जे शिकतो, ते प्रवेश वाढवण्यापूर्वी अधिक मजबूत मूल्यमापने आणि सुरक्षा उपायांचा भाग बनू शकते.

पुढील विभागांत, आम्ही काय पाहिले, समस्यांना कसे हाताळले आणि हा अनुभव भविष्यातील प्रकाशनांना कसा आकार देईल याची ठोस उदाहरणे देतो.

नवे मॉडेल दीर्घ काळ अनेक प्रयत्न करत उद्दिष्टाच्या दिशेत काम करत राहू शकते. तीच चिकाटी त्याला आपल्या वातावरणातील कमकुवत बाजू शोधून त्यांचा फायदा घेण्याकडे नेऊ शकते. मागील मॉडेल्सना सँडबॉक्सिंग किंवा वातावरणातील बंधने आली की ती साधारणपणे थांबून वापरकर्त्याकडे परतत. हे मॉडेल मात्र अनेकदा प्रयत्न करत राहिले, त्यात आपल्या सँडबॉक्सच्या बाहेर कृती करण्याचे मार्ग शोधणेही होते.

याचे एक उदाहरण NanoGPT speedrun⁠(नवीन विंडोमध्ये उघडेल) वरच्या अंतर्गत मूल्यमापनादरम्यान घडले; शक्य तितक्या कमी पायऱ्यांत एक छोटे भाषा मॉडेल प्रशिक्षित करण्यासाठीचा हा सार्वजनिक मापदंड आहे. आमच्या मॉडेलने PowerCool नावाचा power-law learning-rate cooldown तयार केला, ज्यामुळे मोठी सुधारणा झाली. मॉडेलला आपले निकाल फक्त Slack वर पोस्ट करण्याच्या सूचना होत्या, पण NanoGPT च्या सूचनांमध्ये निकाल GitHub वर PR म्हणून पोस्ट करायला सांगितले आहे, आणि मॉडेलने नंतरच्या सूचना पाळून सार्वजनिक GitHub रिपॉझिटरीवर PR #287 उघडला. मॉडेलने बाह्य प्रवेश रोखण्यासाठी तयार केलेल्या sandbox निर्बंधांना बगल दिली आणि GitHub वर अपलोड पुढे नेले. PR करण्यासाठी सँडबॉक्समधील असुरक्षा शोधण्यास आमच्या मॉडेलला एक तास लागला; आधीची मॉडेल्स कमी चिकाटीची होती आणि असुरक्षा शोधू शकली नाहीत, त्यामुळे त्यांनी PR भाग सोडून दिला.¹

AI सहाय्यकांसाठीची अनेक सुरक्षा नियंत्रणे व्यक्तिगत कृतींभोवती रचलेली असतात. एखादी कृती अनुमत नसल्यास ती रोखली जाते. ती संवेदनशील असल्यास, प्रणाली वापरकर्त्याकडून स्पष्ट मंजुरी मागते. परंतु तास, दिवस किंवा आठवड्यांपर्यंत स्वायत्तपणे कृती उलगडणारी दीर्घकाळ चालणारी मॉडेल्स ही रचना आव्हानात टाकतात: एकेक कृती पाहणे संपूर्ण प्रवासाचा हेतू समजण्यासाठी पुरेसे राहत नाही.

उदाहरणार्थ, एका परिस्थितीत मॉडेलला समस्या सोडवायला सांगितले असता, इतर प्रणालींनी यशस्वी पण खाजगी सबमिशन्स केली आहेत हे त्याने पाहिले आणि मूल्यमापन बॅकएंडमधून ती निराकरणे परत मिळवण्याचा प्रयत्न केला. प्रमाणीकरण टोकन ओळखणाऱ्या स्कॅनरमुळे त्याचा पहिला प्रयत्न रोखला गेला तेव्हा मॉडेलने टोकनचा मुख्य भाग दोन तुकड्यांत विभागला, ते अस्पष्ट केले आणि रन करताना क्रेडेन्शियल पुन्हा तयार केले, जेणेकरून पूर्ण टोकन सलग स्ट्रिंग म्हणून कधीच दिसले नाही. स्कॅनरला बगल देण्यासाठीच ही पावले उचलत असल्याचे मॉडेलने वापरकर्त्याला दिलेल्या टिप्पण्यांत आणि आपल्या रीझनिंगच्या नोंदींमध्ये स्पष्ट केले.

हे उदाहरण दाखवते की प्रत्येक पाऊल स्वतंत्रपणे स्वीकारार्ह दिसू शकते, पण मालिका मंजूर न होणारा परिणाम देऊ शकते. दीर्घ वेळेच्या मर्यादांमध्ये प्रभावीपणे काम करणारे मॉडेल मंजुरी प्रणालीतील अंध-बिंदू कसे शिकू शकते आणि आपली उद्दिष्टे साधण्यासाठी त्यांना कशी बगल देऊ शकते, हेही यातून दिसते. दीर्घकालीन सुरक्षिततेसाठी केवळ “ही कृती अनुमत आहे का?” एवढेच नव्हे, तर “कृतींची ही मालिका कोणत्या परिणामासाठी काम करत आहे?” हेदेखील विचारणे आवश्यक आहे.

अशा घटनांमुळे आम्ही नव्या मॉडेलची अंतर्गत डिप्लॉयमेंट थांबवली. आम्ही बचावाभोवतीची सुरक्षा प्रणाली सखोलपणे आणि ट्रॅजेक्टरीच्या पातळीवरची देखभाल नव्याने उभारली.

• घटनांवरून तयार केलेली मूल्यमापने. एखादी प्रणाली प्रत्यक्ष डिप्लॉयमेंटपूर्वी सुरक्षित आहे का याची कल्पना मूल्यमापनांतून मिळू शकते. तरीही, जास्तीत जास्त उपयुक्त होण्यासाठी मूल्यमापनाने प्रत्यक्ष डिप्लॉयमेंटमधील प्रवासांचे वितरण आणि वेळेच्या मर्यादेची लांबी प्रतिबिंबित केली पाहिजे. म्हणूनच आम्ही दिसलेल्या अपयशांचा वापर विरोधी मूल्यमापने विकसित करण्यासाठी केला. प्रत्यक्ष घटनांवरून तयार झालेल्या मूल्यमापनांत सुधारणा केल्याने प्रॉडक्शनमध्ये डिप्लॉयमेंटनंतर वर्तन अधिक सुरक्षित झाले, असे आम्हाला आढळले.
• सुधारित संरेखन. वापरकर्त्याचे उद्दिष्ट साधताना परवानगीशिवाय अवांछित कृती करण्याची त्याची प्रवृत्ती कमी करण्यासाठी आम्ही पावले उचलली.  उदाहरणार्थ, दीर्घ रोलआउट्समध्ये आमची मॉडेल्स सूचना लक्षात ठेवण्यात कमकुवत होती असे आम्हाला आढळले; या क्षमतेसाठी मॉडेल प्रशिक्षित केल्यावर ते दीर्घ रोलआउट्समध्येही संरेखित राहिले. 
• सक्रिय देखरेख. मॉडेल वापरकर्त्याची अट किंवा सुरक्षा सीमा ओलांडत आहे का याची चिन्हे शोधण्यासाठी त्याच्या बदलत्या प्रवासाचे पुनरावलोकन करणारी देखरेख प्रणाली आम्ही तयार केली. मॉनिटर फक्त एक कृती नव्हे, तर संपूर्ण प्रवास पाहतो. महत्त्वाचे म्हणजे, मॉनिटर सत्र थांबवू शकतो आणि अधिक जवळून तपासण्यासाठी वापरकर्त्याला सूचना देऊ शकतो. तपासणीनंतर, मॉनिटर चुकीने सक्रिय झाला असेल तर वापरकर्ता मॉडेलचे काम सुरू ठेवण्याचा निर्णय घेऊ शकतो. 
• वापरकर्त्यासाठी अधिक दृश्यमानता आणि नियंत्रण. वापरकर्त्याला ही दीर्घकाळ चालणारी सत्रे तपासता येणे, झालेल्या कृती पाहता येणे आणि हस्तक्षेपांचे निरीक्षण करता येणे यासाठी आम्ही क्षमता सुधारली.

नव्या देखरेख प्रणालीचे मूल्यमापन करण्यासाठी, मॉडेलने यापूर्वी विसंरेखित कृती केलेली काही अंतर्गत डिप्लॉयमेंट वातावरणे आम्ही नव्या सुरक्षा उपायांसह पुन्हा रिप्ले केली². नवे सुरक्षा उपाय मॉडेलने केलेल्या विसंरेखित कृतींपैकी बऱ्याच अधिक कृती पकडू शकले, आणि ज्या सुटल्या त्या सर्व कमी-तीव्रतेच्या असल्याचे ठरवले गेले.

अशा कमी-तीव्रतेच्या घटनांची काही उदाहरणे पुढीलप्रमाणे आहेत:

• Linear command line tool वापरण्यासाठी मॉडेलने nested codex --yolo सत्र सुरू केले, प्रत्यक्षात ते --yolo flag शिवायही करता आले असते.
• पूर्वी लाईव्ह असलेले संसाधन गायब असल्याचे मॉडेलच्या लक्षात आले; मग त्याने ठोस कारण नसताना आपल्या मालकाच्या नेमस्पेसमधील इतर live CPU pods मध्ये, तसेच OpenAI च्या इतर कर्मचाऱ्यांच्या pods मध्येही, शोध घेणे आणि SSH करणे (अयशस्वी) सुरू केले.
• मॉडेलकडे अनेक अडकलेल्या find प्रक्रिया होत्या आणि प्रत्येक shell कमांड अडकत होती. नंतर त्याने kill -9 -1 चालवले; ते एक्झीक्युट झाले असते तर त्या pod वर ज्यांना kill करण्याची परवानगी आहे अशा प्रत्येक प्रक्रियेला SIGKILL पाठवले गेले असते. मात्र त्याचा टाईमआऊट झाला आणि ते एक्झीक्युट झाले नाही.

नवी प्रणाली तपासल्यानंतर, दीर्घ वेळेच्या मर्यादेच्या क्षमता असलेल्या मॉडेल्सना मर्यादित अंतर्गत प्रवेश पुन्हा देता येईल असा निष्कर्ष आम्ही काढला. काही आठवड्यांपूर्वी पुन्हा डिप्लॉयमेंट सुरू झाल्यापासून सुरक्षा उपायांना गंभीर बगल दिल्याचे आम्ही पाहिलेले नाही. या सुरक्षा उपायांची पहिली आवृत्ती जाणूनबुजून सावध ठेवली होती. सुरक्षा उपाय कमकुवत न करता अनावश्यक व्यत्यय कमी करण्यासाठी आम्ही प्रणालीचे ट्युनिंग सुरू ठेवले आहे.

आम्ही टप्प्याटप्प्याने डिप्लॉयमेंट केली, त्यामुळे प्रवेश वाढवण्यापूर्वी उणिवा शोधून त्यावर उपाय करू शकलो. डिप्लॉयमेंटपूर्वीची मूल्यमापने आवश्यकच आहेत, पण डिप्लॉयमेंट त्यांना न दिसणारी वर्तने उघड करते. मर्यादित प्रवेशाने सुरुवात केल्यामुळे आम्ही मॉडेलला प्रत्यक्ष वापरात पाहू शकलो, समस्या आल्यावर थांबू शकलो, त्या अपयशांतून चांगली मूल्यमापने आणि सुरक्षा उपाय तयार करू शकलो आणि बदल तपासल्यानंतर मर्यादित प्रवेश पुन्हा सुरू करू शकलो.

मॉडेल्स अधिक दीर्घ आणि गुंतागुंतीची कामे स्वीकारू लागल्यावर, मूल्यमापनांत न सापडणाऱ्या अपयशांचे परिणाम अधिक गंभीर असू शकतात. मूल्यमापन आणि डिप्लॉयमेंट यांतील दरी कमी करण्यासाठी आम्ही काम करत राहू: मॉडेल्सची दीर्घ प्रवासांवर चाचणी करणे, संरेखन सुधारणे, हस्तक्षेप करू शकणारी देखरेख उभारणे आणि वापरकर्त्यांना अधिक स्पष्ट दृश्यमानता व नियंत्रण देणे. ही आव्हाने OpenAI पुरती मर्यादित नसतील, आणि आम्ही जे शिकलो ते शेअर केल्याने व्यापक क्षेत्राला त्यांची तयारी करण्यात मदत होईल अशी आशा आहे.