Azure Speech Services: интеграция STT и Custom Speech

Почему Azure Speech Services ошибается на живых записях

Общая модель распознавания обучалась на чистой дикторской речи, а в работе ей достаётся архив реальных звонков. Узкополосный телефонный канал, сжатие, эхо от спикерфона, гул офиса и музыка на удержании снимают разборчивость ещё до того, как сигнал доходит до модели, — и Azure Speech Services на таком входе выдаёт уверенно неверные слова вместо пустого места.

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

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

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

Эффект от настройки: точность, скорость, разбор архива

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

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

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

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

Режимы Azure Speech: поток, архив, дообучение модели

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

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

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

Как строится внедрение: от пилота до передачи

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

1. Разбор задачи и аудио. Сводим источники звука (телефония, микрофоны, архивы), уровень шума, число говорящих и допустимую задержку. На выходе — список сценариев, которые система обязана закрыть.

2. Схема интеграции. Решаем, где живёт звук и куда уходит текст: потоковая расшифровка в звонке, пакетная обработка архива или гибрид. Фиксируем буферизацию и поведение при обрыве связи.

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

4. Настройка модели под отрасль. На Azure Speech Services дообучаем акустику и языковую модель на терминах, аббревиатурах и названиях, которые общий движок слышит неверно; отдельно настраиваем форматирование номеров и дат.

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

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

На выходе — работающая интеграция, набор записей для регрессии и регламент обновления модели.

Конфигурации, словари и политики доступа к сервису

Артефакты адаптации остаются в контуре заказчика: мы передаём не «настроенный сервис», а воспроизводимый комплект конфигураций. Azure Speech Services — базовый слой, поверх которого живут профили моделей, словари и правила доступа: их можно пересобрать, проверить и откатить без нашего участия.

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

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

Кейс: расшифровка архива обращений за неделю

К нам пришёл контакт-центр с архивом обращений: около 40 000 часов аудио за несколько лет, часть записей — в низком качестве и с перекрывающимися голосами. Базовое распознавание на общей модели давало долю ошибок в словах порядка 28%: названия тарифов, имена операторов и отраслевые аббревиатуры превращались в случайный набор букв, а поиск по расшифровкам не находил нужные разговоры. Выборочная ручная сверка занимала недели и всё равно покрывала малую долю архива.

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

На отложенной тестовой выборке доля ошибок в словах упала с 28% до 11%, а по ключевым сущностям — до 4%: номера заказов и названия услуг распознаются почти без правок. Архив в 40 000 часов прошёл обработку за неделю параллельными заданиями, доля фрагментов, которые пришлось переотправить из-за сбоя, — меньше 1%. Поиск по расшифровкам стал находить разговоры по упоминанию услуги, а не по дате звонка.

Чем дообучение модели отличается от базовой версии?

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

В Azure Speech Services адаптация разделена на два независимых слоя. Языковой опирается на текстовый корпус — транскрипты, глоссарий, список фраз — и правит лексику: составные термины, артикулы, имена. Акустический настраивается на запись — канал связи, акцент, фоновый шум — и вытягивает разбор там, где база слышит похожее по звучанию слово.

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

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

Частые технические сомнения перед стартом проекта

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

Аудио не должно покидать закрытый контур — это выполнимо?

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

Как проверить качество распознавания до внедрения?

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

Отраслевая терминология меняется — переделывать всё заново?

Нет. Списки фраз и словари обновляются отдельно от интеграции, а переобучение модели — регламентная процедура с той же проверкой на контрольной выборке. Мы работаем с Azure Speech Services и совместимыми движками, поэтому замена или дообучение модели не ломает логику приложения и сценарии обработки.

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

Чтобы обсудить задачу распознавания речи предметно, к разговору стоит собрать несколько вещей. По ним сразу видно, хватит ли базовой модели или нужно обучение Custom Speech на ваших данных, и складывается объём работ.

• Примеры записей — 20–30 файлов на каждый сценарий: тихая переговорная, шумный цех, телефонная линия. По ним считаем реальный уровень ошибок до дообучения.
• Источники аудио — телефония, записи совещаний, диктофоны, поток с микрофонов. От этого зависит шумоподавление и разделение говорящих.
• Словарь терминов — названия продуктов, должности, аббревиатуры, имена. Он уходит в настройку произношения и снимает ошибки на узкой лексике.
• Требования к точности — где хватит черновой расшифровки, а где нужен посимвольный разбор. Это задаёт объём разметки и число итераций обучения.
• Нагрузка — сколько часов аудио приходит в сутки и какой пик. Отсюда выбор: пакетная обработка или потоковое распознавание.
• Правила работы с данными — где хранить аудио и текст, сколько держать, кто имеет доступ, нужно ли обезличивание перед обучением.
• Точки интеграции — куда отдавать результат: система учёта, хранилище, шина событий — и в каком формате его ждут.

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

Опишите задачу — вернёмся с оценкой и планом.