Урок 6.4. Асинхронные процессы памяти

Цель лекции

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

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

Читатель понимает, какие задачи памяти можно вынести в фоновые пайплайны: consolidation, summarization, batch embedding, re-indexing, conflict scan, PII scan, decay, archive jobs, human review queue и sleep-time compute.

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

Не вся работа с памятью должна происходить во время ответа пользователю.

Если agent loop на каждый запрос будет:

извлекать все факты;
обновлять summaries;
строить embeddings;
пересчитывать graph;
искать конфликты;
сканировать PII;
архивировать старые записи;
ждать human review;

то latency станет неприемлемой.

Некоторые операции нужны для качества памяти, но не обязаны блокировать текущий ответ. Их можно выполнять асинхронно:

после завершения задачи;
по расписанию;
batch jobs;
event-driven workers;
human review queues;
low-priority background compute.

Это делает memory layer быстрее на hot path и качественнее на long path.

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

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

Hot path:

User request -> retrieve enough context -> answer/action

Background path:

Events -> extract -> consolidate -> embed -> re-index -> scan -> archive -> review

Асинхронность не означает "неважно". Напротив, фоновые процессы часто отвечают за долгосрочное качество памяти. Но их нужно проектировать как надежные pipelines: с retries, idempotency, monitoring, permissions и audit.

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

Термин	Короткое определение
`Hot path`	Синхронный путь, который влияет на latency ответа пользователю.
`Background job`	Фоновая задача, выполняемая вне основного ответа.
`Consolidation job`	Фоновое обобщение событий и заметок в устойчивую память.
`Periodic summarization`	Регулярное обновление summaries.
`Batch embedding`	Построение embeddings пачками.
`Re-indexing`	Перестроение retrieval indexes после изменений.
`Conflict scan`	Поиск противоречий между memory records.
`PII scan`	Проверка памяти на персональные или sensitive данные.
`Decay job`	Снижение веса старых или редко используемых записей.
`Archive job`	Перенос записей из active memory в archive.
`Human review queue`	Очередь записей, требующих проверки человеком.
`Sleep-time compute`	Метафора фоновой обработки памяти между активными взаимодействиями.

Схема async memory pipeline

flowchart TD E[Events / memory writes] --> Q[Job queue] Q --> C[Consolidation worker] Q --> S[Summarization worker] Q --> B[Batch embedding worker] Q --> R[Re-indexing worker] Q --> P[PII / secrets scanner] Q --> F[Conflict scanner] Q --> D[Decay / archive worker] Q --> H[Human review queue] C --> M[(Memory store)] S --> M B --> I[(Indexes)] R --> I P --> M F --> M D --> M H --> M

Фоновые процессы читают события и записи, создают derived records, обновляют индексы, помечают риски и подготавливают память к будущему retrieval.

Что оставлять на hot path

На hot path стоит оставлять только то, что нужно для текущего ответа:

минимальный retrieval;
permission checks;
critical policy checks;
context assembly;
synchronous write для явного "запомни";
запись важных events;
blocking safety checks.

Пример:

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

Hot path:

проверить consent/policy;
сохранить preference;
подтвердить пользователю.

Async path:

построить embedding;
deduplicate с похожими preferences;
обновить profile summary;
проверить conflicts.

Background consolidation

Background consolidation обобщает сырые события.

Input:

recent episodes;
user corrections;
tool failures;
repeated tasks;
reflections;
summaries.

Output:

semantic facts;
scoped preferences;
procedural rules;
reflection lessons;
updated summaries;
stale markers.

Пример:

Episodes:
- Agent failed twice after ignoring dependent tests.
- User corrected final answer style.

Consolidation:
- Reflection: shared helper changes need dependent tests.
- Preference: final edit reports should be concise.

Consolidation не всегда должна быть immediate. Часто лучше выполнить ее после task completion, когда known outcome уже есть.

Periodic summarization

Periodic summarization поддерживает compact memory.

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

длинных conversations;
multi-step tasks;
support tickets;
coding sessions;
research projects;
multi-agent blackboards.

Фоновый summary может обновлять:

current task summary;
user profile summary;
project memory summary;
incident summary;
team handoff summary.

Риски:

summarization drift;
потеря source;
смешивание facts и hypotheses;
stale summary;
sensitive data leakage.

Поэтому summary должен иметь source/provenance и status.

Batch embedding

Embeddings можно строить пачками.

Почему batch:

дешевле;
меньше latency на user request;
можно дедуплицировать перед embedding;
можно chunk documents заранее;
можно использовать очередь retry;
можно обновлять index за пределами hot path.

Типичный flow:

Memory record created
-> enqueue embedding job
-> worker builds embedding
-> vector index updated
-> record marked index_status = ready

До готовности embedding запись может быть доступна через keyword/metadata search.

Re-indexing

Indexes нужно обновлять.

Причины:

record created;
record updated;
record superseded;
record deleted;
permissions changed;
chunking strategy changed;
embedding model changed;
graph entity linking improved;
source document updated.

Re-indexing может быть:

incremental;
scheduled;
full rebuild;
per-tenant;
per-project;
triggered by source update.

Важно: delete и permission changes должны обрабатываться особенно строго. Старые index entries не должны продолжать возвращать недоступные данные.

Conflict scan

Conflict scan ищет противоречия.

Примеры:

