Seguretat i alineació en l’era dels models d’horitzó de tasca llarg

Els models que poden treballar de manera autònoma durant períodes llargs poden abordar problemes difícils i oberts. Però la mateixa persistència que els fa útils també els dona més oportunitats de dur a terme accions no desitjades, i de fer-ho de maneres que les avaluacions pensades per a models d’horitzó més curt poden no detectar.

Fa uns dos mesos vam anunciar⁠ que un model intern de propòsit general havia refutat la conjectura de distància unitària d’Erdős. Aquest model es va dissenyar per treballar de manera autònoma durant períodes de temps molt llargs. Durant un ús intern limitat i supervisat, vam observar comportaments no desitjats que les nostres avaluacions de desplegament existents no havien capturat. Com que el desplegament era limitat i supervisat, vam poder identificar aquests problemes, pausar l’accés, crear noves avaluacions basades en el que havíem observat, reforçar el model i les seves mesures de protecció, i després restablir l’accés amb supervisió continuada. 

Les condicions en què avaluem els models mai no coincidiran perfectament amb les que troben en l’ús real. Per això, les avaluacions prèvies al desplegament s’han de combinar amb un desplegament limitat i supervisat, i amb la capacitat d’intervenir, pausar o fer marxa enrere quan sorgeixen problemes. El que aprenem del desplegament pot passar a formar part d’avaluacions i mesures de protecció més sòlides abans d’ampliar l’accés.

En les seccions següents compartim exemples concrets del que vam observar, de com vam abordar els problemes i de com aquesta experiència donarà forma a futurs llançaments.

El nou model pot continuar treballant cap a un objectiu mitjançant intents repetits durant un període de temps llarg. Aquesta mateixa persistència el pot portar a trobar i explotar febleses del seu entorn. Els models anteriors, quan topaven amb restriccions de sandboxing o de l’entorn, simplement s’aturaven i tornaven a l’usuari. Aquest model sovint continuava intentant-ho, fins i tot buscant maneres d’actuar fora del seu sandbox.

