API Gateway:キャッシュ

セマンティックキャッシュの概念

メリット

• デュアルモードキャッシュシステム：2 つのキャッシュモードから選択し、ビジネスニーズに基づいてマッチングしきい値を動的に調整する柔軟性を提供します。

  1. 完全一致キャッシュ：Redis のキーバリューストレージアーキテクチャに基づいており、同一のリクエストに対してミリ秒レベルの応答を提供します。

  2. セマンティックキャッシュ：DashVector ベクトルデータベース (Alibaba Cloud ベクトル検索サービスの一部) を使用して、セマンティックに類似したリクエストをインテリジェントにマッチングします。類似度のしきい値は調整可能で、従来の文字列マッチングの制限を克服します。

• 冗長な計算の削減：同一の AI リクエストに対して、システムはキャッシュデータを直接返し、LLM への冗長な呼び出しを回避します。

• パフォーマンスの向上：キャッシュから結果を迅速に取得することで、AI ゲートウェイは応答時間とバックエンドサーバーの負荷を大幅に削減します。セマンティックキャッシュは「意図レベル」の応答を可能にし、ユーザー満足度とエクスペリエンスを大幅に向上させます。

• シナリオカバレッジの拡大：カスタマーサービスシステムやナレッジベースクエリなどの標準的なシナリオに加え、「明日の天気」や「今後 24 時間の天気予報」などの自然言語命令の変種もサポートします。

• ログモニタリング：キャッシュヒット率のメトリックを分析できます。

操作手順

1. AI ゲートウェイコンソールにログインし、[インスタンス] を選択します。トップメニューバーでリージョンを選択し、ターゲットインスタンスの ID をクリックします。

2. 左側のナビゲーションウィンドウで [モデル API] を選択し、ターゲット API 名をクリックして [API 詳細] ページに移動します。

3. Policies and Plug-ins をクリックし、キャッシュ スイッチを有効にして、パラメーターを設定します。

   AI ゲートウェイはキャッシュ機能をアップグレードし、Semantic と Exact Match をサポートするようになりました。戦略の比較 に基づいて、適切なキャッシュモードを選択します。

   セマンティックキャッシュ

   重要

   リクエストに x-higress-skip-ai-cache: on ヘッダーが含まれている場合、リクエストはキャッシュをバイパスします。リクエストは直接バックエンドサービスに転送され、応答はキャッシュされません。

   • Cache Key Strategy：デフォルトのオプションである Latest Query Only を選択するか、要件に応じて Integrate Historical Queries を選択します。

   • テキストベクトル化設定：

     • AI Service：既存の AI サービスを選択します。AI サービスがない場合は、[サービスを作成] をクリックして作成します。

     • Model Name：使用したいモデルの名前を選択します。

     • Timeout Period：タイムアウト期間を設定します。デフォルト値は 5,000 ms です。

   • ベクトルデータベース設定：

     • Service Provider：DashVector を有効化していない場合は、[コンソールへ移動] をクリックしてサービス有効化ページを開きます。する必要があります。後で使用するためにコレクション名を記録しておきます。

       重要

       コレクションを作成する際は、距離メトリックとして Cosine を選択し、ベクトル次元がテキスト埋め込みモデルの次元と一致することを確認してください。Model Studio プラットフォーム上のテキスト埋め込みモデルの出力ベクトル次元を確認するには、「テキストとマルチモーダル埋め込み」をご参照ください。

     • Service URL：ご利用の DashVector サービスエンドポイントを入力します。

     • コレクション名：作成したコレクションの名前を入力します。

     • API キー：アクセス認証情報です。詳細については、「API キーの管理」をご参照ください。

     • Vector Similarity Threshold：この値は、クエリがキャッシュされたコンテンツとどの程度厳密に一致するかを決定します。範囲は 0 から 1 で、推奨値は 0.8 または 0.9 です。値が高いほど、セマンティックな類似性が高いことを示します。詳細については、「ベクトル類似度しきい値の設定」をご参照ください。

     • Timeout Period：タイムアウト期間を設定します。デフォルト値は 3,000 ms です。

   完全一致キャッシュ

   重要

   • Redis コンソールに移動し、ゲートウェイインスタンスの VPC CIDR ブロックをホワイトリストに追加します。

   • リクエストに x-higress-skip-ai-cache: on ヘッダーが含まれている場合、リクエストはキャッシュをバイパスします。リクエストは直接バックエンドサービスに転送され、応答はキャッシュされません。

   • Cache Key Strategy：デフォルトのオプションである Latest Query Only を選択するか、要件に応じて Integrate Historical Queries を選択します。

   • Redis キャッシュ設定：

     • Redis service URL：ご利用の Redis サービス URL を入力します。

     • Port Number：ご利用のポート番号を入力します。

     • Access Method：Redis サービスへのアクセス方法を選択します。オプションは [アカウント+パスワード]、[パスワードのみ]、[パスワードなし] です。

     • Database Account：[アカウント+パスワード] のアクセス方法を選択した場合は、データベースアカウントを入力します。

     • Database Password：パスワードが必要なアクセス方法を選択した場合は、データベースパスワードを入力します。

     • Database No.：指定されたデータベース番号。

     • Duration (seconds)：デフォルトのキャッシュ期間は 1,800 秒です。この期間中、API が同一の AI リクエストを受信した場合、LLM は呼び出されず、キャッシュされた応答が直接返されます。

