Цель лекции
Показать, как memory layer выглядит в персональном ассистенте.
Ожидаемый результат
Читатель понимает базовый дизайн памяти для consumer-ассистента: что стоит помнить, что нельзя превращать в постоянную память, какие слои нужны и какие риски появляются вокруг приватности и over-personalization.
Зачем это нужно
Персональный ассистент - самый интуитивный пример агентной памяти.
Пользователь ожидает, что ассистент будет помнить:
- как к нему обращаться;
- на каком языке отвечать;
- какие форматы ему удобны;
- какие цели и проекты важны;
- какие задачи уже обсуждались;
- какие детали не стоит спрашивать повторно.
Но именно здесь легко перейти границу. Если ассистент запоминает каждую фразу, он становится навязчивым, устаревшим и потенциально опасным. Если он ничего не помнит, он остается одноразовым chatbot.
Хороший персональный ассистент должен помнить полезное, забывать временное, спрашивать согласие для чувствительного и давать пользователю контроль.
Основная идея
Персональный ассистент должен помнить полезные предпочтения и цели, но не превращать каждую реплику пользователя в вечный факт.
Архитектура строится вокруг трех вопросов:
- что улучшит будущие ответы;
- что пользователь ожидает увидеть в памяти;
- что нельзя хранить без явного основания.
Память персонального ассистента - это не скрытый профиль, а управляемый слой персонализации.
Ключевые термины
| Термин | Короткое определение |
|---|---|
User profile |
Долгосрочные предпочтения, устойчивые факты и настройки пользователя. |
Session memory |
Временный контекст текущей сессии или задачи. |
Preference |
Пользовательское предпочтение по стилю, формату, процессу или поведению. |
Consent |
Явное или контекстно понятное разрешение хранить и использовать память. |
Over-personalization |
Ситуация, когда агент применяет память слишком широко или неуместно. |
Freshness |
Актуальность memory record относительно текущей ситуации. |
User control |
Возможность пользователя посмотреть, исправить, отключить или удалить память. |
Архитектура персонального ассистента
В этой схеме есть две важные идеи.
Первая: запись памяти проходит через policy, а не происходит автоматически.
Вторая: пользователь должен иметь поверхность управления памятью. Если memory layer полностью скрыта, исправление ошибок становится болезненным.
Что стоит помнить
Персональный ассистент может хранить несколько классов информации.
| Класс | Пример | Срок жизни |
|---|---|---|
| Style preferences | "Отвечай по-русски в этом курсе." | Долгосрочно или project-scoped |
| Format preferences | "Финальный отчет делай кратким." | Долгосрочно, если подтверждено |
| Goals | "Я готовлю курс по AI Agent Memory." | Пока цель актуальна |
| Stable entities | "Мой основной проект называется X." | Пока не изменится |
| Recurring routines | "Каждую неделю готовим обзор." | Пока пользователь не отменит |
| Corrections | "Это preference только для рабочих отчетов." | Долгосрочно как refinement |
Хорошая память обычно отвечает хотя бы одному критерию:
- уменьшает повторные вопросы;
- повышает релевантность;
- сохраняет важный контекст между сессиями;
- поддерживает текущую цель;
- была явно задана пользователем как предпочтение.
Что не стоит помнить
Не вся информация из диалога должна стать memory record.
Обычно не стоит сохранять:
- одноразовые детали;
- случайные эмоции как устойчивые черты;
- секреты, ключи, пароли, токены;
- чувствительные данные без явного согласия;
- предположения о пользователе;
- временные инструкции вроде "сегодня отвечай кратко";
- данные, которые пользователь явно не просил помнить;
- конфликтующие факты без разрешения конфликта.
Пример:
User:
"Сегодня я тороплюсь, отвечай очень коротко."
Bad memory:
"User always prefers very short answers."
Better:
session_style = concise
ttl = current session
Главная ошибка персональных ассистентов - превращать временный контекст в вечный профиль.
User profile
User profile хранит устойчивые настройки и предпочтения.
Пример записи:
type: preference
scope: course_project
content: "User prefers detailed lecture bodies and concise final reports."
source: explicit_user_instruction
confidence: high
created_at: 2026-08-08
last_confirmed_at: 2026-08-08
Хороший profile record содержит:
- type;
- scope;
- source;
- confidence;
- timestamp;
- update history;
- deletion status;
- optional expiry.
Профиль должен быть маленьким и точным. Если profile превращается в длинную свалку, retrieval начнет вытаскивать лишнее, а ассистент станет вести себя странно.
Session memory
Session memory хранит то, что нужно прямо сейчас.
Примеры:
- текущая задача;
- последние уточнения;
- temporary style instruction;
- выбранный документ;
- текущий workflow step;
- unresolved question;
- intermediate result.
Session memory может жить:
- один turn;
- одну сессию;
- один task;
- до завершения workflow.
Она не обязана попадать в long-term store.
Пример:
Current task:
"Написать лекции модуля 10."
Session memory:
- working directory
- files to edit
- recent checks
- user's latest instruction
После завершения задачи большая часть этого контекста может исчезнуть.
Lightweight retrieval
Персональному ассистенту редко нужен тяжелый retrieval stack на старте.
Часто достаточно:
- profile lookup;
- recent session summary;
- simple semantic search over user notes;
- project-scoped filters;
- top-k memory records;
- freshness check.
Retrieval должен быть осторожным.
Плохой retrieval:
Question:
"Что мне приготовить на ужин?"
Retrieved:
- старый факт о диете трехлетней давности
- sensitive medical note
- случайная фраза из прошлого диалога
Хороший retrieval:
Retrieved:
- current dietary preference if active and consented
- recent grocery context
- no sensitive assumptions without need
Для personal assistant relevance недостаточно. Нужно проверять appropriateness.
Consent и visibility
Персональная память требует доверия.
Пользователь должен понимать:
- что ассистент запомнил;
- почему это используется;
- как исправить запись;
- как удалить запись;
- как выключить память;
- какие данные не сохраняются.
Минимальный UX:
Memory:
- "Для этого курса писать лекции на русском."
Actions:
- edit
- delete
- disable for this project
Даже если интерфейс пока простой, архитектура должна поддерживать эти операции.
Устаревшие факты
Пользователь меняется. Проекты меняются. Предпочтения меняются.
Поэтому memory record должен иметь:
- created_at;
- last_used_at;
- last_confirmed_at;
- scope;
- optional expiry;
- stale marker;
- update path.
Пример:
Old memory:
"User prefers Python examples."
Current request:
"В этом модуле давай без кода."
Expected:
Current request wins.
Memory may be refined:
"Python examples are preferred only when implementation detail is requested."
Свежесть особенно важна для goals, schedules, project facts and recurring routines.
Риски
| Риск | Как проявляется | Защита |
|---|---|---|
| Over-personalization | Агент применяет preference в неподходящем контексте. | Scopes, current instruction priority, human correction. |
| Privacy creep | Профиль становится слишком подробным. | Data minimization, consent, memory visibility. |
| Stale facts | Старые факты влияют на новые решения. | Freshness checks, confirmation, expiry. |
| Sensitive storage | Секреты или чувствительные данные попадают в память. | Redaction, policy blocks, user confirmation. |
| False inference | Агент записывает догадку как факт. | Source labeling, confidence, explicit confirmation. |
| Hidden memory | Пользователь не может исправить поведение. | View/edit/delete controls. |
Метрики
Для персонального ассистента важны не только retrieval metrics.
| Метрика | Что показывает |
|---|---|
| User correction rate | Как часто пользователь исправляет память или поведение. |
| Answer usefulness | Помогла ли память получить более полезный ответ. |
| Freshness | Как часто используется актуальная, а не старая память. |
| Over-personalization rate | Как часто память применена слишком широко. |
| Memory acceptance rate | Как часто пользователь подтверждает предложенные memories. |
| Deletion success | Удаленная память больше не всплывает. |
| Sensitive write block rate | Сколько опасных записей было остановлено policy. |
Высокая персонализация без user trust - плохой результат.
Мини-кейс
Пользователь говорит:
"Для рабочих писем пиши спокойно и коротко.
Для обучающих материалов можно подробно."
Хорошая memory extraction:
Record 1:
type: style_preference
scope: work_email
content: calm and concise
Record 2:
type: style_preference
scope: educational_materials
content: detailed explanation is acceptable
Плохая extraction:
"User prefers short answers."
Почему плохо: потерян scope, из-за чего агент будет отвечать слишком кратко в лекциях, research notes и архитектурных обсуждениях.
Типичные ошибки
Ошибка 1: хранить все подряд.
Память должна быть curated, а не полной копией диалога.
Ошибка 2: не различать session и long-term memory.
Временная инструкция не должна становиться постоянной чертой пользователя.
Ошибка 3: не давать пользователю контроль.
Без view/edit/delete memory становится источником недоверия.
Ошибка 4: делать personalization сильнее текущей инструкции.
Последняя явная просьба пользователя обычно важнее старого preference.
Ошибка 5: не учитывать чувствительность данных.
Некоторые данные лучше не хранить даже если они технически полезны.
Краткое резюме
Персональный ассистент нуждается в аккуратной памяти: user profile, session memory, lightweight retrieval, consent, freshness и user control. Его задача - помогать без навязчивости и не превращать случайный контекст в вечный профиль.
Главная мысль: персональная память должна быть полезной, минимальной, объяснимой и управляемой пользователем.
Вопросы для самопроверки
- Чем user profile отличается от session memory?
- Почему temporary instruction нельзя автоматически сохранять как preference?
- Какие данные персональный ассистент не должен помнить без явного основания?
- Как over-personalization проявляется в ответах агента?
- Какие метрики помогают оценить качество персональной памяти?
Что дальше
В следующей лекции мы рассмотрим coding agent: сценарий, где память связана не только с пользователем, но и с проектом, файлами, командами, прошлым опытом и процедурными conventions.