この記事は2025年7月に更新されました。

TL;DR

この記事では、RAG（Retrieval Augmented Generation：検索拡張世代）システム、特に顧客サービス／サポートのアプリケーションにおけるリアルタイムの音声対話において、待ち時間を短縮する方法を探る。

はじめに

Retrieval Augmented Generation (RAG)の採用により、多くの組織が、事前学習、微調整、RLHF、アダプターなどの高価で複雑な学習方法に頼ることなく、大規模言語モデル(LLM)の生成能力に簡単にアクセスできるようになりました。RAGは、組織が膨大な量の情報を含む知識ベースを構築し、関連する部分だけを取り出すことを可能にし、情報をLLMに直接組み込むことなく、包括的な答えをLLMに提供します。

RAGとは？

RAGでは、モデルが大規模なデータベースから関連する文書や情報を検索し、その検索された情報を使って応答を生成する。RAGは通常、リトリーバとジェネレータの2つの部分からなるシステムを使用する。リトリーバは、クエリに基づいて関連する文書や文章を検索する。多くの場合、スパース検索、デンス検索、ハイブリッド検索のような方法を使用し、セマンティック（ベクトルベース）検索は、高速で文脈に正確な結果を得るために一般的に使用される。ジェネレーター（多くの場合GPTのようなモデル）は、検索された情報を合成して最終的な応答を生成する。これにより、モデルはより正確で事実に基づいて正しい回答を提供することができる。

RAGの最もポピュラーな使用例は2つある：

1. カスタマーサービス:エンドユーザー向けにバーチャルエージェント/アシスタント/チャットボットを使用して、ビジネスの外部/内部情報を会話形式で公開し、FAQやQ&Aモジュールを自動化することで、高い封じ込め率を実現する。

2. 企業検索:Google Drive、Confluence、JIRA、Zendesk、ウェブサイト、静的ファイルなどのデータソースに接続することで、非公開の組織情報を検索可能にし、より正確な回答を提供します。

Voiceと許容可能な会話待ち時間

カスタマーサービスにRAGを使用する場合、情報検索やLLMとの会話は通常、音声またはデジタルチャネル（ウェブ、WhatsApp、SMSなど）で行われます。待ち時間は、会話の質と効果に大きな影響を与えるため、リアルタイム・コミュニケーションにおいて非常に重要な要素です。リアルタイム・コミュニケーションにおける遅延とは、話し手が音を出してから聞き手がそれを聞くまでの遅れを指します。

音声チャネルは遅延に対する耐性が低く ITU-T（国際電気通信連合の電気通信標準化部門）はは、双方向タスクの片方向待ち時間を100ms、両端に人間が関与する会話ユースケースの待ち時間を150msとすることを推奨しています。デジタル・チャネルは一般に、Voiceチャネルに比べて許容レベルが高い。この記事では、人間対バーチャルアシスタント/エージェント/チャットボットの対話にRAGを使用する場合の音声チャネルの待ち時間を特に分析します。

Voice処理に複数のコンポーネントが関与するRAGのようなアーキテクチャでは、片道150msのレイテンシを達成することはほとんど不可能です。しかし、音声処理ロジックとAIモデルを適切に最適化することで、ほぼリアルタイムに近い体験を実現することができる。バーチャルアシスタント／エージェント／チャットボットのエンドユーザーは、遅延に非常に敏感な人間同士の会話に比べて、遅延耐性が高い。

音声通話のエンド・ツー・エンドの表示

End-to-end view of a voice call

RAGによる音声通話パイプラインは、様々なコンポーネントに分けることができる。通常、エンドユーザーがWebアプリケーションまたは電話で開始した会話から始まり、音声がサービスに到達するまでネットワーク遅延が蓄積されます。音声がサービスに到達すると、最初のステップでは、STT（Speech to Text）サービスを使用してテキストに変換します。書き起こされたテキストは情報検索に使用され、検索されたコンテキストはLLMに渡され、応答が生成される。この生成された応答は音声合成（TTS）サービスに送られ、TTSはテキストを音声に変換する。最後に、音声はネットワークを介してウェブ・アプリケーションまたは電話に送信され、エンドユーザーに再生される。

