Azure AI 検索 でのストレージとメトリックの不一致のトラブルシューティング

Note

Azure AI 検索は、Azure ポータル、REST API、およびAzure SDKから使用できます。 また、Foundry IQ は、エンタープライズ コンテンツを、Microsoft Foundry ポータルのエージェントの再利用可能なアクセス許可に対応したナレッジ ベースに変換するマネージド ナレッジ レイヤーです。

この記事では、Azure portal、REST API、Azure SDK 全体で矛盾しているように見えるストレージ メトリックに関する一般的な質問に回答します。

Azure AI 検索 のストレージ値は定期的に収集され、リアルタイムの状態が反映されない場合があります。 そのため、ほとんどのシナリオで短期的な不一致が予想されます。

メトリックの収集と報告方法の背景については、 Azure AI 検索 の監視に関するページを参照してください。

ドキュメントを削除または更新したときにストレージがすぐに変更されないのはなぜですか?

ドキュメントを削除すると、Azure AI 検索はすぐに削除を確認しますが、物理記憶域の再利用はバックグラウンドマージ操作によって行われます。 基になるドキュメントは削除済みとしてマークされ、後続のクエリ中にスキップされます。 新しいドキュメントのインデックスが作成され、内部インデックスが大きくなると、削除されたドキュメントがクリーンアップされ、リソースが再利用されます。 つまり、ドキュメントを削除してから、基になるリソースが解放されるまでの遅延が発生する可能性があります。

ドキュメントの更新は、ストレージにも同様の影響を与えます。 ドキュメントは不変であるため、更新は内部的には削除および挿入操作です。古いバージョンは削除済みとしてマークされ、新しいバージョンが挿入されます。 バックグラウンドのマージ操作によって古いバージョンがクリーンアップされるまで、ストレージが同じではなく一時的に増加する場合があります。

通常、これらのマージ操作は、サービスの負荷量に応じて 24 ~ 72 時間以内に完了します。 価格レベルのストレージ制限に近い場合は、大規模な更新プログラムまたはドキュメントの置換を計画するときに、この一時的な増加を考慮してください。

詳細については、「検索インデックス内のドキュメントの削除」および「インデックス内のドキュメントの削除または更新のオーバーヘッド」を参照してください。

ポータルと API の値が同じ時点で異なるのはなぜですか?

Azure portal API と REST API は、更新頻度が異なるため、異なる値を報告する場合があります。 具体的な内容は次のとおりです。

  • ポータルの [概要] ページの [使用状況] タブは、通常は数分ごとに定期的に更新されます。
  • GET サービス統計は 、 storageSize、 vectorIndexSize、 documentCountを含むサービス レベルのカウンターを返します。
  • GET インデックス統計 は、インデックスごとのカウンターを返します。

サービス レベルとインデックス レベルの統計は、個別に、異なる間隔で収集されます。 一方のサーフェスのスナップショットが同時にキャプチャされなかった場合、一方のサーフェスのスナップショットが他方のスナップショットと一致しない可能性があります。 この動作は正常であり、欠陥を示すわけではありません。

監視サーフェスの詳細については、「 Azure AI 検索 の監視」を参照してください。

再構築されたインデックスが、類似したコンテンツを持つ古いインデックスよりも大きいのはなぜですか?

バックグラウンドマージ操作で古いドキュメント バージョンのクリーンアップが完了していないため、再構築されたインデックスに一時的に別のストレージ プロファイルが表示されることがあります。 サービスの負荷によっては、通常、これらのマージには 24 ~ 72 時間かかります。 この期間中、ストレージは予想よりも大きく表示されることがあります。これは、価格レベルのストレージ制限に近い場合に特に重要です。 インデックス作成アクティビティの低下期間中に大規模な再構築または移行操作を計画し、マージが完了するまでストレージ メトリックを監視します。

マージ操作が完了した後でも、再構築されたインデックスの最終的なサイズが元のサイズと若干異なる場合があります。 インデックスストレージサイズは非決定的であり、結果に影響するいくつかの要因があります。

  • フィールド、アナライザー、ベクター構成の追加など、スキーマの変更。
  • 削除されたドキュメントの比率に影響するインジェストパターンと更新パターン。
  • 量子化やストレージ削減オプションなどのベクター最適化設定。

サイズに影響を与える要因の詳細については、Azure AI 検索 の ベクター インデックスのサイズと制限 と サービスの制限に関するページを参照してください。

ストレージの合計がベクター インデックス サイズと一致しないのはなぜですか?

storageSize と vectorIndexSize は、さまざまなことを測定します。

  • storageSize は、テキスト、メタデータ、ベクターなど、すべてのデータ型のコンテンツを含む、インデックスのディスク占有領域の合計です。
  • vectorIndexSize は、メモリに読み込まれるベクター インデックスのサイズの制限です。 完全な KNN アルゴリズムを使用するベクター フィールドは、ベクター インデックス クォータを使用せず、 vectorIndexSizeにゼロを報告します。 詳細については、「 ベクター インデックスのサイズと制限」を参照してください。

ディスク上では、ベクターによって消費されるストレージの合計がメモリ内ベクター インデックス サイズよりも大きくなる可能性があります。これは、Azure AI 検索 が目的に応じてベクター フィールドの複数のコピーを格納するためです。 これらのコピーの内容とディスクの使用量を減らす方法については、「 ストレージからオプションのベクター インスタンスを削除する」を参照してください。

メトリックを正しく比較する方法

不一致が実際の成果物かタイミングアーティファクトかを判断するには、一貫性のある UTC 時間枠内で同じサーフェスから値をキャプチャします。

  1. 同じ 5 分以内に GET サービス統計 と GET インデックス統計 を呼び出します。
  2. 20 ~ 30 分ごとなど、固定の周期でサンプリングを繰り返します。
  3. 値が収束していないと結論付ける前に、少なくとも 3 つの連続するウィンドウを比較します。
  4. storageSizeは異なる物理構造を追跡するため、vectorIndexSizeとは別に評価します。

不整合が予想される場合と、実際に欠陥と判明する場合の判断はいつですか？

ほとんどの不一致が予想され、介入なしで解決されます。 欠陥条件が満たされている場合は、次のセクションで説明する証拠を使用してサポート要求を開きます。

予期される相違

  • 最近、大量のインデックス作成、更新、または削除が実行され、値は収束しています。
  • ポータルと API の値は異なりますが、繰り返しのサンプル間でギャップが狭くなります。
  • storageSize と vectorIndexSize が一致しません。これは設計上、異なるものを測定するためです。

考えられる欠陥

  • この不一致は、書き込みまたは削除アクティビティが少ない間に、少なくとも 3 つの調整されたサンプリング ウィンドウで保持されます。
  • サンプリングを繰り返しても収束傾向は表示されません。
  • 報告された値は、自動スケールの開始が遅れることやクォータの適用に失敗するなど、誤った運用判断につながります。

サポート リクエストには何を含める必要がありますか?

サポート リクエストに次の情報を含めます。

  • 各ポータルと API サンプルの UTC タイムスタンプ。
  • GET サービス統計およびGET インデックス統計からの未加工の JSON 応答。
  • 観察期間中のおおよその取り込み、更新、および削除のボリューム。
  • スケーリングの遅延、クォータ ブロック、不適切な容量レポートなど、運用上の影響の説明。

関連するコンテンツ

  • Last updated on