Сравнение систем памяти для агентов LLM: векторные, графовые и журналы событий

Оглавление

Высокоуровневое сравнение

1. Векторные системы памяти
1.1 Простой векторный RAG
1.2 Иерархическая векторная память (MemGPT-стиль виртуального контекста)
2. Графовые системы памяти
2.1 Временные графовые системы памяти (Zep / Graphiti)
2.2 Графовый RAG (GraphRAG)
3. Системы журналов событий и выполнения
3.1 Журналы выполнения и контрольные точки (ALAS, LangGraph)
3.2 Эпизодическая долговременная память

Ключевые выводы

Надёжные мультиагентные системы в основном решают проблему проектирования памяти. Когда агенты вызывают инструменты, сотрудничают и выполняют длительные рабочие процессы, требуются явные механизмы для хранения данных, их извлечения и определения поведения системы при ошибках или отсутствии памяти.

В этой статье сравниваются 6 шаблонов систем памяти, обычно используемых в стеках агентов, сгруппированные в 3 семейства:
* векторная память;
* графовая память;
* журналы событий / выполнения.

Мы сосредоточимся на задержках извлечения, частоте попаданий и режимах сбоев при мультиагентном планировании.

Высокоуровневое сравнение

Векторные системы памяти

1.1 Простой векторный RAG

* Что это такое?
* По умолчанию используется в большинстве RAG и агентских фреймворках:
* Кодируйте текстовые фрагменты (сообщения, выходные данные инструментов, документы) с помощью модели встраивания.
* Храните векторы в индексе ANN (FAISS, HNSW, ScaNN и т. д.).
* При запросе встраивайте запрос и извлекайте k ближайших соседей, опционально переранжируйте.
* Это «память магазина векторов», предоставляемая типичными библиотеками оркестрации LLM.

* Профиль задержки
* Приблизительные индексы ближайших соседей предназначены для сублинейного масштабирования с размером корпуса:
* Графовые структуры ANN, такие как HNSW, обычно демонстрируют эмпирически почти логарифмический рост задержки по сравнению с размером корпуса для фиксированных целей отзыва.
* На одном узле с настроенными параметрами извлечение из миллионов элементов обычно занимает низкие десятки миллисекунд на запрос плюс любые затраты на переранжирование.

* Поведение при попадании
* Частота попаданий высока, когда:
* Запрос локальный («о чём мы только что говорили»), или
* Информация хранится в небольшом количестве фрагментов с вложениями, согласованными с моделью запроса.
* Векторный RAG значительно хуже работает на:
* Временных запросах («что решил пользователь на прошлой неделе»).
* Межсессионном рассуждении и длинных историях.
* Многоходовых вопросах, требующих явных реляционных путей.

1.2 Иерархическая векторная память (MemGPT-стиль виртуального контекста)

* Что это такое?
* MemGPT вводит абстракцию виртуальной памяти для LLM: небольшой рабочий контекст плюс более крупные внешние архивы, управляемые моделью с помощью вызовов инструментов (например, «поменять в этой памяти», «заархивировать этот раздел»). Модель решает, что оставить в активном контексте, а что извлечь из долговременной памяти.

* Архитектура
* Активный контекст: токены, присутствующие в данный момент во входных данных LLM (аналогично ОЗУ).
* Архив / внешняя память: более крупное хранилище, часто поддерживаемое векторной БД и хранилищем объектов.
* LLM использует специализированные функции для:
* загрузки заархивированного содержимого в контекст.
* вытеснения частей текущего контекста в архив.

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

* Поведение при попадании
* Улучшение по сравнению с простым векторным RAG:
* Часто используемые элементы хранятся в рабочем наборе, поэтому они не зависят от ANN-извлечения каждый шаг.
* Редкие или старые элементы по-прежнему страдают от ограничений векторного поиска.

Графовые системы памяти

2.1 Временные графовые системы памяти (Zep / Graphiti)

* Что это такое?
* Zep позиционирует себя как уровень памяти для ИИ-агентов, реализованных в виде временного графа знаний (Graphiti). Он интегрирует:
* Разговорную историю.
* Структурированные бизнес-данные.
* Временные атрибуты и версионирование.

