Урок 9.2. Как выбирать стек под задачу

Цель лекции

Помочь читателю подобрать архитектуру и инструменты памяти под тип агента.

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

Читатель умеет выбирать не самый модный, а подходящий стек памяти: от файлов и SQLite до vector DB, graph layer, memory frameworks, enterprise connectors и observability.

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

Один и тот же термин memory layer может означать очень разные системы.

Для personal assistant память - это preferences, goals, consent и user control.

Для coding agent - project conventions, прошлые решения, tool traces и связь с файлами.

Для customer support agent - customer context, tickets, docs, permissions и audit.

Для research agent - источники, citations, claims, reading history и synthesis.

Для voice agent - low latency, current session, user profile и interruption handling.

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

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

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

Хороший выбор начинается не с названия инструмента, а с вопросов:

кто пользователь;
что агент должен помнить;
сколько живет memory;
сколько пользователей и tenants;
какие источники нужны;
какие данные нельзя хранить;
как пользователь исправляет память;
нужна ли ссылка на source;
есть ли strict latency budget;
нужен ли audit;
насколько сложны relationships;
есть ли команда, которая будет поддерживать stack.

Только после этого выбираются инструменты.

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

Термин	Короткое определение
`Stack`	Набор инструментов и сервисов, из которых собрана memory layer.
`Baseline stack`	Минимальная архитектура, достаточная для первых рабочих сценариев.
`Scale requirement`	Требование по числу пользователей, объему данных, QPS, retention и latency.
`Governance requirement`	Требование по permissions, audit, deletion, compliance и user control.
`Data shape`	Форма данных: facts, documents, events, workflows, graph relationships.
`Latency budget`	Максимальное допустимое время memory read/write на user flow.
`Operational maturity`	Готовность команды поддерживать indexes, jobs, monitoring и migrations.

Базовый алгоритм выбора

flowchart TD A[Start with task] --> B[Define memory types] B --> C[Define data shape] C --> D[Define privacy and governance] D --> E[Define latency and scale] E --> F[Choose minimum viable stack] F --> G[Add retrieval / graph / framework only if needed] G --> H[Test with metrics and scenarios] H --> I[Iterate]

Главный принцип: начинайте с минимального стека, который можно проверить. Добавляйте сложность после появления реального требования.

Decision matrix

Требование	Обычно достаточно	Когда усложнять
Один пользователь, малый объем	Files, SQLite, local search	Нужны sync, multi-device, permissions
User preferences	Profile table, memory framework	Нужны scopes, consent UI, deletion, audit
Документы и знания	RAG framework + vector/search index	Нужны complex ingestion, citations, permissions
Exact terms и logs	Search engine	Нужен semantic similarity или hybrid retrieval
Semantic similarity	Vector DB	Нужны tenant filters, reranking, freshness
Сложные связи	Graph DB	Есть устойчивые entities, dependencies, multi-hop queries
Workflow memory	Procedural store, playbooks	Нужны versioning, policy checks, team sharing
Low latency voice	KV/session memory, prefetch	Нужен async retrieval, streaming, cache strategy
Enterprise governance	Identity, audit, connectors	Нужны retention, legal hold, compliance reports
Debugging memory	Traces/logs	Нужны dashboards, eval datasets, alerting

Эта таблица не заменяет дизайн, но помогает не прыгать сразу к тяжелому stack.

Когда хватит SQLite и файлов

SQLite, Markdown/JSON files и простые logs часто недооценены.

Их может хватить, если:

один пользователь или маленькая команда;
объем memory небольшой;
latency не экстремальная;
нет сложного multi-tenant access control;
memory records легко инспектировать;
важна portability;
проект на стадии prototype;
данные можно хранить локально.

Пример стека:

Memory store: SQLite
Notes/summaries: Markdown files
Search: simple keyword search or local embeddings
Policies: application code
Observability: structured logs

Такой стек подходит для:

personal coding agent;
локального writing assistant;
small research notebook agent;
course-building agent;
internal prototype.

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

нужно самому писать lifecycle;
трудно масштабировать;
нет managed permissions;
vector search может быть слабым;
sync и backup требуют отдельного решения.

Но для старта это часто лучший выбор: прозрачный, дешевый, легко проверяемый.

Когда нужна vector database

Vector DB нужна, когда memory retrieval должен находить смысловые совпадения.

Признаки:

много текстовых fragments;
пользователь формулирует запросы разными словами;
нужны similar past cases;
нужно искать по conversations, docs, tickets, notes;
keyword search дает низкий recall;
top-k retrieval важен для answer quality;
corpus растет.

Пример:

User asks:
"Где мы обсуждали проблему с медленным экспортом?"

