Память в ИИ-агентах: как заставить помнить контекст между сессиями

Любой ИИ-агент из коробки страдает амнезией. Каждый запрос для него первый. Менеджер три недели обсуждал с агентом тендер, а в понедельник тот не помнит ни компанию, ни сумму, ни сроки. Для прототипа это терпимо. Для серьёзной работы у клиента это блок.

Решается через память. Звучит просто. На практике под "памятью" в LLM прячутся три разных механизма, каждый со своими ограничениями, ценой и сценарием применения. В этом разборе показываю где какой тип брать, через что собирать, во сколько обойдётся под средний SMB-проект, и где это всё ломается.

Зачем агенту вообще память

Без памяти ИИ-агент это калькулятор. Дал ему задачу, получил ответ, забыл. Это нормально для одноразовых вычислений: классифицировать письмо, сгенерить SEO-заголовок, ответить на FAQ. Если задача укладывается в один промпт, без памяти жить можно.

Проблемы начинаются, когда:

• агент ведёт длинный диалог с клиентом или сотрудником, и нужно помнить контекст разговора
• агент обрабатывает поток событий (новые заявки, изменения в CRM, входящая почта), и нужно понимать "это связано с тем, что было вчера"
• агенту скармливают большую базу знаний компании, а в один промпт это не влезает (типичная корпоративная база - 5-50 тысяч документов, легко гигабайты текста)
• бизнес требует, чтобы агент адаптировался: запомнил, что Иван Петров всегда просит безналичный расчёт, а у Анны Сидоровой аллергия на жёсткий тон

Память это не один компонент, а слой между "глупым" LLM и реальным миром. И собирать этот слой нужно с пониманием, что именно вам нужно.

Тип 1: короткая память (контекст диалога)

Самый простой случай. Внутри одного разговора с клиентом агент должен помнить, о чём шла речь.

Реализуется через передачу истории сообщений в каждом запросе к LLM. Никаких баз данных. Просто массив [{role: "user", content: "..."}, {role: "assistant", content: "..."}, ...], который растёт с каждым шагом диалога и отправляется целиком на каждый вызов.

Ограничения:

• Контекстное окно LLM ограничено. GigaChat в 2026 даёт 32 тысячи токенов, YandexGPT 8 тысяч, Claude и GPT 200 тысяч. Это ~25 страниц у GigaChat, ~6 страниц у YGPT. Долгий диалог упрётся в потолок.
• Каждый вызов оплачивается по объёму контекста. Диалог из 50 сообщений стоит в 50 раз дороже одного.

Что с этим делают:

1. Summary-память. После каждых 10-15 сообщений отдельный вызов LLM делает выжимку диалога в 2-3 абзаца, и дальше в контекст идёт выжимка + последние 5 сообщений. Контекст не растёт линейно, разговор может идти часами.
2. Sliding window. Просто храним последние N сообщений, более старые отбрасываем. Минимум усилий, но клиент жалуется "вы же говорили вчера, что..."
3. Гибрид. Хранят сводку всего разговора + последние N актуальных сообщений + список именованных сущностей (имена клиентов, номера сделок, договорённости по срокам).

Стоимость нулевая, всё хранится либо в Redis (если кратковременно) либо в самой CRM как поле "история диалога". Подходит для FAQ-ботов, ассистентов в чате на сайте, простых записных сценариев.

Тип 2: семантическая память (векторная база, RAG)

Если у бизнеса есть документация, регламенты, переписка с клиентами, история сделок - агенту это нужно отдавать селективно. Невозможно засунуть базу из 10 тысяч документов в один промпт, и не нужно.

Подход называется RAG (Retrieval-Augmented Generation, "поиск + генерация"). Если простыми словами: при каждом запросе сначала ищем по базе релевантные куски текста, потом отдаём их в LLM как часть промпта, и она отвечает.

Векторная база хранит не сами тексты (вернее, не только их), а их эмбеддинги - числовые векторы, которые отражают смысл. Похожие по смыслу тексты дают близкие векторы. На поиск по миллиону векторов уходят миллисекунды.

Главные движки на рынке:

• pgvector (расширение для PostgreSQL). Плюсы: бесплатно, ставится в одну команду, использует тот же PostgreSQL что у вас уже работает с 1С / amoCRM. Минусы: производительность ниже специализированных, для больших баз нужен тюнинг.
• Qdrant. Российский open-source, активно развивается. Плюсы: быстрый, удобный REST API, есть managed cloud. Минусы: ещё одна точка отказа.
• Chroma. Лёгкий, для прототипов идеальный. Плюсы: ставится pip install, работает без отдельного сервера. Минусы: для production слабоват, дальше 100 тысяч векторов начинает тормозить.
• Milvus, Weaviate. Тяжёлая артиллерия. Для SMB-проекта оверкилл, обычно не нужны.

Под средний проект в РФ (10-50 тысяч документов компании) pgvector или Qdrant - оптимум. Pgvector проще ставить, Qdrant быстрее для миллиона векторов.

