Чат-боты на сценариях против ИИ: сравнение метрик
Сценарий в банковском чате знаком каждому: «Выберите 1 — баланс, 2 — перевод, 3 — оператор». Пять нажатий, и ты говоришь с человеком. С LLM-ботом другая ловушка: он отвечает связно, иногда уверенно — и иногда выдумывает остаток по счёту.
Сценарный бот против LLM: что стоит за 100% предсказуемости
Архитектурный разрыв: дерево решений против вероятностной модели
Что гарантирует сценарный бот
Сценарный чат бот работает как навигатор в аэропорту: каждая развилка просчитана заранее, каждый ответ ведёт к следующему узлу. Ветка заканчивается одним из трёх исходов: ответ дан, эскалация на оператора, тупик. Предсказуемость ответа — 100%. Это не маркетинговое обещание, а свойство архитектуры: бот физически не может выдать формулировку, которой нет в дереве. Онбординг пользователя в такой системе линейный: вход → категория → подкатегория → результат. Если пользователь сбился, бот возвращает его в начало сценария или передаёт оператору. Ретеншн в рамках сценария высокий, потому что выходов из сценария два: завершение задачи или эскалация.
Что обещает LLM
Умные чат боты на базе LLM работают иначе. Они генерируют ответ токен за токеном, опираясь на вероятности, выученные из корпуса данных. Гибкость выше: пользователь формулирует вопрос в свободной форме, бот распознаёт интент и отвечает по существу. Но вероятностная природа — одновременно источник силы и источник галлюцинаций. Модель не «знает» ответ, она «угадывает» наиболее вероятное продолжение текста. Когда вероятность высокая, ответ точный. Когда низкая — модель собирает правдоподобную конструкцию из смежных фактов. Это архитектурное свойство, а не дефект конкретной модели.
Что это значит для продуктовой команды
В первом случае проектировщик флоу пишет сценарий, тестирует 200–500 веток, выкатывает. Команда небольшая, цикл короткий, зависимость от data science нулевая. Во втором — собирается база знаний, настраивается RAG, валидируются ответы на эталонной выборке, выстраивается мониторинг галлюцинаций. Время внедрения сценарного бота — от нескольких недель до 2–3 месяцев в зависимости от сложности домена. ИИ-бот с готовой Knowledge Base разворачивается за дни, но цикл валидации и тюнинга промптов — отдельный процесс, который длится месяцами. Метрика time-to-market в пользу LLM, метрика time-to-stable-quality — в пользу сценария.
Метрики эффективности: от Completion Rate к семантической точности
Метрики сценарного бота
Главная метрика сценарного чат бота — Completion Rate. Это процент сессий, в которых пользователь дошёл до конца сценария без эскалации. Бинарная, понятная цифра. Считается по логам, улучшается переписыванием веток, предъявляется стейкхолдерам без перевода. Высокий Completion Rate означает, что сценарий покрывает интенты пользователя. Низкий — что в дереве есть дыры или формулировки вводят в тупик. Дополнительно измеряются: среднее время до завершения сценария, процент эскалаций, частота возврата в начало. Это операционные метрики, которые работают в реальном времени.
Метрики LLM-бота
Для ИИ-ботов Completion Rate теряет смысл: у LLM нет «конца сценария». Здесь работает набор метрик:
- CSAT — оценка диалога пользователем (лайк/дизлайк, шкала 1–5). Субъективно, но отражает ощущение от флоу.
- Accuracy / F1-score — точность ответа на эталонной выборке. Измеряется через семантический анализ: правильный ли ответ дал бот, правильную ли сущность извлёк, попал ли в интент. Требует размеченного датасета.
- Hallucination Rate — процент ответов с фактическими ошибками. Критическая метрика для регулируемых отраслей.
- Containment Rate — процент сессий, закрытых без участия оператора. Аналог Completion Rate, но учитывает, что диалог может быть открытым.
Сравнение подходов к оценке
| Параметр | Сценарный бот | LLM-бот |
|---|---|---|
| Основная метрика | Completion Rate | CSAT, Accuracy, Hallucination Rate |
| Предсказуемость ответа | 100% | зависит от RAG и качества промпта |
| Время на замер | часы (парсинг логов) | дни (разметка выборки) |
| Целевой порог | 70–85% Completion | зависит от домена и риска |
| Стоимость измерения | низкая | высокая |
Метрика сценарного бота — это пульт управления: повернул — увидел эффект в тот же день. Метрика LLM-бота — это диагностика: пока соберёшь выборку, разметишь, посчитаешь F1, проходит неделя.
Экономика внедрения: фиксированная разработка против переменных затрат
Модель затрат сценарного бота
Разработка сценария — проектная работа. Аналитик описывает ветки, копирайтер формулирует ответы, разработчик собирает движок и интегрирует с CRM. Стоимость фиксируется на этапе технического задания и редко меняется. После запуска бот работает на тех же серверах, обращается к тем же API — операционные затраты минимальны и предсказуемы. Основная статья расходов после запуска — поддержка: обновление сценариев при изменении продукта, добавление новых веток, перевод на новые языки. Эта статья линейна и зависит от частоты релизов основного продукта.
Модель затрат LLM-бота
С ИИ-ботом экономика другая. Каждый запрос пользователя — это API-вызов к языковой модели, тарифицируемый по токенам. На вход идёт контекст (история диалога, фрагменты базы знаний, системный промпт), на выход — сгенерированный ответ. Чем длиннее диалог, тем больше токенов, тем выше счёт. При пиковом трафике стоимость API может превысить затраты на поддержку сценарного бота за квартал. Модель затрат переменная, и это требует другой управленческой дисциплины: мониторинг расходов в реальном времени, лимиты на длину диалога, fallback-сценарии при превышении бюджета.
Где проходит граница окупаемости
Граница зависит от трёх параметров: средняя длина диалога в токенах, цена модели за 1К токенов, объём трафика. Сценарный бот становится выгоднее при высоком трафике и коротких сценариях: фиксированные затраты распределяются на большое число сессий, переменные затраты на токены растут линейно. LLM-бот выгоднее при низком трафике и сложных сценариях: не нужно проектировать 300 веток ради 1К сессий в месяц, бот справляется на базе знаний. Промежуточная зона — гибрид: сценарная обвязка плюс LLM для неструктурированных запросов.
Фиксированная стоимость — это амортизация: заплатил один раз, пользуешься три года. Переменная стоимость — это подписка: каждый день получаешь счёт, и он зависит от того, насколько активно пользователи разговаривают с продуктом.
Безопасность и галлюцинации: где RAG перестаёт быть опцией
Почему галлюцинации — это свойство, а не баг
LLM генерирует наиболее вероятное продолжение текста. Если в обучающих данных не было точного ответа на вопрос пользователя, модель не скажет «не знаю» — она соберёт правдоподобный ответ из смежных фактов. В банковском флоу это критично: бот, который уверенно назвал неверный остаток, подрывает доверие к продукту. В медицинском чате — опасно: бот, который рекомендовал препарат с неверной дозировкой, создаёт регуляторный риск. Галлюцинация — не сбой конкретной версии модели, а фундаментальное свойство вероятностной генерации.
RAG как архитектурный стандарт
Retrieval-Augmented Generation — паттерн, при котором LLM получает не только историю диалога, но и релевантные фрагменты из базы знаний компании. Перед генерацией ответа система ищет документ, ближайший к вопросу пользователя по семантической близости, и подаёт его модели как контекст. Это снижает риск галлюцинации, но не устраняет его полностью. RAG требует собственной инфраструктуры: векторное хранилище, пайплайн индексации, мониторинг релевантности. Без RAG LLM-бот в продуктовом флоу — это технический долг с отложенным дефолтом.
Где сценарная логика остаётся стандартом
В банковских транзакциях, медицинских записях, юридических консультациях — везде, где цена ошибки измеряется деньгами, здоровьем или правовыми последствиями — сценарные чат боты остаются стандартом. Их не выбирают из-за гибкости. Их выбирают из-за аудируемости: каждый ответ можно проследить до конкретного узла дерева, каждое решение задокументировать, каждый сценарий пройти регрессионно. Для регулятора это важнее, чем натуральность диалога. Сценарный бот — это контролируемый риск. LLM-бот — это управляемый риск, но с другой кривой обучения.
Безопасность — не функция, а каркас. Сценарный бот строит стену из правил, LLM-бот натягивает сетку. Сетка гибче, но пропускает то, через что стена не пропускает вовсе.
Критерии выбора: когда сценарная логика превосходит LLM
Когда побеждает сценарный бот
Сценарный чат бот остаётся лучшим выбором в нескольких сценариях. Первый — сбор структурированных данных: заявка на кредит, анкета кандидата, опрос клиента. Пользователь отвечает на закрытые вопросы, бот валидирует формат, передаёт результат в систему. Второй — регулируемые процессы, где нужен аудит каждого шага. Третий — фиксированный бюджет и предсказуемый трафик. Четвёртый — стадия валидации гипотез, когда продукт проверяет, нужна ли автоматизация в этом флоу вообще. В этих сценариях LLM добавляет сложности без пропорциональной ценности.
Когда побеждает LLM-бот
ИИ-бот выигрывает в сценариях, где запросы пользователей не укладываются в предсказуемые категории. Техподдержка со сложной документацией, консультации по каталогу из тысяч позиций, обработка обращений на естественном языке в разных формулировках. Условия: база знаний большая и часто обновляется, команда готова инвестировать в prompt engineering и мониторинг галлюцинаций, продукт конкурирует за счёт скорости ответа. В этих сценариях попытка покрыть всё сценарным деревом приводит к взрывному росту числа веток и стоимости поддержки.
Гибридная архитектура как рабочий компромисс
На практике чистые архитектуры редки. Распространённый паттерн в зрелых продуктах: LLM обрабатывает входящие сообщения, классифицирует интент, и при попадании в критический сценарий — перевод, смена пароля, отмена заказа — передаёт управление сценарному движку. Гибрид сочетает гибкость входа с предсказуемостью ключевых действий. Это требует более сложной архитектуры, двойной команды поддержки и продуманной системы эскалации между слоями. Но для продукта с регулярной нагрузкой и широким спектром запросов это часто оказывается оптимальным балансом между UX, безопасностью и стоимостью.
| Параметр | Только сценарный | Только LLM | Гибрид |
|---|---|---|---|
| Гибкость входа | низкая | высокая | высокая |
| Предсказуемость действий | 100% | зависит от RAG | 100% в критических сценариях |
| Стоимость поддержки | средняя | низкая фиксированная + высокая переменная | высокая |
| Время внедрения | 1–3 месяца | 2–4 недели + цикл валидации | 3–6 месяцев |
| Аудируемость | полная | частичная | полная в сценарной части |
Позиция автора
Сценарные чат боты — не архаизм и не пережиток докомпьютерной эпохи. Это инфраструктура доверия, которая работает в задачах с регулируемым риском и предсказуемой структурой запросов. ИИ-боты — не замена, а надстройка, требующая собственной дисциплины: валидации выборок, мониторинга галлюцинаций, контроля затрат на токены, регулярного тюнинга промптов. Выбор между ними — не вопрос моды, а вопрос архитектурного бюджета и цены ошибки. В финансах, медицине, юридических сервисах сценарии остаются стандартом. В техподдержке, консультациях, продуктовых помощниках с большой базой знаний LLM даёт преимущество, которое окупается. Гибрид — рабочий компромисс, но требует зрелой продуктовой команды, способной держать обе архитектуры одновременно и не размывать ответственность между ними.