Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Память LLM-агента научили различать, что участники обсуждали раньше и какая версия договорённости действует сейчас. В препринте Alibaba Cloud, который не прошёл рецензирование и приводит замеры самих авторов, EGMemory обошла все проверенные системы памяти на двух тестах многосторонних диалогов. Для продуктовой архитектуры это аргумент не в пользу очередного векторного хранилища, а в пользу отдельного слоя состояния с историей изменений.
Плоский список реплик не показывает, что действует сейчас
Обычный поиск по памяти отвечает на вопрос, какие сообщения похожи на запрос. Этого недостаточно, если несколько участников обсуждали одну тему в разных ветках, а поздняя реплика отменила прежнее решение.
EGMemory разделяет память на исходные сообщения и активное состояние. Сообщения остаются неизменными и хранят текст, автора, время, тему и контекст разговора. Активное состояние указывает, какая запись сейчас задаёт действующее значение.
Из этих связей получается доступная для поиска машина состояний: набор текущих значений, их прежних версий и переходов между ними. При изменении договорённости система не перезаписывает старую запись, а связывает новую с той, которую она заменила. Поэтому запрос о текущем решении ведёт к активной версии, а запрос об истории решения — к цепочке предыдущих сообщений.
Такое разделение решает проблему происхождения факта. Модель может не только вернуть ответ, но и найти реплику, на основании которой состояние изменилось. Старые сведения при этом не смешиваются с действующими и не исчезают из памяти.
Как система предлагает, проверяет и фиксирует изменение
При записи нового сообщения EGMemory сначала ищет связанное состояние. Поиск может пройти несколько раундов: результат предыдущего запроса помогает уточнить следующий. Это нужно для коротких реплик вроде «оставим второй вариант», смысл которых зависит от участников, ветки и предыдущих решений.
Затем модель предлагает структурированное изменение: определяет тему, связь с прежним состоянием и новое значение. Это предложение ещё не получает права менять память. Отдельный проверяющий этап сопоставляет значение с исходной репликой и убеждается, что заявленная предыдущая версия действительно существует.
Проверка детерминирована и опирается на совпадения в тексте. Она ограничивает полномочия LLM: модель интерпретирует сообщение, но не может самостоятельно объявить свою интерпретацию действующим фактом. После проверки система фиксирует запись и, если нужно, переводит активное состояние на новую версию.
При чтении EGMemory также не ограничивается единственным поисковым запросом. Сначала она находит наиболее близкие сообщения по словам и смыслу, затем сужает область по темам, участникам, ответам и связям между версиями. Структура диалога определяет, где искать, а содержание — какие записи считать подходящими.
Ответ строится по накопленным свидетельствам, а не по одному фрагменту с максимальной близостью. В эксперименте запрет повторных обращений к памяти снизил точность на 7,9 процентного пункта — это оказался самый заметный результат среди проверок отдельных компонентов.
Когда эту схему стоит закладывать в продукт
На GroupMemBench EGMemory получила 68,2% правильных ответов и опередила лучший проверенный вариант на 22,7 процентного пункта. На EverMemBench результат составил 77,9%, а разрыв с сильнейшей базовой системой — 21,4 процентного пункта. Особенно хорошо схема справлялась с вопросами, где нужно собрать сведения из нескольких реплик, учесть время или проследить обновление знания.
Проверка охватывала GroupMemBench и EverMemBench с многосторонними разговорами, а также LoCoMo с диалогами двух участников. Для построения памяти и ответов использовали qwen3.7-max, ответы оценивала Kimi-K3; все наборы были англоязычными. Сравниваемые системы работали с одинаковыми моделями ответа и оценки, но выводы пока привязаны к одной семье моделей и контролируемой атрибуции реплик.
Командам, которые хранят изменяемые решения нескольких участников, имеет смысл заложить три отдельных механизма: неизменяемый журнал сообщений, версионируемое активное состояние и проверку переходов перед записью. Для этого не требуется отдельно обучать политику управления памятью: EGMemory работает через подсказки и вызовы инструментов.
Переносить схему целиком рано, если ключевые ограничения продукта — задержка и стоимость запросов. Повторный поиск при записи и чтении требует больше обращений к модели, а эксперимент не сравнивает расход токенов и время ответа. Проверка по текстовым совпадениям также может отклонить сильный пересказ или пропустить формально похожее, но неверное изменение.
Практический вывод уже применим на уровне архитектуры: долгую память для меняющихся диалогов стоит проектировать как журнал доказательств и отдельное текущее состояние, а не как коллекцию независимых кратких пересказов. Результаты EGMemory показывают, что на многосторонних разговорах этот выбор влияет сильнее, чем замена одного однопроходного поиска другим.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
