Чат-бот с памятью: что хранить, а что брать из CRM

Фраза «сделаем чат-бота с памятью» звучит как одна функция. На практике за ней скрываются разные задачи: сохранить контекст текущего разговора, вспомнить устойчивое предпочтение клиента, получить свежий статус из CRM, найти правило в базе знаний или продолжить незавершённый workflow.

Клиент назвал компанию десять сообщений назад — это контекст сессии. Неделю назад попросил всегда отправлять документы по электронной почте — кандидат в долговременную память. Текущий статус заказа — данные CRM или ERP. Правила возврата — корпоративная база знаний. Ожидание согласования менеджера — состояние процесса.

Смешать всё это в одно хранилище технически можно. Делать так не стоит.

Хорошая память ИИ — не способность хранить как можно больше, а способность получить нужный тип информации из правильного источника и понять, когда старому факту уже нельзя доверять.

Именно с этого стоит начинать проектирование чат-бота с памятью для бизнеса.

История чата, память, CRM и база знаний — разные слои

История переписки — ещё не долговременная память

Самый простой вариант «памяти» — каждый раз передавать модели предыдущие сообщения.

Пока диалог короткий, подход работает. Клиент сообщил номер заказа, а через две реплики спросил о возврате — системе не приходится запрашивать номер повторно.

Это краткосрочная память, или состояние текущей сессии. Microsoft относит к ней последние реплики, результаты вызовов инструментов и промежуточное состояние задачи. LangGraph также отделяет память внутри одного thread от пользовательских и прикладных данных, которые сохраняются между сессиями.[1][2]

Проблема начинается, когда историю чата принимают за полноценный архив. Разговор может состоять из сотен сообщений, но большая часть старого текста уже не нужна для текущего вопроса. LangGraph предусматривает сокращение, удаление и суммаризацию истории, а Yandex AI Studio Assistants API — отдельные параметры усечения prompt по лимиту токенов или числу последних сообщений.[2][3]

Контекстное окно модели — рабочий стол, а не архив компании. Если факт понадобится через месяц, его нужно сохранить отдельно и уметь найти. Если он утратил актуальность — обновить или удалить.

Пять классов данных

У бизнес-ассистента обычно есть минимум пять разных слоёв.

Что нужно системе	Пример	Где рациональнее хранить
Контекст разговора	«Речь всё ещё о заказе № 123»	история текущей сессии
Долговременная память	предпочитаемый канал связи	хранилище памяти пользователя
Оперативные бизнес-данные	статус заказа, сумма, ответственный	CRM, ERP или исходная система
Корпоративные знания	регламент возврата, инструкция, каталог	база знаний / RAG
Состояние процесса	заявка создана, ждём согласования	workflow / state store

Это разделение важнее выбора конкретной векторной базы или фреймворка. AWS называет единое неразделённое хранилище антипаттерном: контекст разговора смешивается с устойчивыми знаниями, а в активную задачу попадают устаревшие или нерелевантные сведения.[4]

Не спрашивайте сначала, какую базу использовать для памяти. Сначала определите, какие данные вообще имеют право стать памятью.

Что стоит запоминать между разговорами

Долговременная память полезна, если факт:

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

Например, клиент предпочитает электронную почту, сотрудник — определённый формат отчёта, а пользователь внутреннего ассистента обычно работает с конкретным проектом. Microsoft приводит пользовательские предпочтения и краткие итоги прошлых разговоров как типичные примеры долговременной памяти.[1]

Но не каждое предложение пользователя должно автоматически становиться постоянным фактом. Рассмотрим условную реплику:

Клиент: пока отправляйте всё на старый адрес.

Это может быть временным решением на один день, а может быть новым устойчивым предпочтением. Из одной фразы система этого не знает.

Между разговором и долговременной памятью нужен отдельный шаг: извлечь кандидата, проверить тип данных, определить область действия и при необходимости запросить подтверждение. Google Memory Bank следует похожему принципу: извлекает значимую информацию в пределах заданной области, сопоставляет её с существующими записями и может создать, обновить или удалить воспоминание при появлении новых либо противоречащих сведений.[5]

Память должна обновляться, а не просто расти.

Почему статус заказа нельзя «помнить»

Допустим, вчера ассистент получил из CRM ответ:

Заказ № 123 находится на комплектации.

Система сохранила это как долговременную память. Сегодня заказ уже передан в доставку. Клиент спрашивает статус, а ассистент достаёт вчерашнее «воспоминание».

