Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Накопленную память долгоживущего LLM-агента научились сохранять при замене основной модели. В препринте Fudan University, Qwen Applications Business Group и Alibaba Group, который не проходил рецензирование и содержит замеры самих авторов, RPMem достигла 85,52% точности на PERMA. Подход позволяет обновлять модель в работающем продукте, не собирая память каждого пользователя заново.
Как память отделили от основной модели
Текстовая память агента обычно хранит диалоги, сводки или отдельные факты во внешней базе. Перед каждым ответом система ищет подходящие записи и добавляет их в контекст LLM. По мере роста истории результат всё сильнее зависит от поиска: пропущенный факт уже не попадёт в рассуждение, а слишком широкий контекст увеличит нагрузку и не гарантирует, что модель воспользуется нужной информацией.
Параметрическая память работает иначе. Она превращает прошлый опыт в изменения вычислений модели, поэтому агенту не нужно подставлять исторический текст в каждый запрос. Прежние реализации обычно привязывали такое состояние к архитектуре конкретной LLM: после её замены накопленный опыт нельзя было использовать напрямую.
RPMem разделяет представление опыта и способ подключения к модели. Сначала замороженный кодировщик обрабатывает очередную сессию, а модуль на основе Perceiver сжимает её в состояние фиксированной формы. Длина сессии на размер этого состояния не влияет.
Отдельный декодер превращает состояние в низкоранговые адаптеры LoRA для выбранной LLM. Его обучают воспроизводить распределение следующих токенов, которое основная модель выдаёт, когда видит исходную сессию в контексте. Сама LLM и кодировщик при этом остаются замороженными.
Новые сессии объединяет рекуррентный шлюз. Для каждой части состояния он выбирает, сколько сохранить из накопленной памяти и сколько взять из свежей сессии. Шлюз обучают на целевой задаче приложения, а после развёртывания обновление проходит только прямым вычислением, без дополнительного обучения и повторного чтения старой истории.
При смене основной LLM состояние памяти и шлюз остаются прежними. Команде нужен новый декодер, который переведёт это состояние в LoRA-параметры другой модели. Так RPMem отделяет жизненный цикл пользовательской памяти от жизненного цикла обслуживающей LLM.
Где фиксированная память выиграла у контекста и поиска
Подход проверяли на трёх наборах задач долгосрочной памяти и пяти основных моделях разных семейств и архитектур. В сравнение вошли полный контекст, поиск по истории, сводки, внешние текстовые хранилища, обычное дообучение и Metis-9B с параметрической памятью.
На PERMA RPMem обошла Metis-9B на 5,32 процентного пункта, а полный контекст — на 12,98 пункта. Этот набор проверяет, может ли агент формировать, пересматривать и сохранять состояние пользователя между последовательными сессиями, в том числе когда новые события меняют старые сведения.
На PersonaMem-v2 RPMem также показала лучший совокупный результат среди сравниваемых методов. Задача строит независимые запросы по длинной пользовательской истории, поэтому здесь недостаточно запомнить последнюю реплику: нужно удерживать актуальные сведения после серии обновлений.
На PrefEval преимущество проявилось при интервале в 300 реплик между сообщением о предпочтении и вопросом. На короткой истории текстовая LightMem работала лучше, но с ростом интервала её точность снижалась, тогда как результат RPMem рос. Это соответствует назначению метода: фиксированное состояние не зависит от того, насколько далеко нужный факт отстоит от запроса.
Масштаб экспериментов задаёт границы вывода. Проверки охватывают память о состоянии, пользовательских характеристиках и предпочтениях; перенос между моделями оценивали внутри подготовленной архитектуры RPMem. Шлюз обучали отдельно под каждый сценарий, поэтому работа не показывает, что одна политика объединения памяти одинаково подходит приложениям с другими требованиями.
Когда RPMem меняет архитектурный план продукта
Подход стоит учитывать, если агент живёт дольше одной сессии, обслуживает отдельное состояние для каждого пользователя и должен переживать регулярную смену LLM. В такой системе текстовая история со временем увеличивает стоимость поиска и объём контекста, а адаптер, жёстко связанный с одной моделью, усложняет миграцию.
RPMem предлагает другой контракт: история поступает последовательно, состояние сохраняет фиксированный размер, а стоимость очередного обновления почти не растёт вместе с числом прошедших сессий. При переходе на новую LLM не нужно повторно кодировать все пользовательские диалоги — достаточно подготовить совместимый декодер.
Это не готовая универсальная память, которую можно подключить к любому агенту без обучения. Сначала требуется обучить компилятор сессий, затем настроить шлюз на данных целевой задачи, а для каждой новой основной модели подготовить свой декодер. Экономия возникает позже, во время длительной эксплуатации и миграций, а не на этапе первого запуска.
Текстовая память также сохраняет практическое преимущество: её записи можно просмотреть отдельно от LLM. RPMem хранит опыт в скрытом состоянии и подаёт его через параметры модели. Поэтому работа меняет план прежде всего для агентов, где важны длина истории, постоянная персонализация и замена LLM, а не только простота проверки сохранённых записей.
Главный архитектурный вывод — память агента необязательно должна принадлежать модели, которая сейчас отвечает пользователю. Её можно сделать отдельным долговечным слоем, но за переносимость придётся заплатить обучением шлюза под задачу и декодера под каждую LLM.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
