Набор для пакетной обработки контейнеров для обработки речи

С помощью комплекта пакетной обработки можно дополнять и масштабировать рабочие нагрузки в контейнерах службы Speech. Эта служебная программа с открытым кодом доступна в виде контейнера и позволяет упростить пакетное транскрибирование большого количества звуковых файлов во множестве локальных и облачных конечных точек контейнеров службы "Речь".

Схема, на которой показан пример рабочего процесса для контейнера комплекта пакетной обработки

Контейнер комплекта пакетной обработки доступен бесплатно в GitHub и Docker Hub. Плата взимается только за используемые контейнеры "Речь".

Функция Описание
Пакетное распространение звуковых файлов Автоматически отправляйте большое количество файлов в локальные или облачные конечные точки контейнеров службы "Речь". Файлы могут размещаться на любом томе, совместимом с POSIX, в том числе в сетевых файловых системах.
Интеграция с Speech SDK Передавайте в пакет SDK для службы "Речь" стандартные флаги, включая n лучших гипотез, диаризацию, язык и маскирование ненормативной лексики.
Режимы выполнения Запускайте клиент пакетной обработки по мере необходимости, постоянно в фоновом режиме или создавайте конечные точки HTTP для звуковых файлов.
Отказоустойчивость Автоматически выполняйте повторные попытки и продолжайте транскрибирование, не теряя текущие результаты работы, а также различайте ошибки, для которых повторные попытки целесообразны или нецелесообразны.
Определение доступности конечных точек Если конечная точка становится недоступной, клиент пакетной службы продолжает транскрибирование с помощью других конечных точек контейнера. Когда клиент доступен, он автоматически начинает использовать конечную точку.
Горячая замена конечных точек Добавляйте, удаляйте и изменяйте конечные точки контейнера службы "Речь" во время выполнения без прерывания пакетной обработки. Обновления применяются немедленно.
Ведение журнала в режиме реального времени Журнал предпринятых запросов, меток времени и причин сбоев ведется в режиме реального времени, с файлами журналов Speech SDK для каждого звукового файла.

Безопасно обрабатывайте длительное аудио

Контейнеры речи поддерживают звук с максимальной длительностью 24 часа. Перед отправкой на расшифровку разделите любую аудиозапись длительностью более 24 часов на сегменты. Размер файла не является надежной заменой для длительности, так как кодирование, частота выборки, глубина бита и число каналов определяют количество байтов. Например, 1 ГБ не является универсальным пороговым значением сегментации.

Некоторые звуковые конвейеры используют 32-разрядный счетчик для вычисления длительности. Примерно через 37,3 часа счётчик может переполниться и выдать более короткую, на вид корректную длительность. В этом случае транскрибирование может сообщать об успешном выполнении без предупреждения о усечении результата. Точное место в коде, где происходит это переполнение, неизвестно.

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

При преобразовании исходного звука в RIFF/WAV используйте эти значения, чтобы определить, где произошло переполнение:

  • Преобразованная длина 274,568,704 блока данных WAV в байтах указывает на переполнение во время преобразования или записи файлов.
  • Длина блока данных байтов 4,569,536,000 или файл размером более 4 ГБ с правильным заголовком указывает, что файл был записан правильно и переполнение произошло позже в конвейере обработки. Обратитесь в службу поддержки Microsoft для привлечения инженеров в этом случае.

RF64 и Wave64 (W64) не являются готовым решением для этой проблемы. Каждый путь чтения и проверки длительности в конвейере должен поддерживать выбранный формат. Например, встроенный wave модуль Python отклоняет файлы RF64.

Получение образа контейнера с помощью docker pull

Используйте команду docker pull, чтобы скачать последнюю версию контейнера комплекта пакетной обработки.

Примечание.

В следующем примере загружается общедоступный образ контейнера из Docker Hub. Мы рекомендуем сначала войти в свою учетную запись Docker Hub (docker login), вместо отправки анонимного запроса на pull. Чтобы повысить надежность при использовании общедоступного содержимого, импортируйте образ и управляйте им в частном реестре контейнеров Azure. Узнайте больше о работе с общедоступными образами.

docker pull docker.io/batchkit/speech-batch-kit:latest

Конфигурация конечной точки

