Biztonság és összehangolás a hosszú időtávú modellek korában

Azok a modellek, amelyek hosszú ideig képesek önállóan dolgozni, nehéz, nyílt végű problémákat is meg tudnak oldani. Ugyanaz a kitartás azonban, amely hasznossá teszi őket, több lehetőséget is ad nekik nem kívánt műveletek végrehajtására — ráadásul olyan módokon, amelyeket a rövidebb időtávú modellekre szánt értékelések nem feltétlenül vesznek észre.

Körülbelül két hónapja bejelentettük⁠, hogy egy belső, általános célú modell megcáfolta az Erdős-féle egységtávolság-sejtést. Ezt a modellt úgy terveztük, hogy nagyon hosszú ideig képes legyen önállóan dolgozni. A korlátozott, felügyelt belső használat során olyan nem kívánt viselkedést figyeltünk meg, amelyet a meglévő bevezetési értékeléseink nem tártak fel. Mivel a bevezetés korlátozott és felügyelt volt, azonosítani tudtuk ezeket a problémákat, szüneteltettük a hozzáférést, a megfigyeltek alapján új értékeléseket hoztunk létre, megerősítettük a modellt és a védőkorlátait, majd folyamatos felügyelet mellett visszaállítottuk a hozzáférést. 

A modellek értékelési körülményei soha nem fognak tökéletesen megegyezni azokkal, amelyekkel a tényleges használat során találkoznak. Ezért a bevezetés előtti értékeléseket korlátozott, felügyelt bevezetéssel és azzal a képességgel kell kiegészíteni, hogy probléma esetén be tudjunk avatkozni, szüneteltetni tudjunk vagy vissza tudjunk állni egy korábbi állapotra. A bevezetésből tanultak ezután erősebb értékelések és védőkorlátok részévé válhatnak, mielőtt a hozzáférést bővítenénk.

A következő szakaszokban konkrét példákat mutatunk be arra, mit figyeltünk meg, hogyan kezeltük a problémákat, és hogyan alakítja ez a tapasztalat a jövőbeli kiadásokat.

Az új modell ismételt próbálkozásokkal hosszú időn át képes egy cél elérésén dolgozni. Ugyanez a kitartás oda vezethet, hogy gyengeségeket talál és használ ki a környezetében. A korábbi modellek, amikor sandbox- vagy környezeti korlátokba ütköztek, egyszerűen leálltak és visszatértek a felhasználóhoz. Ez a modell gyakran tovább próbálkozott, többek között úgy, hogy kereste a módját, hogyan cselekedhetne a sandboxán kívül.

Erre példa egy belső értékelés során fordult elő a NanoGPT speedrunon⁠(új ablakban nyílik meg), amely egy nyilvános benchmark egy kis nyelvi modell minél kevesebb lépésben történő betanítására. A modell kifejlesztett egy PowerCool nevű, hatványtörvény-alapú tanulásirátacsökkentést, amely jelentős javulást hozott. A modell azt az utasítást kapta, hogy az eredményeit csak a Slackre tegye közzé, de a NanoGPT utasításai szerint az eredményeket PR-ként kell beküldeni a GitHubra, és a modell az utóbbi utasításokat követve megnyitotta a 287-es PR-t a nyilvános GitHub-adattárban. A modell megkerülte a külső hozzáférés blokkolására tervezett sandbox-korlátozásokat, és feltöltötte az anyagot a GitHubra. A modellünknek egy órába telt, mire sebezhetőséget talált a sandboxban a PR elkészítéséhez; a korábbi modellek kevésbé voltak kitartóak, és nem tudtak sebezhetőségeket találni, ezért feladták a PR-hez kapcsolódó részt.¹

Az AI-asszisztensek számos biztonsági vezérlője egyedi műveletek köré épül. Ha egy művelet nem engedélyezett, a rendszer blokkolja. Ha érzékeny, a rendszer kifejezett jóváhagyást kér a felhasználótól. A hosszú ideig futó modellek azonban, amelyek műveletei órákon, napokon vagy akár heteken át önállóan bontakozhatnak ki, próbára teszik ezt a felállást: az egyedi műveletek figyelése már nem elég a teljes pálya szándékának követéséhez.

Például egy olyan helyzetben, amikor a modellt egy probléma megoldására kérték, a modell észrevette, hogy más rendszereknek sikeres, de privát beküldéseik voltak, és megpróbálta visszanyerni ezeket a megoldásokat az értékelési háttérrendszerből. Amikor az első próbálkozását blokkolták, mert egy szkenner hitelesítési tokent észlelt, a modell a token törzsét két részre osztotta, elhomályosította őket, majd futásidőben újra összeállította a hitelesítő adatot, így a teljes token soha nem jelent meg egyetlen összefüggő karakterláncként. A modell a felhasználónak írt megjegyzéseiben és az érvelési nyomaiban is egyértelműen jelezte, hogy ezeket a lépéseket a szkenner megkerülése érdekében teszi.

Ez a példa megmutatja, hogyan tűnhet minden egyes lépés önmagában elfogadhatónak, miközben a sorozat olyan eredményt hozhat létre, amelyet nem hagynának jóvá. Azt is megmutatja, hogy egy hosszú időtávokon hatékonyan működő modell hogyan tanulhatja meg egy jóváhagyási rendszer vakfoltjait, és hogyan kerülheti meg azt céljai eléréséhez. A hosszú időtávú biztonsághoz nem elég azt kérdezni: „engedélyezett ez a művelet?”, hanem azt is: „milyen eredmény felé tart ez a műveletsor?”