Эмбеддинги для русского текста:

• sentence-transformers/paraphrase-multilingual на CPU - бесплатно, работает прямо на вашем VPS, качество среднее
• embeddings от GigaChat - 0,1 ₽ за 1000 токенов, качество для русского хорошее, не нужно держать модель локально
• OpenAI text-embedding-3 - 0,02 $ за 1М токенов, но требует прокси и нарушает 152-ФЗ если у вас персданные

В близкой статье разбирал Как обучить ИИ на данных компании: RAG, fine-tune и 152-ФЗ - там про обучение целиком, тут только про память.

Стоимость в реальном проекте:

• pgvector на одном VPS 4ГБ RAM: 1500 ₽/мес инфраструктура
• эмбеддинги через GigaChat для базы 10 тысяч документов: разовая закладка ~3000 ₽, далее 500-1500 ₽/мес на обновление
• разработка RAG-пайплайна под бизнес: от 80 000 ₽ до 250 000 ₽ под ключ

Тип 3: эпизодическая память (факты о пользователях и событиях)

Это то, что обычно подразумевают под "агент меня запомнил". Не "что мы обсуждали час назад" (тип 1) и не "что есть в наших регламентах" (тип 2), а "какие персональные предпочтения у конкретного клиента / сотрудника / контрагента".

Например:

• Иван Петров (контрагент ИНН 770xxx) всегда работает по безналу, не любит долгих звонков, предпочитает Telegram
• Заказ ОЗ-2401 был с задержкой по логистике, клиент остался недоволен
• Анна из бухгалтерии в марте 2026 жаловалась на дубликаты документов

Технически это отдельная таблица в БД, не вектор. Структурированные факты с привязкой к сущностям (контрагент, сделка, сотрудник). При входе пользователя в систему агент дополнительно запрашивает "какие факты у нас есть про этого человека" и подмешивает их в системный промпт.

Хранится обычно в той же базе, где живёт CRM. Реализация - расширение схемы CRM или отдельная таблица agent_facts.

Тонкость: эти факты надо создавать и обновлять. Либо вручную, либо отдельным LLM-вызовом ("проанализируй последний диалог и извлеки 0-3 факта о пользователе для долговременной памяти"). Второй вариант элегантнее, но требует контроля - модели иногда галлюцинируют факты, которых не было.

Когда какой тип брать

Простое правило для большинства случаев:

Самая частая ошибка - сразу делать "большой RAG", когда задаче хватает короткой памяти и подмешивания пары полей из CRM. Это дороже, медленнее и менее надёжно. Сложность добавляйте по мере необходимости, а не "на всякий случай".

Грабли в production

1. Качество эмбеддингов на русском. Многие открытые модели обучены преимущественно на английском. На русском поиск по смыслу даёт промахи. Лечится: embeddings от GigaChat или специализированные multilingual-модели. Под русский корпоративный текст нужно тестировать на ваших данных.

1. Чанкование документов. Засунуть весь PDF одним вектором - бесполезно. Резать на куски по 200-500 слов с перекрытием 50-100 слов. Слишком крупные куски размывают смысл, слишком мелкие теряют контекст.

1. Confidence score. Если поиск по векторной БД вернул "ничего похожего нет" (низкая косинусная схожесть), не подсовывайте мусор в промпт. Лучше дать агенту ответить "у меня нет информации по этому вопросу" чем заставить его выдумывать.

1. Шифрование персданных. Если в RAG-базе персональные данные (имена клиентов, телефоны, паспорта), 152-ФЗ требует серьёзную инфраструктуру. Часто проще сделать так, чтобы персданные не попадали в векторную БД (заменяются плейсхолдерами при индексации, подставляются в момент финального ответа).

1. Стоимость роста. RAG-база на 100 документов и на 100 тысяч документов это разные инженерные задачи. Закладывайте план роста сразу: если через год документов будет в 100 раз больше, текущая архитектура переживёт это?

Что почитать дальше

Если хочется сначала разобраться с базовой архитектурой - Что у ИИ-агента под капотом. Если планируете обучать модель на своих данных вместо RAG (а это часто хуже выходит) - RAG, fine-tune и 152-ФЗ. А Промпт-инжиниринг для бизнеса показывает как правильно составить промпт, в который потом эта память будет подмешиваться.

Если думаете внедрять

Память в ИИ-агента - это инженерная задача на 2-6 недель в зависимости от объёма базы знаний и точек интеграции. Под средний SMB-проект (база 10-30 тысяч документов, 1-2 LLM, интеграция с CRM) разработка под ключ обойдётся в 150 000 - 400 000 ₽. Поддержка с дообновлением базы и тюнингом - 8 000 - 20 000 ₽/мес.

Если у вас есть конкретный сценарий, где агенту нужна память (длинные диалоги с клиентами, корпоративная база знаний, накопление фактов о контрагентах), пришлите бриф - подберу архитектуру под ваш случай и посчитаю окупаемость до старта.