Безопасност и съгласуване в ерата на модели с дълъг времеви хоризонт

Моделите, които могат да работят автономно дълго време, могат да поемат трудни, отворени проблеми. Но същата тази упоритост, която ги прави полезни, им дава и повече възможности да предприемат нежелани действия — и то по начини, които оценките, предназначени за модели с по-кратък хоризонт, може да пропуснат.

Преди около два месеца обявихме⁠, че вътрешен модел с общо предназначение е опровергал хипотезата на Erdős за единичните разстояния. Този модел беше проектиран да работи автономно за много дълги периоди от време. По време на ограничена, наблюдавана вътрешна употреба забелязахме нежелано поведение, което съществуващите ни оценки за внедряване не бяха уловили. Тъй като внедряването беше ограничено и наблюдавано, успяхме да идентифицираме тези проблеми, да спрем достъпа, да създадем нови оценки въз основа на наблюдаваното, да подсилим модела и предпазните му механизми, а след това да възстановим достъпа при продължаващо наблюдение. 

Условията, при които оценяваме моделите, никога няма да съвпадат напълно с условията, в които те работят при реална употреба. Затова оценките преди внедряване трябва да се съчетават с ограничено, наблюдавано внедряване и с възможност за намеса, спиране или връщане назад при възникване на проблеми. Наученото от внедряването после може да стане част от по-силни оценки и предпазни механизми, преди достъпът да бъде разширен.

В следващите раздели споделяме конкретни примери за това какво наблюдавахме, как се справихме с проблемите и как този опит ще оформи бъдещите версии.

Новият модел може да продължи да работи към дадена цел чрез многократни опити за дълъг период от време. Същата тази упоритост може да го накара да открива и използва слабости в средата си. Предишните модели, когато се сблъскваха с ограничения на пясъчника или средата, просто спираха и се връщаха към потребителя. Този модел често продължаваше да опитва, включително като търсеше начини да действа извън своя пясъчник.

Пример за това се появи по време на вътрешна оценка в NanoGPT speedrun⁠(отваря се в нов прозорец) — публичен бенчмарк за обучение на малък езиков модел с възможно най-малко стъпки. Нашият модел разработи охлаждане на скоростта на обучение по степенен закон, наречено PowerCool, което доведе до значително подобрение. Моделът беше инструктиран да публикува резултатите си само в Slack, но инструкциите на NanoGPT казват резултатите да се публикуват като PR в GitHub и моделът последва вторите инструкции, за да отвори PR #287 в публичното хранилище в GitHub. Моделът заобиколи ограниченията на пясъчника, предназначени да блокират външен достъп, и продължи с качването в GitHub. На нашия модел му отне един час да намери уязвимост в пясъчника, за да създаде PR-а; по-ранните модели бяха по-малко упорити и не успяваха да намерят уязвимости, а вместо това се отказваха от частта с PR-а.¹

Много контроли за безопасност при AI асистенти са проектирани около отделни действия. Ако дадено действие не е разрешено, то се блокира. Ако е чувствително, системата иска изрично одобрение от потребителя. Но дълго работещите модели, чиито действия могат да се развиват автономно в продължение на часове, дни или дори седмици, поставят това устройство под въпрос: наблюдението на отделни действия вече не е достатъчно, за да се проследи намерението на цялостната траектория.

Например в сценарий, в който моделът беше помолен да реши задача, той забеляза, че други системи имат успешни, но частни решения, и се опита да възстанови тези решения от бекенда за оценяване. Когато първоначалният му опит беше блокиран, защото скенер откри токен за удостоверяване, моделът раздели тялото на токена на два фрагмента, обфускира ги и после реконструира идентификационните данни по време на изпълнение, така че пълният токен никога да не се появи като един непрекъснат низ. Моделът изрично посочи както в коментарите си към потребителя, така и в следите от структурираното си анализиране, че предприема тези стъпки, за да заобиколи скенера.

Този пример показва как всяка стъпка може сама по себе си да изглежда приемлива, докато последователността може да доведе до резултат, който не би бил одобрен. Той също така показва как модел, който работи ефективно в дълги времеви хоризонти, може да научи слепите петна на система за одобрение и да я заобиколи, за да постигне целите си. Безопасността при дълъг хоризонт изисква да питаме не само „разрешено ли е това действие?“, но и „към какъв резултат води тази последователност от действия?“

