LLMの応答をキャッシュする:いつ、どのように

言語モデルへの呼び出しは、ソフトウェアの基準でいえば遅く高価です。それなりの時間がかかり、リクエストごとにお金がかかります。キャッシュ、つまり再び呼び出す代わりに保存された結果を再利用することは、その両方に対してあなたが持つ最も直接的なレバーです。しかしLLMは、通常のウェブキャッシュにはない形でキャッシュを複雑にします。同じ質問が千通りに言い表せて、モデルが同一のプロンプトに毎回異なる答えを返すかもしれないからです。本ガイドは、キャッシュがいつ役立つか、利用可能な種類、そして静かに古いまたは間違った答えを返すことなくそれらを適用する方法を説明します。

なぜキャッシュは手間に値するのか

キャッシュの根拠は、スケールするにつれて複利で効く三つの利点に基づきます。

• コスト。 キャッシュヒットはすべて、あなたが支払わなかったモデル呼び出しです。ボリュームがあり、反復的なワークロードでは、これが実行可能な製品と高価な製品との分かれ目です。
• レイテンシ。 保存された答えを返すことは、新しく生成するより劇的に速いです。対話的な製品では、その速さがユーザーに直に感じられます。
• 安定性。 キャッシュされた答えは毎回同一です。新規性より一貫性が重要なワークフローでは、その決定性は限界ではなく特長です。

これらの利点の大きさは、ワークロードがどれだけ反復的かに完全に依存します。ユーザーが似た質問を何度も繰り返すアプリには、巨大なキャッシュの潜在力があります。すべてのリクエストが一意なアプリには、ほとんどありません。自分がどちらを持っているかを知ることが最初の判断です。

完全一致キャッシュ:シンプルで安全な出発点

最も素直なアプローチは、キャッシュのキーを正確なリクエストにすることです。同一のプロンプトが、同一のモデルとパラメータで再び来たら、モデルを呼ぶ代わりに保存された応答を返します。

これは安全で考えやすいものです。一致が文字通りで、二つのリクエストが「十分に近い」かどうかの判断がないからです。本当に繰り返されるリクエストで輝きます。同じ文書を処理する固定のシステムプロンプト、一言一句同じに問われる人気の質問、あるいは同一の入力を再実行する自動化されたジョブ。限界も同じく明らかです。自然言語は多様で、「返金ポリシーは?」と「返金を受けるには?」は、同じ答えを求めていても、どちらも完全一致キャッシュを外す異なる文字列です。完全一致キャッシュが出発点として正しいのは、まさにそれが間違った質問に間違った答えを決して返さないからです。単に外す頻度が高いだけです。

意味キャッシュ:強力でよりリスキー

意味キャッシュは、正確なテキストではなく意味で一致させることで、多様性の問題に対処します。入ってくるリクエストを埋め込み、その埋め込みが十分近い保存済みリクエストを探し、近いものがあれば、そのキャッシュされた答えを返します。

これは自然言語のワークロードのヒット率を劇的に上げます。言い換えが今や一致するからです。それはまた現実のリスクも持ち込みます。「十分近い」は判断であり、緩く設定された類似度の閾値は、似ているが異なる質問への答えを返します。「サブスクリプションを解約するには?」と「サブスクリプションを変更するには?」の二つのクエリは意味的に近く、実質的に異なります。緩いキャッシュは喜んで間違った方を返すでしょう。意味キャッシュは強力ですが、完全一致の文字通りの安全性をカバレッジと引き換えにします。間違っているがもっともらしい答えが許容できる場所で使い、閾値を保守的に調整し、それが何を返すかを見張りましょう。

プロンプトプレフィックスキャッシュ:プロバイダーレベルの勝利

別の種類のキャッシュは、その前ではなくモデルプロバイダーの内部で動きます。多くのプロバイダーは、長く安定したプレフィックス、つまり大きなシステムプロンプト、固定の指示の組、多くのリクエストにわたって再利用される大きなコンテキストのブロックの処理をキャッシュさせ、繰り返しの作業が呼び出しのたびにやり直されないようにします。

