Урок 9.9. Storage and search engines для памяти: vector, search, graph, KV, local

Цель лекции

Разобрать open-source и инфраструктурные хранилища, которые используются в agent memory: vector databases, search engines, graph databases, KV/cache stores and local memory tools.

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

Читатель понимает, какие storage/search engines подходят для разных типов памяти, почему vector DB не равна memory system, когда нужен OpenSearch/Elasticsearch, когда оправдан graph layer и почему SQLite/Markdown часто являются лучшим стартом.

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

В content_plan.md перечислены разные инфраструктурные инструменты:

Milvus, Pinecone, Weaviate, Qdrant, LanceDB;
Elasticsearch, OpenSearch, Tantivy, PostgreSQL full-text;
Neo4j, Memgraph, TigerGraph and graph layers;
Redis, KeyDB, DynamoDB-style stores;
SQLite, Markdown, JSON, local vector indexes.

Многие из них являются open-source или имеют open-source ядро. Но важно понимать: это не конкуренты в одной категории. Они отвечают на разные retrieval and storage questions.

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

Memory layer обычно использует несколько storage/search engines одновременно.

flowchart TD ML[Memory layer] --> SQL[(SQL records)] ML --> KV[(KV or cache)] ML --> V[(Vector index)] ML --> SE[(Search index)] ML --> G[(Graph DB)] ML --> FS[(Files and object storage)] SQL --> A[Audit and structured facts] KV --> B[Session state and hot context] V --> C[Semantic similarity] SE --> D[Exact and hybrid search] G --> E[Entities and relationships] FS --> F[Raw sources and artifacts]

Хорошая архитектура начинается с вопроса:

Какой вопрос должен уметь задавать агент?

Не:

Какую базу сейчас модно поставить?

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

Термин	Короткое определение
`Vector DB`	Хранилище embeddings и metadata для semantic similarity search.
`Search engine`	Индекс для lexical, full-text, filtering, ranking and hybrid search.
`Graph DB`	База для entities, relationships, traversals and multi-hop queries.
`KV store`	Key-value storage для session state, cache, locks and fast lookups.
`Local memory`	Files, SQLite, JSON, local indexes, которые легко инспектировать и переносить.
`Payload metadata`	Структурные поля рядом с memory item: scope, source, permissions, timestamp.
`Hybrid search`	Retrieval, объединяющий semantic and lexical signals.

Vector databases: semantic similarity

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

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

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

похожих past conversations;
document chunks;
support tickets;
research notes;
user memories;
code snippets;
deduplication;
candidate generation before reranking.

Open-source и self-host friendly варианты:

Инструмент	Где силен	На что обратить внимание
Qdrant	Filtering, payloads, hybrid queries, simple operations	Нужно проектировать collections and metadata.
Chroma	Быстрый local/dev start, AI-native retrieval, metadata filters	Следить за parity между local/distributed modes.
Milvus	Масштаб, distributed deployment, large vector workloads	Операционная сложность выше, чем у embedded вариантов.
Weaviate	Vector search plus schema and hybrid capabilities	Нужно понимать data model and modules.
LanceDB	Embedded/local/vector lake style workloads	Хорош для lightweight and file-oriented scenarios.
pgvector	Vector search внутри PostgreSQL	Удобен, если Postgres уже source of truth.

Pinecone тоже часто появляется в списках vector databases, но это managed platform, а не open-source база для self-host. В open-source фокусе курса ее полезнее рассматривать как managed alternative, а не как локальный компонент.

Что vector DB не делает сама

Vector DB не решает:

что записывать;
можно ли это хранить;
кому это можно показать;
устарела ли запись;
как удалить ее из summaries and caches;
как разрешить конфликт;
как объяснить, почему запись попала в prompt.

Минимальная структура memory item рядом с vector:

id
content
embedding
memory_type
scope
source
created_at
valid_from
valid_to
confidence
importance
permissions
deletion_status

Без metadata vector retrieval становится глобальным похожим поиском, а не безопасной памятью.

Search engines: exact, lexical and hybrid retrieval

Search engine отвечает на другой вопрос:

Какие документы точно совпадают с терминами, фильтрами и structured fields?

Это критично, когда важны:

