AIを使えば使うほど、コストが積み上がる。これ、最近すごく実感するんですよね。

特にRAG（Retrieval-Augmented Generation）を本番環境に入れると、ユーザーが増えるたびにLLMへのAPI呼び出しも増えて、気づいたら月の請求額がびっくりするくらいになってた、なんてことが起きやすい。

最近TLDRで紹介されていた記事を読んで、「そういえばこれ、ちゃんと考えてなかったな」と思ったことがあります。それが*セマンティックキャッシュ*の話です。

繰り返し質問の多さに気づいてますか？

エンタープライズのRAGシステムを分析すると、ユーザーのクエリの30%以上が繰り返しか意味的に同じ質問らしいんですよね。

「Q4の売上は？」「新入社員のオンボード手順は？」「このベンダーとの契約の要点は？」

こういう質問って、部署が違っても聞く内容はほぼ同じ。なのに毎回、ベクトル検索してSQLも叩いてLLMに推論させて……という同じ処理を繰り返してる。これは確かにもったいない。

2段階キャッシュ戦略が効く

提案されていた解決策は、2種類のキャッシュを組み合わせること。

1. セマンティックキャッシュ（意味の類似度で判定）

「先月の売上は？」と「前月の売上を教えて」は言い方が違っても同じ質問。埋め込みベクトルの類似度が95%以上ならキャッシュを返す、という仕組みです。

2. リトリーバルキャッシュ（文脈・トピックレベル）

同じドキュメント群を参照する質問なら、検索結果自体をキャッシュしておく。

この2段階を組み合わせると、LLMトークンコストを30%以上削減、レスポンスタイムも36秒→ミリ秒単位に短縮できたという結果が出ています。

中小企業でも使えるか？

「エンタープライズの話でしょ」と思うかもしれませんが、私はそうは思っていなくて。むしろクエリ数が少ない中小規模の方が、全体に占める繰り返し質問の割合が高かったりする。

社内向けのチャットボットや問い合わせ対応AIを作るとき、キャッシュ層を意識して設計するだけで、月々のAPI費用がかなり変わってくるはずです。

注意点も正直に

ただ、キャッシュには「古い情報を返してしまうリスク」がある。在庫数や価格みたいなリアルタイム性が必要なデータには、有効期限の設定とSHA-256フィンガープリントによる更新検知が必要で、ここの設計を手を抜くと間違った情報をキャッシュから返してしまう。

使いどころをちゃんと見極めながら入れるのが大事です。

AIのコストに悩んでいる方がいたら、まずこのアーキテクチャを参考にしてみてください。

---

参考記事: [Zero-Waste Agentic RAG: Designing Caching Architectures to Minimize Latency and LLM Costs at Scale](https://towardsdatascience.com/zero-waste-agentic-rag-designing-caching-architectures-to-minimize-latency-and-llm-costs-at-scale/)

← ブログ一覧に戻る