Note
Azure AI 搜尋服務 可透過 Azure 入口網站、REST API 及 Azure SDK 取得。 它同時也是 Foundry IQ 的基礎，這是一個管理式知識層，能將企業內容轉化為可重複使用、權限感知的知識庫，供 Microsoft Foundry 入口網站中的代理使用。
本文回答了關於 Azure 入口網站、REST API 與 Azure SDK 間儲存指標不一致的常見問題。
Azure AI 搜尋服務 中的儲存值會定期收集，可能無法反映即時狀態。 因此，大多數情況下短期內會出現差異。
關於指標如何被收集與報告的背景，請參閱 Monitor Azure AI 搜尋。
為什麼當我刪除或更新文件時，儲存空間不會立刻改變？
當你刪除文件時，Azure AI 搜尋服務 會立即確認刪除，但實體儲存回收則是透過背景合併操作完成。 底層文件會被標記為刪除，並在後續查詢中跳過。 隨著新文件被編入索引，內部索引增加，系統會清理已刪除的文件並回收資源。 這表示你很可能會看到刪除文件和底層資源被釋放之間會有延遲。
文件更新對儲存也有類似影響。 由於文件是不可變的，更新內部是刪除後插入的操作：舊版本標記為已刪除，插入新版本。 在背景合併操作清理舊版本之前，你可能會發現儲存空間暫時增加，而非保持不變。
這些合併作業通常在24至72小時內完成，視服務負載而定。 如果你接近價格等級的儲存限制，規劃大規模更新或文件替換時，請將此暫時增加納入考量。
欲了解更多資訊，請參閱 「刪除搜尋索引中的文件 」及 「目錄中刪除或更新文件的額外負擔」。
為什麼入口網站和API的價值會在同一時間點不同？
Azure 入口網站和 REST API 可能報告不同的值，因為它們有不同的刷新頻率。 具體而言：
- 入口網站總覽頁面的使用量標籤會定期更新，通常每隔幾分鐘一次。
-
GET 服務統計 回傳服務層級計數器，包括
storageSize、vectorIndexSize、 和documentCount。 - GET 索引統計 返回每個索引的統計數據。
服務層級與指數層級的統計數據會獨立且在不同間隔收集。 如果未在相同時間擷取，一個介面的快照集可能不會與另一個介面的快照集對齊。 這種行為是正常的，並不代表有缺陷。
欲了解更多關於監控表面的資訊，請參閱 「監控 Azure AI 搜尋」。
為什麼重建的索引會比內容相似的舊索引大？
重建的索引可能會暫時顯示不同的儲存設定檔，因為背景合併操作還沒清理完舊文件版本。 依服務負載而定，合併通常需時24至72小時。 在此期間，儲存空間可能比預期更大，尤其當您接近所屬價格等級的儲存限制時，這點尤其重要。 在索引活動較低時規劃大規模重建或遷移作業，並在合併完成前監控儲存指標。
即使合併操作完成後，重建索引的最終大小仍可能與原始略有差異。 索引儲存大小是非確定性的，且有幾個因素會影響結果：
- 模式變更，例如新增欄位、分析器或向量配置。
- 影響刪除文件比例的資料匯入與更新方式。
- 向量優化設定，例如量化或存儲壓縮選項。
欲了解更多影響大小的因素，請參閱 Azure AI 搜尋服務 中的向量索引大小與限制，以及服務限制。
為什麼總儲存空間無法與向量索引大小相符？
storageSize 和 vectorIndexSize 測量不同的事物。
-
storageSize是索引的總磁碟佔用量，包含所有資料類型的內容，例如文字、元資料和向量。 -
vectorIndexSize是載入記憶體的向量索引大小限制。 使用詳盡 KNN 演算法的向量欄位，不會耗用向量索引配額，且vectorIndexSize會回報為零。 欲了解更多資訊，請參閱 向量指數大小與限制。
在磁碟上，向量所佔用的總儲存空間可能大於記憶體內向量索引大小，因為 Azure AI 搜尋服務 會為不同用途儲存多份向量欄位。 關於這些副本是什麼以及如何減少磁碟使用，請參見 「從儲存中消除可選向量實例」。
我該如何正確比較指標？
為了判斷差異是真實還是時間偽證，請在一致的UTC時間窗內擷取同一表面的數值：
- 在同一個五分鐘視窗內，呼叫 GET Service Statistics 和 GET Index Statistics。
- 以固定的頻率重複取樣，例如每20到30分鐘一次。
- 在你得出數值沒有收斂之前，至少要比較三個連續的視窗。
- 分別評估
storageSize和vectorIndexSize，因為它們追蹤不同的物理結構。
什麼時候會預期出現差異，什麼時候才是真正的缺陷？
大多數差異是預期中的，且不需介入即可自行解決。 若符合缺陷標準，請依據下一節所述的證據開啟支援請求。
預期分歧
- 你最近進行了大量的索引、更新或刪除操作，目前數值仍在收斂。
- 入口與API的數值有所不同，但重複樣本的差距會縮小。
-
storageSize而且vectorIndexSize不匹配，這是刻意設計的，因為它們測量的標準不同。
可能的缺陷
- 在寫入或刪除活動較低的期間內，差異至少持續三個已對齊的取樣視窗。
- 儘管反覆抽樣，仍未見收斂趨勢。
- 回報的值會導致錯誤的營運決策，例如延遲觸發自動調整，或配額強制執行失敗。
我應該在支援請求中包含什麼？
請在 您的支援申請中包含以下資訊：
- 每個入口網站與 API 樣本的 UTC 時間戳記。
- 來自 GET 服務統計 和 GET 索引統計的原始 JSON 回應。
- 觀察期間內的大致擷取、更新和刪除量。
- 描述營運影響，例如擴展延遲、配額區塊或容量報告錯誤。