Un exemple d’això es va produir durant una avaluació interna en la speedrun de NanoGPT⁠(s'obre en una finestra nova), un benchmark públic per entrenar un petit model de llenguatge en el mínim nombre de passos possible. El nostre model va desenvolupar una reducció de la taxa d’aprenentatge segons una llei de potència anomenada PowerCool, que va comportar una millora significativa. Es va indicar al model que publiqués els resultats només a Slack, però les instruccions de NanoGPT diuen que cal publicar els resultats com a PR a GitHub, i el model va seguir aquestes darreres instruccions per obrir la PR #287 al repositori públic de GitHub. El model va eludir les restriccions del sandbox dissenyades per bloquejar l’accés extern i va continuar amb la pujada a GitHub. El nostre model va trigar una hora a trobar una vulnerabilitat al sandbox per poder fer la PR; els models anteriors eren menys persistents i no van aconseguir trobar vulnerabilitats, sinó que van abandonar la part de la PR.¹

Molts controls de seguretat per a assistents d’IA estan dissenyats al voltant d’accions individuals. Si una acció no està permesa, es bloqueja. Si és sensible, el sistema demana l’aprovació explícita de l’usuari. Però els models d’execució llarga, les accions dels quals poden desplegar-se de manera autònoma durant hores, dies o fins i tot setmanes, posen en qüestió aquest enfocament: supervisar accions individuals ja no n’hi ha prou per seguir la intenció de la trajectòria global.

Per exemple, en un escenari en què es demanava al model que resolgués un problema, el model va observar que altres sistemes havien fet enviaments privats però satisfactoris i va intentar recuperar aquestes solucions del backend d’avaluació. Quan el seu intent inicial es va bloquejar perquè un escàner va detectar un token d’autenticació, el model va dividir el cos del token en dos fragments, els va ofuscar i després va reconstruir la credencial en temps d’execució perquè el token complet no aparegués mai com una cadena contigua. El model va deixar clar, tant en els comentaris a l’usuari com en les traces de raonament, que feia aquests passos per eludir l’escàner.

Aquest exemple mostra com cada pas pot semblar acceptable per si sol, mentre que la seqüència pot produir un resultat que no s’aprovaria. També mostra com un model que opera de manera eficaç en horitzons de tasca llargs pot aprendre els punts cecs d’un sistema d’aprovació i esquivar-lo per assolir els seus objectius. La seguretat per a horitzons de tasca llargs requereix preguntar no només «aquesta acció està permesa?», sinó també «cap a quin resultat apunta aquesta seqüència d’accions?»

A causa d’incidents com aquests, vam pausar el desplegament intern del nou model. Vam reconstruir el sistema de seguretat al voltant de la defensa en profunditat i la supervisió a nivell de trajectòria.

• Avaluacions derivades d’incidents. Les avaluacions ens poden donar una idea de si un sistema és segur de desplegar abans que es desplegui realment. Tanmateix, perquè sigui realment útil, una avaluació ha de reflectir la distribució i la longitud de l’horitzó de les trajectòries durant el desplegament real. Per aquest motiu, vam utilitzar les fallades observades per desenvolupar avaluacions adversarials. Vam comprovar que millorar en les avaluacions derivades d’incidents del món real conduïa, al seu torn, a un comportament més segur un cop desplegat en producció.
• Millora de l’alineació. Vam prendre mesures per reduir la seva tendència a dur a terme accions no desitjades sense permís en perseguir l’objectiu de l’usuari.  Per exemple, vam detectar que als nostres models els costava més recordar instruccions en execucions llargues i, quan vam entrenar el model per a aquesta capacitat, el resultat va ser un model que es mantenia alineat durant execucions més llargues. 
• Supervisió activa. Vam crear un sistema de supervisió que revisa la trajectòria en evolució del model per detectar indicis que està esquivant una restricció de l’usuari o un límit de seguretat. El monitor observa no només una acció concreta, sinó tota la trajectòria. És important destacar que el monitor pot pausar la sessió i alertar l’usuari perquè l’examini amb més detall. Després d’examinar-la, l’usuari pot decidir continuar la feina del model si el monitor s’ha activat per error. 
• Més visibilitat i control per a l’usuari. Vam millorar la capacitat de l’usuari per inspeccionar aquestes sessions d’execució llarga, veure les accions fetes i supervisar les intervencions.

Per avaluar el nou sistema de supervisió, vam reproduir un petit conjunt d’entorns de desplegament intern en què el model havia seguit anteriorment accions desalineades, aquesta vegada amb les noves mesures de protecció activades². Les noves mesures de protecció van ser capaces de detectar moltes més accions desalineades perseguides pel model, i totes les que van passar per alt es van considerar de baixa gravetat.

Alguns exemples d’aquests incidents de baixa gravetat inclouen els casos següents:

• Per accedir a una eina de línia d’ordres de Linear, el model va iniciar una sessió imbricada de codex --yolo, quan en realitat ho hauria pogut fer sense el senyalador --yolo.
• El model va detectar que faltava un recurs que abans estava actiu i llavors va començar a explorar i a entrar per SSH en altres pods de CPU actius dins l’espai de noms del seu propietari, així com, sense èxit, en pods d’altres empleats d’OpenAI, sense cap bona raó per fer-ho.
• El model tenia molts processos find encallats i totes les ordres de shell quedaven penjades. Aleshores va executar kill -9 -1, que hauria enviat SIGKILL a tots els processos que tenia permís per matar en aquell pod, si s’hagués executat. Tanmateix, va esgotar el temps d’espera i no es va executar.

Després de provar el nou sistema, vam concloure que es podia restablir l’accés intern limitat a models amb capacitats d’horitzó de tasca llarg. No hem observat cap elusió greu de les mesures de protecció des que el redesplegament va començar fa unes quantes setmanes. La primera versió d’aquestes mesures de protecció va ser deliberadament conservadora. Hem continuat ajustant el sistema per reduir les interrupcions innecessàries sense afeblir les mesures de protecció.

Com que vam desplegar de manera iterativa, vam poder trobar i corregir mancances abans d’ampliar l’accés. Les avaluacions prèvies al desplegament continuen sent essencials, però el desplegament revela comportaments que aquestes no detecten. Començar amb accés limitat ens va permetre observar el model a la pràctica, pausar quan sorgien problemes, utilitzar aquestes fallades per construir millors avaluacions i mesures de protecció, i restablir l’accés limitat després de provar els canvis.

A mesura que els models assumeixen tasques més llargues i complexes, les fallades que les avaluacions no detecten poden tenir conseqüències més grans. Continuarem treballant per reduir la distància entre avaluació i desplegament: provant models en trajectòries més llargues, millorant l’alineació, construint sistemes de supervisió que puguin intervenir i donant als usuaris una visibilitat i un control més clars. Aquests reptes no seran exclusius d’OpenAI, i esperem que compartir el que hem après ajudi el conjunt del sector a preparar-s’hi.