# AIエージェント開発の意思決定ポイント ## キャッシュ類似度閾値 — セマンティックキャッシュの「ヒット判定」をどこに置くか 🎯 ポイント LLMエージェントのセマンティックキャッシュ、「閾値0.95にしておけばいいでしょ」と思っていませんか？ その閾値ひとつで、コスト半減にも、誤回答の量産にもなり得ます。領域ごとに閾値を変えないキャッシュは、時限爆弾です。 📋 概要 セマンティックキャッシュの類似度閾値は、「過去のクエリと新しいクエリがどれだけ似ていればキャッシュヒットとみなすか」を決めるパラメータです。埋め込みベクトルのコサイン類似度で測定し、閾値以上なら過去の応答を再利用します。LLM呼び出しは1回あたりのコストが高いため、同じ意図のクエリを毎回処理するのは無駄です。しかし完全一致では表記揺れに対応できず、ヒット率が極端に低くなります。セマンティックキャッシュはこの問題を解決しますが、閾値の設定を誤ると「異なる意図のクエリに古い応答を返す」という誤回答の再利用が発生します。 🔍 意思決定のポイント この閾値は主に2つの力のバランスで決まります。 ⚡ **失敗コスト（failure_cost）** — 誤った応答の再利用がどれだけ深刻か。医療・法務・金融のように誤回答が致命的な領域では、閾値を0.97以上に引き上げるか、そもそもキャッシュ禁止区域（No-Cache Zone）に設定します。 💰 **コスト感度（cost_sensitivity）** — LLM呼び出しコストの削減圧力がどれだけ強いか。コスト削減の圧力が強い場合でも、安全な領域の閾値だけを緩め、リスクの高い領域は厳格に保つ非対称戦略を取ります。 さらに、入力の信頼度が低い環境ではキャッシュポイズニングのリスクもあります。悪意あるクエリに対する応答がキャッシュされ、類似の正当なクエリに返されるという攻撃です。 💡 要点と詳細 閾値の設定は「全クエリに単一の値」ではなく、領域ごとに変えるのが鉄則です。 📊 目安値（コサイン類似度、出発点）: - 🟢 低リスクFAQ: 0.92〜0.94 — ヒット率重視、誤ヒットの影響が小さい - 🟡 中リスク業務（社内ヘルプデスク等）: 0.94〜0.96 — 精度と効率のバランス - 🔴 高リスク領域（医療・法務・金融）: 0.97以上、またはNo-Cache — 誤回答コストが極めて高い - ⛔ リアルタイムデータ依存（在庫・価格）: No-Cache推奨 — TTLを短くしてもタイミング問題が残る - 🔒 個人情報依存: No-Cache推奨 — 埋め込みベースのマッチングではユーザー分離が不完全 重要なのは、埋め込みモデルの選択が閾値の意味を変えるということです。同じコサイン類似度0.95でも、モデルによって意味的な粒度が異なります。モデルを変更したら閾値の再評価は必須です。 ⚖️ トレードオフ **閾値が高すぎる（ほぼヒットしない）場合:** - キャッシュ基盤のコストだけが追加され、LLMコストは削減されない - キャッシュ検索のオーバーヘッドで、キャッシュなしより遅くなる - ベクトルDBの運用コストに見合う効果が得られない **閾値が低すぎる（何にでもヒットする）場合:** - 「Pythonのリスト操作」と「Pythonの辞書操作」のように意図が異なるクエリに誤ヒット - ユーザーAの応答がユーザーBに返される可能性 - 陳腐化した情報（在庫・価格）が長期間再利用される - 時々正確で時々的外れな応答が返り、エージェント全体の信頼が損なわれる 🛠️ ユースケース 💬 **カスタマーサポートFAQ** — 「返品ポリシーは？」「返品の手順を教えて」のような表記揺れが多い質問群。閾値0.93前後で高いヒット率を実現しつつ、注文固有の質問はNo-Cache Zoneに分離します。 🏥 **医療情報アシスタント** — 症状や薬の情報を扱うため、誤回答のコストが極めて高い。閾値0.97以上に設定するか、キャッシュヒット後に軽量モデルで「この応答は現在のクエリに適切か」を再検証するハイブリッドアプローチを採用します。 📦 **ECサイトの在庫・価格問い合わせ** — リアルタイムデータに依存するため、No-Cache推奨。商品説明のような静的情報のみキャッシュ対象にし、価格・在庫は常に最新データを返します。 🔑 実践のコツ: ヒット率だけでなく誤ヒット率も継続的に計測してください。誤ヒットは「ユーザーが指摘しない限り気づかない」沈黙の品質劣化です。定期的にサンプル監査を行い、キャッシュヒットした応答の妥当性を検証する仕組みを入れましょう。 #AIエージェント# #ソフトウェアアーキテクチャ#