Memory contains:
"CSV generation times out for large accounts."

Semantic retrieval может связать эти две формулировки.

Что обязательно добавить поверх vector DB:

metadata filters;
user/project/tenant scope;
freshness signals;
deletion propagation;
reranking;
source references;
observability for retrieved candidates.

Vector DB без metadata и policies быстро превращается в опасный глобальный поиск.

Когда нужен search engine

Search engine нужен, когда exact match важен не меньше semantic match.

Признаки:

много error codes;
продуктовые названия важны;
есть IDs, emails, ticket numbers;
нужно filtering/faceting;
документы имеют structured fields;
требуется mature ranking;
пользователи ищут конкретные формулировки.

Пример:

"EADDRINUSE 3000"
"SOC2 policy retention"
"customer_id 48291 export"

Для таких запросов lexical или hybrid search часто надежнее pure embeddings.

Практический вывод: для production RAG и memory retrieval часто нужен hybrid search, а не спор "keyword против vector".

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

Graph layer нужен не потому, что graph звучит умно, а потому что data shape графовый.

Признаки:

много устойчивых entities;
связи важны для ответа;
есть dependencies;
нужны multi-hop questions;
важна provenance of relationships;
нужно обнаруживать conflicts;
есть temporal relationships;
shared memory между агентами зависит от ролей и связей.

Пример:

Question:
"Какие customers могут пострадать, если мы выключим старый export service?"

Need:
Service -> used_by -> Accounts -> customers -> contracts -> risk level

Graph layer оправдан для:

enterprise knowledge agents;
product dependency maps;
research graphs;
CRM relationship reasoning;
multi-agent coordination;
compliance/audit contexts.

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

все вопросы решаются top-k document retrieval;
сущности нестабильны;
нет команды на schema governance;
связи проще хранить как metadata.

Graph добавляет силу, но требует modeling discipline.

Когда memory framework ускоряет разработку

Memory framework полезен, когда нужны готовые primitives для user/session memory.

Признаки:

нужно быстро добавить long-term preferences;
есть conversations across sessions;
нужны summaries;
нужна автоматическая extraction;
нужны APIs для memory read/write;
нужно prototype persistent assistant;
команда не хочет сразу строить full custom layer.

Подходит для:

personal assistant;
writing assistant;
support copilot;
coaching/tutoring agent;
internal productivity assistant.

Но framework не отменяет:

domain-specific policies;
user consent;
scope design;
safety filters;
deletion UI;
eval datasets;
observability.

Правильный вопрос:

Какие memory responsibilities framework закрывает,
а какие остаются в нашем приложении?

Персональный ассистент

Цель: помнить полезные предпочтения, цели и контекст пользователя без превращения личной истории в бесконтрольный profile.

Типовая память:

user preferences;
long-term goals;
recurring routines;
contacts or entities;
current session context;
explicit user corrections.

Минимальный стек:

Слой	Выбор
Profile memory	Simple DB or memory framework
Session memory	KV/session store
Retrieval	Lightweight semantic search
User control	Memory view/edit/delete UI
Safety	Consent, sensitive data filters
Observability	Basic traces and correction logs

Когда усложнять:

много devices;
сложные permissions;
shared household/work contexts;
много long-term goals;
нужна интеграция с calendar/email/docs;
строгие privacy requirements.

Главный риск: over-personalization. Ассистент не должен использовать память там, где она неуместна.

Coding agent

Цель: помнить project conventions, прошлые решения и useful episodes, но всегда проверять актуальное состояние репозитория.

Типовая память:

project instructions;
coding conventions;
commands that worked;
failed attempts;
architecture decisions;
recurring bugs;
tool usage patterns;
user preferences for final reports.

Минимальный стек:

Слой	Выбор
Project memory	Markdown/SQLite/custom store
Source of truth	Files and git state
Retrieval	Code search + semantic search
Episodic logs	Structured tool traces
Procedural memory	Playbooks/conventions
Observability	Command traces and diffs

Ключевой принцип:

Current repository state beats old memory.

Когда нужна vector DB:

большая кодовая база;
нужно искать похожие past fixes;
есть много docs/issues/PRs;
semantic code search полезен.

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

сложные dependencies;
service map;
ownership graph;
architecture relationships.

Главный риск: агент применяет старую memory к новому состоянию кода.

Customer support agent

Цель: отвечать с учетом customer context, product docs и похожих cases, не раскрывая чужие данные.

Типовая память:

current customer profile;
plan and entitlements;
past tickets;
known issues;
product docs;
support playbooks;
conversation state.

Минимальный стек:

