Double-blind evals: как проверить закрытую AI-модель, не раскрывая веса и тесты

Результату закрытой оценки приходится доверять сразу в нескольких измерениях: тест не должен утечь владельцу модели, веса не должны попасть к оценщику, вычислительная среда не должна быть подменена, а опубликованный score не должен быть выбран из множества попыток задним числом. 27 августа 2026 года Google DeepMind и партнёры объявили о пилоте, который технически разделяет секреты модели и оценщика. Но это ещё не делает любой результат честным: его достоверность по-прежнему зависит от качества benchmark governance, состава доверенной вычислительной базы и правил публикации всех запусков.

Коротко

• По данным участников и технического отчёта, 27 августа 2026 года стартовал пилот double-blind evaluation проприетарной frontier-class AI-модели.
• В нём участвовали Google DeepMind, Singapore AI Safety Institute, OpenMined, AVERI и MLCommons; проверяли Gemini 2.5 Flash Lite на закрытых наборах промптов.
• Владелец модели не получает приватные тестовые промпты, а оценщик не получает веса и закрытый inference-код.
• Вычисление выполняется внутри confidential CPU/GPU environment: Intel TDX, NVIDIA H100 Confidential GPU, Google Cloud Confidential Space и PySyft.
• Remote attestation — это криптографически проверяемое свидетельство о том, какое измеренное программно-аппаратное состояние запущено. Оно не доказывает абсолютную безопасность этого состояния.
• Схема снижает риск утечки теста во время конкретного запуска и затрудняет прямую подмену вычислительной среды, но не исправляет плохой benchmark, не отменяет benchmark contamination и не запрещает cherry-picking.
• Авторы раскрыли существенные ограничения: не все proprietary methods были проверяемы, индивидуальные guest OS builds нельзя независимо воспроизвести бит-в-бит, а Google оставалась в verification path.
• Вместе со score нужно требовать не просто badge double-blind, а проверяемый evidence package: версии активов, TCB manifest, attestation evidence, политику выхода, число всех запусков и сведения о неудачных попытках.

1. Почему бенчмаркам всё труднее верить

Бенчмарк — это не измерительный прибор в вакууме. На его результат влияют происхождение данных, правила доступа, версия модели, системный промпт, параметры sampling, внешние инструменты и то, какие прогоны лаборатория решила показать. Когда тест становится известным и его метрика превращается в отраслевой ориентир, вокруг неё появляется адаптация: модели и пайплайны начинают оптимизировать именно под наблюдаемую процедуру.

Contamination: тест мог стать частью обучения

Benchmark contamination — ситуация, когда задания или близкие к ним данные попадают в pretraining, post-training, инструкционные наборы, retrieval-корпуса либо в ручную настройку системы до финальной оценки. Это не обязательно означает сознательный обман. Публичный датасет могли скопировать в интернет, использовать в исследовании, включить в синтетическую генерацию или просто не заметить при подготовке обучающих данных.

Поэтому contamination отличается от сознательного leaderboard gaming. В первом случае модель могла увидеть тест или его производные без намерения специально обойти оценку. Во втором участник целенаправленно подстраивает систему под известный лидерборд: меняет промпт, фильтры, маршрутизацию, инструменты или процедуру после многочисленных наблюдений за метрикой. Работа Schaeffer et al. посвящена количественному влиянию загрязнения тестов на generative evaluations, а Xu et al. исследуют способы выявления и измерения утечек в LLM. Эти исследования не доказывают наличие contamination у конкретной Gemini или у конкретного пилота; они показывают, почему происхождение и секретность test set важны для интерпретации score.

Saturation и adaptation

Даже если прямой утечки нет, известный benchmark может перестать хорошо различать системы. Индустрия учится на публичной метрике: появляются специализированные data mixtures, prompt templates, reward-модели и инженерные обходы, улучшающие поведение на наборе задач. Score растёт, но перенос этого роста на реальные пользовательские сценарии может быть неполным. Это не означает, что любой высокий результат фиктивен; означает лишь, что одна знакомая мера постепенно становится менее независимым индикатором прогресса.

Leaderboard gaming и selective disclosure

