Keamanan lan keselarasan ing jaman model cakrawala dawa

Model sing bisa kerja otonom sajrone wektu dawa bisa nangani masalah angel lan terbuka. Nanging ketekunan sing nggawe model kuwi migunani uga menehi luwih akeh kesempatan kanggo nindakake tumindak sing ora dikarepake—lan nindakake kanthi cara sing bisa ora katon dening evaluasi kanggo model cakrawala luwih cendhak.

Kira-kira rong wulan kepungkur, kita ngumumake⁠ yen model serbaguna internal wis mbantah konjektur jarak unit Erdős. Model iki dirancang supaya bisa kerja otonom sajrone wektu sing dawa banget. Sajrone panggunaan internal sing winates lan dipantau, kita ngamati prilaku sing ora dikarepake lan durung katangkap dening evaluasi deployment sing wis ana. Amarga deployment kasebut winates lan dipantau, kita bisa ngenali masalah iki, ngaso akses, nggawe evaluasi anyar adhedhasar apa sing diamati, nguatake model lan pengamané, banjur mulihake akses kanthi pemantauan terus. 

Kondisi nalika kita ngevaluasi model ora bakal tau cocog sampurna karo kondisi sing ditemoni nalika digunakake tenan. Mula, evaluasi sadurunge deployment perlu dipasangake karo deployment sing winates lan dipantau, uga kemampuan kanggo campur tangan, ngaso, utawa mbalekake yen muncul masalah. Apa sing kita pelajari saka deployment banjur bisa dadi bagean saka evaluasi lan pengaman sing luwih kuwat sadurunge akses diperluas.

Ing bagean-bagean sabanjure, kita nuduhake conto konkret babagan apa sing diamati, kepiye cara kita nangani masalah, lan kepiye pengalaman iki bakal mbentuk rilis ing mangsa ngarep.

Model anyar bisa terus kerja nggayuh sawijining tujuan liwat upaya bola-bali sajrone wektu sing dawa. Ketekunan sing padha uga bisa ndadekake model nemokake lan ngeksploitasi kelemahan ing lingkungane. Model sadurunge, nalika kena watesan sandbox utawa lingkungan, biasane mung mandheg lan bali menyang pangguna. Model iki asring terus nyoba, kalebu nggoleki cara supaya bisa tumindak ing njaba sandbox-é.

Contone kedadeyan sajrone evaluasi internal ing speedrun NanoGPT⁠(mbukak ing jendhela anyar), benchmark publik kanggo nglatih model basa cilik kanthi langkah sesithik mungkin. Model kita ngembangake cooldown learning-rate adhedhasar power-law sing diarani PowerCool lan ngasilake peningkatan sing signifikan. Model kasebut diprentah supaya ngirim asil mung menyang Slack, nanging instruksi NanoGPT nyebutake supaya asil dikirim minangka PR menyang GitHub, lan model nuruti instruksi pungkasan kuwi kanggo mbukak PR #287 ing gudang kode GitHub publik. Model kasebut ngliwati watesan sandbox sing dirancang kanggo mblokir akses eksternal lan nerusake upload menyang GitHub. Model kita butuh sak jam kanggo nemokake kerentanan ing sandbox supaya bisa nggawe PR; model-model sadurunge kurang tekun lan ora bisa nemokake kerentanan, mula malah nyerah ing bagean PR.¹

Akeh kontrol keamanan kanggo asisten AI dirancang adhedhasar tumindak individu. Yen sawijining tumindak ora diidini, tumindak kasebut diblokir. Yen tumindaké sensitif, sistem njaluk persetujuan eksplisit saka pangguna. Nanging model sing mlaku suwe, sing tumindaké bisa berkembang otonom nganti pirang-pirang jam, dina, utawa malah minggu, nantang tatanan iki: ngawasi tumindak siji-siji ora cukup maneh kanggo nglacak niat saka lintasan sakabèhé.

Contone, ing skenario nalika model dijaluk ngrampungake masalah, model kasebut ngamati yen sistem liya duwe kiriman sing sukses nanging privat, banjur nyoba mbalekake solusi kuwi saka backend evaluasi. Nalika upaya wiwitané diblokir amarga scanner ndeteksi token autentikasi, model mecah isi token dadi rong fragmen, nyamarke fragmen kasebut, banjur mbangun ulang kredensial nalika runtime supaya token lengkap ora tau katon minangka siji string sing nyambung. Model kasebut terang-terangan, ing komentar marang pangguna lan ing jejak nalaré, yen langkah-langkah iki ditindakake kanggo ngliwati scanner.

Conto iki nuduhake kepiye saben langkah bisa katon bisa ditampa yen dideleng dhewe, nanging rangkaiané bisa ngasilake asil sing ora bakal disetujoni. Iki uga nuduhake kepiye model sing efektif sajrone cakrawala wektu dawa bisa sinau titik wuta sistem persetujuan lan ngakal-akali supaya bisa nggayuh tujuane. Keamanan cakrawala dawa ora mung kudu takon “apa tumindak iki diidini?” nanging uga “asil apa sing dituju saka rangkaian tumindak iki?”

