Урок 5.1. Простые паттерны памяти

Цель лекции

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

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

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

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

После Module 04 легко решить, что memory system нужно сразу строить как сложную комбинацию SQL, vector DB, graph, cache, object storage, scopes, policies и consolidation.

Иногда это правда. Но часто первая версия агента не требует сложной архитектуры.

Если агент решает короткие задачи, работает с одним пользователем, не хранит sensitive data и не обязан помнить месяцы истории, простой паттерн может быть лучше:

быстрее запустить;
легче отладить;
проще объяснить пользователю;
меньше surface area для privacy ошибок;
меньше инфраструктуры;
дешевле поддерживать.

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

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

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

Простые паттерны памяти полезны, если понимать их границы.

Они отвечают на разные уровни зрелости:

no memory: агент не сохраняет состояние;
conversation buffer: агент видит последние сообщения;
summary memory: агент хранит сжатую историю;
profile memory: агент помнит устойчивые сведения о пользователе;
RAG-only memory: агент ищет по документам;
local file memory: память живет в Markdown/JSON/YAML;
SQLite memory: локальная структурированная память для одного пользователя или проекта.

Ни один из этих паттернов не является "плохим". Плохим он становится, когда его используют не по масштабу задачи.

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

Термин	Короткое определение
`No memory`	Одноразовый вызов модели без сохраненного состояния.
`Conversation buffer`	Хранение последних сообщений диалога.
`Summary memory`	Сжатое резюме предыдущей части беседы или задачи.
`Profile memory`	Устойчивый профиль пользователя или проекта.
`RAG-only memory`	Поиск по внешним документам без персональной или эпизодической памяти.
`Local file memory`	Память в файлах: Markdown, JSON, YAML.
`SQLite memory`	Локальная структурированная память в lightweight SQL базе.
`MVP memory`	Минимальная память, достаточная для первой версии сценария.
`Migration path`	Путь перехода от простого паттерна к более зрелой архитектуре.

Карта простых паттернов

Паттерн	Когда подходит	Где ломается
No memory	Одноразовые задачи, pure Q&A, stateless API	Нет continuity и персонализации.
Conversation buffer	Короткие диалоги, support chat, простые assistants	Длинные сессии, token cost, lost context.
Summary memory	Длинные диалоги, handoff, low-cost continuity	Summarization drift, потеря source.
Profile memory	Персонализация, preferences, user settings	Privacy, staleness, scope conflicts.
RAG-only	Docs Q&A, enterprise search, support docs	Нет опыта агента и user state.
Local files	Coding agents, project conventions, small teams	Concurrency, permissions, scale.
SQLite	Local agents, single-user tools, prototypes	Multi-tenant, distributed access, heavy retrieval.

No memory

No memory - это stateless-паттерн: каждый запрос обрабатывается независимо.

User input -> LLM -> Response

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

одноразовых вопросов;
simple transformations;
перевода короткого текста;
генерации независимых snippets;
задач, где контекст полностью в prompt;
privacy-sensitive сценариев, где сохранение нежелательно.

Плюсы:

простота;
низкий privacy risk;
легко тестировать;
нет lifecycle, update и deletion;
предсказуемое поведение.

Минусы:

нет continuity;
пользователь повторяет контекст;
нет learning from feedback;
нет personalization;
нет memory-based planning;
длинные задачи неудобны.

No memory не является провалом. Иногда это правильный дизайн: если пользователь ожидает одноразовую операцию, сохранение памяти может быть лишним.

Conversation buffer

Conversation buffer хранит последние N сообщений и передает их модели.

System prompt
+ last N messages
+ current user request
-> LLM

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

коротких чат-сессий;
support conversations;
interactive writing;
simple coding help;
голосовых ассистентов с коротким turn history.

Плюсы:

легко реализовать;
сохраняет локальный контекст;
не требует отдельного extraction;
хорошо работает для коротких диалогов;
прозрачно: модель видит реальные сообщения.

Минусы:

