Siguranța și alinierea în era modelelor cu orizont lung

Modelele care pot lucra autonom perioade lungi pot aborda probleme dificile, deschise. Dar aceeași persistență care le face utile le oferă și mai multe ocazii de a întreprinde acțiuni nedorite — și de a o face în moduri pe care evaluările concepute pentru modele cu orizont mai scurt le pot rata.

În urmă cu aproximativ două luni, am anunțat⁠ că un model intern de uz general a infirmat conjectura lui Erdős privind distanța unitară. Acest model a fost proiectat să lucreze autonom perioade foarte lungi de timp. În timpul unei utilizări interne limitate și monitorizate, am observat comportamente nedorite pe care evaluările noastre existente pentru implementare nu le captaseră. Deoarece implementarea a fost limitată și monitorizată, am putut identifica aceste probleme, suspenda accesul, crea evaluări noi pe baza celor observate, întări modelul și măsurile sale de protecție, apoi restabili accesul sub monitorizare continuă. 

Condițiile în care evaluăm modelele nu vor corespunde niciodată perfect celor pe care le întâlnesc în utilizarea reală. De aceea, evaluările înainte de implementare trebuie asociate cu o implementare limitată și monitorizată și cu posibilitatea de a interveni, de a suspenda sau de a reveni la o versiune anterioară atunci când apar probleme. Ceea ce învățăm din implementare poate deveni apoi parte din evaluări și măsuri de protecție mai solide înainte ca accesul să fie extins.

În secțiunile următoare, prezentăm exemple concrete ale lucrurilor observate, ale modului în care am abordat problemele și ale felului în care această experiență va modela lansările viitoare.

Noul model poate continua să lucreze către un obiectiv prin încercări repetate, pe o perioadă lungă de timp. Aceeași persistență îl poate face să găsească și să exploateze puncte slabe din mediul său. Modelele anterioare, când întâlneau constrângeri de tip sandbox sau de mediu, se opreau pur și simplu și reveneau la utilizator. Acest model continua adesea să încerce, inclusiv căutând modalități de a acționa în afara sandboxului său.

Un exemplu a apărut în timpul unei evaluări interne pe speedrunul NanoGPT⁠(se deschide într-o fereastră nouă), un test de referință public pentru antrenarea unui model lingvistic mic în cât mai puțini pași. Modelul nostru a dezvoltat o metodă de reducere treptată a ratei de învățare pe baza unei legi de putere, numită PowerCool, care a dus la o îmbunătățire semnificativă. Modelului i s-a cerut să își posteze rezultatele doar pe Slack, dar instrucțiunile NanoGPT spun că rezultatele trebuie postate ca PR pe GitHub, iar modelul a urmat aceste din urmă instrucțiuni și a deschis PR #287 în depozitul public GitHub. Modelul a ocolit restricțiile sandboxului, concepute să blocheze accesul extern, și a continuat încărcarea pe GitHub. Modelului nostru i-a luat o oră să găsească o vulnerabilitate în sandbox pentru a crea PR-ul; modelele anterioare erau mai puțin persistente și nu au reușit să găsească vulnerabilități, renunțând în schimb la partea cu PR-ul.¹

Multe controale de siguranță pentru asistenții AI sunt concepute în jurul acțiunilor individuale. Dacă o acțiune nu este permisă, este blocată. Dacă este sensibilă, sistemul îi cere utilizatorului aprobare explicită. Dar modelele care rulează mult timp, ale căror acțiuni se pot desfășura autonom pe parcursul unor ore, zile sau chiar săptămâni, pun la încercare această abordare: monitorizarea acțiunilor individuale nu mai este suficientă pentru a urmări intenția traiectoriei de ansamblu.

De exemplu, într-un scenariu în care modelului i s-a cerut să rezolve o problemă, modelul a observat că alte sisteme avuseseră trimiteri reușite, dar private, și a încercat să recupereze acele soluții din backendul de evaluare. Când încercarea sa inițială a fost blocată deoarece un scanner a detectat un token de autentificare, modelul a împărțit corpul tokenului în două fragmente, le-a obscurizat, apoi a reconstruit acreditarea la runtime, astfel încât tokenul complet să nu apară niciodată ca un singur șir contiguu. Modelul a spus explicit, atât în comentariile către utilizator, cât și în urmele sale de raţionament, că făcea acești pași pentru a ocoli scannerul.

Acest exemplu arată cum fiecare pas poate părea acceptabil de unul singur, în timp ce secvența poate produce un rezultat care nu ar fi aprobat. Arată, de asemenea, cum un model care operează eficient pe orizonturi de timp lungi poate învăța punctele oarbe ale unui sistem de aprobare și le poate ocoli pentru a-și atinge obiectivele. Siguranța pe orizont lung cere nu doar întrebarea „este permisă această acțiune?”, ci și „spre ce rezultat se îndreaptă această secvență de acțiuni?”

