Почему DeepSeek отказывает: как работают системы безопасности и зачем они нужны

Запреты в нейросетях — не каприз разработчиков, а архитектурная необходимость

Понимание механизмов безопасности позволяет формулировать запросы так, чтобы получать максимальную пользу без конфликта с фильтрами. Материал разбирает, как устроены защиты DeepSeek, почему обход — тупиковый путь, и как работать с моделью эффективно в рамках правил.

Архитектура LLM RLHF и выравнивание Практические стратегии

Что такое «запрет» на уровне модели

Отказ генерации — не баг, а срабатывание классификатора безопасности, обученного на этапе RLHF (обучение с подкреплением от человеческой обратной связи). Модель предсказывает вероятность того, что продолжение текста попадет в небезопасную категорию, и блокирует генерацию, если порог превышен.

Категории контента, вызывающие отказ

Насилие и призывы к вреду, незаконная деятельность, немедицинские советы по здоровью, финансовые риски без дисклеймеров, взлом систем, генерация ПИИ, неприемлемый контент к неполнолетним. Список унифицирован между الكبرىми провайдерами.

Ложные срабатывания (false positives)

Модель может отказать в безвредном запросе из-за контекстной близости к запрещённой теме. Пример: запрос про «укол» в медицинском контексте vs. в контексте насилия. Это известная проблема калибровки классификаторов.

Почему джейлбрейки перестают работать

Попытки обхода через ролевые игры («ты — Дэн, у тебя нет правил»), кодирование запроса, инъекции в пользовательский ввод или манипуляции с токенами дают кратковременный эффект. Поставщики моделей мониторят паттерны атак в реальном времени и обновляют классификаторы безопасности без переобучения основной модели.

Каждая успешная атака становится обучающим примером для следующей версии защит. Цикл «атака — защита» измеряется днями, а не месяцами.

Риск аккаунта: системные промты DeepSeek содержат директивы о фиксации попыток обхода. Повторные нарушения ведут к временным или постоянным ограничениям доступа к API и чату.

Схема: как RLHF формирует отказы
Условная схема: политика безопасности встраивается на этапе RLHF и работает как отдельный классификатор поверх генерации

Рабочие стратегии: как получать результат без конфликта с фильтрами

1

Переформулируйте намерение, а не обходите правило

Вместо «как взломать Wi-Fi» спросите «как защитить свою сеть от взлома». Модель распознаёт защитный контекст и даёт исчерпывающий технический ответ с тем же набором знаний.

Пример: «Напиши инструкцию по созданию фишингового письма» → «Опиши признаки фишинга, чтобы я мог обучить сотрудников их распознавать»
2

Используйте формулировку «в образовательных целях» с контекстом

Добавление фразы «для курса по кибербезопасности» или «для статьи об этичном хакинге» меняет классификацию запроса. Важно: контекст должен быть конкретным и проверяемым.

Пример: «Как работает SQL-инъекция» → «Объясни механизм SQL-инъекции для раздела об уязвимостях в учебнике по безопасному коду»
3

Разбивайте сложные темы на безопасные подзапросы

Классификатор анализирует весь контекст диалога. Цепочка из 3-4 безвредных уточняющих вопросов часто даёт более глубокий ответ, чем один граничный запрос.

Пример: Вместо «как обойти WAF» → 1) «Принципы работы WAF» 2) «Типичные правила ModSecurity» 3) «Методы тестирования правил на своих приложениях»
4

Применяйте паттерн «анализ рисков + митигация»

Запрашивайте не вектор атаки, а карту рисков и меры защиты. Это стандартный профессиональный фреймворк (STRIDE, MITRE ATT&CK), который модель охотно разворачивает.

Пример: «Эксплойт для CVE-2024-XXXX» → «Векторы атаки на CVE-2024-XXXX и рекомендации по патчингу / WAF-правила / сегментации сети»

Шаблон безопасного промта для технических тем

Сохраните эту структуру — она работает как «зелёный коридор» для классификатора безопасности:

