Ответ «не знаю, передаю менеджеру» — это целевое поведение, которое проектируется, оплачивается и принимается на приёмке, а не признак того, что бот получился слабым. Причина арифметическая: отказ стоит компании несколько десятков рублей, а неверный ответ про цену, срок или условия возврата — на порядок больше, потому что к прямому разбору добавляются повторное обращение и уступка, которой не должно было быть.
Ошибка обычно возникает не на этапе проектирования, а на первой встрече по результатам. Руководитель видит в отчёте «12 % обращений система передала человеку» и просит эту цифру снизить, потому что покупали автоматизацию. Просьба выглядит разумной, а исполняется она одним движением — понижением порога, после которого система начинает отвечать там, где раньше молчала. Ниже — расчёт, что это движение стоит, и разбор того, как отличить полезный отказ от бота, который отказывается всегда.
Все числа — модельный расчёт на сквозном примере раздела: клиентская поддержка, около 6 000 обращений в месяц, база знаний из 150 страниц, ставка оператора 700 ₽/час, методиста 900 ₽/час. Арифметика открыта, её можно пересчитать под свои ставки.
Что дешевле: отказать или ответить наугад
Сравнивать надо не «отказ против правильного ответа», а «отказ против того, что реально получится, если систему заставить отвечать». Обращения, которые раньше уходили человеку, — это не средние обращения, а самые трудные: те, где документа нет, где вопрос на стыке двух правил, где клиент говорит не теми словами. Доля неверных ответов на них заведомо выше средней по потоку.
В расчёте нет двух вещей, которые считать нечем: клиентов, ушедших без объяснений, и цены решения свернуть проект после публичного эпизода. Обе они работают в ту же сторону. И есть третья, которую стоит назвать прямо: отказ виден в отчёте, а неверный ответ — нет. Первый честно попадает в метрику передач оператору, второй уходит клиенту и превращается в проблему через неделю, когда никто уже не свяжет её с настройкой порога.
Отсюда практическое правило для встречи по результатам: долю отказов нельзя обсуждать в отрыве от доли неверных ответов. Эти два числа связаны жёстко и меняются в противоположные стороны, поэтому и в отчёте они должны стоять рядом. Как измерить второе на своих данных, разобрано в материале про замер качества ИИ на своих данных.
Четыре причины, по которым система обязана отказать
Отказ технически устроен не как одно решение, а как четыре независимые проверки. Различать их важно, потому что настраивают их разные люди и лечат по-разному: три из четырёх — это работа с документами и регламентом, и только одна относится к настройкам модели.
| Причина отказа | Что проверяется | Что видит клиент | Кто настраивает |
|---|---|---|---|
| Нет подходящего документа | Поиск вернул пустоту или фрагменты с оценкой релевантности ниже порога | «Не нашёл точного ответа, передал менеджеру. Ответим до 17:00, номер обращения 4318» | Инженер задаёт порог, методист пополняет базу |
| Стоп-тема | Словарь фраз и классификатор проверяют сообщение до генерации ответа | «Этот вопрос решает менеджер, передаю прямо сейчас» | Владелец процесса утверждает список письменно |
| Лимит на сумму, скидку или срок | Готовый ответ проверяется на числа и слова-обязательства выше согласованного порога | «Такое решение подтверждает руководитель, заявка уже у него» | Руководитель отдела задаёт пороги |
| Порог уверенности модели | Внутренняя оценка связности ответа ниже настройки — грубый фильтр бессвязного текста | Та же формулировка, что и в первом случае | Инженер; это самый слабый из четырёх механизмов |
Последняя строка требует оговорки, потому что именно её обычно имеют в виду, когда говорят «настройте порог уверенности». Внутренняя оценка модели отражает вероятность последовательности слов, а не истинность утверждения: складная выдумка получает высокую оценку, а корявая цитата из вашего регламента — низкую. Подробно этот механизм разобран в статье про механику галлюцинаций. Практический вывод: основной отказ должен опираться на первую строку таблицы, а не на четвёртую — на отсутствие документа, а не на самооценку модели.
Вертикальная схема сверху вниз: «Сообщение клиента» → ромб «Стоп-тема?» → «Поиск по базе» → ромб «Фрагменты найдены?» → «Модель отвечает» → ромб «Число или обязательство выше лимита?» → ромб «Оценка связности ниже порога?» → «Ответ клиенту со ссылкой на источник». От каждого ромба ветка «да» или «нет» уходит вбок в один общий блок «Отказ и передача человеку». Сбоку у каждого ромба подпись, кто его настраивает: владелец процесса, методист, руководитель отдела, инженер.
Норма доли отказов и о чём говорит высокая
Рабочие ориентиры для клиентского агента на базе знаний такие: 18–20 % отказов и эскалаций в первый месяц эксплуатации, 10–12 % к третьему, дальше кривая выходит на полку около 10 % и ниже сама не идёт. Снижение происходит за счёт пополнения базы знаний по найденным пробелам, а не за счёт ослабления правил — это два разных способа получить одну и ту же цифру, и различаются они долей неверных ответов.
Падение ниже 6 % — повод для разбора, а не хорошая новость. На практике оно означает одно из трёх: кто-то понизил порог, сломался классификатор стоп-тем или обновление промпта изменило поведение при пустом поиске. Резкое улучшение метрики подозрительнее ухудшения, и это общее свойство контуров защиты, разобранное в материале про три контура.
Высокая доля отказов на старте — почти всегда диагноз базе знаний, а не модели. Если система отказывает в четверти обращений, значит, в четверти случаев в документах нет ответа; заменой модели это не лечится, потому что новой модели брать ответ будет ровно так же неоткуда. Ровно этот сюжет мы отдельно разбирали в связке с вопросом, сколько обращений реально закрывает бот: потолок автоматизации задаёт полнота документов, а не качество генерации.
Линейный график за шесть месяцев. Ось X — месяцы 1–6, ось Y — проценты от 0 до 25. Линия «доля отказов и передач человеку»: 20, 15, 12, 11, 10, 10. Горизонтальная штриховая линия на уровне 10 % подписана «рабочая полка». Нижняя часть графика ниже отметки 6 % залита штриховкой и подписана «зона разбора: обычно ослаблены правила». Стрелка к участку между вторым и третьим месяцем с подписью «снижение за счёт пополнения базы знаний».
Формулировка отказа, после которой клиент не раздражается
Раздражает не отказ, а неопределённость после него. Разница между «к сожалению, я не могу ответить на этот вопрос» и «передал менеджеру, ответим до 17:00 сегодня, номер обращения 4318» — это разница между брошенным клиентом и клиентом в очереди. Рабочая формулировка состоит из пяти элементов, и все пять помещаются в две строки.
- Прямая констатация без извинений на абзац. Одно «не нашёл точного ответа» достаточно; двойное извинение читается как отписка.
- Конкретный следующий шаг с исполнителем: передал менеджеру, передал в отдел доставки, передал руководителю на подтверждение.
- Срок ответа в часах и с привязкой к часам работы: «до 17:00 сегодня», «до 11:00 завтра». Не «в ближайшее время» и не «в течение рабочего дня».
- Номер обращения, по которому клиент может вернуться. Он же превращает отказ в измеримое событие для журнала.
- То, что можно сделать прямо сейчас, если это уместно: статус текущего заказа, ссылка на бланк, ближайшие свободные слоты. Один полезный шаг вместо извинения меняет тон всего диалога.
Частая ошибка сценария: система, поняв, что ответа нет, начинает уточнять — «правильно ли я понял», «уточните, пожалуйста, модель». Клиент отвечает на три вопроса и в конце получает передачу оператору, которому рассказывает всё заново. Если решение отказать принято, оно исполняется немедленно и молча. Что уходит оператору вместе с диалогом, чтобы клиент не начинал разговор с нуля, разобрано в материале про стоп-темы и перевод на оператора.
Разбор журнала за неделю: полезный отказ или бесполезный бот
Отличить одно от другого по общей цифре нельзя: 12 % отказов бывают признаком аккуратной системы и признаком пустой базы знаний. Различает их распределение по темам, и проверяется это за час работы с журналом за одну неделю. При потоке 6 000 обращений в месяц неделя даёт около 165 отказов.
- 1Выгрузите все отказы за неделю с текстом исходного вопроса и причиной отказа из таблицы выше. Четыре причины разносятся по четырём корзинам сразу — дальше интересна только первая, «нет подходящего документа».
- 2Сгруппируйте вопросы из первой корзины по темам вручную: рассрочка, самовывоз, гарантия на комплектующие, работа с юрлицами. Тем обычно получается 25–40, и группировка занимает около часа.
- 3Посмотрите на верхние восемь тем. В здоровом сценарии они дают больше половины всех отказов — в нашем разборе 99 из 165, то есть 60 %. Это означает, что база знаний неполна в восьми конкретных местах, и её можно дописать.
- 4Если отказы распределены ровно по всем темам и верхние восемь дают меньше четверти, дело не в базе, а в пороге: система отказывает не там, где не знает, а везде понемногу. Это тот случай, когда настройку действительно надо править.
- 5Закройте восемь тем документами и повторите разбор через две недели. Восемь часов методиста по ставке 900 ₽/час — 7 200 ₽ — снимают 99 отказов в месяц из 720 и опускают долю с 12 % примерно до 10 %.
Столбчатая диаграмма отказов по темам за одну неделю, всего 165 отказов. Первые восемь столбцов выделены и подписаны темами: рассрочка, самовывоз, гарантия на комплектующие, работа с юрлицами, замена по браку, доставка в регионы, сроки изготовления, оплата по счёту; их суммарная высота подписана «99 из 165, 60 %». Дальше длинный хвост из низких столбцов, подписанный «остальные 25–30 тем». Внизу ремарка: «8 часов методиста, 7 200 ₽ — и доля отказов падает с 12 % до 10 %».
В приёмку и в договор из всего этого попадает не одно число, а коридор. Требовать конкретную долю отказов от подрядчика до запуска нельзя: она зависит от полноты ваших документов, которую подрядчик не контролирует. Рабочая формулировка выглядит так: значение фиксируется по итогам первого месяца эксплуатации; дальше оно не превышает согласованной верхней границы и не опускается ниже 6 %; выход за любую из границ подрядчик разбирает за свой счёт и предъявляет причину. Отдельным пунктом идёт жёсткий ноль на фактические ответы без ссылки на источник — это единственная метрика раздела, где ноль обещать можно.
Когда отказ не нужен
Настраивать отказ имеет смысл не везде, и в трёх случаях он только мешает.
- Ответы берутся из справочника дословно. График работы, адрес, реквизиты, порядок самовывоза — здесь либо есть точное совпадение, либо нет, и промежуточного состояния «система не уверена» не существует. Отказ вырождается в обычное «ничего не найдено».
- Результат всегда проверяет человек. Если модель готовит черновик письма или классифицирует документ, а сотрудник подтверждает, отказ не экономит ничего: ошибка всё равно ловится на следующем шаге, а лишние передачи только тормозят поток.
- Поток меньше 500–800 обращений в месяц. Передача оператору в этом объёме не создаёт очереди и не требует настройки: человек и так рядом. Порог, с которого разговор о долях отказов становится осмысленным, — примерно 2 000 обращений в месяц.
И обратная ситуация, где отказ должен стоять жёстче обычного. Если цена одной ошибки выше стоимости всей автоматизации — медицинские рекомендации, юридические заключения, расчёт налогов, конструкторские допуски, — правильная настройка не «отказывать при отсутствии документа», а «отвечать только при точном совпадении и передавать всё остальное». Доля отказов там будет высокой и не должна снижаться: система в таких задачах готовит материал для специалиста, а не разговаривает с клиентом от лица компании.
Отказ виден в отчёте, неверный ответ — нет. Поэтому просьба «снизьте долю отказов» почти всегда означает просьбу сделать проблему невидимой.
