Azure AI 搜尋服務中的 Vector indexes

附註

Azure AI 搜尋服務可透過 Azure 入口網站、REST API 及 Azure SDK 取得。它同時也是 Foundry IQ 的基礎，這是一個管理式知識層，能將企業內容轉化為可重複使用、權限感知的知識庫，供 Microsoft Foundry 入口網站中的代理使用。

向量是高維度內嵌，以數學方式表示文字、影像和其他內容。 Azure AI 搜尋服務在場層級儲存向量，允許向量與非向量內容共存於相同的 search index。

當您定義向量欄位和向量組態時，搜尋索引會變成 向量索引 。要填充向量場，你可以將預先計算的嵌入推入，或使用內建的 Azure AI 搜尋服務功能 integrated vectorization，在索引時產生嵌入。

在查詢時，索引中的向量字段會啟用相似度搜尋，其中系統會擷取向量最類似於向量查詢的檔。您可以單獨針對相似度比對使用向量搜尋，或使用混合式搜尋來尋找相似度和關鍵詞比對的組合。

本文涵蓋建立和管理向量索引的重要概念，包括：

向量擷取模式
內容（向量欄位和組態）
實體資料結構
基本作業

小提示

想要立即開始使用嗎？請參閱建立向量索引。

向量擷取模式

Azure AI 搜尋服務支援兩種向量檢索模式：

傳統搜尋。此模式會使用搜尋列、查詢輸入和呈現的結果。在查詢執行期間，搜尋引擎或您的應用程式程式代碼會將使用者輸入向量化。接著，搜尋引擎會對索引中的向量字段執行向量搜尋，並制定您在用戶端應用程式中轉譯的回應。

在 Azure AI 搜尋服務中，結果會以扁平的列集回傳，你可以選擇要包含哪些欄位。雖然搜尋引擎會比對向量，但是您的索引應該包含非向量的、可供人類閱讀的內容，以填入搜尋結果。傳統搜尋同時支援向量查詢和混合式查詢。
行性搜尋。語言模型利用 Azure AI 搜尋服務的資料來回應使用者查詢。協調流程層通常會協調提示並維護內容，將搜尋結果饋送至 GPT 等聊天模型。此模式是以擷取增強世代（RAG）架構為基礎，其中搜尋索引會提供基礎數據。

向量索引的架構

向量索引的架構需要下列項目：

名稱
索引鍵欄位 (字串)
一或多個向量欄位
向量組態

非函式欄位並非必要，但建議將它們納入混合式查詢，或傳回不經過語言模型的逐字內容。如需詳細資訊，請參閱建立向量索引。

您的索引架構應該反映向量擷取模式。本節主要涵蓋傳統搜尋的字段組合，但也提供產生式搜尋的架構指引。

基本向量欄位設定

向量欄位具有唯一的數據類型和屬性。以下是欄位集合中的向量欄位外觀：

{
    "name": "content_vector",
    "type": "Collection(Edm.Single)",
    "searchable": true,
    "retrievable": true,
    "dimensions": 1536,
    "vectorSearchProfile": "my-vector-profile"
}

向量欄位只支援特定資料類型。最常見的類型是 Collection(Edm.Single)，但使用窄型別可以節省儲存空間。

向量字段必須是可搜尋和可擷取的，但無法篩選、分面化或排序。它們也不能有分析器、正規化程式或同義字對應指派。

屬性 dimensions 必須設定為內嵌模型所產生的內嵌數目。例如，text-embedding-ada-002 會為每個文字區塊產生 1,536 個內嵌。

向量欄位是使用 在向量搜尋配置檔中指定的演算法來編制索引，該演算法定義於索引的其他地方，但在此範例中不會顯示。如需詳細資訊，請參閱新增向量搜尋組態。

基本向量工作負載的欄位集合

向量索引需要的不僅僅是向量欄位。例如，所有索引都必須有索引鍵欄位，如 id 下列範例所示：

"name": "example-basic-vector-idx",
"fields": [
  { "name": "id", "type": "Edm.String", "searchable": false, "filterable": true, "retrievable": true, "key": true },
  { "name": "content_vector", "type": "Collection(Edm.Single)", "searchable": true, "retrievable": true, "dimensions": 1536, "vectorSearchProfile": null },
  { "name": "content", "type": "Edm.String", "searchable": true, "retrievable": true, "analyzer": null },
  { "name": "metadata", "type": "Edm.String", "searchable": true, "filterable": true, "retrievable": true, "sortable": true, "facetable": true }
]

其他欄位，例如 content 欄位，提供人類可讀的 content_vector 對等欄位。如果您只針對回應公式使用語言模型，您可以省略非向量內容欄位，但直接將搜尋結果推送至用戶端應用程式的解決方案應該具有非向量內容。

元數據欄位對於篩選很實用，特別是如果他們包含源文檔的原點資訊。雖然無法直接對向量欄位進行篩選，但可設定預先篩選、後置篩選或嚴格後置篩選 (預覽) 模式，在向量查詢執行前後執行篩選。

匯入精靈產生的結構描述

我們建議使用 匯入資料 精靈進行評估與概念驗證測試。本節中的範例結構描述是由該精靈產生的。

