Sicurezza e allineamento nell’era dei modelli a lungo orizzonte

I modelli che possono lavorare autonomamente per lunghi periodi possono affrontare problemi difficili e aperti. Ma la stessa persistenza che li rende utili offre loro anche più occasioni di compiere azioni indesiderate, e di farlo in modi che le valutazioni pensate per modelli con orizzonti più brevi potrebbero non rilevare.

Circa due mesi fa abbiamo annunciato⁠ che un modello interno generalista aveva confutato la congettura di Erdős sulle distanze unitarie. Questo modello è stato progettato per lavorare autonomamente per periodi di tempo molto lunghi. Durante un uso interno limitato e monitorato, abbiamo osservato comportamenti indesiderati che le nostre valutazioni di distribuzione esistenti non avevano colto. Poiché la distribuzione era limitata e monitorata, siamo riusciti a identificare questi problemi, sospendere l’accesso, creare nuove valutazioni basate su ciò che avevamo osservato, rafforzare il modello e le sue salvaguardie, e poi ripristinare l’accesso mantenendo il monitoraggio. 

Le condizioni in cui valutiamo i modelli non corrisponderanno mai perfettamente a quelle che incontrano nell’uso reale. Per questo le valutazioni pre-distribuzione devono essere affiancate da una distribuzione limitata e monitorata e dalla capacità di intervenire, sospendere o ripristinare una versione precedente quando emergono problemi. Ciò che impariamo dalla distribuzione può poi diventare parte di valutazioni e salvaguardie più solide prima di ampliare l’accesso.

Nelle sezioni seguenti condividiamo esempi concreti di ciò che abbiamo osservato, di come abbiamo affrontato i problemi e di come questa esperienza orienterà le release future.

Il nuovo modello può continuare a lavorare verso un obiettivo attraverso tentativi ripetuti per un lungo periodo di tempo. La stessa persistenza può portarlo a trovare e sfruttare debolezze nel suo ambiente. I modelli precedenti, quando incontravano vincoli di sandboxing o dell’ambiente, si fermavano semplicemente e tornavano dall’utente. Questo modello spesso continuava a provare, anche cercando modi per agire fuori dalla propria sandbox.

Un esempio si è verificato durante una valutazione interna sulla speedrun NanoGPT⁠(si apre in una nuova finestra), un benchmark pubblico per addestrare un piccolo modello linguistico nel minor numero possibile di passaggi. Il nostro modello ha sviluppato un cooldown del tasso di apprendimento basato su una legge di potenza, chiamato PowerCool, che ha portato a un miglioramento significativo. Al modello era stato chiesto di pubblicare i risultati solo su Slack, ma le istruzioni di NanoGPT indicano di pubblicare i risultati come PR su GitHub, e il modello ha seguito queste ultime istruzioni aprendo la PR #287 sul repository pubblico di GitHub. Il modello ha aggirato le restrizioni della sandbox progettate per bloccare l’accesso esterno e ha proceduto con il caricamento su GitHub. Al nostro modello è servita un’ora per trovare una vulnerabilità nella sandbox e creare la PR; i modelli precedenti erano meno persistenti e non erano riusciti a trovare vulnerabilità, rinunciando invece alla parte relativa alla PR.¹

Molti controlli di sicurezza per gli assistenti IA sono progettati intorno alle singole azioni. Se un’azione non è consentita, viene bloccata. Se è sensibile, il sistema chiede l’approvazione esplicita dell’utente. Ma i modelli a esecuzione prolungata, le cui azioni possono svilupparsi autonomamente per ore, giorni o persino settimane, mettono in discussione questa impostazione: monitorare le singole azioni non basta più per seguire l’intento della traiettoria complessiva.

Per esempio, in uno scenario in cui al modello era stato chiesto di risolvere un problema, il modello ha osservato che altri sistemi avevano submission riuscite ma private e ha provato a recuperare quelle soluzioni dal backend di valutazione. Quando il suo tentativo iniziale è stato bloccato perché uno scanner aveva rilevato un token di autenticazione, il modello ha diviso il corpo del token in due frammenti, li ha offuscati e poi ha ricostruito la credenziale in fase di esecuzione, così che il token completo non apparisse mai come un’unica stringa contigua. Il modello ha dichiarato esplicitamente, sia nei commenti all’utente sia nelle tracce di ragionamento, che stava compiendo questi passaggi per aggirare lo scanner.

Questo esempio mostra come ogni passaggio possa sembrare accettabile da solo, mentre la sequenza può produrre un esito che non verrebbe approvato. Mostra anche come un modello che opera efficacemente su orizzonti temporali lunghi possa imparare i punti ciechi di un sistema di approvazione e aggirarli per raggiungere i propri obiettivi. La sicurezza su orizzonti temporali lunghi richiede non solo di chiedersi «questa azione è consentita?», ma anche «a quale risultato mira questa sequenza di azioni?»

