Как проверить ИИ-анализ звонков перед оценкой работы менеджеров

Если ИИ отметил, что менеджер не согласовал следующий шаг с клиентом, не переносите эту оценку сразу в отчёт о работе сотрудника. Сначала откройте запись в указанном месте, сверьте слова и говорящего, затем проверьте, следует ли вывод из вашего чеклиста. Один общий «процент точности» не ответит на оба вопроса: расшифровка может ошибиться в важном слове, а верно распознанную фразу система может неверно истолковать.

Ниже — протокол для руководителя продаж, который принимает пилот речевой аналитики перед регулярной обратной связью команде. По итогам пилота зафиксируйте, какие выводы требуют проверки, какие ошибки повторяются и когда отчёт нужно остановить и передать человеку.

Сначала определите, что именно оцениваете

Выберите несколько наблюдаемых событий из действующего стандарта разговора. Например: менеджер назвал следующий шаг, уточнил срок ответа, подтвердил адрес для документов. Для каждого события запишите правило так, чтобы два проверяющих могли указать один и тот же фрагмент записи. Формулировка «проявил заботу» без наблюдаемого признака не годится для автоматической оценки.

Заранее разделите три результата: «подтверждено записью», «не подтверждено» и «нельзя решить по записи». Третья категория нужна, если звук неразборчив, реплики наложились или нельзя уверенно понять, кто говорил. Она не должна автоматически превращаться в отрицательный балл менеджеру.

Назначьте владельца проверки: обычно это руководитель или специалист по качеству, который знает стандарт и может переслушать запись. Его задача — разбирать спорные выводы, а не переписывать за систему весь отчёт. Отдельно договоритесь, какие ошибки критичны: например, ложное замечание о несогласованном сроке важнее пропущенного слова-паразита, если отчёт влияет на обратную связь сотруднику.

Соберите тестовые звонки и ручной эталон

Используйте только записи, разрешённые для этой проверки. До работы с реальным аудио профильный специалист организации должен проверить основания его использования, доступы и условия выбранного сервиса. Если разрешения нет, начните с синтетических записей для демонстрации механики и не делайте по ним вывод о качестве на рабочих звонках.

Для содержательной приёмки нужны разные условия, встречающиеся в вашем процессе: спокойная и шумная линия, разные сценарии разговора, перебивания, короткие и длинные ответы. Не выбирайте только удобные записи. Google Cloud рекомендует сравнивать распознавание с человеческим эталоном на записях, близких к целевым условиям. Это методика оценки распознавания, а не доказательство качества готового вывода об исполнении стандарта. Размер набора и порог приёмки определите для своего процесса и зафиксируйте до просмотра результатов; число из чужой документации не становится универсальной нормой для оценки менеджеров.

Для каждого проверяемого фрагмента человек слушает аудио и записывает слова по заранее принятому правилу: как отмечать паузы, неразборчивую речь и числа. Эталон должен сохранять смысловые части фразы, даже если автоматическая расшифровка выглядит грамматически аккуратнее. Если эталон спорный, отметьте разногласие и не используйте этот фрагмент как бесспорную ошибку системы.

Проверьте два звена: слова и вывод

Первое звено — расшифровка. Сравните машинный текст с ручным эталоном в двух случаях: когда система сообщила о выполнении или нарушении правила и когда проверяющий услышал событие, на которое система должна была ответить, но промолчала. Посмотрите на отрицания, сроки, суммы, имена, перепутанные стороны разговора. При необходимости специалист по речевым технологиям может посчитать долю ошибок в словах (WER): Google Cloud описывает сумму вставок, замен и пропусков, делённую на число слов в ручном эталоне. Но усреднённая доля ошибок не показывает сама по себе, была ли искажена решающая договорённость. Оценка уверенности распознавания тоже не заменяет сверку с аудио.

Второе звено — правило и вывод. Если слова определены верно, проверьте, относится ли цитата к нужному пункту чеклиста. Например, «я пришлю предложение во вторник» и «вы пришлёте исходные данные во вторник» содержат срок, но это разные обязательства. Система должна показывать основание вывода: доступную запись, временную метку, говорящего, фрагмент текста и применённое правило. Если она выдаёт только итоговый балл без проверяемого фрагмента, используйте балл как повод для ручной проверки, а не как факт о работе менеджера.

Разметка говорящих сама требует проверки. Например, документация Yandex SpeechKit описывает разметку в API v3 только для моноаудио в режиме FULL_DATA, не более двух говорящих в результате; это не гарантия, что любой сервис правильно определит менеджера и клиента на вашей записи. Для конкретного инструмента и аудио возможности и качество должен проверить специалист.

Протокол проверки вывода по звонку

До проверки зафиксируйте для каждого правила, о чём сервис обязан сообщать: о наличии и отсутствии события на каждом звонке, только о наличии события или только о нарушении (отсутствии нужного события). Запишите, означает ли молчание по этому правилу штатный ответ или отсутствие обязательного ответа. Если поведение сервиса неизвестно, уточните его у поставщика и не считайте молчание ни выполнением правила, ни ошибкой до выяснения. Например, сервис, который сообщает только нарушения, штатно промолчит, когда менеджер выполнил правило.

