Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Mnemon даёт LLM-агенту доступ к долгой истории без предварительного пересказа разговоров в факты или графы. В препринте Guangren Wang, который не проходил рецензирование и приводит числа, полученные самим автором, система набрала 91,7% на LoCoMo — наборе вопросов по длинным разговорам. Для продуктовой команды это означает, что память можно добавить поверх журнала сообщений, не закрепляя заранее схему фактов и предпочтений.
Исходные записи остаются единственным доказательством
Большинство систем памяти обрабатывает сообщение при записи: извлекает факты, обновляет профиль пользователя или строит граф связей. Такое представление ускоряет последующий доступ, но заранее решает, какая часть сообщения пригодится в будущем. Потерянную деталь уже нельзя вернуть, когда появится вопрос, для которого она важна.
Mnemon вместо этого хранит короткие датированные фрагменты разговора в исходном виде. На пути записи система вычисляет только векторное представление для семантического поиска. Поэтому новый тип данных не требует отдельной схемы извлечения: достаточно хранилища, которое умеет искать и возвращать датированные записи.
При запросе LLM составляет несколько поисковых формулировок и определяет, какие сведения нужны для ответа. Система объединяет обычный поиск по словам с поиском по смысловой близости, собирает до 48 записей-кандидатов и передаёт их модели Jev. Та решает, нужна ли каждая запись, не устарела ли она и какую потребность закрывает.
В итоговый контекст отвечающей модели попадает компактная выборка — не более 16 записей. Саму отвечающую модель менять не требуется: Mnemon работает как отдельный агент памяти и перед каждым ответом публикует для неё отобранную часть истории.
Часть сведений трудно найти прямым запросом: например, однажды данную инструкцию, все упоминания проекта или последовательность сменившихся значений. Для них фоновая задача один раз проходит по журналу и строит тематические линии, истории значений и постоянные инструкции. Эти элементы служат указателями, но каждый из них сохраняет ссылку на исходную запись.
Быстрая модель отбирает, LLM планирует и отвечает
Архитектура разделяет два вида работы. LLM выполняет задачи, где нужно сформулировать запрос, связать несколько фактов или написать ответ. Jev получает узкие вопросы с ответом «да» или «нет» и параллельно оценивает много записей: относится ли фрагмент к запросу, отменяет ли более позднее сообщение старое и достаточно ли найденных сведений.
На LongMemEval-S, другом наборе вопросов по истории разговоров, Mnemon набрал 83,8%. В обоих основных тестах отвечающая модель получала менее 4 тысяч токенов контекста на вопрос. Это отличает систему от подходов, которые повышают точность за счёт передачи большой части истории в дорогой контекст.
На истории от короткого до многомиллионного масштаба расходы на один вопрос выросли лишь в 1,11 раза. Поиск при этом замедлялся, но объём работы LLM и Jev оставался ограничен фиксированными бюджетами: вся история не перечитывалась.
На одинаковых записях Jev отделяла эталонные свидетельства точнее двух протестированных LLM и работала в 3–11 раз быстрее. А система, которая применяла ту же Jev для организации памяти во время записи, уступила Mnemon на 7,3 процентного пункта. Разница статистически значима, хотя сравниваемые системы различались не только моментом принятия решений.
Проверка охватывала память для разговоров и сравнивала Mnemon с системами из общей публичной переоценки. Разработку вели на тех же наборах, где затем измеряли результат; отдельного отложенного теста не было. На задачах с пересказом всей беседы, выполнением инструкций и строгим контролем лишних деталей система занимала места в нижней половине сравнения.
Когда подход меняет архитектурный план продукта
Работа меняет план систем, где история уже хранится как журнал событий, документов или задач. Вместо обязательной миграции в граф памяти можно оставить первичные записи, добавить смешанный поиск и разместить агент памяти между хранилищем и основной LLM. Смена отвечающей модели тогда не требует заново обрабатывать весь архив.
Такой выбор особенно уместен, если заранее неизвестно, какие вопросы появятся через месяцы. Схема, построенная при записи, удобна для стабильного набора запросов; Mnemon переносит решение на момент чтения, когда известны сам вопрос, недавний диалог и найденные записи. Платой становятся дополнительные вызовы моделей перед каждым ответом.
Медианное время полного ответа в экспериментах составляло 10–15 секунд, главным образом из-за обращений к моделям через API. Поэтому архитектура лучше подходит для ассистентов и фоновых рабочих процессов, чем для интерфейсов с жёстким требованием мгновенного отклика.
Есть и инфраструктурная зависимость: Jev — закрытая размещённая модель, а полноценную замену ей в составе Mnemon не проверяли. Кроме того, система сохраняет все исходные записи и дублирует часть сведений в фоновом индексе. Политики удаления, сроков хранения и доступа должны охватывать оба слоя.
Практический вывод не в том, чтобы отказаться от структурированной памяти. Работа показывает более обратимый порядок внедрения: сначала сохранить первичные записи и настроить отбор при чтении, затем добавлять фоновые представления для тех типов вопросов, где прямой поиск систематически пропускает доказательства.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
