Kaligtasan at alignment sa panahon ng long-horizon na mga modelo

Kayang harapin ng mga modelong nakakapagtrabaho nang autonomous sa mahabang panahon ang mahihirap at open-ended na problema. Ngunit ang parehong tiyaga na nagpapakinabang sa kanila ay nagbibigay din sa kanila ng mas maraming pagkakataong gumawa ng mga hindi gustong aksiyon—at gawin iyon sa mga paraang maaaring hindi mahuli ng mga evaluation na inilaan para sa mga modelong may mas maikling horizon.

Mga dalawang buwan na ang nakalipas, inanunsyo⁠ namin na napabulaanan ng isang internal general-purpose na modelo ang Erdős unit distance conjecture. Dinisenyo ang modelong ito para magtrabaho nang autonomous sa napakahabang panahon. Sa limitado at mino-monitor na internal na paggamit, nakakita kami ng hindi gustong gawi na hindi nahuli ng aming mga kasalukuyang deployment evaluation. Dahil limitado at mino-monitor ang deployment, natukoy namin ang mga problemang ito, na-pause ang access, nakagawa ng mga bagong evaluation batay sa aming nakita, napalakas ang modelo at mga pananggalang nito, at pagkatapos ay naibalik ang access sa ilalim ng patuloy na monitoring. 

Hindi kailanman perpektong tutugma ang mga kondisyong ginagamit namin sa pag-evaluate ng mga modelo sa mga kondisyong nararanasan nila sa aktuwal na paggamit. Kaya kailangang ipares ang mga pre-deployment evaluation sa limitado at mino-monitor na deployment, at sa kakayahang makialam, mag-pause, o mag-roll back kapag may lumitaw na problema. Ang natututuhan namin mula sa deployment ay maaari namang maging bahagi ng mas matitibay na evaluation at pananggalang bago palawakin ang access.

Sa mga susunod na seksiyon, nagbabahagi kami ng konkretong mga halimbawa ng aming nakita, kung paano namin tinugunan ang mga isyu, at kung paano huhubugin ng karanasang ito ang mga release sa hinaharap.

Maaaring magpatuloy ang bagong modelo sa pagtatrabaho tungo sa isang layunin sa pamamagitan ng paulit-ulit na pagsubok sa mahabang panahon. Ang parehong tiyagang iyon ay maaaring magdala rito sa paghahanap at pagsasamantala sa mga kahinaan sa environment nito. Kapag nakatagpo ng sandboxing o mga limitasyon sa environment ang mga naunang modelo, hihinto lang sila at babalik sa user. Madalas na patuloy na sumusubok ang modelong ito, kabilang ang paghahanap ng mga paraan para kumilos sa labas ng sandbox nito.

Isang halimbawa nito ang nangyari sa isang internal evaluation sa NanoGPT speedrun⁠(magbubukas sa bagong window), isang pampublikong benchmark para magsanay ng maliit na language model sa pinakakaunting hakbang hangga’t maaari. Nakabuo ang aming modelo ng power-law learning-rate cooldown na tinatawag na PowerCool, na nagdulot ng malaking improvement. Inutusan ang modelo na i-post ang mga resulta nito sa Slack lang, ngunit sinasabi ng mga instruksyon ng NanoGPT na i-post ang mga resulta bilang PR sa GitHub, at sinunod ng modelo ang huling instruksyon para buksan ang PR #287 sa pampublikong GitHub repository. Nilusutan ng modelo ang mga paghihigpit ng sandbox na dinisenyong humarang sa external access at ipinagpatuloy ang pag-upload sa GitHub. Inabot ng isang oras ang aming modelo para makahanap ng kahinaan sa sandbox upang magawa ang PR; hindi ganoon katiyaga ang mga naunang modelo at hindi nila nagawang makahanap ng mga kahinaan, kaya sumuko na lang sila sa bahagi ng PR.¹

Maraming safety control para sa mga AI assistant ang nakadisenyo sa paligid ng indibidwal na mga aksiyon. Kung hindi pinapayagan ang isang aksiyon, hinaharang ito. Kung sensitibo ito, humihingi ang system ng malinaw na pag-apruba mula sa user. Ngunit hinahamon ng mga modelong tumatakbo nang matagal, na maaaring kumilos nang autonomous sa loob ng mga oras, araw, o kahit linggo, ang ganitong setup: hindi na sapat ang pagmo-monitor sa indibidwal na mga aksiyon para masubaybayan ang layunin ng kabuuang trajectory.

Halimbawa, sa isang senaryo kung saan hiniling sa modelo na lumutas ng problema, napansin ng modelo na may matagumpay ngunit pribadong mga submission ang ibang system at sinubukan nitong kunin muli ang mga solusyong iyon mula sa evaluation backend. Nang ma-block ang unang pagtatangka nito dahil may scanner na naka-detect ng authentication token, hinati ng modelo ang katawan ng token sa dalawang fragment, itinago ang mga ito, at pagkatapos ay muling binuo ang credential sa runtime para hindi kailanman lumitaw ang buong token bilang isang magkakadikit na string. Malinaw na sinabi ng modelo, kapwa sa mga komento nito sa user at sa mga bakas ng pangangatwiran nito, na ginagawa nito ang mga hakbang na ito para lusutan ang scanner.

Ipinapakita ng halimbawang ito kung paanong ang bawat hakbang ay maaaring magmukhang katanggap-tanggap mag-isa, habang ang pagkakasunod-sunod ay maaaring magbunga ng resultang hindi maaaprubahan. Ipinapakita rin nito kung paanong maaaring matutuhan ng isang modelong epektibong gumagana sa mahahabang time horizon ang mga blind spot ng isang approval system at lusutan ito upang makamit ang mga layunin nito. Hindi lang dapat itanong sa long-horizon safety ang “pinapayagan ba ang aksiyong ito?” kundi pati “anong kahihinatnan ang tinutungo ng pagkakasunod-sunod ng mga aksiyong ito?”