error codes;
API names;
ticket IDs;
customer IDs;
file paths;
legal clauses;
exact product terms;
filters and facets.

Open-source варианты:

Инструмент	Где полезен
OpenSearch	Full-text, filters, hybrid search, vector/neural search, self-host.
Elasticsearch	Mature search ecosystem, hybrid/vector capabilities, Elastic stack.
PostgreSQL full-text	Простой путь, если данные уже в Postgres.
Tantivy	Embedded Rust search engine для локальных или custom systems.

Search engine особенно важен для coding and enterprise agents.

Пример:

Query: "EADDRINUSE 3000"

Pure vector search может найти похожие проблемы с ports. Lexical search надежно найдет точный error code.

Hybrid search как baseline для production

Для memory retrieval часто нужен hybrid подход:

vector search дает semantic recall;
keyword search ловит exact identifiers;
metadata filters ограничивают scope and permissions;
reranker выбирает useful candidates;
context assembler режет итоговый prompt.

flowchart LR Q[Query] --> V[Vector candidates] Q --> K[Keyword candidates] V --> M[Merge] K --> M M --> F[Scope and permission filters] F --> R[Reranker] R --> C[Context budget]

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

Graph databases: entities and relationships

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

Как сущности связаны друг с другом?

Она нужна, когда важны:

users, teams, projects, documents, accounts;
dependencies;
ownership;
temporal relationships;
multi-hop queries;
provenance;
conflict detection;
impact analysis.

Варианты:

Инструмент	Где полезен
Neo4j	Зрелая graph DB, Cypher, graph modeling, vector indexes in graph context.
Memgraph	Open-source graph DB с Cypher-like подходом и streaming use cases.
FalkorDB	Lightweight graph database, часто встречается в memory/GraphRAG stacks.
TigerGraph	Graph analytics and enterprise graph workloads.
Graphiti	Framework layer для temporal knowledge graphs поверх graph storage.

Graph layer оправдан, если вопросы действительно graph-shaped.

Пример:

"Какие клиенты пострадают, если мы отключим старый export service?"

Нужно пройти путь:

Service -> Account -> Customer -> Contract -> Risk

Vector DB не предназначена для строгого traversal такого вида.

Graph DB не заменяет vector/search

Graph полезен для отношений, но плохо отвечает на расплывчатые вопросы без entity linking.

Пример:

"Где мы обсуждали странную проблему с биллингом после миграции?"

Сначала может понадобиться vector or keyword retrieval, чтобы найти relevant episodes. Затем graph поможет связать:

episode -> service -> migration -> account -> incident

Поэтому зрелые memory systems часто используют graph + vector + keyword.

KV and cache stores: hot state

KV/cache отвечает на вопрос:

Что нужно быстро прочитать или записать прямо сейчас?

Типичные данные:

session state;
current workflow variables;
recent tool results;
retrieval cache;
rate limits;
locks;
idempotency keys;
short-lived preferences;
streaming conversation state.

Варианты:

Инструмент	Где полезен
Redis	Fast cache, session state, queues, vector/search features in some deployments.
KeyDB	Redis-compatible alternative.
DynamoDB-style stores	Managed key-value/document patterns для high-scale apps.
SQLite	Local durable state for single-user tools.

KV store обычно не должен становиться dumping ground для всей памяти.

Запись:

session_style = concise
ttl = current session

не обязана попадать в long-term semantic memory.

Local memory tools: SQLite, Markdown, JSON

Local memory недооценена.

Для многих агентов лучший старт:

Markdown for instructions and summaries;
JSON/YAML for structured small state;
SQLite for local records;
local vector index for small semantic search;
git history for project evolution;
plain logs for episodic memory.

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

прозрачность;
дешевизна;
portable;
easy review;
легко включить в code review;
хороший fit для coding agents and course agents.

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

нет готового multi-tenant permission model;
сложнее sync;
нет managed scaling;
lifecycle нужно писать самому;
search может быстро стать слабым.

Для локального coding agent файлы часто являются source of truth, а не fallback.

SQL as memory backbone

Даже если система использует vector DB and graph DB, SQL часто остается backbone:

memory records;
users;
scopes;
permissions;
audit events;
retention rules;
source metadata;
deletion requests;
evaluation results.

PostgreSQL особенно удобен, если нужна комбинация:

