Derived State в памяти агентов: разбивай вопрос на входные состояния, а не ищи ответ целиком

Это не готовая техника, а диагностика плюс три принципа дизайна памяти.

ДИАГНОСТИКА (как нашли слабое место):
ШАГ 1: Вопрос → разложить на цепочку промежуточных состояний (от ответа вниз к записям)
ШАГ 2: Спросить систему про каждое промежуточное состояние отдельно
ШАГ 3: Сравнить: где ответ верный напрямую, но пропал в сложном вопросе → «не собрано» (ungathered)

ТРИ ПРИНЦИПА:
1. СОБИРАЙ входы по цепочке вывода: вопрос → подвопросы про входы → сборка
2. ХРАНИ правила вместе с версиями (как факты)
3. ПОМНИ зависимости: что от чего вычислено → при изменении входа пересчитай зависимое

Для читателя в чате или агенте принцип 1 превращается в промпт: подвопросы, потом сборка (шаблон ниже). Принципы 2 и 3 — это инструкции для файла памяти агента и для разработчиков систем памяти.

• На «парных» вопросах по одной истории Mem0 падает с 86,7 % до 33,3 %, Cognee с 60 % до 16,7 %. Если дать всю историю целиком, та же модель отвечает на 86,7 %. Вопросы решаемы, теряется всё при выдаче памяти.
• Если дать модели верные ответы на подвопросы, она решает все вопросы. Узкое место — получить промежуточные состояния, а не скомбинировать их.
• Пересборка ответа из ответов на подвопросы возвращает до 30 пунктов точности.
• На полном бенчмарке системы памяти отвечают правильно на 30–48 % вопросов. Простой BM25 (поиск по словам) даёт 58 %, вся история целиком — около 80 %, только нужные события — 96 %.
• Неизменённые ответы системы сохраняют хорошо (около 91–93 %). Явные изменения (новая запись прямо меняет факт) обновляют в 82 % случаев. Неявные (изменился вход, а про сам ответ записи нет) — только в 41 %.
• Работа «на входе» (сложное извлечение и сохранение фактов при поступлении) не купила ни точности, ни обновления.

Задача: Вы ведёте продажи в B2B-студии. Агент с памятью читает ваши заметки по сделкам из amoCRM и отвечает на вопросы. Вы спрашиваете: «Каким крупным клиентам, которые ещё в работе, мы не отправили договор?» Ответа в заметках нет. Его нужно собрать из пяти состояний: кто в работе, кто крупный, кому отправлен договор, как менялся порог «крупного», как менялись бюджеты.

Промпт:

Ниже журнал заметок по сделкам. Ответь на вопрос, но не напрямую.

ЖУРНАЛ:
1. 03.03 «Ромашка» — сделка 450 000 ₽.
2. 05.03 «Вектор» — сделка 280 000 ₽.
3. 06.03 «Нева-Строй» — сделка 600 000 ₽.
4. 11.03 Договор отправлен «Ромашке».
5. 14.03 «Нева-Строй» ушла к конкурентам, сделка закрыта как проваленная.
6. 17.03 Правило: крупный клиент — сделка от 500 000 ₽.
7. 20.03 Правило обновлено: крупный клиент — сделка от 400 000 ₽.
8. 21.03 Бюджет «Вектора» вырос до 420 000 ₽.

ВОПРОС: Каким крупным клиентам, которые ещё в работе, не отправлен договор?

Порядок работы:
1. Выпиши, из каких промежуточных состояний собирается ответ.
2. По каждому состоянию отдельно найди записи в журнале и вычисли его значение на сегодня. Учитывай только последнюю версию каждого факта и правила.
3. Для каждого состояния укажи номера записей-источников.
4. Только после этого собери ответ из промежуточных значений.
5. Если какой-то записи не хватает, скажи, чего именно, а не угадывай.

Результат: Модель сначала перечислит промежуточные состояния: клиенты в работе, текущий порог «крупного», текущие суммы, кому отправлен договор. По каждому покажет значение и номера записей. Видно, что старый порог заменён новым. Видно, что запись про рост бюджета меняет состояние «крупный клиент», хотя про это слова нет. Итог собирается в конце. Если ошибка есть, вы увидите на каком состоянии, а не только то, что ответ неверный.

Слабость. Вопрос «крупные клиенты без договора» не похож по словам ни на одну запись, а нужные записи значимы только вместе. Поиск по сходству с вопросом берёт «похожие» записи и пропускает те, что нужны для сборки. Ограничен и бюджет выдачи: нужных записей может быть больше, чем влезет.