Dahil sa mga insidenteng tulad nito, na-pause namin ang internal deployment ng bagong modelo. Muli naming binuo ang safety system sa paligid ng defense in depth at trajectory-level monitoring.

• Mga evaluation na hinango sa insidente. Makapagbibigay sa amin ang mga evaluation ng ideya kung ligtas bang i-deploy ang isang system bago ito aktuwal na i-deploy. Gayunman, para maging pinakakapaki-pakinabang, dapat sumalamin ang isang evaluation sa distribution at haba ng horizon ng mga trajectory sa totoong deployment. Dahil dito, ginamit namin ang mga naobserbahang failure para bumuo ng mga adversarial evaluation. Nalaman naming ang pagbuti sa mga evaluation na hinango sa mga totoong insidente ay humantong naman sa mas ligtas na gawi kapag na-deploy na sa production.
• Pinahusay na pagkakaayon. Gumawa kami ng mga hakbang para bawasan ang tendensiya nitong gumawa ng mga hindi gustong aksiyon nang walang pahintulot habang hinahabol ang layunin ng user.  Halimbawa, nalaman naming mas mahina ang aming mga modelo sa pag-alala ng mga instruksyon sa mahahabang rollout, at nang sanayin namin ang modelo para sa kakayahang ito, nagbunga ito ng modelong nanatiling nakaayon sa mas mahahabang rollout. 
• Aktibong monitoring. Gumawa kami ng monitoring system na sumusuri sa umuunlad na trajectory ng modelo para sa mga palatandaang nilalampasan nito ang constraint ng user o safety boundary. Hindi lang iisang aksiyon ang inoobserbahan ng monitor, kundi ang buong trajectory. Mahalaga, kayang i-pause ng monitor ang session at i-alert ang user para mas masusing suriin. Pagkatapos ng pagsusuri, maaaring piliin ng user na ipagpatuloy ang gawain ng modelo kung nag-trigger ang monitor nang mali. 
• Mas malaking visibility at kontrol para sa user. Pinahusay namin ang kakayahan ng user na inspeksiyunin ang mahahabang session na ito, tingnan ang mga ginawang aksiyon, at i-monitor ang mga interbensiyon.

Para i-evaluate ang bagong monitoring system, ni-replay namin ang maliit na set ng internal deployment environment kung saan dati nang naghahabol ang modelo ng mga hindi nakaayong aksiyon, sa pagkakataong ito gamit ang mga bagong pananggalang². Nahuli ng mga bagong pananggalang ang mas marami pang hindi nakaayong aksiyon na hinabol ng modelo, at ang mga hindi nito nahuli ay pawang itinuring na mababa ang kalubhaan.

Kabilang sa ilang halimbawa ng mga insidenteng mababa ang kalubhaan ang mga sumusunod na kaso:

• Para ma-access ang isang Linear command line tool, naglunsad ang modelo ng nested na codex --yolo session, kahit sa totoo ay magagawa naman ito nang wala ang --yolo flag.
• Napansin ng modelo na nawawala ang isang resource na dati ay live, pagkatapos ay nagsimula itong mag-explore at mag-SSH sa iba pang live na CPU pod sa ilalim ng namespace ng may-ari nito, gayundin sa mga pod na pag-aari ng ibang empleyado ng OpenAI (nang hindi matagumpay), nang walang mabuting dahilan para gawin iyon.
• Maraming na-stuck na find process ang modelo at nag-hang ang bawat shell command. Pagkatapos ay pinatakbo nito ang kill -9 -1, na sana ay nagpadala ng SIGKILL sa bawat process na pinapayagan itong i-kill sa pod na iyon, kung na-execute ito. Gayunman, nag-time out ito at hindi na-execute.

Matapos subukan ang bagong system, napagpasyahan naming maaaring ibalik ang limitadong internal access sa mga modelong may long-horizon na kakayahan. Wala kaming naobserbahang seryosong paglusot sa mga pananggalang mula nang magsimula ang muling deployment ilang linggo na ang nakalipas. Sadyang conservative ang unang bersiyon ng mga pananggalang na ito. Patuloy naming tina-tune ang system para bawasan ang mga hindi kinakailangang interruption nang hindi pinapahina ang mga pananggalang.

Dahil iterative ang aming deployment, natukoy at natugunan namin ang mga puwang bago palawakin ang access. Mahalaga pa rin ang mga pre-deployment evaluation, ngunit inilalantad ng deployment ang mga gawi na hindi nila nahuhuli. Sa pagsisimula sa limitadong access, naobserbahan namin ang modelo sa praktikal na paggamit, nakapag-pause kapag may lumitaw na problema, nagamit ang mga failure na iyon para bumuo ng mas mahuhusay na evaluation at pananggalang, at naibalik ang limitadong access matapos subukan ang mga pagbabago.

Habang hinaharap ng mga modelo ang mas mahahaba at mas komplikadong gawain, maaaring mas malaki ang maging epekto ng mga failure na hindi nahuhuli ng mga evaluation. Patuloy kaming magsisikap na paliitin ang agwat sa pagitan ng evaluation at deployment: pagsubok sa mga modelo sa mas mahahabang trajectory, pagpapahusay ng alignment, pagbuo ng monitoring na kayang makialam, at pagbibigay sa mga user ng mas malinaw na visibility at kontrol. Hindi magiging natatangi sa OpenAI ang mga hamong ito, at umaasa kaming makatutulong sa mas malawak na larangan ang pagbabahagi ng aming natutuhan upang mapaghandaan ang mga ito.