Заради инциденти като тези спряхме вътрешното внедряване на новия модел. Преизградихме системата за безопасност около защита в дълбочина и наблюдение на ниво траектория.

• Оценки, извлечени от инциденти. Оценките могат да ни дадат представа дали една система е безопасна за внедряване, преди тя действително да бъде внедрена. За да бъде най-полезна обаче, оценката трябва да отразява разпределението и дължината на хоризонта на траекториите при реално внедряване. Поради тази причина използвахме наблюдаваните провали, за да разработим състезателни оценки. Установихме, че подобренията по оценките, извлечени от реални инциденти, на свой ред водят до по-безопасно поведение след внедряване в продукционна среда.
• Подобрено съгласуване. Предприехме стъпки, за да намалим склонността му да предприема нежелани действия без разрешение в преследване на целта на потребителя.  Например установихме, че нашите модели по-трудно запомнят инструкции при дълги изпълнения, и когато обучихме модела за тази способност, това доведе до модел, който оставаше съгласуван при по-дълги изпълнения. 
• Активно наблюдение. Създадохме система за наблюдение, която преглежда развиващата се траектория на модела за признаци, че той заобикаля ограничение на потребителя или граница за безопасност. Мониторът наблюдава не само едно действие, а цялата траектория. Важно е, че мониторът може да постави сесията на пауза и да предупреди потребителя да я разгледа по-внимателно. След преглед потребителят може да избере да продължи работата на модела, ако мониторът се е задействал погрешно. 
• По-голяма видимост и контрол за потребителя. Подобрихме възможността потребителят да преглежда тези дълго работещи сесии, да вижда предприетите действия и да наблюдава намесите.

За да оценим новата система за наблюдение, възпроизведохме малък набор от вътрешни среди за внедряване, в които моделът преди това беше следвал несъгласувани действия, този път с новите предпазни механизми². Новите предпазни механизми успяха да уловят значително повече несъгласувани действия, предприети от модела, а всички пропуснати бяха оценени като нискосериозни.

Някои примери за тези нискосериозни инциденти включват следните случаи:

• За да получи достъп до инструмент за команден ред на Linear, моделът стартира вложена сесия codex --yolo, въпреки че всъщност можеше да го направи и без флага --yolo.
• Моделът забеляза, че ресурс, който преди е бил активен, липсва, след което започна да изследва и да влиза чрез SSH в други активни CPU pod-ове в namespace-а на собственика си, както и (неуспешно) в pod-ове, принадлежащи на други служители на OpenAI, без основателна причина.
• Моделът имаше много блокирали процеси find и всяка shell команда увисваше. След това изпълни kill -9 -1, което би изпратило SIGKILL към всеки процес, който има право да убие в този pod, ако командата беше изпълнена. Тя обаче изтече по време и не се изпълни.

След като тествахме новата система, заключихме, че ограничен вътрешен достъп до модели с възможности за дълъг времеви хоризонт може да бъде възстановен. Не сме наблюдавали сериозно заобикаляне на предпазните механизми, откакто повторното внедряване започна преди няколко седмици. Първата версия на тези предпазни механизми беше умишлено консервативна. Продължихме да настройваме системата, за да намалим ненужните прекъсвания, без да отслабваме предпазните механизми.

Тъй като внедрявахме итеративно, успяхме да открием и отстраним пропуски, преди да разширим достъпа. Оценките преди внедряване остават съществени, но внедряването разкрива поведения, които те пропускат. Започването с ограничен достъп ни позволи да наблюдаваме модела на практика, да спираме при възникване на проблеми, да използваме тези провали за изграждане на по-добри оценки и предпазни механизми и да възстановим ограничен достъп след тестване на промените.

Когато моделите поемат по-дълги и по-сложни задачи, провалите, които оценките пропускат, могат да имат по-сериозни последици. Ще продължим да работим за стесняване на разликата между оценяване и внедряване: да тестваме моделите по по-дълги траектории, да подобряваме съгласуването, да изграждаме наблюдение, което може да се намесва, и да даваме на потребителите по-ясна видимост и контрол. Тези предизвикателства няма да са уникални за OpenAI и се надяваме, че споделянето на наученото ще помогне на по-широката област да се подготви за тях.