relational integrity;
JSONB для гибких records;
full-text search;
pgvector;
transactions;
audit-friendly modeling.

SQL не всегда самый модный слой, но часто самый надежный source of truth.

Как выбирать storage engine по memory type

Тип памяти	Частый storage choice
Working memory	Prompt, state object, cache
Session memory	KV, Redis, SQLite, checkpointer
Semantic user facts	SQL + optional vector index
Episodic memory	Event log, SQL, object storage, vector index
Procedural memory	Markdown, policy files, SQL/versioned docs
Reflection memory	Structured records + review workflow
World/RAG memory	Document store + vector/search index
Shared memory	SQL/graph + permissions + audit
Temporal graph memory	Graph DB + valid time metadata

Ни один engine не покрывает все типы идеально.

Мини-кейс: personal assistant

Минимальный open-source stack:

Postgres or SQLite for user profile
Redis for session state
Qdrant or pgvector for semantic recall
Markdown/JSON for user-visible settings export
Structured logs for audit

Если объем маленький, можно начать без отдельной vector DB:

SQLite + simple search + compact profile

Vector DB появляется, когда preferences, notes and conversations становятся большими.

Мини-кейс: enterprise knowledge agent

Более зрелый stack:

Postgres for records, permissions, audit
OpenSearch for hybrid document retrieval
Vector DB for semantic passages
Neo4j or Graphiti-style graph for entities and relations
Redis for cache/session state
Object storage for raw documents and logs

Главный вопрос не "какая база быстрее", а:

Как обеспечить permissions, freshness, deletion and audit across all indexes?

Мини-кейс: local coding agent

Стартовый stack:

Repository files as source of truth
AGENTS.md as procedural memory
SQLite for task episodes
rg/git for exact search
Optional local embeddings for semantic code/docs search

Здесь managed vector database может быть избыточна. Главное - не доверять старой памяти больше, чем текущему состоянию файлов.

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

Ошибка 1: выбирать vector DB вместо memory architecture.

Vector DB нужен для semantic candidates, но не управляет policies.

Ошибка 2: игнорировать keyword search.

IDs, error codes and file paths часто важнее semantic similarity.

Ошибка 3: строить graph без entity linking.

Graph без нормализации сущностей быстро превращается в набор дублей.

Ошибка 4: хранить permanent facts в cache.

Cache может исчезнуть, устареть или быть очищен.

Ошибка 5: не планировать deletion propagation.

Удаление должно проходить через SQL records, vector index, search index, graph edges, summaries and cache.

Ошибка 6: начинать с distributed stack для single-user tool.

SQLite and files often win until scale requires more.

Источники для дальнейшего чтения

Qdrant hybrid search: https://qdrant.tech/documentation/search/text-search/hybrid-search/
Chroma introduction: https://docs.trychroma.com/docs/overview/introduction
Milvus overview: https://milvus.io/docs/overview.md
Milvus quickstart: https://milvus.io/docs/quickstart.md
OpenSearch hybrid search: https://docs.opensearch.org/docs/3.0/vector-search/ai-search/hybrid-search/index/
OpenSearch hybrid query: https://docs.opensearch.org/latest/query-dsl/compound/hybrid
Neo4j graph database overview: https://neo4j.com/docs/getting-started/graph-database/
Neo4j vector indexes: https://neo4j.com/docs/cypher-manual/current/indexes/semantic-indexes/vector-indexes/

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

Storage and search engines - это инфраструктура памяти, а не сама память. Vector DB дает semantic search, search engine дает lexical/hybrid retrieval, graph DB хранит relationships, KV/cache держит hot state, local files and SQLite дают прозрачный старт.

Хорошая memory layer обычно комбинирует несколько engines и добавляет поверх них policies, lifecycle, scopes, context assembly, deletion and observability.

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

Почему vector DB не отвечает за privacy policy?
Когда search engine важнее vector DB?
Какие признаки говорят, что нужен graph layer?
Почему SQLite and Markdown могут быть лучшим стартом для coding agent?
Что значит deletion propagation across indexes?

Что дальше

В следующей лекции мы закроем последнюю важную категорию экосистемы: enterprise context platforms and connectors, где главными становятся permissions, source metadata, freshness and audit.