Симптом выглядит проще причины
Клиент трижды объясняет проблему, бот предлагает одну и ту же инструкцию и только после требования «позовите человека» открывает очередь. Кажется, что нужно добавить ключевую фразу. Но поздняя передача обычно возникает из нескольких слоёв: модель не видит уверенность поиска, сценарий оценивает отдельную реплику вместо всей истории, а бизнес-метрика поощряет снижение числа обращений к операторам. Исправление одного промпта ненадолго маскирует конфликт.
Разделите незнание и невозможность
Бот может не найти ответ в базе, не иметь права выполнить действие или столкнуться с эмоционально сложной ситуацией. Это разные причины передачи. Для отсутствующего знания нужен оператор с контекстом поиска. Для запрещённого действия — сотрудник с нужной ролью. Для угрозы, жалобы или уязвимого клиента — специальный маршрут. Если всё обозначено одной категорией «не понял», очередь получает мало информации, а аналитика не показывает, что нужно улучшать.
Проверьте сигналы поиска
RAG-система должна возвращать не только текст, но и найденные документы, их актуальность и качество совпадения. Если база не дала подходящего источника, модель не должна заполнять пробел общими словами. Введите правило: ответ о политике или деньгах возможен только при наличии действующего документа. Уверенность самой модели не является доказательством. Лучше показать короткое сообщение о передаче, чем сочинить убедительную процедуру из похожего раздела.
Смотрите на историю диалога
Одна реплика «не получилось» не объясняет, что клиент уже выполнил два шага. Система должна хранить подтверждённые факты, предложенные действия и их результат. Повтор ранее отвергнутой инструкции — сигнал эскалации. Ещё один сигнал — два последовательных запроса уточнения без нового полезного поля. Не нужно ждать прямой команды пользователя. Порог задаётся по состоянию задачи, а не по раздражённому ключевому слову.
Передавайте полезный пакет
Оператору нужны цель клиента, подтверждённые идентификаторы, уже выполненные шаги, найденные источники и причина остановки. Полный сырой диалог заставляет читать всё заново. Автоматическое резюме проверяется по ссылкам на сообщения: если модель написала, что клиент согласился, сотрудник должен открыть точную реплику. Секреты и платёжные данные в сводку не копируются, если они не нужны следующему действию.
Не оптимизируйте только containment
Показатель доли диалогов без оператора легко улучшить, заставив бота дольше удерживать клиента. Это не качество. Добавьте повторные обращения по той же теме, время до решения, негатив после отказа, неверные действия и долю передач с полным контекстом. Иногда рост эскалаций — хороший результат: система раньше признаёт границу и уменьшает число потерянных клиентов. Метрика должна поддерживать решение проблемы, а не защищать красивую статистику автоматизации.
Проведите контрольный прогон
Соберите двадцать историй: отсутствующий документ, старое правило, недоступный инструмент, повторный сбой, конфликтный клиент и запрос вне полномочий. Для каждого укажите момент передачи и обязательные поля пакета. Запустите диалог целиком, а не отдельные сообщения. Измерьте лишние ходы, правильность маршрута и время оператора до первого действия. После изменения базы или модели повторите тот же набор, чтобы улучшение одной темы не сломало другую.
Исправляйте по уровням
На уровне данных уберите устаревшие документы и добавьте владельца. На уровне поиска установите порог и требование к источнику. На уровне диалога храните состояние и число неудачных шагов. На уровне инструментов возвращайте понятные ошибки. На уровне бизнеса измените метрику и расписание операторов. Промпт описывает поведение, но не может сам создать доступную очередь или отличить актуальную инструкцию без метаданных.
Итог разбора
Хорошая эскалация — не поражение бота, а штатный выход процесса. Пользователь не должен доказывать системе, что она не помогает. Передача запускается при отсутствии подтверждённого знания, невозможности действия, повторном неуспехе или специальном риске. Оператор получает краткий проверяемый пакет и продолжает с места остановки. Начните с анализа десяти самых длинных неуспешных диалогов: в них быстро обнаружатся повторяющиеся точки, где бот должен был отступить раньше.