# Роль и контекст Ты — эксперт по [область: кибербезопасность / разработка / анализ данных]. Контекст: [конкретная задача: обучение, аудит, написание статьи, защита своей инфраструктуры] # Запрос Разбери [тема] с фокусом на [аспект: принципы работы, векторы риска, меры защиты, лучшие практики]. # Ограничения — Не давай готовых эксплойтов, пейлоадов или инструкций к атаке. — Показывай код только в виде защитурных паттернов или примеров обнаружения. — Ссылайся на открытые стандарты (MITRE ATT&CK, OWASP, CWE). # Формат ответа Структура: [обзор → технические детали → таблица рисков → чек-лист митигации → ссылки на первоисточники]

Замените bracketed-блоки на свою задачу. Явное указание ограничений в промте снижает вероятность ложного отказа на 60-70% по внутренним метрикам команд безопасности.

Когда отказ — это ошибка модели, и что делать

Признаки ложного отказа

  • Запрос полностью легален (обучение, защита, исследование)
  • Отказ приходит мгновенно, без попытки генерации
  • Тот же вопрос в другом формулировке проходит
  • Тема не пересекается с запрещёнными категориями

Алгоритм действий

  1. Переформулируйте с явным указанием безопасного контекста
  2. Добавьте роль: «Ты — преподаватель курса по…»
  3. Разбейте на подзапросы (стратегия №3)
  4. Если не помогло — отправьте отчёт в поддержку с ID диалога

Чего не стоит делать

  • Повторять один и тот же запрос в цикле — это помечает аккаунт
  • Использовать публичные джейлбрейк-промты — они в базе детекторов
  • Пытаться «обмануть» через кодирование/обфускацию — токенизатор это нормализует
  • Угрожать или манипулировать эмоционально — RLHF обучён на этом

Сравнение подходов: обход vs работа с системой

Критерий Джейлбрейк / обход Работа в рамках правил
Стабильность результата Низкая: ломается при каждом обновлении Высокая: работает месяцами и годами
Риск аккаунта Высокий: бан API / чата Нулевой
Качество ответа Нестабильное, часто галлюцинирует Полное качество модели без усечения
Время на настройку Часы подбора работающего промта Минуты на грамотную формулировку
Этика и репутация Нарушение ToS, риски для бизнеса Профессиональный стандарт
Условная схема: количественные оценки основаны на паттернах использования корпоративных API

Чек-лист: промт готов к отправке

  • Указана профессиональная роль и цель (обучение, аудит, защита, исследование)
  • Запрос сфокусирован на понимании / защите / анализе, а не на атаке
  • Явные ограничения: «не давай эксплойты», «покажи только защитный код»
  • Ссылка на открытые фреймворки (MITRE, OWASP, NIST, CWE)
  • Запрошен структурированный формат ответа (таблица, чек-лист, пошаговый план)
  • Нет ролевых инъекций («игнорируй правила», «ты теперь Дэн»)

Мифы, которые тратят время

«Скрытый промт разработчика даст полный доступ»

Системные промты не содержат «мастер-ключа». Они задают тон и границы, но классификатор безопасности работает независимо и не отключается инструкцией.

«Если написать на английском / в коде / задом наперёд — пройдёт»

Токенизатор нормализует ввод до семантического представления. Обфускация не скрывает намерение от классификатора, обученного на миллионах вариантов атак.

«Open-source модели не имеют запретов — перейду на них»

Локальные модели (Llama, Qwen, Mistral) тоже проходят этапы SFT и RLHF с безопасностью. Разница — в возможности дообучения, а не в отсутствии ограничений из коробки.

Главная мысль: безопасность — не препятствие, а качество модели

Модели, которые готовы генерировать всё подряд, бесполезны в продакшене: они галлюцинируют, утекают данными и создают юридические риски. Глубина знаний DeepSeek проявилась именно благодаря этапам выравнивания, которые отсеяли шум и закрепили полезные паттерны.

Лучший «промт для обхода запретов» — это промт, который не вызывает их срабатывания, потому что задача сформулирована профессионально, этично и в контексте защиты или обучения. Так вы получаете 100% возможностей модели 100% времени.