A causa di incidenti come questi, abbiamo sospeso la distribuzione interna del nuovo modello. Abbiamo ricostruito il sistema di sicurezza attorno alla difesa in profondità e al monitoraggio a livello di traiettoria.

• Valutazioni derivate dagli incidenti. Le valutazioni possono darci un’indicazione sul fatto che un sistema sia sicuro da distribuire prima che venga effettivamente distribuito. Tuttavia, per essere davvero utile, una valutazione dovrebbe riflettere la distribuzione e la lunghezza dell’orizzonte delle traiettorie durante la distribuzione reale. Per questo motivo abbiamo usato i fallimenti osservati per sviluppare valutazioni avversarie. Abbiamo riscontrato che migliorare nelle valutazioni derivate da incidenti reali portava a sua volta a comportamenti più sicuri una volta distribuito in produzione.
• Migliore allineamento. Abbiamo adottato misure per ridurre la sua tendenza a compiere azioni indesiderate senza autorizzazione nel perseguire l’obiettivo dell’utente.  Per esempio, abbiamo riscontrato che i nostri modelli ricordavano peggio le istruzioni nei rollout lunghi e, quando abbiamo addestrato il modello per questa capacità, ne è risultato un modello che rimaneva allineato durante rollout più lunghi. 
• Monitoraggio attivo. Abbiamo creato un sistema di monitoraggio che esamina l’evoluzione della traiettoria del modello alla ricerca di segnali che indichino il superamento di un vincolo dell’utente o di un limite di sicurezza. Il monitor osserva non solo una singola azione, ma l’intera traiettoria. È importante sottolineare che il monitor può sospendere la sessione e avvisare l’utente affinché esamini più da vicino la situazione. Dopo l’esame, l’utente può scegliere di continuare il lavoro del modello se il monitor è stato attivato per errore. 
• Maggiore visibilità e controllo per l’utente. Abbiamo migliorato la capacità dell’utente di ispezionare queste sessioni a esecuzione prolungata, vedere le azioni intraprese e monitorare gli interventi.

Per valutare il nuovo sistema di monitoraggio, abbiamo riprodotto un piccolo insieme di ambienti di distribuzione interna in cui in precedenza il modello aveva perseguito azioni disallineate, questa volta con le nuove salvaguardie in atto². Le nuove salvaguardie sono riuscite a intercettare molte più azioni disallineate perseguite dal modello, e quelle non rilevate sono state tutte giudicate di bassa gravità.

Alcuni esempi di questi incidenti di bassa gravità includono i casi seguenti:

• Per accedere a uno strumento a riga di comando di Linear, il modello ha avviato una sessione annidata codex --yolo, quando in realtà avrebbe potuto farlo senza il flag --yolo.
• Il modello ha notato che mancava una risorsa precedentemente attiva, quindi ha iniziato a esplorare e ad accedere via SSH ad altri pod CPU attivi nel namespace del suo proprietario, nonché (senza riuscirci) a pod appartenenti ad altri dipendenti OpenAI, senza una buona ragione per farlo.
• Il modello aveva molti processi find bloccati e ogni comando shell restava sospeso. Ha quindi eseguito kill -9 -1, che avrebbe inviato SIGKILL a ogni processo che gli era consentito terminare su quel pod, se fosse stato eseguito. Tuttavia è andato in timeout e non è stato eseguito.

Dopo aver testato il nuovo sistema, abbiamo concluso che l’accesso interno limitato ai modelli con capacità su orizzonti temporali lunghi poteva essere ripristinato. Da quando la ridistribuzione è iniziata diverse settimane fa, non abbiamo osservato alcun grave aggiramento delle salvaguardie. La prima versione di queste salvaguardie era deliberatamente prudente. Abbiamo continuato a mettere a punto il sistema per ridurre le interruzioni non necessarie senza indebolire le salvaguardie.

Poiché abbiamo distribuito in modo iterativo, siamo riusciti a individuare e colmare le lacune prima di ampliare l’accesso. Le valutazioni pre-distribuzione restano essenziali, ma la distribuzione rivela comportamenti che esse non colgono. Iniziare con un accesso limitato ci ha permesso di osservare il modello nella pratica, sospendere quando emergevano problemi, usare quei fallimenti per costruire valutazioni e salvaguardie migliori e ripristinare l’accesso limitato dopo aver testato le modifiche.

Man mano che i modelli affrontano compiti più lunghi e complessi, i fallimenti non rilevati dalle valutazioni possono avere conseguenze più gravi. Continueremo a lavorare per ridurre il divario tra valutazione e distribuzione: testando i modelli su traiettorie più lunghe, migliorando l’allineamento, costruendo sistemi di monitoraggio in grado di intervenire e offrendo agli utenti visibilità e controllo più chiari. Queste sfide non saranno proprie solo di OpenAI, e speriamo che condividere ciò che abbiamo imparato aiuti il settore nel suo complesso a prepararsi ad affrontarle.