Перейти к содержанию

Потоковое распознавание речи

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

Обновление от 9 сентября 2026 года

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

Scribe v2 Realtime — 30 сентября 2026 года

Добавлена ElevenLabs-Scribe-v2-Realtime для живого PCM, потоковой обработки файлов и gRPC STT v3. Модель возвращает промежуточный текст и окончательные фразы через ElevenLabs, без дополнительного файлового распознавания.

Поддерживаемые языки

Основные языки локальных потоковых моделей и Playground:

Язык Код языка Поток PCM: WebSocket / gRPC Длинный файл в браузере
Русский ru-RU да да
Английский en-US да да
Казахский kk-KZ да да
Кыргызский ky-KG да да
Узбекский uz-UZ да да
Таджикский tg-TJ да да

ElevenLabs-Scribe-v2-Realtime через API принимает курируемый набор 75 языков, включая все языки таблицы. ElevenLabs заявляет 90+ языков для Realtime; сервис использует свой ограниченный набор. Опубликованные оценки качества файловой Scribe v2 не являются оценками Realtime.

Язык задаётся в начале сессии и сохраняется до её завершения. Для другого языка откройте новую сессию.

В Playground выберите источник «Живые субтитры», укажите «Язык записи» и в поле «Модель распознавания» выберите локальный поток для языка или «ElevenLabs Scribe v2 Realtime». Нажмите «Открыть», затем в окне субтитров — «Начать» и разрешите доступ к микрофону. Тариф показан до запуска. Сеанс не сохраняется, а текст можно скопировать или скачать. Если включён «Приватный режим», выбор внешней модели требует согласия через флажок «Разрешить внешнюю обработку».

В локальном кыргызском потоке («Кыргызча») предварительный текст появляется по мере речи, а окончательный текст каждой фразы уточняется автоматически. В локальном таджикском потоке («Тоҷикӣ») после паузы приходит окончательный результат без автоматической пунктуации и нормализации текста. Пословные таймкоды для этих языков не предоставляются.

Русский поток по умолчанию

В живом PCM WebSocket и gRPC для русского по умолчанию используется SpeechExpert-STT-RU: T-One выдаёт предварительный текст во время передачи, а Riva распознаёт всю принятую запись и возвращает окончательный текст после EOF. Каждый partial заменяет весь предварительный транскрипт сессии. Дочитайте ответы после завершения ввода: итог может отличаться от предварительного текста. Если Riva не вернул текст, окончательным результатом становится последний preview.

Предварительный текст гибрида декодируется без языковой модели KenLM и отправляется при каждом изменении, без дополнительного ограничения частоты. Акустическая модель обрабатывает аудио шагами по 300 мс; более мелкие сетевые пакеты не уменьшают этот шаг. Передавайте PCM порциями примерно по 100 мс, без накопления нескольких секунд на клиенте.

Для прямого пофразового T-One без распознавания всей записи после EOF явно укажите SpeechExpert-STT-RU-stream. В этом режиме partial относится к текущей фразе, а её final приходит по мере обработки. Это также русский поток отдельного маршрута длинных файлов /api/stt/v1/file-stream/ws; его настройка не меняется при смене модели по умолчанию для живого PCM.

Выбор протокола

Протокол Подходит для Аудио и результаты
WebSocket: PCM Микрофон, живые субтитры, заранее декодированная запись Mono PCM16, 16 кГц; результаты в JSON
WebSocket: длинный файл Загрузка готовой длинной записи, в том числе из браузера Исходный файл частями; текст и прогресс в JSON
gRPC Телефония, серверные интеграции и длинные записи в PCM Mono или многоканальный PCM; результаты в protobuf с номером канала

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

Восстановление пунктуации сервисом по умолчанию выключено. Для живого PCM WebSocket передайте "enable_automatic_punctuation": true в первом JSON; для gRPC установите recognition_model.text_normalization.literature_text = true в первых session_options. Восстановление применяется к финальному тексту, если оно поддерживается выбранной моделью; её собственная пунктуация сохраняется.

Потоковая диаризация

