会話型AIのレイテンシーを最適化するにはどうすればよいでしょうか?

ほとんどのアプリケーションでは、レイテンシー（遅延）は軽微な問題です。しかし、会話型AIの場合、レイテンシーが良い会話型AIアプリケーションと優れたアプリケーションとを分ける要素となります。

まず、会話型 AI の目標はかなり野心的です。つまり、知能において人間を超えながら、人間の会話と同じ感覚、感触、声を提供することです。これを実現するには、アプリケーションは長い沈黙といったギャップを発生させずに会話する必要があります。そうでなければ、リアリズムは崩壊します。

会話型AIのレイテンシーの課題は、その断片的な性質によってさらに複雑になります。会話型AIは一連の中間プロセスであり、それぞれがそれぞれの分野で最先端とみなされています。これらの各プロセスでは、少しづつ遅延が積み重なります。

生成音声会社として、私たちは会話型AIの遅延を最小限に抑える方法を長い間研究してきました。今日は、会話型AIアプリケーションの構築に関心のあるすべての人にとって役立つことを願って、私たちが学んだことを共有したいと思います。

4つのコアコンポーネント

すべての会話型AIアプリケーションには少なくとも 4つ ステップ: 音声テキスト変換、ターンテイキング（会話切り替え）、テキスト処理 (LLM など)、およびテキスト読み上げ（TTS)。これらのステップは並行して実行されますが、各ステップで依然として多少の遅延が発生します。text-to-speech. While these steps are executed in-parallel, each step still contributes some latency.

特に、会話型 AI のレイテンシー方程式は独特です。多くのプロセス遅延の問題は、単一のボトルネックにまで軽減できます。たとえば、Web サイトがデータベース要求を行うと、Web のネットワークレイテンシーが全体のレイテンシーに影響し、バックエンドの VPC レイテンシーはわずかな影響しか与えません。ただし、会話型AIのレイテンシーコンポーネントはそれほど大きく変化しません。それらは不均一ですが、各コンポーネントのレイテンシー寄与は他のコンポーネントの程度の範囲内です。したがって、レイテンシーは各部分の合計によって決まります。

自動音声認識

システムの「耳」

自動音声認識 (ASR) は、音声テキスト変換 (STT) とも呼ばれ、音声をテキストに変換するプロセスです。

ASR の遅延は、テキストの生成にかかる時間ではありません。音声テキスト変換プロセスは、ユーザーが話している間にバックグラウンドで実行されます。代わりに、遅延は、音声の終了からテキスト生成の終了までの時間です。

したがって、短い発話間隔と長い発話間隔では、同様の ASR遅延が発生する可能性があります。また、音声テキスト変換モデルはかなり最適化されているため、ネットワークの往復を含めた遅延は通常 100 ミリ秒未満です。（モデルがブラウザに埋め込まれているため、ネットワークレイテンシーがまったく発生しない場合もあります。Chrome/Chromiumなど：

ターンテイキング/割り込み

システムの「本能」

ターンテイキング/割り込み (TTI) は、ユーザーがいつ話し終えたかを判断する中間プロセスです。基礎となるモデルは、音声区間検出 (VAD) として知られています。

ターンテイキングには複雑な一連のルールが関係します。短い発話（「うん」など）でターンを開始すべきではありません。そうしないと、会話があまりにもスタッカートに感じられます。代わりに、ユーザー（話者）が実際にモデルの注意を引こうとしているタイミングを評価する必要があります。また、ユーザーが自分の考えを伝え終えたかどうかも判断する必要があります。

優れたVAD（音声区間検出）は、 無音を検出しても 新しいターンを開始する信号を出しません。単語（およびフレーズ）の間には沈黙があり、モデルはユーザーが実際に話し終えたことを確信する必要があります。これを確実に達成するには、沈黙の閾値（より具体的には、発話の欠如）を探す必要があります。このプロセスにより遅延が発生し、ユーザーにとっては待ち時間が発生します。

技術的に言えば、他のすべての会話型AIコンポーネントが ゼロ遅延であった場合、 TTIに起因する遅延は良いことだと言えます。人間は言葉に反応するまでに少し時間がかかります。機械が同様の一時停止を取ることで、インタラクションにリアリティが生まれます。ただし、会話型 AI の他のコンポーネントではすでに遅延が発生しているため、TTI 遅延は最小限に抑えることが理想的です。

テキスト処理

システムの「脳」

次に、システムは応答を生成する必要があります。現在、これは通常、GPT-4 や Gemini Flash 1.5 などの大規模言語モデル (LLM) を使用して実現されます。

言語モデルの選択によって大きな違いが生じます。Gemini Flash 1.5 のようなモデルは非常に高速で、350 ミリ秒未満で出力を生成します。GPT-4系や Claude など、より複雑なクエリを処理できるより堅牢なモデルでは、700 ミリ秒から 1000 ミリ秒かかる可能性があります。通常、会話型 AI プロセスを最適化する際にレイテンシーをターゲットにする最も簡単な方法は、適切なモデルを選択することです。

しかし、LLMのレイテンーは、 トークンの生成を開始 するまでの時間です。これらのトークンは、次のテキスト読み上げプロセスにすぐにストリーミングできます。テキスト読み上げは人間の声の自然なペースによって遅くなるため、LLM は確実にそれを上回ることができます。重要なのは、最初のトークンの遅延 (つまり、最初のバイトまでの時間) だけです。text-to-speech process. Because text-to-speech is slowed by the natural pace of a human voice, the LLM reliably outpaces it—what matters most is the first token latency (i.e., time to first byte).

