Разработка STT: почему пилот не доживает до эксплуатации
Пилот на чистых записях из переговорной даёт точность распознавания речи выше 90%, а через месяц на реальном трафике она проседает до 65-70%. Шумные каналы, узкополосный телефонный тракт, эхо и перекрытие речи двух говорящих ломают акустику сильнее, чем любой акцент в студийной записи. Чинить это фильтрами постфактум поздно — решение принимается на этапе подготовки данных и выбора модели.
Доменная лексика добивает результат точечно. Артикулы, названия препаратов, аббревиатуры подразделений и фамилии базовая модель уверенно заменяет на похожие по звучанию слова, и такой текст уходит дальше по процессу как валидный. Закрывается это не «дообучением на всём подряд», а словарём произношений, языковой моделью на профильном корпусе и разметкой именно тех сущностей, которые нужны бизнесу.
Задержка на потоке — отдельная точка отказа. Если движок ждёт окончания файла и только потом отдаёт текст, диалог с оператором распадается на паузы; инженеры режут поток на окна и платят за это ростом ошибок на стыках. Поэтому разбор в реальном времени и обработка архива проектируются как два разных режима с разными требованиями к качеству и скорости.
И последнее — повторная обработка архива. Каждая новая версия модели обесценивает ранее расшифрованное: чтобы поднять качество, накопленные часы приходится перегонять заново, а это нагрузка на вычислительные ресурсы и сроки. Планировать это заранее — значит версионировать модели, раздельно хранить исходное аудио и признаки и понимать, какие записи действительно нужно перерабатывать. Разбираем, как эти точки закрываются на этапе проектирования.
Что даёт отлаженный контур распознавания речи
Качество распознавания нельзя оценивать по демо-записи: на реальных звонках появляются шум, перекрывающаяся речь и отраслевые термины, которых нет в общем словаре. Отлаженный контур тем и отличается, что метрики снимаются на том же аудио, с которым работает заказчик, а не на студийном корпусе.
Второй слой — поведение под нагрузкой: сколько ждёт первый фрагмент, что происходит при обрыве связи, как разделяются голоса участников. Модели мы дообучаем под предметную область, включая открытые вроде Whisper, и отдаём результат потоком, а не пачкой после загрузки файла.
| Показатель | Без настройки контура | После настройки |
|---|---|---|
| Доля ошибок на реальных записях | 15–25% на разговорных звонках с шумом и акцентом | 4–8% на том же корпусе, термины из словаря заказчика узнаются стабильно |
| Время отклика | запись копится и расшифровывается целиком после загрузки | первый фрагмент приходит в пределах секунды, остальное — по мере речи |
| Ручная проверка расшифровок | сплошная вычитка всех записей | выборочная сверка только фрагментов с низкой уверенностью модели |
| Устойчивость к обрывам | потеря сессии, запись приходится начинать заново | контрольные точки и дозагрузка: сессия продолжается с последнего подтверждённого фрагмента |
Суммарно меняется не одна цифра, а ушедший класс отказов: расшифровка перестаёт быть задачей «на утро» и не рассыпается при сбое связи. Оператор смотрит не весь текст, а помеченные места — отсюда и кратное сокращение объёма ручной работы.
Разработка STT: варианты архитектуры и их ограничения
Выбор между арендованным сервисом, собственным контуром и гибридной схемой — это не спор о точности распознавания. На одной и той же акустике подходы дают близкие цифры, а расходятся они по трём осям: где физически лежит аудио, какой поток надо держать в час пик и кто отвечает за качество на доменной лексике — названиях препаратов, артикулах, внутренних аббревиатурах.
Главная развилка — ограничения по данным. Если в записи звучат клиенты, а вместе с ними медицинские или юридические детали, передача потока на сторону требует обезличивания на лету, и часто именно это решает в пользу своего контура. Обратный случай — редкий язык, которого нет в собственной модели: здесь аренда закрывает задачу сразу, без месяцев разметки.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Арендованный сервис | Быстрый старт, много языков, пиковые нагрузки без своих мощностей | Аудио уходит наружу, расходы растут линейно с минутами, тонкая настройка на домен недоступна |
| Собственный контур | Требования к защите данных, стабильный объём, закрытая сеть | Долгий вывод в продукт, свои серверы с ускорителями, качество зависит от объёма размеченных записей |
| Гибридная схема | Чувствительное обрабатывается локально, редкие языки и тяжёлые задачи уходят в аренду | Две подсистемы в мониторинге, сложнее маршрутизация и версионирование моделей |
Практический критерий выбора — не средняя точность, а доля ошибок на самых дорогих сценариях: номерах заказов, суммах, адресах. Мы собираем тестовый набор из реальных записей заказчика, прогоняем через все три варианта и показываем, где именно расходятся результаты.
Порядок работ: от аудита записей до передачи контура
Начинать с выбора движка распознавания — типовая ошибка: качество определяется не моделью, а состоянием записей и тем, насколько контур учитывает условия домена. Поэтому этапы идут последовательно, и каждый опирается на артефакты предыдущего.
- Аудит записей. Берём выборку из реальных каналов — звонки, встречи, диктовка — и размечаем проблемы: шум, эхо, наложение реплик, узкополосные линии, спонтанная речь, доля доменных терминов. На выходе карта условий и понимание, какие классы записей вообще подлежат автоматизации.
- Схема контура. Фиксируем поток: источник, предобработка (подавление шума, детекция речи, разделение спикеров), распознавание, постобработка (пунктуация, числа, словарь терминов), выдача в целевую систему. Отдельно описываем точки отказа и поведение при недоступности внешних узлов.
- Настройка под домен. Собираем словари терминов, аббревиатур и названий, настраиваем языковую модель на доменную лексику, при необходимости дообучаем акустическую часть на размеченных фрагментах из аудита.
- Проверка на отложенной выборке. Качество подтверждаем на корпусе, который не участвовал в настройке, и в разбивке по подгруппам: канал связи, уровень шума, темп речи, плотность терминов. Средняя цифра по всему корпусу скрывает провалы на отдельных группах — а в работе важны именно они.
- Приёмка по метрикам. Фиксируем пороги по подгруппам, а не общий процент: где автоматизация отдаёт результат сразу, где нужен второй проход или отметка «на проверку оператору».
- Передача контура и обучение команды. Передаём схему, регламент переобучения при смене лексики, панель метрик и порядок разбора инцидентов, проводим обучение инженеров и операторов.
На выходе заказчик получает работающий контур, документацию и команду, которая может развивать его без нас. Опишите задачу — вернёмся с оценкой и планом по этапам.
Комплект поставки: конфигурации, схемы и регламенты
Инженерный результат проекта — это не только работающий сервис распознавания речи, но и комплект артефактов, по которому его можно развернуть, проверить и развивать силами своей команды. Всё передаём в репозитории вместе с инструкцией по развёртыванию контура на чистой инфраструктуре.
- Конфигурация контура — декларативное описание сервисов распознавания, очередей, балансировки и правил автомасштабирования: контур поднимается из конфигурации, а не собирается руками.
- Схема потоков данных — путь аудио от приёма до выдачи текста: точки буферизации, места повторной обработки, шаги, на которых запись удаляется.
- Политики доступа — роли сервисов, ключи, сетевые ограничения и правила обращения с записями: сроки хранения и маскирование чувствительных полей.
- Модели и профили распознавания — зафиксированные наборы весов, доменные словари и настройки под разные каналы: телефон, микрофон, поток совещания.
- Набор проверок качества — тестовые фрагменты с эталонными расшифровками и метриками: доля ошибок в словах и в именованных сущностях по каждому сценарию.
- Регламент сопровождения — порядок обновления моделей, контроль нагрузки, сигналы мониторинга с порогами и условия отката на предыдущий набор весов.
- Инструкции для команды — как подключить новый канал, пополнить словарь терминов, разобрать инцидент и передать обратную связь по ошибкам.
Кейс: распознавание звонков в контакт-центре до и после
Контакт-центр на несколько десятков операторов обрабатывает тысячи звонков в сутки, и каждую запись нужно превратить в понятную карточку обращения. До перестройки расшифровка шла одним потоком: без разделения каналов, нормализации звука и разметки по ролям. Оператор получал сплошной текст и правил его вручную, а супервизор оценивал качество на слух по десятку записей в неделю.
Что перестроили в контуре
Контур разбили на этапы: приведение звука, выделение речи, распознавание, разметка по ролям, извлечение сущностей. За основу взяли Whisper в актуальной ветке и дообучили на записях заказчика, добавив словарь названий товаров, адресов и типовых формулировок. Распознавание сделали асинхронным: расшифровка приходит к оператору раньше, чем он открывает карточку.
Доля ошибок на ключевых сущностях упала с 28% до 7%. Доля расшифровок, которые оператор принимает без правок, выросла с 59% до 88%, а время обработки обращения сократилось с девяти минут ручного заполнения до полутора минут проверки. Больше половины обращений разбираются автоматически и уходят в отчётность без участия человека.
Побочный эффект — контроль качества: супервизор видит выборку по всем звонкам, а не по десяти в неделю, и спорное обращение разбирается по расшифровке. Модели версионируются, поэтому при падении точности на новом сегменте звонков есть куда откатиться.
Чем потоковая обработка отличается от пакетной
Разница не в модели, а в контракте на выдачу. Потоковая обработка отдаёт промежуточные гипотезы по мере поступления звука и обязана закрыть фразу через доли секунды после паузы; пакетная обработка берёт готовый файл целиком и может позволить себе несколько проходов. Отсюда разные требования к устойчивости: в потоке сбой канала рвёт диалог, в архиве запись просто уходит в конец очереди.
Режим реального времени нужен там, где результат влияет на текущее действие: подсказки оператору, онлайн-контроль качества разговора, субтитры к эфиру, маршрутизация звонка в нужный отдел. Здесь всё подчинено задержке: аудио режется на короткие окна с перекрытием, промежуточные версии текста уточняются по мере накопления контекста, модель считает по сегментам. Точность на коротких фразах ниже, чем при полном проходе, и это осознанный размен, а не дефект.
Пакетная обработка идёт по архиву: записи звонков, встреч, диктофонных заметок. Материал есть целиком, поэтому применяются нормализация уровня, разметка говорящих, повторное распознавание сомнительных участков и словарь терминов предметной области. Задержка измеряется минутами, зато пропускная способность планируется заранее — ночные окна, очередь, повторные прогоны после обновления модели.
Совмещают оба режима на общей основе: один набор моделей, единый слой нормализации текста и словарей, но разные входные адаптеры и разные очереди. Тогда улучшение словаря или модели переносится сразу в оба потока, а результаты можно сверять между собой. Выбор диктует допустимый отклик и доля сценариев, где ответ нужен в момент речи, — всё остальное дешевле и точнее гнать архивами.
Сомнения по качеству, данным и нагрузке
Перед стартом почти всегда всплывают одни и те же пять сомнений: выдержит ли система шумные записи, можно ли дообучать её, не вывозя данные за периметр, реально ли настроить распознавание на своей терминологии, что будет в пиковую нагрузку и как потом без потерь сменить подрядчика. Ни одно из них не закрывается обещаниями — под каждый пункт закладывается конкретный инженерный механизм, который измеряется на ваших записях до начала промышленной эксплуатации.
Ниже — короткие ответы без маркетинга: что делаем, чем измеряем и где проходят границы применимости. Открытые модели уровня Whisper задают базовое качество, но на шумных каналах результат вытягивают подготовка данных и схема выдачи результата, а не сам движок.
Шумные записи: связь, офис, улица — качество просядет?
Аудио приводим к единому формату, режем по спектру и добавляем контролируемый шум при обучении. Доля уверенно распознанных фраз на записях с эхом и фоновым разговором растёт на десятки процентов относительно базовой модели, а сомнительные участки помечаются для выборочной проверки оператором.
Данные нельзя вывозить за пределы контура — это возможно?
Да: разворачиваем весь тракт распознавания на вашей инфраструктуре, обучение идёт на обезличенных выборках внутри периметра. Наружу уходят только агрегированные метрики качества и отчёты об ошибках — без самих записей и расшифровок.
Дообучение на своей терминологии
Собираем словарь названий, аббревиатур и предметных терминов, дообучаем акустическую и языковую части на ваших расшифровках. Это заметно снижает число ошибок на редких словах, а словарь остаётся редактируемым — новые термины добавляются без переобучения всей системы.
Пиковая нагрузка
Потоковые запросы идут с приоритетом, остальные попадают в очередь; вычислительные мощности масштабируются по глубине очереди. Всплеск в разы выше среднего приводит к задержке отложенной обработки, а не к отказам и потерянным записям.
Смена подрядчика — останемся ли мы заложниками?
Конфигурации, словари, адаптеры и разметка — ваши, они лежат в вашем репозитории вместе с чек-листом развёртывания. Переход к другой команде занимает дни: разворачивается тот же контур, воспроизводятся метрики, работа продолжается с накопленными данными.
Обсудим вашу задачу распознавания речи
Оценка проекта по распознаванию речи не собирается из общих слов — она держится на вводных. На первом разговоре уточняем, откуда идёт звук: телефония, микрофоны в зале, записи встреч, сколько каналов нужно вести параллельно. И домен со словарём: имена, артикулы, термины, которые расшифровка обязана писать верно, плюс требования к задержке, если текст нужен по ходу разговора.
Отдельно разбираем шум, перекрытия речи и качество архива записей: по этим вводным видно, где нужно дообучение на ваших данных, а где достаточно настройки языковой модели и правил постобработки.
По итогам разговора присылаем:
- план работ по этапам — от подготовки и разметки записей до проверки на отложенной выборке и вывода в эксплуатацию;
- схему потока: приём аудио, предобработка, распознавание, нормализация текста (пунктуация, числа, имена), отдача результата в вашу систему;
- оценку проекта: состав команды, длительность этапов и то, что требуется с вашей стороны — доступы, записи, согласования;
- целевые метрики: доля ошибок в словах, точность на именах и терминах, допустимая задержка выдачи;
- варианты размещения: в вашем контуре или на выделенных мощностях, с расчётом нагрузки на число одновременных каналов.
Старт проекта — после согласования плана и метрик: фиксируем этапы, точки контроля и порядок приёмки. Давайте обсудим задачу — вернёмся с оценкой и планом работ.