В существующих gRPC и WebSocket API можно запросить определение дикторов Nemotron одновременно с распознаванием. В gRPC включите speaker_labeling.speaker_labeling = SPEAKER_LABELING_ENABLED, в начальном JSON WebSocket — "diarization": true. Подробные примеры: gRPC и WebSocket. Настройка доступна через API; переключателя в Playground пока нет.

Для gRPC и живого PCM WebSocket нужен mono-вход. Файловый WebSocket сам сводит запись в mono и поддерживает диаризацию при совпадении final_model и model; отдельное уточнение текста в этой комбинации не применяется. Диаризация включается на всю сессию и учитывается в стоимости обработки.

Промежуточный текст появляется по мере распознавания без ID диктора. Окончательный фрагмент ждёт, пока диаризация зафиксирует соответствующий участок аудио. Стандартная настройка модели использует окно 1,04 с звука и ещё 16 мс буферизации для извлечения признаков; это не гарантия задержки ответа — к ней добавляются вычисления, сеть и ожидание конца фразы в ASR.

ID диктора — строка от "0" до "7", постоянная в пределах одной сессии. Между подключениями номера не идентифицируют человека. В gRPC номер находится в response.channel_tag, в WebSocket — в speaker_id и channel_tag. Если диктор не определён, в gRPC метка пуста, а в JSON поля отсутствуют.

При доступных пословных таймкодах русского и английского ASR или Scribe Realtime фраза может разделиться на несколько окончательных фрагментов при смене диктора. Когда есть только границы фразы, как в локальных казахском, кыргызском, узбекском и таджикском потоках, выбирается преобладающий диктор всей фразы. Если слова и окончательный текст не согласованы, применяется тот же вариант для всей фразы. Одновременная речь нескольких людей не гарантирует раздельную транскрипцию каждого голоса.

gRPC сохраняет стандартные сообщения SpeechKit v3. При этом онлайн-диаризация в REAL_TIME — расширение: Yandex документирует определение дикторов для mono в FULL_DATA, с максимум двумя дикторами. Наш FULL_DATA подавляет partial и выдаёт сохранённые финалы только после успешного EOF всей обработки. Аудио обрабатывается последовательно; дополнительного офлайн-уточнения нет.

Длинные аудиозаписи

Потоковый режим подходит для длинных, в том числе многочасовых записей на русском, английском, казахском, кыргызском, узбекском и таджикском языках. Аудио обрабатывается последовательно: текст завершённых фраз появляется до окончания всей записи. В Playground выберите источник «Файл», укажите «Язык записи» и включите «Текст по мере обработки». В поле «Модель распознавания» можно выбрать «ElevenLabs Scribe v2 Realtime»; она распознаёт запись последовательно без отдельного уточнения фраз. Загрузите запись и нажмите «Распознавать потоково». Прогресс загрузки и длительность обработанного аудио отображаются отдельно. Оставьте вкладку открытой до завершения обработки.

Для интеграции выберите один из способов:

  • Передайте исходный файл через /api/stt/v1/file-stream/ws. Этот режим принимает контейнеры, например WAV или MP3, и сводит каналы в mono. Размер одного файла — до 10 ГиБ. После ready передавайте бинарные части не больше max_chunk_bytes, одновременно принимая ответы.
  • Декодируйте запись в PCM и передавайте её через WebSocket или gRPC. Для раздельного распознавания каналов используйте gRPC.

Язык задаётся для всей записи. Для английского, казахского, узбекского и таджикского в режиме длинного файла окончательные фразы возвращаются из потока без отдельного уточнения текста. Для русского можно дополнительно выбрать уточнение окончательных фраз. На кыргызском локальный поток уточняет итог каждой фразы автоматически. Для Scribe Realtime на любом языке используются только результаты Realtime. Разделение участников можно включить через API, как описано в разделе о диаризации; в браузерном интерфейсе этого переключателя пока нет. Автоматическая обработка текста недоступна; отчёт можно создать по готовому результату. Дополнительные настройки обычного файлового распознавания находятся в разделе «Параметры обработки» и не применяются к потоку. У локальных казахского, кыргызского, узбекского и таджикского потоков есть границы аудиофрагментов; пословные таймкоды не предоставляются.

