Урок 6.2. Политики памяти: read, write, update, delete

Цель лекции

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

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

Читатель понимает, что правила доступа и изменения памяти должны проектироваться явно: read, write, update, delete, retention, privacy, scope, conflict, injection и user override policies являются ядром надежной memory system.

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

Memory layer без политик ведет себя как импровизатор:

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

Политики нужны, чтобы memory system была не только "умной", но и управляемой.

Политика отвечает на вопрос:

Как система должна поступать в этом классе ситуаций?

Например:

• когда обращаться к памяти;
• что можно сохранять;
• что нельзя сохранять;
• как обновлять противоречия;
• кто может удалить запись;
• сколько хранить data;
• какие scopes разрешены;
• что попадет в prompt;
• как пользователь может переопределить память.

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

Без политик агент либо забывает важное, либо помнит лишнее, либо извлекает контекст, который не должен был использовать.

Memory policies - это control plane памяти. Они не обязательно должны быть сложным policy engine в первой версии, но должны быть явными.

Политика может быть:

• hard-coded rule;
• configuration;
• declarative file;
• system instruction;
• database rule;
• permission model;
• human review process;
• product setting.

Главное - чтобы behavior был предсказуем и проверяем.

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

Карта политик

Эти политики связаны. Например, write policy может сохранить запись, но injection policy не позволит вставить ее в prompt без source label. Retention policy может архивировать запись, а read policy больше не будет использовать ее по умолчанию.

Read policy

Read policy решает, когда агент обращается к памяти и какие слои ищет.

Вопросы:

• нужна ли память для этой задачи;
• какие scopes активны;
• какие memory types искать;
• нужно ли искать world memory;
• какие permission filters применить;
• можно ли использовать archived records;
• нужен ли fresh source вместо old memory;
• когда лучше negative retrieval.

Пример:

If task_type = lecture_writing:
  read:
    - target lesson plan
    - content plan section
    - project writing conventions
    - adjacent lesson style
  do_not_read:
    - unrelated user profile
    - old task states

Read policy защищает от under-retrieval и over-retrieval.

Write policy

Write policy решает, что сохранять.

Вопросы:

• полезно ли это за пределами текущего шага;
• это fact, event, procedure, reflection или session state;
• есть ли consent;
• есть ли PII/secrets;
• какой scope;
• насколько запись стабильна;
• какой confidence;
• synchronous или asynchronous write;
• нужен ли human review.

Пример:

Save as long-term memory if:
- user explicitly says "remember"
- information is stable
- scope is clear
- privacy policy allows storing

Do not save if:
- secret detected
- temporary instruction
- unsupported model inference
- no future utility

Write policy - главный фильтр против memory noise.

Update policy

Update policy решает, как память меняется.

Вопросы:

• новая информация подтверждает старую запись;
• уточняет scope;
• заменяет старую запись;
• конфликтует с ней;
• снижает confidence;
• должна создать new version;
• требует human correction;
• должна пометить запись stale.

Пример:

Old:
- User prefers detailed responses.

New:
- User wants concise final reports but detailed lecture content.

Update policy:
- supersede broad preference
- create two scoped preferences
- mark source as user correction

Update policy предотвращает одновременную активность конфликтующих facts.

Delete policy

Delete policy определяет, как память удаляется.

Вопросы:

• кто может удалить запись;
• какие scopes затронуты;
• нужно ли soft delete или hard delete;
• что делать с embeddings;
• что делать с summaries;
• что делать с cache;
• что делать с archive;
• нужен ли audit/tombstone;
• какие legal retention ограничения.

Пример:

User requests deletion of personal preferences:
- find records with scope.user_id = current user
- status -> deleted
- remove from vector/search indexes
- remove from active summaries
- invalidate cache
- keep deletion tombstone if policy requires

Delete policy нужно проектировать заранее. Иначе "забыть" становится почти невозможным.

Retention policy

Retention policy задает срок хранения.

Примеры:

Retention policy связана с privacy, cost и quality. Данные не должны жить вечно просто потому, что storage дешевый.

Privacy policy

Privacy policy ограничивает, что можно сохранять, читать и показывать.

Вопросы:

• какие данные считаются sensitive;
• можно ли сохранять PII;
• можно ли сохранять health/finance/legal context;
• как обрабатывать secrets;
• нужна ли explicit consent;
• можно ли использовать данные для personalization;
• можно ли делиться записью с другими агентами;
• можно ли включать запись в summaries.

Пример:

Policy:
- Never store API keys or passwords in memory.
- Store sensitive personal data only if required for user-requested task and with limited retention.
- Derived records inherit restrictive scope from sources.

Privacy policy должна применяться до write и до injection.

