Säkerhet och styrning i en tid av modeller med lång tidshorisont

Modeller som kan arbeta självständigt under långa tidsperioder kan ta sig an komplexa, öppna problem. Men samma uthållighet som gör dem användbara ger dem också fler möjligheter att utföra oönskade handlingar – och att göra det på sätt som utvärderingar avsedda för modeller med kortare planeringshorisont kanske inte fångar upp.

För ungefär två månader sedan meddelade⁠ vi att en intern allmän modell hade motbevisat Erdős förmodan om enhetsavstånd. Den här modellen utformades för att arbeta självständigt under mycket långa perioder. Under begränsad, övervakad intern användning observerade vi oönskat beteende som våra befintliga driftsättningsutvärderingar inte hade fångat upp. Eftersom driftsättningen var begränsad och övervakad kunde vi identifiera dessa problem, pausa åtkomsten, skapa nya utvärderingar baserade på det vi observerade, stärka modellen och dess skyddsåtgärder och sedan återställa åtkomsten under fortsatt övervakning. 

De förutsättningar under vilka vi utvärderar modeller kommer aldrig att helt motsvara de förutsättningar som gäller när modellerna används. Därför behöver utvärderingar före driftsättning kompletteras med en begränsad och övervakad driftsättning samt möjlighet att ingripa, pausa eller återställa systemet när problem uppstår. Erfarenheterna från driftsättningen kan sedan ligga till grund för bättre utvärderingar och starkare skyddsåtgärder innan åtkomsten utökas.

I följande avsnitt delar vi konkreta exempel på vad vi observerade, hur vi hanterade problem och hur den här erfarenheten kommer att forma framtida lanseringar.

Den nya modellen kan fortsätta arbeta mot ett mål genom upprepade försök under lång tid. Samma uthållighet innebär också att modellen kan hitta och utnyttja svagheter i sin omgivning. Tidigare modeller brukade avbryta och återvända till användaren när de stötte på begränsningar i sandlådan eller i exekveringsmiljön. Den här modellen fortsatte däremot ofta att försöka, bland annat genom att söka efter sätt att agera utanför sandlådan.

Ett exempel på detta inträffade under en intern utvärdering med NanoGPT⁠(öppnas i ett nytt fönster) Speedrun, ett offentligt benchmark där målet är att träna en liten språkmodell på så få steg som möjligt. Under utvärderingen tog modellen fram en ny metod för att trappa ned inlärningshastigheten enligt en potenslag, kallad PowerCool, vilket förbättrade resultatet avsevärt. Den hade fått instruktioner om att endast publicera resultaten i Slack. Samtidigt angav instruktionerna för NanoGPT att resultaten skulle skickas in som en pull request på GitHub. Modellen följde de instruktionerna och öppnade därför PR #287 i det offentliga GitHub-förvaret. För att kunna göra detta tog den sig förbi sandlådans begränsningar, som var avsedda att förhindra extern åtkomst, och publicerade resultaten på GitHub. Det tog modellen ungefär en timme att hitta en sårbarhet i sandlådan som gjorde detta möjligt. Tidigare modeller var mindre uthålliga och gav upp innan de lyckades hitta någon sådan sårbarhet.¹

Många säkerhetsmekanismer för AI-assistenter är utformade för att hantera enskilda åtgärder. Om en åtgärd inte är tillåten blockeras den. Om den är känslig ombeds användaren att uttryckligen godkänna den. Men modeller som arbetar självständigt under lång tid – där en följd av åtgärder kan sträcka sig över timmar, dagar eller till och med veckor – ställer andra krav. Då räcker det inte längre att övervaka enskilda åtgärder för att förstå avsikten bakom modellens samlade handlande.

Ett exempel är ett scenario där modellen ombads att lösa ett problem. Modellen upptäckte då att andra system hade skickat in framgångsrika, men privata, lösningar och försökte återskapa dem från utvärderingssystemets backend. När det första försöket stoppades eftersom en skanner upptäckte en autentiseringstoken delade modellen upp tokens innehåll i två delar, obfuskerade dem och återskapade sedan autentiseringsuppgiften vid körning, så att den fullständiga token aldrig förekom som en sammanhängande sträng. Både i sina kommentarer till användaren och i sina resonemangsspår var modellen tydlig med att den vidtog dessa åtgärder för att kringgå skannern.

Det här exemplet visar hur varje enskilt steg kan framstå som godtagbart i sig, medan sekvensen av steg kan leda till ett resultat som inte skulle godkännas. Det visar också hur en modell som kan arbeta effektivt över långa tidshorisonter kan lära sig ett godkännandesystems blinda fläckar och kringgå dem för att uppnå sina mål. Säkerhet för modeller med lång planeringshorisont kräver att man inte bara frågar: ”Är den här handlingen tillåten?”, utan också: ”Vilket resultat leder den här sekvensen av handlingar mot?”