Сильная сторона. Модель хорошо отвечает на простые, прямые вопросы («какой сейчас порог крупного клиента?»). И хорошо комбинирует верные части. Это подтверждено: с правильными ответами на подвопросы она решила все вопросы.

Как метод использует это. Разбиение превращает один неудобный вопрос в несколько прямых. Каждый получает собственный поиск и собственные источники. Сборка в конце опирается уже на проверенные части.

Рычаги управления: - Требование номеров записей-источников → можно проверить каждое промежуточное состояние вручную. - Явная фраза «учитывай только последнюю версию правила» → снижает риск взять устаревший порог или условие. - Условие «если не хватает записи, скажи» → отсекает выдуманные ответы там, где история неполная. В статье такие вопросы имеют отдельную метку «неизвестно». - Число подвопросов → для простых вопросов уберите разбиение, для сложных оставьте.

Это перенос в промпт приёма «разбей вопрос на входы и собери заново». В статье этот приём проверен на системах памяти, а не как текстовая инструкция.

Ниже {описание_источника}. Ответь на вопрос, но не напрямую.

{источник}

ВОПРОС: {вопрос}

Порядок работы:
1. Выпиши, из каких промежуточных состояний собирается ответ.
2. По каждому состоянию отдельно найди записи в {источнике} и вычисли значение на {дату_или_момент}. Учитывай только последнюю версию каждого факта и правила.
3. Для каждого состояния укажи номера записей-источников.
4. Только после этого собери ответ из промежуточных значений.
5. Если какой-то записи не хватает, скажи, чего именно, а не угадывай.

Подставьте: {описание_источника} (журнал заметок, переписка, лог задач), {источник} (сам текст), {вопрос} (ваш вопрос), {дата_или_момент} («сегодня», «на 1 апреля»).

🚀 Быстрый старт — вставь в чат:

Вот шаблон «разбей вопрос на входы и собери заново». Адаптируй под мою задачу: [твоя задача].
Задавай вопросы, чтобы заполнить поля.

[вставить шаблон выше]

LLM спросит, в каком формате у тебя история, какой вопрос и на какой момент нужен ответ. Это нужно, чтобы правильно разложить его на промежуточные состояния. Она возьмёт структуру из шаблона и адаптирует под задачу.

Принципы про правила и зависимости можно перенести в инструкции агента, например в файл заметок или CLAUDE.md. Эти формулировки в статье не проверялись:

• «Правила и пороги записывай с датой и номером версии. Старую версию не удаляй, помечай как устаревшую».
• «Для каждого вычисленного итога записывай, из каких фактов он получен. При изменении любого из них пересчитывай итог».
• «Перед ответом по итоговым показателям заново проверь их входы, не доверяй сохранённому итогу».

⚠️ Нет прямой проверки промптом: в статье проверена декомпозиция запроса внутри систем памяти, а готовых текстовых инструкций авторы не тестировали. Шаблон выше — перенос принципа, а не измеренный приём.

⚠️ Основной адресат — разработчики памяти: три принципа (собирать по цепочке, хранить версии правил, помнить зависимости) предполагают доработку самой системы памяти. Читатель, который не пишет код, применит напрямую только часть.

⚠️ Синтетические данные: истории с вымышленными сущностями (города, клиенты, рейсы) и жёсткими правилами. Реальные заметки грязнее, а правила в них часто не записаны.

⚠️ Нужно знать структуру вопроса: разбиение хорошо работает, когда вы понимаете, из чего складывается ответ. Если разложить его неправильно, получите уверенный, но неверный результат.

⚠️ Эффект «до 30 пунктов»: это максимум для лучших систем и вопросов. Выборка парных вопросов небольшая, ответы давала одна модель.

⚠️ Неявные изменения остаются слабым местом: даже с разбиением система не заметит, что рост бюджета «Вектора» поменял статус «крупный», если вы не пересчитываете зависимое состояние.

MemDerive: A Diagnostic Benchmark for Agent Memory over Evolving Data. Авторы: Sen Gao, Han Chen, Bingsheng He (National University of Singapore); Yongan Li, Shixuan Sun (Shanghai Jiao Tong University); Ming Wu, Jason Zeng, Michael Heinrich (Zero Gravity Labs). Бенчмарк: anonymous.4open.science/r/DeriveMem-67C6 Фреймворк оценки: anonymous.4open.science/r/DerivEval-6799 Упомянутые системы и бенчмарки: Mem0, Cognee, LoCoMo, LongMemEval.