OpenAIのRealtime API
2024-Oct-5
最近のブログ執筆は、ほぼリアルタイムで行う必要があります。数日間でもコンテンツを寝かせると、 すぐに時代遅れになるリスクがあります。前回の投稿では、AIインターフェースの使いやすさに対する障害、 たとえば中断や遅延についてお話ししました。2週間も経たないうちに、 OpenAIがこれらの問題に直接対応するリアルタイムAPIをリリースしました。ここで、 私の初見の感想をお伝えします。
スピーチ終了(End-of-Speech)の始まりの終焉
私は、私のように会話型AIに関わる多くの人々が、最近の OpenAI の Realtime API のリリースを理解しようと奮闘していることを想像しています。柔軟性のないターンテイキングは、 音声対話システムの使いやすさに影響を与える大きな障害となっており、 製品品質のリアルタイム音声-to-音声API(別名フルデュプレックス、 すなわち継続的な認識と生成)の発表は、ある意味で世界を揺るがすものです。
少し気持ちを落ち着けた後、Realtime APIが会話型AIシステムの設計にどのように影響を与えるかについてのいくつかの考えをまとめました:
- ユーザー入力をLLMに渡す前のプロンプトへの文脈更新などの外部の意思決定プロセスは、 LLMのリアルタイム応答を使用する場合に比べて、 著しい遅延が生じるコストがかかります。これはおそらくアンチパターンとなるでしょう。
- 即時の応答がLLMによって処理され、 外部制御が時折回復されるハイブリッドな「考える前に話す」フロー(たとえば、LLMが関数呼び出しを開始する場合)です。
言い換えれば、Realtime APIはLLMを会話の時間に敏感なフローを調整するレベルに引き上げ、外部ルーターは時折呼び出される可能性があり、 できれば非同期かつブロッキングしない方法で、関数呼び出しの応答やプロンプトの更新を注入して会話を導く役割を果たします。
自身のターンテイキングの境界を引き続き調整したい人々にとって、Realtime APIはクライアントが独自の音声活動検出(VAD)を使用することを許可します。 このモジュール設計の伝統への敬意は、遅延の増加を招くことになり、さらにアンチパターンになる可能性があります。