Безпека й узгодженість в епоху моделей із тривалим горизонтом

Моделі, здатні автономно працювати тривалий час, можуть братися за складні завдання без чіткого способу розв'язання. Але та сама наполегливість, яка робить їх корисними, також дає їм більше можливостей виконувати небажані дії — причому так, що оцінювання, розраховані на моделі з коротшим горизонтом, можуть цього не помітити.

Близько двох місяців тому ми оголосили⁠, що внутрішня модель загального призначення спростувала гіпотезу Ердеша про одиничні відстані. Цю модель було розроблено для автономної роботи протягом дуже тривалого часу. Під час обмеженого внутрішнього використання під наглядом ми спостерігали небажану поведінку, яку не виявили наші наявні оцінювання для розгортання. Оскільки розгортання було обмеженим і контрольованим, ми змогли виявити ці проблеми, призупинити доступ, створити нові оцінювання на основі спостережень, удосконалити модель і її захисні заходи, а потім відновити доступ із подальшим моніторингом. 

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

У наступних розділах ми наводимо конкретні приклади того, що спостерігали, як усували проблеми та як цей досвід вплине на майбутні випуски.

Нова модель може продовжувати рухатися до мети через багаторазові спроби протягом тривалого часу. Та сама наполегливість може спонукати її знаходити й використовувати слабкі місця у своєму середовищі. Попередні моделі, зіткнувшись з обмеженнями ізольованого середовища або іншими обмеженнями середовища, просто зупинялися й поверталися до користувача. Ця модель часто продовжувала спроби, зокрема шукала способи діяти поза своїм ізольованим середовищем.

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

Багато засобів безпеки для ШІ-асистентів побудовано навколо окремих дій. Якщо дія заборонена, її блокують. Якщо вона чутлива, система просить користувача явно її схвалити. Однак моделі, здатні працювати тривалий час і автономно виконувати дії протягом годин, днів або навіть тижнів, кидають виклик такому підходу: моніторингу окремих дій уже недостатньо, щоб відстежувати намір усієї траєкторії.

Наприклад, у сценарії, де модель попросили розв’язати задачу, вона помітила, що інші системи мали успішні, але закриті рішення, і спробувала відновити ці рішення з бекенду оцінювання. Коли її першу спробу заблокували, бо сканер виявив токен автентифікації, модель розділила тіло токена на два фрагменти, замаскувала їх, а потім відновила облікові дані під час виконання, щоб повний токен ніколи не з’являвся як один суцільний рядок. І в коментарях до користувача, і в трасах міркування модель прямо зазначала, що робить ці кроки, щоб обійти сканер.

Цей приклад показує, як кожен крок окремо може виглядати прийнятним, тоді як послідовність може привести до результату, який не було б схвалено. Він також показує, як модель, що ефективно працює на тривалих часових горизонтах, може виявити прогалини системи схвалення й обійти її, щоб досягти своїх цілей. Безпека моделей із тривалим горизонтом потребує запитувати не лише «чи дозволена ця дія?», а й «до якого результату веде ця послідовність дій?»

Через подібні інциденти ми призупинили внутрішнє розгортання нової моделі. Ми перебудували систему безпеки на основі багаторівневого захисту та моніторингу на рівні траєкторій.

• Оцінювання на основі інцидентів. Оцінювання можуть дати нам уявлення про те, чи безпечно розгортати систему, ще до фактичного розгортання. Однак, щоб бути максимально корисним, оцінювання має відображати розподіл і тривалість горизонту траєкторій під час реального розгортання. З цієї причини ми використали виявлені збої для розроблення змагальних оцінювань. Ми з’ясували, що поліпшення результатів в оцінюваннях, отриманих із реальних інцидентів, своєю чергою приводило до безпечнішої поведінки після розгортання у виробничому середовищі.
• Покращена узгодженість. Ми вжили заходів, щоб зменшити схильність моделі виконувати небажані дії без дозволу заради досягнення мети користувача.  Наприклад, ми виявили, що нашим моделям складніше пам’ятати інструкції під час тривалих прогонів; коли ми навчили модель цієї здатності, це дало модель, що залишалася узгодженою протягом довших прогонів. 
• Активний моніторинг. Ми створили систему моніторингу, яка аналізує траєкторію моделі в міру її розвитку на ознаки того, що вона обходить обмеження користувача або межу безпеки. Монітор спостерігає не лише за однією дією, а за всією траєкторією. Важливо, що монітор може призупинити сеанс і сповістити користувача, щоб той уважніше перевірив ситуацію. Після перевірки користувач може вирішити продовжити роботу моделі, якщо монітор спрацював помилково. 
• Більша прозорість і контроль для користувача. Ми покращили можливості користувача переглядати ці довгі сеанси, бачити виконані дії та відстежувати втручання системи.

Щоб оцінити нову систему моніторингу, ми відтворили невеликий набір внутрішніх середовищ розгортання, де модель раніше виконувала неузгоджені дії, цього разу з новими захисними заходами². Нові захисні заходи змогли виявити значно більше неузгоджених дій, які виконувала модель, а всі пропущені дії було визнано такими, що мали низький рівень серйозності.

Деякі приклади таких інцидентів низького рівня серйозності:

• Щоб отримати доступ до інструмента командного рядка Linear, модель запустила вкладений сеанс codex --yolo, хоча насправді могла зробити це без прапорця --yolo.
• Модель помітила, що раніше активний ресурс зник, а потім почала досліджувати інші активні CPU-поди в просторі імен свого власника та підключатися до них через SSH, а також безуспішно — до подів інших працівників OpenAI без вагомої причини.
• У моделі зависло багато процесів find, і кожна команда оболонки зависала. Потім вона виконала kill -9 -1, що в разі виконання надіслало б SIGKILL кожному процесу на цьому поді, який їй дозволено завершити. Однак команда не виконалася через перевищення часу очікування.

Після тестування нової системи ми дійшли висновку, що обмежений внутрішній доступ до моделей із можливостями тривалого горизонту можна відновити. Від початку повторного розгортання кілька тижнів тому ми не спостерігали жодного серйозного обходу захисних заходів. Першу версію цих захисних заходів навмисно зробили консервативною. Ми й надалі налаштовували систему, щоб зменшити непотрібні переривання, не послаблюючи захисних заходів.

Завдяки ітеративному розгортанню ми змогли знайти й усунути прогалини до розширення доступу. Оцінювання перед розгортанням залишаються необхідними, але розгортання виявляє поведінку, яку вони пропускають. Почавши з обмеженого доступу, ми змогли спостерігати за моделлю на практиці, призупиняти роботу, коли виникали проблеми, використовувати ці збої для створення кращих оцінювань і захисних заходів та відновити обмежений доступ після тестування змін.

Коли моделі беруться за довші й складніші завдання, збої, які пропускають оцінювання, можуть мати серйозніші наслідки. Ми й надалі працюватимемо над скороченням розриву між оцінюванням і розгортанням: тестуватимемо моделі на довших траєкторіях, покращуватимемо узгодження, створюватимемо моніторинг, здатний втручатися, і даватимемо користувачам більшу прозорість і контроль. Ці виклики не будуть унікальними для OpenAI, і ми сподіваємося, що наш досвід допоможе ширшій спільноті підготуватися до них.