два active facts о test runner;
user preference без scope конфликтует с scoped correction;
old project memory противоречит current package file;
summary contradicts raw event;
two agents wrote different decisions.

Conflict scan может:

mark records as conflicted;
lower confidence;
create review task;
suggest scoped split;
ask user clarification;
update active view.

Некоторые conflicts видны сразу на hot path. Другие обнаруживаются только фоновым scan.

PII и secrets scan

Даже при write filtering sensitive data может попасть в память:

через tool logs;
через copied documents;
через user message;
через OCR/transcripts;
через summaries;
через imported data.

Фоновый scanner ищет:

API keys;
passwords;
tokens;
emails;
phone numbers;
addresses;
payment data;
health/legal/financial sensitive data;
customer identifiers.

Действия:

redact;
quarantine;
mark sensitive;
restrict scope;
require review;
delete if policy requires;
invalidate indexes/cache.

PII scan не заменяет pre-write filtering. Он дополнительная защита.

Memory decay jobs

Decay job снижает вес памяти.

Сигналы:

age;
last_used_at;
last_confirmed_at;
low confidence;
no successful reuse;
superseded source;
task closed;
low importance;
high staleness risk.

Результаты:

lower retrieval priority;
demote from warm to cold;
mark as stale;
schedule review;
archive.

Decay помогает active memory оставаться полезной.

Archive jobs

Archive jobs переносят записи из active memory в cold storage.

Кандидаты:

closed task state;
old raw tool logs;
superseded facts;
expired session memory;
old events replaced by summary;
stale reflections;
inactive document chunks.

Archive job должен учитывать:

retention policy;
deletion requests;
permissions;
source links;
derived records;
audit requirements.

Archive не равен delete. Архивные данные всё еще требуют access control.

Human review queue

Не все решения можно автоматизировать.

В human review queue попадают:

high-impact conflicts;
uncertain extracted facts;
policy changes;
sensitive memory candidates;
potential memory poisoning;
user corrections with broad scope;
low-confidence consolidation;
organization-wide rules.

Пример:

Candidate memory:
- "For all customers, export requires Enterprise plan."

Issue:
- Source is one support ticket, not canonical docs.

Action:
- Send to human review before making organization fact.

Human review queue превращает memory system из самовольного "обучения" в governance process.

Sleep-time compute

Sleep-time compute - полезная метафора: агент может улучшать память между активными взаимодействиями.

Во время "сна" система:

сжимает эпизоды;
обновляет summaries;
строит embeddings;
ищет conflicts;
проверяет freshness;
архивирует task state;
готовит suggestions для human review.

Важно: это не мистическое самоулучшение. Это обычные фоновые jobs с понятными inputs, outputs и policies.

Надежность фоновых процессов

Async jobs тоже должны быть инженерно надежными.

Требования:

idempotency;
retries;
dead-letter queue;
monitoring;
audit logs;
job versioning;
permission-aware processing;
backpressure;
partial failure handling;
safe reprocessing.

Пример:

Embedding job can run twice without creating duplicate index entries.

Если фоновые процессы ненадежны, memory layer будет постепенно деградировать.

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

После написания нескольких лекций:

Hot path:

написать текущую лекцию;
кратко ответить пользователю.

Async:

update module summary;
extract repeated writing conventions;
check if any lesson plan bullet was missed;
index new lecture for future retrieval;
mark task progress summary;
scan for accidental TODO/FIXME markers.

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

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

После customer support диалога:

Hot path:

ответить на вопрос;
использовать current CRM/docs;
соблюдать privacy.

Async:

summarize ticket;
update account memory;
scan for PII in notes;
detect conflict with existing account facts;
embed new support article;
archive closed conversation;
send risky promise to human review.

Так система держит user-facing latency низкой, но улучшает long-term memory.

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

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

Пользовательский ответ становится медленным.

Ошибка 2: делать все операции асинхронными.

Critical memory writes и safety checks могут не успеть повлиять на текущую задачу.

Ошибка 3: не мониторить background jobs.

Тихо сломавшийся indexer превращает retrieval в хаос.

Ошибка 4: не делать jobs идемпотентными.

Retries создают дубли и inconsistent indexes.

Ошибка 5: забывать permissions в async processing.

Фоновый job не должен расширять доступ к sensitive memory.

Ошибка 6: считать summaries безошибочными.

Periodic summarization требует provenance и drift checks.

Ошибка 7: не инвалидировать cache и indexes после delete.

Deleted data может продолжить всплывать.

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

Асинхронные процессы памяти улучшают качество memory layer без увеличения latency основного ответа. В фон можно выносить consolidation, summarization, batch embedding, re-indexing, conflict scans, PII scans, decay, archive jobs и human review.

При этом async не означает "без контроля". Фоновые процессы требуют policies, idempotency, retries, monitoring, audit, permission awareness и clear outputs.

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

Какие memory operations должны оставаться на hot path?
Почему embeddings часто лучше строить batch job'ом?
Чем PII scan отличается от pre-write filtering?
Почему archive job не равен delete?
Зачем background jobs должны быть идемпотентными?

Что дальше

Module 06 собрал memory layer как систему: компоненты, политики, context assembly и фоновые процессы. В следующем модуле мы перейдем к failure modes: как memory systems ломаются, почему возникает retrieval noise, stale memory, context rot, memory poisoning и privacy leaks, и как проектировать защиту заранее.