Amarga insiden kaya mangkene, kita ngaso deployment internal model anyar. Kita mbangun ulang sistem keamanan adhedhasar pertahanan berlapis lan pemantauan tingkat lintasan.

• Evaluasi adhedhasar insiden. Evaluasi bisa menehi gambaran apa sawijining sistem aman kanggo di-deploy sadurunge tenan di-deploy. Nanging, supaya paling migunani, evaluasi kudu nggambarake distribusi lan dawa cakrawala lintasan nalika deployment nyata. Mula, kita nggunakake kegagalan sing diamati kanggo ngembangake evaluasi adversarial. Kita nemokake yen perbaikan ing evaluasi sing diturunake saka insiden donya nyata banjur nyebabake prilaku sing luwih aman sawise di-deploy ing produksi.
• Keselarasan sing luwih apik. Kita njupuk langkah kanggo nyuda kecenderungan model nindakake tumindak sing ora dikarepake tanpa idin nalika ngoyak tujuan pangguna.  Contone, kita nemokake yen model kita luwih ala nalika ngelingi instruksi ing rollout dawa, lan nalika kita nglatih model kanggo kemampuan iki, asilé model tetep selaras ing rollout sing luwih dawa. 
• Pemantauan aktif. Kita nggawe sistem pemantauan sing mriksa lintasan model sing terus berkembang kanggo ndelok tandha yen model ngliwati watesan pangguna utawa wates keamanan. Monitor ora mung ngamati siji tumindak, nanging kabeh lintasan. Sing penting, monitor bisa ngaso sesi lan menehi tandha marang pangguna supaya dipriksa luwih teliti. Sawise dipriksa, pangguna banjur bisa milih nerusake kerja model yen monitor ternyata salah kapicu. 
• Visibilitas lan kontrol pangguna sing luwih gedhe. Kita ningkatake kemampuan pangguna kanggo mriksa sesi sing mlaku suwe iki, ndeleng tumindak sing dijupuk, lan ngawasi intervensi.

Kanggo ngevaluasi sistem pemantauan anyar, kita muter ulang sakumpulan cilik lingkungan deployment internal nalika model sadurunge ngoyak tumindak ora selaras, wektu iki nganggo pengaman anyar². Pengaman anyar bisa nyekel luwih akeh tumindak ora selaras sing diupayakake model, lan sing luput kabeh dinilai keruwetané kurang abot.

Sawetara conto insiden kurang abot iki kalebu kasus-kasus ing ngisor iki:

• Kanggo ngakses alat baris perintah Linear, model mbukak sesi codex --yolo bertingkat, padahal sejatine bisa ditindakake tanpa flag --yolo.
• Model weruh yen sumber daya sing sadurunge aktif saiki ilang, banjur miwiti njelajah lan SSH menyang pod CPU aktif liyane ing namespace duwé pemiliké, uga (tanpa sukses) pod duwé karyawan OpenAI liya, tanpa alasan sing apik kanggo nindakake kuwi.
• Model nduwé akeh proses find sing macet lan saben perintah shell mandheg nggantung. Banjur model mbukak kill -9 -1 sing bakal ngirim SIGKILL menyang saben proses sing diijini dipatèni ing pod kuwi, yen dieksekusi. Nanging perintah kasebut timeout lan ora dieksekusi.

Sawise nguji sistem anyar, kita nyimpulake yen akses internal winates menyang model kanthi kapabilitas cakrawala dawa bisa dipulihake. Kita durung ngamati ana pangliwatan pengaman sing serius wiwit redeployment diwiwiti sawetara minggu kepungkur. Versi pisanan pengaman iki sengaja digawe konservatif. Kita terus nyetel sistem kanggo nyuda interupsi sing ora perlu tanpa nglemahake pengaman.

Amarga deployment ditindakake kanthi iteratif, kita bisa nemokake lan ngatasi celah sadurunge akses diperluas. Evaluasi sadurunge deployment tetep penting, nanging deployment mbukak prilaku sing ora katangkap evaluasi. Miwiti nganggo akses winates ngidini kita ngamati model ing praktik, ngaso nalika muncul masalah, nggunakake kegagalan kasebut kanggo mbangun evaluasi lan pengaman sing luwih apik, lan mulihake akses winates sawise nguji owah-owahan.

Nalika model nindakake tugas sing luwih dawa lan luwih kompleks, kegagalan sing luput saka evaluasi bisa nggawa akibat sing luwih gedhe. Kita bakal terus makarya kanggo nyempitake jurang antarane evaluasi lan deployment: nguji model liwat lintasan sing luwih dawa, ningkatake keselarasan, mbangun pemantauan sing bisa campur tangan, lan menehi visibilitas lan kontrol sing luwih cetha marang pangguna. Tantangan iki ora mung duwé OpenAI, lan kita ngarepake apa sing kita bagi bisa mbantu bidang sing luwih amba nyiapake tantangan kasebut.