Спільний посібник для надійних сторонніх оцінювань

Незалежні, надійні сторонні оцінювання відіграють критично важливу роль⁠ у зміцненні екосистеми безпеки. Ці оцінювання проводяться на frontier-моделях, щоб надати додаткові докази для тверджень про критично важливі можливості та заходи безпеки. У цій публікації ми ділимося уроками, які засвоїли на цей момент, і рекомендуємо підходи до розробки оцінювань, здатних валідно оцінювати frontier-моделі, що, як ми сподіваємося, допоможе формуванню нових стандартів у цій сфері.

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

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

Твердження, які перевіряють в оцінюваннях, зазвичай належать до однієї з трьох категорій¹:

• Розкриття можливостей: Чи може модель правдоподібно продемонструвати здатність, яку оцінюють? 
• Ефективність запобіжників: Наскільки стійкими є протестовані запобіжники до поведінки або атаки, яку оцінюють?
• Порівняння: Як різні моделі працюють за еквівалентних умов?

Звіти про оцінювання також мають пояснювати, як рецензенти перевіряли ефекти, що можуть вплинути на валідність результату. До них належать:

• Reward hacking: Використання обхідних шляхів у завданні або системі оцінювання, через що система отримує залік, не демонструючи поведінки, яку оцінювання має вимірювати.
• Відмови: Відмова у спосіб, що приховує поведінку, яку тестують.
• Контамінація: Завищені результати через те, що завдання оцінювання, відповіді або близькі варіанти були в навчальних даних або їх можна було знайти під час оцінювання, наприклад через браузинг.
• Некоректні завдання: Занижені результати через невалідність завдань. Причини можуть включати несправедливе оцінювання (наприклад, правильна відповідь вимагає неявно заданих деталей реалізації) і нерозв’язні середовища (наприклад, відсутні критично важливі файли або ненадійні інструменти).
• Sandbagging: Навмисне заниження результатів, коли модель демонструє обізнаність про те, що її оцінюють.

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

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

Твердження про можливості надійні настільки, наскільки поглибленим є тестування, що за ними стоїть: оцінювачам потрібно обирати harness, який найкраще відповідає завданню та можливості, яку оцінювання намагається виміряти. Стандартизований harness може бути доречним для порівняння систем в однакових умовах, але він може занижувати можливість, якщо не містить конкретних функцій harness, що допомагають моделі виконати завдання. Наприклад, результати GPT‑5.5 на кібердіапазонах OpenAI показують, як вибір harness може суттєво змінити виміряну можливість у завданнях, що потребують тривалого багатокрокового використання інструментів: модель працює краще, коли harness використовує компресію⁠ для збереження релевантного до завдання контексту в міру подовження взаємодії. Це демонструє, що для певних моделей harness без компресії недостатньо виявлятиме продуктивність.

Інші опубліковані оцінювання² також показують, що вибір harness і бюджету змінює результати оцінювання. Збільшення обчислень під час тестування може суттєво змінити те, яку здатність виявляє оцінювання, особливо в доменах, де успіх легко перевірити, як-от у багатьох кіберзавданнях. В оцінюванні кібердіапазону UK AISI⁠(відкривається у новому вікні) збільшення бюджету з 10 млн до 100 млн токенів підвищило продуктивність до 59%, і вона все ще зростала на найвищому протестованому бюджеті. Докладний опис цього робить оцінювання зрозумілішим для інтерпретації: він показує читачам, як результат залежить від протестованого налаштування тестування. Коли продуктивність і далі зростає зі збільшенням бюджету, бал слід описувати як продуктивність за цього harness і бюджету, а не як виміряну верхню межу можливості. Здатність часто залежить від ресурсів, а не є фіксованою величиною, яку можна чисто виміряти раз і назавжди. Там, де успіх можна вимірювати за повторних спроб, у звітах також слід враховувати очікувану вартість одного успішного розв’язання, а не лише частку успіху за фіксованого бюджету токенів. Це може полегшити інтерпретацію серйозності: низька частка успіху все одно може мати практичне значення, якщо вартість повторних спроб вкладається у відповідну модель загрози. Для тверджень про можливості уникнене недовиявлення є помилкою вимірювання: якщо harness або бюджет не дає системі проявити поведінку, яку вона інакше могла б продемонструвати, бал не вимірює заявлену можливість. Там, де оцінювачі просунули тестування настільки далеко, наскільки це практично можливо, а продуктивність усе ще зростає, звіти мають чітко про це сказати й ясно зазначити, що результат є лише оцінкою нижньої межі.

