Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Долгую память разговорного агента можно строить без пересказа каждой беседы через LLM. Авторы Threader сохранили исходные диалоги и получили более точный поиск при меньших расходах, хотя препринт не рецензирован, а все числа получили сами авторы. Для продуктовых команд это повод проверить, не теряет ли текущий конвейер факты ещё до этапа поиска.
Переписывание памяти теряет факты и умножает расходы
Обычная внешняя память агента сначала превращает реплики в краткие записи: извлекает факты, делает сводки или переписывает разговор в заданную структуру. Затем система сохраняет эти записи и подключает их к генерации ответа через поиск по внешним данным — подход RAG.
Такая схема удобна: память можно обновлять отдельно от основной модели, а в запрос передавать только найденные записи. Но полнота будущего ответа зависит от того, что модель решила сохранить во время первичного пересказа. Если она отбросила раннее упоминание, условие или изменение предпочтения, последующий поиск уже не восстановит исходный факт.
Проблема усиливается, когда разговоры становятся длиннее, а темы перемешиваются. В экспериментах Mem0 и MemU создавали меньше записей, удерживали меньше текста и чаще теряли свидетельства, необходимые для ответа. Один и тот же фрагмент при разной группировке беседы мог сохраниться полностью, частично или исчезнуть.
Пересказ требует и повторных обращений к LLM. Для истории объёмом 100 тысяч токенов системы передавали моделям суммарно в 2 раза больше исходного объёма для Mem0, в 9 раз для MemU, в 13 раз для EverMemOS и в 21 раз для A-Mem. Эти токены расходуются до того, как пользователь задаст вопрос к памяти.
Threader оставляет факты в исходной формулировке
Threader не просит LLM составлять долговременные записи. Система хранит исходные реплики и постепенно объединяет соседние сообщения в тематически связные отрезки. Границу определяет небольшой кодировщик BERT: новое сообщение либо продолжает текущую тему, либо начинает следующую.
Такой сегментатор работает по мере поступления сообщений и не перечитывает всю историю после каждой реплики. Для обучения использовали границы сессий из LongMemEval и более подробную разметку смены тем, которую подготовил GPT-4.1-mini.
Каждый отрезок индексируют с нескольких сторон. Отдельные представления описывают сообщения пользователя, ответы ассистента и полный обмен репликами. Это не даёт длинному ответу ассистента заглушить короткий пользовательский факт вроде предпочтения, прошлой покупки или изменившегося требования.
Во время запроса Threader совмещает смысловой поиск, совпадения слов через BM25 и повторное ранжирование кандидатов. Внутри найденных отрезков система отдельно оценивает сообщения, чтобы обнаружить локальный факт, но передаёт генератору весь тематический отрезок. Поэтому модель получает не только подходящую фразу, но и окружающий её контекст в исходном порядке.
Менять архитектуру стоит после проверки на собственных диалогах
Threader проверяли на LongMemEval с 500 вопросами и PersonaMem с 589 вопросами. Средняя сессия в первом наборе занимала около 2 тысяч токенов, во втором — около 26 тысяч. Систему сравнивали с семью решениями для памяти и агентного RAG; работа сообщает о более высокой точности ответов и полноте найденных свидетельств.
На LongMemEval ответы оценивала GPT-4.1-mini, а на PersonaMem применяли точное совпадение с эталоном. Та же GPT-4.1-mini участвовала в подготовке подробных границ тем для сегментатора. В доступном тексте итоговые таблицы сокращены, поэтому по нему нельзя восстановить точный выигрыш Threader для каждой модели и категории вопросов.
Работа меняет планы прежде всего там, где память сейчас строится обязательным пересказом каждой беседы. Практический эксперимент можно ограничить слоем хранения и поиска: оставить исходный журнал, добавить тематическое деление и сравнить, сколько нужных свидетельств доходит до генератора. Основную LLM при этом менять не требуется.
Полностью отказываться от сводок выводы работы не требуют. Они показывают более узкое архитектурное решение: исходный диалог стоит сохранить как основной источник, а сжатые записи не считать единственной копией памяти. Это оставляет возможность повторно проиндексировать историю, изменить правила поиска и проверить ответ по первичным репликам.
Цена такого подхода переносится с предварительного переписывания на хранение исходных сообщений и более сложное извлечение во время запроса. Поэтому проверять нужно не только качество ответа, но и задержку поиска, объём индекса и полноту найденных фактов на реальных историях продукта. Работа даёт конструкцию для такого прототипа, но не универсальный порог, после которого она выгоднее любой памяти на сводках.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
