Из DeepSeek V4.1 Flash убрали отказы: с 81,6% до 4,3% на 838 промптах

Представьте, что вы купили сейф и узнали, что кодовый замок в нём можно вынуть отверткой за вечер. Примерно такую картину рисует вирусный пост в X про DeepSeek V4.1 Flash. Автор пишет, что кто-то убрал из модели большую часть отказов, а сделал это с помощью бесплатного open-source инструмента OBLITERATUS, который выпустил Pliny.

Что именно заявлено

В посте всего несколько фактов. Исходная модель, по данным автора, отказывалась отвечать на 81,6% из 838 тестовых промптов. После модификации доля отказов упала до 4,3%. Инструмент назван бесплатным и открытым, больше технических подробностей в посте нет.

Что мы не знаем, тоже важно. Неизвестно, какие именно промпты вошли в набор из 838 штук, как считали отказ и кто проводил замер. Нет данных о том, как изменилось качество модели в обычных задачах: коде, рассуждениях, длинном контексте. Ссылки на воспроизводимый эксперимент в посте нет, а охват у него скромный, около 4,6 тысячи просмотров. Поэтому цифры стоит считать заявлением, а не результатом проверки.

Почему это возможно в принципе

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

Ключевое свойство такого подхода в том, что он требует доступа к весам, но не требует дорогого дообучения. Поэтому для любой открытой модели вопрос обычно звучит так: когда появится версия без отказов, а не появится ли она.

Что с этим делать разработчику и продакту

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

Второе: если вы берёте чужие дообученные чекпойнты с Hugging Face и подобных площадок, проверяйте происхождение. Модель с похожим названием может вести себя совсем иначе, чем официальная. Прогоняйте собственный red-team набор до выкладки в прод, особенно для агентов с доступом к инструментам и данным.

Третье: для команд, которые выпускают открытые веса, это напоминание о модели угроз. Выравнивание в весах защищает от случайного неправильного использования, но не от целенаправленного. Здесь нужны дополнительные меры: лицензия, мониторинг использования через API-версию, раздельные релизы для разных уровней риска.

Ограничения и вывод

Источник один, это пост в соцсети с эмоциональным заголовком. Для разработчиков это не повод паниковать, а повод пересмотреть допущения. Если вы строите на закрытом API, ваша ситуация иная: веса недоступны, и такой приём не сработает. Если вы строите на открытых моделях, добавьте в чек-лист вопрос о том, что будет, когда отказы пропадут. Ответ должен содержать слой защиты, которым управляете вы сами, а не только разработчик модели.

История с DeepSeek V4.1 Flash, вероятно, не последняя такого рода. Чем сильнее открытая модель, тем быстрее для неё появятся инструменты снятия ограничений, и тем важнее архитектура безопасности вокруг неё.