Клиент пакетной службы использует файл конфигурации YAML, указывающий локальные конечные точки контейнера. Запишите следующий пример в /mnt/my_nfs/config.yaml, который используется в следующих примерах.

MyContainer1:
  concurrency: 5
  host: 192.168.0.100
  port: 5000
  rtf: 3
MyContainer2:
  concurrency: 5
  host: BatchVM0.corp.redmond.microsoft.com
  port: 5000
  rtf: 2
MyContainer3:
  concurrency: 10
  host: localhost
  port: 6001
  rtf: 4

В этом примере YAML указаны три контейнера службы речи на трех хостах. Первый узел указывается по адресу IPv4, второй узел выполняется на той же виртуальной машине, что и клиент пакетной службы, а третий контейнер указывается dns-именем узла другой виртуальной машины. Значение concurrency определяет максимальное число одновременных операций транскрибирования файлов, которые могут выполняться в одном контейнере. rtf Значение (коэффициент реального времени) является необязательным и может использоваться для настройки производительности.

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

Запуск контейнера пакетной обработки

 

Примечание.

  • В этом примере для файла конфигурации, входных данных, выходных данных и журналов используется один и тот же каталог (/my_nfs). Для этих папок можно использовать сетевые или NFS-подключенные каталоги.
  • При запуске клиента с флагом –h перечислены доступные параметры командной строки и их значения по умолчанию. 
  • Контейнер пакетной обработки поддерживается только в Linux.

Чтобы запустить контейнер, используйте команду Docker run. Эта команда запускает интерактивную оболочку внутри контейнера.

docker run --network host --rm -ti -v /mnt/my_nfs:/my_nfs --entrypoint /bin/bash /mnt/my_nfs:/my_nfs docker.io/batchkit/speech-batch-kit:latest

Чтобы запустить клиент пакетной обработки, выполните следующую команду.

run-batch-client -config /my_nfs/config.yaml -input_folder /my_nfs/audio_files -output_folder /my_nfs/transcriptions -log_folder /my_nfs/logs -file_log_level DEBUG -nbest 1 -m ONESHOT -diarization None -language en-US -strict_config

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

docker run --network host --rm -ti -v /mnt/my_nfs:/my_nfs docker.io/batchkit/speech-batch-kit:latest -config /my_nfs/config.yaml -input_folder /my_nfs/audio_files -output_folder /my_nfs/transcriptions -log_folder /my_nfs/logs

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

Режимы выполнения

Комплект пакетной обработки предоставляет три режима с помощью параметра --run-mode.

В режиме однократного выполнения (ONESHOT) расшифровывается один пакет звуковых файлов (из входного каталога и необязательного списка файлов) и результат помещается в выходную папку.

Схема, показывающая контейнер пакетного комплекта, обрабатывающий файлы в одноразовом режиме.

  1. Определите конечные точки контейнера распознавания речи, которые использует клиент пакетной обработки, в файле config.yaml.
  2. Поместите звуковые файлы для транскрибирования во входной каталог.
  3. Вызовите контейнер в каталоге, чтобы начать обработку файлов. Если звуковой файл уже транскрибируется в предыдущем запуске с тем же выходным каталогом (тем же именем файла и контрольной суммой), клиент пропускает файл.
  4. Файлы отправляются в конечные точки контейнеров из шага 1.
  5. Журналы и выходные данные контейнера службы "Речь" возвращаются в указанный выходной каталог.

Логирование

Примечание.

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

Клиент создает файл run.log в каталоге, определяемом аргументом -log_folder в команде Docker run. По умолчанию журналы записываются на уровне отладки. Эти же журналы отправляются в stdout/stderr и фильтруются в соответствии с аргументом -file_log_level или console_log_level. Этот журнал необходим только для отладки или в случае, если необходимо отправить трассировку в службу поддержки. В папке журналов также содержатся журналы Speech SDK каждого звукового файла.

Выходной каталог, указанный -output_folder, содержит файл run_summary.json, который переписывается каждые 30 секунд или когда завершатся новые транскрипции. Этот файл можно использовать для проверки хода выполнения пакетной обработки. Он также содержит окончательную статистику выполнения и окончательное состояние каждого файла при завершении пакета. Обработка пакета завершается, когда процесс завершается корректно и без ошибок.

Следующие шаги

  • Последнее обновление: