バッチ処理キットを使用して、音声コンテナー上のワークロードを補完およびスケールアウトします。 このオープン ソース ユーティリティは、コンテナーとして利用可能であり、任意の数のオンプレミスおよびクラウド ベースの音声コンテナー エンドポイントにわたって、多数のオーディオ ファイルのバッチ文字起こしを容易にすることができます。
バッチ キット コンテナーは GitHub と Docker ハブで無料で入手できます。 使用する音声コンテナーに対してのみ、課金されます。
| 特徴量 | 説明 |
|---|---|
| バッチ オーディオ ファイルの配布 | オンプレミスまたはクラウドベースの音声コンテナー エンドポイントに多数のファイルを自動的にディスパッチします。 ファイルは、ネットワーク ファイル システムなど、POSIX 準拠のボリュームに配置することができます。 |
| Speech SDK の統合 | n-best 仮説、ダイアライゼーション、言語、冒とく的表現のマスキングなど、一般的なフラグを Speech SDK に渡します。 |
| 実行モード | バッチ クライアントを 1 回、バックグラウンドで継続的に実行するか、オーディオ ファイルの HTTP エンドポイントを作成します。 |
| フォールト トレランス | 進行状況を失うことなく文字起こしの再試行と続行を自動的に行い、再試行できるエラーとそうでないものを区別します。 |
| エンドポイントの可用性検出 | エンドポイントが使用不能になった場合、バッチ クライアントによって他のコンテナー エンドポイントが使用され、文字起こしが続行されます。 クライアントが使用可能になると、エンドポイントの使用が自動的に開始されます。 |
| エンドポイントのホットスワップ | バッチの進行を中断せずに、実行時に音声コンテナー エンドポイントの追加、削除、または変更を行います。 更新は即時に行われます。 |
| リアルタイムのログ記録 | 各オーディオ ファイルの Speech SDK ログ ファイルを使用した、試行された要求、タイムスタンプ、およびエラーの理由のリアルタイムのログ記録。 |
docker pull によるコンテナー イメージの取得
docker pull コマンドを使用して、最新のバッチ キット コンテナーをダウンロードします。
注
次の例では、パブリック コンテナー イメージを Docker Hub からプルします。 匿名の pull request を行うのではなく、最初に Docker Hub アカウント (docker login) で認証を行うことをお勧めします。 パブリック コンテンツを使用するときの信頼性を向上させるには、プライベートの Azure Container Registry にイメージをインポートして管理します。
パブリック イメージの操作に関する詳細を参照してください。
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 の例では、3 つのホストに 3 つの音声コンテナーを指定しています。 最初のホストは IPv4 アドレスで指定され、2 つ目のホストはバッチ クライアントと同じ VM で実行され、3 つ目のコンテナーは別の VM の 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
バッチ クライアントとコンテナーを 1 つのコマンドで実行するには:
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 パラメーターを使用して 3 つのモードが用意されています。
ONESHOT モードを使用すると、(入力ディレクトリと省略可能なファイル一覧の) オーディオ ファイルの 1 つのバッチを文字起こしして出力フォルダーに出力できます。
- バッチ クライアントから使用される音声コンテナー エンドポイントを
config.yamlファイルに定義します。 - 文字起こし用のオーディオ ファイルを入力ディレクトリに配置します。
- ファイルの処理を開始するディレクトリ上でコンテナーを呼び出します。 同じ出力ディレクトリ (同じファイル名とチェックサム) を使用して、以前の実行でオーディオ ファイルが既に文字起こしされている場合、クライアントではそのファイルがスキップされます。
- ファイルは、手順 1 のコンテナー エンドポイントにディスパッチされます。
- ログと音声コンテナーの出力は、指定された出力ディレクトリに返されます。
ログ記録
注
run.log ファイルは大きくなりすぎると、バッチ クライアントによって定期的に上書きされる場合があります。
クライアントでは、Docker の コマンドの -log_folder 引数で指定されたディレクトリに run ファイルが作成されます。 ログは既定でデバッグ レベルでキャプチャされます。 同じログが stdout/stderr に送信され、-file_log_level 引数または console_log_level 引数に応じてフィルター処理されます。 このログは、デバッグ目的、またはサポートのためにトレースを送信する必要がある場合にのみ必要です。 ログ フォルダーには、各オーディオ ファイルの Speech SDK ログも含まれています。
-output_folder で指定された出力ディレクトリには、30 秒ごとに定期的に、または新しい文字起こしが完了するたびに書き換えられる run_summary.json ファイルが格納されています。 このファイルを使用すると、バッチの進行状況を確認できます。 また、バッチが完了したときのすべてのファイルの最終的な実行の統計情報と最終的な状態も含まれます。 プロセスに clean exit があると、バッチは完了します。