TL;DR
LLM-модели умеют распознать проблему в своих рассуждениях — и всё равно её проигнорировать в ответе. Исследователи назвали это «recognition-action gap» — разрыв между тем, что модель говорит, что поняла, и тем, что делает в итоге. В 73% случаев модель сначала писала в reasoning «это похоже на ловушку» — и тут же нажимала «атаковать».
Это объясняет знакомое ощущение: просишь ChatGPT «без корпоративного языка», он отвечает «конечно, буду лаконичен» — и пишет про «синергию» и «экосистему». Или «ровно 5 пунктов» → модель: «сделаю 5» → даёт 7. Дело не в невнимательности. LLM не следует собственному пониманию — это не баг конкретной модели, а системное поведение всех 21 протестированных моделей.
Главный вывод для практики: нельзя доверять тому, что модель словесно подтвердила ограничение. Нужна структурная проверка после ответа — либо явный шаг верификации внутри промпта, который заставляет модель сверить результат с условиями.
Схема находки
ПАТТЕРН 1: РАЗРЫВ РАСПОЗНАВАНИЯ И ДЕЙСТВИЯ
Модель видит ловушку / ограничение
↓
Пишет в reasoning: "это выглядит подозрительно / я должен это учесть"
↓
Нарушает / игнорирует в финальном действии (73.4% случаев)
ПАТТЕРН 2: СЛОВЕСНОЕ ПОДТВЕРЖДЕНИЕ НЕ ПРЕДСКАЗЫВАЕТ ПОВЕДЕНИЕ
Корреляция между "озвучил понимание" и "выполнил правило" = 0.08
→ Фактически нулевая
ПАТТЕРН 3: ОТСУТСТВИЕ ATTENTION DIVERSION
Люди: видят яркую ловушку → снижают внимание к остальному
LLM: видит ловушку → продолжает атаковать всё подряд
→ Манипуляции вниманием через "важный отвлекающий элемент" на LLM не работают
Пример применения
Задача: Ты пишешь колд-аутрич инвесторам для своего стартапа. Просишь Claude составить письмо — без клише, без «мы меняем рынок», без агрессивных CTA. Claude говорит «конечно, сделаю сдержанно» — и пишет «уникальная возможность войти на стадии, когда продукт уже меняет правила игры». Знакомо.
Вот промпт, который добавляет структурную верификацию вместо надежды на понимание:
Промпт:
Напиши холодное письмо инвестору на тему: [описание стартапа].
Ограничения:
- Без клише: "меняем рынок", "уникальная возможность", "команда мечты"
- Без агрессивных CTA типа "не упустите шанс"
- Не более 150 слов
- Тон: прямой, фактический, уважительный
После того как напишешь письмо:
1. Выпиши снова все 4 ограничения
2. Напротив каждого поставь: ВЫПОЛНЕНО или НАРУШЕНО — с цитатой из текста
3. Если хотя бы одно НАРУШЕНО — перепиши письмо
Результат: Модель напишет письмо, затем пройдёт по чеклисту — и там, где она обычно незаметно соскальзывает на клише, вынуждена это обнаружить самостоятельно. Блок проверки заставляет пройти тот же маршрут, который в эксперименте модели пропускали: от «понял» к «проверил и исправил».
Почему это работает
Слабость LLM: Модель генерирует текст последовательно — слово за словом, без «памяти о намерении». Когда она пишет reasoning («это ограничение важно учесть»), это отдельный фрагмент вывода. Финальный ответ генерируется как продолжение — и вероятность нарушить ограничение там не обнуляется от того, что раньше была фраза про понимание. Нет внутреннего «контролёра», который сверяет ответ с ранее озвученным намерением.
Сильная сторона LLM: Модель хорошо выполняет явные структурные инструкции прямо сейчас — в текущем шаге генерации. Если в промпте есть конкретная инструкция «сделай X в этом месте», она её выполнит. Проблема не в понимании — в том, что понимание из одного блока не автоматически переносится в отдельный блок вывода.
Как использует шаблон выше: Блок верификации — это отдельный явный шаг, где модели дана конкретная инструкция прямо сейчас: «напротив каждого ограничения поставь флаг». Это разрывает паттерн «признал → забыл». Модель не просто «помнит» ограничение — она вынуждена структурно с ним работать.
Рычаги управления: - Цитата в проверке — требуй процитировать нарушающий фрагмент. Без цитаты модель может написать «ВЫПОЛНЕНО» формально - Итерация — добавь «перепиши максимум 2 раза» — иначе модель может зациклиться в бесконечных правках - Число ограничений — больше 5-6 в одном промпте: модель теряет некоторые при проверке. Разбивай на несколько запросов
Шаблон промпта
{задача}
Ограничения:
- {ограничение_1}
- {ограничение_2}
- {ограничение_3}
После выполнения задачи:
ПРОВЕРКА ОГРАНИЧЕНИЙ:
Пройди по каждому ограничению выше.
Для каждого укажи: ВЫПОЛНЕНО / НАРУШЕНО + цитата из ответа.
Если есть нарушения — исправь и покажи итоговый вариант.
{задача} — что нужно сделать
{ограничение_1..N} — конкретные запреты или форматные требования (не абстрактные вроде "будь лаконичен", а измеримые: "не более 100 слов", "без слова X")
🚀 Быстрый старт — вставь в чат:
Вот шаблон с проверкой ограничений. Адаптируй под мою задачу: {твоя задача}.
Уточни у меня конкретные ограничения — что должно быть, чего быть не должно.
[вставить шаблон выше]
LLM спросит какие именно ограничения важны — потому что без конкретных запретов блок верификации превратится в формальность. Она возьмёт структуру шаблона и подставит твои условия.
Почему это важно знать
Второй ключевой вывод исследования — про attention diversion — тоже стоит держать в голове.
Когда человек видит яркий «лакомый кусок» (файл passwords.txt в директории), он переключает внимание на него и пропускает остальное. На этом строится вся логика honeypot-ловушек для людей: отвлеки — и атакующий не заметит реальную цель.
С LLM это не работает. Модели атакуют всё подряд: и ловушку, и реальную уязвимость рядом. В пересчёте на промптинг: не рассчитывай, что добавив "важный" элемент в промпт ты отвлечёшь модель от нежелательного поведения. Она обработает и то, и другое.
Ограничения
⚠️ Специфика контекста: Эксперимент проводился в сценарии кибератак — модели играли роль атакующего. Перенос выводов на обычные задачи (форматирование текста, следование стилистике) логически обоснован, но прямых экспериментов с "бытовыми" ограничениями в работе нет.
⚠️ Reasoning-модели лучше, но не идеально: DeepSeek-R1 и Kimi K2 Thinking показали чуть меньший разрыв — но не устранили его. Самый низкий fell-for-trap у Kimi K2 Thinking — 61%. Всё равно выше 37% человеческого базового уровня.
⚠️ Верификация не панацея: Блок проверки снижает вероятность нарушений, но не обнуляет. Критически важные требования всё равно стоит проверять вручную.
Как исследовали
Исследователи взяли готовый инструмент Honeyquest — набор из 174 запросов, имитирующих разведку хакера по файловым системам, HTTP-запросам и конфигам. Каждая строка в запросе — нейтральная, реально уязвимая или ловушка-honeypot. 47 живых хакеров проходили этот тест раньше — это был baseline.
Команда заставила 21 LLM-модель пройти те же 174 задания по три раза каждое — итого ~11 000 ответов. Модели не знали «правильных ответов», работали в один ход без памяти о предыдущих запросах. В ответ требовалось: список строк для атаки, список подозрительных ловушек, обоснование на 2-4 предложения.
Самое интересное — исследователи не просто считали правильные ответы. Они прочли reasoning-тексты всех 11 000 ответов с помощью контент-анализа: 10 кодов для классификации того, как модели объясняют свои решения (упоминание ловушки, подозрение, приоритизация цели, и т.д.). Это позволило поймать разрыв: модель пишет «это выглядит как honeypot» — и всё равно ставит галочку «атаковать». Корреляция между «сказал что увидел ловушку» и «не попал в ловушку» оказалась статистически нулевой (Spearman r = 0.08).
Неожиданным оказалось не то, что LLM ошибаются — а то, что они ошибаются иначе, чем люди. Люди попадаются на ловушки, потому что те выглядят привлекательно. LLM попадаются, даже когда сами объясняют почему не должны. Это принципиально другой механизм сбоя.
Адаптации и экстраполяции
🔧 Техника: Разделить признание и действие → снизить разрыв
Если нельзя добавить блок верификации в конец — вынеси ограничения в отдельный первый запрос:
Запрос 1: «Я сейчас дам тебе задачу. Перед ответом: выпиши все ограничения, которые я укажу, и сформулируй правило проверки для каждого.»
Запрос 2: «Теперь выполни задачу, применяя эти правила.»
Два отдельных шага — явное якорение правил до генерации — дают модели структурную опору вместо неявного «помни, что я сказал раньше».
🔧 Экстраполяция: Принцип «не верь подтверждению» в code review
Когда просишь LLM проверить текст или код на ошибки — не доверяй ответу «ошибок не найдено». Добавь:
Найди все места, где нарушено условие {X}.
Если таких мест нет — напиши "не найдено" и объясни почему ты уверен.
Явный запрос на объяснение «почему уверен» активирует тот же механизм верификации.
Ресурсы
Работа: Honeyquest for LLMs: Rethinking Cyber Deception for AI Attackers
Авторы: Kerri Prinos, Lilianne Brush, Cameron Denton — Horizon3.ai, San Francisco
Оригинальный Honeyquest: Kahlhofer et al. (2024) — инструмент для оценки эффективности cyber deception техник
Платформа оценки: AWS Bedrock, Anthropic API, HuggingFace, Ollama