Azure AI 搜尋服務中的向量儲存體

發行項
09/19/2024

Azure AI 搜尋服務針對向量搜尋 (部分機器翻譯) 和混合式搜尋提供向量儲存體和設定。支援是在欄位層級實作，這表示您可以在相同的搜尋主體中結合向量和非向量欄位。

向量會儲存在搜尋索引中。使用建立索引 REST API (部分機器翻譯) 或對等的 Azure SDK 方法來建立向量存放區 (部分機器翻譯)。

向量儲存體的考量包括下列幾點：

根據預期的向量擷取模式，設計結構描述以符合您的使用案例。
估計索引大小，並檢查搜尋服務容量。
管理向量存放區
保護向量存放區

向量擷取模式

在 Azure AI 搜尋服務中，有兩種模式可用於搜尋結果。

生成式搜尋。語言模型會使用來自 Azure AI 搜尋服務的資料來制定對使用者查詢的回應。此模式包括協調流程層，以協調提示和維護內容。在此模式中，搜尋結果會饋送至提示流程，並由 GPT 和 Text-Davinci 等聊天模型接收。此方法是以擷取擴增生成 (RAG) (部分機器翻譯) 結構為基礎，其中搜尋索引會提供基礎資料。
使用搜尋列、查詢輸入字串和轉譯結果的傳統搜尋。搜尋引擎會接受和執行向量查詢、制定回應，且您會在用戶端應用程式中轉譯那些結果。在 Azure AI 搜尋服務中，會以壓平合併的資料列集傳回結果，且您可以選擇要將哪些欄位包括到搜尋結果中。由於沒有聊天模型，因此預期您會在回應中將人類可讀取的非向量內容填入向量存放區 (搜尋索引)。雖然搜尋引擎會與向量比對，但您應該使用非向量值來填入搜尋結果。 向量查詢 (部分機器翻譯) 和混合式查詢 (部分機器翻譯) 涵蓋您可以針對傳統搜尋案例制定的查詢要求類型。

您的索引結構描述應該反映您的主要使用案例。下一節會重點提示針對生成式 AI 或傳統搜尋所建置之解決方案的欄位組合差異。

向量存放區的結構描述

向量存放區的索引結構描述需要名稱、索引鍵欄位 (字串)、一或多個向量欄位，以及向量設定。建議針對混合式查詢，或針對傳回不需要經過語言模型的逐字人類可讀取內容使用非向量欄位。如需向量設定的相關指示，請參閱建立向量存放區 (部分機器翻譯)。

基本向量欄位設定

向量欄位會依其資料類型和向量特有屬性來區別。以下是欄位集合中的向量欄位外觀：

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

向量欄位具有特定的資料類型。目前 Collection(Edm.Single) 是最常見的，但使用窄資料類型可以節省儲存體。

向量欄位必須是可搜尋且可擷取的，但其無法加以篩選、Facet 或排序，或具有分析器、正規化程式或同義字對應指派。

向量欄位必須將 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" 欄位的人類可讀取對等項目。如果您只針對回應公式使用語言模型，您可以省略非向量內容欄位，但直接將搜尋結果推送至用戶端應用程式的解決方案應該具有非向量內容。

中繼資料欄位很適用於篩選，特別是在中繼資料包括來源文件之原始資訊的情況下。您無法直接對向量欄位進行篩選，但您可以設定預先篩選或後置篩選模式，以在向量查詢執行之前或之後進行篩選。

[Import and vectorize data] \(匯入並向量化資料\) 精靈所產生的結構描述

建議針對評估和概念證明測試使用 [Import and vectorize data] \(匯入並向量化資料\) 精靈。本節中的範例結構描述是由該精靈產生的。

此結構描述的偏差在於搜尋文件是以資料區塊為基礎所建置。如果語言模型會制定回應 (此為 RAG 應用程式常見的情況)，建議您使用根據資料區塊設計的結構描述。

資料區塊化是留在語言模型輸入限制內的必要項目，但是當查詢可以比對從多個父文件提取的較小內容區塊時，其也能改善相似性搜尋的精確度。最後，如果您使用語意排名工具，語意排名工具也會有語彙基元限制，而如果資料區塊化是您方法的一部分，便更容易符合那些限制。

在下列範例中，針對每個搜尋文件會有一個區塊識別碼、區塊、標題和向量欄位。精靈會使用 Blob 中繼資料 (路徑) 的 base 64 編碼來填入區塊識別碼和父識別碼。區塊和標題是衍生自 Blob 內容和 Blob 名稱。只會完全產生向量欄位。其為區塊欄位的向量化版本。內嵌是藉由呼叫您提供的 Azure OpenAI 內嵌模型來產生。

"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 (英文) 加速器建立。

來自支援生成式搜尋體驗之聊天索引的欄位：

"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 }
]

來自支援協調流程和聊天記錄之交談索引的欄位：

"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 }
]

