低価格CPUでLLMウェブ検索を高速化する三層キャッシュ構成

導入

ライブウェブを検索して回答するLLMサービスでは、モデルの生成以外にも多くの処理が発生する。追質問のたびに会話履歴を読み直し、以前とほぼ同じ意図の検索を繰り返し、別セッションで既に処理したURLを再び埋め込むこともある。オープンソースの回答エンジンOreoLookは、最終回答だけを再利用するのではなく、検索パイプライン全体にある重複処理を対象にした。

三つのキャッシュ

• セッション・コンテキストウィンドウ：直近の発話をRedisに保存し、すばやく参照する。ウィンドウを超えた内容はHuffman圧縮してディスクへ移す。バックグラウンドのLRU処理がアイドル状態のセッションを退避し、必要なときに復元するため、保持ポリシーの範囲内で数時間から数日後に会話を再開できる。
• セマンティック・クエリキャッシュ：クエリを埋め込みベクトルに変換し、コサイン類似度で過去の近い問い合わせを探す。表現が異なっても意図が近い場合、検索やリモートLLM呼び出しの一部を省ける。
• URL埋め込みキャッシュ：複数のセッションで同じページが参照されることを前提に、URL単位で埋め込みを再利用する。これにより、同じURLのベクトル計算を繰り返さずに済む。

評価結果の読み方

評価環境は、8 vCPUと32GBメモリを備えたIntel Cascade Lakeサーバー1台で、三つのコンテナレプリカ上に30個のHypercornワーカープロセスを配置した。報告された数値は、Redis keyspaceヒット率89.3%、読み取り遅延約0.1ミリ秒、測定されたRedisメモリオーバーヘッド1.38MBである。

ただし、これらを過大解釈してはいけない。keyspaceヒットは要求されたキーが存在したことを示すだけで、クエリ全体がキャッシュから返ったことや、エンドツーエンド遅延が同じ割合で短縮したことを意味しない。意味キャッシュでは、類似度の閾値、ウェブ情報の鮮度、ユーザー間の分離も課題になる。ライブ情報が変化した後に古い結果を再利用する危険があるため、無効化と評価方法が重要になる。

意義

OreoLookは、大規模モデルをローカルで動かさず、CPUを検索、セッション管理、キャッシュ、埋め込みに使い、最終合成を外部推論サービスへ送る現実的な分業を示している。限られた予算で会話型検索を構築するチームにとって、不要な検索、埋め込み計算、モデル呼び出しを減らすヒントになる。

さらに、キャッシュ対象を生成テキストからコンテキスト、検索意図、取得ページの特徴へ広げた点も重要だ。これは長期エージェントメモリ、キャッシュ分離、実際にどれだけ下流処理を削減できたかを測る評価手法への出発点となる。

出典：Hugging Face Daily Papers