Что такое чат-бот
Чат-бот — программа, которая ведёт диалог с пользователем и решает за него задачу: отвечает на вопрос, подбирает товар, выполняет операцию в системах компании. Интерфейс может быть виджетом на сайте, экраном в мобильном приложении или мессенджером.
Термин объединяет технологически очень разные решения — от дерева кнопок до модели с доступом к каталогу. Из-за этого «у нас есть чат-бот» само по себе ничего не говорит ни о возможностях, ни о стоимости поддержки.
Три поколения ботов
| Поколение | Как работает | Гибкость | Стоимость поддержки | Основной риск | Где применим |
|---|---|---|---|---|---|
| Сценарные | Дерево кнопок и жёстких переходов | Низкая: только предусмотренные ветки | Растёт линейно с числом сценариев | Тупик «не понял вопрос» | Узкие повторяющиеся задачи: статус заказа, часы работы |
| NLU-боты | Классификация фразы в намерение, затем сценарий | Средняя: свободная формулировка, фиксированный ответ | Разметка датасета и поддержка списка намерений | Ошибка классификации уводит в чужой сценарий | Поддержка с большим потоком типовых обращений |
| LLM-ассистенты на RAG | Ответ генерируется по подключённым источникам | Высокая: заранее не описанные вопросы | Ниже по сценариям, выше по инфраструктуре и контролю качества | Выдуманные факты — цена, наличие, условия | Подбор товара, консультация в сложных категориях |
Переход между поколениями не отменяет предыдущее. В рабочей конфигурации обычно сосуществуют все три: кнопочные быстрые ответы для частых запросов, распознавание намерений для маршрутизации и генеративный слой — LLM в схеме RAG — для свободного диалога.
Почему в e-commerce решает не «умение разговаривать»
Качество формулировок у современных моделей давно перестало быть узким местом. Разница между полезным и бесполезным ботом в интернет-магазине проходит по двум линиям.
Доступ к каталогу. Бот, который не видит актуальные цены, остатки и характеристики, физически не может решить главную задачу пользователя — выбрать конкретный товар. Он выдаёт общие советы, которые пользователь уже прочитал в обзорах. Технически это решается либо RAG-схемой поверх товарного фида, либо вызовом функций магазина (function calling) — за ценой, наличием, статусом заказа.
Доступ к контексту пользователя. Просмотренные товары, содержимое корзины, история заказов, размер и предпочтения по брендам меняют ответ сильнее, чем любая настройка тона. Без этого контекста бот начинает каждый диалог с нуля и задаёт вопросы, ответы на которые уже есть в данных магазина.
Запрос пользователя
→ интент и параметры подбора
→ поиск по каталогу (фид: цена, остаток, атрибуты)
→ контекст пользователя (просмотры, корзина, история)
→ ответ + карточки товаров + следующий шаг
Это же отличает бота-консультанта от бота поддержки: первый работает в логике диалоговой коммерции и ведёт к покупке, второй — снимает нагрузку с операторов.
Как измерять
Самая частая ошибка — отчитываться количеством диалогов и сообщений. Эти цифры растут и когда бот помогает, и когда пользователь по три раза переформулирует вопрос.
| Метрика | Что показывает | Как считать |
|---|---|---|
| Доля решённых диалогов | Полезность без участия оператора | Диалоги, завершённые без эскалации / все диалоги |
| Конверсия диалога в корзину | Влияние на путь к покупке | Диалоги с добавлением товара / все диалоги |
| Выручка на диалог | Экономический вклад | Атрибутированная выручка / число диалогов |
| Разница с контрольной группой | Реальный прирост, а не самоотбор | Конверсия сессий с ботом vs без бота на A/B-тесте |
| Доля эскалаций к оператору | Нагрузка на поддержку | Переданные диалоги / все диалоги |
Сравнивать пользователей, которые открыли бота, с теми, кто не открыл, некорректно: в диалог чаще заходят люди с более выраженным намерением купить. Изолировать эффект можно только A/B-тестом, где часть трафика бота не видит.
Ориентир по пилотам AI Shopping Assistant: +33% выручки на визит, +9% конверсии и +20% среднего чека; более ранняя версия в формате квиза давала +14% конверсии в корзину.
Риски и ограждения
- Галлюцинации по цене и наличию. Самый дорогой класс ошибок: пользователь получает обещание, которого магазин не выполнит. Правило — все фактические значения приходят из систем магазина, а не из модели.
- Ответы вне зоны компетенции. Юридические, медицинские, финансовые формулировки должны быть явно запрещены промптом и отфильтрованы на выходе.
- Отсутствие человека в контуре. Претензии, возвраты, гарантийные случаи переводятся на оператора. Схема с человеком в контуре нужна не только для качества, но и как страховка при сбое модели.
- Тон и давление. Бот, который настойчиво навязывает более дорогой товар, снижает доверие быстрее, чем повышает средний чек.
- Логи без разбора. Диалоги нужно не только хранить, но и регулярно читать выборкой: там видно и реальные сценарии, и места, где бот уходит в сторону.
Чек-лист перед запуском
- Определены 3–5 задач, которые бот закрывает на старте, — по логам поддержки и поиска, а не по гипотезам.
- Подключён товарный фид с ценами и остатками; проверена частота его обновления.
- Фактические данные (цена, наличие, статус заказа) берутся вызовом функций, а не генерацией.
- Настроена эскалация на оператора и сценарий на случай недоступности модели.
- Заданы метрики до запуска: доля решённых диалогов, конверсия в корзину, выручка на диалог.
- Выделена контрольная группа, иначе прирост будет неотличим от самоотбора заинтересованных пользователей.
- Назначен регулярный разбор логов — еженедельно на старте, затем реже.