ユーザーが同じ質問を40通りの異なる表現でしてきており、あなたはLLMにそれぞれを一から回答させている。 「パスワードをリセットするにはどうすればいいですか？」 「ログイン情報を忘れました、助けてください」 「アカウントにログインできません」 同じ答え。3回の完全なモデル呼び出し。 通常のキャッシュではこの問題を捕捉できない。文字列が完全に一致する場合にのみ機能する。 セマンティックキャッシュは意味に基づいてマッチングする。 質問が入力され、エンベッディングに変換される。キャッシュは、以前に類似の質問に回答したかどうかを確認する。 ヒットした場合、保存された回答が即座に返される。LLM呼び出しはゼロ。 ミスした場合、モデルが回答し、その回答が次回のために保存される。 Redisは、この機能を「LangCache」としてマネージドサービスとして提供している。追加のデータベースをデプロイする必要はなく、TTLや削除処理も自動で対応。 彼らは、キャッシュヒットが15倍速くなり、APIコストを大幅に削減できると主張している。 しかし、誰も投稿していない重要な点がある。 それは、類似度の閾値設定だ。 閾値を緩くしすぎると、「APIキーをローテートする方法は？」という質問に、「APIキーを無効化する方法は？」の回答が返ってしまう。 意味的には近いが、結果は大きく異なる。 まずは厳しく設定すること。1週間、すべてのヒットをログに記録し、実際に回答が互換性があると確認できた箇所だけ緩める。 あなたの節約額は、トラフィックの繰り返し度に依存する。サポートボットや内部ドキュメントアシスタントは大幅な効果を発揮するが、創造的または一回限りのクエリではほとんど効果がない。 価格ページを確認する前に、まずログを確認せよ。 @cyrilXBT をフォロー https://t.co/tQmQCsxVlo