Дерево решений для стратегии памяти агентов

Статья из Machine Learning Mastery, которая переосмысляет проектирование памяти агентов вокруг одного вопроса: не "какую систему памяти должен использовать этот агент", а "где должна храниться каждая категория информации". Главная идея в том, что память - это никогда не один архитектурный выбор. Текущий тикет агента поддержки, уровень подписки клиента и история его жалоб - это три разных вида информации, и каждому из них нужно своё хранилище. Классификация выполняется отдельно для каждой категории, а затем полученные ответы объединяются в архитектуру.

Четыре уровня памяти

Фреймворк опирается на принятое в когнитивистике разделение на четыре типа памяти, каждый из которых определяется предположениями о хранящейся информации:

Рабочая память - всё актуальное прямо сейчас находится в активном диалоге и в рамках ограниченного бюджета токенов. Это буфер беседы, удерживаемый в заданных границах обрезкой или суммаризацией.
Семантическая память - стабильные, многократно используемые факты, которые стоит хранить в виде канонического представления, а не выводить заново или переспрашивать. Атрибуты пользователя (имя, роль, предпочитаемый язык), знания о предметной области (бизнес-правила, спецификации продуктов) и выжимка знаний из повторяющихся взаимодействий.
Эпизодическая память - история произошедших событий, ценная сама по себе, а не только как текущее состояние. Прошлые решения, жалобы, транзакции. Хранится в виде растущего лога.
Процедурная память - повторяющиеся паттерны задач, выполнение которых должно становиться быстрее или надёжнее с каждой итерацией. Это оформленные процедуры, а не сырые стенограммы.

Большинство production-агентов используют более одного уровня. Агент службы поддержки держит тикет в рабочей памяти, уровень подписки - в семантической, прошлые жалобы - в эпизодической, а отработанную процедуру оформления возвратов - в процедурной.

Пять вопросов

Их нужно задавать последовательно для каждой категории информации:

Нужно ли сохранять её дольше текущего шага диалога? Если информация самодостаточна (разовый запрос на классификацию, одноразовый вывод инструмента), уровень памяти не нужен - достаточно контекстного окна. Если она нужна дальше, переходим к следующему вопросу.
Нужно ли сохранять её за пределами одной сессии? Если данные нужны только внутри сессии (что уже спросили, какие инструменты вызывались), хватит рабочей памяти. Если они должны пережить сессию (предпочтения вернувшегося клиента, многодневная задача), переходим к следующему вопросу.
Это неизменный факт или развивающееся событие? Неизменные факты отправляются в семантическую память, развивающаяся история - в эпизодическую. Именно этот вопрос часто пропускают, сваливая всё долговременное в одно хранилище без учёта структуры данных.
Как информация будет извлекаться? Небольшие ограниченные хранилища (профиль, горстка фактов) вычитываются целиком на старте сессии. Большим растущим хранилищам (история взаимодействий, корпус документов) нужен семантический или гибридный поиск, так как читать всё подряд становится непрактично. Одному агенту часто требуются оба паттерна одновременно.
Нужны ли агенту переиспользуемые процедуры? Если структура задачи повторяется и должна улучшаться с опытом, её оформляют в процедурную память поверх существующих семантических и эпизодических хранилищ. Разовые задачи этот шаг пропускают.

Совокупность ответов по всем категориям формирует профиль памяти. Агент для написания кода получает все четыре уровня, а простому FAQ-агенту может хватить одной лишь рабочей памяти. Оба варианта - корректные результаты одного и того же процесса.

Ошибки при выборе неверного уровня

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

Агент повторно переспрашивает то, что уже сообщалось в этой сессии -> рабочая память урезана слишком сильно, либо суммаризация потеряла детали. Нужно скорректировать окно, а не подключать долговременную память.
Поиск возвращает противоречивые результаты -> стабильные факты и развивающиеся события смешаны в одном хранилище. Их следует разделить: структурированное хранилище для фактов, отдельный лог для событий.
Семантическая память перезаписана некорректными данными -> отсутствует валидация или версионирование при записи. Именно эту проблему решает memory-conflict-detection: проверять запись, оставлять обе версии видимыми, не перезаписывать втихую. В статье приводится пример темпорального графа знаний Zep, где у каждого факта есть окно валидности, благодаря чему устаревший факт инвалидируется, а не остаётся противоречить новому.
Процедурная память ни к чему не приводит -> в хранилище попадают необработанные повторы вместо извлечённых выводов. Нужно записывать структурированный опыт, а не полную стенограмму.
Одно хранилище одновременно обслуживает факты, историю и состояние сессии -> данные вообще не были классифицированы. Пройдитесь по дереву решений для каждой категории.

Как это связано с остальным кластером памяти

Дерево решений служит картой верхнего уровня; остальные страницы vault'а о памяти раскрывают механику каждой из ветвей.

Ветка больших хранилищ в вопросе 4 - это область гибридного поиска: BM25 для точных терминов плюс близость эмбеддингов по смыслу. Разделение на факты и события в вопросе 3, а также ошибка с перезаписью некорректными данными - это в точности memory-conflict-detection. В статье эпизодические логи рассматриваются по принципу добавления и очистки; agent-memory-decay предлагает более выверенный подход к очистке: воспоминания угасают по закону периода полураспада, если не подкрепляются извлечением, поэтому устаревшие записи плавно затухают, а не удаляются по жёсткому расписанию.

Что касается инструментов, системы памяти из раздела toolbox занимают свои позиции в этом дереве. hippo-memory по умолчанию реализует три уровня хранения с угасанием и обнаружением конфликтов - фактически рабочую, семантическую и эпизодическую память со встроенными механиками из таблицы ошибок. mempalace представляет собой большое эпизодическое хранилище, закрывающее вопрос 4 с помощью дословной истории и иерархического извлечения (заявлено 96.6% R@5 на LongMemEval). stash активнее всего опирается на шаг дистилляции из вопроса 5: сырые эпизоды синтезируются в фоновом режиме в факты, связи и паттерны, размывая границу между эпизодической и семантической/процедурной памятью, которую дерево проводит как строгую черту.

В статье названы сторонние строительные блоки для конкретных ветвей: OpenAI Agents SDK для буферов сессий (вопрос 2), инструмент памяти Anthropic для небольших полностью вычитываемых хранилищ (вопрос 4, малый объём), Memory Bank от Google и Mem0 для больших хранилищ с возможностью поиска (вопрос 4, большой объём), а также Zep для темпоральных графов знаний (вопрос 3).

Оговорка из обсуждения

Этот фреймворк - таксономия, а не проверенный на практике результат: он подсказывает, куда разложить данные, но не гарантирует качество работы выбранного распределения. Единственный содержательный комментарий на HN подчёркивает, что бенчмаркинг систем памяти остаётся сложной открытой проблемой: существующие бенчмарки вроде LoCoMo и LongMemEval не покрывают все перечисленные в статье сценарии, поэтому пока нет надёжного способа измерить, насколько выбранная архитектура действительно жизнеспособна в production.