Решение задач обработки речи в реальном времени

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

Как появилась идея и к чему стремился проект

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

Зачем это нужно и где применяется

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

Аудио как новый интерфейс взаимодействия

Если посмотреть на эволюцию телеком-платформ, можно увидеть постепенное расширение интерфейсов. Сначала появились CDR, затем события в реальном времени через AMI, позже — постфактум-анализ записей разговоров. Сейчас логичным следующим шагом становится работа с медиапотоками онлайн.
Аудио, а в перспективе и видео, всё чаще рассматриваются как полноценный API. Это не просто звук, а источник данных для аналитики, машинного обучения и принятия решений в реальном времени. В этом контексте Asterisk всё больше воспринимается не только как PBX, но и как медиасервер, от которого ожидают более удобных и универсальных способов доступа к потокам.

Основная задача: доступ к медиапотоку разговора

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

Чтобы это стало возможным, система должна:

• понимать, когда начинается и заканчивается разговор;
• получать доступ к аудиопотоку, желательно отдельно для каждого участника;
• знать, к какому вызову относится получаемый звук и в каком направлении он передаётся;
• по возможности уметь подключаться к Early Media.

Способы подключения к аудио в Asterisk и других системах

В Asterisk существует несколько механизмов работы с медиапотоками. Среди них — audiohooks, JACK-приложения, а также ChanSpy. Последний представляет особый интерес, так как позволяет подключаться к разговору и получать раздельные потоки для каждого участника.
Это принципиально важно для распознавания речи. Смешанный аудиопоток, в котором оба собеседника говорят одновременно, резко ухудшает качество распознавания. Возможность работать с каждым говорящим отдельно значительно повышает точность и открывает путь к более сложному анализу диалога.
Определить момент начала разговора можно либо через логику dialplan, либо через события AMI. В собственных решениях удобнее всего оказалось использовать AMI, особенно если приложение уже построено вокруг этого интерфейса. Для этих целей был создан open source-инструмент, позволяющий из Python подписываться на события и привязывать к ним пользовательскую логику.

Альтернативные подходы и другие платформы

В FreeSWITCH существует команда Unicast, позволяющая перенаправить RTP-поток конкретного разговора на указанный хост и порт. Изначально эта возможность создавалась для работы с факсами, но по своей сути она идеально подходит и для задач анализа речи.
Существуют и стандартные протоколы, такие как SIPREC, предназначенные для записи разговоров на внешние системы. При наличии соответствующего сервера эти потоки можно использовать не для записи, а для онлайн-распознавания.
MRCP и библиотека UniMRCP выглядят перспективно и поддерживают различные облачные движки, однако они ориентированы на сценарии, где управление возвращается в dialplan после завершения распознавания. Для непрерывного анализа разговора от начала до конца этот подход оказался неподходящим.

Облачные АТС и ограничения доступа к данным

Отдельного внимания заслуживают облачные АТС. Многие из них позволяют подключаться к разговору в режиме супервизора, и в ряде случаев этого достаточно для распознавания речи в реальном времени. Однако чаще всего доступен только смешанный поток, а API для отслеживания статусов разговоров либо отсутствуют, либо сильно ограничены.
Для операторов онлайн-АТС это становится точкой роста. Клиенты всё чаще ожидают программного доступа к разговорам, событий в реальном времени и возможности получать аудио в максимальном качестве, а не только в виде сжатых записей.

Реализованное решение

В рамках проекта было принято решение писать собственное приложение. Это оказалось проще и гибче, чем адаптация готовых протоколов. Приложение имело простой REST API для уведомлений о начале и завершении вызова и сообщало, куда необходимо направлять RTP-поток.
Asterisk передавал звук напрямую в это приложение, которое, в свою очередь, отправляло аудио в облачный сервис распознавания речи. При использовании Google задержка получения предварительной транскрипции составляла порядка 1–1,5 секунд. Аудио передавалось чанками по 100 миллисекунд.
Сервисы распознавания обычно возвращают два типа результатов: предварительные и финальные. Предварительные появляются быстрее и часто оказываются достаточно точными для работы в реальном времени.

Облачные сервисы распознавания и их особенности

На практике для потокового распознавания доступны Google Speech-to-Text, IBM Watson и Microsoft Bing. У каждого сервиса есть свои особенности, особенно в части тарификации. Многие из них изначально ориентированы на короткие голосовые команды и плохо подходят для длинных разговоров, округляя длительность запросов в большую сторону.
Наиболее предсказуемой оказалась модель тарификации IBM Watson, однако у сервиса отсутствует поддержка русского языка. У других решений стоимость при длительных диалогах может оказаться неожиданно высокой.

Зачем нужен промежуточный слой обработки аудио

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

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

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