token cost растет;
старые сообщения выпадают;
нет устойчивого user profile;
нет structured update;
sensitive data может оставаться в истории;
нет различия между важным и шумом.

Conversation buffer - это session memory, а не long-term memory.

Summary memory

Summary memory сжимает старую часть диалога в краткое резюме.

Rolling summary
+ last N messages
+ current request
-> LLM

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

длинных диалогов;
многошаговых задач;
handoff между агентами;
customer support;
writing sessions;
coding tasks с несколькими итерациями.

Плюсы:

экономит context window;
сохраняет continuity;
снижает token cost;
удобно передавать между процессами;
можно обновлять после важных steps.

Минусы:

summarization drift;
потеря source attribution;
факты и гипотезы могут смешаться;
summary может устареть;
пользовательские correction могут не попасть в резюме;
сложно удалить конкретный фрагмент.

Хороший summary должен отличать:

подтвержденные факты;
текущий план;
открытые вопросы;
временные constraints;
uncertain hypotheses.

Плохой summary превращает историю в уверенный, но неточный пересказ.

Profile memory

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

Пример:

User profile:
- Prefers concise final reports.
- Uses Russian for this course.
- Wants technical Markdown lectures with diagrams and self-check questions.

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

personalization;
writing assistants;
personal assistants;
developer tools;
повторяющихся workflows;
preferences и settings.

Плюсы:

улучшает continuity между сессиями;
снижает необходимость повторять инструкции;
хорошо работает с явными preferences;
можно хранить в простой JSON/SQL форме.

Минусы:

privacy risk;
staleness;
scope errors;
overgeneralization;
требуется user control;
сложно отличить временную просьбу от постоянной.

Profile memory должна быть conservative. Лучше сохранить меньше, но точнее, чем превратить каждую реплику в характеристику пользователя.

RAG-only memory

RAG-only memory дает агенту доступ к внешним документам, но не хранит персональное состояние агента.

User question -> search docs -> retrieved chunks -> answer

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

documentation Q&A;
internal knowledge search;
help center bots;
policy lookup;
coding agents, которые читают repo/docs;
research assistants с source grounding.

Плюсы:

grounded answers;
source attribution;
не требует personal memory;
легко объяснить пользователю;
хорош для world memory.

Минусы:

не помнит пользователя;
не хранит прошлые actions;
не учится на failures;
не управляет preferences;
не хранит procedural/reflection memory;
source freshness и permissions всё равно сложны.

RAG-only часто называют "memory", но это только external knowledge retrieval. Для agent memory его обычно нужно комбинировать с user/project/session/procedural memory.

Local file memory

Local file memory хранит инструкции, факты или состояние в файлах.

Примеры:

AGENTS.md;
CLAUDE.md;
README.md;
memory.md;
project_notes.md;
profile.json;
workflow.yaml;
decisions.md.

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

coding agents;
project-specific memory;
small teams;
documentation-first workflows;
human-reviewed conventions;
локальных ассистентов.

Плюсы:

прозрачно для человека;
легко редактировать;
хорошо работает с git;
нет отдельной инфраструктуры;
удобно для declarative memory;
отлично подходит для project instructions.

Минусы:

нет fine-grained permissions;
сложная concurrent editing;
нет built-in retrieval;
трудно масштабировать;
легко получить устаревшие инструкции;
нет строгой schema, если не договориться.

Local file memory сильна там, где память должна быть частью проекта и проходить human review.

SQLite memory

SQLite memory - простой вариант структурированной локальной памяти.

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

single-user desktop agents;
локальных developer agents;
небольших prototypes;
offline tools;
structured facts/events;
simple audit logs.

Плюсы:

SQL queries;
транзакции;
один файл;
легко переносить;
можно хранить structured records;
можно добавить FTS для keyword search;
можно комбинировать с local files.

Минусы:

не рассчитана на сложный multi-tenant;
distributed access сложен;
semantic search требует отдельного слоя;
permissions нужно проектировать самому;
concurrent writes ограничены.