此精靈會將內容分成較小的搜尋檔，這有利於使用語言模型來制定回應的RAG應用程式。區塊化可協助您保持在語言模型的輸入限制和語意排序器的標記限制內。它還通過將查詢與從多個父文件提取的區塊進行匹配，以提高相似性搜索的精確度。如需詳細資訊，請參閱針對向量搜尋解決方案將大型文件區塊化。

針對下列範例中的每個搜尋檔，會有一個區塊標識碼、父標識符、區塊、標題和向量欄位。精靈：

將 base64 編碼的 Blob 元資料（path）填入 chunk_id 和 parent_id 欄位。
從 Blob 內容擷取chunk字段，從 Blob 名稱擷取title字段。
透過呼叫你提供的 Azure OpenAI 嵌入模型來建立 vector 欄位，將 chunk 欄位向量化。在此過程中，只有向量場會被完全生成。

"name": "example-index-from-import-wizard",
"fields": [
  { "name": "chunk_id", "type": "Edm.String", "key": true, "searchable": true, "filterable": true, "retrievable": true, "sortable": true, "facetable": true, "analyzer": "keyword"},
  { "name": "parent_id", "type": "Edm.String", "searchable": true, "filterable": true, "retrievable": true, "sortable": true},
  { "name": "chunk", "type": "Edm.String", "searchable": true, "filterable": false, "retrievable": true, "sortable": false},
  { "name": "title", "type": "Edm.String", "searchable": true, "filterable": true, "retrievable": true, "sortable": false},
  { "name": "vector", "type": "Collection(Edm.Single)", "searchable": true, "retrievable": true, "dimensions": 1536, "vectorSearchProfile": "vector-1707768500058-profile"}
]

產生式搜尋的架構

如果您要為 RAG 和聊天樣式應用程式設計向量記憶體，您可以建立兩個索引：

您為其編製索引和向量化的靜態內容之一。
可用於提示流程中的交談之一。

為說明用途，本節使用 chat-with-your-data-solution-accelerator 建立 chat-index 與 conversations 索引。

下列來自chat-index的欄位支援生成式搜尋體驗：

"name": "example-index-from-accelerator",
"fields": [
  { "name": "id", "type": "Edm.String", "searchable": false, "filterable": true, "retrievable": true },
  { "name": "content", "type": "Edm.String", "searchable": true, "filterable": false, "retrievable": true },
  { "name": "content_vector", "type": "Collection(Edm.Single)", "searchable": true, "retrievable": true, "dimensions": 1536, "vectorSearchProfile": "my-vector-profile"},
  { "name": "metadata", "type": "Edm.String", "searchable": true, "filterable": false, "retrievable": true },
  { "name": "title", "type": "Edm.String", "searchable": true, "filterable": true, "retrievable": true, "facetable": true },
  { "name": "source", "type": "Edm.String", "searchable": true, "filterable": true, "retrievable": true  },
  { "name": "chunk", "type": "Edm.Int32", "searchable": false, "filterable": true, "retrievable": true },
  { "name": "offset", "type": "Edm.Int32", "searchable": false, "filterable": true, "retrievable": true }
]

conversations 中的下列欄位支援協調流程與聊天記錄：

"fields": [
    { "name": "id", "type": "Edm.String", "key": true, "searchable": false, "filterable": true, "retrievable": true, "sortable": false, "facetable": false },
    { "name": "conversation_id", "type": "Edm.String", "searchable": false, "filterable": true, "retrievable": true, "sortable": false, "facetable": true },
    { "name": "content", "type": "Edm.String", "searchable": true, "filterable": false, "retrievable": true },
    { "name": "content_vector", "type": "Collection(Edm.Single)", "searchable": true, "retrievable": true, "dimensions": 1536, "vectorSearchProfile": "default-profile" },
    { "name": "metadata", "type": "Edm.String", "searchable": true, "filterable": false, "retrievable": true },
    { "name": "type", "type": "Edm.String", "searchable": false, "filterable": true, "retrievable": true, "sortable": false, "facetable": true },
    { "name": "user_id", "type": "Edm.String", "searchable": false, "filterable": true, "retrievable": true, "sortable": false, "facetable": true },
    { "name": "sources", "type": "Collection(Edm.String)", "searchable": false, "filterable": true, "retrievable": true, "sortable": false, "facetable": true },
    { "name": "created_at", "type": "Edm.DateTimeOffset", "searchable": false, "filterable": true, "retrievable": true },
    { "name": "updated_at", "type": "Edm.DateTimeOffset", "searchable": false, "filterable": true, "retrievable": true }
]

以下螢幕擷取畫面顯示在conversations中搜尋的結果：

在我們的範例中，搜尋分數為 1.00，因為搜尋不合格。數個欄位支援協調流程和提示流程：

conversation_id 會識別每個聊天會話。
type 指出內容來自使用者或助理。
created_at 和 updated_at 將會從記錄中刪除過期的聊天。

實體結構和大小

在 Azure AI 搜尋服務中，索引的實體結構主要是內部實作。您可以存取其架構、載入及查詢其內容、監視其大小，以及管理其容量。然而，Microsoft 會管理與您的搜尋服務相關儲存的基礎設施和具體資料結構。