デバイス/アプリケーション/ブラウザ

エンドユーザーからの会話は通常、インターネットに接続されたデバイス/アプリケーション/ブラウザから始まります。エンドユーザーのデバイス/アプリケーション/ブラウザーは、オーディオをキャプチャし、エンコードを実行するため、レイテンシーにおいて重要な役割を果たします。また、オーディオを受信してデコードすることで、レスポンスを処理します。

エンドデバイスには通常3つの選択肢がある：

1. PSTN電話エンドユーザーがアプリケーションやウェブブラウザー内の通話機能を使用せずに物理的な番号にダイヤルする場合、音声をテキスト化するためにSpeech to TextまたはASRサービスに送信する前に、PSTNゲートウェイに送信する必要があります。

2. モバイルアプリケーションモバイルアプリケーションは、WebSocketまたはWebRTCでオーディオをストリーミングすることができます。しかし、TCPの上に構築されているWebSocketは、遅延の大きいネットワークではパフォーマンスの問題に悩まされる可能性があります。

3. ウェブブラウザウェブブラウザは WebRTCを搭載し、UDP の上に構築された低遅延のメディア・ストリーミングを可能にしている。

推奨アプリケーションがWebRTCをベースにしている場合、低遅延が最も効果的です。

アップリンクとダウンリンク・ネットワーク

アップリンクとダウンリンクのネットワークの待ち時間は様々で、エンドユーザーにとって予測不可能なため、ここで具体的な推奨事項を提示するのは難しい。

音声テキストサービス

このステップでは、音声をテキストに変換してさらに処理するため、非常に重要である。このステップの精度は応答パイプラインの全体的な効率に影響するため、低レイテンシーで高い精度を達成することが重要である。Speechmatics、Deepgram、Google ASR、AWS Transcribeなど、様々なプロバイダーがSpeech to Textサービスを提供している。2つのモードがあります：

1. 録音済み（バッチ）処理録音された音声バッファまたはファイルは、チャンク単位でSpeech to Textプロバイダーに送信されます。この方法では通常、処理前に無音状態を待つ必要があるため、待ち時間が発生します。

2. リアルタイム・ストリーミングエンドユーザーの発話は、受信と同時にSTTサービスに送信されるため、より高速に書き起こせますが、精度に問題が生じる可能性があります。リアルタイム・ストリーミングでは、効率的なVAD（Voice Activity Detection）が不可欠です。

推奨Speech to Textサービスでは、バッチ処理よりもリアルタイムストリーミングの方が低遅延を実現できる。

2025年現在、AssemblyAIやOpenAI Whisper API（ベータ版）のような新しいオプションも利用可能で、その多くは応答性を向上させるためにリアルタイムエンドポインティングをすぐにサポートしている。

情報検索

RAGで使用される検索方法は、生成モデルが有益な回答を生成するために使用できる、関連性のある高品質の文書や文章を検索するために極めて重要である。スパース、デンス、ハイブリッドのいずれの検索手法を選択するかは、回答の精度、待ち時間、計算上の制約などの要因に依存する。ハイブリッド検索法は、スパースとデンシスを融合させた手法であり、精度とリコールを組み合わせることができるため、RAGシステムにおいて非常に効果的であるとして人気を集めている。

セマンティック検索としても知られるベクトル検索は、通常、テキストの埋め込み（ベクトル表現）を使用し、最も類似した結果を見つけるためにそれらの埋め込みを検索する。ベクトル検索の待ち時間は、より短い（しかし文脈的には正確な）埋め込みベクトルを使用し、無関係な文脈をフィルタリングするために、より迅速な再スコアリングアルゴリズムを使用することによって短縮することができる。また、キャッシュやローカル・ベクトル・データベースを実装することでも、検索レイテンシを改善することができる。

推奨リアルタイムの会話には、そのスピードと効率性から、一般的にセマンティック検索が適している。ライブ・インタラクションの流れを維持するのに不可欠な、ほぼ瞬時の検索が可能。

MongoDBアトラスサーチはベクトル検索をサポートするようになったが、より低レイテンシーでリアルタイムのアプリケーションには、Weaviate、Qdrant、Pinecone、FAISSなどの専用ベクトルデータベースの方が一般的に性能が高い。

