Урок 6.1. Компоненты memory layer

Цель лекции

Собрать все понятия в общую системную архитектуру зрелого слоя памяти.

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

Читатель получает системную карту компонентов, из которых можно собрать memory architecture: router, extractor, policy engine, store adapters, indexer, retriever, reranker, context assembler, consolidator, auditor и user controls.

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

В предыдущих модулях мы разобрали типы памяти, lifecycle, storage, representation, scopes и архитектурные паттерны. Теперь нужно собрать эти идеи в одну инженерную систему.

Memory layer - это не одна таблица, не один vector store и не один prompt block.

Зрелый memory layer должен уметь:

• принять наблюдение;
• понять, относится ли оно к памяти;
• определить тип и scope;
• проверить политики;
• сохранить запись;
• построить индексы;
• найти релевантные записи;
• отранжировать кандидатов;
• собрать компактный context;
• обновить или забыть старые записи;
• объяснить, почему память была использована;
• дать пользователю контроль.

Если эти обязанности смешаны в одном prompt или одном сервисе без ясных границ, систему трудно тестировать, отлаживать и безопасно развивать.

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

Memory layer состоит из маршрутизации, extraction, policy engine, storage, indexing, retrieval, context assembly, consolidation и аудита.

Его можно представить как middleware между agent loop и хранилищами памяти.

Agent loop не должен напрямую знать:

• в какой таблице лежат preferences;
• какой индекс использовать для episodes;
• как проверять PII;
• какие scopes разрешены;
• как объединять vector и keyword search;
• какие memories можно вставлять в prompt;
• как обновлять stale facts.

Этим занимается memory layer.

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

Общая схема

Эта схема не означает, что все компоненты должны быть отдельными микросервисами. В MVP часть логики может быть функциями в одном приложении. Но архитектурные роли полезно различать с самого начала.

Memory router

Memory router решает, что делать с входом.

Примеры решений:

• это user message, tool result или document update;
• нужен read path или write path;
• какие memory types затронуты;
• какой scope активен;
• какие policies применить;
• нужно ли обращаться к world memory;
• нужно ли запускать async process;
• нужно ли user confirmation.

Пример:

Input:
"Запомни, что для этого проекта финальные отчеты должны быть короткими."

Router:
- route to write pipeline
- candidate type: semantic preference / procedural style rule
- scope: current project + user
- require source: direct user instruction

Router предотвращает хаос: не каждое наблюдение должно идти во все компоненты.

Extractor

Extractor превращает raw input в structured candidates.

Он может выделять:

• atomic facts;
• episodic events;
• entities;
• relations;
• preferences;
• procedures;
• policy candidates;
• reflection lessons;
• metadata;
• PII/secrets candidates.

Пример:

Raw:
"Мы перешли с Jest на Vitest. Для Markdown-правок тесты не нужны."

Extracted:
- semantic fact: project uses Vitest
- supersedes candidate: project uses Jest
- procedural rule: no tests for Markdown-only edits
- scope: current project

Extractor не должен сам решать, что окончательно сохранить. Он подготавливает candidates для policy engine.

Policy engine

Policy engine применяет правила памяти.

Основные вопросы:

• можно ли сохранить эту запись;
• можно ли читать эту память в текущем scope;
• не содержит ли запись sensitive data;
• нужен ли consent;
• какой retention;
• какой priority;
• как обрабатывать conflict;
• кто может update/delete;
• можно ли inject в prompt.

Policy engine - safety boundary memory layer.

Без него agent может:

• сохранить secrets;
• прочитать данные другого tenant;
• использовать stale fact;
• записать temporary session note как permanent profile;
• вставить private memory в shared context.

Store adapters

Store adapters скрывают детали хранилищ.

Примеры:

• SQL adapter для structured facts и permissions;
• file adapter для declarative memory;
• vector adapter для embeddings;
• search adapter для BM25;
• graph adapter для entities;
• object adapter для raw artifacts;
• KV adapter для session state.

Задача adapter:

• читать и писать records;
• сохранять metadata;
• поддерживать update/delete semantics;
• применять scope filters;
• возвращать canonical ids;
• обеспечивать consistency с indexes.

Agent loop не должен работать напрямую с каждым storage. Это делает memory layer менее хрупким.

Indexer

Indexer делает записи доступными для retrieval.

Он может строить:

• embeddings;
• keyword/full-text index;
• graph edges;
• temporal indexes;
• metadata indexes;
• entity aliases;
• summary indexes.

Indexer должен реагировать на:

• create;
• update;
• supersede;
• archive;
• delete;
• permission change;
• source update.

Ошибка: сохранить запись в SQL, но забыть удалить ее embedding после deletion. Поэтому indexer - часть lifecycle, а не optional optimization.

Retriever

Retriever ищет candidates под текущую задачу.

Он учитывает:

• read policy;
• user/project/session scopes;
• memory type;
• query construction;
• vector search;
• keyword search;
• graph search;
• temporal search;
• permissions;
• freshness.

Retriever не обязан возвращать final context. Он возвращает candidate pool.

Пример:

