Почему качество расшифровки - не главный критерий Speech Analytics
Самая распространённая ошибка при выборе системы речевой аналитики: сравнить вендоров по качеству расшифровки аудио и на этом остановиться. Разбор на Habr называет такую логику выбора главным провалом, и спорить тут не с чем. Транскрибация отвечает за первый слой работы. Решение о том, качественно ли прошла консультация, принимается на двух других.
Короткий ответ на главный вопрос: точная расшифровка не равна верной оценке. ASR-модель может восстановить диалог почти дословно, а менеджер в этом диалоге не выяснил, какая у клиента CRM, не уточнил требования к интеграции, не назвал конкретный срок и не договорился о следующем действии. Текст читается гладко. С оценкой результата консультации - проблемы.
Speech Analytics проходит три уровня: распознавание речи, интерпретация смысла и агрегация оценок в отчёты. Сбой на любом уровне меняет управленческие выводы, потому что руководитель смотрит на цифры и по ним решает вопросы обучения, премий и численности команды. Дальше разбираем, как устроен каждый уровень, как проверить систему на собственных звонках и почему убедительное объяснение от LLM не служит доказательством.
Что показывает WER и чего он не показывает
WER (word error rate) считает долю неверно распознанных слов относительно эталонной расшифровки: WER = (S + D + I) / N, где S - замены, D - пропуски, I - вставки, N - число слов в эталоне. Метрика полезна для настройки ASR и сравнения движков на одинаковом аудио. Дальше начинаются ограничения.
Небольшая доля ошибок даёт существенную ошибку для бизнес-аналитики. Классический пример - потерянная частица «не»: «Мы можем подключить интеграцию» и «Мы не можем подключить интеграцию» отличаются одним словом, а смысл меняется на противоположный. Тот же разбор приводит эту пару фраз как аргумент против оценки сервиса по одной цифре WER.
Практический вывод: общую точность транскрибации дополняют проверкой критических сущностей и высказываний. Для отдела продаж это названия продуктов, суммы, сроки, упоминания конкурентов, прямые отказы, реплики про следующий шаг. Такие проверки отвечают на вопрос «правильно ли система поняла то, что влияет на сделку», а WER на него не отвечает.
Почему демо с чистым аудио обманывает ожидания
Сбои распознавания известны: шум в офисе и на улице, одновременная речь, технические термины, названия продуктов, акценты, некачественная телефония с узкой полосой и потерями пакетов. Демо-запись обычно делают в тихом помещении и на хороший микрофон. Реальный поток звонков отдела продаж выглядит иначе: гарнитуры разной степени убитости, разговоры из машины, клиенты с плохой связью.
Разница между студийной записью и записью из телефонии влияет на всё, что стоит выше ASR. Испорченное слово на входе превращается в неверный критерий на выходе. Правило простое: проверять систему нужно на своих записях из тех каналов, где она будет работать. И шумный текст остаётся проблемой даже после распознавания: почему классический spell check не справляется с шумным текстом и что с этим делают в enterprise-контуре.
Один диалог, две разные оценки: где заканчивается транскрибация и начинается интерпретация
Клиент спрашивает, есть ли возможность интеграции с его CRM. Менеджер отвечает: «Да, такая возможность предусмотрена». Клиент уточняет сроки. Ответ: «Обычно недолго». Разговор закончился, обе стороны вежливы, никто не повышал голос.
С точки зрения распознавания здесь почти нечего обсуждать: даже простая ASR-модель восстановит такой диалог достаточно точно. Проверка по критериям даёт четыре пропуска: не выяснена CRM, не уточнены требования к интеграции, не назван конкретный срок, не согласовано следующее действие. Фраза «обычно недолго» не содержит полезной для клиента оценки сроков. Этот диалог показывает главное: качество консультации - отдельная задача, для которой нужны критерии, а не только текст.
Какие вопросы система должна была заметить, но не заметила
Каждый пункт выше - отдельный критерий, и каждый настраивается явно: формулировки, синонимы, порог срабатывания, исключения. Критерий «менеджер задал уточняющий вопрос о CRM» проверяется по правилу: в реплике менеджера есть вопросительная конструкция и упоминание CRM или её названия из списка. Без такого правила система не отличит «Да, интеграция есть» от выяснения деталей.
Если критерий не настроен, система по умолчанию оценивает гладкость разговора: вежливость, отсутствие длинных пауз и перебиваний. Эти признаки связаны с чем угодно, кроме результата. Менеджер может быть предельно вежливым и при этом не собрать ни одного требования клиента.
Почему «обработал возражение» - это договорённость о стандарте, а не факт из текста
Клиент говорит: «Ваше решение слишком дорогое». Менеджер отвечает: «Понимаю вас. Давайте посмотрим другие варианты». Засчитать это обработкой возражения или нет?
Зависит от принятого стандарта. Вариант первый: возражение обработано, если менеджер проявил эмпатию и предложил альтернативу. Вариант второй: обработано, если назван конкретный вариант дешевле, изменена комплектация или предложена рассрочка с числами. В первом случае оценка будет «да», во втором «нет», а текст разговора один и тот же.
Отсюда требование к любой системе: команда фиксирует стандарт письменно. Что считается обработкой возражения, что нет, какие формулировки дают срабатывание, какие исключения. Без такого документа оценка остаётся субъективной и невоспроизводимой: два руководителя посмотрят один звонок и поставят разные баллы, а система добавит третий вариант.
Три уровня ошибок Speech Analytics и как каждый искажает управленческие выводы
Ошибки делят на три уровня: распознавание, интерпретация, агрегация. Уровни связаны, сбой на нижнем передаётся наверх и там усиливается. Разберём, что происходит на каждом.
Ошибки распознавания: шум, термины и частица «не»
Первый уровень: аудио превращается в текст с ошибками. Источники перечислены выше, и они не исчезают после покупки нового движка. Низкий WER не гарантирует правильного восстановления критически важных слов: пропущенное «не» или перепутанная сумма меняют смысл реплики целиком.
Что делать: завести список критических сущностей под свои процессы (названия тарифов, продуктов, конкурентов, диапазоны сумм) и проверять точность распознавания именно по нему, отдельно от общей метрики.
Ошибки интерпретации: когда текст верный, а вывод - нет
Второй уровень: транскрибация корректна, а система неверно определяет, обработал ли менеджер возражение, назвал ли срок, договорился ли о следующем шаге. Причина обычно в критериях: их нет, они расходятся со стандартом компании или написаны так широко, что под них подходит любая вежливая фраза.
Опасность в том, что такую ошибку не видно в транскрипте. Расшифровка читается нормально, ссылка на фрагмент ведёт на реальную реплику, а вывод неверный, потому что правило сформулировано слишком свободно.
Ошибки агрегации: как частные сбои превращаются в неверные KPI
Третий уровень: оценки по отдельным звонкам суммируются в отчёты по менеджерам, командам и периодам. Руководитель решения принимает по агрегату, поэтому этот уровень самый дорогой. Систематический пропуск отсутствия следующего шага завышает средний балл по критерию, и руководитель видит команду, которая уверенно дожимает клиентов, хотя значительная часть разговоров заканчивается без договорённости.
Средние скрывают распределение. Разница в один-два процентных пункта на команде из десяти человек может означать один неудачный звонок, а не изменение качества работы. Почему красивая сводка уводит в сторону, разбирали в материале про опасный дашборд и субъективные KPI. Отдельный класс проблем - сбои без сигнала об ошибке: тихие дефекты, которых не видно на дашбордах, когда метрики успеха зелёные, а результат неверный.
Как проверить систему речевой аналитики перед внедрением
Проверка сводится к пяти шагам: контрольный набор разговоров, эталонная разметка, расчёт метрик, разбор ошибок, проверка ссылок на фрагменты. Каждый шаг делается на своих данных, а не на демо-записях вендора.
Контрольный набор разговоров и эталонные оценки экспертов
Набор собирают из реальных звонков: первичный контакт, работа с возражением, повторное обращение, отказ. В нём нужны сильные и слабые менеджеры, разные каналы связи и разные телефонии. По объёму ориентир такой: несколько десятков звонков на каждый критерий, который планируется измерять. Если критерий редкий, например упоминание конкурента, придётся либо увеличивать выборку, либо отдельно добирать звонки по ключевым словам.
Эталон выставляют эксперты по тем же критериям, которые потом получит система. Без эталона сравнивать не с чем. Полезная практика: два эксперта независимо размечают пересекающуюся часть выборки, а расхождения разбирают до запуска. Так становятся видны расплывчатые критерии, ещё на этапе ручной разметки.
Precision и recall: как считать и что они говорят о системе
Precision показывает долю верных срабатываний среди всех срабатываний: precision = TP / (TP + FP). Recall показывает долю найденных случаев среди всех реальных: recall = TP / (TP + FN). Разберём на учебном примере, не связанном с конкретным вендором.
Эксперт нашёл 40 звонков без согласованного следующего шага. Система отметила 50 звонков, из них 30 совпали с эталоном. Precision = 30 / 50 = 60%, recall = 30 / 40 = 75%. То есть 20 ложных срабатываний и 10 пропусков.
Для управления это означает следующее. При precision 60% четыре из десяти звонков в отчёте «нет следующего шага» на самом деле нормальные, и разговор с менеджером по ним будет несправедливым. При recall 75% четверть проблем не попала в отчёт, и руководитель считает, что процесс в порядке.
Перекосы неравнозначны. Высокая precision при низком recall значит, что система редко ошибается, но многое пропускает: подходит для премирования и дисциплинарных разговоров. Высокий recall при низкой precision значит, что система находит всё, но с шумом: подходит для поиска зон роста и обучения. Метрики считают по каждому критерию отдельно, среднее по системе прячет провал одного правила.
Анализ ложных срабатываний и пропусков
Метрики без разбора примеров мало что дают. Каждое ложное срабатывание и каждый пропуск относят к уровню: распознавание (слово потеряно или искажено), интерпретация (правило сформулировано широко или узко), агрегация (оценка по звонку верная, но суммарный отчёт искажает картину). От уровня зависит, что именно править: словарь и доменную адаптацию ASR, формулировки правил и промптов или логику суммирования.
Пример: система отметила «нет следующего шага» в звонке, где менеджер сказал «отправлю коммерческое предложение и завтра наберу». Это пропуск на уровне интерпретации: правило ищет слова «договорились», «встреча», «созвон», а формулировка «наберу» в список не попала.
Можно ли доверять выводам LLM в оценке звонков
LLM-оценщик удобен: он объясняет решение человеческим языком и работает без жёсткой сетки правил. Риск в том, что объяснение звучит убедительнее, чем позволяют основания.
Почему убедительное объяснение - не доказательство
Языковая модель обучена выдавать правдоподобный текст. Вывод «менеджер не выяснил потребность» может быть логичным и при этом опираться не на разговор, а на ожидание типичного сценария продаж. Проверить это можно одним способом: посмотреть, на какой фрагмент ссылается модель, и есть ли в этом фрагменте нужные слова.
С оценщиками на базе LLM есть отдельная ловушка: плохо откалиброванные критерии маскируют реальные изменения. Кейс Similarweb с LLM-as-judge, проверками faithfulness и трейсингом разобран в материале про оценку качества ответов LLM и ошибку калибровки.
Ссылка на фрагмент, настройка критериев и аудит спорных оценок
Доверие к выводам LLM держится на трёх опорах. Первая: ссылка на конкретный фрагмент разговора с таймкодом, репликой и автором. Оценка без такой ссылки непроверяема. Вторая: явно настроенные и версионируемые критерии, по которым модель выставляет балл. Третья: регулярный аудит спорных случаев.
В аудит отправляют звонки с низкой уверенностью модели, оценки на границе порога, случаи, которые оспорил менеджер. Выборка должна быть систематической, иначе разбор превращается в реакцию на жалобы. Если модель не может показать фрагмент, на котором основана оценка, вывод не годится для управленческого решения: это текст, а не доказательство.
Как сравнивать системы речевой аналитики и что спрашивать у вендора
Критерии сравнения: качество интерпретации на ваших данных, прозрачность правил, наличие ссылок на фрагменты, поддержка аудита, устройство агрегации. WER остаётся в списке, но как один пункт из пяти, а не как основной аргумент.
Вопросы вендору на демо
- Как система определяет наличие следующего шага и что считается договорённостью?
- Кто настраивает критерии: вендор, интегратор или наша команда, и в каком виде они хранятся?
- Можно ли получить ссылку на фрагмент для каждой оценки?
- Как считаются precision и recall и на каком наборе звонков их можно проверить?
- Как оспорить спорную оценку и что происходит после оспаривания?
- Можно ли видеть распределение, а не только средний балл по менеджеру?
- Как версионируются критерии при изменении скриптов и тарифов?
Ответы на эти вопросы важнее качества демо-транскрибации. Демо показывает работу движка на подготовленном аудио, а вопросы показывают, как система поведёт себя на вашем потоке звонков через полгода.
Красные флаги при выборе системы
- Акцент в презентации держится на точности распознавания, про интерпретацию и агрегацию говорят общими словами.
- Нет разбора на ваших звонках, только заранее подобранные примеры.
- Критерии непрозрачны: «модель сама понимает смысл» без описания правил.
- Нельзя посмотреть ложные срабатывания и пропуски.
- Оценки не сопровождаются фрагментами разговоров.
- Отчёт показывает средние без распределения и без числа проверенных звонков.
Каждый признак по отдельности не доказывает, что продукт плохой. Вместе они означают, что проверять систему придётся дольше и жёстче.
Что сделать до и после внедрения речевой аналитики
Чек-лист проверки перед покупкой
- Зафиксировать критерии оценки и стандарт: что считать обработкой возражения, названным сроком, согласованным следующим шагом.
- Собрать контрольный набор из своих реальных звонков по разным сценариям, менеджерам и каналам.
- Получить эталонные оценки экспертов по тем же критериям, с пересекающейся разметкой у двух людей.
- Посчитать precision и recall по каждому критерию отдельно, зафиксировать ложные срабатывания и пропуски.
- Разобрать ошибки по уровням: распознавание, интерпретация, агрегация.
- Проверить на случайной выборке, что каждая оценка подкреплена фрагментом разговора.
- Посмотреть, как формируется агрегат и можно ли увидеть распределение по менеджерам.
Чек-лист проходят на своих данных и до подписания договора. Если вендор готов прогнать ваш набор и показать результаты с ошибками, это хороший сигнал. Если показывает только сводку успехов, проверка не состоялась.
Как поддерживать доверие к оценкам после запуска
После запуска работа не заканчивается. Раз в месяц или квартал пересчитывают precision и recall на свежей контрольной выборке: качество интерпретации меняется вместе с продуктом и скриптами. Критерии обновляют при смене тарифов, появлении новых продуктов, переписанных скриптах, иначе правила начинают оценивать прошлогодний процесс.
Резкий рост или падение доли срабатываний по критерию сначала проверяют на стороне правил, а не людей: чаще ломается формулировка, чем дисциплина целой команды. Жалобы менеджеров на несправедливые оценки собирают в отдельную очередь и разбирают выборочно, это дешёвый источник информации о ложных срабатываниях.
Запуск речевой аналитики - это настройка стандартов оценки, а не установка софта. Начните с 50-100 своих звонков и одного критерия, например «согласован следующий шаг», доведите precision и recall до приемлемых значений, и только потом расширяйте набор критериев. Если система не может показать фрагмент, на котором основана оценка, вы получаете красивый отчёт с недоказуемыми выводами.