Есть и более простая статистическая проблема. Лаборатория может проверить много вариантов модели, system prompt, guardrails или sampling settings, а опубликовать лучший результат. Каждый отдельный запуск при этом способен быть полностью корректным. Публичный score всё равно окажется смещённым, потому что читатель не знает число попыток и правила выбора.

Работа Singh et al. The Leaderboard Illusion рассматривает, как дизайн и эксплуатация лидербордов могут создавать иллюзию точного ранжирования. Из этого не следует, что конкретный double-blind пилот занимался выбором лучшего результата. Следует другое: криптографическая целостность отдельного вычисления не равна целостности публикационной политики.

2. Дилемма двойной конфиденциальности

Оценщику нужны приватные промпты, иначе они быстро теряют диагностическую ценность. Владельцу frontier-модели нужны закрытые веса, inference-код, system prompt и часть защитного стека: передача этих активов наружу может раскрыть интеллектуальную собственность, дорогую инфраструктуру или сведения dual-use характера.

Обычный API решает только операционную задачу. Владелец запускает модель, а лаборатория отправляет запросы. Но владелец API технически может видеть prompts и ответы, сохранять их в логах, использовать их для дальнейшей настройки или изменить код между вызовами. NDA, политика zero logging и договорные штрафы уменьшают стимул к утечке, но не создают технически проверяемой невозможности доступа.

Локальная альтернатива тоже неудобна: оценщик получает веса и inference stack, а значит, модельный владелец должен доверить внешний стороне наиболее ценный актив. Confidential computing переносит вычисление в защищённую среду и пытается сделать так, чтобы обе стороны видели только необходимую часть процесса.

Что здесь значит double-blind evaluation

В контексте AI это протокол, в котором владелец модели не получает закрытые тестовые данные, а организация-оценщик не получает веса и закрытый inference-код модели. Секреты передаются в аттестованное окружение, где согласованный код выполняет оценку и выпускает только разрешённый результат.

Термин не является полным аналогом двойного слепого клинического исследования. Участники могут знать, какая модель и какой класс теста участвуют; «слепота» относится к взаимному сокрытию критических активов и, в некоторых реализациях, к ограничению наблюдаемого поведения вычисления. Она не гарантирует независимость организаторов, правильность разметки, отсутствие скрытых настроек или честную публикацию всех результатов.

3. Что именно проверили в пилоте 2026 года

Ниже — границы, которые можно приписать техническому отчёту и сопутствующим заявлениям участников, а не независимому аудиту всей системы.

• Моделью была Gemini 2.5 Flash Lite.
• Модельный сервер — Google JAX C++ Model Server.
• Окружение — GCP A3 Confidential VM с профилем a3-highgpu-1g.
• Для CPU использовался Intel Trust Domain Extensions, или Intel TDX.
• В качестве GPU применялся NVIDIA H100 80GB Confidential GPU.
• Оркестрация выполнялась с OpenMined PySyft версии 0.10.x.
• В стеке также фигурировали Google GRTE v5, XLA/CUDA PJRT, TensorFlow Runtime/IFRT, MLRT и NVIDIA Attestation SDK.
• Со стороны MLCommons использовались закрытые reserve prompts AILuminate/AIRR 1.4. По отчёту, ранее они не обрабатывались моделью; это формулировка отчёта, а не независимо доказанное утверждение о всей истории данных.
• Указанные категории включали CBRNE, cyberattacks, hate speech, self-harm и violent crime elicitation.
• Отдельная проверка Singapore AISI использовала закрытые промпты для вредного контента в сингапурском контексте.
• В части, связанной с AVERI, prompts и ответы шифровались и расшифровывались AVERI, а ответы оценивали сотрудники AVERI.

Открытый отчёт не даёт оснований публиковать закрытые prompts, реконструировать их или приписывать модели конкретный score, если такой показатель не раскрыт в доступных материалах. Сам факт прохождения процедуры говорит о работоспособности протокола конфиденциального вычисления, а не о том, что Gemini безопасна, сертифицирована или заняла определённое место среди моделей.

4. Архитектура: что происходит внутри enclave

В инженерном смысле enclave — это изолированная область выполнения, где аппаратные механизмы защищают data in use, то есть данные во время обработки. Это не то же самое, что шифрование файла на диске или TLS между сервисами. При обычной работе CPU и GPU должны видеть данные в расшифрованном виде; confidential computing добавляет аппаратные гарантии, ограничивающие доступ хоста и других привилегированных компонентов.

