Speech Analytics: почему сервис речевой аналитики может правильно распознать разговор и неправильно его оценить

Точность распознавания речи — важная характеристика системы, но не единственная. Разбираю, почему качественная транскрибация еще не означает качественную аналитику и как проверять выводы ИИ на реальных звонках.

Одна из самых распространенных ошибок при выборе системы речевой аналитики — оценивать ее по качеству расшифровки аудио.

Загрузили запись. Получили текст. Несколько терминов распознаны неправильно, но в целом разговор читается. Кажется, что основная техническая задача решена.

На практике самое интересное начинается после транскрибации.

Допустим, клиент спрашивает менеджера:

— А есть возможность интеграции с нашей CRM?

— Да, такая возможность предусмотрена.

— А сколько времени это займет?

— Обычно недолго.

С точки зрения распознавания здесь почти нечего обсуждать. Даже простая ASR‑модель может восстановить такой диалог достаточно точно.

А теперь попросим систему оценить качество консультации.

Менеджер ответил на вопрос? Да.

Выяснил, какая CRM используется? Нет.

Уточнил требования к интеграции? Нет.

Назвал конкретный срок? Нет.

Договорился о следующем действии? Нет.

Фраза «обычно недолго» вообще не содержит полезной для клиента оценки сроков.

И вот здесь проходит граница между распознаванием речи и полноценной речевой аналитикой.

Три уровня ошибок Speech Analytics

1. Ошибки распознавания

На первом уровне система преобразует аудио в текст.

Проблемы известны: шум, одновременная речь, технические термины, названия продуктов, акценты, некачественная телефония.

Но даже низкий WER не гарантирует, что правильно восстановлены критически важные слова.

Например, пропущенная частица «не» способна изменить смысл:

«Мы можем подключить интеграцию».

«Мы не можем подключить интеграцию».

Доля неверно распознанных слов может быть небольшой, а ошибка для бизнес‑аналитики — существенной.

Поэтому общую точность транскрибации полезно дополнять проверкой критических сущностей и высказываний.

2. Ошибки интерпретации

Вторая проблема сложнее.

Предположим, транскрибация корректна, но система должна определить, обработал ли менеджер возражение клиента.

В разговоре звучит:

— Ваше решение слишком дорогое.

— Понимаю вас. Давайте посмотрим другие варианты.

Можно ли засчитать обработку возражения?

Зависит от принятого стандарта. Если достаточно признать сомнение и предложить альтернативу — возможно. Если требуется выяснить причину возражения и аргументировать стоимость — нет.

Алгоритм здесь должен следовать конкретным критериям, а не самостоятельно придумывать определение хорошей продажи.

Поэтому любой показатель качества нужно начинать с операционного определения: что именно считается успешным выполнением и какие исключения допустимы.

3. Ошибки агрегации

Третий уровень — отчетность.

Допустим, система правильно оценила несколько тысяч разговоров. Но затем руководителю показывают среднюю оценку операторов без разделения по типам обращений.

Один сотрудник принимает простые вопросы о графике работы. Другой занимается претензиями и конфликтными ситуациями.

Сравнивать их только по средней оценке — сомнительная идея.

При построении аналитики важно учитывать сценарий, тип клиента, задачу обращения и состав критериев. Иначе корректные оценки отдельных разговоров могут привести к неправильному управленческому выводу.

Как проверить систему перед внедрением

Нужен контрольный набор реальных, разрешенных к обработке разговоров. Желательно включить в него не только типичные звонки, но и сложные случаи: перебивания, противоречивые ответы, незавершенные разговоры, неоднозначные возражения.

Для каждого критерия эксперты составляют эталонные оценки. Спорные случаи согласовываются отдельно.

Далее считаются не только общая доля совпадений, но и precision, recall, количество ложных срабатываний и пропусков.

Представим, что в выборке есть 100 разговоров с нарушением стандарта. Система обнаружила 90 подозрительных разговоров, но только 70 из них действительно содержали нарушение.

Получаем:

• Precision = 70 / 90 = 77,8%.

• Recall = 70 / 100 = 70%.

Если смотреть только на число найденных событий, результат может выглядеть впечатляюще. Но фактически 30% нарушений пропущены, а часть сотрудников получила ложные замечания.

Особенно важно отдельно проверять критические критерии, где ошибка алгоритма может привести к несправедливой оценке человека.

Почему нельзя ограничиваться ответом LLM

Большая языковая модель способна объяснить свою классификацию очень убедительно. Но убедительное объяснение не равно доказательству.

Если ИИ утверждает, что менеджер не предложил следующий шаг, желательно иметь возможность открыть соответствующий фрагмент разговора и проверить этот вывод.

Поэтому в промышленных системах полезны ссылки на первоисточник, настройки критериев, механизмы перепроверки и аудит спорных оценок.

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

Вывод

Speech Analytics — это не просто ASR плюс LLM.

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

Чем ближе результаты анализа к премиям сотрудников, оценке качества обслуживания и коммерческим решениям, тем важнее проверять не только качество распознавания, но и достоверность интерпретации.

Красивой транскрибации недостаточно. Нужна аналитика, выводам которой можно доверять.