Як Google DeepMind перевіряла Gemini, не розкриваючи ні модель, ні тестові запити

Google DeepMind разом із Singapore AI Safety Institute, OpenMined, AVERI та MLCommons випробувала спосіб оцінювати пропрієтарну фронтирну модель, не передаючи розробнику конфіденційні запити й не відкриваючи зовнішнім оцінювачам ваги моделі. У пілоті, оголошеному 27 серпня 2026 року, тестували Gemini 2.5 Flash-Lite. Google назвала його першим подвійним сліпим оцінюванням пропрієтарної фронтирної моделі ШІ. 1213

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

Що саме тестували

Для пілоту відібрали невелику приватну частину сімейства бенчмарків MLCommons AILuminate. За даними AVERI, запити раніше не передавали Google DeepMind і використали для перевірки поведінки моделі в таких сферах, як допомога в кібернападах, хімічні та біологічні небезпеки, мова ворожнечі, самоушкодження та підбурювання до насильницьких злочинів. 1

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

Як працював «подвійний сліпий» режим

Оцінювання проводили в Confidential Space — сервісі Google Cloud Confidential Computing — на віртуальній машині A3 Confidential VM. Згідно з технічним звітом, Intel TDX шифрувала й ізолювала пам’ять хоста, а конфіденційний графічний процесор NVIDIA H100 захищав ваги моделі у власній пам’яті за допомогою апаратного шифрування. Зашифровані з’єднання передавали запити оцінювачів і ресурси Google у захищене середовище. 13

Архітектура також передбачала обмеження для самого процесу та його результатів. Серед них — зашифровані канали передавання даних, апаратні міжмережеві екрани, одноразовий життєвий цикл ізольованого середовища та політичний рівень OpenMined PySyft. Модель, код інференсу, запити й код оцінювання об’єднувалися лише всередині схваленого апаратно захищеного середовища. Там виконувалася погоджена операція, після чого назовні поверталися лише обмежені результати. 13

Навіщо потрібна віддалена атестація

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

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

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

Яку проблему це має вирішити

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

Подвійне сліпе оцінювання пропонує третій варіант між двома недосконалими схемами:

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

Отже, пілот демонструє правдоподібний механізм взаємної конфіденційності. Водночас сам по собі він не доводить, що висновки про безпеку моделі є повними або остаточними.

Важливі обмеження пілоту

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

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

По-друге, робоче середовище не можна було відтворити незалежно від початку до кінця. Розгортання, хмарна інфраструктура та операційне середовище залишалися під контролем Google, а не були перебудовані й повторно запущені неафілійованою стороною. Процес атестації також залежав від обладнання, мікропрограм, систем обслуговування та інфраструктури атестації Google Cloud. Апаратно підтверджена перевірка сильніша за обіцянку «не вести журнали», але не скасовує довіри до ширшого ланцюга постачання. 13

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

Чому це ще не галузевий стандарт

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

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

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

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

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

Пілот Google DeepMind варто сприймати як інфраструктурний крок до складнішого оцінювання ШІ, а не як остаточну відповідь на питання довіри до бенчмарків. Він показує, як конфіденційні обчислення можуть зменшити конфлікт між захистом тестових даних і захистом пропрієтарної моделі. Чи стане це переконливим доказом на рівні всієї галузі, залежатиме від незалежного нагляду, якісного адміністрування бенчмарків, правових гарантій, відтворюваності та практичності — не лише від криптографії ізольованого середовища. 1320