Слой	Выбор
Customer context	CRM/helpdesk connector
Docs retrieval	RAG framework + search/vector
Similar tickets	Vector/hybrid search
Permissions	Tenant filters and identity
Conversation memory	Session store
Audit	Structured logs

Когда усложнять:

enterprise customers;
strict compliance;
many integrations;
multilingual support;
complex entitlement logic;
regulated data.

Главный риск: cross-customer leakage. В support agent безопасность retrieval важнее максимального recall.

Research agent

Цель: помогать искать, читать, сравнивать и синтезировать источники.

Типовая память:

search history;
read sources;
extracted claims;
citations;
unresolved questions;
research plan;
user preferences for depth and format.

Минимальный стек:

Слой	Выбор
Source corpus	Files/DB/document store
Retrieval	RAG framework
Citations	Source metadata
Notes	Markdown/structured DB
Claim tracking	Tables or graph
Observability	Source traces

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

много authors/entities/concepts;
нужно связывать claims;
нужно видеть contradictions;
research длится долго;
важна provenance.

Главный риск: agent confuses notes with verified facts. Research memory должна хранить uncertainty и source quality.

Voice agent

Цель: быстро реагировать в реальном времени, сохраняя полезный context.

Типовая память:

current conversation state;
user profile;
recent intents;
short-lived slots;
preferences;
task progress;
handoff notes.

Минимальный стек:

Слой	Выбор
Session memory	In-memory/KV store
User profile	Low-latency DB/cache
Retrieval	Prefetch or async retrieval
Long-term writes	Async pipeline
Observability	Latency traces
Safety	Consent and redaction

Voice memory отличается жестким latency budget. Если retrieval тормозит ответ, нужно:

prefetch;
cache;
summarize;
defer long-term writes;
separate real-time state from background memory.

Главный риск: дорогой retrieval в critical path делает агента неудобным.

Enterprise agent

Цель: работать с corporate knowledge, permissions, audit и compliance.

Типовая память:

documents;
policies;
employee/customer records;
tickets;
project history;
decisions;
access-controlled sources;
audit trails.

Минимальный стек для серьезного enterprise use case:

Слой	Выбор
Source connectors	Enterprise context platform/connectors
Identity	SSO/IAM integration
Retrieval	Hybrid search/RAG
Permissions	Source-level filters
Audit	Immutable logs
Retention	Policy-driven lifecycle
Observability	Dashboards and alerts

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

org relationships;
customer/account hierarchies;
service dependencies;
policy dependencies;
knowledge graph already exists.

Главный риск: memory bypasses existing access controls. Enterprise agent должен уважать source permissions, а не создавать параллельный бесконтрольный индекс.

Multi-agent workflow

Цель: несколько агентов работают над общей задачей и используют shared memory без хаоса.

Типовая память:

shared task state;
agent roles;
handoff notes;
decisions;
artifacts;
constraints;
work history;
conflict resolution records.

Минимальный стек:

Слой	Выбор
Workflow state	Agent framework/state graph
Shared memory	Structured DB
Artifacts	File/object store
Retrieval	Search/vector if corpus grows
Coordination	Event log
Policies	Role-based access and write rules
Observability	Multi-agent traces

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

много agents;
сложные dependencies;
tasks depend on entities and relationships;
нужно reason about ownership and handoffs.

Главный риск: shared memory становится мусорной доской. Нужны schemas, write policies и cleanup.

Практические стартовые стеки

Ниже не "лучшие стеки", а разумные starting points.

Сценарий	Starting stack
Local writing assistant	Files + SQLite + simple logs
Personal assistant prototype	Memory framework + KV session store + user memory UI
Coding agent	Repo files + git + SQLite/Markdown project memory + code search
Support copilot	CRM connector + docs RAG + hybrid search + tenant filters
Research agent	RAG framework + source metadata + notes DB + citation traces
Voice agent	Low-latency session store + profile cache + async memory writes
Enterprise knowledge agent	Enterprise connectors + IAM + hybrid retrieval + audit + retention
Multi-agent workflow	Agent framework + shared DB + event log + observability

Начинать можно скромно. Главное - чтобы выбранный stack явно закрывал key risks.

Анти-паттерн: выбор по популярности

Плохой процесс:

1. Увидели популярный инструмент.
2. Решили, что он "делает память".
3. Подогнали архитектуру под него.
4. Позже обнаружили gaps: deletion, permissions, freshness, evals.

Хороший процесс:

1. Описали user scenarios.
2. Выделили memory types.
3. Определили data shape and risks.
4. Выбрали minimum viable stack.
5. Проверили на metrics and scenario tests.
6. Добавили сложность только там, где baseline не хватает.

Инструмент должен обслуживать архитектуру, а не диктовать ее.

Вопросы перед выбором инструмента

