キャッシュ類似度閾値¶

このダイヤルは何か¶

キャッシュ類似度閾値は、セマンティックキャッシュにおいて「過去のクエリと新しいクエリがどれだけ似ていればキャッシュヒットとみなすか」を決めるパラメータです。一般的にはクエリの埋め込みベクトル間のコサイン類似度で測定し、閾値以上であればキャッシュされた応答を再利用します。

AI エージェントシステムでは、LLM 呼び出しの 1 回あたりのコストが高いため、同じ意図のクエリを毎回処理するのは無駄です。しかし、完全一致キャッシュでは表記揺れ（「東京の天気は？」と「東京の天気を教えてください」）に対応できず、ヒット率が極端に低くなります。セマンティックキャッシュはこの問題を解決しますが、閾値の設定を誤ると「異なる意図のクエリに対して古い応答を返す」という誤回答の再利用が発生します。

この閾値は固定値ではなく、クエリの領域ごとに異なる値を設定すべき変数です。FAQ のような汎用的な質問には緩い閾値を、医療・法務・金融のようなリスクの高い領域には厳しい閾値を適用するか、そもそもキャッシュ禁止区域（No-Cache Zone）に設定します。

効かなすぎる害 ⇔ 効きすぎる害¶

閾値が高すぎる場合（効かなすぎ＝ほぼヒットしない）¶

閾値を 0.99 のように厳しく設定すると、実質的に完全一致に近い条件になり、以下の問題が起きます。

コスト削減効果がない：キャッシュのヒット率が極端に低下し、ほぼ全てのクエリが LLM を呼び出します。キャッシュ基盤（埋め込み生成＋ベクトル検索）のコストだけが追加され、LLM コストは削減されません。
レイテンシの悪化：キャッシュ検索のオーバーヘッド（埋め込み生成 + ベクトル DB 検索）が加わるにもかかわらずヒットしないため、キャッシュがない場合よりも遅くなります。
投資対効果の不在：ベクトル DB の運用・保守コストをかけているのに見合う効果が得られず、システムの複雑さだけが増します。

閾値が低すぎる場合（効きすぎ＝何にでもヒットする）¶

閾値を 0.85 のように緩く設定すると、以下の危険があります。

誤回答の再利用：「Python のリスト操作」と「Python の辞書操作」のように、表面的に似ているが意図が異なるクエリにキャッシュがヒットし、的外れな応答を返します。ユーザーは LLM が「分かっていない」と感じます。
個別コンテキストの無視：「私の注文状況を教えて」という類似のクエリが、ユーザー A の応答をユーザー B に返してしまう可能性があります。キャッシュキーにユーザー識別子を含めていても、埋め込み空間での類似度は内容の類似性のみを反映するため、メタデータの分離が不十分だと混同が起きます。
陳腐化した情報の返却：在庫状況・価格・ステータスなど時間で変化する情報のキャッシュが、緩い閾値によって長期間再利用され続けます。TTL を設定していても、閾値が緩いと「類似しているが別の商品」の古いキャッシュに当たる可能性があります。
信頼性の低下：ユーザーが同じエージェントに似た質問を繰り返したとき、時々正確で時々的外れな応答が返ると、エージェント全体への信頼が損なわれます。

決め方¶

類似度閾値は主に [failure_cost] と [cost_sensitivity] のバランスで決まります。

[failure_cost]：失敗コストが高い領域ほど閾値を厳しく（高く）設定します。誤った応答の再利用による被害が大きい領域では、閾値を 0.97 まで引き上げるか、No-Cache Zone に指定してキャッシュ自体を禁止します。
[cost_sensitivity]：コスト感度が高いほど閾値を緩めてヒット率を上げたくなりますが、[failure_cost] との相反が生じます。コスト削減の圧力が強い場合は、安全な領域の閾値だけを緩め、リスクの高い領域は厳格に保つという非対称な戦略をとります。
[input_trust]：入力の信頼度が低い環境では、キャッシュポイズニング（悪意あるクエリに対する応答がキャッシュされ、類似の正当なクエリに返される）のリスクがあります。閾値を上げるか、書込側にも検証を入れます。

閾値の決定には、開発環境でのオフライン評価が有効です。クエリペアに対して「同じ意図か否か」のラベルを付け、各閾値での適合率（precision）と再現率（recall）を測定します。ヒット時の誤回答率（false positive rate）を概ね 1% 以下に抑えられる閾値を選ぶのが出発点です。

目安値（出発点）¶

以下はコサイン類似度を用いた場合の出発点です。使用する埋め込みモデルによって最適値は変わるため、必ず評価データで検証してください。

領域	閾値の目安	補足
低リスク FAQ（一般的な質問応答）	0.92〜0.94	ヒット率を重視。誤ヒットがあっても影響が小さい
中リスク業務（社内ヘルプデスク、商品説明）	0.94〜0.96	精度と効率のバランス
高リスク領域（医療、法務、金融判断）	0.97 以上、または No-Cache	誤回答のコストが極めて高い。再検証を併用する場合は 0.95 まで緩められる
リアルタイムデータ依存（在庫、価格、フライト）	No-Cache 推奨	TTL を極端に短くしてもタイミングの問題が残る
個人情報依存（ユーザー固有の質問）	No-Cache 推奨	キャッシュキーにユーザー ID を含めても、埋め込みベースのマッチングでは分離が不完全

閾値は本番運用開始後もモニタリングが必要です。ヒット率が低すぎれば閾値を下げ、誤ヒット報告が増えれば上げるという継続的な調整を行います。

実践的なアドバイス¶

閾値は領域ごとに変えてください。全クエリに単一の閾値を適用すると、安全な領域でヒット率が下がるか、リスクの高い領域で誤ヒットが増えるかのどちらかになります。D6 Semantic Cache with No-Cache Zones の No-Cache Zone を先に定義し、残りの安全領域にのみ閾値を適用するのが基本戦略です。
埋め込みモデルの選択が閾値の意味を変えます。同じコサイン類似度 0.95 でも、埋め込みモデルによって意味的な粒度が異なります。モデルを変更したら閾値の再評価が必須です。
キャッシュヒット後の再検証を検討してください。[failure_cost] が中程度の領域では、キャッシュヒットした応答を軽量モデルで「この応答は現在のクエリに適切か」と検証するハイブリッドアプローチが有効です。キャッシュの高速性を活かしつつ、誤ヒットのリスクを低減できます。
キャッシュのメタデータにコンテキスト情報を含めてください。ユーザーセグメント、タイムスタンプ、使用言語などをメタデータとして保存し、ベクトル類似度だけでなくメタデータの一致もヒット条件に加えると、誤ヒットを構造的に防げます。
ヒット率と誤ヒット率の両方を継続的に計測してください。ヒット率だけを見ると閾値を下げたくなりますが、誤ヒットは「ユーザーが指摘しない限り気づかない」沈黙の品質劣化です。定期的にサンプル監査を行い、ヒットした応答の妥当性を検証する仕組みを入れましょう。