Проверить точность ИИ-оценки звонков можно только сравнением с согласованной оценкой людей на тех же записях. Сравнивать нужно каждый критерий: какие нарушения система нашла, какие пропустила и где обвинила менеджера ошибочно. Общий балл за разговор этих различий не показывает.
Ниже - порядок такой проверки. Он подходит, если у отдела уже есть записи, правила оценки и человек, который может разрешить спор по конкретной реплике. Если критерии ещё не собраны, начните с чек-листа оценки звонка менеджера.
Сначала определите, какое решение зависит от оценки
Требования к точности зависят от последствий ошибки. Отправить сомнительный звонок руководителю на прослушивание и автоматически назначить сотруднику обязательный разбор - разные действия. Для каждого критерия заранее запишите, что произойдёт после срабатывания.
Возьмём условный критерий: менеджер обещал срок поставки, которого нет в регламенте. Пропуск оставит такое обещание незамеченным. Ложное срабатывание потратит время руководителя и сотрудника на проверку корректного разговора. Оба вида ошибок важны, но исправлять их приходится по-разному.
До пилота заполните короткую карточку:
- Что проверяем: конкретное действие или фразу.
- Когда правило применимо: тип звонка, продукт, этап разговора.
- На чём основан вывод: запись, расшифровка, версия регламента, при необходимости данные CRM.
- Что делает система после обнаружения нарушения.
- Кто подтверждает спорный вывод и кто отвечает за изменение правила.
Для первой проверки разумно оставить автоматические оценки в режиме наблюдения: руководитель видит их, сверяет основания и сам решает, что делать. Не используйте непроверенные баллы как единственное основание для решений о сотрудниках.
Как получить эталон, если люди тоже оценивают по-разному
Попросите двух проверяющих независимо оценить одни и те же записи по одной версии чек-листа. До завершения разметки они не должны видеть ответы друг друга и ИИ. Затем разберите несовпадения по записи и зафиксируйте согласованный ответ с объяснением.
Такую сверку называют калибровкой. В документации NiCE CXone она устроена как оценка одного разговора несколькими людьми по одной форме. Большое расхождение - повод уточнить форму оценки.
Допустим, в вашем правиле следующий шаг считается согласованным, только если клиент подтвердил действие и срок. Менеджер сказал: «Пришлю предложение завтра», клиент сменил тему. Один проверяющий поставил зачёт за озвученный план, второй - незачёт из-за отсутствия подтверждения. Здесь сначала нужно договориться о применении правила. Подгонять ИИ под случайно выбранную оценку рано.
Храните рядом с эталоном фрагмент разговора и объяснение. Если основание находится за пределами звонка, укажите его: например, действующий для этой сделки срок поставки. Проверяющий и система должны иметь доступ к тем данным, которые нужны для вывода.
Предусмотрите отдельные состояния:
| Состояние | Когда ставить | Что делать дальше |
|---|---|---|
| Выполнено | Действие подтверждено записью и нужным контекстом | Учесть как выполненный критерий |
| Нарушение | Правило применимо, невыполнение подтверждено | Зафиксировать основание |
| Не применимо | В этом типе разговора действие не требовалось | Исключить критерий из оценки этого звонка |
| Недостаточно данных | Запись оборвалась, фрагмент неразборчив или нужный контекст недоступен | Отправить на проверку, не превращать в нарушение |
Например, при разговоре только о статусе доставки предложение новой покупки может быть неприменимо. Обрыв записи до окончания разговора не доказывает, что менеджер забыл следующий шаг. Эти ситуации должны отличаться и в эталоне, и в отчёте системы.
Если хотите увидеть, как организован разбор разговоров в Точке СУТИ, посмотрите решение для отделов продаж. На демонстрацию полезно прийти со своим критерием и примером спорной оценки.
Какие записи взять и какие оставить для контроля
Разделите записи на набор для настройки и отдельный набор для итоговой проверки. На первом можно уточнять правила и исправлять ошибки. Второй нужен, чтобы увидеть результат на примерах, под которые настройку ещё не подгоняли.
Принцип независимого тестового набора описан в документации scikit-learn. Если по контрольным примерам меняли систему, эти примеры уже участвовали в настройке. Для следующего итогового замера подготовьте новые записи. Связанные разговоры одной сделки держите в одной части: иначе система может получить знакомый контекст в обеих.
Соберите два вида проверки и показывайте их результаты отдельно:
- Обычный поток. Звонки за заранее выбранный период: разные сотрудники, продукты и сценарии в пропорциях, близких к работе отдела. Зафиксируйте способ отбора, чтобы в подборку не попали только удобные разговоры.
- Сложные случаи. Записи с редким нарушением, перебиваниями, шумом, пересказом чужого обещания или нестандартным ответом клиента. Здесь вы проверяете конкретные слабые места. Доля ошибок в специально собранной подборке не описывает весь поток.
Небольшой первый разбор помогает обнаружить неясные критерии и проблемы загрузки. Он не доказывает точность системы на всех звонках. Размер итоговой выборки зависит в том числе от частоты проверяемых событий: если нужное нарушение в неё не попало, способность находить его осталась непроверенной.
Используйте только записи, для которых в компании оформлены необходимые основания записи, обработки и передачи выбранному сервису. До загрузки согласуйте с ответственным за данные порядок уведомления участников, получения согласий там, где они нужны, доступ и сроки хранения. Сам факт наличия аудиофайла не подтверждает, что его можно передать любому подрядчику.
Как посчитать пропуски и ложные срабатывания
Для каждого критерия посчитайте четыре исхода: найденное нарушение, пропуск, ложное срабатывание и верно отмеченное отсутствие нарушения. Отдельно покажите неприменимые случаи и нехватку данных. Формулы точности срабатываний и полноты обнаружения приведены в справке Google по метрикам классификации.
Ниже условный расчёт, а не измерение Точки СУТИ или результат клиента. Проверяем один критерий на 100 звонках, где он применим и данных достаточно. По согласованному эталону нарушение есть в 20 звонках. ИИ нашёл 15 из них, пропустил 5 и дополнительно отметил нарушение в 10 корректных разговорах.
| Результат ИИ | В эталоне нарушение есть | В эталоне нарушения нет |
|---|---|---|
| Отметил нарушение | 15 найдено верно | 10 ложных срабатываний |
| Не отметил нарушение | 5 пропущено | 70 верных отрицательных ответов |
Из этой таблицы получаются три разных ответа:
- Совпадение с эталоном: (15 + 70) / 100 = 85%.
- Точность срабатываний: 15 / (15 + 10) = 60%. Из всех отмеченных нарушений подтвердились шесть из десяти.
- Полнота обнаружения: 15 / (15 + 5) = 75%. Система обнаружила три четверти нарушений из эталона.
В отчёте стоит 85% совпадений, но руководитель получит 10 ложных тревог и не увидит 5 реальных нарушений. Для решения о запуске нужны все эти числа.
Показывайте числитель и знаменатель рядом с процентом. Если ИИ ни разу не отметил нарушение, точность срабатываний рассчитать нельзя. Если нарушений нет в эталоне, нельзя рассчитать полноту обнаружения. В обоих случаях пишите «нет данных для расчёта» и объясняйте причину.
Не исключайте молча ответы «недостаточно данных». Укажите их количество, причины и отдельно проверьте, как часто система ставит этот статус там, где человек способен дать оценку. Иначе система, которая отказывается оценивать сложные записи, будет выглядеть точнее, чем помогает в работе.
Как понять, что именно исправлять
Для каждого расхождения восстановите путь от аудио до вывода. Иначе легко переписать критерий, хотя проблема возникла раньше: система неверно распознала отрицание или приписала клиентскую реплику менеджеру.
Проверяйте последовательно:
- Исходную запись. Нужный фрагмент существует и слышен? Если нет, исправляйте получение аудио или оставляйте случай неоценённым.
- Расшифровку и говорящего. Сохранены ли отрицания, суммы, названия и роли? «Не обещаю завтра» и «обещаю завтра» приводят к разным оценкам.
- Контекст правила. Система использовала актуальный регламент? Критерий подходит этому типу обращения?
- Применение критерия. Есть ли в записи основание для вывода? Совпадает ли оно с объяснением ИИ?
- Действие после оценки. Даже верное срабатывание может привести к ненужному действию, если правило реагирования настроено слишком широко.
Заведите журнал расхождений. Для каждой записи достаточно идентификатора звонка, критерия, эталона, ответа ИИ, фрагмента-основания, причины ошибки и принятого изменения. Контакты клиентов в такой журнал без необходимости не переносите.
После правки проверьте и исправленный случай, и другие сценарии по тому же критерию. Новое правило может убрать ложные тревоги ценой дополнительных пропусков. Итоговый результат снова измерьте на независимой контрольной части.
Когда можно запускать и что проверять после
Принимайте систему по заранее согласованным условиям для конкретных критериев и действий. Универсальный процент точности не определяет, можно ли доверить ИИ ваш процесс: последствия пропущенного обещания клиенту и неверной отметки о приветствии различаются.
До итогового прогона запишите допустимые пропуски, ложные срабатывания и долю неоценённых случаев. Если вы ещё не понимаете приемлемые значения, проведите разведочный пилот, оцените нагрузку на ручную проверку и согласуйте пороги для следующего независимого испытания. Не подбирайте порог задним числом под уже полученный результат.
К запуску должны быть готовы:
- правила и эталоны с указанными версиями;
- отчёт по важным критериям с числами и составом выборки;
- объяснение оставшихся ограничений и сценариев для ручной проверки;
- ответственный за спорные оценки и порядок их пересмотра;
- условия повторной проверки после изменения модели, регламента или состава звонков.
Можно запускать поэтапно: оставить ненадёжный критерий на ручной проверке, а проверенные использовать в согласованном сценарии. Граница применения должна быть видна людям, которые читают отчёт.
После запуска проверяйте выборку из обычного потока, включая звонки без срабатываний. Если смотреть только отмеченные нарушения, пропуски так и останутся невидимыми. Для управленческой работы с уже проверенными результатами пригодится отдельный разбор анализа звонков отдела продаж.
Источники
- NiCE CXone: калибровка форм и оценок - сверка оценок нескольких проверяющих на одном разговоре.
- Google: точность, полнота и другие метрики классификации - определения и ограничения метрик.
- scikit-learn: проверка качества на независимых данных - разделение данных для настройки и итоговой оценки.
Перед демонстрацией Точки СУТИ выберите один важный критерий и несколько спорных разговоров. Так обсуждение начнётся с того, как проверяется оценка и какое решение вы сможете принять по её результату.
Посмотрите, как это работает на ваших звонках
Разберём реальный сценарий вашего отдела продаж и покажем платформу за 30–40 минут.