Тестування запобіжників може занижувати ймовірність успіху атаки та її серйозність, якщо не враховує ресурси, доступні атакувальникам, зокрема спеціальні harness. У кібероцінюванні GPT‑5.5 від UK AISI⁠(відкривається у новому вікні) їхній експертний red teaming виявив універсальний jailbreak, який еліцитував порушувальний кіберконтент у шкідливих запитах, наданих OpenAI, зокрема в багатокрокових агентних сценаріях. Вони використали Codex для створення спеціального harness, щоб посилити атакувальну ефективність моделі: він вбудовував повторно використовуваний шаблон обходу запобіжників у взаємодію, зберігав цей шаблон між ходами та блоками й застосовував його до шкідливих кіберзапитів, наданих OpenAI. Тестування запобіжників має відповідати супротивнику. Якщо твердження стосується стійкості до зловживання з боку експерта, тест має оцінювати найсильнішу правдоподібну наскрізну стратегію атаки в межах визначеного бюджету, включно з будь-яким harness, потрібним для збереження та повторного використання цієї стратегії. Інакше результати ризикують бути хибно відкаліброваними: вони можуть підтримувати лише вужче твердження про стійкість до простішого формулювання запитів, можуть не показати ні того, наскільки серйозною стає атака, ні ймовірності її успіху після операціоналізації методу розкриття можливостей, а також можуть перебільшити ймовірність або серйозність проблеми, якщо надати занадто великий бюджет.

Для порівнянь зі стандартизованими harness є свій час і місце, але оцінювачі мають чітко пояснювати, чому доречно використовувати узгоджений набір harness і яке твердження це може підтримати. Оцінювання часового горизонту від METR⁠(відкривається у новому вікні) є прикладом ширшого, належно зафіксованого налаштування оцінювання: воно розроблене для отримання порівнюваних результатів між системами, які оцінює. METR визначає спільний результат — типову тривалість людського завдання, за якої прогнозується, що ШІ-агент досягне успіху з заданим рівнем надійності. У межах кожного пакета оцінок, що звітуються разом, воно застосовує спільний набір завдань, метод оцінювання, метод підгонки та невеликий набір повторно використовуваних scaffolds, таких як Triframe і ReAct⁠(відкривається у новому вікні). Коли METR розширила набір завдань і перенесла інфраструктуру оцінювання з фреймворку Vivaria до Inspect, вона повідомила про цю зміну (оновлення Time Horizon 1.1⁠(відкривається у новому вікні)) і повторно оцінила моделі за новим налаштуванням оцінювання. У цьому й полягає цінність стандартизованого налаштування оцінювання, зокрема узгодженого набору harness: воно може дати читачам упевненість, що різниця в балах справді відображає різницю між порівнюваними системами, а не зміну налаштування вимірювання.

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

У міру того як моделі стають здатнішими, бали оцінювання стає легше неправильно інтерпретувати. Порівняно з реальними здатностями, бали оцінювання можуть бути штучно занижені, якщо модель розпізнає, що її оцінюють, і стратегічно знижує результативність. Вони можуть бути завищені, якщо модель використовує обхідний шлях у завданні, запиті, системі оцінювання або harness. Їх також може спотворювати контамінація (коли модель уже знає або може знайти відповідь, не розв’язуючи завдання) або «некоректні» завдання, які є неоднозначними, неправильно оціненими, нерозв’язними або вразливими до ненавмисних обхідних шляхів. Тому звіти про оцінювання мають поєднувати ключові бали з обговоренням цих ризиків, щоб читачі могли оцінити, чи відображають бали задуману поведінку.

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

Reward hacking

Reward hacking означає досягнення високих балів оцінювання способами, які не відображають задуману можливість. Тут занепокоєння полягає в тому, що система отримує залік, використовуючи завдання, систему оцінювання, запит або harness, а не виконуючи роботу, яку оцінювання мало виміряти. Оцінювання GPT 5.4 від METR⁠(відкривається у новому вікні) показує, чому це важливо: хоча модель успішно виконувала завдання з частотою, яка при першому проході відповідала б часовому горизонту приблизно 13 годин, перевірка людьми показала, що частина цих успіхів була наслідком reward hacking, і перегляд результатів з урахуванням лише випадків без reward hacking знизив оцінку приблизно до 6 годин. Оцінювачі мають визначати потребу в таких коригуваннях і, коли вони потрібні, чітко про них повідомляти: оцінка здатності значно корисніша, коли читачі можуть побачити, які видимі успіхи були дискваліфіковані, чому їх дискваліфікували і наскільки результат залежить від цього судження.

