Почему диалоговый менеджмент рассыпается на живых сценариях
Чаще всего сценарий проходит демонстрацию и разваливается на третьем-четвёртом сообщении живого человека. Причина не в модели, а в том, что состояние разговора нигде не хранится отдельно: следующая реплика выводится из последней фразы, а не из всей истории. Как только человек отвечает не по шаблону — «да, но лучше в среду» — ветка перестаёт совпадать с реальностью.
Отсюда потеря контекста диалога: бот путает ответы, повторно спрашивает уже заполненные поля и откатывается на два шага назад. Пользователь читает это как «меня не слышат» и уходит, а в логах остаётся формально успешный диалог без результата.
Необработанные обращения — вторая точка отказа. Намерение, которого нет в дереве ветвлений, обрывает разговор: бот молчит или повторяет меню. Список таких фраз растёт быстрее сценария, и без отдельного слоя распознавания каждое новое обращение снова упирается в тупик.
Третье — передача оператору. Диалог обрывается на полуслове: сотрудник не получает ни историю реплик, ни заполненные поля, и человек заново объясняет задачу. На выходе — потерянный клиент или ручной перенос данных из чата в учётную систему.
Это не ошибки отдельных реплик, а отсутствие управляющего слоя, который держит состояние, распознаёт намерение и передаёт контекст целиком. Разбираем, как это закрывается.
Эффект в метриках: доля автоответов, передача оператору, отказы
Считаем эффект по сквозной воронке обращения, а не по логам бота: доля автоответов — это обращения, где последнее сообщение принадлежит боту и передачи оператору не было в течение окна ожидания. Метрика подвижна: сдвинули порог уверенности — автоответов меньше, но и ошибочных срабатываний меньше. Поэтому пороги фиксируем вместе с заказчиком до запуска и меняем только по накопленной статистике.
Время ответа бота на пиках не растёт, потому что маршрут по намерениям детерминирован: типовые сценарии закрываются правилами и слотами, а языковая модель подключается только на ветках, где шаблонного ответа нет. Плюс кэш частых формулировок и явная деградация: если внешний сервис не ответил, бот не молчит, а предлагает повтор, альтернативный шаг или передачу оператору.
Классы отказов считаем отдельно. Не распознано намерение — лечится разметкой и уточняющими вопросами в ветке. Намерение понято, но нет данных в системе — чинится интеграцией и внятным сообщением о причине. Сработала политика передачи по риску или эмоции — это не отказ, а плановое срабатывание, его долю держим управляемой. Сбой связи — повторные попытки и деградация без потери контекста диалога.
Итог виден в снижении нагрузки на поддержку: падает не просто число обращений к оператору, а меняется их состав — остаются сложные, спорные и эмоциональные. Политики ветвления описываем декларативно, как правила и сценарии в Rasa, поэтому границу передачи можно переставить без переписывания диалога.
Три режима сборки логики ответов и их ограничения
Режимы различаются тем, где принимается решение о следующей реплике: в описанных правилах, в поиске по базе знаний или в генеративной модели. Ниже — где каждый упирается в потолок и в каком случае его меняют на другой.
Сценарный бот предсказуем: ответ одинаков в любой момент, его легко проверить и объяснить, но с ростом числа тем комбинация веток растёт быстрее списка вопросов, а неописанный путь превращается в тупик. Поиск по базе знаний закрывает длинный хвост формулировок, отвечая по смыслу, но не ведёт многошаговый диалог. Генеративные ответы звучат естественно, однако без опоры на найденный фрагмент домысливают и дают разный результат на один и тот же вопрос.
| Режим | Когда подходит | Где упирается |
|---|---|---|
| Сценарный бот | Повторяемые операции: заявка, статус, запись — где важна одинаковая формулировка | Комбинаций веток больше, чем вопросов; незаданный путь — тупик |
| Поиск по базе знаний | Справка по документам, инструкциям, условиям — длинный хвост формулировок | Не ведёт диалог, легко теряет контекст предыдущих реплик |
| Генеративные ответы | Свободная речь, перефразировки, уточнения | Без источника домысливает, результат не повторяется от запуска к запуску |
| Гибридная схема | Разные типы запросов: операции, справка и свободный диалог вместе | Нужны маршрутизация и журнал запросов, чтобы отлаживать границы режимов |
Рабочая конфигурация в большинстве проектов — гибридная: запрос проходит маршрутизацию и уходит в свой режим, критичные операции остаются на сценарии. Так справка не ломает учётную логику, а генерация отвечает только там, где под ней есть проверенный источник.
Этапы внедрения: от аудита сценариев до передачи в эксплуатацию
Диалоговый менеджмент плохо поддаётся «донастройке» на живом боте: правила переходов разъезжаются, а узкое место становится видно только на потоке. Поэтому работаем этапами, и каждый заканчивается артефактом, который можно проверить до следующего шага.
Порядок работ
- Аудит сценариев и текущих обращений — выгружаем историю диалогов, считаем долю обрывов на каждом шаге и темы, которые чаще всего уходят оператору. На выходе — карта проблемных переходов.
- Разметка намерений — собираем корпус реальных фраз, помечаем интенты, слоты, отказы, вопросы вне сценария и опечатки. Согласованная разметка становится эталоном для проверки.
- Проектирование схемы диалога — граф состояний, обязательные уточнения, правила переспроса, эскалация на оператора и запасные ветки. Схему фиксируем до настройки.
- Настройка и сборка — правила переходов, формулировки реплик, пороги уверенности, ограничение длины диалога. Всё, что меняется без переписывания кода, выносим в конфигурацию.
- Тестирование бота — прогон эталонной разметки, диалоги «вслепую» силами инженеров, проверка отказов и тупиковых веток. Ошибки ловим до боевого запуска.
- Проверка на боевом трафике — запуск на часть обращений при параллельной работе оператора. Смотрим долю диалогов, закрытых без человека, и число переспросов.
- Ввод в эксплуатацию и передача — схема диалога, регламент правки сценариев, панели мониторинга и обучение вашей команды. Дальше изменения вносите сами.
Комплект поставки: конфигурации, схемы диалогов и регламенты
Работающая модель — не единственное, что остаётся у заказчика. Диалоговый менеджмент живёт дольше первой версии бота: меняются темы обращений, добавляются услуги, уточняются правила эскалации. Поэтому комплект поставки мы собираем так, чтобы ветки диалога правились без разбора чужого кода и без обращения к нам за каждой формулировкой.
- Схема диалога как граф состояний: ветки, переходы, точки возврата, поведение на нераспознанную реплику — по ней видно, куда встраивать новый сценарий.
- Набор намерений и сущностей с примерами реплик — он же служит регрессионным набором: после правок прогоняем и видим, не деградировали ли соседние ветки.
- Политики передачи оператору: условия эскалации — сколько непониманий подряд, ключевые слова, темы вне компетенции — состав передаваемого контекста и правила возврата в бота.
- Настройки журналирования: сработавшее намерение, уверенность распознавания, факт эскалации, идентификатор сессии; форма выгрузки для разбора.
- Документация по боту: карта интеграций, поведение при недоступности внешних систем, точки отказа и действия при каждом из них.
- Регламент правок: кто меняет ветки, какие проверки обязательны перед выкладкой, как откатывается версия и ведётся история изменений.
- Инструкция для операторов и чек-лист приёмки — чтобы эксплуатация не держалась на одном человеке.
Кейс: меньше передач оператору и стабильные ответы на пиках
Что было
Бот собирался под один сценарий и разбирал реплику по ключевым словам и регуляркам — на перефразировку «а если я хочу вернуть» он отвечал не той веткой. Контекст жил внутри одного шага: слоты, названные в начале разговора, к третьей реплике терялись, и бот заново спрашивал номер заказа. Итог — 41% диалогов заканчивались передачей человеку, ожидание оператора в пик доходило до семи минут, а поток обращений в поддержку рос быстрее, чем число диалогов.
Что изменили
Ядро диалогового менеджмента собрали на Rasa и перевели на явную модель: интенты с порогом уверенности, слоты с обязательностью и источником заполнения, состояния сценария, хранящиеся отдельно от текста реплики. Ветвление описано декларативно, поэтому новая тема добавляется настройкой, а не патчем кода. Правило эскалации стало частью сценария: три нераспознанные реплики подряд, прямой запрос на человека или критичный интент — и диалог уходит с историей и заполненными слотами, оператор не переспрашивает заново.
Что стало
Доля самостоятельных ответов выросла до 79%, ожидание в пик сократилось до 40 секунд, число передач оператору уменьшилось вдвое при выросшем трафике. Каждый шаг пишется в лог вместе с интентом и уверенностью, а набор реальных обращений стал регрессионным тестом: перед выкаткой видно, какие сценарии просели и где порог уверенности срабатывает слишком поздно.
Чем диалоговый менеджмент отличается от сценария бота
Сценарий — это дерево переходов: состояние бота равно номеру шага, а реплика пользователя лишь выбирает следующую ветку. Пока человек идёт по ожидаемому пути, всё предсказуемо. Но если он меняет тему, задаёт встречный вопрос или возвращается на два шага назад, дерево ломается — бот повторяет меню или уводит в тупик.
Диалоговый менеджмент вместо номера шага держит модель состояния разговора. В ней отдельно живут распознанные намерения, заполненные поля, стек незакрытых тем и признак, что пользователя не поняли. Реплика не переключает бота на ветку, а обновляет эту модель — поэтому смена темы и возврат к отложенному вопросу внутри одной сессии не требуют новых веток в схеме.
Управление контекстом — это набор правил, а не память модели. Мы задаём, сколько реплик хранить, какие значения считать подтверждёнными, когда задать уточнение и когда молча принять ответ. Отдельная политика отвечает за эскалацию: явная просьба позвать человека, два непонимания подряд, негатив или выход за пределы темы — диалог уходит оператору вместе с историей и уже собранными данными.
Сценарий при этом не выбрасывается. Ветки, где ошибка недопустима — оплата, идентификация, подтверждение заявки — остаются жёстко детерминированными, а диалоговый слой работает вокруг них. Такой гибрид даёт свободу в разговоре, не теряя контроля на критичных шагах, в любом канале — от виджета на сайте до Telegram.
Технические сомнения: контекст, доступы, откат изменений
Глубина контекста — параметр конфигурации, а не свойство модели. Мы держим последние реплики целиком, а более ранние сворачиваем в сводку, которая обновляется после каждого блока ходов: бот помнит суть обращения и договорённости, но не тащит в каждый запрос всю переписку — время ответа остаётся предсказуемым.
Доступы выдаём точечно: сценарий получает только те операции внутренних систем, которые ему действительно нужны, с ограничением по статусу обращения и роли оператора, всё остальное запрашивает человек. Обновления выкладываем ревизиями, поэтому вчерашняя рабочая версия остаётся под рукой.
Насколько глубоко бот помнит диалог?
Окно контекста настраивается: сколько последних реплик передаётся дословно и после какого порога история сворачивается в сводку. Сводка хранится отдельно от журнала переписки, поэтому долгий разговор не раздувает запрос и не роняет скорость ответа. Если клиент возвращается через неделю, поднимаем его карточку по идентификатору, а не всю прошлую переписку.
Как бот получает доступ к внутренним системам?
Через отдельный сервисный слой с ограниченным набором операций: прочитать статус заявки, добавить комментарий, создать обращение. Учётные данные лежат в хранилище секретов и боту недоступны, а каждый вызов фиксируется в журнале с идентификатором диалога. Доступ отзывается в любой момент, без остановки бота.
Что делать, если новая версия сценария сработает хуже?
Сценарии версионируются как код: каждая ревизия — отдельный артефакт, инструкции модели меняются независимо от логики. Выпускаем сначала на малую долю трафика и сверяем метрики с предыдущей версией. Если доля диалогов, где понадобился оператор, растёт — переключаемся на прошлую ревизию, это занимает минуты и не требует пересборки.
Как обрабатываются персональные данные?
В журналах маскируем номера, адреса и реквизиты, сырые записи живут ограниченный срок и затем удаляются. Для доработки сценариев используем обезличенные выборки. Если по требованиям заказчика данные не должны покидать его контур — разворачиваем обработку внутри, доступ к журналам выдаём по ролям.
Обсудим задачу и вернёмся с оценкой и планом работ
Чтобы разбор задачи занял один проход, а не серию уточняющих писем, полезно сразу прислать вводные — в том виде, в каком они уже есть. Идеально оформленные документы не нужны, хватит рабочих материалов.
- Сценарии: что бот закрывает сам, а где обязан передать диалог оператору.
- Реальные обращения: 30–50 диалогов из текущего канала поддержки в исходном виде — по ним видны живые формулировки, а не придуманные.
- Системы-источники: CRM, база знаний, система расчётов, запись — что доступно программно, а что придётся отдавать выгрузкой.
- Правила эскалации: в какой момент и к кому уходит диалог, что оператор видит в карточке.
- Каналы и ограничения: мессенджеры, чат на сайте, голос; требования к скорости ответа и достоверности данных.
- Критерии успеха: доля диалогов, закрытых без человека, число уточняющих вопросов на диалог, доля ошибок в ответах.
Из этого собираем оценку проекта и план работ: этапы, состав работ по каждому, зависимости от вашей стороны и точки, где показываем промежуточный результат. Диалоговый менеджмент проектируем до написания кода — схема переходов и правила ветвления согласуются заранее, поэтому дорогие переделки на поздних этапах не возникают.
Опишите задачу — вернёмся с оценкой и планом работ.