Чтение результатов должно идти одновременно с отправкой файла. После последней части отправьте EOF и дождитесь completed: окончание загрузки ещё не означает окончание распознавания. Сохраняйте полученные final по мере поступления. Закрытие соединения останавливает обработку; автоматического продолжения с места разрыва нет. Это сессия с активным соединением, а не фоновая задача. Списание идёт по длительности обработанного аудио и сохраняется при отмене; поле длительности, переданное клиентом, используется для прогресса.

ElevenLabs Scribe в потоковом режиме

Проверено по документации ElevenLabs 30 сентября 2026 года:

Модель ElevenLabs ID у провайдера Способ обработки
Scribe v2 scribe_v2 Готовый файл или завершённый аудиофрагмент
Scribe v2 Medical scribe_v2_medical Готовый файл или завершённый аудиофрагмент; специализация на медицинской речи
Scribe v2 Realtime scribe_v2_realtime Живой поток через WebSocket провайдера

Scribe v2 Medical поддерживает те же 90+ языков, функции и тариф ElevenLabs, что Scribe v2. В список входят все шесть языков сервиса: русский, английский, казахский, кыргызский, узбекский и таджикский. Опубликованные измерения улучшения медицинского распознавания относятся к английскому, французскому и немецкому; отдельного медицинского результата для русского и языков Центральной Азии провайдер не приводит. Источники: описание моделей, поддерживаемые языки, публикация о Medical.

Уточнение русского длинного файла

В /api/stt/v1/file-stream/ws русский поток может использовать Scribe как final_model: предварительный текст выдаёт SpeechExpert-STT-RU-stream, а завершённые фразы отправляются на файловое распознавание ElevenLabs. Пример начального сообщения с обычной Scribe v2:

{"type":"start","language":"ru-RU","model":"SpeechExpert-STT-RU-stream","final_model":"ElevenLabs-Scribe-v2","diarization":false}

Для медицинской речи используйте тот же режим с Medical:

{"type":"start","language":"ru-RU","model":"SpeechExpert-STT-RU-stream","final_model":"ElevenLabs-Scribe-v2-Medical","diarization":false}

Это уточнение по фразам: аудио каждой завершённой фразы передаётся внешнему провайдеру, а final приходит после ответа на файловый запрос. Пословные таймкоды уточнения переводятся на временную шкалу исходной записи. Если уточнение не удалось, сервис возвращает текст потока с refinement_status: "fallback" и причиной в fallback_reason. Выбранная модель влияет на тариф; отсутствие ответа уточнения не отменяет учёт обработанного аудио.

Отдельный final_model доступен только для русского и при выключенной потоковой диаризации. В других языках и при включённой диаризации final_model должен совпадать с model. В живом PCM WebSocket и gRPC файловые модели Scribe не принимаются как model.

Scribe v2 Realtime

Используйте публичный ID ElevenLabs-Scribe-v2-Realtime; короткий ID scribe_v2_realtime также принимается. В JSON живого WebSocket:

{"language":"ru-RU","model":"ElevenLabs-Scribe-v2-Realtime"}

Для исходного файла через /api/stt/v1/file-stream/ws:

{"type":"start","language":"ru-RU","model":"ElevenLabs-Scribe-v2-Realtime","diarization":false}

final_model пропустите или укажите тот же ID. Окончательные фразы возвращает Realtime; файловые Scribe v2 и Medical дополнительно не вызываются. В gRPC задайте recognition_model.model и язык в language_restriction, как в примере STT v3. Для загруженного целиком файла доступен также OpenAI-совместимый SSE с stream=true. Обычные файловые HTTP v1/v3 и stream=false эту модель не принимают.

Сервер отправляет mono PCM16 16 кГц в WebSocket ElevenLabs. Промежуточные гипотезы выдаются по мере распознавания; VAD провайдера завершает фразы по паузам. Окончательный текст ожидает отдельного события пословных таймкодов, затем выдаётся один final с временной разметкой исходной записи. Если провайдер не прислал таймкоды вовремя, границы фразы оцениваются по переданному аудио; пословная разметка в таком финале отсутствует.

