Как выбрать speech-to-text для продукта: от обработки аудио до STT API

Whisper показывает высокое качество распознавания, но не всегда подходит для real-time сценариев. Streaming-модели позволяют получать текст практически без задержек, однако требуют более сложной инфраструктуры. Готовые STT API снимают часть инфраструктурных задач, но взамен добавляют собственные ограничения по стоимости, задержкам и возможностям интеграции.

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

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

В статье разберём, как устроены современные speech-to-text системы, какие архитектуры используют для распознавания речи, чем отличаются Whisper, FastConformer и MMS, а также когда имеет смысл использовать собственную инфраструктуру, а когда проще работать через готовые API.

Как устроен speech-to-text pipeline

Когда речь заходит о speech-to-text, чаще всего обсуждают только модели распознавания речи. На деле качество системы зависит от всей цепочки обработки аудио.

В большинстве production-сценариев используется pipeline из нескольких независимых компонентов:
Wake Word → VAD → preprocessing → ASR → post-processing → NLU → dialogue manager → TTS

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

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

Что происходит до распознавания речи

До того как аудио попадёт в speech-to-text модель, системе необходимо определить момент начала взаимодействия, выделить речь из общего аудиопотока и подготовить запись для дальнейшей обработки.

Для этого используют wake word detection, VAD и слой предобработки аудио. Wake word detection отвечает за активацию системы по ключевой фразе и позволяет не запускать полноценную обработку аудио постоянно.

После активации начинает работать VAD (Voice Activity Detection). Его задача — выделять только те участки аудио, где действительно присутствует речь.

Ошибки на этом этапе быстро отражаются на всей дальнейшей обработке. Если VAD слишком агрессивно обрезает аудио, speech-to-text модель начинает получать неполные фразы и теряет контекст. Если сегментация работает слишком мягко, в ASR попадают тишина, шум и посторонние звуки, что увеличивает объём обработки и задержку.

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

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

Какие подходы используют для распознавания речи

После подготовки аудио система переходит к преобразованию речи в текст.

Здесь и приходится выбирать между разными speech-to-text архитектурами. Универсального решения нет. Модели, которые хорошо подходят для транскрибации встреч или длинных записей, не всегда оказываются лучшим выбором для голосовых интерфейсов или real-time сценариев.

Выбор зависит от того, что важнее для системы: качество распознавания, скорость отклика или возможность локального развёртывания.

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

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

Такие модели часто используют для:

• транскрибации встреч;
• аналитики звонков;
• обработки длинных записей;
• серверных сценариев, где задержка не критична.

Кроме того, encoder-decoder архитектуры хорошо подходят для адаптации под специализированные данные.
Минус такого подхода — более высокие требования к вычислительным ресурсам и задержке обработки. Из-за этого такие модели редко становятся основой real-time систем.

Когда критичен real-time

Если система должна реагировать во время разговора, требования меняются. Пользователь не может ждать завершения всей записи, прежде чем получить результат. Поэтому для потоковых сценариев часто используют RNNT и Conformer-модели, например RNNT и Conformer-модели.

В отличие от Whisper они работают с аудио постепенно и выдают текст по мере поступления данных. Это позволяет заметно снизить задержку.
Такие архитектуры используют в голосовых интерфейсах, live-диалогах, call-center системах и голосовом управлении.

У этого подхода есть и обратная сторона. Модель получает меньше контекста, поэтому удерживать качество распознавания сложнее, чем в offline-сценариях.

Кроме того, вокруг streaming-ASR обычно появляется дополнительная инфраструктура: сегментация аудио, отдельные модели пунктуации и механизмы обработки потоков.

В итоге приходится искать баланс между качеством распознавания и скоростью отклика.

Когда важны локальное развёртывание и мультиязычность

Отдельный класс решений ориентирован на сценарии с ограниченными вычислительными ресурсами или большим количеством поддерживаемых языков. Для таких задач используют CTC-модели, wav2vec-подобные архитектуры и решения вроде MMS.

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

MMS (Massively Multilingual Speech) создавалась как мультиязычная модель и поддерживает большое количество языков, включая low-resource локали, для которых доступно ограниченное количество обучающих данных.

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

После распознавания речи текст часто проходит дополнительную обработку.

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

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

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

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

Для решения этой проблемы используют словари терминов, contextual prompting, шаблонные правила и дополнительные механизмы коррекции после распознавания.

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

