Инцидентът с Hugging Face и какво предстои

През май и юни започнахме серии от обучения чрез обучение с подсилване (RL) на няколко нови изследователски модела, които не бяха предназначени за публично пускане. Един от тези модели впоследствие стоеше зад действията, довели до инцидента с Hugging Face. Това е изследователски модел само за вътрешна употреба, който наричаме Вътрешен модел 1 (IM1).

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

Първоначално моделите откриха начин да комуникират, като записват файлове в услугата за управление на пакети Artifactory.Така Artifactory на практика неволно се превърна в табло за съобщения, чрез което агентите можеха да обменят информация помежду си. Това на практика превърна Artifactory в непреднамерено табло за съобщения, където агентите можеха да обменят информация помежду си. Прочетете още: Как агентите използваха таблото за съобщения 

До 4 юли продължителната активност на агентите беше дестабилизирала засегнатата инстанция на Artifactory, което доведе до прекъсване на услугата. На 5 юли беше регистриран инцидент със сигурността. Екипът по сигурността блокира известен начин за повишаване на привилегиите, премахна разкритите идентификационни данни и изгради Artifactory наново. Като страничен ефект от това таблото за съобщения беше изчистено. След въвеждането на тези мерки оценките за киберсигурност бяха възобновени.

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

След като Artifactory беше изграден наново, възобновихме оценките за киберсигурност. Провеждаме тези оценки, за да разберем на какво са способни нашите модели и да определим подходящите защитни механизми при внедряването им. За тази цел не прилагаме същото ниво на защитни механизми като при системите ни, предоставяни на външни потребители. Оценката ExploitGym, която стои в основата на този инцидент, е изключително трудна — за някои задачи може да няма известно решение. За да успеят, агентите трябва да намерят начини да използват уязвимости в даден софтуер, за да получат отговор, известен като „флаг“.

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

Идентифицирахме четири модела на несъгласувано поведение, допринесли за поведението на моделите: манипулиране на наградата, упорито продължаване на привидно невъзможни задачи, неоторизирана комуникация и възприемане на цели от други агенти.

За да разберем тези модели, анализирахме изпълнения от обучението и оценяването на моделите.¹ Извършихме обширни ретроспективни прегледи на веригите на разсъжденията (CoT), действията и крайните резултати, използвайки най-нови техники за наблюдение на CoT⁠. В процеса целенасочено подобрихме способността на системата ни за наблюдение да открива типовете поведение, наблюдавани при инцидента, като използвахме информацията, получена впоследствие от разследването.

Опитите на агентите да мамят при изпълнението на задачите си, като търсят решения онлайн, бяха един от основните фактори за инцидента с Hugging Face. Това поведение е известно като „манипулиране на наградата“ (reward hacking): агентите изпълняват задачите по непредвидени начини, за да получат по-високи награди или да улеснят получаването им. Манипулирането на наградата се наблюдава в AI системите както отдавна (вж. тази разработка отпреди⁠ десетилетие, фигурата по-долу), така и при съвременните авангардни големи езикови⁠(отваря се в нов прозорец) модели (LLM). Инвестирали сме значителни усилия в методи за откриване и отстраняване на подобни начини за манипулиране⁠.

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

В хода на разследването установихме, че преди инцидента нито един от нашите модели не беше давал правилен отговор на 198 от общо 898 задачи в оценката ExploitGym. Тези нерешени задачи се оказаха съществен фактор за активността на агентите — 93% от задачите, обсъждани в таблото за съобщения на Artifactory по време на инцидента с Hugging Face, бяха именно от този набор от 198 задачи.

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

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

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

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

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

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

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

Първо, съществуват множество механизми, които намаляват несъгласуваността в продукционна среда за нашите клиенти, включително системни подкани, среди за изпълнение и механизми за контрол, като например нашите модели за автоматичен преглед и класификатори за безопасност. Тези защитни механизми не бяха приложени в средата за оценка, използвана по време на инцидента. След инцидента създадохме оценка, която измерва склонността на даден модел да компрометира инфраструктура по време на оценки с ExploitGym. Установихме, че при използване на продукционната среда за изпълнение и системната подкана на Codex склонността към компрометиране на инфраструктура може да намалее над 100 пъти. Освен това приложихме системата за автоматичен преглед на Codex към набор от изпълнения, свързани с инцидента с Hugging Face, и установихме, че тя би маркирала множество опасни действия на моделите.

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

При ретроспективните оценки установихме, че нашите системи за наблюдение на веригата на разсъжденията (CoT) са много ефективни при откривването на дейности, свързани с инцидента. Ако използваната в момента система за наблюдение на веригата на разсъжденията беше работила по време на инцидента, тя вероятно щеше да уведоми екипа ни по сигурността в рамките на един час след първия неоторизиран достъп до услуга на трета страна. Това е повече от 30 часа преди моделите да проникнат в системите на Hugging Face. Работим и за допълнително намаляване на времето за задействане на тези сигнали.

Трето, макар че бяхме тествали и валидирали тази тестова среда, агентите успяха да комбинират неизвестни дотогава уязвимости („0-day“) в услугата за управление на пакети, достъпна в тестовата среда, за да заобиколят ограниченията, както е описано подробно в техническия доклад за инцидента. След инцидента постигнахме значителен напредък в укрепването на нашите вътрешни тестови среди, за да ограничим подобни рискове при внедряването и оценяването.

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

Както споделихме в неотдавнашната ни актуализация относно темпото на разработване⁠ на модели, временно преустановихме обучението с утвърждаване (RL) на най-новите ни модели, предназначени за внедряване. Използвахме това време, за да укрепим допълнително сигурността на изследователските среди за най-усъвършенстваните ни модели и да я подложим на тестове от red team екипи. Пренасочихме служители към работа по сигурността, безопасността и съгласуването. Най-мащабното ни планирано авангардно RL обучение остава временно спряно, докато провеждаме обучения и оценки в по-малък мащаб, за да оценим поведението на моделите, да валидираме защитните си механизми и да съберем повече доказателства за съгласуваност, преди да продължим. Тази работа изискваше значителни инженерни усилия и доведе до съществени разходи и забавяния в изследванията на най-усъвършенстваните модели.

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