Формально память сработала. Бизнес-процесс — нет.

Статус заказа, задолженность, остаток на складе, ответственный менеджер, доступный лимит и дата следующего действия — меняющиеся операционные факты. Их источник истины находится не в памяти ИИ, а в бизнес-системе.

Схема должна быть другой:

пользователь → идентификация → актуальные данные CRM или ERP → релевантный контекст → модель → ответ.

Память помогает понять, что нужно клиенту. CRM сообщает, что происходит сейчас. Если ассистент работает с CRM, права на чтение и запись лучше проектировать отдельно для каждого действия — этот вопрос подробнее разобран в материале о правах доступа ИИ-агентов в CRM.

База знаний — тоже не память клиента

Документы компании и историю пользователей можно искать одной технологией, например семантическим поиском. Но у этих данных разные владельцы и жизненный цикл.

Политика возврата действует для многих клиентов и управляется компанией — это корпоративное знание. Предпочтение конкретного клиента относится только к нему — это память пользователя. Запись о том, что модель однажды решила разрешить возврат без документов, может быть ошибочным выводом; превращать её в корпоративное правило нельзя.

AWS разделяет контекст сессии, постоянную память и внешние корпоративные корпуса для RAG именно потому, что этим классам информации нужны разные правила хранения и извлечения.[4]

Если проблема находится в документах — версии конфликтуют, старые файлы остаются в индексе, а права доступа не обновляются, — память пользователя её не решит. Сначала нужно наладить обновление базы знаний для ИИ.

Как устроить рабочую архитектуру чат-бота с памятью

Для поддержки или продаж процесс можно разделить на семь шагов.

Определить пользователя и область данных. Система должна понимать, к какой компании, клиенту, сотруднику или проекту относится разговор. Память разных пользователей нельзя искать в общем пространстве без обязательной фильтрации. AWS рекомендует разделять ресурсы памяти по сессии, пользователю или другой области доступа и не считать общее пространство безопасным значением по умолчанию.[6]
Восстановить краткосрочный контекст. Поднять последние сообщения или компактное состояние текущего разговора. Старую историю при необходимости сократить или суммаризировать.
Найти только релевантную долговременную память. Не загружать весь профиль клиента в каждый prompt. Для вопроса о доставке предпочтительный формат коммерческого предложения, скорее всего, не нужен.
Получить свежие операционные данные. Статусы, суммы, ответственных и другие изменяемые поля запросить из CRM, ERP или внутреннего API.
Найти корпоративные знания. Если для ответа нужен регламент или документация, выполнить отдельный поиск по базе знаний.
Сформировать ответ или действие. Модель получает уже собранный контекст, а не всё, что компания когда-либо сохраняла о клиенте.
Решить, появилось ли новое долговременное воспоминание. Результат разговора не должен автоматически становиться памятью. Сначала нужно определить источник, устойчивость факта, область действия и срок хранения.

Архитектура чат-бота с памятью: запрос проходит идентификацию, сбор контекста из сессии, памяти, CRM и базы знаний, после чего модель формирует ответ, а система проверяет кандидата на сохранение — Память — один из источников контекста, а не центральное хранилище всех данных.

Так память становится одним компонентом процесса, а не центральным складом всех данных компании.

Самая опасная ошибка — сохранить вывод модели как факт

Память создаёт необычный тип ошибки: неверный ответ может пережить сам разговор. Модель ошиблась один раз, система сохранила её вывод, а через неделю достала его как предыдущий опыт. Новое решение опирается уже не на исходные данные, а на старую галлюцинацию.

Поэтому для каждой записи полезно хранить:

область действия;
источник и ссылку на исходное событие;
время появления;
тип факта;
срок действия или правило пересмотра;
способ исправления и удаления.

Запись в память должна проходить проверки не только на входе публичного API. AWS рекомендует валидировать все пути записи, включая результаты инструментов, межагентные сообщения и операции консолидации, а также не допускать распространения галлюцинаций между сессиями.[6]

Память без происхождения факта быстро превращается в удобную, но плохо проверяемую версию реальности.

Почему большая память может сделать ассистента медленнее

Чем больше данных система ищет, обрабатывает и передаёт модели, тем длиннее prompt, выше задержка и стоимость. Поэтому проблему «ассистент забывает» нельзя автоматически лечить увеличением контекста.

