Урок 9.1. Категории инструментов для AI Agent Memory

Цель лекции

Разложить экосистему инструментов по категориям, чтобы читатель не смешивал memory frameworks, RAG, vector DB и observability.

Ожидаемый результат

Читатель понимает карту инструментов и может не путать категории решений: где нужен memory framework, где agent framework, где RAG pipeline, где database, а где достаточно файлов, logs и disciplined prompts.

Зачем это нужно

После модулей про типы памяти, retrieval, безопасность и evaluation возникает практический вопрос:

Что ставить в стек?

На него легко ответить неправильно. Экосистема выглядит как набор похожих слов:

memory framework;
agent framework;
RAG framework;
vector database;
graph database;
search engine;
cache;
observability platform;
enterprise knowledge platform.

Все они могут участвовать в memory layer, но решают разные задачи. Ошибка начинается, когда один инструмент пытаются использовать вместо всей архитектуры.

Vector DB не является memory system. RAG framework не является policy engine. Agent framework не решает governance сам по себе. Observability не исправляет плохую retrieval strategy. А dedicated memory framework может ускорить разработку, но не отменяет требований к приватности, scope, freshness и deletion.

Основная идея

Инструменты памяти решают разные задачи: одни управляют долгосрочной памятью, другие оркестрируют агентов, третьи хранят векторы, графы, documents, events или logs.

Полезно думать не "какой инструмент лучший?", а "какой слой системы он закрывает?".

Memory architecture обычно состоит из нескольких слоев:

capture: что записывать;
storage: где хранить;
indexing: как искать;
retrieval: что доставать;
ranking: что считать важным;
context assembly: что вставлять в prompt;
policy: что разрешено читать и писать;
lifecycle: как обновлять, забывать и удалять;
observability: как видеть, что произошло.

Разные инструменты покрывают разные части этой цепочки.

Ключевые термины

Термин	Короткое определение
`Memory framework`	Инструмент, который предоставляет abstractions для записи, поиска, обновления и иногда summarization памяти.
`Agent framework`	Инструмент для orchestration: state, steps, tools, agents, workflows.
`RAG framework`	Инструмент для ingestion, indexing, retrieval и grounding по внешним знаниям.
`Vector DB`	Хранилище embeddings и metadata для semantic search.
`Search engine`	Система keyword/hybrid search, часто с filters, ranking и document retrieval.
`Graph DB`	Хранилище entities and relationships для graph traversal и multi-hop queries.
`KV store`	Простое key-value хранилище для sessions, cache, short-term state.
`Observability`	Traces, logs, metrics и dashboards для debugging и quality monitoring.
`Enterprise context platform`	Платформа доступа к корпоративным источникам: docs, tickets, CRM, permissions, audit.

Карта экосистемы

flowchart TD U[User / environment] --> A[Agent runtime] A --> M[Memory framework] A --> R[RAG framework] A --> O[Observability] M --> S1[Profile / semantic store] M --> S2[Episodic store] M --> S3[Procedural store] R --> I[Ingestion / chunking] I --> V[Vector DB] I --> SE[Search engine] I --> G[Graph DB] A --> KV[Cache / KV / session store] A --> E[Enterprise connectors] E --> P[Permissions / audit] O --> T[Traces] O --> D[Dashboards]

Эта схема не говорит, что каждый проект обязан иметь все блоки. Она показывает, что "memory tools" - это не один класс продуктов, а несколько слоев вокруг агента.

Dedicated memory frameworks

Dedicated memory frameworks пытаются дать готовые abstractions именно для agent memory.

В эту категорию обычно попадают инструменты вроде Mem0, Zep, Letta и похожие системы.

Они могут предоставлять:

user memory profile;
session memory;
conversation history;
automatic extraction;
summaries;
semantic search;
memory update;
memory deletion;
metadata and scopes;
APIs для read/write;
иногда UI для просмотра памяти.

Когда они полезны:

нужно быстро собрать persistent memory для агента;
важны user profiles и long-term preferences;
команда не хочет писать extraction/update/retrieval слой с нуля;
есть типовые сценарии ассистента или support agent;
нужны готовые primitives для sessions и long-term memory.

Ограничения:

framework не знает ваших product policies сам по себе;
privacy и compliance все равно нужно проектировать;
сложная domain memory может потребовать своих schemas;
vendor abstraction может плохо лечь на ваш data model;
"автоматическая память" может записывать лишнее без строгих policies.

Важно: memory framework - это ускоритель разработки, а не замена архитектурного мышления.

Agent frameworks with state

Agent frameworks помогают строить workflows, tools, state machines и multi-agent orchestration.

Примеры категорий и инструментов: LangGraph, AutoGen, CrewAI, Mastra и похожие agent runtimes.

Они обычно закрывают:

graph/state machine для agent flow;
tool calling;
multi-step planning;
retries;
human-in-the-loop;
shared state;
multi-agent coordination;
persistence of execution state;
structured events.

Как они связаны с памятью:

agent state может хранить short-term operational memory;
checkpoints помогают resume workflow;
tool traces становятся episodic memory;
workflow conventions могут стать procedural memory;
multi-agent systems требуют shared context.

Но agent framework не всегда является memory layer.

Пример:

Agent framework умеет сохранять state graph.
Но кто решает, что из диалога стало long-term user preference?
Кто удаляет memory по запросу пользователя?
Кто проверяет stale facts?

Если framework не отвечает на эти вопросы, нужен отдельный memory design.

RAG frameworks

RAG frameworks нужны, когда агент должен работать с внешними знаниями: documents, docs, wiki, manuals, tickets, code, policies.

Примеры категорий и инструментов: LlamaIndex, LangChain и другие библиотеки для retrieval pipelines.

Они помогают с:

document loading;
parsing;
chunking;
embeddings;
indexing;
retrieval;
reranking;
citations;
query transformation;
hybrid search;
response synthesis.

RAG ближе всего к world memory: агент не "помнит" все внутри себя, а достает релевантные знания из внешнего корпуса.

Когда RAG framework нужен:

есть много documents;
знания часто обновляются;
нужны citations;
важен grounding;
memory должна ссылаться на source;
нужен ingestion pipeline.

Ограничения:

RAG не решает user preference memory автоматически;
RAG не заменяет policy layer;
chunk retrieval может принести правильный документ, но неправильный fragment;
stale documents требуют freshness strategy;
ingestion errors становятся memory errors.

RAG framework - это инструмент для world/context memory, а не универсальная память агента.

Vector databases

Vector DB хранит embeddings и позволяет искать похожие записи по смыслу.

Она может использоваться для:

semantic search по documents;
retrieval of memory records;
similar past conversations;
clustering;
deduplication;
candidate generation for reranking.

Что обычно хранится рядом с vector:

text fragment;
embedding;
source id;
timestamp;
scope;
tenant/user/project id;
permissions metadata;
importance score;
validity period;
record type.

Vector DB отвечает на вопрос:

Что семантически похоже на этот запрос?

Но она не отвечает сама:

можно ли это показывать этому пользователю;
не устарела ли запись;
является ли это secret;
насколько source reliable;
что делать при конфликте;
нужно ли записывать новый memory item.

Vector DB - важный infrastructure component, но не вся memory layer.

Search engines

Search engines решают keyword, lexical и hybrid search.

Они полезны, когда:

exact terms важны;
есть IDs, error messages, product names;
нужны filters and facets;
нужен ranking по structured signals;
corpus большой;
требуется production-grade document search.

Для agent memory search engine часто дополняет vector DB.

Пример:

Query:
"ошибка EADDRINUSE в dev server"

Vector search может найти похожие эпизоды.
Keyword search надежно найдет точный error code.
Hybrid retrieval даст лучший candidate set.

Search engines особенно полезны для:

enterprise docs;
support tickets;
logs;
code search;
operational incidents;
compliance records.

Ограничение: lexical search плохо находит смысловые совпадения, если слова разные. Поэтому в memory systems часто используют hybrid retrieval.

Graph databases

Graph DB хранит entities and relationships.

Она полезна, когда нужно понимать связи:

пользователь работает над проектом;
проект использует сервис;
сервис зависит от базы данных;
база данных имеет инцидент;
инцидент связан с customer tickets.

Graph memory помогает в задачах:

entity resolution;
relationship traversal;
dependency mapping;
multi-hop reasoning;
conflict detection;
provenance;
shared memory между агентами;
enterprise knowledge graphs.

Пример:

User -> owns -> Project A
Project A -> uses -> Search Stack B
Search Stack B -> replaced_by -> Vector DB C
Reason -> latency incidents

Когда graph layer нужен:

много сущностей;
связи важнее отдельных chunks;
нужно отвечать на "почему" и "как связано";
есть dependencies;
нужны temporal relationships;
требуется audit of relationships.

Когда graph layer избыточен:

memory - это несколько preferences;
задачам хватает top-k retrieval;
нет устойчивых entities;
нет команды, которая будет поддерживать schema.

Graph DB дает выразительность, но добавляет modeling cost.

Cache and KV stores

Cache и KV stores нужны для short-term state.

Они могут хранить:

session state;
current task state;
temporary preferences;
tool results;
recent retrieval results;
rate-limit state;
intermediate summaries;
locks;
idempotency keys.

Примеры технологий в этой категории: Redis, SQLite, Postgres key-value patterns, local files, embedded stores.

Для memory layer это часто "рабочий стол", а не библиотека долгосрочной памяти.

Пример:

User says:
"В этой сессии отвечай кратко."

Store:
session_style = concise
ttl = current session

Эту запись не нужно превращать в permanent semantic memory.

Local memory tools

Не вся память требует отдельной платформы.

Для малых проектов достаточно:

Markdown files;
JSON/YAML state;
SQLite;
local search;
git history;
logs;
structured notes;
simple summaries.

Это особенно полезно для:

personal tools;
prototypes;
course projects;
local coding agents;
small research assistants;
single-user workflows.

Преимущества:

понятность;
контроль;
дешевизна;
portability;
easy inspection;
меньше hidden magic.

Ограничения:

сложнее масштабировать;
нет готового permission model;
нет managed indexing;
нужно самому строить lifecycle;
трудно делать multi-tenant isolation.

