AI-консультант в мессенджерах: разговор ведёт модель, заказ оформляет код

Клиент пишет тогда, когда менеджера может не быть

Значительная часть покупателей интернет-магазина начинает выбор не на сайте, а в мессенджере. В Telegram, WhatsApp и других каналах они спрашивают, есть ли товар, сколько он стоит, какой вариант подойдёт, как оплатить и когда придёт доставка по Украине через Новую Почту.

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

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

Для этого потока собрали одного AI-консультанта с общим ядром для разных каналов. Он ведёт разговор и помогает выбрать. Всё, где ошибка влияет на деньги, доставку или состав заказа, вынесено в обычный предсказуемый код либо передаётся менеджеру.

Одна переписка проходит через несколько исполнителей

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

Если клиент определился, разговор переходит в контур оформления. Код считает сумму, проверяет адрес, создаёт счёт и формирует структурированные данные для CRM. Если приходит фото, голосовое или нетиповой вопрос, автоответ в этой переписке останавливается и подключается человек.

Модель здесь не сценарный бот с веткой "нажал А - получил Б". Она сама выбирает инструмент под смысл реплики. Но инструмент - это не абзац в промпте, а функция над реальными данными магазина с определённым входом и результатом.

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

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

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

Каталог пришлось подготовить раньше агента

В сырой выгрузке товары не образуют аккуратную таблицу "размер плюс цвет". У одной категории есть размер и материал, у другой - собственная ось характеристик, у третьей часть свойств вообще отсутствует. Вариации динамические, и универсального набора колонок для всего ассортимента нет.

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

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

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

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

Так подготовка каталога становится частью качества консультанта. Аккуратные группы, признаки и актуальные остатки дают модели материал для полезного ответа, а их отсутствие ничем не компенсируется.

Каждое строгое правило выросло из конкретной ошибки

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

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

Клиент этой самопроверки не видит. Агент исправляет корзину и продолжает разговор дальше, не превращая собственную ошибку в отдельное сообщение и лишнюю тревогу.

Эти правила не делают модель детерминированной целиком. Они ограничивают области, где свобода формулировки способна повредить заказу, и оставляют гибкость там, где она помогает понять человека.

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

Сумму, оплату и доставку модель не решает

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

Поэтому система разделена на два контура:

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

Счёт также создаётся вне AI. Код поддерживает полную оплату и предоплату, отдаёт ссылку клиенту и ждёт подтверждение платёжного сервиса. Реплика в чате остаётся репликой, пока внешний источник не сообщил о фактическом платеже.

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

Жёсткий конец есть и у цикла инструментов, и у памяти диалога

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

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

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

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

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

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

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

Движок и канал можно заменить отдельно

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

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

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

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

Три обрывка складываются в одну мысль клиента

Люди пишут в мессенджере не абзацами. Клиент отправляет "привет", затем "а такое есть" и через несколько секунд "и сколько". Формально это три сообщения, по смыслу один вопрос.

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

Менеджер подключается вместе с контекстом

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

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

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

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

Незавершённая корзина возвращается в тот же канал

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

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

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

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

Неудачный диалог пополняет базу знаний

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

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

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

Магазин получает консультацию в любое время, но не автономного продавца

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

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

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