以下螢幕擷取畫面顯示搜尋總管 (部分機器翻譯) 中針對交談索引的搜尋結果。搜尋分數為 1.00，因為該搜尋不合格。請注意存在以支援協調流程和提示流程的欄位。交談識別碼會識別特定的聊天。 "type" 指出內容來自使用者或助理。日期是用來從記錄中淘汰聊天。

實體結構和大小

在 Azure AI 搜尋服務中，索引的實體結構主要是內部實作。您可以存取其結構描述、載入並查詢其內容、監視其大小並管理容量，但叢集本身 (反向和向量索引) 以及其他檔案和資料夾則是由 Microsoft 內部管理。

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

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

Azure AI 搜尋服務會對向量儲存體施加限制，其有助於為所有工作負載維護平衡且穩定的系統。為了協助您保持在限制之下，會在 Azure 入口網站中個別追蹤和報告向量使用量，並透過服務和索引統計資料以程式設計方式報告。

下列螢幕擷取畫面顯示已設定一個分割區和一個複本的 S1 服務。這個特定的服務有 24 個小索引，每個索引平均有一個向量欄位，每個欄位包含 1536 個內嵌。第二個圖格顯示向量索引的配額和使用量。向量索引是針對每個向量欄位建立的內部資料結構。因此，向量索引的儲存體一律是整體索引所使用之儲存體的一小部分。其他非向量欄位和資料結構會取用剩餘的儲存體。

向量索引限制和估計是涵蓋於另一篇文章 (部分機器翻譯) 中，但要先強調的兩點是：儲存體上限會因服務層級而異，也會因搜尋服務的建立時間而有所不同。較新的相同層級服務用於向量索引的容量會大上許多。基於這些原因，請採取下列動作：

檢查搜尋服務的部署日期 (部分機器翻譯)。如果其是在 2024 年 4 月 3 日之前建立，請考慮建立新的搜尋服務以取得更大的容量。
如果您預期向量儲存體需求會有波動，請選擇可調整的層級 (部分機器翻譯)。基本層固定在舊版搜尋服務的一個分割區。請考慮標準 1 (S1) 和更新版本，以獲得更高的彈性和更快的效能，或建立新的搜尋服務，以在每個可擷取層使用更高的限制和更多分割區。

基本作業和互動

本節將介紹向量執行階段的作業，包括連線至及保護單一索引。

注意

管理索引時需注意一點，沒有入口網站或 API 可支援移動或複製索引。作為替代，客戶通常會將其應用程式部署解決方案指向不同的搜索服務 (如果使用相同索引名稱)，或是修改名稱以在目前的搜尋服務上建立複本。

持續可用

在第一份文件完成編製索引後，索引便立即可供查詢使用，但必須等到所有文件索引編製完成才能獲得完整功能。在內部，索引會分散到分割區，並在複本上執行 (部分機器翻譯)。實體索引是由內部管理。邏輯索引是由您管理。

索引會持續可用，無法暫停或離線。因為索引是設計用於連續作業，所以其內容的任何更新或索引本身的新增都會即時發生。因此，如果要求與文件更新同時發生，查詢可能會暫時傳回不完整的結果。

請注意，文件作業 (重新整理或刪除) 以及不影響目前索引的現有結構和完整性的修改 (例如新增欄位)，將不會影響查詢持續性。如果您需要進行結構化更新 (變更現有欄位)，這些更新的管理方式通常是在開發環境中使用卸載和重建工作流程，或在實際執行服務上建立新版本的索引。

若要避免索引重建，某些進行小型變更的客戶會建立與舊版並存的新欄位，藉此保留欄位的各個「版本」。但隨著時間增長，這種做法會導致過時欄位或過時自訂分析器定義形式的孤立內容，特別是在成本高昂的實際執行索引中。您可以在索引生命週期管理流程中，透過索引計劃性更新來解決這些問題。

端點連線

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

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

如何連線至 Azure AI 搜尋服務

請確定您有權限 (部分機器翻譯) 或 API 存取金鑰 (部分機器翻譯)。除非您正在查詢現有的索引，否則您需要系統管理員權限或參與者角色指派，才能管理及檢視搜尋服務上的內容。
從 Azure 入口網站開始。建立搜尋服務的人員可以檢視及管理搜尋服務，包括透過 [存取控制 (IAM)] 頁面將存取權授與其他人。
移至其他用戶端以進行程式設計存取。針對初始步驟建議的快速入門和範例：
- 快速入門：REST (部分機器翻譯)
- 向量範例 (英文)

安全存取向量資料

Azure AI 搜尋服務會透過 Microsoft Entra ID 實作資料加密、適用於無網際網路案例的私人連線，以及適用於安全存取的角色指派。 Azure AI 搜尋服務中的安全性 (部分機器翻譯) 概述企業安全性功能的完整範圍。

管理向量存放區

Azure 提供監視平台 (部分機器翻譯)，其中包括診斷記錄和警示。以下是建議的最佳做法：

共用方式為