Локальная память хороша, когда requirements простые и важна прозрачность.

Observability tools

Observability не хранит память как product feature, но без нее memory layer трудно отлаживать.

Нужны:

traces of memory reads;
traces of memory writes;
retrieved candidates;
reranker scores;
injected context;
policy decisions;
deletion propagation;
latency and cost;
errors in async jobs;
user correction events.

Observability отвечает на вопрос:

Почему агент сказал именно это?

Для memory layer это критично. Если пользователь говорит "агент помнит неправильно", нужно увидеть:

какая memory была найдена;
откуда она пришла;
почему она прошла filters;
была ли она stale;
как она попала в prompt;
использовала ли ее модель;
была ли записана новая ошибочная memory.

Без traces memory bugs выглядят как "модель странно себя ведет".

Enterprise context platforms

Enterprise context platforms соединяют агента с корпоративными источниками:

document repositories;
CRM;
ticket systems;
email;
chat;
data catalogs;
wiki;
file storage;
BI tools;
identity and access systems.

Главная сложность здесь не retrieval, а governance.

Такие платформы должны учитывать:

permissions;
tenancy;
audit;
retention;
legal hold;
source freshness;
access revocation;
data classification;
compliance requirements.

Для enterprise memory важно:

Не просто "нашел правильный документ",
а "нашел правильный документ, который этому агенту и пользователю разрешено использовать".

Если этого слоя нет, agent memory становится источником leakage.

Как категории сочетаются

В реальной системе категории часто комбинируются.

Пример personal assistant:

Слой	Возможный инструмент
Session state	KV store или local DB
User preferences	Memory framework или Postgres
Semantic search	Vector DB
Observability	Tracing/logging
User control	Product UI + policy layer

Пример enterprise support agent:

Слой	Возможный инструмент
Customer context	CRM connector
Docs retrieval	RAG framework + search engine
Similar tickets	Vector DB
Permissions	Enterprise identity layer
Audit	Logging/observability platform
Conversation memory	Memory framework or custom store

Инструменты не заменяют друг друга; они закрывают разные design responsibilities.

Мини-кейс: почему vector DB не равна памяти

Команда строит support agent и кладет все прошлые tickets в vector DB.

Потом пользователь спрашивает:

"Почему у нас снова сломался экспорт?"

Vector DB достает похожие tickets, но среди них:

ticket другого customer;
старый incident, который уже закрыт;
internal note с sensitive detail;
документ до обновления pricing plan.

Семантически retrieval сработал. Память как system - нет.

Чтобы это стало memory layer, нужны:

source metadata;
tenant filters;
freshness;
access control;
conflict handling;
grounding;
audit;
deletion and retention.

Мини-кейс: когда memory framework помогает

Команда делает персонального writing assistant.

Нужно помнить:

preferred language;
style preferences;
project-specific formatting;
recent writing goals;
corrections from user.

Dedicated memory framework может быстро дать:

user profile;
memory extraction;
retrieval API;
conversation summaries;
update mechanics.

Но команда все равно должна определить:

что считать permanent preference;
что считать session-only instruction;
какие данные не хранить;
как пользователь видит и удаляет memory;
какие scopes есть: global, project, document.

Framework ускоряет mechanics, но product rules остаются за вами.

Типичные ошибки

Ошибка 1: выбирать инструмент по популярности.

Популярный инструмент может решать не вашу проблему.

Ошибка 2: называть vector DB "памятью".

Vector DB - это storage/indexing component. Memory layer включает policies, lifecycle, retrieval strategy и context assembly.

Ошибка 3: брать agent framework и считать, что memory готова.

Stateful workflow не равен долгосрочной пользовательской памяти.

Ошибка 4: строить RAG без freshness и permissions.

Поиск по документам опасен, если не учитывать актуальность и доступ.

Ошибка 5: добавлять graph DB без graph-shaped problem.

Graph полезен, когда связи действительно важны. Иначе это лишняя сложность.

Ошибка 6: забывать observability.

Memory bugs нельзя нормально исправлять без traces.

Ошибка 7: начинать с enterprise stack для маленького проекта.

Иногда SQLite, files и clear policies дадут лучший результат на старте.

Краткое резюме

Экосистема AI Agent Memory состоит из разных категорий инструментов: memory frameworks, agent frameworks, RAG frameworks, vector DB, search engines, graph DB, cache/KV stores, local memory tools, observability и enterprise context platforms.

Главная мысль: инструмент нужно выбирать по роли в архитектуре. Хорошая memory layer - это не один продукт, а согласованная система storage, retrieval, policies, lifecycle, context assembly и monitoring.

Вопросы для самопроверки

Почему vector DB не является полноценной memory layer?
Чем memory framework отличается от agent framework?
Когда RAG framework полезнее dedicated memory framework?
В каких случаях graph DB действительно оправдана?
Почему observability является обязательной частью production memory?

Что дальше

В следующей лекции мы перейдем от карты инструментов к выбору стека под конкретную задачу: personal assistant, coding agent, support agent, research agent, voice agent, enterprise agent и multi-agent workflow.