Урок 7.1. Основные failure modes памяти

Цель лекции

Собрать типичные ошибки и деградации memory systems.

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

Читатель узнает основные способы, которыми память может ухудшить поведение агента, и понимает, какие архитектурные меры помогают заранее снижать риск: write policy, retrieval quality, context assembly, update, forgetting, scopes и evaluation.

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

Память делает агента сильнее: он может помнить пользователя, проект, прошлые ошибки, workflows, источники и решения. Но та же память может ухудшить систему.

Плохая память опаснее отсутствия памяти, потому что агент начинает действовать уверенно на основе старого, шумного или неверного контекста.

Примеры:

• агент вспоминает старое предпочтение пользователя и игнорирует новое;
• retrieval достает похожий, но нерелевантный episode;
• summary постепенно искажает историю;
• в prompt попадает слишком много памяти, и модель теряет текущую задачу;
• конфликтующие facts активны одновременно;
• ошибка агента сохраняется как lesson learned и повторяется;
• память одного проекта применяется к другому.

Failure modes нужны не для пессимизма. Они помогают проектировать memory layer не только по happy path.

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

Память усиливает возможности агента, но также может усиливать ошибки, если retrieval, обновление и контекстная сборка работают плохо.

Memory failure обычно возникает не в одном месте. Это цепочка:

bad write -> bad retrieval -> bad injection -> bad action -> bad memory update

Например:

1. Агент сохранил временную просьбу как постоянное предпочтение.
2. Retrieval достал эту запись в новой задаче.
3. Context assembly вставил ее без scope.
4. Модель изменила стиль ответа неправильно.
5. Пользователь исправил агента, но update не обработал конфликт.

Значит, защита должна быть сквозной: write policy, metadata, scopes, retrieval filters, reranking, context budget, conflict detection, decay и user correction.

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

Карта failure modes

Lost in the middle

Lost in the middle возникает, когда важная информация находится в длинном контексте, но модель ее фактически не использует.

Пример:

Prompt:
- System instructions
- Long history
- 15 retrieved memories
- Important constraint in the middle:
  "Do not edit generated files."
- More tool logs
- User request

Агент редактирует generated file, хотя constraint был в prompt.

Причины:

• слишком длинный context;
• важное не выделено;
• плохой порядок блоков;
• много похожего текста;
• constraint спрятан среди logs;
• нет grouping by type.

Защита:

• помещать critical policies ближе к началу или в отдельный блок;
• группировать constraints;
• сокращать raw logs;
• использовать explicit labels;
• не перегружать prompt retrieved memories;
• тестировать context assembly.

Context rot

Context rot - деградация качества ответа из-за большого, старого или шумного контекста.

Симптомы:

• агент отвечает не на текущий запрос, а на старую тему;
• смешивает несколько задач;
• повторяет устаревший план;
• становится чрезмерно осторожным из-за старых warnings;
• игнорирует свежие tool results;
• использует стиль из другой сессии.

Пример:

User:
"Исправь опечатку."

Context:
- long architecture discussion
- old debugging attempts
- unrelated reflection notes
- stale frontend workflow

Агент начинает предлагать большой refactor.

Защита:

• session summaries вместо полной истории;
• current-task working set;
• context budget;
• negative injection;
• TTL для task state;
• demotion старых records;
• разделение current state и history.

Retrieval noise

Retrieval noise - это память, похожая на запрос, но бесполезная или вредная для текущего действия.

Пример:

Query:
"memory retrieval"

Retrieved:
- все упоминания слова retrieval в курсе;
- старые заметки про RAG;
- unrelated support examples;
- точный план нужного урока потерялся среди шума.

Причины:

• слишком широкий query;
• только vector search;
• нет metadata filters;
• нет reranking;
• top-k слишком высокий;
• scopes не применены;
• old low-confidence records не снижены.

Защита:

• hybrid retrieval;
• query construction;
• scope filters;
• reranking;
• context budget;
• source priority;
• negative retrieval.

Stale memory

Stale memory - память, которая была правильной раньше, но больше не актуальна.

Примеры:

• проект перешел с Jest на Vitest;
• пользователь изменил preference;
• policy обновилась;
• API изменил behavior;
• ticket закрылся;
• customer plan изменился;
• файл переехал.

Опасность stale memory в том, что она часто выглядит уверенно.

Защита:

• last_confirmed_at;
• valid_from / valid_until;
• source freshness;
• decay;
• update policy;
• contradiction detection;
• preference confirmation;
• проверка current source для volatile facts.

Пример:

Old memory:
- Project uses Jest.

Current source:
- package.json uses Vitest.

Action:
- Use current source.
- Mark old memory superseded/stale.

Contradictory memory

Contradictory memory возникает, когда active context содержит несовместимые записи.

Пример:

- User prefers detailed final answers.
- User prefers concise final reports after edits.

Это может быть настоящий конфликт, а может быть scope issue.

Лучшее представление:

- Detailed explanations: architecture discussions.
- Concise final reports: file edit summaries.

Причины:

• нет conflict detection;
• нет scoped update;
• add-only без active view;
• summaries не обновляются;
• weak source записан как high-confidence fact.

Защита:

• contradiction detection;
• status: active/stale/superseded/conflicted;
• scoped records;
• source priority;
• human review для high-impact conflicts;
• не inject unresolved conflicts как facts.

Summarization drift

Summarization drift - искажение памяти при многократном сжатии.

Пример:

Original:
"Сегодня отвечай кратко."

Summary v1:
"User wants concise answers today."

Summary v2:
"User prefers concise answers."

Summary v3:
"Always answer briefly."

Временная просьба стала постоянной policy.