Task:
"Напиши лекцию 6.2."

Retriever:
- target lesson plan
- content plan section
- style patterns from neighboring lectures
- project writing rules
- user final-answer preference

Reranker

Reranker выбирает самые полезные candidates.

Он учитывает:

• relevance;
• scope match;
• source authority;
• confidence;
• recency;
• importance;
• novelty;
• conflict status;
• context cost;
• diversity;
• current plan step.

Первичный retrieval часто возвращает много похожего. Reranker отвечает за вопрос:

Что действительно стоит вставить в prompt?

Reranker может быть rule-based, model-based или гибридным.

Context assembler

Context assembler превращает selected memories в prompt-ready context.

Он решает:

• какие группы памяти показать;
• в каком порядке;
• как кратко сформулировать;
• какие source labels добавить;
• как отделить policies от facts;
• как показать uncertainty;
• что не inject;
• как уложиться в token budget.

Пример:

Relevant project memory:
- Course is written in Russian.
- Full lectures use terms, diagrams, examples, mistakes, summary and self-check questions.

Relevant instruction:
- Do not update TODO unless requested.

Context assembler - последний защитный слой перед моделью.

Consolidator

Consolidator поддерживает качество памяти во времени.

Он выполняет:

• episodic-to-semantic distillation;
• rolling summaries;
• duplicate merge;
• contradiction detection;
• confidence updates;
• stale marking;
• promotion/demotion;
• archive decisions;
• reflection consolidation.

Consolidator часто работает асинхронно. Он не обязан замедлять пользовательский ответ.

Auditor

Auditor помогает объяснить память.

Вопросы:

• почему эта запись была сохранена;
• откуда она взялась;
• почему она попала в prompt;
• какие sources использовались;
• какие policies применились;
• были ли conflicts;
• кто обновил или удалил запись;
• почему запись имеет такой confidence.

Audit нужен для:

• debugging;
• trust;
• compliance;
• user controls;
• memory quality evaluation;
• security investigations.

User controls

Пользователь должен иметь контроль над memory.

User controls могут включать:

• показать сохраненную память;
• исправить запись;
• удалить запись;
• отключить память;
• ограничить scopes;
• одобрить сохранение sensitive data;
• экспортировать память;
• посмотреть, почему память использована.

Память без user controls выглядит как скрытый механизм наблюдения. Для продукта это риск доверия.

Read и write pipelines

Write pipeline:
Observation
  -> Router
  -> Extractor
  -> Policy engine
  -> Store adapter
  -> Indexer
  -> Audit

Read pipeline:
Current task
  -> Router
  -> Read policy
  -> Retriever
  -> Reranker
  -> Context assembler
  -> LLM
  -> Audit

Разделение read/write pipelines помогает тестировать систему. Можно отдельно оценивать write quality, retrieval quality и prompt quality.

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

Задача:

"Напиши лекцию 6.1."

Memory router:

• read path for project context;
• read target lesson plan;
• read neighboring content;
• no TODO update unless requested.

Retriever:

• content plan section;
• target lesson file;
• previous module conclusion;
• writing conventions.

Reranker:

• prioritize current lesson plan and Module 06 scope.

Context assembler:

• inject only compact project/writing context.

After writing:

• no long-term memory write needed unless user gives new preference or task outcome matters.

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

Запрос:

"Почему export недоступен у нашего аккаунта?"

Router:

• read account-scoped memory and world sources.

Policy engine:

• verify user has access to account data.

Retriever:

• CRM entitlement;
• docs for export feature;
• recent incidents;
• support history for same account.

Reranker:

• prioritize current CRM and official docs over old tickets.

Context assembler:

• include source labels and avoid private internal notes unless role permits.

Auditor:

• record which sources supported answer.

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

Ошибка 1: строить memory layer как один vector search call.

Retrieval - только один компонент.

Ошибка 2: смешивать extraction и policy.

Extractor может предложить запись, но policy должен решать, можно ли ее сохранять.

Ошибка 3: не иметь context assembler.

Даже хороший retrieval может испортить prompt, если вставить слишком много.

Ошибка 4: забывать index lifecycle.

Update/delete должны синхронизироваться с embeddings, search и graph indexes.

Ошибка 5: не строить audit.

Без audit трудно понять, почему агент вспомнил запись.

Ошибка 6: не давать пользователю control.

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

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

Memory layer - это системный слой, который управляет памятью агента через несколько компонентов: router, extractor, policy engine, store adapters, indexer, retriever, reranker, context assembler, consolidator, auditor и user controls.

Эти компоненты можно реализовать просто или сложно, но их роли полезно различать с самого начала. Так memory system становится тестируемой, безопасной и расширяемой.

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

1. Почему memory layer нельзя свести к хранилищу?
2. Чем extractor отличается от policy engine?
3. Зачем нужен reranker после retriever?
4. Почему context assembler является отдельным компонентом?
5. Какие задачи решает auditor?

Что дальше

В следующей лекции мы подробно разберем политики памяти: read, write, update, delete, retention, privacy, scope, conflict, injection и user override.