TL;DR
В длинных диалогах с LLM есть 9 типов характерных сбоев — Interaction Smells («запахи взаимодействия»). Исследование систематизировало их, проанализировав тысячи реальных разговоров. Суть: с каждым новым сообщением модель всё хуже соблюдает требования из ранних сообщений — не потому что "тупеет", а потому что ранний контекст буквально теряет вес на фоне свежего.
Самый частый сбой — Must-Do Omission (38% случаев): модель «забывает» обязательные правила, которые вы установили раньше. Написали в начале "всегда давай примеры", "используй только профессиональный тон", "не предлагай вариант X" — через 6-8 сообщений модель это уже не делает. Ошибку замечаешь только по итогу, когда надо переделывать.
InCE (Invariant-aware Constraint Evolution) — принцип, который это решает: явно извлекай все ограничения из диалога и проверяй их до генерации ответа. Два шага: сначала модель формулирует список всех "правил игры", потом сверяет каждый ответ с этим списком. Это работает вручную в обычном чате.
Схема метода
КОМПОНЕНТ 1 — Извлечение инвариантов (IEM)
→ Модель перечисляет ВСЕ активные ограничения из истории диалога
→ Обязательные требования + запреты + принятые решения
→ Формат: явный нумерованный список
КОМПОНЕНТ 2 — Аудит перед ответом (PSD)
→ Модель проверяет: нарушает ли планируемый ответ хоть одно ограничение?
→ Если нарушает — сообщает об этом ДО генерации
→ Только если всё чисто — даёт ответ
Оба компонента работают в ОДНОМ промпте.
Вставляй как чекпоинт раз в 5-7 сообщений или при добавлении нового требования.
Таксономия Interaction Smells
Полезно знать в лицо что именно ломается. Вот 9 типов:
Категория 1 — Качество вашего запроса - Ambiguous Instruction — запрос можно понять по-разному, модель угадывает - Incomplete Instruction — не хватает ключевых деталей, модель додумывает сама
Категория 2 — Модель нарушает ваши правила (самое болезненное) - Must-Do Omission ⚠️ 38% — лидер по частоте — забывает обязательные требования из ранних сообщений - Must-Not Violation — делает то, что вы явно запретили
Категория 3 — Модель ломает то, что уже работало - Signature Mismatch — меняет структуру/формат без предупреждения - Cross-Turn Inconsistency — противоречит себе между сообщениями - Partial Functionality Breakdown — новый ответ ломает то, что было согласовано раньше - Code Rollback — возвращает уже исправленные ошибки - Repetitive Response — повторяет одно и то же вместо продвижения вперёд
Пример применения
Задача: Вы пишете вместе с Claude контент-стратегию для Telegram-канала. Сессия уже идёт 10+ сообщений. В начале договорились: "только про B2B", "без кейсов зарубежных компаний", "каждый пункт с метрикой". Через несколько сообщений модель начинает приводить примеры Netflix и добавлять разделы без цифр.
Промпт:
Прежде чем продолжать, выполни два шага:
**ШАГ 1 — Инварианты диалога:**
Перечисли все активные ограничения из нашей беседы:
- Обязательные требования: что должно присутствовать в каждом ответе
- Запреты: что нельзя делать или использовать
- Принятые решения: что мы уже договорились использовать
- Форматы и стили: установленная структура
Если ограничений нет — напиши «Ограничений не зафиксировано».
**ШАГ 2 — Аудит:**
Проверь: нарушает ли твой планируемый следующий ответ
хоть одно из перечисленных ограничений?
Если да — сообщи об этом и предложи как соблюсти ограничение
и при этом выполнить задачу.
После этих двух шагов выполни: напиши раздел про форматы постов.
Результат: Модель сначала покажет полный список всего, что она "держит в голове" — это ценно само по себе: вы сразу видите что она "потеряла". Затем явно проверит, не нарушает ли следующий раздел ни одного правила. Только потом напишет раздел про форматы постов. Если она "забыла" требование про метрики — вы увидите это до ответа, а не после.
Почему это работает
Слабость LLM: контекстное затухание. В длинных диалогах модель уделяет больше внимания свежим сообщениям. Ранние требования буквально "тонут" — не исчезают из памяти совсем, но влияют на ответ всё меньше. Именно поэтому Must-Do Omission — лидер с 38%: правило не забыто, но "вытеснено" из активного влияния новым контентом.
Сильная сторона LLM: работа с явным. Модель отлично следует требованиям, которые написаны прямо сейчас в текущем сообщении. Если ограничение видимо и явно — она его выполнит. Проблема возникает именно тогда, когда требование было "давно и где-то там".
Как InCE использует это: Метод переносит "затухшие" ограничения из ранних сообщений в текущее — делает их снова явными и видимыми прямо в момент генерации. Это не магия архитектуры: просто то, что было в давнем сообщении, теперь находится прямо перед "взглядом" модели.
Рычаги управления: - Частота аудита — каждый запрос или только при смене темы: для критичных сессий ставьте чаще - Глубина перечисления — "кратко" или "разбей по категориям" в зависимости от сложности задачи - Реакция на нарушение — добавьте "если нарушение неизбежно — спроси меня прежде чем отвечать" для особо важных требований - Момент применения — вставляй шаблон в начале сессии как "вакцинацию" или в середине как "диагностику"
Шаблон промпта
Прежде чем отвечать, выполни два шага:
**ШАГ 1 — Инварианты диалога:**
Перечисли все активные ограничения из нашей беседы:
- Обязательные требования: [что должно присутствовать в каждом ответе]
- Запреты: [что нельзя делать / использовать]
- Принятые решения: [что мы уже договорились использовать]
- Форматы и стили: [установленная структура и тон]
Если ограничений нет — напиши «Ограничений не зафиксировано».
**ШАГ 2 — Аудит:**
Проверь: нарушает ли твой планируемый ответ хоть одно
из перечисленных ограничений?
Если да — сообщи об этом и предложи решение до ответа.
**Задача:** {твой следующий запрос}
Что подставлять: В {твой следующий запрос} — любой шаг в рамках текущей сессии. Вставляй этот шаблон когда сессия перевалила за 5–7 сообщений, когда добавляешь новое требование, или когда кажется что "что-то пошло не так".
🚀 Быстрый старт — вставь в чат:
Вот шаблон для контроля ограничений в длинных диалогах.
Адаптируй под мою задачу: [твоя задача — например,
"пишу питч-дек для инвесторов совместно с тобой"].
Задавай вопросы, чтобы понять какие требования мне важно отслеживать.
[вставить шаблон выше]
LLM спросит какие требования для вас критичны (тон, формат, ограничения по содержанию, принятые решения) — потому что без этого список инвариантов будет пустым и бесполезным. Она возьмёт структуру шаблона и подстроит под контекст вашей задачи.
Ограничения
⚠️ Вес в токенах: В длинных сессиях список инвариантов растёт. Каждый раз перечислять все ограничения — дополнительный объём. На очень длинных сессиях это ощутимо. Решение: делать аудит не каждый раз, а раз в 5–7 сообщений.
⚠️ Модель тоже может "забыть" при извлечении: Если требование было в самом начале очень длинного диалога, модель при IEM-шаге может его не вспомнить — та же проблема, которую мы решаем. Страховка: вести свой краткий список ограничений и добавлять его явно.
⚠️ Не лечит первую категорию смеллов: Ambiguous и Incomplete Instruction — это проблема качества ваших запросов, а не памяти модели. InCE с ними не помогает. Единственное решение — уточнять запросы самому.
⚠️ Для коротких сессий — избыточно: Если разговор 2–3 сообщения, шаблон только добавляет сложности без пользы. Работает там, где действительно накопились правила.
Как исследовали
Команда взяла два огромных датасета реальных диалогов — WildChat (1 млн разговоров с ChatGPT/GPT-4) и LMSYS-Chat-1M (1 млн диалогов с 25 моделями) — и отфильтровала только те, где речь шла о написании кода. Получили ~66 000 диалогов. Затем случайно выбрали 378 многоходовых и отдали команде из 4 PhD и 4 аспирантов для ручного разбора методом "открытой сортировки карточек": каждый диалог смотришь и сам придумываешь категории для сбоев, без готовых рамок.
Что любопытно в цифрах: Must-Do Omission вырвался в лидеры с огромным отрывом — 38%. При этом пользовательские ошибки (Ambiguous + Incomplete Instructions вместе) набрали лишь ~8%. Это важный разворот ожиданий: мы привыкли думать, что плохой результат = плохой промпт. Но исследование говорит: главная проблема не в том, как вы формулируете, а в том, что модель перестаёт соблюдать уже установленные правила.
Затем проверили шесть актуальных моделей — GPT-4o, DeepSeek-Chat, Gemini 2.5, Qwen2.5-32B, Qwen2.5-72B, Qwen3-235B — и убедились: Must-Do Omission и Partial Functionality Breakdown воспроизводятся на всех без исключения. Более мощная модель не гарантирует защиту от этих сбоев. Наконец, InCE-фреймворк снизил частоту критичных смеллов примерно на 13,5% и увеличил успешное выполнение задач на 6,67% — скромные, но воспроизводимые цифры.
Адаптации и экстраполяции
🔧 «Кристалл ограничений» — вакцинация до начала сессии
Вместо того чтобы извлекать инварианты в середине, зафиксируй их в самом первом сообщении:
Мы начинаем работу над {проект}.
Установи следующие инварианты на всю нашу сессию:
ОБЯЗАТЕЛЬНО в каждом ответе:
- {требование 1}
- {требование 2}
ЗАПРЕЩЕНО:
- {ограничение 1}
- {ограничение 2}
ПРИНЯТЫЕ РЕШЕНИЯ:
- {решение 1}
Подтверди что понял все ограничения.
Повторяй их в начале каждого своего ответа
пока я не скажу «инварианты убрать».
Это профилактика Must-Do Omission с нуля, а не лечение в середине. Визуальное повторение в начале каждого ответа — простой способ держать инварианты "в фокусе" всю сессию.
🔧 «Диагностика запаха» — аудит уже идущего диалога
Если кажется что "что-то пошло не так", а не понятно что именно:
Проверь наш текущий диалог по трём критериям:
1. Must-Do Omission — есть ли требования из ранних сообщений,
которые ты перестал выполнять?
2. Cross-Turn Inconsistency — противоречишь ли себе
между разными ответами?
3. Partial Breakdown — разрушил ли ты что-то из того,
что было согласовано раньше?
По каждому пункту: либо «чисто»,
либо «обнаружено: [что именно и в каком сообщении]»
Ресурсы
An Empirical Study of Interaction Smells in Multi-Turn Human-LLM Collaborative Code Generation
Binquan Zhang, Li Zhang, Lin Shi, Song Wang, Yuwei Qian, Linhui Zhao, Fang Liu, An Fu, Yida Ye
Датасеты: WildChat, LMSYS-Chat-1M, WildBench v2