Чат-бот — программа, которая ведёт с человеком диалог текстом. Под одним словом скрываются устройства, различающиеся принципиально, и путаница между ними — источник большинства неудачных проектов.
Различать их стоит по одному признаку: откуда берётся ответ.
Четыре типа
Сценарный. Ответы заданы заранее, пользователь идёт по дереву кнопок или фраз. Предсказуем полностью, не ошибается, не понимает ничего за пределами сценария.
С распознаванием намерений. Фраза пользователя относится к одному из заранее описанных намерений, дальше работает сценарий. Гибче в формулировках, но набор тем по-прежнему закрытый.
По базе знаний. Ответ строится по найденным в ваших документах фрагментам. Отвечает на то, чего не предусматривали, но качество зависит от документов. Технически это RAG-подход, поэтому таких ботов часто называют RAG-ботами.
Агент. Не только отвечает, но и выполняет действия в системах. Другой уровень риска и другие требования.
Про чисто генеративного бота. Модель без базы знаний и без сценариев — «болтун»: отвечает складно на любую тему, включая выдуманную. Для внутреннего и клиентского сервиса генеративный слой всегда привязан к источникам: сценарий задаёт рамки, поиск по документам — факты. Гибрид «сценарий для частого + база знаний для остального» — самый распространённый рабочий вариант, подробности в статьях «Сценарный бот» и «RAG».
Как выбрать
Вопрос не «что современнее», а насколько разнообразны обращения и какова цена ошибки.
Если восемьдесят процентов обращений — пять типовых вопросов, сценарный бот закроет их дешевле, быстрее и без риска. Языковая модель здесь избыточна и добавляет неопределённости там, где её не было.
Если вопросы формулируются по-разному и упираются в документы, нужен бот по базе знаний. Попытка описать такое сценариями превращается в дерево на сотни веток, которое невозможно поддерживать.
Промежуточный вариант работает чаще всего: сценарий для частых обращений, база знаний для остального, передача человеку при неуверенности.
Что определяет успех
Подготовленные материалы. Бот не создаёт знания, он их пересказывает. Если ответов нет в документах, их не будет и в диалоге.
Понятная передача человеку. Возможность попасть к оператору должна быть очевидной и быстрой. Бот, из которого нельзя выйти, раздражает сильнее, чем его отсутствие.
Честное представление. Попытка выдать бота за человека почти всегда распознаётся и вредит доверию.
Маркировка ответов. Сгенерированные моделью ответы в ряде случаев подлежат маркировке как контент ИИ; сценарные реплики — заранее опубликованный текст, требований к маркировке для него нет. В гибриде границу проводят по факту: чем именно сформирован показанный пользователю ответ.
Разбор диалогов после запуска. Первые недели показывают, о чём люди спрашивают на самом деле, и это почти никогда не совпадает с ожиданиями.
Чего ждать по цифрам
Доля закрытых без человека обращений сильно зависит от однородности вопросов. При подготовленной базе и типовых обращениях это обычно значимая часть потока, при разнородных вопросах — заметно меньше.
Обещать конкретный процент до замера на ваших обращениях нельзя. Считать его нужно так: доля диалогов, после которых человек не обратился повторно в течение суток. Без этого условия показатель приукрашен.
Метрики качества бота
Доля решённых. Основная метрика: доля диалогов, решённых ботом без оператора и без повторного обращения в течение суток. Сутки — важное условие: без него «решённым» считается диалог, после которого человек написал снова через два дня.
Эскалация и её причины. Доля передач человеку сама по себе ни хороша, ни плоха — её разбирают по причинам: нет информации в базе, вопрос вне тематики, бот не понял, клиент настаивает на человеке. Устойчивый рост «не понял» — проблема распознавания, рост «нет информации» — проблема базы.
CSAT. Оценка диалога пользователем в конце. Показатель смещён: оценку чаще оставляют либо очень довольные, либо очень раздражённые, поэтому его читают в динамике и рядом с долей решённых, а не вместо неё.
Операционные метрики. Время до первого ответа и до решения, доля диалогов, завершённых на первом шаге, среднее число шагов до результата. Их же используют для сравнения вариантов бота между собой: A/B на живом потоке честнее любой демонстрации.
Анти-паттерны внедрения
Бот ради бота. Проект без измеримой цели («автоматизировать общение») не имеет критерия успеха, и его невозможно провалить или улучшить. Перед стартом фиксируется метрика: доля решённых, время до ответа, разгрузка линии в часах.
Барьер на пути к оператору. Прятать передачу человеку ради красивой доли автоматизации — самый быстрый способ воспитать пользователей, которые пишут «оператор» первым сообщением. Эскалация — часть сервиса, а не дефект метрики.
База из сырых документов. Индексация папки «как есть» без чистки дубликатов и устаревших версий приводит к ответам по отменённым регламентам — и винят потом «ИИ», а не процесс подготовки данных.
Тестирование примерами команды. Команда формулирует вопросы теми словами, которые есть в документах; пользователи — бытовыми. Оценивать надо на выгрузке реальных обращений до запуска, иначе первый контакт с реальностью случится на живых клиентах.
Запуск сразу во всех каналах. Поведение и формулировки в чате сайта и в мессенджере различаются; порядок — один канал, доведение метрик, потом масштабирование.
Частые вопросы
Какой бот нам нужен?
Зависит от разнообразия обращений. Если большая часть вопросов типовая, дешевле и надёжнее сценарный. Если формулировки разные и ответы лежат в документах — бот по базе знаний. Чаще всего оптимален смешанный вариант с передачей человеку при неуверенности.
Сколько обращений закроет бот?
Величина зависит от однородности вопросов и подготовленности документов, поэтому называть процент до замера некорректно. Считать нужно долю диалогов, после которых человек не обратился повторно в течение суток, — иначе показатель завышен.
Нужно ли предупреждать, что отвечает бот?
Да. Попытка выдать бота за человека распознаётся почти всегда и обходится дороже, чем честное представление. Плюс в ряде случаев это требование к информированию пользователя.
Что делать, если бот не знает ответа?
Передавать человеку, а не пытаться ответить приблизительно. Возможность выйти на оператора должна быть очевидной: бот, из которого нельзя выйти, вызывает больше раздражения, чем его отсутствие.
Из чего складывается стоимость владения?
Из трёх частей: однократная подготовка (сценарии, база знаний, интеграции), эксплуатация (плата за модельные обращения у ботов по базе знаний, инфраструктура) и сопровождение (разбор диалогов, пополнение базы). Сценарный бот дёшев в эксплуатации, но живёт за счёт ручной поддержки веток; RAG-бот платит за каждый диалог, зато расширяется добавлением документов. Сравнивать типы честнее по совокупности, а не по цене запуска.
Кто отвечает за ошибку бота?
Ответственность лежит на компании, внедрившей бота, независимо от того, кто именно сказал неверное — сценарий, модель или оператор. Поэтому рискованные действия (платежи, изменение данных) либо выполняются с подтверждением человеком, либо не отдаются боту вовсе; принципы разбора — в статье «Кто отвечает за ошибку ИИ».