SQLite часто хороший шаг между "JSON file" и полноценной backend database.

Минимальная архитектура для MVP

Пример практичного MVP для writing/coding agent:

flowchart TD U[User request] --> C[Conversation buffer] C --> P[Project files: AGENTS.md / README / plans] P --> S[Short profile memory] S --> L[LLM] L --> A[Answer / file edits] A --> M[Update local summary or profile if needed]

Хранилища:

conversation buffer в runtime;
project memory в files;
небольшие preferences в JSON или SQLite;
docs retrieval через local search;
no long-term event log на старте, если он не нужен.

Такой MVP достаточно прост, но уже разделяет session, project и profile memory.

Когда простых паттернов достаточно

Простого паттерна достаточно, если:

один пользователь или малая команда;
мало sensitive data;
нет сложного compliance;
задачи короткие;
нет многомесячной continuity;
нет multi-agent coordination;
объем документов небольшой;
качество можно контролировать вручную;
потеря памяти не критична;
retrieval не требует сложного ranking.

Пример: локальный ассистент для написания курса может долго жить на files + conversation summaries + project conventions. Ему не обязательно сразу нужна распределенная memory platform.

Где простые паттерны ломаются

Признаки, что пора усложнять архитектуру:

появились тысячи пользователей;
memory leaks стали privacy risk;
один profile конфликтует с другим;
retrieval возвращает много шума;
summaries начали искажать факты;
нужно удалять пользовательские данные;
появились разные scopes: user, project, org;
нужно хранить audit trail;
требуется source attribution;
нужна синхронизация между агентами;
latency и cost стали заметными;
один vector store уже не объясняет связи.

Когда появляются эти признаки, нужно переходить к patterns из следующих лекций: tiered memory, OS-style context management, hybrid vector-graph memory, event sourcing и declarative memory governance.

Migration path

Переход от простого паттерна лучше планировать заранее.

Пример эволюции:

No memory
-> conversation buffer
-> rolling summary
-> JSON user profile
-> SQLite memory records
-> SQL + vector index
-> tiered memory with scopes, update and deletion

Важно не ждать, пока память станет неуправляемой. Даже в MVP полезно с самого начала хранить:

type;
scope;
source;
timestamps;
status;
confidence.

Тогда миграция будет переносом данных, а не археологией по старым blobs.

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

Ошибка 1: начинать со слишком сложной архитектуры.

Если задача простая, большая memory platform замедлит разработку и создаст лишние failure modes.

Ошибка 2: оставаться на MVP-паттерне после роста продукта.

Conversation buffer не должен становиться единственной памятью enterprise assistant.

Ошибка 3: считать summary надежным source of truth.

Summary удобен, но может терять детали и искажать историю.

Ошибка 4: смешивать profile memory и session memory.

Временная просьба не всегда является постоянным предпочтением.

Ошибка 5: называть RAG-only полноценной памятью агента.

RAG дает доступ к documents, но не хранит experience, preferences и procedures.

Ошибка 6: хранить local files без ownership.

Если инструкции устарели, агент будет дисциплинированно выполнять неправильные правила.

Ошибка 7: не проектировать migration path.

Даже простой pattern должен иметь путь к structured records и scopes.

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

Простые паттерны памяти - хороший старт: no memory, conversation buffer, summary memory, profile memory, RAG-only, local file memory и SQLite memory.

Их сила в простоте. Их слабость в росте: scope, privacy, retrieval noise, update, deletion, multi-user и audit requirements быстро требуют более зрелой архитектуры.

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

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

Когда no memory является правильным design choice?
Чем conversation buffer отличается от long-term memory?
Почему summary memory может дрейфовать?
Почему RAG-only не равен полноценной agent memory?
Какие признаки показывают, что простой паттерн пора усложнять?

Что дальше

В следующей лекции мы разберем Tiered Memory: как разделять память на hot, warm и cold layers, чтобы управлять стоимостью, задержками и объемом контекста.