索引的大小和實質內容取決於：

文件的數量和組成。
個別欄位的屬性。例如，可篩選欄位需要更多儲存體。
索引組態，包括指定如何建立內部導覽結構的向量組態。您可以選擇 HNSW 或詳盡的 KNN 進行相似性搜尋。

Azure AI 搜尋服務對向量儲存施加限制，有助於維持所有工作負載的平衡與穩定系統。為了幫助你控制在限制內，向量使用情況會分別在 Azure 入口網站中進行追蹤和報告，並透過服務和索引統計數據程式化地回報。

下列螢幕擷取畫面顯示已設定一個分割區和一個複本的 S1 服務。此服務有 24 個小索引，每個索引平均有一個向量字段，其中包含 1,536 個內嵌。第二個圖格顯示向量索引的配額和使用量。因為向量索引是針對每個向量欄位所建立的內部數據結構，因此向量索引的記憶體一律是索引所使用的整體記憶體的一小部分。非函式欄位和其他數據結構會取用其餘部分。

另一篇文章涵蓋向量索引限制和估計，但要強調的兩點是，記憶體上限取決於您搜尋服務的建立日期和定價層。較新的相同層級服務用於向量索引的容量會大上許多。基於這些原因，您應該：

檢查搜尋服務的建立日期。如果在 2024 年 4 月 3 日之前建立，您可以升級服務以提升容量。
如果您預期向量儲存空間需求可能會有波動，請選擇可擴展的層級。對於較舊的搜尋服務，基本層會固定在一個分割區。請考慮標準 1 （S1）和更高版本，以獲得更高的彈性和更快的效能。您也可以在基本層與標準層 (S1、S2 和 S3) 之間切換。

基本作業和互動

本節介紹向量運行時間作業，包括連接到和保護單一索引。

附註

沒有移動或複製索引的入口或 API 支援。一般而言，您可以將應用程式部署至不同的搜尋服務（使用相同的索引名稱），或修改名稱，以在目前的搜尋服務上建立複本，然後加以建置。

索引隔離

在 Azure AI 搜尋服務中，你一次只操作一個索引。所有索引相關的作業都會以單一索引為目標。在編製索引或查詢方面，不存在相關索引或獨立索引聯結的概念。

持續可用

索引會在第一份文件編製索引后立即可供查詢使用，但在編製所有文件索引之前，它不會完全運作。在內部，索引會分配到分區中，並在副本上執行。實體索引是由內部管理。您管理邏輯索引。

索引會持續可用，且無法暫停或離線。由於它被設計為長時間運行，因此即時更新內容並對索引本身進行新增。如果要求與檔更新一致，查詢可能會暫時傳回不完整的結果。

文件作業 (例如重新整理或刪除) 以及不影響目前索引現有結構或完整性的修改 (例如新增欄位)，將保有查詢持續性。結構更新，例如變更現有的欄位，通常會在開發環境中使用卸除和重建工作流程來管理，或在生產服務上建立新版本的索引。

若要避免索引重建，某些客戶會建立與舊版並存的新欄位，藉此對欄位進行小變更。但經過一段時間後，這種做法會導致過時欄位和過時的自訂分析器定義產生孤立的內容，特別是在複寫成本高昂的實際執行索引中。您可以在索引生命週期管理期間規劃的索引更新期間解決這些問題。

端點連線

所有向量索引編製和查詢要求都會以索引為目標。端點通常是下列其中一項：

端點	連線和存取控制
`<your-service>.search.windows.net/indexes`	以索引集合為目標。在建立、列出或刪除索引時使用。這些作業需要系統管理員許可權，而且可透過系統管理員 API 金鑰或搜尋參與者角色取得。
`<your-service>.search.windows.net/indexes/<your-index>/docs`	以單一索引的文件集合為目標。在查詢索引或資料重新整理時使用。對於查詢，讀取許可權就已足夠，而且可透過查詢 API 金鑰或資料讀取器角色來取得。資料重新整理需要管理員權限。

如何連接 Azure AI 搜尋服務

請確定您有權限 (部分機器翻譯) 或 API 存取金鑰 (部分機器翻譯)。除非您正在查詢現有的索引，否則您需要系統管理員許可權或參與者角色指派，才能管理和檢視搜尋服務上的內容。
從Azure入口開始。建立搜尋服務的人員可以檢視和管理它，包括授與 訪問控制（IAM） 頁面上其他人的存取權。
移至其他用戶端以進行程式設計存取。作為第一步，我們建議使用 Quickstart：使用 REST 進行向量搜尋，以及 azure-search-vector-samples 倉庫。

管理向量存放區

Azure 提供一個包含診斷記錄與警示功能的監控平台。建議您：

安全存取向量資料

Azure AI 搜尋服務實作資料加密、無網際網路情境下的私有連線，以及透過 Microsoft Entra ID 進行角色分配以確保安全存取。欲了解更多企業安全功能，請參閱資料、隱私與內建保護。

意見反應

此頁面對您有幫助嗎？

Last updated on 2026-04-07