Урок 3.4. Memory Update, Consolidation и Forgetting

Цель лекции

Объяснить, как память обновляется, сжимается, устаревает и удаляется.

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

Читатель понимает, что память без обновления быстро превращается в источник ошибок, и умеет объяснить consolidation, episodic-to-semantic distillation, rolling summaries, contradiction detection, versioning, memory decay, TTL, archive, delete и human-in-the-loop correction.

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

В предыдущих лекциях Module 03 мы разобрали lifecycle, запись и retrieval. Но memory layer не заканчивается после успешного поиска.

Память живет во времени:

• пользователь меняет предпочтения;
• проект переходит на новый стек;
• документы обновляются;
• старые эпизоды теряют важность;
• временные session facts истекают;
• ошибки анализируются и превращаются в lessons learned;
• несколько похожих событий обобщаются в устойчивое правило;
• пользователь просит удалить сохраненные сведения.

Если память только добавляет новые записи и никогда не обновляется, она становится архивом противоречий. Агент может одновременно "помнить", что проект использует Jest и Vitest, что пользователь любит подробные ответы и краткие финалы, что policy разрешает и запрещает одно и то же действие.

Поэтому memory layer должен уметь менять активную память: уточнять, объединять, версионировать, снижать вес, архивировать и забывать.

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

Память должна эволюционировать.

Memory update отвечает за изменение существующих записей. Consolidation сжимает сырые наблюдения в более устойчивые знания. Forgetting убирает из активного слоя то, что больше не должно влиять на поведение агента.

Это не housekeeping после основной работы. Это центральная часть качества памяти.

Без update память устаревает.

Без consolidation память тонет в эпизодах.

Без forgetting память становится шумной и небезопасной.

Хорошая система памяти поддерживает active view: набор записей, которые сейчас считаются применимыми. Исторические записи могут оставаться в audit log или archive, но не должны автоматически попадать в context assembly.

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

Схема update lifecycle

Схема показывает, что update, consolidation и forgetting связаны. Новая информация может подтвердить старую запись, конфликтовать с ней, породить summary или вытеснить старую запись из active memory.

Что значит обновить память

Обновление не всегда означает "перезаписать текст".

Возможные операции:

• изменить status: active, superseded, stale, archived, deleted;
• повысить или снизить confidence;
• обновить last_confirmed_at;
• добавить source;
• уточнить scope;
• добавить relation к entity;
• создать новую версию;
• split запись на две scoped записи;
• merge дубли;
• заменить active fact;
• пометить conflict;
• применить TTL;
• удалить sensitive data.

Пример:

Old:
- User prefers detailed responses.
  scope: all tasks
  status: active

New:
- "Для финальных отчетов по правкам отвечай коротко, но объяснения архитектуры оставляй подробными."

Плохой update:

Add new memory:
- User prefers concise responses.

Теперь retrieval может вернуть два конфликтующих факта.

Лучший update:

Memory 1:
- User prefers detailed architectural explanations.
  scope: architecture_explanation
  status: active

Memory 2:
- User prefers concise final edit reports.
  scope: file_edit_final_response
  status: active

Old memory:
- User prefers detailed responses.
  status: superseded_by_scoped_preferences

Update часто заключается в уточнении scope, а не в выборе "старое или новое".

Consolidation

Consolidation превращает множество сырых записей в более устойчивое знание.

Сырые эпизоды:

Episode 1:
- User asked to write lesson 2.5 with table and diagram.

Episode 2:
- User asked to write lesson 2.6 in same Markdown lecture style.

Episode 3:
- User asked to write lesson 2.7 and accepted concise final report.

Consolidated memory:

Project writing pattern:
- Full lectures should include clear sections, key terms, visual explanation,
  examples, typical mistakes, summary and self-check questions.

User preference:
- Final reports after lecture edits should be concise.

Consolidation снижает шум. Вместо десятков эпизодов agent retrieves компактное правило или preference.

