В Дне 10 решили: контекст — это проектирование, выборка из чего-то большего. Сегодня — из чего именно. Зачем инженеру четыре разных типа памяти и почему путать их — самая дорогая ошибка.
Память агента — это не одно хранилище, а четыре разных. Делятся по двум осям: краткосрочная / долгосрочная (по времени жизни) и эпизодическая / семантическая (по типу данных). Эпизодическая — это «что произошло», семантическая — «что я знаю». В инженерии это две разные базы, два разных способа поиска, два разных способа обновления. Большинство «плохих» агентов — это попытка хранить всё в одной памяти.
В Кластере 02 ты разобрался с памятью в пределах одной задачи: массив messages, который твой код пересобирает. Но как только задача начинает жить дольше одной сессии — появляются вопросы, на которые этот массив не отвечает:
Это всё разные виды «памяти». Их нельзя свалить в одну кучу. Если сваливаешь — получаешь систему, которая помнит всё одинаково плохо: вытаскивает не то, путает источники, перезаписывает важное.
Хорошая память агента — это не «один большой архив». Это несколько разных хранилищ с разными правилами: что записывать, как искать, когда забывать.
Чтобы спроектировать память — нужна классификация. Простая, но рабочая модель — на двух осях. Её и рассмотрим.
Время жизни. Это «как долго информация должна жить».
Технически это разные хранилища: краткосрочная — в массиве в памяти процесса, долгосрочная — в базе данных или файловой системе.
Тип содержимого. Это «о чём вообще запись».
Семантическая память получается из эпизодической путём обобщения. Из 20 эпизодов «пользователь жалуется на длинные ответы» делается семантическая запись «не любит длинные ответы».
Пересечение двух осей даёт четыре квадранта. У каждого — свой смысл, своё место в системе, свой способ управления:
Текущий диалог, последовательность шагов агента в этой сессии. Сырая хронология того, что происходит прямо сейчас.
Промежуточные выводы и текущее состояние задачи. Не события, а извлечённое знание в рамках этой сессии. Часто живёт в одном дополнительном сообщении.
Логи прошлых сессий. Хранится в базе для отладки, аналитики, иногда — для контекста («помнишь, на прошлой неделе мы…»). Объёмная, редко используется в полном виде.
Извлечённые факты и предпочтения. Структурированно: имя, роль, привычки, контекст. Самый ценный тип памяти — именно эта подгружается в контекст почти всегда.
Когда ты понимаешь, в какой квадрант попадает информация — у тебя автоматически появляются ответы на четыре вопроса проектирования:
Working memory — в массиве в памяти процесса (живёт пока сессия открыта). Scratchpad — в специальном сообщении внутри того же массива, обновляемом каждый шаг.
История взаимодействий — в обычной БД, индексированной по user_id и timestamp (Postgres, MongoDB).
База знаний о пользователе — в структурированном хранилище (key-value, JSON-документ) или в векторной БД (если хочешь искать «семантически близкое»). Часто комбинируется: структурное для точных полей (имя, возраст), векторное для «свободных» фактов (предпочтения, особенности).
Working memory — каждый ход. Это и есть состав массива.
Scratchpad — каждый ход, обновляется. Часто реализуется как «модель явно пишет обновлённое состояние» в специальное сообщение, и старое заменяется новым.
История взаимодействий — в конце сессии. Логируется автоматически.
База знаний о пользователе — выборочно. Не каждая реплика заслуживает попасть в долгосрочную семантическую память. Обычно — отдельный шаг в конце сессии: «извлеки из этого диалога факты о пользователе, которые стоит запомнить надолго». Это решение модели, не запись «всего подряд».
Working memory — никак не искать, она вся в массиве, целиком отправляется в контекст.
Scratchpad — берётся целиком (он короткий).
История взаимодействий — фильтр по user_id и времени, иногда RAG-поиск по содержимому (Кластер 05).
База знаний о пользователе — выборочно: что-то всегда (имя, базовые предпочтения), что-то — только под нужный запрос. Например, «факт о том, что Иван — Python-программист» — кладём в контекст всегда. А «факт о том, что он переезжал в 2022 году» — только если разговор зашёл про переезды.
Working memory — автоматически в конце сессии. Просто исчезает вместе с массивом.
Scratchpad — он сам себя перезаписывает каждый ход.
История взаимодействий — обычно никогда не забывают полностью, но архивируют (старше года → в холодное хранилище).
База знаний — самое сложное. Факты о пользователе устаревают: «работает в компании X» становится неправдой через год. Здесь нужна гигиена памяти: либо метки «когда записано», чтобы понимать актуальность; либо периодические ревизии («спроси у пользователя, всё ли ещё актуально»). Без этого память превращается в свалку, где правда лежит рядом с устаревшими фактами.
Соблазн — сразу строить «настоящего ассистента с памятью». В большинстве случаев это преждевременная сложность. Долгосрочная память оправдана, только если задача правда живёт между сессиями.
Чат-бот поддержки, который решает разовую проблему — не нуждается в долгосрочной памяти. Каждая сессия — самодостаточна. Зато ассистент по подготовке к собеседованиям, который ведёт тебя 2 недели — без долгосрочной памяти бесполезен.
Правило: если 80%+ задач завершаются за одну сессию — обходись без долгосрочной памяти. Если задача растянута во времени или ценен «накопленный контекст» — стройте.
У долгосрочной семантической памяти два основных формата хранения:
{ "name": "Иван", "role": "программист", "tone_preference": "short" }. Точный поиск, легко обновлять, легко показать пользователю «что я о тебе знаю». Не масштабируется на «нестандартные» факты.«Иван не любит формальный тон». Поиск по семантической близости. Хорошо масштабируется, но трудно показать содержимое, трудно обновлять конкретный факт.Хорошая практика: комбинировать. Структурная — для базового профиля (имя, роль, базовые предпочтения, факты которые точно есть у каждого пользователя). Векторная — для «всего остального» (нестандартные факты, наблюдения, эпизоды).
«Чем больше памяти — тем лучше». На практике — наоборот. Чем больше шума в долгосрочной памяти, тем хуже поиск, тем больше нерелевантного попадает в контекст, тем хуже работает агент.
Хорошее правило: в долгосрочную память попадает только то, что переживёт неделю. «Сегодня пользователь хочет сводку по AAPL» — это не запись в долгосрочную память. «Пользователь интересуется инвестициями в технологический сектор» — это запись.
Записал в долгосрочную память факт «живёт в Москве» — и всё. А через полгода пользователь переехал. Откуда ты узнаешь, что факт устарел?
У каждой записи в долгосрочной памяти должны быть метаданные: когда записано, на основании какой сессии, какая уверенность в факте. С этими данными ты можешь делать ревизию: «факты, которым больше года и которые касаются работы/места жительства — спрашивать у пользователя при следующем удобном моменте».
«У меня есть память про пользователя — буду класть её целиком в каждый запрос». Это работает, пока память маленькая. Когда у пользователя накопилось 50 фактов про себя — ты не должен класть их все. Только релевантные текущему запросу.
Это связь с Кластером 05 (RAG): даже «своя» память пользователя — это база, по которой надо искать, не «грузить всё». Возвращаемся к мантре Дня 10: контекст — это выборка, не сваливание.
«Я просто буду напоминать модели важное в каждом промпте, и она запомнит». Модель stateless (см. День 1). Она не «запомнит». Каждый запрос — это новый взгляд на то, что лежит в массиве. Если ты не положил факт в массив — модель его не увидит, даже если он лежал там в прошлой сессии.
«Запоминание» — это всегда работа твоего кода: записать факт в хранилище, потом вытащить и положить в контекст. Без этого магии не случится, даже на самой большой модели.
В современных версиях этих ассистентов есть включаемая память. Открой настройки — посмотри, какие факты они о тебе сохранили. Классифицируй каждый факт: краткосрочный или долгосрочный? Эпизодический или семантический? Сделай таблицу с четырьмя квадрантами. Это покажет тебе, как реальные продакшен-системы решают эту задачу.
Возьми идею «персональный ассистент по саморазвитию» (книги, курсы, привычки). Распиши: что у него в working memory (что во время текущего разговора)? Что в scratchpad (текущая цель / состояние задачи)? Что в истории взаимодействий (что архивируется по сессиям)? Что в базе знаний о пользователе (что переживает месяцы)? Получишь на бумаге архитектуру памяти этого агента.
Представь, что ты сам пользуешься AI-ассистентом, у которого есть память. Какие факты о тебе ты хочешь, чтобы он помнил между сессиями? Какие — нет, даже если они «полезны»? Эта личная интуиция понадобится завтра в Дне 12, где разбираем персонализацию — границы и гигиена.