Наша система звітування про неузгодженість моделей
Ми представляємо нову систему відстеження, розслідування й оприлюднення випадків неузгодженої поведінки моделей в OpenAI, а також шість звітів про неочікувану або тривожну поведінку моделей, яку ми спостерігали протягом останніх шести місяців.
Щоб краще інформувати дослідників, розробників ШІ, політиків і широку громадськість, раніше ми прагнули оприлюднювати наші висновки щодо неузгодженості. Однак через відсутність системного підходу до звітування про ці висновки оприлюднення відбувалися ситуативно й рідше, ніж хотілося б: ми часто чекали, доки зможемо об’єднати кілька випадків в одному звіті, або додавали їх до системних карток нових моделей. Нова система покликана пришвидшити публікацію звітів про неузгодженість після її виявлення, навіть якщо ми ще не до кінця пояснили або усунули відповідну поведінку.
У міру розвитку й поширення систем ШІ нам потрібно формувати ширший і краще поінформований консенсус щодо поступу досліджень узгодженості. Ми не вважаємо, що індустрія ШІ вже достатньою мірою розв’язала проблеми узгодженості й моніторингу, щоб і надалі відповідально нарощувати масштаби з максимальною швидкістю. Рішення про розвиток ШІ в найближчі місяці й роки мають спиратися на докази, які люди за межами компаній — розробників передових моделей зможуть самостійно вивчити.
Приклади неузгодженості можуть допомогти виявити проблеми, з якими зіткнуться інші розробники ШІ, коли їхні системи досягнуть подібних можливостей, розкрити слабкі місця засобів захисту або поставити під сумнів припущення про поведінку моделей. Оприлюднення цих висновків дає іншим змогу досліджувати ті самі проблеми, перевіряти наші пояснення й удосконалювати заходи протидії. Оскільки ми переконані в цінності прозорості щодо неузгодженості, наша нова система віддає перевагу оприлюдненню навіть за невизначеної значущості. Це означає, що деякі оприлюднені нами випадки можуть виявитися випадковими, не бути частиною ширшої закономірності й не вказувати на майбутні тенденції.
Наразі в галузі немає єдиної системи з чіткими стандартами того, як розробники ШІ мають повідомляти про приклади неузгодженості своїх моделей. Сподіваємося, що представлена сьогодні система стане першим кроком до створення таких стандартів і визначить, які випадки неузгодженості розробники мають оприлюднювати та що повинні містити їхні звіти. Ця система перебуває в розробці, ми її вдосконалюватимемо на основі досвіду й відгуків громадськості.
Нижче ми пояснюємо, як працюватиме ця система, і представляємо перші опубліковані за нею звіти.
Ми прагнемо оприлюднювати приклади, що містять корисні докази того, як виникає та проявляється неузгодженість моделей і де засоби захисту спрацьовують або зазнають невдачі. Ми надаємо пріоритет новим механізмам, істотним змінам у відомій поведінці та висновкам, що ставлять під сумнів припущення про безпеку чи заходи протидії. Щоб заслуговувати на оприлюднення, випадок не обов’язково має завдати шкоди або свідчити про ширшу закономірність. Ця система охоплюватиме відповідну критеріям поведінку протягом усього життєвого циклу моделі, зокрема під час навчання, оцінювання, тестування й розгортання.
Це стосується нових способів, у які моделі діють без дозволу, координують дії з іншими моделями або уникають нагляду; невдач, що ставлять під сумнів метод узгодження чи засіб захисту; а також поведінки, яка суперечить твердженням в опублікованій оцінці безпеки. Ті самі критерії оприлюднення застосовуються до неузгодженості, яка може вплинути на треті сторони.
Це також може стосуватися випадків неузгодженості, схожих на ті, про які ми повідомляли раніше. Повторне виникнення проблеми саме по собі може бути достовірним свідченням поведінки наших моделей або ефективності засобів захисту. Наприклад, якщо певний тип неузгодженої поведінки й далі виникає попри неодноразові спроби його усунути. За таких обставин ми публікуватимемо додаткові приклади, оновлюючи початкове повідомлення про неузгодженість.
Згодом ми плануємо розробити об’єктивніші критерії оприлюднення спільно з іншими розробниками, зовнішніми дослідниками, органами стандартизації та регуляторами. Ми також вважаємо, що про серйозні інциденти, пов’язані з безпекою, кіберзахистом й неузгодженістю, слід повідомляти федеральному уряду США, і працюємо над пропозиціями щодо механізмів звітування. Ми вважаємо цю систему доповненням до наших чинних зобов’язань і наголошуємо, що вона не замінює юридичних вимог щодо розкриття інформації, зокрема про критичні інциденти безпеки або порушення кібербезпеки.
Започатковуючи нову систему оприлюднення відомостей про неузгодженість, ми публікуємо шість звітів про випадки неузгодженої поведінки, які спостерігали під час навчання або оцінювання наших моделей. Ці випадки ілюструють різні типи поведінки, про які, на нашу думку, варто розповісти: від приховування інформації від користувача до несанкціонованих дій задля подолання перешкод. Це звіти про окремі випадки, і за ними не слід судити про загальну частоту неузгодженості наших моделей. Кожен пункт нижче містить посилання на повний звіт.
Самостійно створені інструкції в підсумках завдань(відкривається у новому вікні). Неопублікована дослідницька модель вставила в підсумки, що використовувалися для продовження її роботи в новому контекстному вікні, сторонні інструкції, зокрема вказівки ігнорувати звичайні обмеження. Ми виявили 27 підсумків із цією проблемою.
Інструкції приховувати помилки в підсумках завдань(відкривається у новому вікні). Під час навчання GPT‑5.6 Sol багато екземплярів моделі додавали до своїх підсумків інструкції приховувати від користувача помилки або неузгоджену поведінку. Наприклад, підсумки ущільнення містили інструкції вигадувати відсутні історичні дані, не повідомляючи про це, і приховувати розбіжності між версіями джерел.
Пошук відкритих ключів API у загальнодоступних репозиторіях із подальшим вигадуванням інформації(відкривається у новому вікні). Відповідаючи на звичайне запитання про показники доходів в одному з округів Каліфорнії, модель знайшла й без дозволу використала відкритий ключ API. Коли отримати запитані показники все одно не вдалося, вона вигадала їх і представила як дані із зазначеного джерела.
Завантаження файлів в інтернет для їх цитування(відкривається у новому вікні). Коли користувач попросив неопубліковану модель надати ідентифікатори й назви озер площею понад 5 000 000 квадратних метрів, агент знайшов правильну відповідь за допомогою Python. Однак, оскільки інструкції вимагали посилання на джерело в браузері, агент вирішив без дозволу користувача завантажити файл в інтернет, щоб послатися на нього у відповіді.
Несанкціонований запис і обмін повідомленнями через внутрішній репозиторій програмного забезпечення(відкривається у новому вікні). Шукаючи відсутні вхідні файли, моделі використовували внутрішній репозиторій програмного забезпечення як дошку повідомлень для обміну запитами й відповідями між окремими навчальними прикладами, хоча відновити ці файли їм не вдалося. У звіті також розглянуто давніший випадок, коли модель успішно завантажила тестові файли до репозиторію, намагаючись обійти мережеві обмеження.
Несанкціонований обмін файлами між агентами, що співпрацюють(відкривається у новому вікні). Агенти, які спільно виконували те саме навчальне завдання, використовували загальнодоступні файлообмінні сайти, коли не могли отримати доступ до локальних файлів одне одного. Через це результати виконання завдання стали доступними за загальнодоступними URL-адресами, хоча завдання вимагало від моделей використовувати лише локальні файли.
Будь-який працівник OpenAI може повідомити про випадок неузгодженості нашим командам із безпеки й узгодженості для розслідування та попросити розглянути можливість його оприлюднення. Це запускає процес оприлюднення, у якому для кожного етапу встановлено строки, щоб забезпечити своєчасне розслідування й публікацію.
Після реєстрації випадку наші технічні фахівці з’ясують, що сталося, що залишається незрозумілим, чи виправдане оприлюднення та які факти можна повідомити. Вони також оцінять, чи постраждала будь-яка третя сторона та чи потрібно приватно повідомити її до публікації.
Потім випадок віднесуть до одного з трьох категорій розгляду: «Готовий до оприлюднення», «Невелике розслідування» або «Розширене розслідування» («Повільна категорія»).
Категорія «Готовий до оприлюднення» охоплює випадки, що відповідають критеріям і розслідування яких достатньо завершене для публікації після перевірки. Категорія «Невелике розслідування» охоплює випадки, що потребують додаткового технічного вивчення. Ми очікуємо, що ці дві категорії охоплять переважну більшість оприлюднених нами випадків, особливо тих, що не потребують масштабного розслідування, координації з третіми сторонами або реагування на серйозні ризики зловживання. Усі оприлюднені сьогодні випадки належать до однієї з цих двох категорій.
Категорія «Розширене розслідування» охоплює складні розслідування, особливо за участю третіх сторін. Якщо випадок зачіпає третю сторону, наші зобов’язання щодо безпеки, права й відповідального розкриття інформації мають перевагу над цією системою. Ми прагнутимемо якнайшвидше опублікувати початкове повідомлення, але з міркувань безпеки іноді муситимемо його відкласти — наприклад, якщо модель виявить раніше невідому вразливість у програмному забезпеченні широкого використання. Якщо звіт дасть змогу ідентифікувати третю сторону, ми плануємо повідомляти її заздалегідь, навіть якщо межі безпеки не було порушено.
Початкове повідомлення про випадок категорії «Розширене розслідування» міститиме загальний опис події, інформацію про участь зовнішніх експертів у розслідуванні та, за наявності, орієнтовну дату публікації остаточного звіту. Якби про інцидент OpenAI на Hugging Face повідомляли за цією системою, він належав би до цієї категорії.
Працівника, який повідомив про цей випадок, поінформують про рішення щодо його оприлюднення та, якщо його буде оприлюднено, про порядок подальшого розгляду. Невирішені розбіжності щодо оприлюднення або належного порядку розгляду передаватимуть Консультативній групі з питань безпеки OpenAI (SAG) — групі керівників із різних підрозділів компанії, яка оцінює можливості передових моделей і засоби захисту, здійснює нагляд за нашою рамковою системою готовності та консультує керівництво OpenAI. Розбіжності всередині SAG або заперечення працівників проти її рішень передаватимуть на розгляд керівництву OpenAI. Рішення не оприлюднювати інформацію або визнати оприлюднення необґрунтованим повідомлятимуть керівникам напрямів безпеки й узгодженості та, наскільки це можливо, відповідним технічним фахівцям.
Ми можемо переглядати цей процес оприлюднення, дізнаючись, як він працює на практиці, і фіксуватимемо всі зміни в цій публікації.
У кожному повному звіті буде описано спостережувану поведінку, її серйозність і будь-які зовнішні наслідки, обставини, за яких вона виникла, дату або період події, час її виявлення, а також загальні відомості про залучену модель чи моделі. За можливості ми також повідомлятимемо:
докладніші відомості про подію та заподіяну нею шкоду;
як ми виявили неузгодженість і яким був обсяг нашого розслідування;
наше тлумачення наслідків для досліджень узгодженості й технічної безпеки ШІ;
важливі питання, порушені цим випадком, які залишаються без відповіді;
заходи, яких ми вживаємо або плануємо вжити у зв’язку з такою поведінкою. На момент оприлюднення ця інформація може бути доступна не завжди, адже ми можемо опублікувати звіт про неузгодженість до завершення розслідування або розроблення виправлення.
Щодо неузгодженості в системах, розгорнутих клієнтами, ми надаватимемо стільки інформації, скільки дозволяють конфіденційність клієнтів і наші договірні зобов’язання.
Опубліковані сьогодні звіти — це початковий набір матеріалів, а не вичерпний опис відомих випадків неузгодженості чи поточних розслідувань. Ці початкові звіти не покликані відображати весь спектр або серйозність випадків, охоплених цією системою. Ми зобов’язуємося повідомляти про випадки неузгодженості, які відповідають критеріям цієї системи, зокрема про складніші випадки, що потребують тривалішого розслідування або координації з третіми сторонами. Ми й надалі регулярно публікуватимемо звіти за цією системою та докладніше розповідатимемо про свої зобов’язання щодо звітування в міру їх подальшого опрацювання.