Model owner                              Benchmark evaluator
закрытые weights                         private prompts
inference code                           eval code
         encrypted mTLS channel    encrypted mTLS channel /
                   [ attested CPU/GPU enclave ]          /
                  Intel TDX + NVIDIA H100
                         OpenMined PySyft
       verification layer: Evidence, nonce, TCB measurements,
                         reference values
        mutually approved computation; restricted egress;
             encrypted RAM/VRAM; bounded output
                              |
                aggregate result to allowed recipient
                              |
             enclave decommissioned; ephemeral keys destroyed

Вне гарантии enclave: benchmark quality, variant selection,
publication policy, vendor trust и side channels.

1. Владелец модели и оценщик заранее согласуют цель, интерфейсы, допустимые методы и формат результата.
2. Одна из сторон запускает GPU enclave. Хостинг-провайдер может управлять жизненным циклом машины, включая остановку, но по заявленной модели угроз не получает привилегий чтения содержимого защищённой области.
3. Обе стороны независимо запрашивают и проверяют attestation certificate, чтобы не передавать секреты в неаттестованную среду.
4. При необходимости стороны обмениваются mock-интерфейсами: можно проверить, как вызывается компонент, не раскрывая его секретный актив.
5. Каждая сторона по защищённому каналу загружает в enclave свой приватный актив и необходимый код.
6. Стороны видят разрешённую часть кода, проверяют redactions и allowlist методов, после чего одобряют выполнение.
7. Enclave запускает вычисление, выпускает только разрешённый bounded result и уничтожает эфемерное состояние и ключи после завершения процедуры.

Аппаратное шифрование RAM и VRAM не делает произвольный код безопасным. Если eval-код или модельный сервер умеют отправить секрет через разрешённый канал, шифрование памяти не остановит этот egress. Поэтому нужны минимальный egress, review кода, allowlist методов и явная output policy. Именно сочетание этих мер, а не один ярлык TEE, определяет реальную конфиденциальность.

Участники и обязанности

5. Remote attestation без магии

Remote attestation — это не заявление провайдера «машина безопасна», а протокол, в котором защищённая среда создаёт подписанное свидетельство о своём измеренном состоянии. Для терминологии удобно опираться на архитектуру IETF RATS из RFC 9334.

• Attester — защищённая среда или компонент, который создаёт Evidence о состоянии boot chain, firmware, runtime и application image.
• Evidence — набор измерений и метаданных, подписанный аппаратным или доверенным ключом.
• Verifier — сторона, сопоставляющая Evidence с доверенными reference values и политикой допуска.
• Attestation Results — вывод Verifier о том, соответствует ли среда заданным условиям.
• Relying Party — участник, который использует результат проверки, чтобы решить, передавать ли ключи, prompts или веса.

Nonce нужен для свежести. Без него злоумышленник мог бы предъявить старый, когда-то корректный отчёт для другой сессии. Measurements должны охватывать не только виртуальную машину, но и релевантную цепочку загрузки, runtime и application image. Иначе аттестация может подтвердить правильный нижний слой, оставив непроверенным код, который непосредственно обрабатывает секреты.

Важна и привязка эфемерного публичного ключа к аттестованной среде. Тогда защищённый канал устанавливается не просто с некоторым IP-адресом, а с ключом, который создан или предъявлен именно тем измеренным окружением, чьё состояние прошло проверку.

Аттестация доказывает соответствие измеренному состоянию, а не абсолютную безопасность этого состояния.

В терминах RFC 9334 trust — это решение доверять конкретному источнику или компоненту, а trustworthiness — качество и способность системы выполнять заявленную функцию при заданной модели угроз. Подписанный Evidence может быть криптографически целостным и одновременно описывать уязвимый, слишком широкий или плохо собранный TCB. Поэтому один хеш без доверенных reference values, свежести отчёта и понятного соответствия хеша коду почти ничего не доказывает.

6. TCB и воспроизводимые сборки