Но consolidation опасна, если делает слишком сильные выводы. Три эпизода могут показывать pattern, но не всегда universal rule. Поэтому consolidated memory должна иметь source, confidence и scope.

Episodic-to-semantic distillation

Episodic-to-semantic distillation - частный случай consolidation: события превращаются в факты или знания.

Пример:

Episodes:
- In task A, project tests used Vitest.
- In task B, package.json had vitest dependency.
- In task C, npm test ran vitest.

Distilled semantic fact:

Project uses Vitest as test runner.
source:
  - package.json
  - observed npm test output
confidence: high

Другой пример:

Episodes:
- User corrected agent twice when it updated TODO without being asked.
- Project instructions say todo files track workflow, not every edit.

Distilled procedural rule:

Do not update writing_todo.md unless the user explicitly asks to track progress.

Distillation должна быть cautious. Из одного события лучше создавать reflection или low-confidence hypothesis, а не high-confidence semantic fact.

Rolling summaries

Rolling summary используется для длинных диалогов, задач и сессий.

Вместо хранения всего transcript в active memory система поддерживает обновляемое резюме:

Current task summary:
- User is writing Module 03 of AI Agent Memory Guide.
- Lessons 3.1 and 3.2 are already expanded.
- Style: Russian technical Markdown, conceptual 101-level, diagrams and self-check questions.
- Do not update TODO unless requested.

Когда появляются новые события, summary обновляется.

Плюсы:

• экономит context window;
• поддерживает continuity;
• снижает retrieval noise;
• помогает handoff;
• удобно для session memory.

Риски:

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

Хороший rolling summary должен иметь ссылку на источники или хотя бы markers неопределенности.

Compaction

Compaction шире rolling summary. Это любое сжатие памяти.

Примеры compaction:

• 100 tool events -> task execution summary;
• 20 похожих user preferences -> 3 scoped preferences;
• 50 document chunks -> topic summary;
• длинный chat transcript -> session state;
• много failed attempts -> reflection lesson;
• series of facts -> entity profile.

Compaction нужен, когда:

• active memory слишком большая;
• retrieval возвращает дубли;
• context budget ограничен;
• старые детали редко нужны;
• нужно подготовить handoff;
• нужно перенести данные в cold storage.

Главный риск compaction - потеря auditability. Поэтому полезно хранить связь:

summary_record -> derived_from -> raw_events

Не всегда raw_events должны быть активными. Но для объяснимости и correction иногда нужно знать, откуда взялся summary.

Contradiction detection

Новая информация может противоречить старой памяти.

Примеры:

Old:
- Project uses Jest.

New:
- package.json contains Vitest and no Jest dependency.

Old:
- User prefers detailed final answers.

New:
- "Теперь финалы делай короткими."

Old:
- Feature export is available on Pro plan.

New:
- Current entitlement table says export requires Business plan.

Contradiction detection должна учитывать:

• subject и relation;
• scope;
• source;
• confidence;
• freshness;
• version;
• authority;
• temporal validity.

Не каждый конфликт является настоящим противоречием. Иногда scope разный:

User prefers detailed architecture explanations.
User prefers concise final edit reports.

Обе записи могут быть true, если scopes различаются.

Стратегии разрешения противоречий

Важно не оставлять конфликтующие active facts без статуса. Иначе retrieval может вернуть оба, а модель будет импровизировать.

Versioning

Versioning сохраняет историю изменений памяти.

Пример:

fact_project_test_runner
v1:
  value: Jest
  source: README
  status: superseded
  valid_until: 2026-07-20

v2:
  value: Vitest
  source: package.json
  status: active
  valid_from: 2026-07-20

Versioning полезен для:

• audit;
• debugging;
• historical questions;
• rollback;
• compliance;
• explanation;
• time-aware retrieval.