LLMプロセッシング

RAGシステムの生成部では、LLMを使用して、検索された情報とユーザーのクエリに基づいて、首尾一貫した文脈に関連した応答を生成する。Time to First Token (TTFT)は重要なパフォーマンス指標である。これは、プロンプトを受け取った後、モデルが最初のトークンの出力を生成するのにかかる時間を指す。この指標は、チャットボット、バーチャルアシスタント、リアルタイムコンテンツ生成などの対話型アプリケーションにおいて非常に重要です。

Google Chat Bisonのようなバッチ処理モデルでは、TTFTは一般的にレスポンス全体を生成するのにかかる時間を指し、Text to Speech (TTS)サービスがレスポンスを処理する前に、レスポンス全体が生成されるまで待たなければならないため、遅延が発生する可能性があります。対照的に、Gemini 1.5 Proのようなストリーミングモデルでは、最初のトークンが生成された瞬間からTTFTを測定することができ、即時出力が可能です。これは、TTSサービスが、応答の一部が利用可能になった時点で処理を開始し、配信できることを意味し、知覚される待ち時間を減らすことで、ユーザーエクスペリエンスを大幅に向上させます。

RAGの将来は、Google Vertex Geminiファミリーのような、より大きなコンテキストウィンドウを持つ、より洗練されたモデルによって実現される、リトリーバーコンポーネントが最小化されるか、完全に除去されるような進歩が見られるかもしれない。他にもいくつかの要因がLLMの応答生成に影響し、プロンプトのサイズを小さくしたり、コンテキストキャッシュを使用するなどの最適化が行われる。 コンテキストキャッシュを使用するなどの最適化により、待ち時間を短縮することができます。場合によっては、LLMの代わりにスモール・ランゲージ・モデル（SLM）を選択し、精度と応答時間の短縮を両立させることもできる。以下のようなプロバイダー FireworksAIのようなプロバイダーは、レイテンシーに特化したモデルの最適化に注力しています。 Claude 3 HaikuやMistral 7B Instructのような小型言語モデルも、本格的なLLM推論が不要なレイテンシが重要なアプリケーションで人気を集めています。

推奨ストリーミング・モードでのLLM出力は、待ち時間を大幅に短縮し、TTSが生成された応答をより早く再生できるようにする。また、Google Gemini Flash 8Bのような、よりレイテンシーの低い高速モデルもご検討ください。

音声合成サービス

このステップは非常に重要で、このサービスはテキストを音声に変換し、再生またはストリーミングする。Amazon Polly、Google TTS、Eleven LabsなどのプロバイダーがText to Speechサービスを提供しており、通常2つのモードがある：

1. 録音済み（バッチ）処理大量のテキストを1回の非同期処理で音声に変換します。電子書籍、ポッドキャスト、録音済みアナウンスの音声生成など、リアルタイム処理が重要でないアプリケーションに便利です。

2. リアルタイム・ストリーミングバーチャルアシスタント、対話型音声応答（IVR）システム、リアルタイムコミュニケーションツールなど、即時の音声出力を必要とするアプリケーションに不可欠です。

推奨バッチ処理に比べ、低遅延を実現するにはリアルタイムストリーミングが望ましい。

結論

RAG を使用したリアルタイム音声アプリケーションの待ち時間は、多くの要因に影響されま すが、さまざまな最適化技術によって、待ち時間を制御することができます。以下の表は、音声通信のさまざまなフェーズで予想される最大双方向レイテンシをまとめたものです。最適化により、レイテンシの大幅な改善が期待できます。この表は、デバイスおよびアップリンク/ダウンリンクネットワークによってもたらされるレイテンシを除外しています。

1. セマンティック検索 - ベクターデータベースはMongoDBをベースにしています。

2. LLM - ストリーミングなし

3. LLM - ストリーミング

これらの最適化戦略を実施することで、RAGパイプラインを使用した音声アプリケーションの待ち時間を大幅に短縮し、よりスムーズで効率的なリアルタイムの会話を実現できます。

お問い合わせ

私たちのAIスタジオをチェックしてください。 VonageコミュニティSlackまたは X.