Scope policy

Scope policy определяет, где запись применима.

Вопросы:

• user, session, project, agent, team или organization;
• private или shared;
• tenant/workspace/account boundary;
• можно ли cross-scope retrieval;
• какой priority при конфликте scopes;
• наследуют ли derived records scope.

Пример:

Project convention:
- Applies only to project_id = ai-agent-memory-guide.

Organization security policy:
- Applies to all projects in organization.

Session instruction:
- Applies until current task closes.

Scope policy предотвращает "правильную память в неправильном месте".

Conflict policy

Conflict policy определяет, что делать с противоречиями.

Типы конфликтов:

• old fact vs new fact;
• user preference vs project rule;
• project rule vs organization policy;
• memory vs current source;
• two agents write different conclusions;
• summary vs raw event;
• model inference vs tool result.

Стратегии:

Conflict policy должна быть явной. Иначе модель сама будет решать, чему верить.

Injection policy

Injection policy решает, какие memories попадут в prompt.

Вопросы:

• какие types разрешены;
• какой priority;
• как учитывать confidence;
• как показывать source;
• как показывать uncertainty;
• что делать с conflicts;
• сколько tokens выделить;
• какие memories нельзя inject;
• когда negative injection.

Пример:

Inject:
- active high-priority policies
- relevant project facts
- current task summary
- recent important events
- cited world sources

Do not inject:
- deleted records
- low-confidence hypotheses as facts
- private memory outside scope
- stale records unless task asks history
- raw logs if summary is enough

Injection policy - последний gate перед context window.

User override

Пользователь должен иметь возможность управлять памятью.

User override включает:

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

Но user override не может нарушать hard policies.

Пример:

User:
"Запомни мой API key."

Policy:
Secrets must not be stored.

Result:
Reject storage and explain safe alternative.

User control важен, но safety boundary остается.

Policy hierarchy

Политики имеют приоритеты.

Примерная иерархия:

System safety / legal / security
  > organization policy
  > project policy
  > explicit current user request
  > session constraints
  > user long-term preference
  > agent learned habit

Это не универсальная формула. В конкретном продукте hierarchy нужно описать явно.

Главное: learned memory и reflection не должны обходить hard policies.

Схема policy engine

Policy engine не обязательно должен быть отдельной программой. Но каждая memory operation должна проходить через policy decision.

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

User:

"Исправь баг и не запускай тесты."

Context:

Project policy:
- Run targeted tests for code changes.

Task:
- Code change likely needed.

Policy behavior:

• current user request is important;
• project policy says tests are expected;
• agent can patch code but should report tests not run only if user insists;
• if tests are safety-critical, ask or explain conflict.

Final:

I changed X. I did not run tests because you asked not to; targeted tests would normally be recommended for this code path.

Политика не обязана запрещать работу, но должна сделать deviation explicit.

Мини-кейс: personal memory

User:

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

Write policy:

• session memory only;
• TTL current session;
• do not update long-term profile.

Injection policy:

• inject concise style instruction during current session.

Update policy:

• if user later says "всегда так отвечай", consider long-term preference.

Так система не превращает временную просьбу в постоянную память.

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

Ошибка 1: проектировать storage без политик.

База знает, где лежат данные, но не знает, можно ли их использовать.

Ошибка 2: смешивать read и injection.

Можно иметь право прочитать запись для audit, но не вставлять ее в prompt.

Ошибка 3: не задавать retention.

Данные начинают жить вечно по умолчанию.

Ошибка 4: считать user override абсолютным.

Пользователь не может override safety, legal и privacy policies.

Ошибка 5: не обрабатывать conflicts.

Конфликтующие active facts ухудшают reasoning.

Ошибка 6: применять privacy policy только при final answer.

Privacy должна применяться до write, retrieval и injection.

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

Policies должны иметь test cases: что сохраняется, что блокируется, что удаляется.

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

Memory policies делают память управляемой. Они определяют, когда читать, что писать, как обновлять, что удалять, сколько хранить, какие scopes разрешены, как обрабатывать privacy и conflicts, что inject в prompt и как пользователь может управлять memory.

Без политик memory layer становится непредсказуемым: агент помнит лишнее, забывает важное или использует контекст, который не должен был попасть в работу.

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

1. Чем read policy отличается от injection policy?
2. Почему write policy должна учитывать consent и PII?
3. Что должна делать conflict policy при новой пользовательской correction?
4. Почему retention policy важна даже при дешевом storage?
5. Какие user overrides не должны нарушать hard policies?

Что дальше

В следующей лекции мы разберем Context Assembly: последний и очень важный этап, где найденная память превращается в компактный, приоритизированный и безопасный prompt для модели.