После EOF сервер отправляет провайдеру commit оставшегося звука и дочитывает ответы. При стандартной настройке завершение может занять до 15 секунд после последнего аудиофрагмента; продолжайте читать до completed в файловом WebSocket, закрытия PCM WebSocket сервером с кодом 1000 или CLOSED в gRPC. Ошибки провайдера, квоты и разрыв соединения завершают сеанс; автоматического переподключения и повторной отправки аудио нет. Быстро отправленный файл передаётся провайдеру с ограничением скорости, близким к длительности аудио: обработка часовой записи занимает около часа плюс сетевые и вычислительные задержки.

У Realtime нет нативной диаризации. Необязательная потоковая диаризация Nemotron доступна через API для mono и добавляет свой тариф и задержку. Тариф Realtime в сервисе — 1750 кредитов за час до округления и дополнительной стоимости диаризации.

Аудио этого режима передаётся внешнему сервису ElevenLabs. На сервере нужен ELEVENLABS_API_KEY; webhook для Realtime не требуется. Протокол провайдера: Realtime API, серверный поток и события.

В начальном JSON обоих WebSocket-маршрутов privacy_mode=true блокирует внешнее распознавание без external_ai_consent=true. Эти поля и пример согласия описаны в справочнике WebSocket. Текст Realtime возвращается без отдельного уточнения, восстановления пунктуации и нормализации сервиса, чтобы сохранить соответствие таймкодам слов.

Настройки сервера:

Переменная окружения По умолчанию Назначение
ELEVENLABS_SCRIBE_REALTIME_CONNECT_TIMEOUT 15 Ожидание подключения, секунды
ELEVENLABS_SCRIBE_REALTIME_TIMEOUT 180 Ожидание событий провайдера, секунды
ELEVENLABS_SCRIBE_REALTIME_FINAL_TIMEOUT 15 Ожидание таймкодов и дочитывание после EOF, секунды
ELEVENLABS_SCRIBE_REALTIME_VAD_SILENCE_THRESHOLD_SECS 1.5 Пауза для завершения фразы VAD провайдера, секунды

Промежуточный и окончательный текст

В русском SpeechExpert-STT-RU partial заменяет весь предварительный текст сессии, а final после EOF заменяет его окончательным транскриптом. В пофразовых режимах, включая SpeechExpert-STT-RU-stream, partial — текущая гипотеза для незавершённой фразы. Каждый следующий partial заменяет предыдущий текст этой фразы: не добавляйте все гипотезы подряд в транскрипт.

В пофразовом режиме final — окончательный результат отдельной фразы. Сохраните его в транскрипте, а новые partial показывайте как следующую фразу. Финальный текст может отличаться от последнего промежуточного результата.

В WebSocket эти состояния обозначены полем is_final: false для partial, true для final; для длинного файла также передаётся type: "partial" или type: "final". В gRPC используются отдельные события partial и final. В локальном кыргызском потоке partial следующей фразы может прийти раньше final предыдущей. В WebSocket, включая длинный файл, храните текущие гипотезы по phrase_id и очищайте только завершённую фразу. Финалы сохраняют порядок. В gRPC без диаризации ключ фразы — пара channel_tag и Alternative.start_time_ms; самостоятельного поля phrase_id в protobuf нет. Для остальных режимов без идентификатора используйте текущую гипотезу каждого канала. При диаризации метки дикторов появляются только в финалах, и одна фраза может дать несколько финальных фрагментов. Сохраняйте каждый фрагмент; в gRPC сопоставляйте его с предварительной гипотезой по диапазону времени, поскольку метка диктора у partial ещё отсутствует.

Завершение записи

После последнего аудиофрагмента передайте EOF согласно выбранному протоколу и продолжайте принимать результаты: в SpeechExpert-STT-RU только после EOF приходит окончательный текст всей сессии. В пофразовых режимах оставшийся final может прийти после прекращения записи. Появление final во время речи означает завершение фразы, а не всей сессии.

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

Для готового аудиофайла доступны синхронный и асинхронный методы. Выдача ответа по SSE после загрузки целого файла описана отдельно в OpenAI-совместимом API.