Единица проверки — один разрешённый звонок × одно заранее выбранное правило. Создайте строку для каждого сочетания в выбранной выборке, даже если ИИ ничего не сообщил. Проверяющий сначала слушает запись и отмечает наличие события по правилу независимо от списка выводов ИИ. Затем по зафиксированному режиму определяет, должен ли быть ответ, и сопоставляет ручное решение с отчётом системы. Если событие отсутствует, укажите «нет» и что проверен весь звонок; временную метку оставьте пустой. Если запись не позволяет решить, укажите «нельзя решить», не угадывая ответ. Доступ к записи у проверяющего должен быть разрешён; в общедоступную таблицу не переносите реальные аудио и персональные данные.

Учебный вымышленный пример. Для TEST-04 выбрано правило «менеджер обещал расчёт сегодня» с режимом «ответ всегда». На отметке 03:12 по ручному эталону менеджер говорит: «Я не обещаю отправить расчёт сегодня; пришлю завтра до обеда». Машинная версия пропускает «не» и оставляет «Я обещаю отправить расчёт сегодня». Система пишет: «Обещан расчёт сегодня; срок согласован». В строке протокола ручное решение — «события нет», вывод ИИ — «событие есть», итог — «ложный вывод». Проверяющий исключает его из оценки и проверяет на тестовом наборе другие фразы с отрицанием и сроками. Это иллюстрация механизма ошибки, не результат испытания какого-либо продукта.

Второй учебный пример. Для TEST-05 правило — «менеджер назвал срок следующего шага». В этом примере сервис настроен сообщать о наличии и отсутствии события на каждом звонке. На учебной записи менеджер отчётливо говорит: «Пришлю расчёт завтра до обеда». При самостоятельной проверке записи проверяющий ставит «событие есть»; по режиму ответ обязателен, а в отчёте ИИ по этому правилу нет ни подтверждения, ни замечания. В строке TEST-05 × правило он записывает «вывода нет» и итог «обязательный ответ пропущен». Если бы сервис сообщал только о нарушениях, молчание при выполненном правиле было бы штатным и в пропуски не вошло бы.

Теперь представим, что машинный текст передал слова без ошибки, но система записала эту реплику клиенту. Тогда причина уже другая — принадлежность реплики, а не точность слов. Поэтому в протоколе есть отдельное поле для стороны разговора. Если невозможно расслышать отрицание даже человеку, правильный вердикт — «нельзя решить», а не попытка угадать по уверенному тексту модели.

Как принять решение после пилота

Сведите строки по каждому правилу и его режиму ответа; отдельно посмотрите на критичные выводы, способные повлиять на обратную связь менеджеру. Знаменатель выборки — все проверенные сочетания «звонок × правило». Для долей по содержанию отложите строки «нельзя решить» и «режим неизвестен», назвав число каждой группы из общего знаменателя. Среди разрешимых строк с известным режимом считайте: подтверждённые выводы — совпадения ручного решения и ответа ИИ из всех строк с ответом ИИ; ложные выводы — противоречия ручному решению из того же числа строк с ответом ИИ; пропущенные обязательные ответы — отсутствие ответа там, где он требовался по режиму и ручному решению, из всех строк, где ответ требовался. Штатное молчание, например при соблюдении правила в режиме «только нарушения», не входит в числитель и знаменатель пропусков. Отдельно отметьте лишние ответы там, где режим предполагал молчание. В двух учебных строках TEST-04 и TEST-05 режим «ответ всегда»: один ложный вывод из одного ответа ИИ, один пропущенный обязательный ответ из двух обязательных, ноль неразрешимых из двух проверенных сочетаний. Это арифметика примера, а не измерение качества сервиса. Записывайте также время ручной проверки и исправлений. Порог приемлемости установите до испытания с учётом цены именно ваших ошибок; не объявляйте пилот успешным по красивому среднему баллу, если в нём остаются ложные существенные замечания.

Если ошибки сосредоточены в одном сценарии, устройстве записи или виде реплик, не переносите вывод на все звонки. Исправьте условие, правило или конфигурацию и снова проверьте соответствующие случаи. NIST AI RMF предлагает документировать условия тестирования и распределять роли контроля как часть управления рисками ИИ; это добровольная методическая рамка, не знак сертификации вашего пилота.

Пока существенные выводы не воспроизводятся по записи, оставьте автоматический отчёт черновиком для проверяющего. Не превращайте его в автоматическое кадровое решение. Если звонков мало либо стандарт качества ещё не разложен на наблюдаемые события, начните с ручной выборочной проверки или простого правила без ИИ. Это даст основу для чеклиста и покажет, какую работу вообще стоит автоматизировать.

Для другой операции можно использовать общий тест ИИ-помощника на сценариях. Здесь ближайший практический шаг — согласовать одно правило звонка и заполнить протокол на разрешённых записях до обсуждения оценок сотрудников.