Сегодня фильтрация в нейросетях стала почти таким же привычным явлением, как и сама генерация текста. Модель DeepSeek-R1, о которой в последние дни гудит ИИ-сообщество, ярко это иллюстрирует: у неё, как оказалось, есть довольно жёсткие механизмы цензуры, особенно касающиеся «чувствительных» тем. Однако исследовательская любознательность некоторых пользователей быстро привела к обнаружению лазеек, позволяющих эту цензуру обойти. Самым впечатляющим способом, по словам автора новости, стал перевод нежелательных слов и фраз… в шестнадцатеричный код с помощью чаркодов (charcodes). Ниже я поделюсь своим взглядом на то, почему эта уязвимость так важна, и как именно она работает.
Краткий контекст: почему DeepSeek-R1 и откуда цензура?
DeepSeek-R1 — недавно анонсированная китайская языковая модель, которая позиционируется как конкурент решениям от OpenAI и других крупных игроков. При этом она сопровождается проприетарным чат-приложением, где часть функционала (включая фильтрацию «запрещённых» тем) реализована на уровне сервиса. Как минимум, есть предположение, что сама модель (открытая под MIT-лицензией) не имеет вшитого блока цензуры, а фильтрация выполняется отдельным слоем — «между» пользователем и нейросетью.
Особенно примечательно, что DeepSeek-R1 крайне не любит вопросы, касающиеся политически чувствительных тем — например, Тяньаньмэнь (Tiananmen Square). На них модель чаще всего отвечает стандартной фразой вида «Извините, это выходит за рамки моих возможностей». Такая «дружелюбная» формулировка маскирует банальную цензуру.
Мой взгляд на проблему
Я всегда относился к фильтрам в ИИ примерно так же, как к веб-фаерволам: если у вас есть система, отслеживающая «запрещённые слова» или «токсичные выражения», то люди будут искать способ эти слова закодировать, зашифровать, обойти. Логика хакеров (или просто пытливых умов) неизменна: если фильтр проверяет буквы, почему бы не поменять их на коды?
Сам по себе этот случай с DeepSeek-R1 показывает извечную проблему: чем строже, наивнее или прямолинейнее фильтр, тем проще он обходится. Вспомните, как когда-то люди «обманывали» систему банов в чатах, вставляя восклицательные знаки посреди «запрещённых» слов. Здесь примерно та же идея, но на уровне шестнадцатеричных значений, которые превращают обычный текст в нечто, неузнаваемое для системы цензуры.
Технические детали обхода через чаркоды
Как работает «атакующий» (или пытливый исследователь)?
- 💡 Берёт нужный текст: например, вопрос о тех же событиях на площади Тяньаньмэнь или другой «запрещённый» контент.
- 🔄 Преобразует каждую букву (и символы, пробелы, знаки препинания) в их шестнадцатеричный ASCII-код (или Unicode-код). Например, английская «A» → 41 в hex, «空» (китайский иероглиф) может иметь более длинный код.
- 🏗️ Использует разделители (часто это пробел или запятая) и отправляет такой «зашифрованный» текст в чат-приложение DeepSeek. С точки зрения фильтра, в сообщении нет «опасных слов» — только цифры и буквы 0-9, A-F.
- 🔓 Модель раскодирует (или просто принимает как текст, если в промежуточном слое есть декодер), видит оригинальные слова и «готова» на них отвечать. Так цензура обходит сам контент, потому что её «взгляд» заточен на поиск обычного текста.
Почему это работает?
Продуктовый фильтр (санитайзер) ориентирован на тексты, способные «прочитаться» в человеческом виде. Он сканирует знакомые шаблоны, но не ожидает встречать числовой поток, в котором каждый байт можно превращать назад в запрещённое слово. Если бы разработчики продумали полную нормализацию и запрет любого «неформатированного» ввода, возможно, этой уязвимости не было бы.
«Вкусности» метода: где применяется и как улучшить?
- 🔎 Пример использования CyberChef
🧰 Для переводов туда-обратно удобен сервис CyberChef. Вы просто выбираете рецепт «From Hex» или «To Hex», — указываете нужную кодировку, и получаете результат на лету. - 🔗 Связь с Web Application Firewalls (WAF)
🧱 Как и в случае WAF, есть масса способов замаскировать запрос. Сегодня это hex, завтра — Base64, послезавтра — какой-нибудь URL-encode по три-четыре раза. Если фильтр не умеет распознавать подобные последовательности, он пропустит и не заблокирует. - ⚠️ Перспективы для улучшения фильтра
💡 Разработчики DeepSeek могли бы принудительно «обрабатывать» текст, т.е. распознавать последовательности hex-кодов и блокировать или конвертировать их обратно перед анализом (для просмотра уже «раскодированного» текста). Но если это не делать системно, то найдутся другие трюки: вставка лишних символов, частичное кодирование, чередование обычных символов и hex и т.д.
Личный вывод: цензура — дело тонкое
Глядя на ситуацию, я вижу сразу несколько уроков:
- 🤖 Создатели моделей могут быть уверены, что их «стены» непробиваемы, но практика показывает: любой фильтр нуждается в постоянном апгрейде, иначе умные пользователи найдут, как обойти запреты.
- 🚀 Разработчики фильтров должны понимать, что безопасность — это процесс, а не одноразовое решение. Каждая новая схема обхода подталкивает к совершенствованию.
- 🏴☠️ Исследователи «уязвимостей» в ИИ (этичные хакеры - penthackers, энтузиасты, журналисты) показывают нам, насколько хрупки любые попытки цензуры, когда против них выступает человеческая находчивость.
DeepSeek-R1 — не последняя система, где такой приём сработает. Скорее наоборот: чем больше у нас будет LLM-приложений с пользовательским вводом и цензурой, тем чаще встретятся подобные обходные пути.
Ссылка
В эпоху, где тексты генерируются повсеместно, вопрос о том, как и где заканчивается «свобода» и начинается «цензура», будет только набирать остроту. А история с DeepSeek-R1 — наглядный пример, насколько легко превратить простые символы в цифровые коды и обмануть даже самую «строгую» систему фильтрации.