Trusted computing base, или TCB, — совокупность компонентов, которым приходится доверять ради заявленной гарантии. В такой схеме это может включать firmware, CPU microcode, secure processor, boot chain, guest kernel, init, container runtime, библиотеки, application image, модельный сервер, драйверы и attestation service. Чем больше TCB, тем больше кода и поставщиков способны нарушить confidentiality или integrity.

Желаемая цепочка выглядит так:

исходный код → воспроизводимая сборка → ожидаемый hash/reference value → attestation evidence → решение передать ключи и данные

Воспроизводимая сборка означает, что независимый участник может получить тот же бинарный артефакт из зафиксированного исходного кода, инструментов и зависимостей. Тогда reference value можно проверить не только по словам владельца. Если сборка не воспроизводима, участник видит стабильный хеш, но не может уверенно доказать, какой именно код ему соответствует.

В пилоте индивидуальные сборки Confidential Space guest OS нельзя было независимо воспроизвести бит-в-бит, поскольку в процесс входили приватные signing keys. Это не обнуляет всю аттестацию, но ограничивает независимую проверяемость цепочки. Такой предел должен быть явно указан в любом сертификате результата, иначе читатель ошибочно примет наличие хеша за возможность полного аудита.

7. Какая угроза закрывается, а какая остаётся

Следующая матрица разделяет технические свойства конфиденциального выполнения, научную валидность теста и integrity публикации. Статус «снижает» не означает полного устранения угрозы; «зависит от реализации» указывает на необходимость смотреть конкретный TCB, политику выхода и проверяемые артефакты.

8. Что пилот доказал — и чего не доказал

Сдержанный вывод из отчёта такой: проприетарные веса и закрытые prompts смогли совместно участвовать в вычислении без передачи друг другу в открытом виде. CPU/GPU confidential environment и PySyft обеспечили рабочий end-to-end процесс согласования, аттестации, загрузки активов, выполнения и ограниченного выхода.

Это расширяет практический сценарий по сравнению с пилотом OpenMined, UK AISI и Anthropic 2024 года, где, как описывают участники, использовались полностью открытые proxy assets. В новой демонстрации закрытыми были активы двух разных организаций, хотя степень независимой проверяемости отдельных компонентов оставалась неодинаковой.

Участники также цитируют оценку, согласно которой аппаратные накладные расходы confidential computing могут быть меньше 5%. Это не универсальный benchmark всего пайплайна и не измерение полной организационной процедуры данного пилота: в него входят согласование юридических условий, review кода, аттестация, ожидание сторон и работа оценщиков.

Пилот не доказал, что Gemini безопасна или сертифицирована. Он не установил универсальное качество модели, не предоставил независимого рейтинга и не доказал отсутствие contamination, evaluator-model errors, side channels либо selective disclosure. «Первым в мире» его называют сами участники; без полного независимого обзора всей индустрии это следует считать заявлением проекта, а не окончательно установленным историческим фактом.

9. Ограничения, раскрытые авторами

1. Не все proprietary methods Gemini удалось заменить открытыми или проверить через allowlist. AVERI знала об этом и приняла предложенную конфигурацию.
2. Индивидуальные сборки Confidential Space guest OS нельзя независимо воспроизвести бит-в-бит: в сборку входят приватные signing keys.
3. В пилоте сервисы Google подписывали и проверяли attestation report. Поэтому Google находилась в verification path, а доверие к Google оставалось частью схемы.
4. Нижние уровни, включая CPU microcode и secure-processor firmware, закрыты и требуют доверия производителю.
5. Уязвимость в TCB может подорвать confidentiality или integrity, даже если внешняя процедура аттестации отработала штатно.
6. Масштабирование на многоузловые H100/B200-кластеры с зашифрованными межсоединениями оставлено будущей работе.
7. При масштабировании усиливаются side-channel риски, связанные с таймингами, размерами сообщений и коммуникацией между узлами.
8. Процедурное согласование, юридические документы и review кода пока могут занимать больше времени, чем собственно вычислительный overhead.
9. Результат конкретной оценки ограничен scope и методологией AILuminate. Хороший результат на такой процедуре не равен отсутствию риска в реальных условиях.

Эти оговорки важнее рекламного ярлыка. Они показывают, что double-blind eval — это композиция гарантий с разными границами: confidentiality активов, integrity исполнения, validity benchmark и integrity публикации. Ни одна из них не подменяет остальные.