* Архитектура
* Основные компоненты:
* Узлы: сущности (пользователи, билеты, ресурсы), события (сообщения, вызовы инструментов).
* Рёбра: отношения (создано, зависитот, обновленоby, обсуждалось_in).
* Временная индексация: интервалы допустимости и временные метки на узлах/рёбрах.
* API для:
* записи новых событий / фактов в KG.
* запроса по сущностям и временным измерениям.
* KG может сосуществовать с векторным индексом для семантических точек входа.

* Профиль задержки
* Графовые запросы обычно ограничены небольшой глубиной обхода:
* Для вопросов типа «последняя конфигурация, прошедшая проверки» система:
* Локализует соответствующий узел сущности.
* Проходит по исходящим рёбрам с временными фильтрами.
* Сложность масштабируется с размером локальной окрестности, а не всего графа.

2.2 Графовый RAG (GraphRAG)

* Что это такое?
* GraphRAG — это конвейер извлечения с генерацией, основанный на Microsoft, который строит явный граф знаний над корпусом и выполняет иерархическое обнаружение сообществ (например, Hierarchical Leiden) для организации графа. Он хранит сводки по сообществам и использует их во время запроса.

* Конвейер:
* Извлечение сущностей и отношений из исходных документов.
* Построение KG.
* Запуск обнаружения сообществ и построение многоуровневой иерархии.
* Генерация сводок для сообществ и ключевых узлов.
* Во время запроса:
* Идентификация соответствующих сообществ (через ключевые слова, вложения или графовые эвристики).
* Извлечение сводок и поддерживающих узлов.
* Передача их в LLM.

* Профиль задержки
* Индексация тяжелее, чем у простого RAG (построение графа, кластеризация, суммирование).
* Задержка при запросе может быть конкурентоспособной или лучше для больших корпусов, потому что:
* Вы извлекаете небольшое количество сводок.
* Вы избегаете построения чрезвычайно длинных контекстов из множества необработанных фрагментов.

* Поведение при попадании
* GraphRAG имеет тенденцию превосходить простой векторный RAG, когда:
* Запросы являются многодокументными и многоходовыми.
* Вам нужна глобальная структура, например, «как этот дизайн эволюционировал», «какая цепочка инцидентов привела к этому сбою».
* Вы хотите ответы, которые интегрируют доказательства из многих документов.

Системы журналов событий и выполнения

3.1 Журналы выполнения и контрольные точки (ALAS, LangGraph)

* Что они из себя представляют?
* Эти системы рассматривают «что делали агенты» как структуру данных первого класса.
* ALAS: транзакционная мультиагентная структура, поддерживающая версионный журнал выполнения плюс:
* Изоляция валидатора: отдельная LLM проверяет планы/результаты со своим контекстом.
* Локализованный каскадный ремонт: при сбоях редактируется только минимальная область журнала.
* LangGraph: предоставляет потоковые контрольные точки агента (сообщения, выходные данные инструментов, состояния узлов), которые можно сохранять, возобновлять и разветвлять.

* Профиль задержки
* Для нормальной прямой реализации:
* Чтение хвоста журнала или недавнего контрольного момента — O(1) и мало.
* Задержка в основном связана с выводом LLM и вызовами инструментов, а не с доступом к журналу.
* Для аналитики / глобальных запросов:
* Вам нужны вторичные индексы или офлайн-обработка; сканирование в сыром виде — O(n).

* Поведение при попадании
* Для вопросов типа «что произошло», «какие инструменты были вызваны с какими аргументами» и «каково было состояние до этого сбоя» частота попаданий практически равна 100%, при условии:
* Все соответствующие действия инструментированы.
* Настроена правильная конфигурация сохранения и удержания журналов.
* Журналы не обеспечивают семантическое обобщение сами по себе; вы накладываете векторные или графовые индексы поверх них для семантики между выполнениями.

3.2 Эпизодическая долговременная память

