バッチ文字起こしは、ストレージ内の大量のオーディオ データを文字起こしする場合に使用されます。 音声テキスト変換 REST API と Speech CLI の両方で、バッチ文字起こしがサポートされています。
要求ごとに複数のファイルを提供するか、文字起こしするオーディオ ファイルを含む Azure Blob Storage コンテナーをポイントする必要があります。 バッチ文字起こしサービスでは、送信された多数の文字起こしを処理できます。 サービスによってファイルが同時に文字起こしされ、ターンアラウンド時間が短縮されます。
それはどのように機能するのでしょうか。
バッチ文字起こしでは、オーディオ データを送信し、文字起こしの結果を非同期的に取得します。 サービスではオーディオ データを文字起こしし、その結果をストレージ コンテナーに格納します。 その後、ストレージ コンテナーから結果を取得できます。
ヒント
ローまたはノーコードのソリューションの場合は、Power Automate、Power Apps、Logic Apps などの Power Platform アプリケーションでバッチ音声テキスト変換コネクタを使用できます。 開始するには、「Power でバッチ文字起こしを自動化する」ガイドを参照してください。
バッチ文字起こし REST API を使用するには:
- バッチ文字起こし用のオーディオ ファイルを検索する - 独自のデータをアップロードするか、パブリック URI または Shared Access Signature (SAS) URI を使用して既存のオーディオ ファイルを使用できます。
- バッチ文字起こしを作成する - オーディオ ファイル、文字起こし言語、文字起こしモデルなどのパラメーターを使用して文字起こしジョブを送信します。
- バッチ文字起こしの結果を取得する - 文字起こしの状態を確認し、文字起こしの結果を非同期で取得します。
重要
バッチ文字起こしジョブは、ベスト エフォートの原則でスケジュールされます。 ピーク時には、文字起こしジョブの処理が開始されるまでに最大 30 分、完了するまでに最大 24 時間かかる場合があります。 バッチ文字起こしジョブの現在の状態を確認する方法については、こちらのセクションを参照してください。
パフォーマンスを向上するためのベスト プラクティス
要求サイズ: バッチ文字起こしは非同期であり、要求は各リージョンで一度に 1 つずつ処理されます。 より高いレートでジョブを送信しても、処理は高速化されません。 たとえば、1 分あたり 600 要求または 6,000 要求を送信しても、スループットには影響しません。 1 つの Transcription_Create 要求で最大 1,000 個のファイルを送信することをお勧めします。 これにより、送信される要求が全体的に少なくなります。
時間配分: 時間の経過に伴う要求の配布: 数分以内に送信するのではなく、数時間にわたって送信します。 バックエンド処理では、固定帯域幅のために安定したパフォーマンス レベルが維持されるため、要求の送信が速すぎてもパフォーマンスが向上しません。
ジョブの監視: ジョブの状態を監視する場合、数秒ごとにポーリングする必要があります。 複数のジョブを送信した場合、最初に処理されるのは最初のジョブだけです。後続のジョブは、最初のジョブが完了するまで待機します。 すべてのジョブをポーリングすると、多くの場合、システムの負荷が増加し、メリットはありません。 10 分ごとに状態を確認するだけで十分であり、1 分に 1 回以上ポーリングすることはお勧めしません。
- 順次処理のため、ファイルのサブセットのみをチェックしてジョブの状態を取得できます。最初の 100 個のファイルを確認します。完了していない場合は、後のバッチも競合しない可能性があります。 もう一度確認する前に、少なくとも 1 分 (理想的には 5 分) 待機することをお勧めします。
API 呼び出しのピーク トラフィックを回避する: ListFiles、 Update、および Get API 呼び出しは、 Create 呼び出しと同様に動作し、ピーク時に最小化する必要があります。
負荷分散: 大規模なバッチ文字起こしのスループットを最適化するには、サポートされている複数の Azure リージョンにジョブを分散することを検討してください。 この方法は、データとコンプライアンスの要件によって複数リージョンの使用が可能な場合に、負荷の分散と全体的な処理時間の短縮に役立ちます。 リージョンの可用性を確認し、使用する予定の各リージョンからストレージとリソースにアクセスできることを確認します。