Память ИИ-агента: чтобы клиента помнили

Вторник, 09:12. Оператор поддержки открывает четвёртое сообщение от одного и того же клиента: «Как мы договорились на прошлой неделе, установку перенесли на более ранний срок». О прошлой неделе оператор не знает ничего: тот разговор шёл в другом канале и в другую смену. Чтобы восстановить контекст, он задаёт три вопроса и тратит четыре минуты. За день этот круг повторяется ещё двенадцать раз. Теряется не только время: ощущение клиента «здесь меня знают» обнуляется при каждом обращении.

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

Что именно хранит память агента?

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

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

Почему «вставить всю переписку в модель» — это не память?

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

Работает другой подход: резюмирование. Когда разговор закончен, агент извлекает из него только то, что должно сохраниться, и записывает как отдельные пункты. «Клиент попросил перенести установку на 14 марта, согласовано» — это пункт. «Здравствуйте, как дела» — нет. Решение не оставляют модели: список полей, которые вообще можно извлекать, задаётся заранее. То, чего агент не должен записывать никогда, описывается через Guardrails, и поскольку эти границы проверяются в момент выполнения, объяснение «сегодня модель повела себя иначе» перестаёт работать.

Что заслуживает постоянной памяти, а что должно устареть?

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

Тип данных	Где хранить	Пример срока	Обоснование
Язык общения и форма обращения	Постоянная память о клиенте	Пока клиент не изменит	Меняется редко, ошибку легко исправить
Открытый заказ или дата установки	Карточка CRM, память лишь ссылается	До закрытия сделки	Источник правды должен быть один
Жалоба и как её решили	Постоянная память, с датой	Например, 12 месяцев	Нужно, чтобы видеть повторяющуюся проблему
Реквизиты оплаты	Нигде, агент не должен их видеть	Нет	Хранение не даёт деловой пользы
Настроение в моменте, резкий тон	Только контекст сессии	Удаляется в конце разговора	Ярлык на человеке порождает неверное поведение

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

Откуда память берёт данные: диалоги, CRM или база знаний?

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

Связка источников окупается там, где агент может действовать. Пункт «перенести установку раньше» перестаёт быть заметкой, когда он ещё и создаёт задачу в CRM: память превращается из записи в решение. О том, как это накопление используется перед встречей, мы отдельно писали в материале про подготовку брифинга по клиенту за пять минут: там память полезна именно как готовое резюме, а не как сырая история.

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

Как выглядит ложное воспоминание и как его поймать?

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

Практический способ поймать все три — требовать, чтобы рядом с утверждением было основание. Если агент говорит «установку перенесли на 14 марта», должно быть видно, из какой записи это взято. Ровно для этого существует След выполнения: параметры каждого действия, результат, длительность и тот, кто согласовал, лежат в одном потоке, и вопрос «откуда агент это взял» закрывается журналом, а не догадками. Когда ошибка найдена, у исправления тоже есть место: на экране обучения ИИ неверный ответ правится, а одобренные примеры попадают в промпт агента и задают направление следующим ответам.

Когда «он меня помнит» начинает раздражать?

У памяти есть порог комфорта. Клиент спокойно относится к тому, что помнят сказанное им самим: фраза «в прошлый раз вы предпочли переписку на английском» никого не задевает. Но если помнят то, чего он не говорил, а система вывела сама, это настораживает: заметка вроде «бюджет, похоже, ограничен» портит отношения, даже когда она верна. Правило простое: в памяти живут заявления клиента и ваши формальные записи, а не выводы о характере или намерениях.

Второй порог — канал. То, что в переписке звучит заботливо, в разговоре голосом может прозвучать слишком близко. Где именно голосовому агенту стоит остановиться, мы разбирали в материале про голосовых ИИ-агентов на телефоне. Когда память используется в звонке, короткое подтверждение («у нас записана установка на 14 марта, верно?») работает и как проверка, и как вежливость.

Третий порог — язык. Один и тот же клиент может начать на русском и продолжить на английском; если сохранённое предпочтение не обновляется, агент упрямо отвечает не на том языке. Решения о переводе и локализации в многоязычных продажах нельзя принимать в отрыве от памяти: язык — самое подвижное и самое заметное поле памяти.

Что требует защита персональных данных от хранимого контекста?

Технически память — это возможность продукта, юридически — обработка данных. У вас должен быть письменный ответ на три вопроса: какие данные вы храните, с какой целью и как долго. Поле без сформулированной цели в памяти не место; «пригодится потом» целью не считается. Срок хранения задаётся по каждому полю отдельно, единый срок на всё не работает: языковое предпочтение и история жалоб живут по разным календарям.

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

Более широкую регуляторную картину даёт материал про управление ИИ и требования EU AI Act для небольшой компании: он охватывает и вашу политику памяти. Список полей, сроки хранения и порядок удаления в большинстве команд оказываются приложением к тому же документу.

Как команде проверять память, не превращая это в проект?

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

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

Какие тесты нужно пройти до запуска?

Агент с памятью ломается иначе, чем агент без неё: ошибка всплывает не в первом разговоре, а в третьем. Поэтому тестируют сериями, а не одиночными сообщениями. Прогоните минимум четыре сценария. Разговор с одним клиентом в три разных дня. Изменение факта во втором разговоре и проверка, какая версия осталась в третьем. Диалог с двумя разными людьми с одинаковыми именами. И просьба клиента «забудьте это».

Для этого и существует панель Тест и предпросмотр: агента пробуют вживую до публикации, в реальных сценариях видят и ответы, и действия, и донастраивают его прежде, чем это заметит клиент. Ещё одна полезная привычка — не ставить запись в память на автоматическое согласование в первые недели. Контроль согласования позволяет для каждого типа действия отдельно выбрать, выполняется оно само или ждёт вас, так что поведение записи можно понаблюдать в бою и только потом отпустить.

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

Как выглядит план внедрения на четыре недели?

Первая неделя — объём: запишите, какие пять полей будут запоминаться, и держите список коротким. Команды, начинающие с большего числа полей, обычно всё равно урезают его к третьей неделе. Вторая неделя — порядок источников и границы: приоритет между CRM, диалогом и базой знаний фиксируется письменно, доступ агента сужается, запрещённые для записи поля описываются. Третья неделя — тесты: четыре сценария выше прогоняются, запись в память остаётся на ручном согласовании.

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

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

Если хотите проверить это на своей команде, откройте бесплатный аккаунт Rocketly и начните с одного агента и одного поля памяти.

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

Передаёт ли память агента данные клиента в модель?

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

Что происходит, если клиент просит его забыть?

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

Через какое время память даёт заметный эффект?

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

Должны ли несколько агентов делить одну память?

Факты о клиенте делить можно: для вас клиент один человек. А знания компании стоит разделять по агентам: источник, который читает агент продаж, не обязан совпадать с источником агента поддержки, и чаще всего не должен.