Память ИИ-агента между сессиями: что запоминать, куда писать и как не утонуть в мусоре
Агент принял заявку, отправил письмо, согласовал условия — и в следующем запуске не помнит ни клиента, ни договорённостей. Память между сессиями не появляется сама: её нужно где-то хранить, чем-то отбирать и регулярно чистить. Разберём, что записывать, куда писать и как память не превращается в свалку, из которой агент достаёт устаревшее.
Коротко
- Память агента делится на два уровня: рабочую (внутри одной сессии, живёт в истории диалога) и долговременную (между сессиями, в отдельном хранилище). Путаница между ними — причина большинства сбоев вида «он забыл».
- Длинная история в контексте память не заменяет. По бенчмарку LongMemEval (ICLR 2025, 500 вопросов) коммерческие ассистенты и длинноконтекстные модели теряют 30% точности при воспроизведении информации из продолжительных диалогов, а при чтении полной истории на 115 тыс. токенов падение доходит до 30–60%.
- Отбор памяти даёт и экономию: авторы Mem0 на бенчмарке LOCOMO получили на 26% выше оценку LLM-судьи, чем у базовой памяти OpenAI, при p95-задержке ниже на 91% и расходе токенов меньше более чем на 90%, чем у подхода «вся история в контексте».
- В долговременную память идут три вида сведений: факты (семантическая), собственные действия и их результаты (эпизодическая) и правила работы (процедурная). Остальное — история переписки, для работы она не нужна.
- Мусор появляется по четырём привычкам: писать всё подряд, не чистить устаревшее, хранить без даты и источника, смешивать факты с правилами. У каждой записи должны быть тип, дата и источник — иначе через месяц ей нельзя верить.
Почему агент забывает всё между сессиями
Сессия — это один разговор или один запуск задачи. Внутри сессии контекст держится сам: модель видит историю сообщений и понимает, о чём речь. Как только сессия закрылась, история остаётся текстом, который в следующий запуск никто не подставляет. Агент начинает с пустого окна и честно не знает ни клиента, ни прошлых договорённостей.
Отсюда типовые сбои: клиент второй раз рассказывает то же самое, менеджер получает повторное письмо, агент предлагает вариант, от которого отказались месяц назад. Модель тут ни при чём — ей просто некуда посмотреть. Нужно место, где факты о клиенте и о работе лежат между запусками и откуда их можно достать по запросу. Это и называют долговременной памятью агента.
Два уровня памяти и три вида сведений
Классификация простая и совпадает с рабочими схемами из документации по агентам — например, с разделом о памяти в LangChain. Сначала память делят по охвату: рабочая и долговременная. Потом долговременную — по содержанию: семантическая (факты), эпизодическая (опыт и действия) и процедурная (правила). То же деление есть в научной таксономии памяти агентов CoALA.
| Вид | Что лежит | Пример записи | Как часто меняется |
|---|---|---|---|
| Рабочая (сессия) | История текущего диалога и промежуточные результаты | «Клиент просит прайс на 2000 саженцев» | Постоянно, живёт до конца сессии |
| Семантическая | Факты о клиенте, продукте, договорённостях | «Канал связи — Telegram, платит по счёту» | При новом подтверждённом факте |
| Эпизодическая | Что уже сделали и с каким результатом | «12 марта отправили КП, ответа нет» | После каждого значимого действия |
| Процедурная | Правила и порядок работы | «Скидку выше 10% согласует руководитель» | Редко, при изменении правил |
Границы важнее названий. Факт о клиенте живёт, пока он верен; эпизод — пока полезен для истории отношений; правило — пока не изменился порядок работы. Если все три вида лежат одной кучей без типа и даты, через месяц поиск вернёт старый прайс, а правило будет звучать как чьё-то мнение.
Как память работает по кругу
Между сессиями память — это цикл: заметить, отобрать, записать, найти, подставить. Схема показывает шесть шагов и два места, где цикл рвётся чаще всего.
Рвётся цикл предсказуемо. На шаге отбора в память уходит всё, что жаль потерять, — и полезное тонет в пересказах. На шаге записи старые значения остаются рядом с новыми, и агент либо берёт первое попавшееся, либо перестаёт понимать, какому верить.
Проверить цикл можно на живом примере: возьмите недавнюю переписку с клиентом и отметьте, что из неё должно было пережить сессию. Обычно из десяти сообщений в память идут одно-два: канал связи, договорённость, ограничение. Остальное — история: она нужна для разбора, а не для работы.
Где хранить: файл, база с поиском, граф связей
Выбор места — вопрос задач, а не вкуса. Рабочих вариантов три, и они неплохо сочетаются друг с другом.
- Файл или таблица рядом с агентом. Факты о клиенте, реквизиты, договорённости, правила работы. Видно глазами, легко править руками, не нужны дополнительные сервисы: для сотни записей этого достаточно.
- База с поиском по смыслу (векторное хранилище). Нужна, когда записей тысячи: поиск подбирает близкие по смыслу записи, а не только точные совпадения. Плюс — масштаб, минус — обслуживание и аккуратные ключи, иначе находятся записи не про того клиента.
- Граф связей между сущностями. Клиент, сделка, письмо, счёт связаны между собой. Нужен там, где важен вопрос «что с чем связано»: авторы Mem0 отмечают, что графовая версия памяти дала около 2% прироста к общей оценке на бенчмарке LOCOMO против обычной.
На практике получается комбинация: правила и профиль — в файле, история действий — в базе, связи — по мере необходимости. Начинать разумно с файла: пока записей меньше сотни, поиск по смыслу решает задачу, которой ещё нет.
Отдельный вопрос — что агент имеет право делать с памятью сам: стирать записи, менять договорённости, обещать скидку. Это уже про полномочия, которые мы разбирали в статье про уровни автономии ИИ-агента.
Что запоминать, а что не запоминать
Отбор — самая недооценённая часть работы. Лишняя запись не просто занимает место: она попадает в контекст и размывает внимание модели. Chroma в исследовании Context Rot проверила 18 моделей и показала, что с ростом длины входа точность падает — неравномерно, но у всех. При этом классический тест «иголка в стоге сена» эту деградацию не ловит: он проверяет совпадение слов, а не работу со смыслом.
Простое правило отбора: в память идёт то, что понадобится в другой сессии и без чего решение будет другим. Профиль, канал связи, согласованные условия, ограничения вроде «не звонить до десяти», история значимых действий.
Не идёт: пересказ диалога целиком, промежуточные рассуждения, всё, что можно перечитать в первоисточнике — письме, счёте, договоре. Отдельная строка — догадки: запись «клиент недоволен» непроверяема, через месяц она станет ложью. Если факт нельзя подтвердить ссылкой на письмо или на действие, в долговременную память он не попадает — так же, как в журнале действий агента запись без основания считается бесполезной.
Как память превращается в свалку
Свалка собирается из четырёх привычек, и каждая из них выглядит разумно в момент появления.
- Писать всё подряд. Кажется, что память — это архив и чем больше, тем лучше. На деле каждая лишняя запись — лишний шум в контексте следующего ответа.
- Не чистить устаревшее. Сменился контакт, поставщик, цена — старая запись осталась, и агент достаёт обе, выбирая наугад.
- Хранить без даты и источника. Через полгода невозможно понять, актуален факт или относился к прошлой сделке.
- Складывать в одно место факты, правила и историю. Поиск по такому хранилищу возвращает правило, когда нужен факт, и наоборот.
Цена мусора измерима. Авторы LongMemEval разложили долговременную память на три этапа — индексирование, поиск и чтение — и показали, что точность проседает уже на чтении: чем больше в контексте постороннего, тем хуже модель достаёт нужное. То есть отбор памяти — это не только экономия, но и точность ответов.
Как память превращается в свалку
- Записывают всё подряд: и решения, и пересказ диалога.
- Не чистят устаревшее: рядом живут старый и новый контакт.
- Хранят без даты: непонятно, к какой сделке относится факт.
- Смешивают факты, правила и историю в одном списке.
Что делает отбор
- В память попадает то, что нужно в другой сессии.
- У каждой записи есть тип, дата и источник.
- Новая подтверждённая запись вытесняет старую.
- Факты, правила и история лежат раздельно.
Экономия идёт приятным бонусом: авторы Mem0 на бенчмарке LOCOMO получили 26% прироста оценки LLM-судьи против базовой памяти OpenAI, а против подхода «вся история в контексте» — p95-задержку ниже на 91% и расход токенов меньше более чем на 90%.
Что проверить перед тем, как включать память в работу
Пять вопросов, на которые стоит ответить до внедрения, а не после первого сбоя.
- У каждой записи есть дата и источник? Без них нельзя отличить актуальный факт от вчерашнего.
- Кто и когда чистит память? Нужны ответственный и регулярность: раз в месяц — минимум.
- Что делать при противоречии записей? Правило простое: новая запись с подтверждением вытесняет старую, обе рядом не живут.
- Что именно попадает в контекст в новой сессии? Короткий отбор под текущую задачу, а не вся память целиком — иначе теряется весь смысл отбора.
- Как измерить результат? Простейшая метрика — сколько раз клиент повторил уже сказанное. Порог в 5% повторных уточнений — наши ориентиры, а не отраслевой стандарт.
Если на первые три вопроса ответа нет, включать память рано: она быстро станет источником ошибок, которые дороже, чем отсутствие памяти.
С чего начать
Начать можно за день: завести одно место для фактов и правил, договориться, что туда попадает, и включить очистку по дате. Это работа, которую видно глазами, — без новых сервисов и подписок.
Дальше — по потребности: поиск по смыслу, когда записей стало много; связи между сущностями, когда агент путает письмо со счётом, а клиента — с подрядчиком. Такую память мы собираем вместе с ИИ-ассистентами и связками почты, CRM и мессенджеров, а стоимость владения считаем заранее — об этом была статья про стоимость владения ИИ-агентом. Примеры похожих внедрений — в разделе кейсов, порядок работы описан в подходе, а задачу можно обсудить на странице контактов.
Разберём, что из ваших клиентских данных должно жить в памяти агента, а что — только в первоисточнике.
Получить диагностикуИсточники
- LongMemEval: Benchmarking Chat Assistants on Long-Term Interactive Memory (ICLR 2025) — 500 отобранных вручную вопросов в масштабируемых историях диалогов «пользователь — ассистент»; коммерческие ассистенты и длинноконтекстные модели показывают падение точности на 30% при запоминании информации в продолжительных взаимодействиях (в репозитории бенчмарка указано падение 30–60% при чтении полных историй на 115 тыс. токенов вместо только сессий с нужными сведениями); память разложена на три этапа — индексирование, поиск, чтение; оцениваются пять способностей: извлечение информации, рассуждение между сессиями, временные рассуждения, обновление знаний, отказ от ответа.
- Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory (arXiv:2504.19413, апрель 2025) — на бенчмарке LOCOMO: 26% относительного прироста по метрике LLM-as-a-Judge против системы памяти OpenAI, графовая версия памяти — примерно на 2% выше базовой конфигурации по общей оценке; против подхода «вся история в контексте» p95-задержка ниже на 91% и экономия токенов более 90%; сравнение велось с шестью категориями базовых решений (системы с памятью, RAG с разными размерами фрагментов, полный контекст, открытая и проприетарная память, платформа управления памятью).
- Chroma — Context Rot: How Increasing Input Tokens Impacts LLM Performance (2025) — оценка 18 моделей, включая ведущие закрытые и открытые: с ростом длины входа точность падает неравномерно у всех; классический тест Needle in a Haystack измеряет только лексическое совпадение и недооценивает деградацию; среди задач — разговорный вопрос-ответ на LongMemEval, а также влияние отвлекающих фрагментов.
- LangChain Docs — Memory overview (2025) — краткосрочная память привязана к сессии (потоку) и хранится в состоянии агента через контрольные точки, долговременная — между сессиями, в произвольных пространствах имён; виды долговременной памяти: семантическая (факты), эпизодическая (опыт), процедурная (инструкции); обновление возможно «на горячем пути» решением агента либо фоновой задачей; отмечено, что модели «отвлекаются» на устаревшее содержимое и что полная история может не поместиться в контекст.