MIT Technology Review предупредил: отказам ИИ-моделей доверяют слишком сильно

В выпуске рассылки The Download от 9 октября MIT Technology Review выносит на первое место тезис, который многие в индустрии считают аксиомой: мы слишком верим в способность ИИ сказать «нет». Сегодняшние модели обучены отказывать на огромное число запросов. Спросите чат-бота, как отравить человека, и он, скорее всего, откажется. Издание считает, что именно на такой отказ индустрия возлагает слишком много надежд. Второй сюжет выпуска посвящён побочным эффектам препаратов для похудения и к ИИ не относится.

Важная оговорка: в анонсе есть только завязка аргумента, без данных и имён. Полную позицию авторов стоит читать в оригинале. Ниже разбираем, как отказы устроены технически и где у них слабые места.

Как модели учатся говорить «нет»

Отказ не встроен в LLM изначально. Базовая модель просто продолжает текст и с одинаковой готовностью опишет и рецепт пирога, и опасную процедуру. Поведение «я не могу с этим помочь» появляется позже, на этапах дообучения: люди и другие модели оценивают ответы, а система учится выбирать те, что считаются безопасными. Сверху накладываются системные промпты и внешние фильтры, которые проверяют запрос на входе и ответ на выходе.

Итог выглядит как граница, но на деле это статистическая склонность. Модель не «понимает», что запрос опасен, а узнаёт знакомые паттерны опасных запросов.

Где отказ ломается

У такой защиты три известных слабых места.

• Обход формулировкой. Ролевые сценарии, перефразирование, смена языка и разбиение опасной задачи на безобидные шаги годами остаются рабочими приёмами джейлбрейка.
• Неизвестное намерение. Вопрос о ядах задаёт токсиколог, автор детектива, студент и злоумышленник. Из одного текста запроса их не различить, поэтому система вынуждена выбирать между лишними отказами и пропусками.
• Цена ошибки в обе стороны. Слишком строгая модель перестаёт быть полезной для врачей, исследователей безопасности и журналистов. Слишком мягкая выдаёт то, чего выдавать не должна.

Отдельная проблема появляется у агентов. Когда у модели есть доступ к браузеру, почте, коду и платёжным инструментам, вежливый отказ в чате ничего не гарантирует. Опасное действие может быть собрано из серии шагов, каждый из которых по отдельности выглядит невинно.

Из чего на практике складывается защита

Если не опираться на отказ как на единственный барьер, картина получается многослойной:

• обучение на примерах отказов и предпочтениях людей;
• системные инструкции оператора с описанием допустимого и недопустимого;
• отдельные классификаторы на входе и выходе, независимые от основной модели;
• red teaming: целенаправленные попытки взлома до релиза и после него;
• ограничение прав агента на уровне инфраструктуры, а не промпта.

Последний пункт самый недооценённый. Права доступа, лимиты и подтверждение критичных действий человеком работают независимо от того, что «решила» модель.

Что делать командам, которые внедряют модели

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

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

Третье: для агентов проектируйте минимальные права и журналирование действий. Если модель ошибётся или её обманут, ущерб должен упираться в технический лимит.

Четвёртое: измеряйте обе стороны ошибки. Доля пропущенных опасных запросов и доля ложных отказов на легитимных задачах говорят о качестве системы больше, чем любой отдельный показатель.