TL;DR
State-Update — техника для длинных диалогов, которая заменяет линейное накопление истории на реконструкцию состояния. Вместо "вот весь наш разговор + новая информация" модель получает "вот что было важно + новая информация". На каждом шаге модель выводит все найденные ключевые факты в XML-тегах <info>, а на следующем шаге эти факты явно возвращаются как "Previously selected".
LLM страдают провалами памяти в длинных диалогах. Чем больше сообщений, тем хуже модель помнит начало разговора — это "феномен забывания". Авторы показали: на HotpotQA при разбиении 10 параграфов на 10 сообщений F1 падает на ~10% по сравнению с одним длинным промптом. Хуже того — модели лучше работают с информацией из последних сообщений. Если ключевой факт в первом сообщении диалога — производительность падает на 15-20% по сравнению со случаем, когда тот же факт в последнем сообщении.
State-Update решает через три механизма: (1) State Reconstruction — на каждом шаге контекст содержит только текущую информацию + сжатое состояние (не всю историю), (2) History Reminder — явное поле "Previously selected: {...}" напоминает модели о ранее найденных фактах, (3) XML Output — модель обязана выводить результат в тегах <info> и подставляете в следующий запрос как "Previously selected".
Схема метода
Метод выполняется в несколько запросов с обновлением состояния между ними:
SYSTEM PROMPT (единый для всех шагов):
Инструкции: находить поддерживающие предложения
Формат: выводить в <info>...
Правило: каждый ответ содержит ВСЕ факты (старые + новые)
ШАГ 1 (первый запрос):
USER: Вопрос + первый фрагмент информации
→ LLM выводит ключевые факты в <info>
ШАГ 2-N (последующие запросы):
USER: Вопрос + новый фрагмент + "Previously selected: {факты из шага N-1}"
→ LLM выводит ВСЕ факты (старые + новые) в <info>
МЕЖДУ ШАГАМИ:
Вы парсите <info> из ответа LLM и подставляете содержимое в следующий запросПример применения
Задача: Вы пишете обзор российских криптобирж для клиента и собираете информацию из статей, аналитики, отзывов. Фактов много, они разбросаны. Нужно выделить только релевантное для вопроса: "Какие биржи имеют лучшую репутацию по безопасности хранения средств?"
Промпт — Шаг 1:
SYSTEM: Ты помогаешь фильтровать информацию для исследования.
Твоя задача: найти предложения, которые отвечают на вопрос.
Формат ответа: оборачивай все релевантные предложения в теги <info>....
Правило: каждый ответ должен содержать ВСЕ релевантные предложения (предыдущие + новые).
USER:
Вопрос: Какие криптобиржи имеют лучшую репутацию по безопасности хранения средств?
Контекст (Фрагмент 1):
Garantex — одна из старейших российских бирж, работает с 2019 года. В 2022 году попала под санкции OFAC. Компания использует холодное хранение для 95% средств клиентов и двухфакторную аутентификацию. По данным обзора Forklog, ни одного взлома с похищением средств не зафиксировано за всю историю работы.LLM выведет факты в <info>:
<info>
Garantex использует холодное хранение для 95% средств клиентов и двухфакторную аутентификацию. Ни одного взлома с похищением средств не зафиксировано за всю историю работы.
Промпт — Шаг 2:
USER:
Вопрос: Какие криптобиржи имеют лучшую репутацию по безопасности хранения средств?
Новый контекст (Фрагмент 2):
Bybit запустила российскую локализацию в 2023. Биржа предлагает торговлю с плечом до 100x. В том же году Bybit потеряла $1.4 млрд в результате атаки на кошелёк Ethereum. После инцидента компания ввела страховой фонд и многоуровневую верификацию транзакций.
Previously selected:
Garantex использует холодное хранение для 95% средств клиентов и двухфакторную аутентификацию. Ни одного взлома с похищением средств не зафиксировано за всю историю работы.Результат:
На каждом шаге модель получает новую информацию + явное напоминание о ранее найденных фактах. Она обязана вывести все релевантные факты (старые + новые) в тегах <info>. Вы парсите этот блок и используете его содержимое в поле "Previously selected" следующего запроса. В итоге модель не теряет контекст из ранних сообщений и строит накопительный список фактов, который отвечает на исходный вопрос.
Почему это работает
LLM плохо интегрируют информацию из разных частей длинного контекста. Это усиливается в многоходовых диалогах: модель лучше "видит" последние сообщения (recency bias) и хуже помнит начало. Авторы показали: если ключевой факт в первом сообщении диалога из 10 шагов — производительность падает на 15-20% по сравнению с тем же фактом в последнем сообщении.
LLM отлично работают со структурированными инструкциями и явными напоминаниями. XML-теги убирают двусмысленность вывода — модель точно знает, что выводить и где. Поле "Previously selected" создаёт явную связь между шагами диалога. Вместо неявного "помни что было раньше" модель получает конкретный список: "вот что ты уже нашёл, добавь новое".
State Reconstruction экономит токены и фокусирует внимание. Традиционный подход — копировать всю историю диалога на каждом шаге. Это раздувает контекст и размывает внимание модели. State-Update хранит только сжатое состояние (Previously selected) + текущую информацию. Это даёт 73% экономии времени и 59% экономии токенов при сохранении качества. Модель работает с компактным контекстом, где каждый элемент важен.
Рычаги управления:
- Объём "Previously selected" — если накопилось слишком много, можно пересжать через дополнительный промпт ("сократи до 3 ключевых пунктов")
- Система тегов — замени
<info>на<facts>,<evidence>,<quotes>под свою задачу - Формат накопления — вместо "все старые + новые" можно попросить "топ-5 самых релевантных"
- Критерий релевантности — уточни в system prompt что именно фильтровать (только прямые ответы / косвенные свидетельства / статистику)
Шаблон промпта
System Prompt (единый для всех шагов):
Ты помогаешь фильтровать информацию для исследования.
Твоя задача: находить предложения или факты из контекста, которые отвечают на вопрос.
Формат ответа: оборачивай ВСЕ релевантные факты в теги <info>....
ВАЖНО: каждый твой ответ должен содержать ВСЕ релевантные факты — и те, что были найдены ранее (из "Previously selected"), и новые из текущего контекста.User Prompt — Шаг 1:
Вопрос: {твой_вопрос}
Контекст:
{первый_фрагмент_информации}User Prompt — Шаг 2 и далее:
Вопрос: {твой_вопрос}
Новый контекст:
{следующий_фрагмент_информации}
Previously selected:
{содержимое_тега_info_из_предыдущего_ответа}Что подставлять:
{твой_вопрос}— вопрос, на который собираете информацию{первый_фрагмент_информации}— первый текст для анализа (статья, параграф, отзыв){следующий_фрагмент_информации}— очередной фрагмент для анализа{содержимое_тега_info_из_предыдущего_ответа}— текст из...
Между шагами вручную:
- Получили ответ от LLM
- Скопировали текст между
<info>и</info> - Вставили его в "Previously selected" следующего запроса
🚀 Быстрый старт — вставь в чат:
Вот шаблон State-Update для фильтрации информации в длинном диалоге. Адаптируй под мою задачу: [опиши свою задачу — что исследуешь, какой вопрос, какие фрагменты будешь подавать].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]LLM спросит про вопрос исследования и формат фрагментов — это нужно для настройки критериев релевантности в system prompt. Она возьмёт структуру из шаблона и адаптирует под вашу задачу.
Ограничения
⚠️ Ручной парсинг между шагами: Метод требует извлекать содержимое
<info>после каждого ответа и вставлять в следующий запрос. Это нельзя автоматизировать без кода или API.
⚠️ Не для свободного диалога: Метод заточен под задачи фильтрации и накопления информации (QA, исследования, анализ документов). Для творческих диалогов или brainstorming'а традиционная история работает лучше.
⚠️ Накопление может разрастаться: Если фрагментов много и каждый добавляет факты, поле "Previously selected" раздуется. Нужно либо периодически пересжимать, либо задавать лимит (например, "топ-10 фактов").
⚠️ Зависимость от структурированности вывода: Если модель не следует формату
<info>— парсинг сломается. В бесплатных/лёгких моделях это может быть проблемой.
Как исследовали
Исследователи взяли три бенчмарка для многоходового QA — HotpotQA, 2WikiMultiHopQA, и QASC — и разбили контекст на несколько диалоговых шагов. Например, 10 параграфов разделили на 1, 5 или 10 сообщений. Задача: на каждом шаге модель должна найти поддерживающие предложения для ответа на вопрос.
Сравнивали с baseline — традиционным подходом, где вся история диалога копируется на каждом шаге. Метрики: Word F1 (насколько пересекаются слова с эталоном) и LLM-based Score (Gemini 2.5 Pro оценивает качество фильтрации и итоговый ответ на вопрос).
Ключевая находка: Чем длиннее диалог, тем сильнее деградирует baseline. На 10 шагах F1 падает на ~10-15%. Хуже того — если ключевая информация в первом сообщении, производительность на 15-20% ниже, чем если она в последнем. Это подтверждает recency bias — модели лучше помнят недавние сообщения.
State-Update показал противоположную динамику: производительность почти не падает с ростом числа шагов. На HotpotQA при N=10 улучшение Info Score на 32.6% по сравнению с baseline, что дало 14.1% рост итогового QA Score. При этом время инференса снизилось на 73.1%, а потребление токенов — на 59.4%.
Почему так произошло? Baseline тащит всю историю → контекст раздувается → модель теряет фокус → забывает начало. State-Update хранит только сжатое состояние (Previously selected) → контекст компактный → модель видит все ключевые факты явно → не забывает.
Ablation study подтвердил критичность обоих компонентов:
- Убрали History Reminder (w/o HR) → Info Score упал с 6.91 до 3.74 — катастрофа, модель не интегрирует информацию между шагами
- Убрали State Reconstruction (w/o SR) → эффективность упала до уровня baseline (время 45.2с, токены 6526)
Вывод: HR — это мозг метода (отвечает за производительность), SR — двигатель (отвечает за эффективность). Оба критичны.
Ресурсы
A State-Update Prompting Strategy for Efficient and Robust Multi-turn Dialogue — Ziyi Liu, Beijing University of Posts and Telecommunications, 2025
Исследование проведено с вычислительной поддержкой Hong Kong University of Science and Technology