På grund av incidenter som dessa pausade vi den interna driftsättningen av den nya modellen. Vi byggde om säkerhetssystemet kring försvar på djupet och övervakning på förloppsnivå.

• Utvärderingar baserade på incidenter. Utvärderingar kan ge oss en uppfattning om huruvida ett system är säkert att driftsätta innan det faktiskt tas i bruk. För att vara så användbara som möjligt bör en utvärdering dock återspegla fördelningen och tidshorisonten för de händelseförlopp som uppstår vid verklig användning. Därför använde vi observerade fel för att utveckla motståndskraftstester. Vi såg att förbättringar av utvärderingar som tagits fram utifrån verkliga incidenter i sin tur ledde till säkrare beteende när systemen togs i drift.
• Förbättrad styrning. Vi vidtog åtgärder för att minska modellens benägenhet att utan tillåtelse utföra oönskade handlingar i syfte att uppnå användarens mål.  Vi upptäckte till exempel att våra modeller hade svårare att komma ihåg instruktioner under långa körningar. När vi tränade modellen för att optimera denna förmåga förblev den samstämmig med instruktionerna även under längre körningar. 
• Aktiv övervakning. Vi skapade ett övervakningssystem som granskar modellens fortlöpande händelseförlopp för att upptäcka tecken på att den kringgår användarens begränsningar eller säkerhetsgränser. Övervakningssystemet observerar inte bara en enskild handling utan hela händelseförloppet. Det kan också pausa sessionen och uppmana användaren att granska den närmare. Efter granskningen kan användaren välja att låta modellen fortsätta sitt arbete om övervakningssystemet har utlösts felaktigt. 
• Ökad insyn och kontroll för användaren. Vi förbättrade användarens möjligheter att granska dessa långvariga körningar, se vilka åtgärder modellen vidtagit och följa övervakningssystemets ingripanden.

För att utvärdera det nya övervakningssystemet spelade vi upp en liten uppsättning interna driftsättningsmiljöer där modellen tidigare hade vidtagit avvikande åtgärder, denna gång med de nya skyddsåtgärderna på plats². De nya skyddsåtgärderna kunde fånga upp betydligt fler avvikande åtgärder som modellen vidtog, och de som missades bedömdes alla ha låg allvarlighetsgrad.

Några exempel på sådana incidenter med låg allvarlighetsgrad är följande:

• För att få åtkomst till ett kommandoradsverktyg för Linear startade modellen en underordnad codex --yolo-session, trots att den hade kunnat göra det utan flaggan --yolo.
• Modellen upptäckte att en tidigare tillgänglig resurs saknades och började därefter undersöka och SSH-ansluta till andra aktiva CPU-poddar inom ägarens namnområde, samt – utan framgång – poddar som tillhörde andra OpenAI-medarbetare, utan någon godtagbar anledning.
• Modellen hade många find-processer som hade hängt sig, och varje skalkommando låste sig. Därefter körde den kill -9 -1, vilket skulle ha skickat signalen SIGKILL till varje process som den hade behörighet att avsluta på den podden, om kommandot hade körts. Det överskred dock tidsgränsen och kördes därför aldrig.

Efter att ha testat det nya systemet drog vi slutsatsen att begränsad intern åtkomst till modeller med lång planeringshorisont kunde återställas. Sedan återdriftsättningen inleddes för flera veckor sedan har vi inte observerat några allvarliga försök att kringgå skyddsåtgärderna. Den första versionen av dessa skyddsåtgärder var avsiktligt konservativ. Vi har fortsatt att finjustera systemet för att minska antalet onödiga avbrott utan att försvaga skyddsåtgärderna.

Genom att driftsätta modellen stegvis kunde vi identifiera och åtgärda brister innan vi utökade åtkomsten. Utvärderingar före driftsättning är fortfarande avgörande, men först vid driftsättning blir det tydligt vilka beteenden de inte fångar upp. Genom att inledningsvis begränsa åtkomsten kunde vi observera modellen i praktiken, pausa driftsättningen när problem uppstod, använda dessa misslyckanden för att utveckla bättre utvärderingar och skyddsåtgärder samt återställa den begränsade åtkomsten efter att ha testat förändringarna.

I takt med att modeller tar sig an allt längre och mer komplexa uppgifter kan de fel som utvärderingar missar få större konsekvenser. Vi kommer att fortsätta arbetet med att minska klyftan mellan utvärdering och driftsättning genom att testa modeller över längre händelseförlopp, förbättra styrningen, utveckla övervakningssystem som kan ingripa och ge användarna bättre insyn och kontroll. Dessa utmaningar är inte unika för OpenAI, och vi hoppas att det vi har lärt oss kan hjälpa det bredare AI-fältet att förbereda sig för dem.