Перед тем как добавить новый компонент, спросите:

Какую конкретную responsibility он закрывает?
Какой failure mode он уменьшает?
Какие новые failure modes он добавляет?
Как мы будем тестировать его вклад?
Как он поддерживает deletion?
Как он работает с permissions?
Как он влияет на latency?
Как он влияет на cost?
Кто будет его обслуживать?
Можно ли начать проще?

Если на эти вопросы нет ответов, инструмент добавлен слишком рано.

Мини-кейс: маленький курс-агент

Задача: агент помогает писать Markdown-лекции в одном репозитории.

Память нужна для:

структуры лекций;
стиля курса;
уже написанных модулей;
cross-references;
пользовательских preferences;
final response style.

Достаточный стартовый стек:

Files as source of truth
Markdown lesson plans
Git status
Local search with rg
Light procedural memory in instructions
Structured final checks

Vector DB здесь не обязательна. Graph DB тоже. Memory framework может быть полезен позже, но сначала хватает ясного процесса и чтения локального контекста.

Мини-кейс: support agent в SaaS

Задача: агент помогает support team отвечать customer questions.

Память нужна для:

customer plan;
past tickets;
product docs;
known incidents;
support playbooks;
current conversation.

Более подходящий стек:

CRM/helpdesk connector
Docs ingestion pipeline
Hybrid retrieval
Tenant-scoped metadata filters
Conversation session store
Audit logs
Human review for risky answers

Здесь простые files уже не хватят, потому что есть permissions, many customers, stale docs and audit.

Мини-кейс: research agent

Задача: агент собирает обзор по теме и обновляет его неделю за неделей.

Память нужна для:

прочитанных источников;
extracted claims;
disagreements between sources;
citation graph;
open questions;
synthesis history.

Возможный стек:

RAG framework
Document/source store
Vector search for passages
Structured claim table
Optional graph layer for entities and claims
Citation-aware context assembly
Evaluation rubric for grounding

Если research short-lived, graph можно отложить. Если research превращается в knowledge base, graph становится полезнее.

Как развивать стек по этапам

Этап 1: prototype.

files/SQLite;
simple session memory;
manual policies;
basic logs;
small golden dataset.

Этап 2: product pilot.

structured memory records;
vector or hybrid retrieval;
user/project scopes;
deletion flow;
traces;
regression tests.

Этап 3: production.

robust indexing;
reranking;
audit;
monitoring;
async job reliability;
privacy reviews;
A/B tests;
human evaluation.

Этап 4: enterprise scale.

IAM integration;
source-level permissions;
retention policy;
legal/compliance workflows;
multi-tenant isolation;
advanced observability;
governance dashboards.

Такой growth path помогает не строить enterprise complexity до появления enterprise risk.

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

Ошибка 1: начинать с самого сложного stack.

Сложность съедает скорость, а качество памяти еще не проверено.

Ошибка 2: игнорировать source of truth.

Для coding agent это файлы, для support agent - CRM/docs, для enterprise - authorized sources.

Ошибка 3: выбирать vector DB без metadata strategy.

Semantic search без scopes и freshness опасен.

Ошибка 4: добавлять graph layer без graph questions.

Если нет multi-hop relationship questions, graph может быть лишним.

Ошибка 5: забывать latency budget.

Особенно для voice and interactive agents.

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

Если стек не умеет удалять memory из indexes, summaries and caches, он не готов.

Ошибка 7: не иметь observability.

Без traces невозможно понять, почему агент использовал плохую memory.

Ошибка 8: покупать platform вместо определения policies.

Ни один инструмент не знает автоматически, что вашему продукту разрешено помнить.

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

Выбор memory stack должен идти от задачи, data shape, privacy, latency, масштаба и операционных требований. Для малых проектов часто достаточно файлов, SQLite и дисциплинированного процесса. Vector DB нужна для semantic retrieval, search engine - для exact/hybrid search, graph layer - для отношений, memory framework - для ускорения user/session memory, enterprise stack - для governance.

Главная мысль: лучший стек не самый модный, а самый маленький стек, который надежно закрывает нужные сценарии и риски.

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

Какие признаки говорят, что проекту уже нужна vector DB?
Когда graph layer оправдан, а когда он добавляет лишнюю сложность?
Почему coding agent должен считать текущие файлы source of truth?
Какие требования делают enterprise memory stack принципиально сложнее?
Почему выбор по популярности является анти-паттерном?

Что дальше

В следующей лекции мы начнем глубокий разбор dedicated memory frameworks с Mem0: посмотрим, как устроен слой персонализации, атомарные memory records, hybrid retrieval и управление изменяющимися предпочтениями пользователя.