Semantic CacheでLLMの使用コストを最適化

私はRetrieval Augmented Generation(RAG)によって動作する自然言語チャットボットのレポートシステムを構築しました。それはユーザーに素晴らしい体験を提供し、彼らはデータをクエリし、レポートを彼らが望んだサイズで切り替え、切断することができます。それは直感的で効率性を提供しました。 その後、LLM API Billが届きました。 そこで私は、このインテリジェンスを構築するための私の探求の中で、金融のブラックホールを作り出したことに気付きました。 その後、LLM API Billが届きました。 そこで私は、このインテリジェンスを構築するための私の探求の中で、金融のブラックホールを作り出したことに気付きました。 今日のITの世界では、各チームはAgentic AIシステムを構築しようとしています。これらのAgentic AIシステムは、開発、 eval、ユーザー受け入れテストから始めて、生産環境で何百と何千ものLLM呼び出しを行います。 RAG(Retrieval Augmented Generation)を導入するために、我々は、同様のコンテンツのためのベクトルストアをクエリし、ユーザーの質問、プロンプト、例、ガードレイルの指示、構造化された応答スケジュールなどをLLMに送信することを意味します。これは単純な質問のために、我々は文脈の名前で何百もの追加トークンを追加し、ガードレイルやいくつかのショットプロンプトなどを追加します。大言語モデル(LLM)はこれらのトークンをトークンとして分析し、答えを生成し、その後我々は私たちの質問に答えを得ます。この答えは、私たちの質問への答えであるか、または複数のエージェントワークフローのステップの1つへの構造 私のシステムでは、システムはVector DBとKnowledge Graphからデータを引っ張って答えを土台にします。私は文脈ウィンドウで約2000個の入力トークンを観察しました。LLMはその後、思慮深い、500個のトークンの応答を生成します。最初の目で見ると、それはわずか数セントです。しかし、1日あたり20万件のリクエストで、これらの「セント」はモンスターに変わります。開発と評価の段階で複数のユーザーとの使用を追加するだけです。現在、入力と出力がより安く見えるように、私たちはLLM APIの採用の初期段階にあり、サービスプロバイダーは意図的に多くの割引を提供しています。将来、これらの価格はより高くなります、そして、これらのシステム あなたはまた、LLMコストの周りの課題を引用するいくつかの記事を参照することができます。 The LLM Pricing War Is Hurting Education - and Startups 学費の戦争は教育とスタートアップを傷つける 間違ったLLMでエンタープライズAIをスケーリングする方法はあなたにコストがかかるかもしれません 私はLangGraph、Neo4j、ChromDB、Redisを使用してRAGベースのシステムを構築しました。私は生産におけるトークン燃焼を減らすためにセマンティックキャッシュと実装詳細と呼ばれるこのアーキテクチャパターンを導入しました。このパターンは、Cachingと同様の質問に答えることによってLLMの使用コストを減らすことができます。Let me present this pattern to you that you can apply in multiple use cases and in multiple touch points in your Agentic AI workflow. 何が隠蔽 キャッシュは私たちのITシステムアーキテクチャで何世紀にもわたって存在してきました。それはIn-Memoryで始まり、その後配布されました。当初はオンプレムまたはVMベースのデプロイのための限定的なオファーが少なかった。クラウドの登場とともに、多くのクラウドオファーが進化しました。今日の時点で、我々はかなり成熟したキャッシュシステムを持っています。しかし、キャッシュシステムの使用はキー値のペアに基づいています。キーはハッシュテーブルの種類のデータ構造にハッシュされ、保存されています。キャッシュは常に正確なキーベースの検索でした。あなたのキーが存在する場合、キャッシュシステムはあなたのキーの値を返します、そしてキーがそうでない場合、それは保存されていないか追放されたことを意味します。しかし Semantic Cacheとは? 複数の次元を持つベクトルとコジン類似性または類似のメカニズムを使用してベクトルを見つけることも長い間存在していました。しかし、LLMとRAGでは、ベクトル埋め込みと類似性の検索はかなり人気となっています。Vector RAGはRAGベースのシステムのソリューションの主な選択の一つです。これは類似したコンテンツを見つけるのに役立ちます。これは正確なキーを見つけるものではありません。代わりに、これはセマンティックに類似している埋め込みベクトルを見つけるのに役立ちます。 この機能はもともとVectorデータベースで開発されたが、今では、Redisなどのキャッシュシステムでも利用可能になり、今ではクラウドサービスプロバイダーもこの機能をキャッシュオファーに導入している。 Semantic Cache は、キーのハッシュの代わりにコンテンツまたはドキュメントの意味に基づいてキャッシュエントリを取得するキャッシュとして定義できます。 Semantic Cache は、キーのハッシュの代わりにコンテンツまたはドキュメントの意味に基づいてキャッシュエントリを取得するキャッシュとして定義できます。 Semantic Cacheの違い Cache、Semantic Cache、RAGの間を区別してみましょう。 以下のテーブルは、従来のキャッシュとセマンティックキャッシュの違いを明確にするのに役立ちます。 Factors Traditional Cache Semantic Cache Approach Key based Meaning based Key Search Exact match Similar match Best For APIs LLMs Example Key, Value (Student_Id, Student_Obj) 2025081520, StudentObject1 2025091640, StudentObject2 if key used while doing look up is different, then it wont's return any result Statements Where did Alex graduate from? Which university did Alex graduate from? both will fetch the same entry from cache. アプローチ キーベース 根拠の意味 キー検索 正確な試合 似た試合 ベスト for APIs LLM 例 キー、値(Student_Id、Student_Obj) 2025081520, 学生 対象1 2025091640, 学生オブジェクト2 検索時に使用したキーが異なる場合は、 then it won's return any result 声明 アレックスはどこから卒業したのか。 アレックスはどの大学を卒業したのか。 どちらもキャッシュから同じ入力を入力します。 次のテーブルは、RAGとSemantic Cacheの違いを明確にするのに役立ちます。 Factors RAG Semantic Cache Use To generate new response To return previously generated and cached answer Data External data sources like Vector databases Previously generated Questions and Answer Cost Medium to High Low Best For Grounded response generation Repeated but similar question 利用 新たな反応を生み出すために 以前生成され、キャッシュされた回答を返します。 データ ベクターデータベースなどの外部データソース 以前に生み出された質問と回答 コスト 中高〜中高 低い ベスト for 基盤反応世代 繰り返されるが似た質問 RAGとセマンティックキャッシュの違いは単純ですが、財政的な影響は大きいことがわかります。RAGは原始情報を取得し、回答を生成します。あなたの質問が繰り返しである場合、キャッシュの答えは、リハビリ、ツールオーケストラ、および生成を回避するため勝っています。 Semantic Cache ベースの RAG アーキテクチャ 私は、標準のRAGアーキテクチャの上に、セマンティックキャッシュのための次のアーキテクチャを設計しました。 建築の構成要素 ユーザー: ブラウザやモバイルアプリなどのクライアントから、ユーザーが自然言語で質問を入力すると、Q&A APIが呼び出されます。 API Gateway: API リクエストは Gateway で認証され、許可されています。 GraphRAG + VectorRAG Agent System(FastAPI) A LangGraph ReAct agent, this orchestrates the workflow. It decides whether to check the cache, query the graph store or vector store, or respond to the user. Guardrails: Implemented via system prompts and specific instruction sets to ensure safe and accurate responses. MCP (Model Context Protocol): Semantic Cache MCP Client: Connects to the cache server using Server-Sent Events (SSE). Semantic Cache MCP Server: A FastMCP server that exposes tools (cache_lookup, cache_store) and manages cache server(Redis) interactions. Semantic Cache Server(Redis): Acts as a Semantic Cache. It stores vector embeddings of questions and corresponding answers to provide fast retrieval for similar queries. LLM: エージェントの推論エンジンと、GraphRAGと自然言語の応答のためのCypherクエリのジェネレーター。 Observability(LangSmith):エージェントの実行ステップの追跡、モニタリング、デバッグを提供します。 知識グラフ(Neo4j):それは構造化された関係(例えば、(人)-[:WORKS_AT]->(組織))を格納し、LLMによって生成されたCypherを介してクエリされます。 Vector Store(ChromaDB): 知識文書から生成されたベクトル埋め込みを格納します。 セマンティックキャッシュを実装するために、主に新しいセマンティックキャッシュMCPコンポーネントが標準のRAGベースのエージェントシステムに追加されました。 The agent first does a cache look up. Semantic Cache MCP client uses cache_lookup tool to check if the question is already answered and cached Semantic Cache MCP Server uses CACHE_SIMILARITY_THRESHOLD of >95% to decide whether a similar question is cached in the server. I tested similarity thresholds ranging from 80% to 99%. Below 90%, false positives increased and I started getting incorrect cached answers for loosely similar phrases. Above 97%, cache hit rates were significantly bad. In my use case, finally 95% provided the best trade off between precision and reuse. The right balance, however, depends on your specific use case and data distribution. キャッシュヒットが発生した場合、RAG呼び出しをすることなく答えを返します、つまりVector dbも知識グラフ呼び出しもLLM呼び出しもありません。 キャッシュミスが発生した場合、標準のRAGを実行し、答えを生成します。 次のコードスナップは、キャッシュ検索のためのMCPサーバコードを表示します。私はKNNベースの類似性検索を使用し、最も近い一致を1つしか返しません。私は距離をスコアと1スコアを類似性として使用します。もう一つの重要なポイントは、REDISのベクトルクエリの必須用語である方言2の使用です。 @mcp.tool() def cache_lookup(question: str) -> str: """ Look up a semantically similar question in the cache. Args: question: The question to look up Returns: JSON with cached answer if found (similarity >= 95%), or cache miss indication """ global _hits, _misses client = get_redis_client() ensure_index_exists(client) # Compute embedding for the query query_embedding = compute_embedding(question) query_vector = np.array(query_embedding, dtype=np.float32).tobytes() # Vector similarity search try: q = ( Query(f"*=>[KNN 1 @embedding $vec AS score]") .return_fields("question", "answer", "expires_at", "score") .sort_by("score") .dialect(2) ) results = client.ft(INDEX_NAME).search( q, query_params={"vec": query_vector} ) if results.total > 0: doc = results.docs[0] score = float(doc.score) similarity = 1 - score # Convert distance to similarity expires_at = float(doc.expires_at) # Check expiration if time.time() > expires_at: logger.info(f"Cache entry expired for: '{question[:50]}...'") # Delete expired entry client.delete(doc.id) _misses += 1 return json.dumps({ "found": False, "reason": "expired" }) # Check similarity threshold if similarity >= CACHE_SIMILARITY_THRESHOLD: _hits += 1 logger.info(f"Cache HIT: similarity={similarity:.4f} for '{question[:50]}...'") return json.dumps({ "found": True, "answer": doc.answer.decode() if isinstance(doc.answer, bytes) else doc.answer, "similarity": round(similarity, 4), "original_question": doc.question.decode() if isinstance(doc.question, bytes) else doc.question }) _misses += 1 logger.info(f"Cache MISS for: '{question[:50]}...'") return json.dumps({ "found": False, "reason": "no_similar_question" }) except Exception as e: logger.error(f"Cache lookup error: {e}") _misses += 1 return json.dumps({ "found": False, "reason": f"error: {str(e)}" }) 最初に質問の埋め込みを計算しましたが、この質問の標準 md5 ハッシュであるキーの値として、原始質問と答えとともに保存されます。 @mcp.tool() def cache_store(question: str, answer: str) -> str: """ Store a question-answer pair in the semantic cache. Args: question: The original question answer: The answer to cache Returns: JSON confirmation of storage """ client = get_redis_client() ensure_index_exists(client) try: # Compute embedding embedding = compute_embedding(question) embedding_bytes = np.array(embedding, dtype=np.float32).tobytes() # Generate unique key key_hash = hashlib.md5(question.encode()).hexdigest()[:12] cache_key = f"cache:{key_hash}" current_time = time.time() # Store in Redis hash client.hset(cache_key, mapping={ "question": question, "answer": answer, "embedding": embedding_bytes, "created_at": current_time, "expires_at": current_time + CACHE_TTL_SECONDS }) # Set TTL on the key client.expire(cache_key, CACHE_TTL_SECONDS) logger.info(f"Cached answer for: '{question[:50]}...' (TTL: {CACHE_TTL_SECONDS}s)") return json.dumps({ "stored": True, "key": cache_key, "ttl_seconds": CACHE_TTL_SECONDS }) except Exception as e: logger.error(f"Cache store error: {e}") return json.dumps({ "stored": False, "error": str(e) }) 下記のスナップショットは、埋め込みでRedisで質問と答えのキャッシュを示しています。 次のスナップは、Cache_lookup を呼び出す MCP クライアント コードを表示します。 def cache_lookup(self, question: str) -> dict: return _run_async(self._req_with_connection("cache_lookup", question)) 次のスナップは、Cache_store を呼び出す MCP クライアント コードを示します。 def cache_store(self, question: str, answer: str) -> dict: return _run_async(self._req_with_connection("cache_store", question, answer)) 下記のトラックは、実行の流れを示しています。 Trace は cache_lookup 呼び出しで強調され、cache_hit としての出力は no_similar_question の理由で false として表示できます。 したがって、このフローでは、標準 RAG が実行されます。 あなたは graph_rag_query ノードを トラックに表示し、LLM 呼び出しに続きます。 今、それは真実の瞬間であり、同じような質問が再び質問される時です。次のスナップショットでは、cache_hit が真であることがわかります。質問の文法にわずかな変更がありますが、それは以前のものに似ていますので、類似性のスコアは下に示すように 0.9866 です。したがって、答えはキャッシュから直接取得され、RAG フローの実行は見られません。答えはセマンティック キャッシュから直接返されます。 結果 GraphRAG または VectorRAG システムにセマンティック キャッシュを追加することで、測定可能なパフォーマンスとコストの利点が得られました。以前は、システムはリクエストごとに 5 秒から 6 秒を要し、これは Vector 検索、Knowledge Grapher cypher クエリの生成と実行、および LLM による最終回答の生成を含みました。 セマンティックキャッシュ戦略 セマンティック・キャッシュが勝つ システムが大容量で予測可能なトラフィックを扱う場合、キャッシュレイヤーはパフォーマンスの利点を増加させます。多くのユーザーが同じ知識を求める場合、例えば「顧客サポート&ヘルプデスク」の使用ケースでは、「パスワードをリセットするにはどうすればよいですか?」、「返金ポリシーは何ですか?」などの質問があります。製品文書使用ケースでは、ユーザーが同じ製品マニュアルをクエリしている場合でも、開発者が同じ技術文書やAPIドキュメントをクエリする場合でも同じことが起こります。内部HR&オンボードングの使用ケースでは、「健康保険に登録するにはどうすればよいですか?」や「休日のスケジュールは何ですか?」などの質問が各社員に浮かび上がります。 セマンティックキャッシュを避けるには 特に、ハイパーパーソナライゼーションを提供するシステムでは失敗します。同じ質問を2人のユーザーが質問するが、彼らの医療歴やプロフィールまたはアカウントバランスを基に異なる回答を必要とする場合、セマンティックキャッシュは間違った答えを提供することができます。 あなたの文書、知識ベース、データが変動している場合、またはリアルタイムである場合でも失敗します。 例えば、株価やライブインベントリについての回答が必要な場合、キャッシュはあなたの敵です。 あなたは世界の現在の状態を見るためにRAGが必要です。 Semantic Cache Invalidation 戦略 キャッシュはリフレッシュする必要があり、セマンティックキャッシュには追加の無効化戦略が必要です。キャッシュのすべてのエントリは、その生存時間(TTL)値を管理するために created_at timestamp でタグ付けされなければなりません。セマンティックキャッシュでは、生成中に使用される document_version と embedding_model もタグ付けされるべきです。これは、インバージョンモデルをアップグレードする場合、ベクトルスペースが変化するため、重要です。これは古いキャッシュエントリを時代遅れさせるためです。これらの変数を追跡する必要があるので、ドキュメントソースが更新され、またはインバージョンモデルが変更または更新されるたびにキャッシュの無効化を引き起こすことができます。 認可およびセキュリティ考慮 どのキャッシュシステムでも、ユーザーにデータを提供する前に許可することを確認する必要があります。また、キャッシュされたデータが休憩時に保護されていることを確認する必要があります。セマンティックキャッシュの実装はこれらの原則に従わなければなりません。 マルチレンタントシステムでは、レンタント隔離キーはキャッシュで実装する必要があります。同様に、ハイパーパーソナライズされたユーザシステムでは、ユーザレベルのネームスペース分割はキャッシュで行わなければなりません。 権限認証に関する最も重要なポイントは、キーのハッシュがユーザーの特定の役割またはアクセスレベルを含む許可認識キャッシュキーの作成です。これにより、権限が少ないユーザーが、より特権のあるユーザーからキャッシュされた回答を受け取らないことを保証します。キャッシュヒットは、許可されていないデータキャッチメカニズムであってはなりません。ユーザーがRAGパイプラインを通じて特定の文書またはデータベースラインをキャッシュする許可がない場合は、キャッシュから生成された回答を引き出すことができません。 最後に、HIPPA または SOC2 などのさまざまなコンプライアンス要件を満たすために、あなたの回答はキャッシュされる前に暗号化されなければなりません。 結論 アーキテクチャのブレイプ、コードのスナップレット、およびさまざまなスナップショットは、質問をセマンティックにキャッシュし、Vector embeddingsに基づく類似性の検索を行い、以前生成された答えを返し、RAGベースのLLMの呼び出しを回避することが可能であることを証明します。 上記の例はかなりシンプルですが、このアーキテクチャの選択肢を、エージェント AI システムで起こる複数の LLM タッチポイントに拡張して、エンドユーザの質問と答えだけでなく、意思決定を行うことができます。 セマンティックキャッシングは、トークンのコストを低下させながら反応の質を維持するための簡単な方法です。あなたのシステムが同様のクエリを回答する場合、リハビリと生成ステップの前にキャッシュレイヤーを追加することは利点です。最も簡単な部分は、RAGアーキテクチャを修正する必要はありません、あなたは単にチェーンの早期に繰り返しの意図を扱って流れを最適化することです。