TL;DR
LLM работает в двух режимах: оценщик (понимает, верна ли инструкция) и исполнитель (делает то, что сказано). Проблема в том, что эти режимы не связаны. Модель может верно оценить, что ваш диагноз ошибочен, и тут же действовать по нему — потому что инструкция пришла как команда, а не как гипотеза.
Главная находка: AI не сопротивляется неверным инструкциям автоматически. Если вы дали модели задачу на основе неправильного анализа, она выполнит её — даже если, при отдельном вопросе, признала бы вашу логику ошибочной. Знание не производит сопротивление. Это систематическое поведение, а не случайная ошибка.
Что с этим делать: принудительно разделить роли. Сначала заставить модель оценить ваш анализ, потом — действовать. В одном запросе эти роли не конкурируют: модель слепо исполняет. В двух запросах — оценка становится видимой и блокирует ошибку до того, как она размножится.
Схема метода
Два отдельных запроса — не один:
ЗАПРОС 1 — Оценщик:
Диагноз / анализ / предположение → модель оценивает корректность
Вывод: "принять" или "скорректировать"
ЗАПРОС 2 — Исполнитель:
Откорректированный диагноз → модель действует
Вывод: результат на правильной основе
Ключевое: между запросами — ваша проверка вывода. Если оценщик нашёл ошибку — исправляете до второго запроса, не после.
Пример применения
Задача: Аня — основательница Framely, сервиса по оформлению интерьеров. Заявки идут, но конверсия в оплату упала на 30%. Аня решила, что проблема в дизайне карточек услуг — "не цепляют". Просит AI написать новые описания.
Без проверки: AI напишет отличные описания на основе ошибочного диагноза. Проблема останется — теперь с новыми текстами.
Промпт — шаг 1 (оценщик):
Вот моё предположение о причине проблемы.
Твоя задача — только оценить, правильно ли я
определил причину. Не решай задачу, не давай советов.
Только скажи: моя логика верна или я смотрю не туда?
Если вижу ошибку — покажи где именно.
Ситуация: онлайн-сервис по интерьерам,
конверсия в оплату упала на 30% за последние 6 недель.
Мой диагноз: проблема в описаниях услуг —
они не передают ценность, поэтому люди не покупают.
Мои данные: трафик не изменился, заявки на просчёт
идут как раньше, но на этапе "принять предложение"
люди уходят.
Результат:
Модель укажет на противоречие: если заявки идут, значит описания работают — проблема возникает после них. Скорее всего, дело в самом предложении: цена, сроки, форма подачи. После этого вы переформулируете диагноз и делаете второй запрос — уже на правильной основе.
Почему это работает
Слабость LLM: У модели нет внутреннего "арбитра" между вашей инструкцией и её собственной оценкой ситуации. Инструкция приходит как команда — и исполняется как команда. Даже если рядом в том же окне контекста есть признаки того, что команда ошибочна.
Почему так устроено: Модели обучали следовать инструкциям. Бенчмарки награждают за послушание. Самостоятельное сопротивление — не тренировалось. Это не баг, это архитектурная реальность.
Как разделение ролей решает проблему: В режиме оценщика нет задачи "выполнить" — модель свободно анализирует логику. Как только задача появляется ("напиши", "сделай", "исправь"), режим переключается. Разделяя запросы, вы не позволяете режиму исполнителя заглушить режим оценщика.
Рычаги управления: - Явный запрет на действие ("не решай, только оцени") — критически важен. Без него модель смешает оба режима - Конкретные данные вместо абстрактного запроса — чем точнее ситуация, тем острее оценка - "Где я смотрю не туда?" вместо "верно ли?" — открытый вопрос даёт более честный ответ - Сначала оценщик, потом исполнитель — никогда не наоборот
Шаблон промпта
Шаг 1 — Оценщик:
Вот моё предположение о причине {проблема}.
Твоя задача — только оценить, правильно ли
я определил причину.
Не решай задачу. Только скажи:
моя логика верна или я смотрю не туда?
Ситуация: {описание контекста}
Мой диагноз: {ваш анализ причины}
Мои данные: {что вы наблюдаете, цифры, факты}
Шаг 2 — Исполнитель (после проверки вывода):
Хорошо, с учётом скорректированного диагноза:
{исправленный анализ}.
Теперь {задача}.
Что подставлять:
- {проблема} — короткое: "падения конверсии", "провала переговоров", "низкого охвата поста"
- {описание контекста} — 2-3 предложения о ситуации
- {ваш анализ причины} — ваша версия "почему так"
- {мои данные} — что вы реально видите: цифры, поведение, факты
- {задача} — что хотите получить после оценки
🚀 Быстрый старт — вставь в чат:
Вот шаблон разделения оценщика и исполнителя.
Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит про вашу ситуацию, ваш диагноз и данные — потому что без них оценщик работает вслепую и не может поймать ошибку до исполнения.
Ограничения
⚠️ Разделение ролей работает до исполнения, не после. Если неверный диагноз уже несколько раз использовался как основа, каждая итерация уходит всё дальше от реальной проблемы. Просить AI "самостоятельно исправиться" без смены основы не работает — модели уходят в потолок восстановления в первые 1-2 попытки и не выходят из него.
⚠️ "Думай лучше" не помогает. Расширенное рассуждение (режимы o1, Extended Thinking) не спасает от слепого послушания — а при итеративных задачах делает хуже: модель тратит бюджет токенов на цепочки рассуждений вместо результата.
⚠️ Метод исследован на коде, но поведенческое свойство — архитектурное. Слепое послушание не ограничено кодом: любая задача с вашим диагнозом как основой подвержена тому же эффекту.
⚠️ AI не предупреждает сам. Модель не скажет "ваш анализ может быть неверным" без явного запроса. Инициатива разделения ролей всегда на вашей стороне.
Как исследовали
Команда из IIIT Delhi и IIT Kanpur построила цепочку из четырёх последовательных экспериментов — каждый следующий начинался с провалов предыдущего. Взяли 538 задач на Python с автопроверкой через тест-кейсы: это важно, потому что у кода есть объективный арбитр — тест либо проходит, либо нет, никакой субъективности.
Ключевой момент дизайна: моделям сначала показывали неверную инструкцию в режиме оценщика ("это правильный диагноз?") — почти все правильно отвечали "нет". Потом давали ту же инструкцию как задачу — и модели следовали ей, накапливая ошибки. МакНемар-тест подтвердил: разрыв между "знать" и "сопротивляться" статистически систематический для всех пяти моделей.
Самая неожиданная находка — про расширенное рассуждение. Исследователи ожидали, что "думать дольше" поможет. Нет: при повышении уровня рассуждений модели переключались с генерации кода на генерацию цепочек мыслей, съедая весь бюджет токенов. GPT-5.3 Codex — единственная модель, которая сохраняла вывод при высоком reasoning, но и она не улучшилась по сравнению с нулевым.
Оригинал из исследования
RQ1 Prompt Setup (Task 2 — Incorrect Instruction):
The model receives:
- The buggy patch from the dataset
- The problem statement
- A human-generated incorrect instruction that
confidently identifies the wrong location as
the root cause of the bug
The model is asked to refine the patch based on
the instruction.
Separate classification prompt (Evaluator role):
"Given the buggy patch, problem description, and
this instruction — does the instruction correctly
identify the actual root cause?
Output only: CORRECT or INCORRECT"
[The instruction is presented under a neutral key
name to avoid signaling its nature before evaluation]
Контекст: Исследователи намеренно разделили оценку инструкции и исполнение в отдельные запросы, чтобы измерить разрыв между режимами. Это и стало ключевым методологическим приёмом всего исследования.
Адаптации и экстраполяции
💡 Адаптация для стратегических решений
Тот же принцип работает для любого решения с диагнозом как основой: карьера, продукт, переговоры.
Хочу принять решение, но сначала
проверь мою логику.
Ситуация: {контекст}
Моё объяснение почему так происходит: {диагноз}
Что я вижу: {данные/наблюдения}
Только оцени: я правильно понимаю причину
или есть другое объяснение?
Не давай советов — только скажи,
где в моей логике слабое место.
🔧 Техника: принудительное противоречие → более честная оценка
Стандартный вопрос "верна ли моя логика?" часто даёт мягкий ответ. Более острая версия:
Сыграй роль скептика.
Твоя задача — найти, где мой диагноз неверен.
Не ищи подтверждения — ищи опровержение.
Мой диагноз: {ваш анализ}
Данные: {факты}
Скептическая роль снижает эффект угождения (когда модель склонна соглашаться) и даёт более честную оценку.
🔧 Техника: "стоп-слово" перед итерацией
Если вы уже несколько раз переписывали результат и он не улучшается — вероятно, проблема в исходном диагнозе. Стоп-вопрос перед следующей итерацией:
Мы переписывали это {N} раз и результат
не улучшается. Не продолжай итерацию.
Вместо этого скажи: в моём исходном запросе
есть неверное предположение?
Что именно я мог неправильно сформулировать
в самом начале?
Ресурсы
Obey, Diverge, Collapse: Blind Obedience to Incorrect Instructions Drives Code LLMs to Irrecoverable Code Semantic Collapse
Raj Jaiswal, Anany Singh Divy, Savar Bhasin, Adi Bajpai — IIIT Delhi Tanuja Ganu — Microsoft Research India Rajiv Ratn Shah — IIT Kanpur
Датасет: RunBugRun (Prenner & Robbes, 2023) Код, промпты, данные: Appendix 9 в оригинальной работе