RAGを50％高速化するための工夫

RAGは、LLMの応答を大規模なナレッジベースに基づかせることで、AIエージェントの精度を高めます。ナレッジベース全体をLLMに送るのではなく、RAGはクエリを埋め込み、最も関連性の高い情報を取得して、モデルにコンテキストとして渡します。このシステムでは、取得前にまずクエリ書き換えのステップを加え、対話履歴を正確で自己完結したクエリにまとめます。

ナレッジベースが非常に小さい場合は、すべてを直接プロンプトに渡すほうがシンプルなこともあります。しかし、ナレッジベースが大きくなると、RAGはモデルに過度な負荷をかけずに応答の精度を維持するために不可欠になります。

多くのシステムではRAGを外部ツールとして扱いますが、このシステムではリクエストパイプラインに直接組み込み、すべてのクエリで実行しています。これにより精度の一貫性を確保できる一方で、レイテンシーのリスクも生じます。

クエリ書き換えが遅延の原因になった理由

ユーザーのリクエストの多くは以前の会話ターンを参照するため、システムは対話履歴を正確で自己完結したクエリにまとめる必要があります。

たとえば：

• ユーザーが次のように尋ねた場合： 「ピークトラフィックのパターンに応じて、これらの制限をカスタマイズできますか？」
• システムは次のように書き換えます： 「エンタープライズプランのAPIレート制限は、特定のトラフィックパターンに合わせてカスタマイズできますか？」

この書き換えにより、「これらの制限」のような曖昧な参照を、検索システムが利用できる自己完結したクエリに変換し、最終応答のコンテキストと精度を向上させます。しかし、外部ホスト型LLMを1つだけ利用する方法では、その速度と稼働率に大きく依存することになります。このステップだけで、RAGレイテンシーの80％超を占めていました。

モデルレースで解決した方法

クエリ書き換えを、競争形式で実行するよう再設計しました：

• 複数モデルを並列実行。各クエリを、自社ホストのQwen 3-4Bおよび3-30B-A3Bモデルを含む複数のモデルへ同時に送信します。最初に有効な応答を返したモデルを採用します。
• 会話を止めないフォールバック。1秒以内に応答するモデルがない場合は、ユーザーの元のメッセージにフォールバックします。精度は下がる可能性がありますが、停止を避け、会話の継続性を確保します。

パフォーマンスへの効果

この新しいアーキテクチャにより、RAGの中央値レイテンシーは326msから155msへと半減しました。RAGを外部ツールとして選択的に起動する多くのシステムとは異なり、すべてのクエリで実行しています。中央値レイテンシーが155msまで下がったことで、そのオーバーヘッドは無視できるほど小さくなりました。

レイテンシーの改善前後：

• 中央値：326ms → 155ms
• p75：436ms → 250ms
• p95：629ms → 426ms

このアーキテクチャにより、モデルごとのばらつきに対するシステムの耐性も高まりました。外部ホスト型モデルは需要のピーク時に遅くなることがありますが、内部モデルは比較的一貫した性能を維持します。モデルを競争させることでこのばらつきを平準化し、予測しにくい個々のモデルの性能を、より安定したシステム動作へと変換します。

たとえば先月、LLMプロバイダーの1社で障害が発生した際も、会話は自社ホストのモデル上で途切れることなく継続しました。このインフラはすでに他のサービスでも運用しているため、追加のコンピューティングコストは無視できるほど小さいものです。

重要な理由

200ms未満のRAGクエリ書き換えにより、会話型エージェントにおける大きなボトルネックが解消されます。その結果、大規模なエンタープライズナレッジベースを扱う場合でも、コンテキストを理解しつつリアルタイムに動作するシステムを実現できます。検索のオーバーヘッドがほぼ無視できる水準まで減ることで、会話型エージェントはパフォーマンスを損なうことなくスケールできます。