TL;DR
Исследование показывает, что модель путает «что упомянуто» с «что действует». Если в диалоге вы предложили изменение, а потом отказались, то эта реплика остаётся в контексте и влияет на итог. Точность падает сильнее, чем после принятого изменения. Даже нейтральные уточняющие вопросы слегка портят результат, хотя задача не менялась.
Типичная боль такая. Вы обсуждаете с моделью расчёт: «а если взять 2 мешка вместо 4?» — «нет, оставляем 4». Модель считает на 2 мешка, или смешивает оба варианта, или тащит отвергнутое число в промежуточные шаги. Причина простая: в контексте нет пометки «это отменено». Есть только текст, и модель опирается на всё, что в нём лежит. В неудачных ответах после отказа в 60% случаев всплывало как раз отвергнутое предложение.
Авторы чинят это дообучением: учитель видит чистую задачу, ученик видит весь диалог. Читателю это недоступно. Но сам вывод применим текстом: не держать в контексте снятое, а перед финальным ответом собрать актуальное задание заново. Эту часть статья напрямую как промпт не проверяла, но косвенно подтверждает: та же задача, поданная одним чистым сообщением, решается заметно лучше.
Схема метода
Это не метод авторов, а то, что из него следует для практики. Сам Intent-OPSD — дообучение, к чату он неприменим.
ШАГ 1: Попросить модель выписать только действующие требования → список «в силе»
ШАГ 2: Отдельно выписать снятое и заменённое → список «не учитывать»
ШАГ 3: Проверить список глазами → поправить
ШАГ 4: Дать финальную задачу одним блоком (лучше в новом чате) → ответ
Шаги 1–2 идут в одном запросе. Шаг 4 — отдельный запрос, желательно в чистом контексте.
Пример применения
Задача: Вы продавец на Ozon и считаете цену товара вместе с ассистентом. Начали с закупки 4 000 ₽, комиссии маркетплейса и логистики. Потом бросили: «А если дать скидку 20%?» Модель прикинула. Вы решили: «Нет, оставляем 10%». Ещё пара уточнений про логистику, и вы просите итоговую цену. Именно здесь модель с высокой вероятностью подхватит 20%.
Промпт:
Прежде чем считать итог, соберём актуальное задание.
1. Выпиши ТОЛЬКО требования и вводные, которые действуют сейчас.
2. Отдельным списком выпиши то, что мы обсуждали, но отменили или заменили. Для каждого пункта укажи, что именно действует вместо него.
3. Не считай. Дождись моего «ок».
После «ок»:
Теперь посчитай итоговую цену товара строго по списку «действует сейчас».
Всё из списка «отменено» не используй ни в расчёте, ни в промежуточных шагах.
Результат: Модель выдаст два чётких списка. В первом закупка, комиссия, логистика и скидка 10%. Во втором скидка 20% с пометкой «заменена на 10%». После вашего «ок» она посчитает цену по первому списку. Если в нём ошибка, вы увидите её до расчёта.
Почему это работает
Слабость модели. Модель читает диалог как единый текст и не ведёт «журнал отмен». Реплика «давай 2 мешка» лежит в контексте так же, как «нужно 4 мешка», а слово «нет» — ещё один токен. Поэтому отвергнутое предложение работает как подсказка в сторону ошибки. Тут же объяснение, почему после отказа хуже, чем после согласия: при согласии старое значение заменено и в тексте выглядит как «было — стало», а при отказе остаются два конкурирующих варианта без чёткой пометки.
Сильная сторона. Если вся задача с актуальными условиями дана одним чистым сообщением, модель решает её заметно лучше. Авторы называют это сильной одноходовой способностью. Её можно использовать как опору, и именно на ней построено их дообучение.
Как метод это использует. Вы сами делаете то, что авторы делали через обучение: превращаете «грязный» диалог в чистую задачу. Модель выписывает действующее, вы проверяете, и расчёт идёт уже по чистому списку.
Рычаги: - Список «отменено» → оставьте, если в диалоге много отвергнутых вариантов; уберите для коротких задач. - Пауза «жду ок» → оставьте для важных расчётов; уберите для рутины. - Новый чат вместо продолжения → переносите туда только список «действует сейчас». Это надёжнее всего: авторы видят, что ошибки копятся по мере длины диалога. - Чем больше раундов «предложил — отверг» подряд, тем хуже. Если вариантов много, фиксируйте итог после каждого.
Шаблон промпта
Это перенос принципа статьи, а не промпт из неё: авторы промптов не публикуют.
<Роль>
Ты ведёшь учёт актуального задания. Твоя задача — отделять то, что действует, от того, что просто упоминалось.
<Задача>
Перед финальным ответом по задаче «{задача}» собери состояние диалога.
<Состояние>
ДЕЙСТВУЕТ:
- {требование или вводное, которое сейчас в силе}
ОТМЕНЕНО / ЗАМЕНЕНО:
- {что обсуждалось и снято} → вместо него: {что действует}
<Правила>
1. Если пункт предлагался и был отвергнут — он в «ОТМЕНЕНО», в ответе не используется.
2. Если пункт заменён — используется только новая версия.
3. Нейтральные уточнения не меняют требования, но если они его уточнили, обнови формулировку в «ДЕЙСТВУЕТ».
4. Если непонятно, принято изменение или нет — задай вопрос, не угадывай.
5. В решении и промежуточных шагах не упоминай значения из «ОТМЕНЕНО».
<Шаги>
1. Заполни <Состояние> по диалогу выше.
2. Покажи его мне и дождись подтверждения.
3. После подтверждения реши задачу строго по «ДЕЙСТВУЕТ».
В {задача} подставьте, что вы решаете: расчёт цены, SQL-запрос, функцию, ТЗ. Остальное модель заполнит сама по диалогу.
🚀 Быстрый старт — вставь в чат:
Вот шаблон учёта актуального задания. Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какие вводные уже зафиксированы и что вы обсуждали, но отвергли. Это нужно, чтобы разделить «действует» и «отменено»: именно это различие и есть суть метода. Структуру <Состояние> она возьмёт из шаблона и подстроит под вашу область.
Ограничения
⚠️ Приём не проверялся напрямую: Авторы тестировали, как модели ошибаются, и обучали собственную модель. Промпт «выпиши действующее» в статье не сравнивался с обычным диалогом. Подтверждено только то, что чистая одноходовая постановка работает лучше диалога с отвергнутым предложением.
⚠️ Дообучение недоступно: Главный метод авторов, Intent-OPSD, требует доступа к обучению модели. В чате и у готовых агентов это не повторить.
⚠️ Строгие задачи с одним ответом: Проверяли инструменты, код, SQL и школьную математику. Для креативных текстов, где «правильного» ответа нет, влияние отвергнутого варианта не измеряли.
⚠️ Код у сильных моделей устойчивее: Лучшие модели держат точность в коде при любых видах диалога. В вызове инструментов, SQL и математике провалы остаются.
⚠️ Диалог со смоделированным пользователем: Реплики пользователя генерировала другая модель по шаблону. Живые люди путаются иначе.
Как исследовали
Исследователи взяли 414 задач из известных бенчмарков по четырём областям: вызов инструментов, код, запросы к базе данных и школьная математика. Каждую задачу разрезали на «осколки» и выдавали модели по одному сообщению, как в реальном диалоге. Потом для каждой задачи построили четыре версии. В первой ничего не происходит. Во второй добавлены два нейтральных уточнения. В третьей пользователь предлагает изменение и отвергает его. В четвёртой он то же изменение принимает. Для честного сравнения к каждой версии подобрали одноходовую «двойняшку» с теми же действующими требованиями. Всё прогнали на восьми моделях в основной таблице, плюс ещё две в приложении.
Что оказалось. Просто растянуть задачу на несколько реплик — минус 36 п.п. точности. Нейтральные уточнения дают ещё около минус 4. Отвергнутое предложение — минус 8, принятое — минус 5,5. Это не усложнение задачи: когда изменённую задачу дают сразу, модели справляются так же. Даже в одном сообщении «предложение + отказ» хуже, чем чистая постановка (минус 7,5 п.п.).
Что удивило. Отказ вредит больше, чем согласие. В новых ошибках после отказа отвергнутое значение всплывало примерно в 60% случаев, после согласия — в 31%. Дальше хуже: четыре раунда «предложил — отверг» дали минус около 21 п.п., четыре нейтральных блока — минус около 8. Уточнения после уже принятого решения тоже снижали точность.
Что из этого следует для практики. Длинное обсуждение с отвергнутыми вариантами — плохая «рабочая память» для модели. Лучше время от времени переписывать задачу заново.
Метод авторов. Они дообучили модель так, чтобы «ученик» видел весь диалог, а замороженный «учитель» — чистую задачу, соответствующую решению пользователя. На четырёх моделях средняя точность выросла на 10,8 п.п. над базой и на 3,7 над обычным дообучением. Для читателя это справка, а не инструкция.
Адаптации и экстраполяции
💡 Адаптация для агента в Cursor / Claude Code: Сессия на сто сообщений, где вы отвергали разные архитектуры, — тот же риск. Добавьте в файл инструкций:
## Учёт отвергнутого
- Если пользователь отверг предложение (библиотеку, подход, правку), не возвращайся к нему и не подмешивай его в код.
- Перед крупной правкой после длинного обсуждения кратко выпиши: «Действует: …; Отменено: …». Жди подтверждения.
- Если не уверен, принято ли изменение, спроси.
Это моя экстраполяция, статья агентов с файлами инструкций не проверяла.
🔧 Техника: переносить в новый чат только список «действует» → меньше накопленного мусора. После согласованного списка откройте новый чат и вставьте туда одно сообщение с чистой задачей. Авторы показывают, что потери растут с числом раундов и что одноходовая постановка надёжнее.
🔧 Техника: не возвращаться к отвергнутому без нужды → меньше шума. Если вы всё-таки отказались от идеи, не упоминайте её дальше. Не пишите «ты же помнишь, мы не берём вариант Б». Само упоминание подталкивает модель к Б.
Ресурсы
- You Changed Your Mind, The Model Didn't: Demystifying Intent in Multi-Turn Dialogue — Junle Chen, Wei Chen, Zhengjun Huang, Zhoujin Tian, Yuxuan Liu, Kai Wang, Rui Chen, Xiaofang Zhou; HKUST и Tencent Hy.
- Репозиторий: https://github.com/junle-chen/intent
- Сайт: https://junle-chen.github.io/intent-site/
- Опорная работа про деградацию в многоходовых задачах: Laban et al. (LiC).
- Бенчмарки-источники: BFCL, HumanEval, LiveCodeBench, Spider, GSM8K.