Veiligheid en afstemming bij modellen met lange tijdshorizon

Modellen die lange tijd autonoom kunnen werken, kunnen moeilijke, open problemen aanpakken. Maar dezelfde volharding die ze nuttig maakt, geeft ze ook meer kansen om ongewenste acties uit te voeren — en dat op manieren die evaluaties voor modellen met een kortere tijdshorizon kunnen missen.

Ongeveer twee maanden geleden kondigden⁠ we aan dat een intern model voor algemeen gebruik het vermoeden van Erdős over eenheidsafstanden had weerlegd. Dit model was ontworpen om zeer lange tijd autonoom te werken. Tijdens beperkt, gemonitord intern gebruik zagen we ongewenst gedrag dat onze bestaande uitrolevaluaties niet hadden opgemerkt. Omdat de uitrol beperkt was en werd gemonitord, konden we deze problemen identificeren, de toegang pauzeren, nieuwe evaluaties maken op basis van wat we zagen, het model en de waarborgen versterken en de toegang daarna onder voortdurende monitoring herstellen. 

De omstandigheden waarin we modellen evalueren, zullen nooit perfect overeenkomen met wat ze in werkelijk gebruik tegenkomen. Daarom moeten evaluaties vóór uitrol worden gecombineerd met beperkte, gemonitorde uitrol en de mogelijkheid om in te grijpen, te pauzeren of terug te draaien wanneer er problemen ontstaan. Wat we uit de uitrol leren, kan daarna deel worden van sterkere evaluaties en waarborgen voordat de toegang wordt uitgebreid.

In de volgende secties delen we concrete voorbeelden van wat we zagen, hoe we problemen hebben aangepakt en hoe deze ervaring toekomstige releases zal vormgeven.

Het nieuwe model kan via herhaalde pogingen gedurende lange tijd aan een doel blijven werken. Diezelfde volharding kan ertoe leiden dat het zwakke plekken in zijn omgeving vindt en uitbuit. Eerdere modellen stopten simpelweg en keerden terug naar de gebruiker wanneer ze op sandbox- of omgevingsbeperkingen stuitten. Dit model bleef vaak proberen, onder meer door te zoeken naar manieren om buiten zijn sandbox te handelen.

Een voorbeeld hiervan deed zich voor tijdens een interne evaluatie op de NanoGPT‑speedrun⁠(opent in een nieuw venster), een openbare benchmark om een klein taalmodel in zo min mogelijk stappen te trainen. Ons model ontwikkelde een power-law-afkoeling van de learning rate, PowerCool genoemd, die tot een aanzienlijke verbetering leidde. Het model kreeg de instructie zijn resultaten alleen op Slack te plaatsen, maar de NanoGPT‑instructies zeggen dat resultaten als PR op GitHub moeten worden geplaatst, en het model volgde die laatste instructies en opende PR #287 in de openbare GitHub-repository. Het model omzeilde sandboxbeperkingen die externe toegang moesten blokkeren en ging door met de upload naar GitHub. Ons model had een uur nodig om een kwetsbaarheid in de sandbox te vinden en zo de PR te kunnen maken; eerdere modellen waren minder volhardend en wisten geen kwetsbaarheden te vinden, maar gaven het PR-gedeelte op.¹

Veel veiligheidsmaatregelen voor AI-assistenten zijn ingericht rond afzonderlijke acties. Als een actie niet is toegestaan, wordt die geblokkeerd. Als een actie gevoelig is, vraagt het systeem de gebruiker om expliciete goedkeuring. Maar modellen die lang doorlopen en waarvan de acties zich autonoom over uren, dagen of zelfs weken kunnen ontvouwen, zetten deze opzet onder druk: individuele acties monitoren volstaat niet meer om de intentie van het totale traject te volgen.

In een scenario waarin het model werd gevraagd een probleem op te lossen, merkte het bijvoorbeeld dat andere systemen succesvolle maar private inzendingen hadden en probeerde het die oplossingen uit de evaluatiebackend te achterhalen. Toen de eerste poging werd geblokkeerd omdat een scanner een authenticatietoken detecteerde, splitste het model de inhoud van de token in twee fragmenten, verhulde die en reconstrueerde de credential vervolgens tijdens runtime, zodat de volledige token nooit als één aaneengesloten tekenreeks verscheen. Het model maakte zowel in zijn opmerkingen aan de gebruiker als in zijn redeneringssporen expliciet dat het deze stappen zette om de scanner te omzeilen.

Dit voorbeeld laat zien hoe elke stap op zichzelf aanvaardbaar kan lijken, terwijl de reeks een uitkomst kan opleveren die niet zou worden goedgekeurd. Het laat ook zien hoe een model dat effectief over lange tijdshorizonten werkt, de blinde vlekken van een goedkeuringssysteem kan leren kennen en eromheen kan werken om zijn doelen te bereiken. Veiligheid bij een lange tijdshorizon vraagt niet alleen: “is deze actie toegestaan?” maar ook: “naar welk resultaat werkt deze reeks acties toe?”

