在 Azure AI 搜尋服務中建立向量查詢
在 Azure AI 搜尋服務中,如果您有向量索引 (部分機器翻譯),本文將說明如何:
本文使用 REST 進行說明。 如需其他語言的程式碼范例,請參閱 azure-search-vector-samples GitHub 存放庫,了解包括向量査詢的端對端解決方案。
如果您設定將字串轉換成內嵌的向量化工具,也可以在 Azure 入口網站中使用 [搜尋總管]。
必要條件
Azure AI 搜尋,在任何區域和任何層級。
Azure AI 搜尋服務上的向量索引。 檢查索引中的
vectorSearch
區段,以確認向量索引。如果您想自己執行這些範例,請使用帶有 REST 用戶端和範例資料的 Visual Studio Code。 若要開始使用 REST 用戶端,請參閱快速入門:使用 REST 的 Azure AI 搜尋服務。
將査詢字串輸入轉換為向量
若要查詢向量欄位,查詢本身必須是向量。
將使用者的文字査詢字串轉換為其向量表法的一種方法是在應用程式程式碼中呼叫內嵌程式庫或 API。 作為最佳做法,一律使用用於在來源文件中產生內嵌的相同內嵌模型。 您可以在 azure-search-vector-samples 存放庫中找到顯示如何產生內嵌的程式碼範例。
第二種方法是使用整合向量化,目前處於公開預覽狀態,讓 Azure AI 搜尋服務處理您的査詢向量化輸入和輸出。
以下是提交查詢字串以部署 Azure OpenAI 內嵌模型部署的 REST API 範例:
POST https://{{openai-service-name}}.openai.azure.com/openai/deployments/{{openai-deployment-name}}/embeddings?api-version={{openai-api-version}}
Content-Type: application/json
api-key: {{admin-api-key}}
{
"input": "what azure services support generative AI'"
}
預期的回應為 202,表示成功呼叫已部署的模型。
回應本文中的「內嵌」欄位是查詢字串 "input" 的向量表示法。 針對測試目的,您將會使用接下來數節中所示的語法,將「內嵌」陣列的值複製到查詢要求中的 "vectorQueries.vector"。
對部署模型進行此 POST 呼叫的實際回應包含 1536 個內嵌,在這裡為了可讀性會修剪為僅前幾個向量。
{
"object": "list",
"data": [
{
"object": "embedding",
"index": 0,
"embedding": [
-0.009171937,
0.018715322,
...
-0.0016804502
]
}
],
"model": "ada",
"usage": {
"prompt_tokens": 7,
"total_tokens": 7
}
}
在此方法中,應用程式程式碼負責連線至模型、產生內嵌和處理回應。
向量查詢要求
本節說明向量查詢的基本結構。 您可以使用 Azure 入口網站、REST API 或 Azure SDK 來製訂向量査詢。 如果您從 2023-07-01-Preview 進行移轉,則會有一些突破性變更。 如需有關詳細資訊,請參閱升級至最新 REST API。
2023-11-01 是搜尋 POST 的穩定 REST API 版本。 此版本支援:
vectorQueries
是用於向量搜尋的建構。kind
設定為vector
指定査詢是向量陣列。vector
是査詢 (文字或影像的向量表示法)。exhaustive
(選用) 會在查詢時叫用詳盡的 KNN,即使欄位是針對 HNSW 編製索引也一樣。
在下列範例中,向量是此字串的表示法:「什麽 Azure 服務支援全文檢索搜尋」。 査詢以 contentVector
欄位為目標。 查詢會傳回 k
結果。 實際向量有 1536 個內嵌,因此為了可讀性會在此範例中修剪此向量。
POST https://{{search-service-name}}.search.windows.net/indexes/{{index-name}}/docs/search?api-version=2023-11-01
Content-Type: application/json
api-key: {{admin-api-key}}
{
"count": true,
"select": "title, content, category",
"vectorQueries": [
{
"kind": "vector",
"vector": [
-0.009154141,
0.018708462,
. . .
-0.02178128,
-0.00086512347
],
"exhaustive": true,
"fields": "contentVector",
"k": 5
}
]
}
向量查詢回應
在 Azure AI 搜尋服務中,査詢回應預售由所有 retrievable
欄位組成。 然而,透過在 select
陳述式中列出搜尋結果,將搜尋結果限制在 retrievable
欄位的子集內是很常見的。
在向量査詢中,請仔細考慮是否需要在回應中向量欄位。 向量欄位不是人類可讀的,所以如果把回應推送至 web 上,您應該選擇代表結果的非向量欄位。 例如,如果査詢對 contentVector
執行,則可以傳回 content
。
如果您確實希望在結果中使用向量欄位,此處有回應結構的範例。 contentVector
是內嵌的字串陣列,為簡潔起見,此處進行了修剪。 搜尋分數表示相關性。 内容還包括其他非向量欄位。
{
"@odata.count": 3,
"value": [
{
"@search.score": 0.80025613,
"title": "Azure Search",
"category": "AI + Machine Learning",
"contentVector": [
-0.0018343845,
0.017952163,
0.0025753193,
...
]
},
{
"@search.score": 0.78856903,
"title": "Azure Application Insights",
"category": "Management + Governance",
"contentVector": [
-0.016821077,
0.0037742127,
0.016136652,
...
]
},
{
"@search.score": 0.78650564,
"title": "Azure Media Services",
"category": "Media",
"contentVector": [
-0.025449317,
0.0038463024,
-0.02488436,
...
]
}
]
}
重點︰
k
決定傳回多少個最近鄰居結果,在本例中為三個。 向量査詢一律傳回k
個結果,假設至少存在k
個文件,即使存在相似性較差的文件,因為演算法會找到査詢向量的任何k
個最近鄰居。@search.score
由 向量搜尋演算法決定。搜索結果中的欄位要麼是所有
retrievable
欄位,要麼是select
子句中的欄位。 在向量査詢執行期間,僅對向量資料進行比對。 不過,回應可以在索引中包含任何retrievable
欄位。 因為沒有解碼向量欄位結果的設施,所以包含非向量文字欄位有助於其人類可讀值。
使用篩選條件進行向量查詢
查詢要求可以包含向量查詢和篩選條件運算式。 篩選條件適用於 filterable
非向量欄位,無論是字串欄位還是數字欄位,對於根據篩選準則包括或排除搜尋文件都很實用。 儘管向量欄位本身不可篩選,但篩選條件可以套用至同一索引中的其他欄位。
您可以在執行査詢之前或在執行査詢之後套用篩選作為排除準則來篩選搜尋結果。 如需每個模式的比較和以索引大小為基礎的預期效能,請參閱向量查詢中的篩選條件。
提示
如果您沒有搭配文字或數值的來源欄位,請檢查可能在中繼資料篩選條件中很有用的文件中繼資料,例如 LastModified 或 CreatedBy 屬性。
2023-11-01 是此 API 的穩定版本。 其中包含:
- 適用於預先篩選 (預設) 或後置篩選的
vectorFilterMode
篩選結果。 filter
會提供準則。
在下列範例中,向量是此查詢字串的表示法:「哪些 Azure 服務支援全文檢索搜尋」。 査詢以 contentVector
欄位為目標。 實際向量有 1536 個內嵌,因此為了可讀性會在此範例中修剪此向量。
在搜尋引擎執行向量查詢之前,篩選準則會套用至可篩選的文字欄位 (此範例中的 category
)。
POST https://{{search-service-name}}.search.windows.net/indexes/{{index-name}}/docs/search?api-version=2023-11-01
Content-Type: application/json
api-key: {{admin-api-key}}
{
"count": true,
"select": "title, content, category",
"filter": "category eq 'Databases'",
"vectorFilterMode": "preFilter",
"vectorQueries": [
{
"kind": "vector",
"vector": [
-0.009154141,
0.018708462,
. . .
-0.02178128,
-0.00086512347
],
"exhaustive": true,
"fields": "contentVector",
"k": 5
}
]
}
多個向量欄位
您可以將“vectorQueries.fields”屬性設定為多個向量欄位。 向量査詢針對 fields
清單中提供的每個向量欄位執行。 査詢多個向量欄位時,請確保每個欄位都包含來自同一內嵌模型的內嵌,並且査詢也是從同一內嵌模式產生的。
POST https://{{search-service-name}}.search.windows.net/indexes/{{index-name}}/docs/search?api-version=2023-11-01
Content-Type: application/json
api-key: {{admin-api-key}}
{
"count": true,
"select": "title, content, category",
"vectorQueries": [
{
"kind": "vector",
"vector": [
-0.009154141,
0.018708462,
. . .
-0.02178128,
-0.00086512347
],
"exhaustive": true,
"fields": "contentVector, titleVector",
"k": 5
}
]
}
多個向量查詢
多查詢向量搜尋會在您的搜尋索引中跨多個向量欄位傳送多個查詢。 下列情況是此查詢要求的常見範例:針對相同模型可以向量化影像和文字內容的多模式向量搜尋,使用 CLIP 這類的模型。
下列查詢範例會同時在 myImageVector
和 myTextVector
中尋找相似性,但會分別以兩種不同的查詢內嵌方式傳送,而每個查詢內嵌都會以平行方式執行。 此查詢會產生一個使用 倒數排名融合 (RRF) 來評分的結果。
vectorQueries
會提供向量查詢的陣列。vector
包含搜尋索引中的影像向量和文字向量。 每個執行個體都是個別的查詢。fields
會指定要設為目標的向量欄位。k
是要包含在結果中的最接近像素相符項目數目。
{
"count": true,
"select": "title, content, category",
"vectorQueries": [
{
"kind": "vector",
"vector": [
-0.009154141,
0.018708462,
. . .
-0.02178128,
-0.00086512347
],
"fields": "myimagevector",
"k": 5
},
{
"kind": "vector"
"vector": [
-0.002222222,
0.018708462,
-0.013770515,
. . .
],
"fields": "mytextvector",
"k": 5
}
]
}
搜尋結果將會包含文字和影像的組合,前提是您的搜尋索引包含影像檔案的欄位 (搜尋索引不會儲存影像)。
使用整合向量化進行查詢 (預覽)
本節顯示了向量査詢,它叫用了新的整合向量化預覽功能,它會將文字査詢轉換為向量。 使用 2023-10-01-Preview REST API 和更新的預覽版 REST API,或更新的 Beta Azure SDK 套件。
先決條件是搜尋索引已設定 向量化工具並指派給向量欄位。 向量化工具會將連線資訊提供給查詢時所使用的內嵌模型。 檢查向量化工具規格的索引定義。
查詢會提供文字字串,而不是向量:
kind
必須設定為text
。text
必須具有文字字串。 其會傳遞至指派給向量欄位的向量化工具。fields
是要搜尋的向量欄位。
以下是查詢時向量化的查詢簡單範例。 文字字串會向量化,然後用來查詢 descriptionVector 欄位。
POST https://{{search-service}}.search.windows.net/indexes/{{index}}/docs/search?api-version=2024-05-01-preview
{
"select": "title, genre, description",
"vectorQueries": [
{
"kind": "text",
"text": "mystery novel set in London",
"fields": "descriptionVector",
"k": 5
}
]
}
下方是使用文字査詢的整合向量化之混合式査詢。 此査詢包括多個査詢向量欄位、多個非向量欄位、一個篩選條件和語意排名。 同樣地,差異在於向量查詢的 kind
和 text
字串,而不是 vector
。
在此範例中,搜尋引擎會在索引中對指派給 descriptionVector
、synopsisVector
和 authorBioVector
的向量化工具進行三次向量化呼叫。 產生的向量用來針對各自的欄位擷取文件。 搜尋引擎還對 search
査詢執行關鍵字搜尋,即「以倫敦為背景的懸疑小說」。
POST https://{{search-service}}.search.windows.net/indexes/{{index}}/docs/search?api-version=2024-05-01-preview
Content-Type: application/json
api-key: {{admin-api-key}}
{
"search":"mystery novel set in London",
"searchFields":"description, synopsis",
"semanticConfiguration":"my-semantic-config",
"queryType":"semantic",
"select": "title, author, synopsis",
"filter": "genre eq 'mystery'",
"vectorFilterMode": "postFilter",
"vectorQueries": [
{
"kind": "text",
"text": "mystery novel set in London",
"fields": "descriptionVector, synopsisVector",
"k": 5
},
{
"kind": "text"
"text": "living english author",
"fields": "authorBioVector",
"k": 5
}
]
}
來自這四個查詢的評分結果都是使用 RRF 排名融合的。 次要語意排名是透過融合式搜尋結果叫用的,但僅限在 searchFields
上,這會提升語意上最符合 "search":"mystery novel set in London"
的結果。
注意
向量化工具是在編製索引和查詢期間使用。 如果不需要索引中的資料區塊化和向量化,您可以略過建立索引子、技能集和資料來源等步驟。 在此倩況下,向量化工具只會在查詢時用來將文字字串轉換成內嵌。
向量查詢回應中的排名結果數目
向量查詢會指定 k
參數,決定結果中傳回多少個相符項目。 搜尋引擎一律會傳回 k
相符項目數目。 如果 k
大於索引中的文件數目,則文件數目會決定可以傳回的上限。
如果熟悉全文檢索搜尋,您就會知道,若索引未包含字詞或片語,則會預期零個結果。 不過,在向量搜尋中,搜尋作業會識別最接近像素,而且即使最接近像素不是那麼類似,此作業仍會一律 k
結果。 因此,您可能會取得無意義或偏離主題查詢的結果,特別是如果您未使用提示來設定界限。 較不相關的結果會有更差的相似度分數,但如果沒有任何更接近的項目,這些結果仍然是「最接近」的向量。 因此,不含有意義結果的回應仍然可以傳回 k
結果,但每個結果的相似度分數將會很低。
包含全文檢索搜尋的混合式方法可以緩解此問題。 另一個緩解方式是在搜尋分數上設定最小閾值,但限於查詢是純單一向量查詢時。 混合式查詢不利於最小閾值,因為 RRF 範圍非常小且不穩定。
影響結果計數的查詢參數包括:
- 僅限向量查詢的
"k": n
結果 - 混合式查詢的
"top": n
結果,而這些查詢包含「search」參數
「k」和「top」都是選用。 未指定,回應中的預設結果數目為 50。 您可以設定「top」和「skip」,逐頁檢視更多的結果或變更預設值。
向量査詢中使用的排名演算法
結果的排名是由下列其中一項計算:
- 相似度計量
- 倒數排名融合 (RRF),若有多個搜尋結果集的話。
相似度計量
相似度計量,其指定於僅限向量查詢的索引 vectorSearch
區段中。 有效值為 cosine
、euclidean
及 dotProduct
。
Azure OpenAI 內嵌模型會使用餘弦相似度,因此如果您使用 Azure OpenAI 內嵌模型,則 cosine
是建議的計量。 其他支援的排名計量包括 euclidean
和 dotProduct
。
使用 RRF
如果査詢以多個向量欄位為目標,平行執行多個向量査詢,或者査詢是向量搜尋和全文檢索搜尋的混合,無論是否有語意排名,都會建立多個集合。
査詢執行期間,向量査詢只能以一個內部向量索引為目標。 因此,對於多個向量欄位和多個向量查詢,搜尋引擎會產生多個查詢,以每個欄位的個別向量索引為目標。 輸出是每個查詢的一組排名結果,這些結果會使用 RRF 融合。 如需詳細資訊,請參閱使用倒數排名融合 (RRF) 的相關性評分。
設定閾值以排除低評分結果 (預覽)
由於近鄰搜尋一律會傳回要求的 k
近鄰,因此在滿足搜尋結果上的 k
數量需求時,可能會取得多個低評分相符項目。
使用 2024-05-01-preview REST API,您現在可以新增 threshold
査詢參數,以根據最低分數來排除評分較低的搜尋結果。 在對來自不同重新叫用集合進行融合結果之前進行篩選。
在此範例中,所有分數低於 0.8 的相符項目都會從向量搜尋結果中排除,即使結果數目低於 k
也一樣。
POST https://[service-name].search.windows.net/indexes/[index-name]/docs/search?api-version=2024-05-01-Preview
Content-Type: application/json
api-key: [admin key]
{
"vectorQueries": [
{
"kind": "vector",
"vector": [1.0, 2.0, 3.0],
"fields": "my-cosine-field",
"threshold": {
"kind": "vectorSimilarity",
"value": 0.8
}
}
]
}
混合式搜尋的 MaxTextSizeRecall (預覽)
向量查詢通常用於包含非向量欄位的混合式建構中。 如果您發現混合式查詢結果中的 BM25 排名結果表示過高或過低,您可以將 maxTextRecallSize
設定為增加或減少針對混合式排名提供的 BM25 排名結果。
您只能在混合式要求中設定此屬性,包括 "search" 和 "vectorQueries" 元件。
如需詳細資訊,請參閱設定 maxTextRecallSize - 建立混合式查詢。
向量權數 (預覽)
新增 weight
査詢參數以指定搜尋作業中所包含每個向量查詢的相對權數。 結合相同要求中兩個或多個向量查詢所產生的多個排名清單結果時,或從混合式查詢的向量部分結合時,會使用這個值。
預設值為 1.0,且值必須是大於零的正數。
在計算每個文件的倒數排名融合分數時會使用權數。 計算是 weight
值與文件在其各自結果集中的排名分數的乘數。
下列範例是混合式查詢,其中包含兩個向量查詢字串和一個文字字串。 會將權數指派給向量查詢。 第一個查詢是 0.5 或一半的權數,可降低其在要求中的重要性。 第二個向量查詢重要性為兩倍。
文字查詢沒有權數參數,但您可以設定 maxTextRecallSize 來增加或減少其重要性。
POST https://[service-name].search.windows.net/indexes/[index-name]/docs/search?api-version=2024-05-01-Preview
{
"vectorQueries": [
{
"kind": "vector",
"vector": [1.0, 2.0, 3.0],
"fields": "my_first_vector_field",
"k": 10,
"weight": 0.5
},
{
"kind": "vector",
"vector": [4.0, 5.0, 6.0],
"fields": "my_second_vector_field",
"k": 10,
"weight": 2.0
}
],
"search": "hello world"
}
下一步
下一步,查看 Python、C# 或 JavaScript 中的向量査詢程式碼範例。
意見反應
https://aka.ms/ContentUserFeedback。
即將登場:在 2024 年,我們將逐步淘汰 GitHub 問題作為內容的意見反應機制,並將它取代為新的意見反應系統。 如需詳細資訊,請參閱:提交並檢視相關的意見反應