Разработка AI Speech Analytics для анализа звонков: STT, NLP, compliance

Разработка AI speech analytics: где ломается анализ звонков

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

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

Отдельная проблема — разрозненность. Записи лежат в одной системе, расшифровки — в таблицах, оценки — в личных заметках супервизора, и свести это в общую картину не получается. Речевая аналитика в таком виде не отвечает ни на вопрос о причинах обращений, ни на вопрос, где проседает конкретная команда.

Разработка AI speech analytics начинается с того, что анализ звонков перестаёт быть ручной операцией. Распознавание речи в контакт-центре работает как конвейер: запись автоматически попадает в обработку, разделяется по ролям участников, приводится к тексту с учётом терминов и названий. Дальше по расшифровке работают правила и модели — от обязательных фраз до признаков выгорания у операторов.

Ниже разбираем, как это закрывается: от доступа к записям и словаря терминов до отчётов, по которым руководитель видит динамику по командам и темам обращений.

Эффект внедрения: качество распознавания и разбор отказов

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

• Полнота разбора архива. Ручное прослушивание закрывало единицы процентов записей — остальное оставалось вне проверки. После внедрения распознавание и автоматический разбор по сценариям проходят по всему трафику, включая ночные смены и линии подрядчиков.
• Точность распознавания речи. Считаем на размеченной выборке — открытый корпус Common Voice плюс слепок записей заказчика. Метрику разносим по типам линий: на шумном канале и на связи с пережатием качество заметно ниже, чем на эталонной студийной записи.
• Скорость поиска разговора. Поиск по архиву звонков идёт по фразе, номеру, оператору и периоду — нужный эпизод находится за секунды вместо часов ручного прослушивания.
• Доля автоматически найденных нарушений. Отсутствие обязательной оговорки о записи разговора, перебивание клиента, конфликтные формулировки подсвечиваются системой. Специалист приходит к готовому инциденту, а не ищет его вручную.

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

Режимы обработки звонков: поток, пакет, гибрид

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

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

Гибридная схема снимает это противоречие: лёгкий потоковый проход даёт оперативную картину и метаданные, а пакетный проход на открытой модели Whisper уточняет расшифровку и разметку для отчётности. Расхождение между проходами — ещё и индикатор проблем со звуком на стороне телефонии.

Выбор режима — это выбор между задержкой разбора и качеством расшифровки; гибрид покупает оба, но требует зрелой эксплуатации.

Этапы разработки: от аудита записей до передачи системы

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

1. Аудит архива и каналов. Разбираем записи из всех источников: телефония, контакт-центр, диктофоны, записи встреч. Смотрим разделение по каналам, долю шума, обрывы, кодеки, длину диалогов. На выходе — карта источников с долей записей, пригодных для автоматического разбора, и списком того, что придётся чистить на входе.
2. Схема потока и правила обработки. Фиксируем, где проходит выгрузка, хранение, разбор и витрина отчётов. Отдельно согласуем обезличивание, сроки хранения и доступ по ролям — это требование, которое дешевле заложить сразу, чем перестраивать хранилище задним числом.
3. Настройка словарей. Термины, названия продуктов, аббревиатуры, сленг операторов, фонетические варианты произношения. Словари закрывают то, что общая модель слышит неверно: без них названия тарифов и услуг распознаются как случайный набор слов.
4. Разметка выборки. Вручную размечаем несколько сотен диалогов и получаем эталон: роли, темы, ключевые события, нарушения. Выборку стратифицируем по каналам, темам и качеству связи, иначе оценка качества окажется завышенной.
5. Внедрение речевой аналитики. Настраиваем разделение по ролям, детекторы и теги, правила проверки скриптов и запрещённых формулировок. Пороги срабатывания подбираем так, чтобы отчёты не тонули в ложных срабатываниях.
6. Проверка качества разбора. Прогоняем систему на отложенной выборке и смотрим точность распознавания, корректность определения ролей, полноту и точность тегов. Каждую ошибку относим к источнику: модель, словарь, разметка или правило.
7. Обучение и передача. Отдаём документацию, регламент обновления словарей, инструкции для аналитиков и схему мониторинга качества. Команда заказчика дальше правит словари и пороги самостоятельно — без нас.

Что передаём на выходе: словари, разметка, политики доступа

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

