Структурирование памяти по типам сокращает количество извлекаемых токенов примерно на 40%.

Почему плоское хранилище памяти не работает

Большинство туториалов для начинающих учат LLM-агента «запоминать» информацию, просто добавляя каждый новый фрагмент в единый список и передавая этот список модели на каждом шаге. Код буквально занимает три строки и создает рабочее демо. На практике же список растет бесконтрольно. Появляются два симптома:

  • Агент воспринимает устаревшие данные как актуальные — например, выдает расчетное время прибытия (ETA), которое истекло несколько часов назад.
  • Контекстное окно заполняется второстепенной информацией, которая никак не влияет на ответ, что увеличивает расходы на API и замедляет время ответа.

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

Структурированная память: четыре категории, одна цель

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

  • Факты о пользователе — стабильные атрибуты, такие как роль пользователя, предпочтительный язык или уровень допуска. Они меняются редко и могут кэшироваться на протяжении всей сессии.
  • Обратная связь — явные правила, которым должен следовать агент, например: «никогда не раскрывай пароли к базе данных» или «избегай юмора в запросах по комплаенсу». Поскольку они определяют поведение, их следует помещать в системный промпт (system prompt), а не в пул для поиска.
  • Состояние проекта — быстро меняющиеся данные, такие как текущие ETA, прогресс задач или временные токены. Для этой категории необходима проверка срока действия; как только временная метка выходит за пределы заданного окна, запись должна быть удалена.
  • Справочные данные — указатели на внешние сервисы, ID документов или эндпоинты API. Это не контент для отображения, а маршруты для получения свежих данных при необходимости.

Mem0 позволяет разработчикам прикреплять произвольные метаданные к каждой записи памяти. Индексируя поле kind, можно сначала отфильтровать запрос по нужной категории, прежде чем LLM решит, как использовать результат.

Двухэтапное извлечение с Mem0

  1. Извлечение памяти по типу — короткий фильтрующий запрос просит Mem0 выдать «всю обратную связь» или «записи состояния проекта, созданные за последний интервал». Набор результатов уже ограничен соответствующей категорией.
  2. Предоставление решения LLM — отфильтрованные фрагменты вставляются в промпт вместе с текущим вопросом пользователя. Теперь модель может рассуждать на их основе, не просеивая кучу нерелевантных фактов.

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

Практические хитрости для снижения затрат

  • Кэшируйте правила обратной связи — сохраняйте набор правил один раз за сессию и используйте его повторно, вместо того чтобы выполнять поиск на каждом шаге. Это снижает расход токенов в каждом раунде.
  • Пропускайте поиск состояния проекта, если он не нужен — если пользователь задает чисто концептуальный вопрос («В чем разница между обучением с учителем и обучением с подкреплением?»), нет необходимости извлекать данные об ETA или прогрессе задач.

Применяя эти две привычки, можно сократить использование токенов примерно на 40% по сравнению с наивным подходом с плоской памятью. Экономия напрямую конвертируется в более низкие счета за API и более быстрое время ответа, особенно для агентов, участвующих в длительных диалогах.

Кто выигрывает, а кто беспокоится

Выигрывают — команды, создающие ботов для поддержки клиентов, ассистентов для внутренних рабочих процессов или любые многоходовые LLM-интерфейсы. Они получают более надежные ответы, избегают неловких ошибок из-за устаревших данных и эффективнее распоряжаются бюджетом.

Итог

Если вы хотите, чтобы LLM-агент сохранял точность в ходе длительных сессий, перестаньте запихивать каждый факт в одно контекстное окно. Помечайте каждую запись как факт о пользователе, обратную связь, состояние проекта или справочные данные, устанавливайте сроки действия там, где это необходимо, и позвольте такому инструменту, как Mem0, взять на себя основную работу. Результатом станут более актуальные ответы, меньше лишних токенов и заметное снижение операционных расходов.