Есть два одинаково неприятных разговора с поддержкой. В первом бот каждую минуту забывает, что клиент уже назвал номер заказа. Во втором внезапно вспоминает старую личную деталь, которую человек вообще не ожидал увидеть в текущем диалоге.
Поэтому вопрос «должен ли AI помнить клиента?» для меня слишком общий. Полезнее спросить: что именно нужно помнить для решения текущей задачи, как долго это остаётся актуальным и понимает ли сам клиент, откуда взялся этот контекст. Чат-бот с памятью нужен прежде всего затем, чтобы человек не повторял уже сообщённое и при этом понимал границы сохранённого контекста.
Память может сделать поддержку спокойнее. Но только если она сокращает повторение, а не превращается в бесконечный склад сведений о человеке.
Контекст одного разговора — самый понятный уровень памяти
Если клиент уже сообщил номер заказа и уточнил, что речь о возврате, система должна сохранить это внутри текущего диалога. Иначе каждая новая реплика начинается почти с нуля, а человеку приходится обслуживать память бота.
Здесь цель проста: не просить повторять то, что уже известно и всё ещё относится к текущей задаче. Контекст должен включать не только слова клиента, но и выполненные проверки: какой заказ найден, какой статус прочитан, какое правило применено.
Я бы завершала session context вместе с диалогом или переводила только нужную часть в историю обращения. Не всё, что было полезно на минуту, должно становиться долговременным профилем клиента.
Проверяемые источники: Microsoft — Dynamics 365 Contact Center overview
История обращений и профиль клиента — разные вещи
Предыдущее обращение о сломанном товаре может быть важно, если человек снова пишет по тому же заказу. Но оно не обязательно нужно для вопроса о новой покупке. История — это события. Профиль — более устойчивые сведения, которые помогают обслуживать человека в разных ситуациях.
Я бы не смешивала эти слои. Оператору полезно видеть недавние связанные обращения. AI должен получать только те записи, которые действительно помогают текущему intent. Профиль можно использовать для языка, выбранного канала или подтверждённого статуса клиента, если компания имеет на это основание.
Чем шире автоматический доступ к прошлому, тем легче получить странный ответ, в котором система связывает несвязанные события. Для клиента это выглядит не как забота, а как вторжение.
Проверяемые источники: Microsoft — Dynamics 365 Contact Center overview
Долговременная память должна быть видимой и управляемой
OpenAI в пользовательской памяти отдельно развивает идею контролей: человек может посмотреть, что система помнит, управлять записями и отключать использование памяти. В корпоративной поддержке детали реализации будут другими, но сам принцип мне кажется правильным.
Если AI использует устойчивое предпочтение или профильный факт, пользователь не должен удивляться его происхождению. Для чувствительной информации особенно важно понимать, кто создал запись, из какого источника она получена и можно ли её исправить или удалить по правилам компании.
Я бы избегала скрытой «интуитивной» памяти, где никто не может объяснить, почему старый факт продолжает влиять на ответы. Лучше меньше контекста, но с понятным сроком жизни и владельцем.
Проверяемые источники: OpenAI — Memory and new controls for ChatGPT
Устаревший контекст иногда хуже отсутствующего
Клиент сменил адрес, тариф, контактное лицо или предпочтительный канал. Если AI продолжает считать старое значение актуальным, память начинает производить уверенные ошибки. Это особенно заметно, когда система сама подставляет сведения в действия.
Каждому устойчивому полю нужен источник и механизм обновления. Некоторые факты берутся из CRM или учётной системы и не должны копироваться в отдельную «память модели». Другие можно хранить как предпочтение, но показывать дату и возможность пересмотра.
Для меня хороший вопрос к любому remembered fact: где лежит source of truth? Если ответа нет, я бы не использовала это значение для важного действия.
Проверяемые источники: Microsoft — Dynamics 365 Contact Center overview · NIST — AI Risk Management Framework
Персонализация не оправдывает лишний сбор данных
Иногда под персонализацией понимают максимальное количество информации. В поддержке это редко нужно. Чтобы объяснить статус доставки, системе не требуется знать всю историю покупок человека. Чтобы подобрать язык ответа, не нужен его полный профиль поведения.
Я бы использовала принцип минимально достаточного контекста: взять ровно те данные, которые помогают решить текущий вопрос, и дать доступ только нужному сервису. Это уменьшает и риск, и количество случайных связей в ответе.
NIST AI RMF предлагает учитывать контекст использования и риски системы на протяжении жизненного цикла. В customer support этот подход хорошо переводится в простой выбор: прежде чем добавить новую память, объясните, какую ошибку или повторение она уменьшает и какой новый риск создаёт.
Проверяемые источники: NIST — AI Risk Management Framework
Хорошая память ощущается как отсутствие лишних повторов
Я бы проверяла память на живых сценариях. Клиент продолжил разговор через другой канал — система сохранила нужный контекст? Открыл новый вопрос через месяц — старый случай не мешает? Исправил контактные данные — AI перестал использовать прежние?
Полезно отдельно измерять повторные запросы одних и тех же сведений. Если человек трижды называет номер заказа в одном кейсе, память не работает. Если система автоматически вытягивает десять старых обращений, а оператору приходится разбирать шум, памяти уже слишком много.
Лучший результат довольно незаметен. Клиент просто не повторяет то, что уже сказал, и не удивляется чужому контексту в ответе.
Проверяемые источники: OpenAI — Memory and new controls for ChatGPT · Microsoft — Dynamics 365 Contact Center overview
Что обычно хочется уточнить
Что должен помнить AI-чат-бот о клиенте?
Минимум — контекст текущего вопроса и уже выполненные проверки. Долговременные сведения стоит хранить только когда они реально помогают в будущих обращениях и имеют понятный источник, срок жизни и правила доступа.
Нужно ли хранить всю историю диалогов для персонализации?
Нет. История полезна выборочно. Я бы извлекала связанные обращения, а не отправляла модели весь архив клиента на всякий случай.
Как избежать устаревшей памяти AI?
У каждого значимого значения должен быть source of truth и механизм обновления. Профильные записи полезно датировать, а чувствительные и изменяемые факты не дублировать без необходимости.
Мне нравится память, которую клиент почти не замечает. Не нужно повторять номер заказа, оператор получает продолжение разговора, старые факты не всплывают без причины. Если память создаёт больше вопросов, чем снимает, её стоит уменьшить, а не делать умнее.
Если продолжать с точки зрения клиентского опыта для «чат-бот с памятью»: Как объединить AI-поддержку в Telegram, на сайте и в почте · Как подключить AI к базе знаний компании · Когда AI должен передать обращение оператору.