文字起こしとコミット戦略
このガイドでは、ElevenLabsリアルタイムスピーチtoテキストAPIで文字起こしとコミット戦略を扱う方法を紹介します。
ハウツーガイド · クライアント側 または サーバー側 ストリーミングのガイドを完了していることを前提としています。
概要
オーディオを文字起こしすると、部分文字起こしとコミット済み文字起こしを受け取ります。
- 部分文字起こし - 文字起こしの中間結果
- コミット済み文字起こし - 「commit」メッセージを受信した際に送信される、文字起こしセグメントの最終結果。1つのセッションには複数のコミット済み文字起こしを含められます。
コミット済み文字起こしには、任意で単語レベルのタイムスタンプを含められます。これは「include timestamps」オプションをtrueに設定した場合にのみ受信します。
コミット戦略
WebSocket経由でオーディオチャンクを送信する際、文字起こしセグメントは手動コミットまたは音声アクティビティ検出(VAD)の2つの方法でコミットできます。
手動コミット
手動コミット戦略では、文字起こしセグメントをコミットするタイミングを制御します。これはデフォルトで使用される戦略です。セグメントをコミットすると、文脈を失わずに処理済みの蓄積文字起こしをクリアし、新しいセグメントを開始します。レイテンシーを改善するには、20~30秒ごとにコミットすることをおすすめします。手動でコミットしない場合でも、モデルは蓄積されたオーディオが約36秒に達すると自動的にコミットします。
最良の結果を得るには、無音の間やターンの切れ目など、論理的なタイミングでコミットしてください。
短時間に連続して何度も手動コミットすると、モデルのパフォーマンスが低下する可能性があります。
以前のテキストコンテキストを送信する
文字起こし用のオーディオを送信する際、最初のオーディオチャンクとともに以前のテキストコンテキストを送信すると、モデルが音声の文脈を理解しやすくなります。これは次のような場面で役立ちます。
- 会話型AIのユースケースにおけるエージェントのテキスト - モデルが会話の文脈をより簡単に理解し、より良い文字起こしを生成できます。
- ネットワークエラー後の再接続 - 以前のテキストを手がかりとして、モデルが文字起こしを継続できます。
- 一般的な文脈情報 - 文字起こしの内容に関する短い説明があると、モデルが文脈を理解しやすくなります。
previous_textコンテキストを送信できるのは、最初のオーディオチャンクを
connection.send()で送信するときだけです。以降のチャンクで送信するとエラーになります。以前のテキストは
50文字未満の場合に最も効果的です。
音声アクティビティ検出(VAD)
VAD戦略では、文字起こしエンジンが音声と無音のセグメントを自動的に検出します。無音のしきい値に達すると、文字起こしエンジンは文字起こしセグメントを自動的にコミットします。
クライアント側インテグレーションでマイクからのオーディオを文字起こしする場合は、VAD戦略の使用をおすすめします。
無音中も接続を維持する
公式SDKはメッセージが届かなくても接続を切断しないため、ほとんどのインテグレーションでは対応不要です。独自のWebSocketクライアントや、その間にあるプロキシまたはロードバランサーが、しばらくフレームが届かないと接続を閉じる場合は、接続時に任意のkeepalive_interval_msクエリパラメータを渡してください。これは、たとえば10~15秒の間がある電話の通話など、長時間の無音時に重要です。サーバーはおおよそ各インターバルごとに、キープアライブのpartial_transcriptを送信します。現在のセグメントに未コミットのテキストがない場合は空(text: "")、ある場合は最新の部分テキストを繰り返します。
キープアライブは自動で継続するpingではありません。オーディオのストリーミングを継続する必要があります(無音フレームでも問題ありません)。 オーディオの送信を停止すると、キープアライブは送信されず、クライアントメッセージがない状態が15秒続くとサーバーは接続を閉じます。 このサーバー制限は設定できません。
500~10000(ミリ秒)の整数を受け付けます。デフォルトでは無効です。既存の動作を維持するにはパラメータを省略してください。- 範囲外または整数以外の値を指定すると、サーバーは
invalid_requestエラーを送信して接続を閉じます。 - キープアライブは自動で継続するタイマーではなく、送信した無音オーディオをモデルが実際に処理することで駆動されます。そのため、文字起こし経路が稼働していることも確認できます。
- オーディオは約1秒のチャンクで処理されるため、キープアライブはその周期に合わせて丸められたインターバルで届きます(たとえば、
1000は約1秒ごと、3000は約3秒ごとに発生します)。セッションの最初のキープアライブは、サーバーが文字起こし前に最初の約2秒間のオーディオをバッファリングするため、開始から約2秒後に届きます。余裕を持たせるため、インターバルは独自の読み取りタイムアウトの約3分の1以下に設定してください。 - キープアライブの
textが空になるのは、現在のセグメントにまだ未コミットのテキストがない場合だけです。発話後かつコミット前に一時停止が発生した場合、特にfilter_background_audio=trueまたはコミットを行わない手動コミットモードで顕著ですが、キープアライブは空にする代わりに最新の部分テキストを繰り返します。そのため中間テキストが消えることはありません。コミット後は、新しい発話が届くまでキープアライブは再び空になります。 commit_strategy=manualとcommit_strategy=vadの両方、およびfilter_background_audio=trueで動作します。すでにストリーミングしているオーディオ以外に、課金への影響はありません。session_startedメッセージのconfigはkeepalive_interval_msをそのまま返します(無効な場合はnull)。
空のpartial_transcript(text: "")は「現在のセグメントに発話がない」ことを意味します。一時停止中に同じ内容の
partial_transcriptが繰り返された場合もキープアライブです。クライアントでは、繰り返しを特別扱いせず、
通常どおり部分文字起こしを表示してください。
WebSocket URLにパラメータを追加します。
対応オーディオ形式
ベストプラクティス
オーディオ品質
- 品質と帯域幅の最適なバランスを得るには、16kHzのサンプルレートを使用してください。
- バックグラウンドノイズを最小限に抑えた、クリアなオーディオ入力を確保してください。
- クリッピングを避けるため、適切なマイクゲインを使用してください。
- 現時点ではモノラルオーディオのみをサポートしています。
チャンクサイズ
- スムーズなストリーミングのため、長さが0.1~1秒のオーディオチャンクを送信してください。
- チャンクを小さくするとレイテンシーは低くなりますが、オーバーヘッドは増加します。
- チャンクを大きくすると効率は向上しますが、レイテンシーが発生する場合があります。