* Что это такое?
* Эпизодические структуры памяти хранят эпизоды: связные сегменты взаимодействия или работы, каждый с:
* Описанием задачи и начальными условиями.
* Соответствующим контекстом.
* Последовательностью действий (часто ссылки на журнал выполнения).
* Результатами и метриками.
* Эпизоды индексируются с помощью:
* Метаданных (временные окна, участники, инструменты).
* Вложений (для поиска по сходству).
* Опциональных сводок.
* Некоторые системы периодически дистиллируют повторяющиеся шаблоны в более высокий уровень знаний или используют эпизоды для тонкой настройки специализированных моделей.

* Профиль задержки
* Эпизодический поиск обычно двухэтапный:
* Идентификация соответствующих эпизодов с помощью фильтров метаданных и/или векторного поиска.
* Извлечение содержимого в выбранных эпизодах (подпоиск или прямые ссылки на журнал).
* Задержка выше, чем при однократном плоском векторном поиске на небольших данных, но лучше масштабируется по мере роста истории жизни, потому что вы избегаете поиска по всем отдельным событиям для каждого запроса.

Ключевые выводы

* Память — это проблема систем, а не трюк с подсказками: надёжные мультиагентные системы нуждаются в явном проектировании того, что хранится, как оно извлекается и как система реагирует, когда память устарела, отсутствует или неверна.
* Векторная память быстрая, но структурно слабая: простые и многоуровневые векторные хранилища обеспечивают низкую задержку, сублинейное извлечение, но борются с временным рассуждением, межсессионным состоянием и многоходовыми зависимостями, что делает их ненадёжными в качестве единственной основы памяти при планировании рабочих процессов.
* Графовая память устраняет временные и реляционные слепые зоны: временные графы (например, Zep/Graphiti) и графовые системы типа GraphRAG улучшают частоту попаданий и задержку по запросам, ориентированным на сущности, временные и многодокументные запросы, кодируя сущности, отношения и время явно.
* Журналы событий и контрольные точки — это основа истины: ALAS-подобные журналы выполнения и LangGraph-подобные контрольные точки предоставляют авторитетную запись о том, что на самом деле делали агенты, обеспечивая воспроизведение, локализованный ремонт и реальную наблюдаемость в производственных системах.
* Устойчивость систем обеспечивается сочетанием нескольких слоёв памяти: практические архитектуры агентов сочетают векторную, графовую и эпизодическую память, с чёткими ролями и известными режимами сбоев для каждого, вместо того чтобы полагаться на единый «магический» механизм памяти.

1. Какие преимущества и недостатки есть у простой векторной системы памяти по сравнению с иерархической векторной памятью?

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

2. В чём заключается основная разница между временными графовыми системами памяти (Zep / Graphiti) и графовым RAG (GraphRAG)?

Ответ: временные графовые системы памяти (Zep / Graphiti) интегрируют разговорную историю, структурированные бизнес-данные, временные атрибуты и версионирование. Они используют узлы и рёбра для представления сущностей и отношений между ними. Графовый RAG (GraphRAG) строит явный граф знаний над корпусом и выполняет иерархическое обнаружение сообществ для организации графа. Он хранит сводки по сообществам и использует их во время запроса.

3. Какие системы памяти обеспечивают наилучшую поддержку для многоходовых вопросов и рассуждений, ориентированных на сущности и временные запросы?

Ответ: графовая память, особенно системы типа GraphRAG, обеспечивают наилучшую поддержку для многоходовых вопросов и рассуждений, ориентированных на сущности и временные запросы. Они улучшают частоту попаданий и задержку по запросам, кодируя сущности, отношения и время явно. Это делает их более надёжными для использования в мультиагентных системах по сравнению с векторной памятью.

4. Какие механизмы используются в системах журналов событий и выполнения для обеспечения воспроизводимости и локализованного ремонта?

Ответ: ALAS-подобные журналы выполнения и LangGraph-подобные контрольные точки предоставляют авторитетную запись о том, что на самом деле делали агенты. Они обеспечивают воспроизведение, локализованный ремонт и реальную наблюдаемость в производственных системах. ALAS поддерживает версионный журнал выполнения с изоляцией валидатора и локализованным каскадным ремонтом, в то время как LangGraph предоставляет потоковые контрольные точки агента.

5. Какие выводы можно сделать о важности сочетания различных слоёв памяти в мультиагентных системах?

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

Источник