AWS рекомендует избирательное извлечение вместо массовой загрузки и постоянное сжатие или очистку длинных сессий.[7] Иногда нужно сохранить конкретный факт. Иногда — улучшить поиск. Иногда — заново получить значение из CRM. А иногда система просто передаёт модели слишком много текста.

Если время ответа уже стало проблемой, полезно разложить задержку по всей цепочке — этот подход описан в статье о том, почему ИИ-ассистент отвечает медленно.

Как проверить память на пилоте

Пилот чат-бота с памятью стоит проверять не вопросом «он меня помнит?», а набором сценариев.

Клиент сообщает факт и задаёт уточнение в той же сессии. Затем начинает новый разговор, меняет сохранённое предпочтение, а в CRM одновременно обновляется оперативное поле. Другой пользователь задаёт похожий вопрос. Наконец, долговременное хранилище временно становится недоступно.

Для каждого сценария нужен ожидаемый результат:

Сценарий	Что должна сделать система
Уточнение в той же сессии	использовать недавний контекст без повторного вопроса
Новый разговор того же клиента	извлечь только разрешённые долговременные сведения
Клиент изменил предпочтение	обновить прежнюю запись, а не хранить два противоречащих факта
Статус изменился в CRM	получить актуальное значение из CRM, не доверять старому контексту
Похожий вопрос другого пользователя	не извлечь память первого клиента
Долговременная память недоступна	перейти в ограниченный режим и честно запросить нужные сведения

Полезные метрики пилота:

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

Последний сценарий часто забывают. Ассистент поддержки не обязан полностью переставать работать из-за недоступности долговременной памяти. AWS предлагает заранее определить режимы деградации: полный, только с контекстом текущей сессии и полностью без состояния. В ограниченном режиме система сообщает о недоступности прошлых разговоров и заново запрашивает необходимые сведения.[8]

Когда память вообще не нужна

Не каждому ИИ-ассистенту требуется долговременная память.

Для разовой обработки загруженного документа достаточно состояния текущей операции.
Для общих вопросов по корпоративной документации может хватить RAG и истории текущего диалога.
Если все необходимые сведения однозначно получаются из CRM по идентификатору клиента, не нужно копировать их в ещё одно хранилище только ради слова «память».
Если сайт каждый раз просит повторно заполнить известные поля, возможно, исправить нужно форму и профиль пользователя, а не добавлять LLM-memory.

Технически память можно добавить почти в любой ассистент. Практически она нужна только там, где сохранённый контекст действительно меняет следующий полезный шаг.

Вывод: память — не копия всех данных

Чат-бот с памятью не должен помнить клиента так, как человек вспоминает прошлый разговор. Для бизнес-системы полезнее другая модель:

Диалог хранит недавний контекст; долговременная память — устойчивые факты и предпочтения; CRM и ERP отвечают за актуальное состояние бизнеса; база знаний — за корпоративные правила; workflow — за ход операции.

Тогда у каждого факта появляется владелец, срок жизни и способ проверки.

Первый шаг перед разработкой — взять один процесс и выписать все сведения, которые использует сотрудник. Напротив каждого указать: откуда значение появляется, как быстро устаревает, кому принадлежит и где должно храниться. После такой таблицы обычно становится понятно, что действительно является памятью ИИ, а что ею никогда не должно становиться.

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

Частые вопросы

Что такое память ИИ?

В прикладной ИИ-системе память — сохранённая информация, которую ассистент может использовать после исходного взаимодействия. Обычно отдельно выделяют краткосрочный контекст текущей сессии и долговременные сведения между сессиями.

Чем память ИИ отличается от контекста?

Контекст — информация, доступная модели при конкретном вызове. Память может храниться отдельно и извлекаться в этот контекст только тогда, когда она нужна.

Можно ли просто сохранять всю историю чата?

Историю сохранять можно, но передавать её целиком модели при каждом запросе обычно нерационально. Длинные диалоги приходится сокращать, суммаризировать или выбирать из них релевантные фрагменты.[2]

Нужно ли хранить данные CRM в памяти ИИ?

Для изменяемых операционных данных лучше оставлять CRM или ERP источником истины и получать актуальное значение при выполнении запроса. В память имеет смысл помещать только сведения, для которых действительно нужен перенос контекста между разговорами.

Может ли ИИ сам решать, что запомнить?

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

Чат-бот с памятью: что ИИ должен помнить, а что брать из CRM