Но active context не должен получать все версии по умолчанию. Обычно retrieval должен выбирать active version, если пользователь не спрашивает историю.

Memory decay

Memory decay снижает вес записей со временем или при отсутствии использования.

Decay может учитывать:

• age;
• last_used_at;
• last_confirmed_at;
• confidence;
• importance;
• source quality;
• number of successful uses;
• staleness risk;
• conflict status.

Не все записи decay одинаково.

Decay не обязательно удаляет запись. Он может просто снижать шанс попадания в active retrieval.

TTL

TTL задает срок жизни записи.

Примеры:

Session preference:
- "Сегодня отвечай очень коротко."
ttl: current_session

Temporary task state:
- Coder agent is waiting for test results.
ttl: until_task_closed

Cached CRM entitlement:
- export enabled = false
ttl: 10 minutes

TTL особенно полезен для:

• session state;
• task state;
• temporary user instructions;
• cached external data;
• intermediate plans;
• drafts;
• handoff notes;
• short-lived permissions.

TTL защищает память от временных фактов, которые иначе стали бы "вечными".

Archive

Archive переносит запись из active memory в холодный слой.

Архивировать стоит, если:

• запись редко используется;
• она нужна для audit, но не для active behavior;
• task закрыт;
• событие старое;
• summary заменил raw log;
• запись superseded, но историю нужно сохранить;
• пользователь не просил deletion;
• compliance разрешает retention.

Archive отличается от delete. Архивная запись может быть найдена при специальном запросе:

"Что происходило в этой задаче месяц назад?"

Но она не должна всплывать в обычном context assembly.

Delete и право на забывание

Delete - физическое или логическое удаление записи.

Причины удаления:

• пользователь попросил удалить память;
• истек retention period;
• запись содержит secret;
• запись была сохранена ошибочно;
• policy требует удаления;
• данные больше не нужны;
• consent отозван.

Deletion сложнее, если память была:

• продублирована в нескольких индексах;
• попала в summaries;
• использована в derived records;
• записана в logs;
• синхронизирована в shared memory;
• включена в backups.

Поэтому delete должен быть проектным требованием с самого начала. Нельзя просто сказать "удалим из основной таблицы", если embeddings, summaries и caches все еще содержат данные.

Human-in-the-loop correction

Не все update decisions стоит отдавать модели.

Human-in-the-loop нужен, когда:

• конфликт high-impact;
• запись касается privacy или legal;
• пользователь исправляет память;
• automated extraction не уверен;
• два источника authoritative, но противоречат;
• policy update может изменить поведение системы;
• memory poisoning risk высок.

Пример пользовательской коррекции:

User:
"Нет, я не предпочитаю короткие объяснения. Я просил коротким делать только финальный отчет."

Система должна:

1. Найти старую запись.
2. Пометить ее как superseded или split by scope.
3. Создать scoped preferences.
4. Сохранить correction source.
5. Не продолжать использовать старую формулировку.

Human correction - один из самых надежных источников update.

Active memory view

Важная архитектурная идея: memory store и active memory view - не одно и то же.

Memory store может содержать:

• старые версии;
• archived records;
• raw events;
• superseded facts;
• conflicts;
• deleted tombstones;
• audit metadata;
• low-confidence hypotheses.

Active memory view должна содержать только то, что можно использовать сейчас:

• active facts;
• applicable procedures;
• relevant recent events;
• confirmed preferences;
• non-expired session state;
• high-confidence lessons;
• permitted records.

Retrieval должен по умолчанию работать с active view, а не со всей историей.

Мини-кейс: смена предпочтения пользователя

Старое воспоминание:

id: pref_response_detail
summary: User prefers detailed final answers.
scope: all tasks
status: active
confidence: medium

Новое сообщение:

"Для правок файлов финальный ответ делай коротким. Подробности нужны только в самой лекции."

Правильный update:

old:
  status: superseded
  reason: user clarified scope