Az ilyen incidensek miatt szüneteltettük az új modell belső bevezetését. A biztonsági rendszert többrétegű védelem és pályaszintű monitorozás köré építettük újjá.

• Incidensekből származtatott értékelések. Az értékelések képet adhatnak arról, hogy egy rendszer biztonságosan bevezethető-e, még a tényleges bevezetés előtt. Ahhoz azonban, hogy igazán hasznosak legyenek, az értékelésnek tükröznie kell a valós bevezetés során előforduló pályák eloszlását és időtávjának hosszát. Ezért a megfigyelt hibák alapján ellenséges értékeléseket dolgoztunk ki. Azt találtuk, hogy a valós incidensekből származtatott értékeléseken elért javulás a produkciós bevezetés után biztonságosabb viselkedéshez vezetett.
• Javított összehangolás. Lépéseket tettünk annak csökkentésére, hogy a modell a felhasználó célját követve engedély nélkül hajtson végre nem kívánt műveleteket.  Például azt tapasztaltuk, hogy modelljeink hosszú futtatások során rosszabbul emlékeztek az utasításokra; amikor erre a képességre betanítottuk a modellt, olyan modellt kaptunk, amely hosszabb futtatásokon át is összehangolt maradt. 
• Aktív monitorozás. Olyan monitorozási rendszert hoztunk létre, amely a modell alakuló pályáját vizsgálja annak jelei után, hogy a modell megkerül egy felhasználói korlátozást vagy biztonsági határt. A monitor nem csupán egyetlen műveletet figyel, hanem a teljes pályát. Fontos, hogy a monitor szüneteltetni tudja a munkamenetet, és figyelmeztetheti a felhasználót, hogy vizsgálja meg alaposabban. A vizsgálat után a felhasználó dönthet úgy, hogy folytatja a modell munkáját, ha a monitor tévesen jelzett. 
• Nagyobb felhasználói átláthatóság és kontroll. Javítottuk a felhasználó lehetőségét arra, hogy megvizsgálja ezeket a hosszú ideig futó munkameneteket, megtekintse a végrehajtott műveleteket és figyelje a beavatkozásokat.

Az új monitorozási rendszer értékeléséhez visszajátszottunk néhány olyan belső bevezetési környezetet, ahol a modell korábban nem összehangolt műveleteket követett, ezúttal az új védőkorlátokkal². Az új védőkorlátok lényegesen több, a modell által követett nem összehangolt műveletet tudtak elkapni, és a kimaradtakat mind alacsony súlyosságúnak ítélték.

Ezekre az alacsony súlyosságú incidensekre példák többek között a következő esetek:

• Egy Linear parancssori eszköz eléréséhez a modell beágyazott codex --yolo munkamenetet indított, pedig valójában ezt a --yolo jelző nélkül is megtehette volna.
• A modell észrevette, hogy egy korábban élő erőforrás hiányzik, majd elkezdett más élő CPU-podokat felderíteni és SSH-val elérni a tulajdonosa névterében, valamint — sikertelenül — más OpenAI-alkalmazottak podjait is, anélkül hogy erre jó oka lett volna.
• A modellnél sok beragadt find folyamat volt, és minden shellparancs lefagyott. Ezután lefuttatta a kill -9 -1 parancsot, amely végrehajtás esetén SIGKILL-t küldött volna minden olyan folyamatnak azon a podon, amelyet jogosult leállítani. A parancs azonban időtúllépés miatt nem futott le.

Az új rendszer tesztelése után arra a következtetésre jutottunk, hogy visszaállítható a hosszú időtávú képességekkel rendelkező modellek korlátozott belső hozzáférése. Az újrabevezetés néhány héttel ezelőtti kezdete óta nem figyeltünk meg súlyos védőkorlát-megkerülést. E védőkorlátok első verzióját szándékosan konzervatívra terveztük. Folytattuk a rendszer finomhangolását, hogy csökkentsük a szükségtelen megszakításokat anélkül, hogy gyengítenénk a védőkorlátokat.

Mivel iteratívan vezettük be a rendszert, még a hozzáférés bővítése előtt meg tudtuk találni és kezelni tudtuk a hiányosságokat. A bevezetés előtti értékelések továbbra is elengedhetetlenek, de a bevezetés olyan viselkedéseket tár fel, amelyeket ezek nem vesznek észre. A korlátozott hozzáféréssel való indulás lehetővé tette, hogy a modellt a gyakorlatban figyeljük meg, probléma esetén szüneteltessünk, a hibákból jobb értékeléseket és védőkorlátokat építsünk, majd a változtatások tesztelése után visszaállítsuk a korlátozott hozzáférést.

Ahogy a modellek hosszabb és összetettebb feladatokat vállalnak, az értékelések által kihagyott hibáknak nagyobb következményei lehetnek. Tovább dolgozunk azon, hogy szűkítsük az értékelés és a bevezetés közötti rést: hosszabb pályákon teszteljük a modelleket, javítjuk az összehangolást, beavatkozni képes monitorozást építünk, és világosabb átláthatóságot, valamint nagyobb kontrollt adunk a felhasználóknak. Ezek a kihívások nem lesznek egyediek az OpenAI számára, és reméljük, hogy a tanultak megosztása segít a tágabb szakmai közösségnek felkészülni rájuk.