LLM のレイテンシーに影響を与える要因は、モデルの選択以外にも存在します。これらには、プロンプトの長さと知識ベースのサイズが含まれます。どちらかが大きいほど、待ち時間は長くなります。結局のところ、LLM が考慮する必要がある項目が増えるほど、時間がかかるという単純な原則になります。したがって、企業はモデルに過度の負担をかけずに、適切な量のコンテキストのバランスをとる必要があります。

テキスト読み上げ

システムの「口」

会話型AI の最後のコンポーネントは、テキスト読み上げ (TTS) です。テキスト読み上げのネット遅延とは、テキスト処理から入力トークンを受け取ってから読み上げを開始するまでにかかる時間です。そう、追加のトークンは人間の音声よりも速い速度で利用可能になるため、テキスト読み上げの遅延**は厳密には最初のバイトまでの時間になります。text-to-speech (TTS). Text-to-speech’s net latency is the time it takes to begin speaking after receiving input tokens from text-processing. That’s it—because additional tokens are made available at a rate faster than human speech, text-to-speech’s latency is strictly the time to first byte.

以前は、テキスト読み上げは特に遅く、音声を生成するのに 2～3秒もかかっていました。ただし、当社のターボエンジンのような最先端のモデルでは、わずか 300 ミリ秒の遅延で音声を生成できます。実際、当社の V2/V2.5 フラッシュ TTS エンジンは、最初のバイトのオーディオ遅延が 200ミリ秒という、この分野で最高のスコアを達成しています (少し自慢しなければなりません!)。text-to-speech was particularly slow, taking as long as 2-3s to generate speech. However, state-of-the-art models like our Turbo engine are able to generate speech with just 300ms of latency the the new Flash TTS engine is even faster. Flash has a model time of 75ms and can achieve an e2e 135ms of time to first byte audio latency, the best score in the field (we have to brag a little!).

追加寄稿者

4つのコンポーネント以外にも、会話型AIのネット遅延に影響を与える要因がいくつかあります。

ネットワーク遅延

ある場所から別の場所にデータを送信する際には、常に遅延が発生します。一部の会話型AIアプリケーションでは、ASR、TTI、LLM、および TTS プロセスが同じ場所に配置されるのが理想的です。そのため、重大なネットワーク遅延の唯一の発生源は、スピーカーとシステム全体の間のパスになります。TTS processes should ideally be co-located, so the only source of non-trivial network latency is the paths between speaker and the entire system. This gives us an advantage on latency as we can save two server calls since we have our own TTS and an internal transcription solution.

関数呼び出し

機能を呼び出す（つまり、ツールやサービスとのインターフェース）ための会話型AIアプリケーションが多数存在します。たとえば、AIに天気を調べるように口頭で依頼するかもしれません。これには、テキスト処理レイヤーで呼び出される追加の API 呼び出しが必要になり、ニーズに応じて大幅に長い遅延が発生する可能性があります。API calls invoked at the text-processing layer, which can incur significantly more latency depending on the needs.

たとえば、ピザを口頭で注文する必要がある場合、複数の API 呼び出しが必要になる可能性があり、その中には過度の遅延が発生するものもあります (例: クレジットカードの処理)。API calls that are necessary, some with excessive lag (e.g. processing a credit card).

しかし、会話型AIシステムは、関数呼び出しが完了する前にLLMにユーザーに応答するように促すことで、関数呼び出しに関連する遅延に対処することができます（例：「天気を調べてみましょう」。これは現実の会話をモデル化しており、ユーザーが関与せずに終わることはありません。

これらの非同期パターンは通常、Webhook を活用して長時間実行されるリクエストを回避することによって実現されます。

電話

会話型AIプラットフォームのもう 1 つの一般的な機能は、ユーザーが電話でダイヤルインできるようにすることです (または、場合によっては、ユーザーに代わって電話をかけることもできます)。電話通信では追加の遅延が発生しますが、この遅延は地理的な条件に大きく依存する可能性があります。

基本的に、電話が同じリージョンに限定されている場合、追加の200ミリ秒の遅延が発生します。国際通話（例：アジア → 米国）の場合、遅延が約500ミリ秒に達し、移動時間が大幅に長くなる可能性があります。このパターンは、ユーザーが所在する地域外の電話番号を持っている場合によく見られる可能性があります。その場合、ベース国の電話ネットワークへのホップが強制されます。

最後に

会話型 AI に関するこの往復の調査が興味深いものであったことを願っています。要約すると、アプリケーションは 1秒未満のレイテンシーを目標にする必要があります。これは通常、タスクに適した LLM を選択することで実現できます。また、より複雑なプロセスがバックグラウンドで実行されているときは、長時間の停止を防ぐために、ユーザーとインターフェースをとる必要があります。

結局のところ、目標はリアリズムを生み出すことです。ユーザーは、コンピュータ プログラムの利点を享受しながら、人間と話す気楽さを感じる必要があります。サブプロセスを強化することで、これが可能になりました。

Elevenlabs では、最先端の STT および TTS モデルを使用して、会話型AIシステムのあらゆる部分を最適化しています。プロセスの各部分に取り組むことで、シームレスな会話フローを実現できます。このトップダウンのオーケストレーションの視点により、あらゆる段階でレイテンシーを少し（ 1ミリ秒でも）削減できます。TTS models. By working on each part of the process, we can achieve seamless conversation flows. This top-down view on orchestration allows us to shave off a little latency—even 1ms—at every juncture.