Note
Azure AI 搜尋服務 可透過 Azure 入口網站、REST API 及 Azure SDK 取得。 它同時也是 Foundry IQ 的基礎，這是一個管理式知識層，能將企業內容轉化為可重複使用、權限感知的知識庫，供 Microsoft Foundry 入口網站中的代理使用。
Azure AI 搜尋服務 支援兩種定價模式，各自針對不同的工作負載模式設計：
專用：按搜尋單位（SU）計算的固定價格。 您會選取服務層，並根據佈建單位按小時計費。
無伺服器 (預覽版)：以每小時計算單位 (CU/hr) 和索引儲存體每 GB/月計量的取用型定價。
Important
無伺服器開發者層級目前仍處於預覽階段。 此預覽版在沒有服務等級協議的情況下提供，不建議用於生產工作負載。 某些功能可能不被支援或功能受限。 欲了解更多資訊，請參閱 Microsoft Azure 預覽版補充使用條款。
預覽期間尚未啟用無伺服器開發者層級的計費功能。 您的使用預估費用會在 Azure 入口網站和遙測系統中查詢，但在這段初期期間，該使用量不會出現在您的 Azure 帳單上。 Microsoft 會在開始計費前至少提前 30 天通知。 本次預覽期間的帳單延後是暫時的。 無伺服器開發方案屬於付費方案，開始計費後，你必須負擔所產生的任何費用。
無伺服器開發者層級不支援遷移至或遷移至其他定價層級，且部分其他層級的功能在公開預覽階段不被支援。 服務限制、支援功能及價格細節可能會在正式上市前有所變動。
預覽目前僅在美國中西部、瑞士北部及日本東部提供。
欲了解更多關於定價模式與服務層級差異的資訊，請參閱 「選擇定價模式與服務層級」。
無伺服器模型中成本的決定方式
在無伺服器模型中， 效能優化直接影響成本。 成本與工作負載執行直接相關：
- 查詢與索引會消耗計算量，計算單位為每小時計算單位（CU/h）。
- 儲存空間是根據磁碟上的索引大小分開計費的。
- 當服務閒置且沒有主動查詢或索引時，計算使用量為零。 不收取預留容量或最低容量費用。
無伺服器定價模式對於流量變動、間歇性或不可預測的工作負載最具成本效益，因為在這種情況下，預先佈建的容量可能無法被充分利用。
Important
您的每小時計算單位 (CU/h) 費用不包含語意排名器、代理式擷取、影像擷取和技能執行。 這些功能會分開計費。
了解計算單元（CU）
計算單元（CU）代表在無伺服器模型中執行搜尋與索引操作所需的系統資源。 CU 成本主要由 CPU、記憶體與 IO 利用率驅動，其次則由索引大小與文件有效載荷大小決定，使用量以每小時運算單位（CU/h）計費。
計算成本會隨以下項目調整：
- 查詢複雜度
- 指數規模（GB）與結構
- 文件有效載荷大小（KB）
- 欄位數量與檢索結果
不同營運的成本輪廓不同：
- 查詢：成本低。 依照 ID 檢索單一文件是最有效率的操作。
- 關鍵字搜尋：低成本。 文字搜尋使用反向索引，並針對速度與低運算資源使用量進行最佳化。
- 向量搜尋：高成本。 向量查詢計算成本高，因為它們需要跨高維嵌入進行相似度計算。 與關鍵字搜尋相比，它們消耗的運算量顯著增加。
- 混合式搜尋：結合關鍵字和向量搜尋的成本，因為每個查詢都會執行這兩個管線，另加 Reciprocal Rank Fusion (RRF) 用於合併結果的少量額外負荷。
監控運算使用情況
監控運算消耗有助於你識別昂貴的操作、優化查詢模式並估算成本。 每個請求的運算單元（CU）成本會以浮點數的形式在 x-ms-request-charge HTTP 回應標頭中回傳。 使用此標頭來識別昂貴操作並優化查詢模式。 你可以透過檢查 Azure 監視器 中的 HTTP 回應標頭和操作事件來追蹤每個請求的 CU 成本。 欲了解更多關於可用監控資料類型及分析方法的指引，請參閱「監控 Azure AI 搜尋服務」。
-
標頭：
x-ms-request-charge: <value> - 值：一個浮點數，代表所消耗的 CU。
範例：
Status: 200 OK
Content-Type: application/json
x-ms-request-charge: 12.45
在此範例中，請求消耗了 12.45 個運算單元。 你可以利用這個值來辨識高成本操作，並比較不同查詢模式的相對成本。
要檢視無伺服器搜尋服務的歷史計算消耗，請使用 Azure 入口網站中的 Azure 監視器 指標：
- 前往您的搜尋服務。
- 選取 [計量]。
- 選擇 + 新增指標。
- 從指標清單中，選擇 計算單位使用量。
- 利用圖表分析使用趨勢，並找出計算量增加的時期。
監控整體使用情況有助於你了解整體服務成本，並找出消耗最多運算資源的工作負載。 有關可用監測指標的說明，請參見 監測資料參考。 你可以使用 Azure 監視器 日誌追蹤累積的 CU 使用情況，並與查詢量和工作負載變化做關聯。
設定計算使用警報
你可以在 Azure 入口網站建立警示規則，當運算消耗達到指定門檻時收到通知。
- 請前往搜尋服務中的 警示 。
- 選取 + 建立警示規則。
- 在 條件中，選擇 「計算單位使用量 」作為訊號。
- 定義警報邏輯。 例如，當總使用量超過指定值時觸發。
- 設定 動作，例如電子郵件、簡訊或 webhook 通知。
- 完成剩餘步驟後，選擇 檢視 + 建立。
警示幫助你主動應對突發的使用量激增並管理成本。
估計無伺服器成本
Azure 價格計算器與基於搜尋單元（SU）的容量規劃指引不適用於使用無伺服器定價模型的服務。
估算無伺服器成本：
- 索引代表性樣本資料。
- 執行典型的索引和查詢工作負載。
- 記錄
x-ms-request-charge每個操作回傳的值。 - 使用 Azure 監視器 指標來衡量隨時間的總體使用情況。
- 根據預期的生產流量推算成本。
由於同一請求對相同資料執行通常產生相似的計算消耗，代表性工作負載能提供可靠的成本估算基礎。
無伺服器使用量會持續測量並彙總以計費。 運算用量會在每分鐘內持續追蹤，且僅在使用運算資源時才會記錄。
在估算成本時，使用請求收費值來了解個別營運的成本，並用 Azure 監視器 指標來了解整體服務消耗模式。
計費是根據總體運算使用量，而非個別請求。 使用量以一分鐘為間隔計量，並向上取整至每分鐘最接近的 0.25 CU。 這些一分鐘的使用間隔會在一小時內累積，以決定可計費的每小時CU金額。 在內部，系統會將用量從毫運算單位（mCU）彙總為運算單位（CU），並換算為用於計費報告的每小時用量。
不同的運算消耗的運算量也不同。 通常：
- 關鍵字搜尋通常使用最少的運算資源。
- 向量搜尋通常比關鍵字搜尋消耗更多運算資源。
- 混合式搜尋結合關鍵字與向量搜尋執行，因此通常比單一技術使用更多的運算資源。
實際計算消耗取決於查詢複雜度、索引大小、資料量、向量配置及回傳結果數量等因素。 監控請求費用與總體使用指標，有助於您識別優化機會，並更準確預測生產成本。
透過優化降低計算成本
高效的查詢與索引設計降低運算消耗並降低成本。
最佳化您的結構描述
你的索引結構決定基線運算與儲存成本：
- 限制欄位屬性：僅在必要時啟用屬性（可搜尋、可篩選、面表、可排序）。 每個屬性都會增加索引大小與索引成本。
- 扁平化複雜型別：盡可能將巢狀的 JSON 結構映射到簡單的欄位或集合。
-
僅篩選或僅排序欄位請設定 retrievable=false：若某欄位用於篩選或排序，但不需要在結果中回傳，請保持該欄位索引並設定
retrievable=false以降低磁碟儲存空間及每 GB/月儲存成本。 - 盡可能使用僅可檢索的欄位：例如，僅用於顯示的欄位（如圖片網址）不應被搜尋。
- 減少向量維度：高維向量會增加儲存與查詢成本。 適當時使用較小的嵌入模型或量化。
- 在索引前盡量減少文件有效載荷大小：較大的文件編索引成本越高。 在將文件送入索引前，移除不必要的欄位、裁剪長文字並剔除 HTML。
優化索引請求
你如何將資料傳送到索引，會影響成本與吞吐量：
盡可能使用較大的批次：批次索引可將網路與處理成本分攤到更多文件上，從而降低每次請求的開銷。 一般而言，最多 ~1,000 份文件或 ~16 MB 的批次比許多小型請求更具 CU 效率。 不過，最佳批次大小取決於你的工作量。 測試以平衡吞吐量、延遲和可靠性。
僅索引新資料或變更資料：盡量避免全面重新索引。 僅傳送新增與更新可減少處理的文件數量，降低計算成本並提升擷取速度。
使用變更偵測進行增量索引：在重新處理內容前，先偵測哪些變更。 增量索引避免了對未修改文件重複工作，並降低重新處理成本。
除非需要，否則跳過影像擷取：影像擷取會增加額外的處理工作，且可能成為另一個成本驅動因素。 只在需要圖片內容的文件或工作流程時開啟。
將技能鎖定於相關領域與文件：將擴充技能的範圍聚焦於所需的特定領域或文件。 避免在不需要擴充的內容上執行技能，尤其是下游未使用輸出時。
考慮指數規模的成長：盡可能建立較小的指數。 隨著索引成長，索引成本增加，因為必須儲存和維護更多資料，且操作需要更多運算。 對於非常龐大的資料集，可以考慮將資料分割到多個索引，以協助管理效能與成本。 雖然成本隨指數規模增加，但其增長是次線性的。 較大的指數每次操作成本較高，但不會成比例增加。
更多指導請參見提升Azure AI 搜尋服務表現技巧。
優化你的查詢
查詢設計是變動成本的主要驅動因素：
用於
$select限制回傳欄位：此方法可減少序列化所需的有效載荷大小與計算量。GET /docs?search=test&$select=id,title,url使用
searchFields限制搜尋文字的範圍：將查詢時的比對限制在與該情境相關的重要欄位。 每增加一個可搜尋欄位，查詢工作量增加，並可能增加 CU/h。偏好精確匹配或簡單關鍵字查詢：模糊、通配字、正則表達式及前綴式查詢會強制廣泛掃描索引，並大幅消耗更多 CU/h。 只有在需要部分匹配行為時才使用，並盡可能選擇精確匹配或較簡單的關鍵字查詢。
盡可能使用查詢取代搜尋：依 ID 檢索文件比執行搜尋查詢更有效率。 如果你知道文件 ID，請使用查找，而不要使用搜尋查詢。 查詢更有效率，因為它們直接以鍵檢索文件，而搜尋查詢則會啟動完整的查詢流程（解析、索引遍歷、評分與排名），這會增加計算成本。
避免深度分頁（
$skip）：較大$skip的值會增加計算，因為引擎必須處理並排名所有先前的結果（例如，$skip=5000需要評分至少 5,000 份未回傳的文件）。 這會浪費運算量（CU）並增加成本。 相反地，請使用篩選器縮小結果範圍，並限制回傳的數量。$top將$top調整為適合您 UI 顯示的大小。 例如，$top=10成本較低$top=50，因為評分與回傳的結果較少。 只請求應用程式所需的結果數量，避免需要引擎處理大量未使用的結果的模式。減少面數與面範圍：只請求介面中顯示的面，並盡量保持每個面
count值最低。 分面需要針對每次查詢執行聚合，而數量過高會增加運算成本。用於
search.in篩選：當以 ID 或值列表篩選時，請使用 該search.in函數而非多個or條件（例如id eq '1' or id eq '2'）。 此方法更有效率，並降低計算負擔。 您也應該避免將高基數欄位 (具有大量唯一值的欄位，例如唯一 ID 或自由文字描述) 標示為可篩選或可 Facet，除非必要，因為這會增加索引大小和查詢成本。
最佳化您的管理要求
除了查詢與索引操作外，Azure AI 搜尋服務 還包含物件層級及服務層級的管理操作（例如擷取索引結構或服務統計資料）。 這些請求的每次請求費用是固定的。 雖然每個請求成本低廉，但重複或不必要的呼叫會隨時間累積，並增加整體運算使用量。
- 避免過多的管理要求：請在用戶端快取中繼資料（例如索引結構描述），而不是反覆擷取這些資料。 例如，在每次寫入操作前擷取索引結構會產生不必要的成本。 在無伺服器模型中，此模式會直接增加計算費用；而在 Dedicated 服務中，固定小時計費通常會隱藏其影響。
優化向量成本
向量工作負載通常是無伺服器定價模型中成本最高的部分，因為它們同時影響計算單元（查詢與索引）及儲存空間（磁碟上的向量大小）。 為了降低成本，優化向量的儲存方式和查詢方式。
優化向量儲存與結構
向量場能顯著增加索引大小與索引成本。 請使用以下技術來降低儲存開銷：
利用壓縮來減少向量大小：應用量化以減少儲存佔用，且對相關性的影響最小。 例如，純量量化可將向量儲存量減少多達4×且對搜尋品質影響極小。
不需要時停用向量儲存：如果你只需要搜尋向量而非檢索，請在向量欄位上設 stored=false。 這避免了將原始向量儲存在索引中，降低儲存成本，同時不影響查詢行為。
盡可能使用較小的嵌入維度：高維向量會增加儲存與查詢成本。 對於非關鍵工作負載，使用較小的嵌入模型（例如，384或768維度取代1536維度）以降低成本。
優化向量查詢執行
向量查詢計算密集，因為它們需要在高維資料結構上進行相似性計算。
選擇性地使用混合式搜尋：混合式查詢同時執行關鍵字與向量檢索。 只有在必要時才使用。
在向量查詢前套用篩選器：在向量搜尋前縮小候選集範圍，以減少處理的資料量。 請參閱向量查詢中的篩選機制。
透過減少使用量來降低成本
無伺服器模式僅對已消耗的資源收費。 當沒有請求時，運算使用量會相應下降。
為了降低使用成本：
- 只有在需要時才執行查詢。
- 避免重複或過於頻繁的請求。
- 監控使用情況並根據需求調整工作負載。
Tip
相同的查詢會因服務處於預熱或冷啟動狀態，而呈現不同的延遲和 CU 特性。 在一段時間沒有讀取或寫入流量後，無伺服器計價模型中的運算用量會降為零。 下一個請求可能會有較高的延遲，並在資料路徑預熱期間消耗更多 CU。 較大的索引通常比較小的索引需要更長的預熱時間，因此冷啟動效應在較大的服務上通常更為明顯。
將儲存體成本最佳化
儲存裝置依據磁碟索引大小按 GB 月計費，該索引大小可能超過原始資料大小。 降低儲存成本：
- 移除未使用的索引。
- 最小化儲存欄位。
- 設計綱要時，請將儲存額外負擔納入考量。
- 建議器請有選擇性地使用，因為它們能大幅增加儲存空間。
如需了解向量專屬技術（壓縮、剪枝及儲存設定），請參閱 最佳化向量儲存與處理。
關於儲存與查詢效能權衡的更多指引，請參見