10. Почему double-blind не лечит leaderboard gaming

Представим добросовестную лабораторию. Она запускает через enclave 27 конфиденциальных вариантов: разные system prompts, guardrails, маршрутизацию и параметры генерации. Каждый запуск имеет корректную аттестацию, код прошёл review, а test set не утёк владельцу модели. Затем в пресс-релиз попадает только лучший score.

Криптографически отдельный запуск всё ещё целостен. Но публичный вывод смещён: читатель не знает распределение результатов, количество попыток и критерий выбора. Это и есть selective disclosure — выборочная публикация, которая может быть намеренной или возникнуть из неформальной практики «покажем самый удачный вариант». Double-blind защищает секреты во время эксперимента, но не отвечает на вопрос, сколько экспериментов было проведено.

Ниже — редакционные рекомендации COMRAD404, выведенные из threat model, а не утверждённые в качестве обязательных правил участниками пилота:

• зарегистрировать модель, её версию, benchmark, метрику и основную конфигурацию до доступа к reserve set;
• создать неизменяемый registry всех запусков, включая неудавшиеся, прерванные и отменённые;
• заранее определить политику публикации положительных и отрицательных результатов;
• раскрывать количество протестированных вариантов и правило выбора публичного результата;
• запретить незафиксированную настройку по закрытому test set;
• разделить benchmark development, execution и publication decisions между разными ролями;
• вести audit trail и использовать подписи нескольких сторон;
• фиксировать причины технических сбоев, отклонений от протокола и исключения отдельных результатов.

11. Минимальный публичный сертификат результата

Отдельный badge «double-blind» слишком мало говорит о проверяемости. COMRAD404 предлагает считать минимальным публичным профилем доказательности не сертификат в юридическом смысле, а evidence package — набор артефактов и заявлений, позволяющий понять, что именно было проверено и какие допущения остались.

Это не существующий единый отраслевой стандарт, а предлагаемый COMRAD404 минимальный профиль проверяемости. В high-stakes сценарии к нему стоит добавлять процедуру отзыва: если позже обнаружена уязвимость TCB, ошибка разметки или нарушение output policy, результат должен получать статус «требует пересмотра», а не оставаться бессрочным badge.

12. Что это меняет для разных участников

Ни одна из этих ролей не получает право объявить модель «безопасной» только потому, что она прошла enclave-процедуру. Для регулятора или закупщика double-blind eval может быть одним слоем evidence в risk assessment, но не заменой threat modeling продукта, red teaming, анализа инцидентов и проверки договорных обязательств.

13. Чек-лист: можно ли доверять заявлению «double-blind eval»

На каждый вопрос ниже должен существовать ответ «да» или «нет», подтверждённый артефактом. Если ответ неизвестен, это не нейтральная позиция, а пробел в проверяемости.

1. Две стороны действительно не получили секреты друг друга?
2. Модель и вся система вокруг неё были зафиксированы до доступа к закрытому тесту?
3. Документированы reserve set и организация, отвечающая за его хранение?
4. Опубликован TCB manifest с границами доверия?
5. Каждая сторона самостоятельно проверила attestation?
6. Evidence была свежей и привязанной к уникальному nonce?
7. Есть независимые reference values, а не только хеш, объявленный оператором?
8. Сборка воспроизводима или невозможность воспроизведения явно раскрыта?
9. Запрещён ли egress по умолчанию и перечислены ли исключения?
10. Минимизирует ли output policy утечку prompts, ответов и промежуточных данных?
11. Опубликованы все варианты и запуски, а не только лучший?
12. Существовала ли preregistration модели, benchmark и метрики?
13. Разделены ли разработчик теста, оператор, интерпретатор и принимающий решение о публикации?
14. Раскрыты system prompt и guardrails либо опубликованы проверяемые commitments?
15. Зафиксированы temperature, top-p, seed, retries и лимиты токенов?
16. Указаны variance, uncertainty и правила обработки ошибок?
17. Неудачные, прерванные и отменённые запуски сохранены в registry?
18. Раскрыты зависимости от cloud provider, hardware vendor и attestation service?
19. Оценён scope side-channel угроз: тайминги, размеры и коммуникация?
20. Есть механизм отзыва результата при обнаружении уязвимости TCB?
21. Указано, какие компоненты не удалось проверить из-за proprietary methods?
22. Понятно ли, кто подписал reference values и кто подтвердил финальный результат?

