TL;DR
StateMem — метод, который заставляет модель хранить каждый факт как отдельную "карточку состояния" с пометкой "актуально" или "заменено" и явными связями между фактами и их производными. Когда исходный факт меняется, модель проходит по этим связям и пересчитывает всё, что от него зависело, а не просто добавляет новую информацию поверх старой.
Проблема, которую метод решает — не в том, что модель "теряет" факт в длинном диалоге. Даже если нужная цифра точно есть в контексте, модель часто цепляется за первое или самое часто повторяемое значение, а не за последнее актуальное. Пример из жизни: в начале переписки договорились про бюджет 500 тысяч рублей, через 20 сообщений подрядчик увеличил его до 800 тысяч — а модель, считая ROI или итоговую смету, продолжает использовать старую цифру, потому что никто явно не сказал ей "пересчитай всё, что зависит от бюджета".
Метод работает в три шага: сначала каждая реплика разбивается на отдельные факты с указанием, от чего каждый зависит; потом при появлении новой информации помечаются устаревшие факты и все, что от них производно; и только потом модель отвечает, обязательно пересчитывая зависимые величины, а не просто беря первое совпадение.
Схема метода
ШАГ 1 (отдельный запрос на каждую реплику): Разбор сообщения на "единицы состояния"
→ факт + источник + от чего зависит + приоритет (жёсткое правило / гибкое)
ШАГ 2 (без LLM, механическая проверка): Если факт изменился —
пометить его как SUPERSEDED, а все связанные с ним факты как NEEDS_RECHECK
ШАГ 3 (отдельный запрос при ответе на вопрос): Собрать только активные факты
и явно пересчитать всё, что помечено NEEDS_RECHECK → финальный ответ
В оригинале шаги 1 и 3 — это отдельные вызовы модели, шаг 2 — механическая проверка без LLM. В обычном чате все три шага можно свести в один диалог, если явно просить модель вести такую таблицу и обновлять её после каждого важного изменения.
Пример применения
Задача: Вы ведёте с ассистентом долгий чат по подготовке питча для инвесторов. За несколько дней переписки менялись ключевые цифры: выручка, юнит-экономика, размер раунда. Нужно, чтобы финальная версия питча считала всё от актуальных данных, а не от черновых цифр из третьего сообщения.
Промпт:
Веди для меня таблицу состояния проекта в таком виде:
АКТИВНЫЕ ФАКТЫ:
- [факт] | источник: [когда/кто сказал] | зависит от: [ничего / других фактов]
УСТАРЕВШИЕ ФАКТЫ (не используй в расчётах, но не удаляй):
- [факт] | заменён на: [новый факт]
ТРЕБУЕТ ПЕРЕСЧЁТА (изменился исходный факт, но производное значение ещё старое):
- [что нужно пересчитать] | из-за изменения: [какой факт изменился]
Каждый раз, когда я сообщаю новую цифру или условие, которое меняет прежнее:
1. Обнови таблицу — перемести старый факт в "устаревшие"
2. Найди всё, что зависело от этого факта, и помести в "требует пересчёта"
3. Прежде чем отвечать на любой мой вопрос — проверь список "требует пересчёта"
и обнови все производные цифры
Вот исходные данные проекта: {данные_проекта}
Результат: Модель будет держать в чате видимую таблицу с тремя блоками. Когда вы сообщите новую цифру (например, изменённую выручку), она пометит старую как устаревшую и явно перечислит, какие расчёты (маржа, ROI, прогноз) нужно обновить, прежде чем дать финальный ответ.
Почему это работает
Модель хорошо запоминает факты, которые есть в контексте, но плохо умеет сама решать, какие из старых расчётов "протухли" после исправления одного исходного числа. Она просто добавляет новую информацию в общий пул, а не аннулирует то, что от неё зависело.
Зато модель хорошо выполняет явные структурированные инструкции — если сказать "если X изменилось, найди всё, что от X зависит, и пересчитай", она это сделает почти механически.
Метод превращает "помни, что что-то изменилось" (то, что модель делает плохо) в "проверь список зависимостей и пересчитай отмеченное" (то, что модель делает хорошо) — за счёт явной структуры, а не надежды на память модели.
Рычаги управления: - Разделение на "жёсткие" и "гибкие" факты → жёсткие (бюджет, дедлайн) требуют строгого пересчёта, гибкие (предпочтения) можно оставить как есть - Частота обновления таблицы → после каждого сообщения (для критичных проектов) или раз в несколько сообщений (для экономии токенов) - Явные связи "зависит от" → чем подробнее вы их прописываете в начале, тем точнее модель поймёт, что пересчитывать
Шаблон промпта
Мы ведём длинный проект: {описание_задачи}.
Условия и цифры могут меняться по ходу переписки.
Веди таблицу состояния в трёх блоках:
1. АКТИВНЫЕ ФАКТЫ — текущие верные данные, с указанием от чего каждый производный факт зависит
2. УСТАРЕВШИЕ — заменённые данные (для истории, не используй в расчётах)
3. ТРЕБУЕТ ПЕРЕСЧЁТА — производные значения, которые нужно обновить из-за изменения исходных данных
Когда я сообщаю новую информацию, которая меняет прежний факт:
- перемести старый факт в "устаревшие"
- найди всё, что от него зависело, и добавь в "требует пересчёта"
- перед ответом на мой вопрос — обязательно обнови всё из этого списка
Начальные данные: {исходные_факты}
🚀 Быстрый старт — вставь в чат:
Вот шаблон StateMem для отслеживания меняющихся условий в проекте.
Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какие факты в вашем проекте могут меняться и что от них зависит — потому что без этой карты зависимостей она не сможет понять, что нужно пересчитывать при каждом обновлении.
Ограничения
⚠️ Не панацея: даже лучшая версия метода в исследовании давала точность около 30-40% на самых сложных сценариях — это существенное улучшение, но не полное решение проблемы.
⚠️ Требует дисциплины: если забыть попросить модель обновить таблицу после важного изменения, эффект пропадает — метод работает только пока вы явно поддерживаете структуру.
⚠️ Зависит от модели: на более слабых моделях метод помогает меньше — если модель путает "часто упоминаемое" с "актуальным" на уровне понимания текста, явная таблица не всегда это компенсирует.
⚠️ Не для коротких диалогов: ценность метода проявляется в долгих проектах с реальными изменениями условий — в коротком чате без пересмотра фактов эта техника избыточна.
Ресурсы
StateMemBench / StateMem, Xinyi Fan, Miri Liu, Ruozhen Yang, Siru Ouyang, Jiawei Han — University of Illinois Urbana-Champaign