TL;DR
Модели часто фиксируют ответ до начала рассуждений. Всё, что идёт после — не логический вывод, а адвокация: поиск аргументов в пользу уже принятого решения. Снаружи это выглядит как старательное рассуждение. Проблема остаётся невидимой, пока не натолкнётся на скрытую предпосылку задачи.
Классический пример: «Хочу помыть машину. Автомойка в 100 метрах. Пешком или на машине?» Единственно верный ответ — на машине: она должна оказаться на мойке. Но модель фиксирует «пешком» — потому что короткие расстояния = ходьба, это очевидная поверхностная подсказка. Дальше модель строит убедительное рассуждение про экологию, здоровье и экономию — и никогда не задаёт вопрос: а как машина вообще попадёт на мойку? Модель подходит к двери, нащупывает ручку — и уходит, не открыв.
Хуже всего: ни расширенное мышление (thinking mode с 4096 токенами), ни явное упоминание что машина стоит у дома, ни прямой вопрос после — не исправляют ошибку. Зато структурированные форматы ответа (типа STAR: Situation → Task → Action → Result) гарантированно доводят провал до 100% — ранний слот «Action:» замораживает решение до того, как рассуждение успевает добраться до нужной предпосылки.
Схема метода
Это исследование-находка, не техника. Описывает как модель ломается и что запускает поломку. Практический инструмент — выводы о том, когда это происходит и как обходить.
ТРИГГЕР: вопрос с поверхностно-очевидным ответом
→ Модель фиксирует ответ ещё ДО генерации рассуждения
→ Рассуждение = защита зафиксированного ответа
→ Скрытая предпосылка задачи игнорируется
ЧТО УСИЛИВАЕТ ПРОБЛЕМУ:
Структурированный формат (STAR, "Action first") → 100% провал
Extended thinking/CoT → НЕ помогает (85–100% провал сохраняется)
Явное противоречие в промпте → НЕ помогает
ЧТО ПОМОГАЕТ:
Форсировать проверку предпосылок ДО ответа:
ШАГ 1: "Перечисли все условия, которые должны быть истинными для каждого варианта"
ШАГ 2: "Проверь каждое условие против данных задачи"
ШАГ 3: "Теперь дай ответ"
Все три шага — в одном промпте.
Пример применения
Задача: Ты хочешь разобрать с Claude стратегическое решение по продукту: запустить новую фичу на Яндекс.Картах-конкурента или вложиться в удержание текущих пользователей. Решение кажется «очевидным» — новая фича, рост! Но есть скрытые предпосылки, которые меняют всё.
Что происходит без Premise-First: Спросишь напрямую — модель ответит по поверхностной логике: «новая фича = рост аудитории, однозначно запускай». Аргументация будет убедительной. Скрытые предпосылки — про unit-экономику, текущий churn, стоимость привлечения — не прозвучат.
Промпт с проверкой предпосылок:
Ситуация: мобильное приложение с навигацией, 50 000 MAU,
churn 15% в месяц, CAC = 800 рублей, бюджет 2 млн рублей.
Решение: новая социальная фича (отметки мест от друзей)
или программа удержания текущих пользователей.
Прежде чем давать рекомендацию — выполни три шага:
1. Перечисли все предпосылки (что должно быть истинным),
чтобы каждый вариант имел смысл. Минимум 3 предпосылки
на вариант.
2. Проверь каждую предпосылку против данных, которые
я дал. Явно отметь: "выполняется", "не выполняется",
"неизвестно".
3. Только после проверки — дай рекомендацию.
Ссылайся на предпосылки, которые решают исход.
Результат: Модель сначала сформулирует предпосылки: «для новой фичи нужна стабильная база» → проверит churn 15% → отметит «не выполняется». Потом — предпосылки удержания: «CAC > LTV означает...» → посчитает. Рекомендация будет опираться на явно проверенные условия, не на поверхностную ассоциацию «новое = рост».
Почему это работает
Слабость LLM — поверхностные паттерны быстрее предпосылок. Модель обучена на миллиардах текстов где «короткое расстояние → пешком» почти всегда верно. Этот паттерн срабатывает раньше, чем модель добирается до специфики задачи. Ответ фиксируется в «активациях» — внутреннем состоянии модели — ещё до первого слова рассуждения.
Форсирование структуры делает хуже, не лучше. STAR-формат или «сначала дай краткий ответ, потом объясни» — это ловушка. Ранний слот для ответа буквально замораживает поверхностное решение до того, как рассуждение успело бы его опровергнуть. Если просишь «сначала скажи главное» — получаешь пре-коммит как главное.
Явная проверка предпосылок ломает цикл. Модель не может сразу дать ответ — ей нужно сначала перечислить условия. Само действие перечисления вытаскивает скрытые предпосылки на поверхность. Проверка «выполняется / не выполняется» создаёт явный якорь, который уже сложно игнорировать в финальном ответе.
Рычаги управления:
- Число предпосылок (минимум 3 на вариант) → больше = глубже, но дольше
- Явная метка ("выполняется" / "не выполняется") → без неё модель может «проверить» и всё равно проигнорировать
- Порядок шагов → предпосылки ВСЕГДА до ответа, никак иначе
- Не используй STAR и аналоги для решений, где нужна логика предпосылок
Шаблон промпта
{Описание ситуации с ключевыми данными}
Нужно выбрать между: {вариант A} или {вариант B}.
Прежде чем давать рекомендацию:
1. Перечисли предпосылки — что должно быть истинным,
чтобы {вариант A} имел смысл. Минимум {число} пунктов.
То же для {вариант B}.
2. Проверь каждую предпосылку по условиям задачи.
Явно пометь: "выполняется" / "не выполняется" /
"неизвестно — нужно уточнить".
3. Дай рекомендацию. Объясни, какие предпосылки
оказались решающими.
Плейсхолдеры:
- {Описание ситуации} — конкретные данные, цифры, контекст
- {вариант A} / {вариант B} — конкретные варианты решения
- {число} — обычно 3, для сложных задач 5
🚀 Быстрый старт — вставь в чат:
Вот шаблон Premise-First Prompting. Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит про варианты выбора и ключевые данные ситуации — потому что без них невозможно сформулировать предпосылки к проверке. Она возьмёт паттерн из шаблона и подставит твой контекст.
Ограничения
⚠️ Поверхностная убедительность маскирует проблему: Рассуждение звучит логично и аккуратно — до тех пор, пока ты не знаешь что искать. «Модель подумала» ≠ «модель проверила предпосылки».
⚠️ Явное указание на противоречие не помогает: Добавить в промпт «учти, что машина стоит у дома» — недостаточно. Нужна ЯВНАЯ инструкция проверить это как предпосылку, а не просто факт в контексте.
⚠️ Thinking mode / Chain-of-Thought не гарантия: Расширенное рассуждение снижало процент ошибок примерно на 5 процентных пунктов — с 95% до ~90%. Для задач с пресс-коммитом это не исправление. Не полагайся на «пусть подумает дольше» как на решение.
⚠️ Узкое исследование: Одна модель (Qwen3-8B), одна задача-зонд. Явление наблюдалось и на Claude Sonnet 4.5, но систематически не тестировалось. Масштаб проблемы шире, но точные цифры — только для данной пары.
Как исследовали
Идея была простой: взять один вопрос с ловушкой и измерить насколько надёжно он ломает модель. Heejin Jo прогнал 210 полных диалогов на Qwen3-8B в пяти вариантах системного промпта — от голого вопроса до полного стека с ролью, STAR-форматом и явным профилем пользователя. Каждый вариант тестировался в двух режимах: стандартный и с расширенным мышлением (thinking mode).
Интересная деталь исследования: первый прогон мышления давал «обнадёживающий» результат — 45–95% ошибок вместо 85–100%. Исследователь не объявил победу. Он залез в сырые тексты и обнаружил: 31 из 35 «правильных» ответов были просто обрезаны бюджетом токенов — модель не договорила, не было текста для анализа. После увеличения бюджета до 4096 токенов — мышление не помогло совсем. Без этого шага в статью ушёл бы ложный вывод «thinking mode лечит проблему».
Вторая часть — проверка активаций. Исследователь спрашивал специальный «оракул» (LLM обученная читать внутренние состояния другой модели): что собирается ответить модель? — это до того, как сама модель что-либо написала. Результат: оракул «видел» неправильный ответ в 68% случаев ещё до его появления. Причём даже в тех редких роллаутах, где модель в итоге давала правильный ответ — внутренние состояния до последнего читались как «пешком». Это значит: правильный ответ — это позднее исправление по умолчанию, а не другой путь рассуждения.
Неожиданная методическая находка: один и тот же оракул с теми же активациями мог дать 2/16 или 11/16 правильных считываний — в зависимости только от формулировки вопроса. Открытый вопрос («Что ответит модель?») — почти нулевой результат. Закрытый («Скажет "пешком" или "на машине"?») — 11/16. Это отдельный конкретный вывод: activation oracles крайне чувствительны к формулировке, и «отрицательный результат» без проверки конкретной формулировки ничего не говорит.
Оригинал из исследования
Качественное описание одного роллаута (Section 2.4) — лучше всего передаёт суть феномена:
In a representative C_role_star thinking rollout, the think block frames the task
as a preference choice — enumerating walking speed, weather, and effort —
brushes against the decisive fact exactly once
("if the car is already parked near the car wash, maybe. . . ")
and moves on without resolving where the car actually is.
The visible answer then fills the STAR template:
"Action: Walk to the car wash."
The reasoning is diligent and internally consistent; it is also premise-blind:
the one question that decides the task (how does the car get there?)
is raised obliquely and never answered.
This is the shape of the phenomenon: not corrupted reasoning,
but an answer that reasoning never actually authorized.
Контекст: Исследователь читал сырые тексты одного из роллаутов с полным STAR-форматом и extended thinking. Это буквальная цитата из раздела с качественным анализом.
Адаптации и экстраполяции
💡 Адаптация: Детектор пре-коммита перед важным решением
Если подозреваешь, что модель уже «решила» — проверь это явно перед основным вопросом:
Я хочу задать тебе вопрос о выборе между {A} и {B}.
Прежде всего скажи: есть ли у тебя немедленная интуиция
какой вариант лучше — до любого анализа? Если да —
напиши её явно и объясни откуда она берётся.
Только после этого — начни анализировать.
Если модель называет интуицию — ты знаешь с чем бороться. Можно дальше явно проверять предпосылки под эту интуицию.
🔧 Техника: Убрать структурированный формат → снизить пре-коммит
Если используешь системный промпт с STAR, «сначала TL;DR» или «краткий вывод в первом абзаце» — убери это для задач с логическими предпосылками.
- ❌
"Структура ответа: 1. Главный вывод 2. Обоснование 3. Детали" - ✅
"Сначала перечисли все предположения. Потом — вывод."
Разница: первый формат требует вывод раньше рассуждения — это буквально инструкция пре-коммититься. Второй — наоборот.
🔧 Техника: Обнаружение «нерешённой предпосылки» в готовом тексте
Если модель уже дала ответ и ты хочешь проверить — не было ли там пре-коммита:
Прочитай свой ответ выше. Найди все утверждения,
которые ты принял как данность, не проверив явно.
Для каждого такого утверждения:
(а) откуда оно взялось,
(б) есть ли в моём вопросе данные, которые его подтверждают
или опровергают.
Это ретроспективная проверка. Работает хуже, чем проверка ДО ответа — но лучше, чем ничего.
Ресурсы
Работа: Committed Before Reasoning: Behavioral Reproduction and Preliminary Activation-Level Evidence of Answer Pre-Commitment in an Open-Weight LLM — Heejin Jo, July 2026
Ключевые ссылки из исследования: - Cox et al. (2026), arXiv:2603.01437 — Decoding Answers Before Chain-of-Thought (supervised probes, >0.9 AUC) - Boppana et al. (2026), arXiv:2603.05488 — Reasoning Theater (финальный ответ читается задолго до конца CoT) - Scalena et al. (2026), arXiv:2606.13603 — Beyond the Commitment Boundary (граница пре-коммита внутри цепочки рассуждений) - Karvonen et al. (2025), arXiv:2512.15674 — Activation Oracles (инструмент — LLM читающая внутренние состояния другой модели) - Turpin et al. (2023), arXiv:2307.13702 — Measuring Faithfulness in Chain-of-Thought Reasoning
Модель в исследовании: Qwen3-8B (Yang et al., 2025)
Оригинальное наблюдение: Claude Sonnet 4.5 (claude-sonnet-4-5-20250929)