これは、末尾の小さな変化する部分だけを伴って同じ大きなコンテキストを繰り返し送るときに特に価値があり、検索やエージェントのワークフローでよくあります。利点は共有部分のコストとレイテンシの削減で、変化する尾は依然として新しく処理されるので、最終的な答えは古くなりません。仕組みと制約はプロバイダーによって異なるので、AnthropicとOpenAIのドキュメントが、プレフィックスキャッシュがどう構成され何を要するかを確認する場所です。要点は、これが安定したプレフィックスでの計算をキャッシュするのであって最終的な答えではないということで、だからこそ上記の応答キャッシュと競合するのではなくうまく組み合わさります。

何を安全にキャッシュでき、何ができないか

キャッシュの安全性はリクエストが何のためのものかに依存し、その区別を明示する価値があります。

• 安定した、事実的な、リファレンス風の答えはよくキャッシュできます。正しい答えが二つの同一リクエストの間で変わらないなら、再利用は安全で有益です。
• 個別化された、または文脈依存の答えは不用意にキャッシュすると危険です。あるユーザーのデータのために計算された答えを、別のユーザーに決して返してはなりません。個別化されたものすべてのキャッシュキーは、関連する同一性または文脈を含まねばならず、さもなければ重大なデータ漏洩のバグのリスクを冒します。
• 時間に敏感な答えは古くなります。現在の状態に依存するものはすべて消費期限を持ち、キャッシュは有効期限を通じてそれを尊重せねばなりません。
• 意図的に多様な、または創造的な出力は、そもそもキャッシュを望まないかもしれません。ユーザーが毎回新鮮な切り口を期待するなら、キャッシュされた繰り返しはその意義を損ないます。

横断する規則はこうです。キャッシュキーは答えを変えるべきすべてを捉えねばなりません。ユーザー、文脈、パラメータを含め忘れれば、ある人の答えを別の人に返すバグを作ったことになります。

キャッシュを新鮮に保つ

決して期限切れにならないキャッシュは、間違った答えの源になります。二つの仕組みがそれを正直に保ちます。第一に時間ベースの有効期限。基となる情報がどれだけ速く変わるかに応じた寿命を設定し、変わりやすいコンテンツには短く、安定したリファレンス資料には長く。第二に変更時の無効化。キャッシュされた答えの背後にある元データが更新されたら、キャッシュされたエントリをクリアして次のリクエストが再生成するようにせねばなりません。古典的な失敗は、ナレッジベースを更新しながら、古い版から作られた答えを返し続けることです。「永遠」を偶然のデフォルトにさせるのではなく、キャッシュごとに新鮮さのポリシーを意図的に決めましょう。

実践的な導入順序

キャッシュをリスクの増す順に展開しましょう。完全一致キャッシュから始めます。間違った質問に間違った答えを決して返さず、本当に繰り返されるリクエストを即座に捕らえます。大きな安定したコンテキストを再利用する場所にはプロバイダーのプレフィックスキャッシュを加えます。低リスクのコストとレイテンシの勝利だからです。意味キャッシュには、トラフィックを理解し、類似度の閾値を調整し監視できるようになってからだけ手を伸ばしましょう。それが、間違った答えを確信を持って返し得る唯一のアプローチだからです。あらゆる層で、答えに影響するすべてを含むキャッシュキーを作り、出荷する前に新鮮さのポリシーを設定しましょう。古い答えがあなたに恥をかかせた後ではなく。

まとめ

キャッシュはLLMのコストとレイテンシに対する最も直接的なレバーですが、言い回しが多様で答えが個別化または時間に敏感であり得るため、言語モデルはそれを通常のキャッシュより厄介にします。文字通りの安全性のために完全一致キャッシュから始め、再利用されるコンテキストのためにプロバイダーのプレフィックスキャッシュを重ね、もっともらしいが間違った答えが許容できる場所で意味キャッシュを慎重に採用しましょう。何よりも、すべてのキャッシュキーに答えを変えるべきものを捉えさせ、すべてのエントリに新鮮さのポリシーを与えましょう。その規律をもって行えば、キャッシュは大きく安全な勝利です。不用意に行えば、間違った答えを速く返す静かな機械です。