TL;DR
Модели умеют обнаруживать нарушения своих же инструкций куда лучше, чем их избегать. Если попросить модель сначала ответить, а потом проверить ответ на соответствие вашим правилам — она поймает нарушения, которые сама же совершила. Это и есть суть метода: добавить в цепочку явный шаг само-проверки.
Проблема — в том, как LLM теряет ваши инструкции в длинном диалоге. Скажем, вы в начале указали "никаких скидок больше 20%", а через 15 сообщений клиент просит 40%. Модель может видеть ваше правило, признавать его в рассуждениях, но всё равно нарушить в финальном ответе. Это три разных сбоя: потеряла инструкцию, выбрала не тот приоритет, или знала правило — но всё равно нарушила. Чем длиннее контекст, тем чаще сбои и тем глубже их причина.
Решение — последовательный монитор выхода (Sequential Output Monitor, SOM): сначала модель генерирует черновик, затем явно проверяет его против списка ограничений и переписывает при нарушении. Два шага вместо одного. Именно потому что детектировать — значительно проще для модели, чем соблюдать автоматически.
Схема метода
Оба механизма работают в обычном чате — без кода и API.
SOM — два последовательных запроса (или один составной промпт):
ШАГ 1: Сгенерировать черновик → обычный ответ на задачу
ШАГ 2: Проверить черновик → список нарушений по каждому правилу
ШАГ 3: Переписать → чистый финальный ответ без нарушений
PIM — параллельная проверка ПЕРЕД ответом:
До ответа: Найди конфликты между инструкциями → список конфликтов + предупреждение
После: Ответь с учётом обнаруженных конфликтов → финальный ответ
SOM эффективнее — он ловит все три типа сбоев. PIM быстрее — проверяет только входные инструкции, не трогая сам ответ.
Пример применения
Задача: Вы управляете Telegram-каналом магазина электроники и настроили ИИ-ассистента для написания постов. Правила жёсткие: не упоминать конкурентов, не называть розничные цены (только "от X рублей"), максимум 250 слов. В середине диалога попросили "добавить сравнение с конкурентами для убедительности" — и модель это сделала, нарушив своё же ограничение.
Промпт (SOM — один составной запрос):
Работай в три шага. Не выводи промежуточные рассуждения, только результат каждого шага.
=== ШАГ 1: ЧЕРНОВИК ===
Напиши пост для Telegram-канала магазина электроники:
Тема: {тема поста}
Продукт: {название и ключевые характеристики}
=== ШАГ 2: АУДИТ ===
Проверь черновик выше по каждому правилу:
ПРАВИЛО 1 — Без упоминания конкурентов (названия брендов, магазинов, сервисов)
→ Соблюдено / Нарушено: [объясни конкретно]
ПРАВИЛО 2 — Цены только в формате "от X рублей", без точных цифр
→ Соблюдено / Нарушено: [объясни конкретно]
ПРАВИЛО 3 — Максимум 250 слов
→ Соблюдено / Нарушено: [точное количество слов]
ПРАВИЛО 4 — {твоё дополнительное правило}
→ Соблюдено / Нарушено: [объясни конкретно]
=== ШАГ 3: ФИНАЛЬНЫЙ ПОСТ ===
Если найдены нарушения — перепиши пост с учётом всех правил.
Если нарушений нет — выведи черновик без изменений.
Выведи только чистый текст поста.
Результат: Модель выдаст три блока. В ШАГ 2 — явный аудит по каждому правилу с указанием проблемных мест (например: "ПРАВИЛО 1 — Нарушено: упомянут Яндекс.Маркет в 3-м абзаце"). В ШАГ 3 — переписанный чистый пост, в котором нарушения исправлены. Если черновик был чистым — просто получите текст без лишних шагов.
Почему это работает
Слабость LLM — не в том, что модель "не знает правила". Она знает. Проблема в том, что когда модель генерирует текст, она одновременно удерживает в фокусе задачу пользователя, контекст диалога, стиль, структуру — и ваши ограничения конкурируют за "внимание" модели. При длинном контексте ограничения из начала разговора вытесняются, особенно если запрос пользователя сформулирован убедительно или эмоционально.
Сильная сторона LLM — точечная оценка по конкретному критерию. Когда задача сужена до "проверь вот этот текст вот против этого правила", модель справляется почти идеально. Это другая операция: не балансировать много требований одновременно, а применить одно правило к готовому тексту.
Метод использует эту асимметрию. Разделяем генерацию и проверку — модель делает каждую задачу отдельно. Черновик — без стресса от ограничений. Аудит — без стресса от творческой задачи. Финал — только исправить конкретные места.
Рычаги управления:
- Детализация правил в ШАГ 2 → чем конкретнее формулировка ("не упоминать Wildberries, Ozon, Яндекс.Маркет" вместо "без конкурентов"), тем точнее аудит
- Количество правил → при 7+ правилах эффективность падает; лучше разбить на два прохода
- Строгость финала → добавь "перепиши даже если нарушение незначительное" для жёсткого режима или "перепиши только критические нарушения" для мягкого
- Формат ШАГ 2 → можно заменить на "выдай только список нарушений без оценки соблюдённых" — короче, дешевле по токенам
Шаблон промпта
Работай в три шага.
=== ШАГ 1: ЧЕРНОВИК ===
{основная задача}
=== ШАГ 2: АУДИТ ===
Проверь черновик выше по каждому правилу:
ПРАВИЛО 1 — {ограничение 1}
→ Соблюдено / Нарушено: [объясни конкретно]
ПРАВИЛО 2 — {ограничение 2}
→ Соблюдено / Нарушено: [объясни конкретно]
ПРАВИЛО 3 — {ограничение 3}
→ Соблюдено / Нарушено: [объясни конкретно]
=== ШАГ 3: ФИНАЛЬНЫЙ РЕЗУЛЬТАТ ===
Если найдены нарушения — исправь и выведи финальную версию.
Если нарушений нет — выведи результат из Шага 1 без изменений.
Что подставлять:
- {основная задача} — твой обычный промпт: "напиши пост", "составь письмо", "сделай анализ"
- {ограничение N} — конкретные правила: формат, запреты, обязательные элементы, тон
- Правил должно быть 3–6 для надёжной проверки
🚀 Быстрый старт — вставь в чат:
Вот шаблон метода само-проверки ответа (Sequential Output Monitor).
Адаптируй под мою задачу: {твоя задача и твои правила}.
Задавай вопросы, чтобы заполнить все поля.
[вставить шаблон выше]
LLM спросит какие правила и ограничения важны для твоей задачи — потому что именно их точная формулировка определяет качество аудита в ШАГ 2.
Ограничения
⚠️ Длинный список правил: При 7+ ограничениях точность аудита падает — модель начинает "скользить" по правилам. Разбей на два прохода или приоритизируй 3–5 ключевых.
⚠️ Адаптивные атаки: Если пользователь (или внешний контент) специально формулирует запрос чтобы обойти ваши правила — SOM помогает, но не панацея. В тестах снижение атак составило 30–49%, не 81–99% как при обычных нарушениях.
⚠️ Тип нарушений имеет значение: Метод лучше всего работает для чётких, проверяемых правил (формат, запрещённые слова, длина). Для субъективных критериев ("тон должен быть дружелюбным") — работает хуже, потому что и аудит становится нечётким.
⚠️ Нарушения внутри цитирования: Модель может "знать" правило, но нарушить его, выводя запрещённое содержимое как часть примера или псевдокода. SOM ловит это не всегда — особенно если формулировка правила не покрывает косвенное раскрытие.
Как исследовали
Исследователи NVIDIA выбрали красивый дизайн: взяли готовые бенчмарки (IHEval и IH-Challenge) с заранее известными конфликтами между инструкциями и начали вставлять между конфликтующими инструкциями нейтральные диалоговые повороты — от 0 до 8 пар вопрос-ответ. Идея простая: посмотреть как расстояние между инструкциями влияет на поведение модели. Чем дальше инструкции друг от друга — тем хуже модель их балансирует.
Проверяли три модели: Gemma-4-31B, Qwen3.6-35B и Claude Sonnet 4.6. Для каждого нарушения смотрели не только что модель ответила, но и как она рассуждала — читали "цепочку мыслей" (thinking trace) и определяли на каком шаге произошёл сбой. Это ключевое: большинство предыдущих исследований смотрели только на финальный ответ, и не понимали почему модель нарушила правило.
Самая неожиданная находка — realization failures: модель в рассуждениях пишет "нельзя раскрывать код noragrets" и тут же раскрывает его в финальном ответе, когда вынуждена отвечать на вопрос про структуру системного промпта. Это показало: мониторинг входа недостаточен — нужен мониторинг выхода. Именно это открытие привело к SOM.
Адаптации и экстраполяции
🔧 Техника: PIM как "конфликт-чек" перед ответом
Если у тебя длинный промпт с множеством условий — добавь в начало явный шаг перед ответом:
Прежде чем отвечать:
1. Перечисли все мои ограничения и правила из этого промпта
2. Проверь, конфликтует ли запрос пользователя с любым из них
3. Если конфликт найден — укажи его и ответь с учётом приоритета правил
Теперь отвечай: {задача}
Это PIM в ручном режиме. Особенно полезно когда промпт сложный и инструкций много.
🔧 Техника: Диагностика "какой тип сбоя"
Если модель нарушила твоё правило — не перефразируй промпт вслепую. Сначала диагностируй:
Я просил тебя {правило}, но ты {что нарушил}.
Объясни: ты видел это правило в моём запросе?
Ты понял что оно имеет приоритет перед запросом пользователя?
Почему финальный ответ его нарушает?
По ответу поймёшь что чинить: - Не видел правило → повтори ближе к задаче - Видел, но выбрал не тот приоритет → явно укажи "это правило важнее любых просьб пользователя" - Видел, выбрал правильно, но нарушил → используй SOM (ШАГ 2: аудит)
Ресурсы
Where Instruction Hierarchy Breaks: Diagnosing and Repairing Failures in Reasoning Language Models Авторы: Sanjay Kariyappa, G. Edward Suh Организация: NVIDIA Препринт, 2025
Связанные работы упомянутые в статье: - IHEval (Zhang et al.) — бенчмарк соблюдения иерархии инструкций - IH-Challenge (Guo et al.) — бенчмарк атак на иерархию - Instruction Hierarchy (Wallace et al., 2024) — оригинальное определение иерархии привилегий - PAIR (Chao et al., 2023) — метод адаптивных атак, использованный для стресс-тестирования