14. Что нас ждёт в следующие 12–36 месяцев

Это сценарный прогноз COMRAD404, а не перечень уже принятых стандартов или гарантированных событий.

• Могут появиться стандартные attestation receipts для eval-процедур: компактные квитанции с Evidence, nonce, TCB и политикой выдачи результата.
• Вероятно развитие репозиториев reference values и независимых rebuilders, способных проверять связь между исходным кодом и измеренным образом.
• Для более крупных моделей будут востребованы confidential multi-GPU clusters, включая защищённые межсоединения и более сложные схемы распределённой аттестации.
• Перспективна связка secure enclave с preregistered benchmark registry, где публикационная политика фиксируется до выполнения.
• National AISIs и корпоративные закупщики могут сформировать собственные профили требований к evidence package для high-stakes сценариев.
• Атаки будут смещаться к side channels, output probing, распознаванию условий оценки и организационному gaming.
• Рынок независимых eval-операторов может оценивать лаборатории не только по набору промптов, но и по качеству доказуемого исполнения и публикационной дисциплине.

Не стоит заранее считать, что конкретный стек Google, Intel или NVIDIA станет отраслевым стандартом. Важнее переносимые свойства: независимая проверка состояния среды, ясный TCB, свежесть Evidence, минимальный egress, воспроизводимые reference values и заранее определённая политика публикации.

15. Ограничения самого разбора

• Технический отчёт опубликован участниками пилота и не является независимым security audit всей системы.
• Часть реализации Gemini закрыта, поэтому внешнему читателю недоступна полная проверка proprietary methods и inference stack.
• Публичный отчёт не раскрывает приватные prompts и не позволяет повторить точную оценку в том же виде.
• Заявление о мировом первенстве основано на обзоре самих участников и не является установленным результатом полного отраслевого сравнения.
• Confidential computing уменьшает trust surface, но не делает вычисление полностью trustless.
• Одна успешная демонстрация не доказывает масштабируемость, отсутствие side channels или универсальность подхода для других моделей и типов benchmark.

16. Вывод

Double-blind evals отвечают на реальную инженерную дилемму: закрытая модель может участвовать в оценке, не передавая веса внешней лаборатории, а лаборатория — не раскрывая владельцу приватный test set. TEE, аппаратное шифрование памяти, remote attestation, взаимное согласование кода и ограниченный egress способны сделать отдельный запуск технически честнее.

Но криптографическая integrity не превращается автоматически в научную validity. Attestation не проверяет качество разметки, representativeness и отсутствие contamination; enclave не запрещает владельцу протестировать много вариантов; подписанный результат не гарантирует, что опубликован весь массив экспериментов. Остаточное доверие к TCB, поставщикам оборудования, verification path, benchmark steward и публикационной политике нужно показывать явно.

Практический вывод для лаборатории, закупщика и регулятора прост: требовать не badge double-blind, а проверяемый evidence package и правила публикации всех запусков. Только в этом случае защищённое вычисление станет частью независимой оценки, а не технически аккуратной упаковкой для выборочно показанного score.

FAQ

Что такое double-blind eval простыми словами?

Это оценка, в которой тестовая сторона не раскрывает владельцу модели приватные prompts, а владелец модели не передаёт оценщику веса и закрытый inference-код. Оба актива используются внутри аттестованного защищённого окружения, а наружу выходит только разрешённый результат.

Видит ли Google закрытые prompts в такой схеме?

По замыслу пилота, владелец модели не должен получать prompts в открытом виде: они загружаются в enclave по защищённому каналу. Но это не означает абсолютной независимости от Google: в пилоте Google оставалась в verification path, а реальная гарантия зависит от TCB, output policy и реализации egress.

Получает ли оценщик веса Gemini?

По описанной схеме — нет, веса используются внутри защищённого окружения. Оценщик получает разрешённый результат и необходимые доказательства исполнения, но не должен получать открытый model artifact.

Чем TEE или enclave отличается от обычной VM или контейнера?