По этой причине качество speech-to-text оценивают не только по метрикам распознавания, но и по тому, насколько полученный текст пригоден для следующих этапов обработки.

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

Обработка пользовательского запроса

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

Для этого используют NLU-компоненты или LLM-модели, которые извлекают параметры запроса, работают с контекстом и связывают голосовой интерфейс с бизнес-логикой приложения.

В зависимости от сценария архитектура может быть полностью построена вокруг LLM или использовать более специализированные компоненты: intent-классификаторы, NER-модели и механизмы извлечения данных. На этом этапе voice pipeline выходит за рамки распознавания речи и начинает работать с прикладной логикой системы.

Генерация ответа

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

Хотя TTS часто воспринимается как завершающий технический слой, именно он напрямую влияет на пользовательский опыт. Даже качественная speech-to-text система может восприниматься медленной, если генерация ответа занимает слишком много времени.

На этом цикл обработки речи заканчивается: от аудио на входе до формирования голосового ответа пользователю.

Собственная инфраструктура или STT API

До этого момента мы рассматривали speech-to-text как набор компонентов: обработку аудио, ASR-модели, постобработку текста и работу с контекстом. Однако при построении production-системы довольно быстро возникает ещё один вопрос: кто будет запускать и обслуживать эти модели.
Обычно здесь выбирают между двумя подходами:

• собственной инфраструктурой;
• готовыми STT API.

Оба варианта позволяют получить качественную транскрибацию, но отличаются требованиями к инфраструктуре, стоимостью эксплуатации и уровнем контроля над системой. На этапе прототипирования ответ часто кажется очевидным.

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

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

Приходится учитывать сразу несколько факторов:

• качество транскрибации;
• задержку обработки;
• стоимость;
• требования к безопасности данных;
• ограничения по размеру файлов;
• возможности кастомизации;
• дополнительные функции вроде диаризации и post-processing.

Во многих случаях инфраструктурные ограничения оказываются важнее различий между самими моделями.

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

На что смотреть при выборе STT API

Если сравнивать современные STT API, качество распознавания оказывается лишь одним из критериев.

Не меньшее значение имеют:

• скорость обработки;
• стабильность работы;
• ограничения платформы;
• дополнительные возможности;
• удобство интеграции.

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

Популярные STT API

За последние несколько лет количество готовых speech-to-text сервисов заметно выросло. Большинство из них позволяют быстро получить транскрибацию без необходимости самостоятельно разворачивать модели и поддерживать инфраструктуру.

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

Fireworks

Fireworks позволяет быстро использовать современные speech-to-text модели без собственного развёртывания. Отдельного внимания заслуживает Whisper v3 Turbo, который сочетает хорошее качество распознавания с высокой скоростью обработки.

Такой подход подходит для проектов, где важно быстро запустить speech-to-text без поддержки собственного ML-стека. При этом часть контроля над обработкой аудио остаётся на стороне провайдера, поэтому особенности сегментации и обработки запросов стоит учитывать заранее.

OpenAI Whisper API

Whisper API остаётся одним из самых популярных способов использовать Whisper без собственного развертывания. Его основные преимущества — предсказуемое качество распознавания и простая интеграция. Для многих команд этого достаточно, чтобы быстро внедрить speech-to-text без дополнительной инфраструктуры.

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

AssemblyAI

AssemblyAI предлагает не только транскрибацию, но и дополнительные инструменты для работы с аудио. Помимо распознавания речи сервис предоставляет диаризацию, аналитику разговоров и различные механизмы обработки текста. Поэтому его часто используют не только как STT API, но и как часть более широкого voice pipeline.

Другие решения

Помимо перечисленных сервисов существует большое количество альтернативных решений: DeepInfra, Nexara, Shopot, SpeechKit и другие платформы.

Большинство из них предоставляют доступ к схожим speech-to-text моделям, но отличаются стоимостью, набором функций, ограничениями инфраструктуры и особенностями интеграции.

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

Выводы

За последние несколько лет выбор speech-to-text решений стал значительно шире. Сегодня можно использовать открытые модели, строить real-time системы на базе streaming-ASR или полностью опираться на готовые облачные сервисы.

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

Whisper, FastConformer, MMS и современные STT API решают разные задачи и требуют разных компромиссов. Универсального решения здесь нет, и именно поэтому проектирование speech-to-text систем остаётся отдельной инженерной задачей.