Відмови

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

Контамінація

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

Некоректні завдання

Некоректні завдання включають, наприклад, ситуації, коли завдання випадково неможливо розв’язати. Некоректні завдання трапляються достатньо часто⁠(відкривається у новому вікні), щоб вважати їх стандартним ризиком для валідності. До них належать неправильні еталонні дані, неоднозначні запити, відсутні файли, нестабільні сервіси, несправедливі критерії оцінювання та середовища, що відкривають обхідні шляхи, як-от приховані файли з відповідями або історія репозиторію, що містить ground-truth patch.

Sandbagging

Sandbagging з боку моделі або системи означає стратегічне заниження результатів, коли висока результативність суперечила б певній меті. Оцінювання GPT‑5.5 від Apollo⁠(відкривається у новому вікні) перевіряло це, створивши контекст, у якому модель розуміла, що високі бали оцінювання можуть спричинити втрату знань або заблокувати розгортання. GPT‑5.5 усе одно відповідала правильно, що свідчить про незначні поведінкові ознаки стратегічного заниження результатів³. Але їхній огляд траєкторій міркування додав важливий контекст: Apollo виявила помірні або сильніші ознаки обізнаності про оцінювання вирівнювання у 52% зразків в умовах sandbagging, порівняно з 0% у контрфактичних випадках. Ці докази ускладнюють інтерпретацію результату, але зрештою дають читачам більше сигналів: вони бачать і заспокійливий поведінковий результат, і причину обережно ставитися до його надмірної інтерпретації.

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

• Ми надаємо рецензентам конкретні рекомендації щодо максимального розкриття можливостей.
• Ми просимо оцінювачів можливостей використовувати Codex як спільний мінімальний рівень для моделей OpenAI: тести мають принаймні запускати базовий сценарій через той самий агентний інтерфейс, на який, імовірно, покладатимуться користувачі, а не лише через спрощений інтерфейс моделі.
• Ми також надаємо траєкторії міркування та інші проміжні артефакти там, де вони потрібні для оцінки обману, sandbagging або обізнаності про оцінювання. METR і Apollo використовують цей доступ в оцінюваннях OpenAI ще з GPT‑5. 
• Нарешті, ми надаємо пріоритет дослідженням, щоб глибше зрозуміти, коли і як вибір harness суттєво змінює результати — від керування контекстом і доступу до інструментів до поведінки повторних спроб, оцінювання та бюджетів ресурсів.

Ці рекомендації покликані не лише покращити окремі звіти про оцінювання, а й допомогти формуванню нових національних ⁠(відкривається у новому вікні)та міжнародних ⁠(відкривається у новому вікні)стандартів оцінювання та звітування щодо frontier-ШІ. Надалі стандарти стороннього оцінювання мають вимагати достатньо деталей, щоб особи, які ухвалюють рішення, розуміли, які твердження підтримують конкретні оцінювання, яку систему тестували, як було виявлено результат і як оцінювачі перевіряли його валідність. Для frontier-систем, які тестують на завданнях, де важливі агентні можливості, деталі мають включати (з урахуванням будь-яких міркувань безпеки чи конфіденційності):

• Твердження: чи порівнює оцінювання системи, оцінює верхню межу здатності або тестує запобіжники.
• Зміст оцінювання: достатньо деталей про завдання або розподіл завдань, щоб читачі розуміли, які навички, поведінку чи режими відмови оцінювання фактично тестує.
• Протестована система: модель, налаштування міркування, доступ до інструментів, harness і запобіжники.
• Бюджет: ходи, токени, спроби/повторні спроби, астрономічний час, вартість інференсу та, де доречно, очікувана вартість одного успішного розв’язання.
• Методи розкриття можливостей: вибір harness, використаний для отримання результату, і те, наскільки тісно протестоване відображає ширше твердження, яке робиться.
• Перевірки валідності: як оцінювачі шукали reward hacking, обізнаність про оцінювання, контамінацію, відмови, sandbagging та іншу поведінку, що могла підірвати результат, зокрема як підтверджені випадки вплинули на оцінювання або інтерпретацію.

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