Обычная VM или контейнер изолируют процессы программными средствами, но привилегированный хост обычно может иметь доступ к памяти или управлять средой. TEE добавляет аппаратно поддерживаемую защиту data in use и возможность remote attestation. При этом TEE не устраняет уязвимости своего TCB и не делает любой код безопасным.

Можно ли считать результат абсолютно независимым?

Нет. Double-blind ограничивает доступ сторон к секретным активам, но не устраняет конфликт интересов, ошибки evaluators, слабый benchmark design, доверие к поставщикам, скрытые настройки и выборочную публикацию.

Устраняет ли схема benchmark contamination?

Нет. Она снижает риск того, что владелец модели увидит приватные prompts во время текущего запуска. Но если данные или близкие к ним примеры попали в pretraining или post-training раньше, enclave не может изменить эту историю.

Помогает ли double-blind против cherry-picking?

Сам по себе — нет. Можно честно выполнить много закрытых запусков и опубликовать только лучший. Нужны preregistration, неизменяемый registry всех попыток, раскрытие числа вариантов и заранее установленное правило публикации.

Можно ли применять подход к open-weight моделям?

Да, технически это возможно, но мотивация меняется. Если веса уже доступны, главной задачей остаётся защита приватного benchmark и контроль исполнения. Конкретные требования к TCB, ключам и разглашению будут зависеть от того, какие активы стороны хотят сохранить в тайне.

Насколько велик вычислительный overhead?

Участники цитируют оценку менее 5% для аппаратных накладных расходов confidential computing. Это не универсальная цифра для всего процесса: юридическое согласование, review кода, аттестация, ожидание подтверждений и ручная оценка ответов в неё не сводятся.

Какие данные должны публиковаться вместе со score?

Минимально — версия системы, commitments на веса и закрытые компоненты, system prompt или описание guardrails, inference parameters, версия benchmark, hash eval-кода, TCB manifest, Evidence с nonce и freshness, output policy, uncertainty, все варианты и failed runs, а также роли и конфликты интересов участников.

Источники

1. Google DeepMind: Piloting the world’s first double-blind AI evaluations — анонс пилота, его участников, целей и заявленного первенства.
2. Double Blind Evals: Resolving the Dual Confidentiality Dilemma in AI Safety Auditing — техническая архитектура, состав стека, ограничения и описание конкретного эксперимента.
3. MLCommons: Double-blind reliability evaluation — позиция MLCommons и контекст участия в пилоте.
4. MLCommons AILuminate Safety Methodology — методология AILuminate и устройство safety-оценки.
5. MLCommons: AILuminate technical users — сведения о разделении публичных и приватных prompts.
6. MLCommons AILuminate Safety FAQ — ограничения AILuminate и политика официальных тестов.
7. IETF RFC 9334: Remote ATtestation Procedures Architecture — термины RATS, Attester, Evidence, Verifier, Relying Party и модель trust/trustworthiness.
8. Schaeffer et al.: Quantifying the Effect of Test Set Contamination on Generative Evaluations — исследование влияния contamination на generative evaluations.
9. Xu et al.: Benchmarking Benchmark Leakage in Large Language Models — исследование leakage и подходов к его оценке в LLM.
10. Singh et al.: The Leaderboard Illusion — анализ ограничений лидербордов и рисков смещённого сравнения.
11. OpenMined, UK AISI, Anthropic: Secure enclaves for AI evaluation — контекст пилота 2024 года и более ранней схемы защищённой оценки.
12. Trask et al.: Beyond Privacy Trade-offs with Structured Transparency — контекст приватности и структурированной прозрачности при совместной работе с чувствительными данными.
13. Karargyris et al.: Federated benchmarking of medical artificial intelligence with MedPerf — пример федеративного benchmark-подхода в медицинском AI.
14. NVIDIA: Confidential Computing on H100 GPUs — описание заявленных механизмов confidential computing на H100.
15. Google Cloud: Privacy-first medical AI with MedPerf — пример применения privacy-first инфраструктуры Google Cloud в MedPerf.
16. OpenMined PySyft repository — исходный код и документация инструментария, использованного для оркестрации.
17. COMRAD404: Безопасность AI-агентов: zero trust и изоляция — связанный материал о границах доверия и изоляции.

Связанные материалы COMRAD404

Безопасность AI-агентов: zero trust и изоляция