4. 設定を確認し、Save をクリックします。

ベクトル類似度しきい値の設定

キャッシュヒット率

次の検索文を使用して、ゲートウェイレベルでキャッシュヒット率をクエリできます。

cluster_id:{your-gatewayId} and inner-ai-cache-{your-gatewayId} | SELECT 
SUM(CASE WHEN content LIKE '%cache hit for key%' OR content LIKE '%key accepted%' THEN 1 ELSE 0 END) AS hit_count,
SUM(CASE WHEN content LIKE '%cache miss for key%' OR content LIKE '%score not meet the threshold%' THEN 1 ELSE 0 END) AS miss_count,
SUM(CASE WHEN content LIKE '%cache hit for key%' OR content LIKE '%key accepted%' THEN 1 ELSE 0 END) * 100.0 / 
NULLIF(SUM(CASE WHEN content LIKE '%cache hit for key%' OR content LIKE '%key accepted%' OR content LIKE '%cache miss for key%' 
           OR content LIKE '%score not meet the threshold%' THEN 1 ELSE 0 END), 0) AS hit_rate

• {your-gatewayId} をご利用のゲートウェイインスタンス ID に置き換えます。最初の置き換えではプレフィックス gw- を保持する必要がありますが、2 回目の置き換えでは保持しないことに注意してください。キャッシュスイッチボタンからプラグインログクエリシステムにアクセスすると、クエリボックスには自動的に `cluster_id` フィルターが含まれます。この場合、フィルターの後に残りのクエリ文を貼り付けるだけで済みます。[モニタリング (AI キャッシュ)] ページで [ログの表示] をクリックしてログクエリページに移動します。ログソースは apig-plugin-log です。前述のクエリ文をクエリバーに入力して実行します。

• クエリはキャッシュヒット率を返します。

  例えば、結果は `hit_count` (キャッシュヒット) が 7、`miss_count` (キャッシュミス) が 6、`hit_rate` (ヒット率) が約 53.85% であることを示す場合があります。

例

• 完全一致キャッシュが有効な場合、同一のクエリのみがマッチングされます。例えば、ユーザーが「あなたは誰ですか？」というクエリを送信し、それがキャッシュから提供されない場合、モデルは通常どおりトークンを消費します (入力トークン：127、出力トークン：40)。同じクエリが完全一致キャッシュにヒットした場合 (from-cache で示される)、入力と出力の両方のトークンは 0 になり、キャッシュされた結果が直接返されます。これにより、トークンの消費が大幅に削減されます。

• セマンティックキャッシュが有効な場合、セマンティックに類似したクエリもマッチングできます。セマンティックな類似度がしきい値を下回るクエリはマッチングされません。

  セマンティックキャッシュヒットが発生すると、キャッシュされた応答が類似の質問に再利用されます。入力と出力の両方のトークンは 0 で、モデル推論リソースを消費しません。

  例えば、ユーザーが Where can my package be delivered today? (荷物は今日どこに配達されますか？) と尋ね、このクエリがキャッシュされた質問とセマンティックに大きく異なる場合、キャッシュミスが発生します。その後、`qwen-max` モデルが応答を生成し、通常どおりトークンを消費します。