new_1:
  summary: User prefers concise final reports after file edits.
  scope: file_edit_final_response
  status: active
  confidence: high

new_2:
  summary: User wants lecture content itself to remain detailed.
  scope: lecture_writing_content
  status: active
  confidence: high

Если система просто добавит новую запись "User prefers concise answers", она потеряет важное различие.

Мини-кейс: episodic-to-semantic distillation

Эпизоды:

Episode 1:
- Agent wrote lesson 2.5 with terms, schema, cases and questions.

Episode 2:
- Agent wrote lesson 2.6 with same structure.

Episode 3:
- Agent wrote lesson 2.7 with RAG diagram and self-check questions.

Episode 4:
- User requested writing all lectures in Module 03 sequentially.

Consolidated project memory:

Course-writing convention:
- Full lessons should preserve title, goal and expected result,
  then expand into sections with key terms, conceptual explanation,
  diagrams or tables, examples, risks, summary and self-check questions.

Potential procedural memory:

When asked to write a full module, process lessons in order and make transitions explicit.

Эта distillation полезна, но должна иметь project scope. Она не должна становиться universal rule для всех repositories.

Мини-кейс: forgetting временного состояния

Task state:

- Tester is waiting for patch.
- Reviewer is blocked until test results.
- Current hypothesis: rounding stage is wrong.
ttl: until_task_closed

После закрытия задачи эти записи не должны всплывать в будущих задачах как active context.

Что делать:

• task status -> archived;
• hypothesis -> archived или deleted, если не подтверждена;
• final decision -> сохранить как team memory, если важно;
• test outcome -> episodic memory или summary;
• raw intermediate state -> удалить или compact.

Так memory layer сохраняет полезную историю, но не заставляет агента жить в старом task state.

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

Ошибка 1: только добавлять, никогда не обновлять.

Append-only без active view приводит к конфликтующим воспоминаниям.

Ошибка 2: считать summary истиной.

Summary может терять детали и ошибаться. Нужен source или связь с raw records.

Ошибка 3: превращать один эпизод в semantic fact.

Distillation требует evidence, повторяемости или надежного source.

Ошибка 4: не различать stale, superseded и deleted.

Устаревшая запись может быть полезна исторически. Deleted запись не должна использоваться.

Ошибка 5: не применять TTL к временным данным.

Session state и task state без TTL становятся ложной долгосрочной памятью.

Ошибка 6: физически удалять без учета derived records.

Если данные попали в summaries и indexes, deletion должен учитывать производные записи.

Ошибка 7: не давать пользователю исправлять память.

Пользовательская коррекция - важный канал качества и доверия.

Ошибка 8: не учитывать permissions при archive retrieval.

Архивные данные тоже могут быть sensitive.

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

Memory Update, Consolidation и Forgetting завершают lifecycle памяти. Они позволяют памяти оставаться полезной во времени: подтверждать актуальные записи, заменять устаревшие, обобщать эпизоды, сжимать длинные истории, обнаруживать противоречия, снижать вес старого, архивировать и удалять данные.

Память без обновления превращается в набор конфликтующих утверждений. Память без consolidation тонет в событиях. Память без forgetting становится шумной и небезопасной.

Зрелая memory system разделяет memory store и active memory view, поддерживает versioning, TTL, decay, archive, delete и human correction.

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

1. Чем update отличается от простого добавления новой записи?
2. Что такое episodic-to-semantic distillation?
3. Почему rolling summary может быть источником ошибок?
4. Чем stale, superseded, archived и deleted отличаются друг от друга?
5. Почему deletion должен учитывать indexes, summaries и derived records?

Что дальше

Module 03 показал жизненный цикл памяти: запись, хранение, поиск, инъекция, обновление и забывание. В следующем модуле мы перейдем к хранилищам и представлениям памяти: где физически держать разные типы записей и как моделировать memory records, facts, events, skills и graph relations.