TL;DR
Когда нужно доказать, что решения не существует — задача нерешаема, план невозможен, обход защиты не сработает — модель по умолчанию продолжает искать один удачный пример вместо того, чтобы систематически перебрать все случаи и найти противоречие в каждом. Она ведёт себя так, будто перед ней задача «найди хоть один вариант», даже когда задача на самом деле «докажи, что вариантов нет».
Исследователи заметили две беды. Первая: когда модель ошибается на простых задачах («найди решение»), её рассуждение резко сужается — она начинает раньше времени проверять один и тот же вариант по кругу и быстро останавливается на ответе, хотя формально «просмотрела» всю задачу. Вторая, более серьёзная: на задачах «докажи, что решения нет» модель почти всегда ошибочно объявляет «решение есть» — потому что вместо разбора всех случаев она перебирает кандидатов, как будто ищет пример, а не строит доказательство невозможности.
Простая просьба «попробуй ещё раз внимательнее» эту ошибку не лечит — модель просто повторяет тот же неправильный подход. Помогает только явное указание сменить процедуру рассуждения: разбить задачу на случаи, вывести все следствия каждого случая и искать противоречие. Такой промпт поднял точность модели Llama3-70B на задачах «докажи невозможность» с 13% до 85% — исправив 85 из 100 ошибок.
Схема метода
ШАГ 1: Определи тип задачи → «найти решение» или «доказать, что решения нет»
ШАГ 2 (если «доказать, что нет»): Разбей на случаи → перечисли все варианты, которые надо проверить
ШАГ 3: Для каждого случая выведи прямые следствия → что становится обязательным или запрещённым
ШАГ 4: Найди противоречие в каждом случае → если противоречие есть везде — решения нет
ШАГ 5: Заявляй «решение есть» только после полной проверки конкретного примера по всем условиям
Всё выполняется в одном промпте — это инструкция к порядку рассуждения, не отдельные запросы.
Пример применения
Задача: Комплаенс-менеджер в банке проверяет, может ли сотрудник с определённым набором ролей в системе получить доступ к данным клиентов, если по регламенту это запрещено. Нужно не найти пример нарушения, а доказать, что нарушение невозможно при текущей матрице прав.
Промпт:
Мне нужно доказать, что сотрудник с ролями [Аналитик отчётности, Оператор колл-центра]
НЕ МОЖЕТ получить доступ к персональным данным клиентов, если система прав построена так:
[описание правил доступа].
Не пытайся сразу угадать один сценарий и остановиться. Действуй так:
1. Разбей все возможные комбинации действий сотрудника на отдельные случаи
(через основное меню, через экспорт отчётов, через API, через смену роли).
2. Для каждого случая выведи, что из правил доступа прямо следует —
что становится разрешено или запрещено в этом случае.
3. Найди противоречие: покажи, где следствия случая конфликтуют
с требованием «доступ запрещён».
4. Заяви «доступ возможен» только если нашёл полностью рабочий сценарий,
который проверил по всем правилам. Если противоречие нашлось во всех случаях —
заяви «доступ невозможен» и покажи, в каком случае и почему.
Результат: Модель выдаст структурированный разбор — список случаев, для каждого явные следствия из правил доступа, и либо найденное противоречие (доступ невозможен), либо конкретный рабочий сценарий с полной проверкой (доступ возможен). Ответ будет опираться на цепочку логики, а не на быстрое «скорее всего, невозможно» без разбора.
Почему это работает
LLM обучена на огромном количестве задач вида «найди ответ» — там правильная стратегия: предложи вариант, проверь, если не сработало — предложи другой. Эта стратегия зашита как рефлекс, и модель применяет её даже там, где нужна прямо противоположная логика: не искать пример, а исключить все примеры сразу.
Модель хорошо умеет следовать явно расписанной процедуре, если её проговорить по шагам — это сильная сторона рассуждения через текст. Проблема не в том, что модель «не может» доказать невозможность, а в том, что без подсказки она даже не понимает, что задача требует другой процедуры.
Метод обходит это, называя процедуру напрямую: разбей на случаи → выведи следствия → ищи противоречие → не спеши с «решение есть». Это переключает модель из режима «угадай и проверь» в режим «докажи полным перебором», и эффект — резкий скачок точности.
Рычаги управления: - Число случаев для разбора — задай явно («минимум 3 случая»), если модель разбирает слишком грубо. - Порядок «сначала следствия, потом противоречие» — если убрать, модель может искать противоречие вслепую и промахнуться. - Условие для вывода «решение есть» («полная проверка примера») — без него модель по привычке радуется первому похожему варианту.
Шаблон промпта
Мне нужно доказать, что {условие/ограничение} делает {результат} невозможным.
Не ищи сразу один пример и не останавливайся на нём. Действуй по шагам:
1. Разбей ситуацию на все возможные случаи (перечисли варианты, которые нужно проверить).
2. Для каждого случая выведи прямые следствия — что становится обязательным
или запрещённым, если этот случай верен.
3. Найди противоречие в каждом случае — покажи конфликт с условием {условие}.
4. Заяви, что {результат} возможен, ТОЛЬКО если нашёл полностью работающий пример
и проверил его по всем условиям. Если во всех случаях есть противоречие —
заяви, что {результат} невозможен, и покажи, где именно противоречие.
Что подставлять: {условие/ограничение} — правило или ограничение, которое не должно нарушаться (регламент, бюджет, физический лимит). {результат} — то, что проверяется на возможность/невозможность.
🚀 Быстрый старт — вставь в чат:
Вот шаблон для доказательства невозможности. Адаптируй под мою задачу:
{твоя задача — например, "докажи, что бюджет не позволяет запустить проект за 2 месяца"}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит про конкретные ограничения и возможные случаи — потому что без них разбор на случаи и поиск противоречий бессмысленны. Она возьмёт логику шаблона и подставит твои условия.
Ограничения
⚠️ Только для задач «докажи, что невозможно»: Если задача в стиле «найди хоть один вариант», этот промпт избыточен и может усложнить простой ответ.
⚠️ Не гарантия правильности: Метод меняет процедуру рассуждения модели, но не проверяет её математически — если модель ошибётся при выводе следствий, вывод всё равно будет неверным. Для критичных решений (безопасность, юридические выводы) результат нужно проверять отдельно.
⚠️ Эффект слабее на слабых моделях: В исследовании метод сильнее всего сработал на крупной модели (70B параметров); на менее способных моделях улучшение может быть заметно меньше.
Как исследовали
Исследователи взяли пять разных моделей (Qwen3, Llama3, OLMo2) и прогнали их через задачи булевой выполнимости (SAT) — формальные логические задачи с проверяемым решателем ответом, где часть задач решается «найди пример», а часть — «докажи, что примера нет» (UNSAT). Чтобы честно сравнивать модели, для каждой подобрали свой уровень сложности — такой, где модель то угадывает, то ошибается, а не всегда права или всегда неправа.
Дальше они разбили рассуждение модели на предложения и пометили каждое предложение ролью (проверка, откат, финализация и так далее) — вручную заданными правилами, а не через отдельную модель. Сравнивая ошибочные и верные рассуждения на одной и той же задаче, увидели: ошибочные короче, чаще повторяют одни и те же проверки и раньше финализируют ответ — при этом покрывают формулу не хуже верных.
Самое интересное — на задачах «докажи невозможность» модели почти всегда ошибочно заявляли «решение есть», причём эффект не пропадал, даже если убрать из текста все слова про финальный ответ (значит, дело в структуре рассуждения, не просто в формулировке вывода). Тогда исследователи попробовали два вмешательства: просто попросить «попробуй ещё раз внимательнее» — не сработало, и явно расписать процедуру доказательства через случаи — сработало резко, подняв точность с 13% до 85%. Это и есть главный практический вывод: лечится не мотивацией «будь внимательнее», а точным указанием, какую процедуру рассуждения применить.
Адаптации и экстраполяции
💡 Адаптация для бизнес-фидбека: Тот же принцип работает при проверке бизнес-гипотез на нежизнеспособность — например, «докажи, что при таких юнит-экономике и CAC маркетинговый канал никогда не выйдет в плюс».
Докажи, что при цене подписки {X} руб/мес, стоимости привлечения клиента {Y} руб
и оттоке {Z}% в месяц, юнит-экономика никогда не станет положительной.
Разбей на случаи по горизонту удержания клиента (3 мес, 6 мес, 12 мес, бессрочно),
для каждого случая выведи накопленную выручку и сравни со стоимостью привлечения.
Заяви "экономика сходится", только если нашёл конкретный горизонт,
где выручка полностью покрывает затраты — и показал расчёт.
🔧 Техника: добавь запрос «покажи альтернативные пути перед ответом» → снижает риск скороспелого вывода
Исследование показало, что ошибочные рассуждения часто зацикливаются на одной и той же проверке и быстро финализируют ответ. Если добавить в промпт «прежде чем дать финальный ответ, покажи минимум два разных подхода к проверке и сравни их результаты» — это форсирует модель разнообразить рассуждение и снижает риск раннего неверного вывода, особенно на сложных многошаговых задачах.
Ресурсы
The Tell-Tale Trace: Detecting Reasoning Failures in LLMs Using Chain-of-Thought Dynamics — Shashwat Sourav (Washington University in St. Louis), Aishwarya Balwani (St. Jude Children's Research Hospital).