Суть предложения: Карантин для чекпоинтов
Автор поста на LessWrong, Анна Ванг (Annawang), предлагает регуляторную меру, направленную на снижение рисков от сверхспособных ИИ. Идея проста, но радикальна: ни один чекпоинт (модель) не может использоваться внутри компании для целей, отличных от тестирования безопасности, в течение фиксированного периода X календарных дней после того, как её хэш (цифровой отпечаток весов) был зарегистрирован у независимого аудитора.
Ключевые параметры предложения:
- Начало отсчета: С момента фиксации хэша чекпоинта у аудитора.
- Запрет: Любое внутреннее использование модели (деплой, использование в продуктах, R&D), кроме прямого тестирования безопасности.
- Обучение: Продолжение обучения весов чекпоинта (fine-tuning) не считается «внутренним использованием» и не блокируется, что предотвращает алгоритмический оверхаунд и стимулирует разработчиков публиковать больше чекпоинтов для тестирования.
Механика тестирования: Поэтапный подход
Период X не является единым окном простоя. Предлагается структурировать его в два этапа, чтобы максимизировать выявление проблем:
| Этап | Действия | Ограничения |
|---|---|---|
| Этап 1 (Первая часть X) | Пререгистрированные оценки (evals) и работа с назначенными тестерами в изолированной среде. | Строгий контроль, отсутствие доступа к продуктовым системам. |
| Этап 2 (Вторая часть X) | Широкое мониторированное внутреннее использование сотрудниками компании. | Запрет на запуск задач, слияние кода, запись в обучающие данные и доступ к prod-средам. |
Параллельно с этим вводится механизм «скрытых запусков»: когда сотрудник использует уже «очищенную» модель, новая модель получает ту же задачу в песочнице. Её вывод идет только в отдел безопасности, а не обратно сотруднику, что позволяет выявлять отклонения в реальном времени.
Почему это важно: Борьба с обходом правил
Основная проблема существующих подходов — возможность маскировать исследования возможностей (capabilities) под исследования безопасности. Ванг выделяет несколько векторов обхода, которые пытается закрыть правило X дней:
- Маскировка R&D: Разработчики не могут использовать новые модели для написания более быстрого кода или оптимизации обучения, называя это «тестированием».
- Обучение на выводах: Запрет на использование выводов новой модели для обучения других моделей или в качестве обучающих данных до истечения срока X.
- Экстренные случаи: Аудитор может разрешить ранний деплой только для одного конкретного чекпоинта в случае чрезвычайной ситуации (например, для нейтрализации вредоносной модели), но это решение должно быть подтверждено или отменено законодательным органом в течение X дней.
Открытые вопросы и риски
Предложение не лишено противоречий. Ключевые спорные моменты включают:
- Длина периода X: Должно ли время ожидания расти по мере увеличения способности моделей? (Например, от 10 до 90 дней). Более сложные модели (рои, долгосрочная память) требуют больше времени для выявления сбоев.
- Исключения для безопасности: Должны ли исследователи по выравниванию (alignment) иметь доступ к моделям раньше? Без исключения они работают с устаревшими моделями, с исключением — возникает риск маскировки исследований возможностей под безопасность.
- Определение «существенно более способных»: Как измерять порог входа в регулирование? Использование индекса ECI (Epoch Capabilities Index) или вычислительной мощности? Это создает поле для манипуляций, когда компании создают «вторые семьи» моделей, чуть не дотягивающие до порога, чтобы избежать карантина.
Инициатива перекликается с предложениями AI Futures Project (AIFP) о том, что ИИ-исследования должны проводиться с моделями, обученными не менее 9 месяцев назад, но предлагает более гибкий и детализированный механизм контроля на уровне конкретных чекпоинтов.
Источник: LessWrong ↗