Причины:

• summary без source;
• исчезают qualifiers;
• model fills gaps;
• repeated compaction;
• facts и hypotheses смешиваются;
• нет validation.

Защита:

• сохранять source links;
• не терять scope/time qualifiers;
• periodic drift checks;
• human correction;
• structured summaries;
• различать session summary и long-term memory.

Over-personalization

Over-personalization - агент слишком сильно опирается на сохраненные preferences или profile.

Симптомы:

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

Пример:

Memory:
- User prefers short final reports.

Task:
- User asks for detailed architecture explanation.

Bad:
- Agent gives tiny answer.

Защита:

• current request priority;
• scoped preferences;
• confidence and recency;
• user-visible memory;
• ask when uncertain;
• avoid sensitive inferences.

Under-retrieval

Under-retrieval - агент не достал важную память.

Пример:

Project memory:
- Do not edit generated files.

Task:
- User asks to change generated output.

Failure:
- Agent does not retrieve project rule and edits generated file.

Причины:

• read policy слишком узкая;
• query construction слабый;
• missing index;
• wrong scope;
• memory not indexed;
• retrieval disabled to reduce latency.

Защита:

• task-type based retrieval;
• critical policies always hot/warm;
• index health checks;
• regression tests;
• explicit project instruction loading;
• fallback to files/source of truth.

Over-retrieval

Over-retrieval - агент достает слишком много памяти.

Симптомы:

• context window перегружен;
• важное теряется среди retrieved chunks;
• модель становится verbose;
• старые episodes влияют на текущий ответ;
• latency растет.

Причины:

• большой top-k;
• нет reranking;
• нет context budget;
• retrieval "на всякий случай";
• no negative retrieval;
• дубли не объединены.

Защита:

• smaller top-k;
• diversity-aware reranking;
• context budget;
• summaries instead of raw logs;
• negative injection;
• active view вместо всей истории.

Memory feedback loop

Memory feedback loop возникает, когда ошибка сохраняется и начинает усиливать будущие ответы.

Пример:

1. Агент ошибочно решил, что для frontend задач тесты не нужны.
2. Reflection сохранила: "CSS changes do not require running app."
3. В следующей frontend задаче retrieval достал этот lesson.
4. Агент снова не проверил UI.
5. Ошибка подтвердилась как "повторяющийся pattern".

Проблема: memory начинает ссылаться сама на себя.

Защита:

• не сохранять weak inference как strong rule;
• evidence requirements;
• confidence;
• human review для procedural promotion;
• external validation;
• track source vs derived records;
• decay unconfirmed lessons.

Диагностическая схема

Эта схема помогает отлаживать memory failures. Не вся плохая работа агента вызвана моделью. Часто проблема в том, что memory layer дал плохой context.

Мини-кейс: написание лекции

Задача:

"Напиши лекцию в модуле 7."

Возможные failure modes:

• under-retrieval: агент не читает план урока;
• over-retrieval: агент вставляет все прошлые лекции целиком;
• stale memory: использует старый template;
• context rot: начинает писать про Module 06;
• summarization drift: думает, что TODO нужно обновлять всегда;
• over-personalization: делает финальный ответ слишком подробным, хотя пользователь обычно хочет кратко.

Защита:

• читать target lesson plan;
• читать relevant content plan;
• использовать соседний финал для перехода;
• не inject весь курс;
• держать writing workflow scoped;
• проверять TODO/FIXME как markers, но не обновлять tracking без просьбы.

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

Запрос:

"Почему export недоступен?"

Failure modes:

• retrieval noise: похожие tickets других клиентов;
• stale memory: старый plan клиента;
• contradictory memory: docs говорят Pro, CRM говорит Business;
• over-retrieval: в prompt попали internal notes;
• under-retrieval: не достали current entitlement;
• feedback loop: старое неправильное explanation сохраняется в account summary.

Защита:

• account scope filters;
• current CRM as high-priority source;
• source labels;
• conflict policy;
• permission-aware context assembly;
• human review для customer-facing commitments.

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

Ошибка 1: считать memory failure ошибкой модели.

Иногда модель использовала именно тот плохой контекст, который ей дали.

Ошибка 2: не измерять retrieval noise.

Если retrieved context похож, но бесполезен, качество будет падать скрыто.

Ошибка 3: не хранить source и time.

Без source и time нельзя отличить fresh fact от stale memory.

Ошибка 4: не иметь active view.

Append-only память без статусов создает conflicts.

Ошибка 5: доверять summaries без проверки.

Summary может быть удобным, но не всегда reliable source of truth.

Ошибка 6: не тестировать long-term scenarios.

Многие failure modes видны только через несколько сессий.

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

User correction - важнейший сигнал для update.

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

Память может ухудшить агента, если write, retrieval, update и context assembly работают плохо. Главные failure modes: lost in the middle, context rot, retrieval noise, stale memory, contradictory memory, summarization drift, over-personalization, under-retrieval, over-retrieval и memory feedback loop.

Защита строится не одним приемом, а сквозной дисциплиной: metadata, scopes, source, timestamps, confidence, read/write policies, reranking, context budget, conflict detection, decay, forgetting и evaluation.

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

1. Почему плохая память может быть опаснее отсутствия памяти?
2. Чем retrieval noise отличается от over-retrieval?
3. Как summarization drift может превратить временную просьбу в постоянную preference?
4. Почему stale memory требует timestamps и source?
5. Что такое memory feedback loop?

Что дальше

В следующей лекции мы разберем security-аспект памяти: memory poisoning, prompt injection через документы и tool results, secret leakage, cross-user leakage, trust levels, sanitization, permission-aware retrieval и audit trail.