STT с шумоподавлением: WER < 10% даже при SNR 5 дБ

Почему noise robust STT ломается на реальном шуме

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

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

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

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

Что даёт устойчивое распознавание: измеримый эффект

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

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

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

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

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

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

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

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

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

Этапы внедрения шумоустойчивого распознавания

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

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

Что передаём заказчику: конфигурации и регламенты

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

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

Комплект разбираем на передаче вместе с вашими инженерами и фиксируем, кто за что отвечает дальше.

Кейс: складской контакт-центр — ошибки до и после

До: расшифровку перепроверяли вручную

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

Что изменили в конвейере

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

После: что показали замеры

На шумных каналах доля ошибок распознавания снизилась с 22% до 8-9%, на номерах накладных — до 3%, там, где раньше начинался ручной переспрос. Готовый текст теперь идёт потоком параллельно разговору, а не через несколько минут после звонка. Объём ручной правки упал примерно в пять раз: оператор просматривает только помеченные фрагменты, а не каждый диалог целиком, — и это освободило смену под обработку обращений, а не под вычитку.

Что делать, если уже развёрнут другой движок распознавания

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

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

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

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

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

Технические сомнения: задержка, нагрузка, качество

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

Что будет при пиковой нагрузке на сервис?

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

Как обрабатываются записи с перекрытием речи?

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

Реально ли дообучение на нашей терминологии?

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

Обсудим задачу: что уточнить перед стартом проекта

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

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

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