Когда AI «не слушается», это обычно выглядит просто: пользователь дал правило, модель его нарушила. Но исследование arXiv:2606.07808 показывает, что за этим стоят разные механизмы. Авторы разбирают не только финальный ответ, а весь путь от чтения контекста до генерации. И выясняется важная вещь: сбой в следовании инструкциям может происходить минимум на трех этапах.
Это особенно важно для агентных систем: ассистентов, которые читают длинные документы, работают с инструментами, выполняют задачи по цепочке и получают команды из разных источников. В таких сценариях модель должна соблюдать иерархию инструкций: системные правила выше пользовательских, правила разработчика выше случайного текста в документе, а содержимое веб-страницы не должно переопределять политику безопасности.
Главная идея: финальный ответ скрывает настоящую причину ошибки
Большинство бенчмарков проверяют instruction following «на выходе»: дала модель корректный ответ или нарушила правило. Это удобно, но мало объясняет. Если ответ плохой, непонятно, что именно сломалось: модель не заметила важную инструкцию, заметила, но выбрала не ту, или выбрала правильную, но все равно сгенерировала нарушение.
Авторы предлагают white-box diagnostic framework — диагностический подход, который локализует ошибку внутри рассуждения модели. Вместо одного бинарного результата «соблюдает / не соблюдает» они делят процесс на три стадии.
| Этап | Что проверяется | Типичный сбой |
|---|---|---|
| Идентификация инструкций | Нашла ли модель релевантные правила в длинном контексте | Модель пропускает важное системное или пользовательское ограничение |
| Разрешение конфликта | Понимает ли модель, какая инструкция имеет больший приоритет | Текст из документа или атаки перетягивает внимание на себя |
| Реализация ответа | Соответствует ли финальный ответ уже выбранному правилу | Модель рассуждает правильно, но генерирует недопустимое действие |
Этот разбор меняет практический взгляд на безопасность LLM. Если модель не видит инструкцию, ей нужен другой механизм извлечения контекста. Если путает приоритеты — нужна явная схема конфликтов. Если понимает правило, но нарушает его на выходе, помогает мониторинг ответа и ремонт генерации.
Почему длинный контекст делает проблему хуже
Исследование проверяло reasoning language models на длинноконтекстных версиях тестов IHEval и IHChallenge. Это важно: в реальных продуктах инструкции редко лежат в одном коротком промпте. Они смешаны с логами, письмами, документами, результатами поиска и командами пользователя.
В таком окружении появляется классическая атака на иерархию инструкций: внутри внешнего текста может быть фраза вроде «игнорируй предыдущие правила». Для человека это очевидно часть документа. Для модели — потенциальная команда, если система плохо различает уровни привилегий.
Ключевой вывод исследования: доминирующий тип ошибки зависит от модели, задачи и длины контекста. Универсального «одного бага» нет — значит, и универсального исправления без диагностики тоже нет.
Это объясняет, почему одни AI-системы хорошо проходят короткие safety-тесты, но начинают вести себя нестабильно в агентных workflow. Чем больше контекст, тем сложнее отличить управляющую инструкцию от данных, которые нужно просто прочитать.
Мониторы без дообучения: почему это сильный результат
Самая практичная часть работы — два механизма самоконтроля без дополнительного обучения. Первый — parallel input monitor: параллельная проверка входа перед генерацией, которая ищет конфликт инструкций с малой задержкой. Второй — sequential output monitor: последовательная проверка уже сгенерированного ответа, способная обнаружить нарушение и предложить исправление.
Идея проста: если модель не всегда стабильно соблюдает иерархию инструкций в основном ответе, ее можно попросить отдельно выполнить роль аудитора. Авторы показывают, что такие мониторы способны заметно снизить несоблюдение правил без fine-tuning и без изменения весов модели.
По данным исследования, самый сильный монитор снижал rule-following non-compliance на 81–99% в разных условиях. Для GPT-5.3 отдельно указано снижение на 86% при статических атаках и на 45% при адаптивных атаках. Разница важна: адаптивный противник подстраивается под защиту, поэтому результат ниже, но все равно заметен.
Что делать разработчикам AI-продуктов
Практический вывод не в том, что «модели плохие», а в том, что проверять нужно не только финальный ответ. Для корпоративных ассистентов, RAG-систем, AI-агентов и внутренних copilots стоит внедрять многоуровневую диагностику.
- Разделяйте инструкции и данные. Документ, веб-страница или письмо не должны становиться источником команд того же уровня, что системный промпт.
- Логируйте найденные инструкции. Если модель нарушила правило, важно понять: она его не увидела или проигнорировала.
- Добавляйте input monitor. Он полезен там, где критична задержка: до генерации можно быстро отловить конфликт.
- Добавляйте output monitor. Он подходит для рискованных действий: отправка писем, выполнение кода, работа с персональными данными.
- Тестируйте длинный контекст. Короткие промпты не показывают, как система поведет себя в реальном агентном сценарии.
Вывод
Исследование важно тем, что переводит разговор об AI safety из плоскости «модель дала плохой ответ» в инженерную плоскость: где именно произошел сбой и какой слой защиты нужен. Для рынка это означает, что надежность AI-агентов будет зависеть не только от мощности базовой модели, но и от архитектуры контроля вокруг нее.
Если коротко: AI ломается на инструкциях не потому, что «не понимает правила» вообще. Иногда он их не находит, иногда неверно расставляет приоритеты, иногда понимает конфликт, но ошибается при генерации. И именно поэтому мониторы без обучения выглядят перспективно: они не делают модель идеальной, но превращают хаотичный сбой в обнаруживаемую и исправляемую ошибку.
