Azure AI 搜尋中的向量記憶體

發行項
04/07/2024

Azure AI 搜尋提供向量儲存和設定，以供向量搜尋和混合式搜尋使用。支援是在欄位層級實作，這表示您可以在相同的搜尋主體中結合向量和非向量字段。

向量會儲存在搜尋索引中。使用建立索引 REST API 或對等的 Azure SDK 方法來建立向量存放區。

向量記憶體的考慮包括下列幾點：

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

向量擷取模式

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

行性搜尋。語言模型會使用來自 Azure AI 搜尋的數據來制定使用者查詢的回應。此模式包含協調流程層，可協調提示和維護內容。在此模式中，搜尋結果會饋送至提示流程，由 GPT 和 Text-Davinci 等聊天模型接收。此方法是以 擷取增強世代（RAG） 架構為基礎，其中搜尋索引會提供基礎數據。
使用搜尋列、查詢輸入字串和轉譯結果的傳統搜尋。搜尋引擎會接受和執行向量查詢、制定回應，並在用戶端應用程式中轉譯這些結果。在 Azure AI 搜尋中，結果會在扁平化的數據列集中傳回，您可以選擇要包含搜尋結果的欄位。由於沒有聊天模型，因此預期您會在回應中填入向量存放區（搜尋索引），並填入人類可讀取的非vector 內容。雖然搜尋引擎會比對向量，但您應該使用非向量值來填入搜尋結果。 向量查詢和混合式查詢涵蓋您可以針對傳統搜尋案例制定的查詢要求類型。

您的索引架構應該反映您的主要使用案例。下一節強調針對針對產生 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" 對等欄位。如果您只針對回應公式使用語言模型，您可以省略非函式內容欄位，但直接將搜尋結果推送至用戶端應用程式的解決方案應該具有非函式內容。

元數據欄位適用於篩選，特別是元數據包含源文檔的源資訊時。您無法直接篩選向量欄位，但您可以設定預先篩選或後置篩選模式，以在向量查詢執行之前或之後進行篩選。

匯入和向量化數據精靈所產生的架構

建議匯入和向量化數據精靈，以進行評估和概念證明測試。精靈會在本節中產生範例架構。

此架構的偏差在於搜尋檔是以數據區塊為基礎所建置。如果語言模型制定回應，就像RAG應用程式一般，您希望針對數據區塊設計架構。

數據區塊化是留在語言模型的輸入限制內的必要專案，但是當查詢可以比對從多個父檔提取的較小內容區塊時，也會改善相似性搜尋的有效位數。最後，如果您使用語意排名，語意排名器也會有令牌限制，如果數據區塊化是方法的一部分，則更容易符合這些限制。

在下列範例中，針對每個搜尋檔，會有一個區塊標識碼、區塊、標題和向量字段。使用 Blob 元數據的基底 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 提供監視平臺，其中包含診斷記錄和警示。我們建議下列最佳做法：

共用方式為