メインコンテンツへスキップ

​
概要

WebSocket API でコンテキスト ID を使用する場合、単一のコンテキストに送信されたすべてのトランスクリプトの音声チャンクは、同じコンテキスト ID を共有します。これにより、どの音声チャンクが特定のトランスクリプト送信に対応しているかを判別することが難しくなります。 この動作はストリーミング音声には適していますが、一部の実装では音声チャンクをその元となったトランスクリプトに対応付ける機能が必要になります。
context_flushing

​
手動フラッシング

手動フラッシングは、同一コンテキスト内でのトランスクリプト送信の境界を明確にします。

​
動作の仕組み

手動フラッシをトリガーするたびに、システムは flush_id カウンターをインクリメントします。この ID は対応するレスポンスの音声チャンクのペイロードに含まれるため、どのトランスクリプトが特定の音声チャンクを生成したかを追跡できます。

​
実装

手動フラッシをトリガーするには、次のようにします:
  1. 次のパラメーターを含むリクエストを送信します:
    • continue=True (同じコンテキストを継続することを示します)
    • flush=True (フラッシュ操作をトリガーします)
    • 空のトランスクリプト
    • 直前のリクエストと同じコンテキスト ID

​
フロー例

1. Submit transcript 1 on context 1
2. Flush context 1
3. Submit transcript 2 on context 1
このフローでは:
  • トランスクリプト 1 のすべての音声チャンクは flush_id=1 を持ちます
  • 手動フラッシによって ID がインクリメントされます
  • トランスクリプト 2 のすべての音声チャンクは flush_id=2 を持ちます

​
ペイロード構造

各音声チャンクのペイロードには、トランスクリプト識別子として機能する flush_id フィールドが含まれます。この ID は手動フラッシュ操作のたびにインクリメントされ、トランスクリプト送信間の明確な境界を作ります。

​
手動フラッシングを使う場面

次のような場合に手動フラッシングの利用を検討してください:
  • 音声チャンクを元のトランスクリプトに関連付ける必要がある場合
  • アプリケーションのアーキテクチャがトランスクリプトとレスポンスストリームの 1 対 1 の関係を前提としている場合
  • 各トランスクリプトに対応するジェネレーターがあることを前提としたフレームワークと統合する場合
この機能は複数のプロバイダーを使用する場合に特に有用で、トランスクリプトごとに個別のジェネレーターレスポンスを期待するシステムと Cartesia API を整合させます。