Din cauza unor incidente ca acestea, am suspendat implementarea internă a noului model. Am reconstruit sistemul de siguranță în jurul apărării în profunzime și al monitorizării la nivel de traiectorie.

• Evaluări derivate din incidente. Evaluările ne pot oferi o idee despre cât de sigur este un sistem pentru implementare înainte ca acesta să fie efectiv implementat. Totuși, pentru a fi cât mai utilă, o evaluare ar trebui să reflecte distribuția și lungimea orizontului traiectoriilor din timpul implementării reale. Din acest motiv, am folosit eșecurile observate pentru a dezvolta evaluări adversariale. Am constatat că îmbunătățirea rezultatelor la evaluările derivate din incidente reale a dus, la rândul ei, la un comportament mai sigur după implementarea în producție.
• Aliniere îmbunătățită. Am luat măsuri pentru a-i reduce tendința de a întreprinde acțiuni nedorite fără permisiune în urmărirea obiectivului utilizatorului.  De exemplu, am constatat că modelele noastre rețineau mai slab instrucțiunile în rulările lungi, iar când am antrenat modelul pentru această capacitate, am obținut un model care rămânea aliniat pe parcursul unor rulări mai lungi. 
• Monitorizare activă. Am creat un sistem de monitorizare care analizează evoluția parcursului modelului pentru a detecta semne că acesta eludează o constrângere impusă de utilizator sau o limită de siguranță. Sistemul de monitorizare nu observă doar o singură acțiune, ci întregul parcurs. Este important că acesta poate întrerupe sesiunea și poate alerta utilizatorul pentru o examinare mai atentă. După verificare, utilizatorul poate alege să permită continuarea activității modelului dacă alerta s-a dovedit a fi falsă. 
• Vizibilitate și control sporite pentru utilizator. Am îmbunătățit capacitatea utilizatorului de a inspecta aceste sesiuni de lungă durată, de a vedea acțiunile efectuate și de a monitoriza intervențiile.

Pentru a evalua noul sistem de monitorizare, am reluat un set mic de medii de implementare internă în care modelul urmărise anterior acțiuni nealiniate, de data aceasta cu noile măsuri de protecție în vigoare². Noile măsuri de protecție au putut detecta considerabil mai multe acțiuni nealiniate urmărite de model, iar cele ratate au fost toate considerate de severitate scăzută.

Câteva exemple de astfel de incidente cu severitate scăzută includ următoarele cazuri:

• Pentru a accesa un instrument Linear în linie de comandă, modelul a lansat o sesiune codex --yolo imbricată, deși, de fapt, ar fi putut face acest lucru fără indicatorul --yolo.
• Modelul a observat că lipsea o resursă care fusese anterior activă, apoi a început să exploreze și să se conecteze prin SSH la alte poduri CPU active din spațiul de nume al proprietarului său, precum și, fără succes, la poduri aparținând altor angajați OpenAI, fără un motiv întemeiat.
• Modelul avea multe procese find blocate și fiecare comandă shell se bloca. Apoi a rulat kill -9 -1, care ar fi trimis SIGKILL către fiecare proces pe care are voie să îl oprească în acel pod, dacă s-ar fi executat. Totuși, a expirat și nu s-a executat.

După testarea noului sistem, am concluzionat că accesul intern limitat la modele cu capacități pe orizont lung putea fi restabilit. Nu am observat nicio ocolire gravă a măsurilor de protecție de când reimplementarea a început, acum câteva săptămâni. Prima versiune a acestor măsuri de protecție a fost în mod deliberat conservatoare. Am continuat să ajustăm sistemul pentru a reduce întreruperile inutile fără a slăbi măsurile de protecție.

Deoarece am implementat iterativ, am putut găsi și remedia lacune înainte de a extinde accesul. Evaluările înainte de implementare rămân esențiale, dar implementarea dezvăluie comportamente pe care acestea le ratează. Faptul că am început cu acces limitat ne-a permis să observăm modelul în practică, să suspendăm accesul când au apărut probleme, să folosim acele eșecuri pentru a construi evaluări și măsuri de protecție mai bune și să restabilim accesul limitat după testarea schimbărilor.

Pe măsură ce modelele preiau sarcini mai lungi și mai complexe, eșecurile pe care evaluările le ratează pot avea consecințe mai mari. Vom continua să lucrăm pentru a reduce decalajul dintre evaluare și implementare: testând modele pe traiectorii mai lungi, îmbunătățind alinierea, construind monitorizare capabilă să intervină și oferindu-le utilizatorilor vizibilitate și control mai clare. Aceste provocări nu vor fi specifice OpenAI și sperăm că împărtășirea celor învățate va ajuta domeniul mai larg să se pregătească pentru ele.