• Словари терминов и правила разметки — отраслевая лексика, синонимы, сокращения, список исключений; пополняются из корпуса ваших записей, а не переписываются с нуля при каждом изменении речи.
• Схемы потоков данных — где запись появляется, где хранится, где удаляется, какие копии остаются; по этой схеме дальше спокойно проходит служба безопасности.
• Матрица ролей и политики доступа — кто слышит аудио, кто видит только текст, кто работает с отчётами; доступ к записи не выдаётся «на всякий случай».
• Обезличивание записей — персональные данные вырезаются или маскируются до момента хранения, аналитикам уходит уже очищенный текст, а исходник живёт под отдельным ограниченным правом.
• Регламенты контроля качества — как часто измеряется точность распознавания, по какой выборке и кто перепроверяет вручную; зафиксировано, какой просадки считаем деградацией.
• Документация на систему — архитектура, параметры конфигурации, инструкции для операторов и администраторов, порядок обновления моделей и словарей.
• Журнал изменений и порядок отката — версия словаря привязана к результату разбора, поэтому можно вернуться к предыдущей и сравнить вывод на одной и той же записи.

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

Кейс: как разбор звонков сократил время контроля качества

Кейс речевой аналитики начался с замера: заказчик — сервисная компания с контакт-центром на несколько десятков операторов и потоком 2–3 тысячи звонков в сутки. Отдел контроля качества из трёх человек прослушивал 40–50 диалогов в неделю — около 2% трафика. На одну проверку уходило 20–25 минут: прослушать разговор целиком, сверить со скриптом, зафиксировать нарушение, оформить заключение. Остальные записи не разбирал никто, поэтому о конфликтах узнавали из жалоб, а не по своей выборке звонков.

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

Что изменилось

Результаты внедрения считали по одним и тем же метрикам до и после. Разбор вырос с 2% до 100% звонков: каждый диалог получает оценку и метки «спор», «отказ от оплаты», «нарушение регламента». Оператор открывает не случайную запись, а отфильтрованную выборку — сокращение времени проверки до 4–6 минут вместо 20–25, потому что расшифровка, таймкоды и подсветка нарушений уже готовы.

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

Как разбор речи встраивается в существующую телефонию

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

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

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

Разные источники звонков — несколько АТС, провайдеров, площадок контакт-центра — сводим к единому виду: контейнеры и кодеки, число каналов и частоту дискретизации нормализуем, битые и пустые участки отбрасываем. Дальше один индекс поверх всех хранилищ аудио, и поиск идёт сразу по всем источникам, а не по каждому отдельно.

Сырые записи остаются у вас: сюда уходит только нужное для разбора, с заданной политикой хранения и удаления, а доступ выдаётся сервисной учётной записью с минимальными правами.

Технические вопросы: точность, языки, хранение записей

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

Сколько языков поддержать и что со смешанной речью?

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

Насколько глубокий архив нужен и как хранить записи?

Аудио и расшифровки живут раздельно: текст с метриками хранится дешевле и ищется быстрее, аудио — по политике (срок, холодный класс, автоудаление). Часто достаточно держать целиком только фрагменты со сработавшими правилами контроля, остальное — ограниченный срок.

Кто и как получает доступ к записям?

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

Обсудим задачу: что нужно для оценки разбора звонков

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

• Каналы и объём. Откуда идут записи — телефония, мессенджеры, очные встречи — сколько часов разговоров в месяц и как растёт поток. По этому считаем нагрузку и выбираем схему обработки.
• Формат архивов. Один канал или стерео, слышно ли обоих участников, есть ли посторонний шум и как хранится история. Отсюда — объём предобработки и ожидаемая точность распознавания.
• Что ищем в разговорах. Скрипты и критерии оценки оператора, стоп-слова, названия продуктов, конкурентов, спорные формулировки. Список превращается в правила и словари.
• Регуляторные рамки. Требования к хранению персональных данных, срокам и доступам, нужно ли ограничить обработку вашим контуром.
• Системы-получатели. Куда отдавать результаты — в CRM, хранилище отчётов или внутреннюю панель, какие роли и права нужны руководителям и службе контроля качества.
• Критерий успеха. Как вы поймёте, что внедрение сработало: доля проверенных звонков, скорость реакции на инцидент, полнота выборки для разбора.

Собрав ответы, мы возвращаемся с оценкой и планом работ: этапы, состав, что закрывается на вашей стороне и что на нашей. Готовое ТЗ не требуется — опишите задачу своими словами, остальное разберём вместе.