Жизненный цикл памяти LLM-агента: когда факты нужно забывать

Память LLM-агента научили различать текущие, устаревшие, отозванные и ещё не наступившие факты до того, как они попадут в ответ. В препринте Bilkent University, который не прошёл рецензирование и содержит замеры самих авторов, система FR-Bank прошла 76,9% проверок LifecycleBench против 70,5% у ближайшего конкурента MemoryOS. Для продукта это сдвигает задачу от «найти похожую запись» к «сначала определить, действует ли она сейчас».

Как факт получает срок действия

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

Fortunate Recall добавляет над хранилищем слой правил жизненного цикла. При записи LLM извлекает сам факт, его поведенческую категорию, ключ поля, состояние, время события, время добавления и уверенность. Категория описывает не форму знания, а то, как оно меняется: предпочтения заменяются, хроническое заболевание сохраняется, поручение приближается к сроку, а логистическая деталь истекает после события.

Классифицируют именно факт, а не реплику или сущность. Фраза «я сменил фамилию, пока обновлял страховку» относится к идентичности, хотя в ней упомянут документ. Запись «Alex поймал окуня» относится к хобби, а не к отношениям только потому, что Alex — человек.

Ключ поля связывает конкурирующие версии одного свойства. Уверенное «переехал в Лондон» заменяет прежнее место жительства, а «думаю о переезде в Лондон» сохраняет обе версии. Состояние отдельно помечает активные, заменённые, истёкшие и отозванные записи, поэтому запрос об истории может получить старый факт, а запрос о текущем положении — нет.

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

Метаданные повысили точность, категории сократили выдуманные ответы

На LongMemEval-S FR-Bank набрал 75,2%, то есть правила жизненного цикла не ухудшили результат на обычных задачах долгосрочной памяти. Главный эффект проявился там, где в истории конкурируют несколько версий факта.

По всем запросам доля конфабуляций — ответов, которые опирались на неподходящую память, — снизилась с 32,2% у Mem0 до 13,0% у FR-Bank. При этом система чаще отвечала правильно, а не просто чаще отказывалась от ответа.

Удаление категорий почти не изменило правильность: достаточно было оставить ключ поля, состояние и время события. Но без категорий конфабуляции выросли с 12,0% до 24,2%. Значит, базовое преимущество даёт сама модель жизненного цикла, а категории позволяют отдельно настраивать срок хранения, замену и маршрутизацию для разных фактов.

Работу проверяли на LifecycleBench из 516 вопросов, полном LongMemEval-S из 500 вопросов и независимом BEAM из 280 вопросов. В сравнение вошли Mem0, A-MEM, Memory-R1 и MemoryOS, а порядок результатов дополнительно проверили с генераторами GPT-5.4 и Kimi K2.5. LifecycleBench создали вместе с методом, но перенос результата на BEAM снижает риск того, что система подогнана только под собственный набор заданий.

Планы меняет схема памяти, а не выбор базы

Работа не требует менять векторное хранилище на графовую базу: FR-Bank использует плоское хранилище и накладывает правила поверх найденных кандидатов. Поэтому действующий контур памяти можно развивать по слоям, не переписывая всю инфраструктуру.

• Разделить время записи и время события. Без этого агент не отличит недавно упомянутый прошедший рейс от старой записи о будущем рейсе.
• Хранить явное состояние факта. Замена, истечение срока и отзыв должны менять доступность записи, а не оставаться текстом, который модель попробует истолковать при каждом запросе.
• Связывать конкурирующие версии. Ключ поля позволяет заменить адрес или предпочтение, не подавляя независимые факты о том же человеке.
• Применять типовые правила после базовой схемы. Точная онтология из работы не объявлена оптимальной. Сначала полезно внедрить общие механизмы, затем разделять категории там, где одна настройка даёт слишком много устаревших ответов или преждевременно забывает факты.

Для ассистента, CRM-агента или сервиса с персональной историей это меняет архитектурный план: память становится реестром состояний, а не архивом фрагментов. Для поиска по почти неизменным документам эффект будет меньше, потому что там факты редко заменяют и отзывают друг друга.

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

Источники

• Fortunate Recall: Ontology-Driven Memory Lifecycle Management for Persistent Coherence in LLMs