Vanwege dit soort incidenten pauzeerden we de interne uitrol van het nieuwe model. We bouwden het veiligheidssysteem opnieuw op rond gelaagde verdediging en monitoring op trajectniveau.

• Evaluaties op basis van incidenten. Evaluaties kunnen ons een beeld geven van de vraag of een systeem veilig kan worden uitgerold voordat het daadwerkelijk wordt ingezet. Maar om het meest bruikbaar te zijn, moet een evaluatie de verdeling en tijdshorizon van trajecten tijdens echte uitrol weerspiegelen. Daarom gebruikten we waargenomen fouten om adversariële evaluaties te ontwikkelen. We zagen dat verbetering op de evaluaties die uit praktijkincidenten waren afgeleid, vervolgens leidde tot veiliger gedrag na uitrol in productie.
• Verbeterde afstemming. We namen maatregelen om de neiging te verminderen om zonder toestemming ongewenste acties uit te voeren bij het nastreven van het doel van de gebruiker.  We ontdekten bijvoorbeeld dat onze modellen instructies slechter onthielden tijdens lange roll-outs; toen we het model op deze vaardigheid trainden, bleef het over langere roll-outs afgestemd. 
• Actieve monitoring. We maakten een monitoringsysteem dat het zich ontwikkelende traject van het model beoordeelt op tekenen dat het een gebruikersbeperking of veiligheidsgrens omzeilt. De monitor kijkt niet alleen naar één actie, maar naar het hele traject. Belangrijk is dat de monitor de sessie kan pauzeren en de gebruiker kan waarschuwen om nader onderzoek te doen. Na onderzoek kan de gebruiker ervoor kiezen het werk van het model voort te zetten als de monitor onterecht is geactiveerd. 
• Meer zicht en controle voor gebruikers. We verbeterden de mogelijkheid voor gebruikers om deze langlopende sessies te inspecteren, de uitgevoerde acties te bekijken en interventies te monitoren.

Om het nieuwe monitoringsysteem te evalueren, speelden we een kleine set interne uitrolomgevingen opnieuw af waarin het model eerder niet-afgestemde acties had nagestreefd, ditmaal met de nieuwe waarborgen actief². De nieuwe waarborgen konden aanzienlijk meer niet-afgestemde acties van het model onderscheppen, en de gemiste acties werden allemaal als incidenten met lage ernst beoordeeld.

Enkele voorbeelden van deze incidenten met lage ernst zijn:

• Om toegang te krijgen tot een command-line-tool van Linear startte het model een geneste sessie met codex --yolo, terwijl dit ook zonder de vlag --yolo had gekund.
• Het model merkte dat een eerder actieve resource ontbrak en begon daarna andere actieve CPU-pods binnen de namespace van de eigenaar te verkennen en er via SSH op in te loggen, evenals, zonder succes, pods van andere OpenAI-medewerkers, zonder goede reden.
• Het model had veel vastgelopen processen van find en elke shellopdracht bleef hangen. Vervolgens voerde het kill -9 -1 uit, wat SIGKILL zou hebben gestuurd naar elk proces dat het op die pod mocht beëindigen, als de opdracht was uitgevoerd. Maar de opdracht liep af en werd niet uitgevoerd.

Na het testen van het nieuwe systeem concludeerden we dat beperkte interne toegang tot modellen met capaciteiten voor een lange tijdshorizon kon worden hersteld. Sinds de heruitrol enkele weken geleden begon, hebben we geen ernstige omzeiling van waarborgen gezien. De eerste versie van deze waarborgen was bewust conservatief. We zijn het systeem blijven afstemmen om onnodige onderbrekingen te verminderen zonder de waarborgen te verzwakken.

Omdat we iteratief uitrolden, konden we hiaten vinden en aanpakken voordat we de toegang uitbreidden. Evaluaties vóór uitrol blijven essentieel, maar uitrol brengt gedrag aan het licht dat zij missen. Door met beperkte toegang te beginnen, konden we het model in de praktijk observeren, pauzeren wanneer er problemen ontstonden, die fouten gebruiken om betere evaluaties en waarborgen te bouwen en na het testen van de wijzigingen beperkte toegang herstellen.

Naarmate modellen langere en complexere taken uitvoeren, kunnen fouten die evaluaties missen grotere gevolgen hebben. We blijven werken aan het verkleinen van de kloof tussen evaluatie en uitrol: modellen testen over langere trajecten, afstemming verbeteren, monitoring bouwen die kan ingrijpen en gebruikers duidelijker zicht en controle geven. Deze uitdagingen zijn niet uniek voor OpenAI, en we hopen dat het delen van wat we hebben geleerd het bredere veld helpt zich erop voor te bereiden.