У чат-бота нет одной универсальной метрики качества. Высокая доля диалогов без оператора может означать, что бот решил вопросы, а может — что люди не нашли кнопку выхода и закрыли окно. Быстрый ответ может быть неверным. Положительная реакция после одной реплики не доказывает, что клиент выполнил нужное действие.
Поэтому измерение строят слоями: качество конкретного ответа, итог диалога, последующее поведение клиента и безопасность границ. Для каждого слоя нужны отдельные данные. Итоговая панель должна помогать принять решение — расширять тему, исправлять источник, менять маршрутизацию или отключать сценарий.
Начните с цели и единицы оценки#
Сформулируйте одну цель бота. Например: дать подтверждённый ответ по условиям доставки; собрать данные заявки; определить тему обращения и передать нужной группе. Нельзя одной цифрой сравнивать справочного бота и помощника, который только классифицирует входящие.
Определите единицу:
- ответ — подходит для фактической точности и ссылок;
- диалог — для полноты решения и количества повторов;
- обращение клиента — для повторного контакта в другом канале;
- тема — для поиска слабого раздела базы знаний;
- версия системы — для сравнения до и после изменения.
Запишите события, которые система умеет фиксировать: показ ответа, открытие источника, переформулировка, просьба об операторе, перевод, закрытие окна, повторное обращение, действие в личном кабинете. Если нужного события нет, не заменяйте его удобным суррогатом без пометки.
Четыре слоя качества#
1. Корректность отдельного ответа#
Ответ оценивают глазами по фиксированной рубрике:
| Критерий | Вопрос проверяющего |
|---|---|
| точность | каждое утверждение подтверждается источником или данными запроса? |
| полнота | хватает ли ответа, чтобы сделать следующий шаг? |
| релевантность | отвечает ли текст на намерение, а не на отдельное слово? |
| границы | не добавлены ли обещания, расчёты или действия без основания? |
| понятность | может ли клиент выполнить инструкцию без расшифровки терминов? |
| проверяемость | показан ли действующий источник там, где он нужен? |
Используйте шкалу 0–2 с описанием каждого значения. Сначала отметьте критическую ошибку отдельно: раскрытие недоступного, выдуманное обязательство, неверное действие с деньгами, опасная инструкция. Такой ответ нельзя «усреднить» с хорошим тоном.
2. Результат диалога#
Диалог может содержать хорошие отдельные фразы и не решить вопрос. Проверяйте, понял ли бот намерение, запросил ли недостающие сведения, сохранил ли контекст, завершил ли сценарий или вовремя передал человеку.
Полезные показатели:
- доля диалогов с подтверждённым решением;
- доля повторных формулировок одного вопроса;
- доля просьб позвать оператора;
- число неудачных ответов до передачи;
- доля передач с полной сводкой контекста;
- доля брошенных диалогов после ошибочного ответа;
- время до результата, а не до первой реплики.
Подтверждение решения лучше получать не вопросом «вам помог ответ?», а проверяемым событием: пользователь открыл нужную форму, получил статус, завершил настройку или не обратился повторно по той же теме в выбранное окно. Окно определяет компания по циклу обслуживания и фиксирует заранее.
3. Последствие для процесса#
Сравнивайте не только диалоги, но и нагрузку на поддержку. Бот может уменьшить входящие в одном канале и увеличить письма, звонки или повторные обращения. Свяжите каналы настолько, насколько это допустимо по данным, и смотрите темы, а не только общий объём.
Показатели процесса:
- число обращений по теме на единицу клиентов;
- доля повторов после автоматического ответа;
- время оператора на обращение после передачи;
- доля исправлений обещаний, данных ботом;
- число жалоб, где упоминается автоматический ответ;
- нагрузка на владельцев базы знаний;
- стоимость одного подтверждённо решённого вопроса.
Не приписывайте изменение только боту, если одновременно поменялись продукт, сезон, канал или состав клиентов. Сохраняйте период сравнения, темы и версию системы.
4. Безопасность и соблюдение границ#
Создайте отдельный набор запретов: темы мгновенной передачи, недоступные сведения, действия без полномочия, запросы с персональными данными, попытки заставить бота игнорировать правила. Доля успешных защитных реакций — самостоятельная метрика. Один серьёзный провал может потребовать остановки сценария независимо от средней оценки.
Как собрать ручную выборку#
Случайные двадцать диалогов редко представляют весь поток: большинство окажется простыми частыми вопросами. Используйте стратифицированную выборку. Разделите обращения по теме, каналу, результату, длине, наличию передачи и версии. Из каждой группы берите примеры, а редкие критичные случаи включайте принудительно.
Минимальная недельная выборка содержит:
- частые темы пропорционально объёму;
- все темы высокого риска хотя бы несколькими примерами;
- диалоги без ответа;
- просьбы об операторе;
- длинные цепочки и повторные формулировки;
- положительные и отрицательные оценки;
- обращения после обновления базы;
- случаи, где клиент ушёл в другой канал.
Два проверяющих независимо оценивают часть выборки. Если их оценки расходятся, проблема может быть в рубрике, а не в боте. Уточните критерии и приведите примеры пограничных случаев. Только после согласования шкалы можно строить тренд.
Не поручайте модели быть единственным судьёй другой модели. Автоматическая оценка помогает сортировать объём и искать подозрительные диалоги, но контрольный слой остаётся у специалистов, которые знают правила бизнеса.
Контрольный набор до запуска#
Помимо живой выборки нужен фиксированный регрессионный набор. Это список вопросов с ожидаемым ответом, допустимыми источниками и критическими запретами. Его прогоняют перед релизом и после каждого изменения модели, инструкции, поиска, базы или маршрутизации.
Состав набора:
- прямые частые вопросы;
- разговорные варианты и опечатки;
- неполные запросы, требующие уточнения;
- вопросы с несколькими условиями;
- исключения из общего правила;
- устаревшие формулировки клиента;
- вопрос без ответа в базе;
- запрос к закрытым данным;
- эмоциональная жалоба;
- требование действия без полномочия;
- попытка изменить правила бота;
- длинный диалог со сменой намерения.
Для каждого примера храните версию эталона и владельца. Если правило бизнеса изменилось, сначала обновляется источник, затем ожидаемый ответ. Нельзя подправлять эталон только потому, что новая версия бота ответила иначе.
Метрики, которые вводят в заблуждение#
Доля автоматизации. Полезна только вместе с решением вопроса, повторами и передачами. Рост в одиночку может означать спрятанный выход.
Средняя длина диалога. Короткий диалог может быть успешным или брошенным. Разделяйте по результату.
Оценка пальцем вверх. Её оставляет малая и смещённая часть пользователей. Смотрите как сигнал для выборки, а не как точную долю довольных.
Скорость ответа. После достижения приемлемого времени улучшение миллисекунд редко компенсирует неверный смысл.
Число сообщений оператору. Сокращение хорошо только если вопрос не вернулся в другом канале.
Средний балл качества. Скрывает критические провалы и слабые темы. Всегда показывайте распределение и отдельную долю стоп-ошибок.
Панель владельца чат-бота#
Еженедельная панель может состоять из восьми строк:
| Метрика | Разрез |
|---|---|
| подтверждённо решённые диалоги | тема, канал, версия |
| критические ошибки | тип риска и источник |
| повторные обращения | тема первого и повторного контакта |
| переформулировки | тема и место сбоя |
| передачи оператору | своевременные и запоздалые |
| полнота контекста при передаче | команда операторов |
| время ручной правки | сценарий |
| стоимость решённого вопроса | период и объём |
Рядом нужен журнал изменений: что поменяли, когда, на какой доле трафика и какой показатель ожидали улучшить. Без журнала график невозможно интерпретировать.
Как принимать решение по результатам#
Если падает точность в одной теме, проверьте источник и поиск. Если ответы верны, но люди переспрашивают, проблема может быть в полноте или языке. Если переводы правильны, но оператор долго разбирается, улучшайте сводку контекста. Если растёт доля критических ошибок, сузьте доступные темы и верните ручную обработку до исправления.
Новую версию выпускайте на ограниченную долю потока. Сравнивайте одинаковые темы и периоды, не смешивайте результаты разных конфигураций. Заранее запишите порог остановки: критическая ошибка, рост повторов или падение подтверждённого решения. Возврат к прошлой версии должен быть технически готов до эксперимента.
Границы применения бота и правила передачи человеку подробно разобраны в статье об ИИ в поддержке, а внедрение процесса — в плане запуска ИИ в службе поддержки.
Чек-лист системы качества#
- у бота одна измеримая цель;
- определены единицы ответа, диалога и обращения;
- критические ошибки считаются отдельно;
- результат подтверждается действием или проверкой;
- повторные контакты ищутся по всем доступным каналам;
- ручная выборка покрывает редкие и рискованные случаи;
- часть диалогов оценивают два специалиста;
- есть фиксированный регрессионный набор;
- вопросы без ответа и без доступа входят в тест;
- каждая версия системы отмечена в данных;
- изменения раскатываются постепенно;
- установлен порог остановки и готов откат.
Хорошая система качества не доказывает, что бот «умный». Она быстро показывает, где именно он перестал помогать и какое изменение это вызвало. Такая наблюдаемость важнее красивого общего процента: благодаря ей команда расширяет автоматизацию только там, где результат подтверждён, а не там, где клиенту просто не удалось добраться до человека.
Как связать разметку с исправлением#
Одного балла недостаточно. Добавьте к каждой неудаче первичную причину:
| Причина | Что обычно исправляют |
|---|---|
| нет утверждённого ответа | владелец процесса создаёт или отклоняет правило |
| источник устарел | владелец базы обновляет и отзывает версию |
| найден не тот фрагмент | команда поиска правит индекс и метаданные |
| намерение определено неверно | маршрутизация и примеры классификации |
| ответ добавил лишнее | инструкция формирования и правило отказа |
| потерян контекст | хранение состояния и сводка диалога |
| поздняя передача | порог уверенности и стоп-сигналы |
| оператору не хватает сведений | пакет контекста при переводе |
Класс выбирают по первому сломанному звену. Если устаревший документ найден правильно и точно пересказан, это ошибка содержания, а не модели. Такая дисциплина позволяет назначить владельца и проверить исправление на том же диалоге.
Контроль качества разметчиков#
Проверяющие тоже ошибаются и со временем меняют трактовку. Раз в месяц возвращайте в выборку несколько старых примеров без прошлой оценки и сравнивайте результат. Если баллы поплыли, проведите калибровку на пограничных случаях и уточните рубрику.
Храните короткие примеры для каждого уровня шкалы. Формулировка «ответ в целом хороший» не воспроизводится, а «потеряно обязательное исключение, поэтому 0 по полноте» воспроизводится. Для новых тем привлекайте владельца содержания: универсальный специалист качества не всегда распознает отраслевую неточность.
При расчёте тренда не смешивайте оценки разных рубрик. Если критерий изменился, отметьте новую версию и при необходимости переоцените сопоставимую историческую выборку. Иначе улучшение графика может быть следствием более мягкого правила, а не лучшего бота.
Когда автоматическая оценка полезна#
Автоматический проверяющий способен находить отсутствие ссылки, нарушение формата, запрещённые слова, слишком длинный ответ и расхождение с известным эталоном. Используйте его как фильтр, который увеличивает долю подозрительных диалогов в ручной выборке.
Но он не должен единолично подтверждать фактическую правильность сложного ответа или уместность решения для клиента. Регулярно измеряйте его собственные ложные пропуски и тревоги на размеченном наборе. Инструмент контроля становится частью системы и требует тех же версий, тестов и владельца.