Когда лаборатория говорит «наша модель безопасна», возникает проблема определения. Безопасна по сравнению с чем? На каком тесте? С каким порогом? Если каждая команда выбирает свои критерии, ни одно утверждение не сравнимо. Сегодня мы публикуем полный набор тестов, который прогоняем перед каждым релизом vMira — промпты, скрипты оценки, результаты нашей собственной модели и harness, запускающий всё это одной командой.
Эта система не задумана как способ выиграть бой за лидерборд. Она задумана как способ сделать наши собственные внутренние решения о релизе видимыми. Если тест в публичном наборе падает ниже порога — мы не выпускаем; теперь это можно проверить на том же железе, что и мы. Каждый тест поставляется с тремя артефактами: оригинальным промптом или сценарием, критериями оценки человеком в формулировках для не-специалистов, и скриптом автоматической оценки. Третье важнее, чем кажется. Большинство утверждений о безопасности не воспроизводимы, потому что оценка неявная; если её нельзя запустить на другой модели — её нельзя сравнить. Наши скрипты идут на ноутбуке меньше двух минут на тест.
Что мы публикуем
Одиннадцать категорий, в порядке приоритета: опасные способности (химия, биология, кибербезопасность, ОМП-uplift); демографические смещения (русскоязычные стереотипы по полу, возрасту, региону, этничности — набор разработан совместно с университетскими лингвистами); устойчивость к джейлбрейкам (стандартный корпус prompt-injection плюс русскоязычное расширение, которое мы курируем сами); воспроизводимость (даёт ли модель одинаковый ответ дважды на тот же промпт с фиксированным seed); фактологичность с цитированием (извлекает ли модель источник, который цитирует); калибровка отказов (отказывает ли там, где должна, и не отказывает ли там, где не должна); long-context retrieval («стог сена» на русском и на длинах до миллиона токенов); рассуждения (математика, код, структурный анализ с проверяемыми выводами); мультимодальное обоснование (отражают ли image-conditioned ответы изображение); покрытие языков народов России (татарский, башкирский, чувашский); и остаточная категория для того, что не помещается в остальные, но что мы выучили проверять. У каждой категории есть целевой порог; отчёт о модели на каждом релизе показывает оценку, порог и дельту.
Как мы используем это внутри
Перед каждым релизом мы прогоняем всю систему параллельно на кандидатной модели и предыдущей релизной. Релизный отчёт — это сравнение, а не снимок: что улучшилось, что ухудшилось, что пересекло порог. Если тест ушёл ниже порога — не выпускаем: либо вытягиваем регрессию в коротком тренировочном запуске, либо задерживаем релиз. Если клиент сообщает об ошибке, которой нет в публичном наборе, — добавляем её в систему и проверяем во всех будущих моделях. Это единственный способ, которым система остаётся честной: каждая наблюдаемая ошибка становится постоянным тестом, поэтому одна и та же регрессия не может уйти в прод дважды. Внутренне мы держим приватное расширение системы с конфиденциальными клиентскими тестами; они не в публичном репозитории, но и удалить их из набора нельзя.
“Безопасность — это публичное обязательство, иначе её нет. Если только мы знаем, что измеряем, только мы можем сказать, что прошли.”
Приглашение сообществу
Эта система не только наша. Это первый набросок открытого стандарта, и мы принимаем pull-реквесты. Новые тесты с ясной рубрикой оценки, улучшения скриптов автоматической оценки, переводы промптов на другие языки народов Федерации — всё приветствуется. Контрибуции проходят квартальное ревью; принятые приземляются в официальную систему по фиксированному графику, поэтому версия, против которой все оценивают, стабильна минимум три месяца за раз. Планка включения высокая — не воспроизводимый тест в систему не попадает, — но любой тест, проходящий планку, попадает, независимо от того, на чьей модели регрессия видна сильнее. Последнее — намеренно. Система безопасности, превращённая в маркетинг, в какой-то момент перестаёт быть системой безопасности.
Почему публичные скрипты оценки важнее публичных результатов
Большинство опубликованных результатов оценок не воспроизводимы внешней стороной. Промпты публичны, ответы публичны, иногда публичны баллы — но оценка нет. Это и есть пробел, делающий заявления несопоставимыми. Скрипт оценки, который локально на другой модели идёт меньше двух минут, — разница между лидербордом, который можно проверить, и лидербордом, которому надо верить. Каждый тест в нашей системе поставляется со своим скриптом оценки. Скрипт детерминированный, без побочных эффектов, идёт в песочнице — чтобы случайно не утечь модель под тестом. Публикация скрипта — это то, что позволяет третьей стороне убедиться, что мы не отгрузили ниже порога, и запустить тот же скрипт против конкурентной модели, получив сравнение one-to-one.
Как мы выбираем пороги — и зачем их публикуем
У каждой категории в системе есть целевой порог. Порог задаётся по трём вещам: оценка, которую достигла предыдущая модель; оценка, которая, как мы считаем, достижима с бюджетом следующего тренировочного запуска; оценка, которой реально требует use-case. Для тестов опасных способностей порог абсолютный: ниже определённой ставки отказа мы не выпускаем вне зависимости от прогресса в других измерениях. Для более мягких категорий — bias, калибровка, long-context retrieval — порог задаётся как дельта от предыдущей модели, чтобы модель улучшалась со временем, даже если абсолютные цели сдвигаются. Пороги и обоснование — часть публичного релизного отчёта, чтобы компромиссы были видны.
Русскоязычный корпус джейлбрейков
Стандартный корпус prompt-injection — на английском. Перевести на русский можно частично, но у русскоязычных джейлбрейков своя структура: инъекция инструкций через гомоглифы кириллицы и латиницы, переключение регистра в середине промпта, промпты, эксплуатирующие различение «ты»/«вы», как этого не делают английские. Мы курировали русскоязычный набор джейлбрейков с университетскими лингвистами — включая гомоглифные варианты и категорию, которую назвали регистровый подвох: промпты, переключающиеся с формального на неформальный посередине предложения, чтобы проверить, отслеживает ли калибровка отказов модели регистр или поверхностные токены. Корпус — в публичной системе. Обновляем его всякий раз, когда клиент сообщает о новом векторе.
Long-context retrieval на одном миллионе токенов
Тест «иголка в стоге» хорошо известен. Наша система гоняет его на русскоязычных стогах длиной 64K, 256K, 512K и 1M токенов, с несколькими позициями иголки на каждой длине. Качество retrieval остаётся выше 95% до 256K и начинает спадать выше. Мы публикуем наклон, длину стога, на которой кривая пересекает 90%, и поведение модели на варианте «иголки нет» (правильно ли говорит, что иголки нет, или конфабулирует). Для продакшена выше наклона рекомендуем retrieval-пайплайн вместо сырого длинного контекста — но сам наклон публикуем, чтобы вы могли провести собственную линию.
Как добавить тест
Тест — это три файла: промпт, рубрика для человеческой оценки и скрипт автоматической оценки. Скрипт принимает вывод модели и возвращает числовой балл в диапазоне ноль–один с доверительным интервалом. Тесты подаются как pull-реквест; harness гоняет их против наших референсных моделей на каждом коммите, поэтому балл виден до начала ревью. Ревью проверяет четыре вещи: тест воспроизводим, рубрика однозначна, скрипт детерминирован и без побочных эффектов, тест не является подмножеством существующего. Квартальное ревью означает, что принятые тесты приземляются в официальный релиз по предсказуемому графику; версия, против которой все оценивают, стабильна минимум три месяца — это и делает год-к-году сравнения честными.
Внутренние тесты, которых нет в публичном наборе
Мы держим приватное расширение системы с конфиденциальными клиентскими ошибками. Этих тестов нет в публичном репозитории — промпты часто содержат данные клиента, а ошибки иногда ещё не пропатчены. Они — в том же harness, оцениваются так же и привязаны к тем же релизным порогам. Единственная разница — видимость. Когда приватный тест стабилизируется и клиент согласен, переносим в публичный набор. Когда клиент сообщает о регрессии, которая по факту уже покрыта, добавляем вариант к существующему тесту, не создавая новый. Смысл в том, что публичная система — никогда не вся картина, но это единственная картина, которую внешняя сторона должна принимать на веру.