共用方式為

Azure AI 搜尋服務中的向量

  • 發行項

向量搜尋是一種資訊擷取方法，可支援對內容的數值表示法進行索引編製和查詢執行。 由於內容是數值而非純文本，因此比對是以最類似於查詢向量的向量為基礎，可跨下列專案進行比對：

  • 語意或概念相似性（“狗”和“犬”，在概念上相似但語言上不同）
  • 多語系內容（英文為“狗”，德文為“狗”）
  • 多種內容類型（純文字中的「狗」，以及圖像檔中狗的照片）

本文提供 Azure AI 搜尋服務中向量 的高階簡介。 其也會說明與其他 Azure 服務的整合，並涵蓋與向量搜尋開發相關的詞彙和概念。

建議您以本文為背景概念，但如果您想要開始使用，請依照下列步驟操作：

您也可以從向量快速入門 (部分機器翻譯) 或 GitHub 上的程式碼範例 (英文) 開始。

向量搜尋支援哪些案例？

適用於向量搜尋的案例包括：

  • 相似性搜尋。 使用如 OpenAI 內嵌的內嵌模型，或是如 SBERT 的開放原始碼模型來對文字進行編碼，並使用同樣也編碼為向量的查詢來擷取文件。

  • 搜尋不同內容類型 (多模式)。 使用多模式內嵌來對影像和文字進行編碼 (例如，使用 OpenAI CLIP (英文) 或在 Azure OpenAI 中使用 GPT-4 Turbo 搭配視覺 (部分機器翻譯))，並查詢由來自這兩個內容類型的向量所組成的內嵌空間。

  • 混合式搜尋 (部分機器翻譯)。 在 Azure AI 搜尋中，混合式搜尋是指相同要求中的向量和關鍵詞查詢執行。 向量支援是在欄位層級實作，且具有包含向量欄位和可搜尋文字欄位的索引。 查詢會以平行方式執行，且結果會合併成單一回應。 選擇性地，使用支援 Bing 的相同語言模型新增語意排名 (部分機器翻譯)，以利用 L2 重新排名取得更精確的結果。

  • 多語系搜尋。 可透過以多種語言定型的內嵌模型和聊天模型，以使用者自己的語言提供搜尋體驗。 如果您需要對翻譯取得更多控制，在混合式搜尋案例中，您可以使用 Azure AI 搜尋服務針對非向量內容所支援的多語言功能 (部分機器翻譯) 來加以補充。

  • 已篩選的向量搜尋。 查詢要求可以包括向量查詢和篩選條件運算式。 篩選條件會套用至文字和數值欄位，而且適用於中繼資料篩選，以及根據篩選準則包括或排除搜尋結果。 雖然向量欄位本身無法篩選，您可以設定可篩選的文字或數值欄位。 搜尋引擎可以在執行向量查詢之前或之後處理篩選。

  • 向量資料庫。 Azure AI 搜尋服務會儲存您查詢的資料。 每當您需要長期記憶體或知識庫，或是針對擷取擴增生成 (RAG) 結構 (部分機器翻譯) 建立基礎資料，或是任何使用向量的應用程式時，請將其作為純向量存放區 (部分機器翻譯) 使用。

向量支援包括對來自搜尋索引的向量內嵌進行索引編製、儲存和查詢。

下圖顯示向量搜尋的索引編製和查詢工作流程。

向量搜尋工作流程的架構。

在編製索引端，Azure AI 搜尋服務會採用向量內嵌，並使用最近鄰項目演算法 (部分機器翻譯)，以將類似的向量在索引中擺在一起。 在內部，其會為每個向量欄位建立向量索引。

如何從來源內容將內嵌傳送至 Azure AI 搜尋服務需取決於您的方法，以及您是否可以使用預覽功能。 您可以使用來自 OpenAI、Azure OpenAI 和任意數目提供者的模型，針對模型所支援的文字、影像或其他內容類型的眾多來源內容進行向量化或產生內嵌作為初步步驟。 然後，您可以將預先向量化的內容推送至向量存放區中的向量欄位 (部分機器翻譯)。 這是適用於正式推出版本的方法。 如果您可以使用預覽功能，Azure AI 搜尋服務能在索引子管線中提供整合式資料區塊化和向量化 (部分機器翻譯)。 您仍然會提供資源 (針對 Azure OpenAI 的端點和連線資訊)，但 Azure AI 搜尋服務會負責所有呼叫並處理轉換。

在查詢端的用戶端應用程式中，您通常會透過提示工作流程從使用者收集查詢輸入。 接著，您可以新增可將輸入轉換成向量的編碼步驟，然後將向量查詢傳送至 Azure AI 搜尋服務上的索引以進行相似性搜尋。 如同編製索引，您可以部署整合向量化 (預覽) (部分機器翻譯) 以將問題轉換成向量。 針對任一種方法，Azure AI 搜尋服務都會在結果中傳回具有所要求 k 個最近鄰項目 (kNN) 的文件。

Azure AI 搜尋服務支援混合式案例 (部分機器翻譯)，其能平行執行向量和關鍵字搜尋，並傳回統一的結果集，此做法通常能傳回比單獨搜尋向量或關鍵字更好的結果。 針對混合式，系統會將向量和非向量內容內嵌到相同的索引中，以同時進行查詢。

可用性和價格

向量搜尋在所有區域中皆以所有 Azure AI 搜尋服務層級之一部分的形式提供，且不另外收費。

在 2024 年 4 月 3 日之後建立的較新服務支援 較高的向量索引配額。

向量搜尋在下列項目中提供：

注意

某些在 2019 年 1 月 1 日之前建立的較舊搜尋服務會部署在不支援向量工作負載的基礎結構上。 如果您嘗試將向量欄位新增至結構描述並收到錯誤，其為過時服務的結果。 在這種情況下，您必須建立新的搜尋服務以嘗試向量功能。

Azure AI 搜尋服務已深入整合至整個 Azure AI 平台。 下表列出數個在向量工作負載中很有用的服務。

Products 整合
Azure OpenAI 工作室 在與您資料遊樂場的聊天中，[新增您自己的資料] 會使用 Azure AI 搜尋服務來進行基礎資料的建立和交談式搜尋。 這是與您的資料聊天最簡單且最快的方法。
Azure OpenAI Azure OpenAI 提供內嵌模型和聊天模型。 示範和樣本會以 text-embedding-ada-002 (部分機器翻譯) 為目標。 我們建議使用 Azure OpenAI 來產生文字的內嵌。
Azure AI 服務 影像擷取向量化影像 API (預覽) (部分機器翻譯) 支援影像內容的向量化。 我們建議使用此 API 來產生影像的內嵌。
Azure 資料平台：Azure Blob 儲存體、Azure Cosmos DB 您可以使用索引子來將資料擷取自動化，然後使用整合向量化 (預覽) (部分機器翻譯) 來產生內嵌。 Azure AI 搜尋服務可以自動對來自兩個資料來源的向量資料進行索引編製：Azure Blob 索引子 (部分機器翻譯) 和 Azure Cosmos DB for NoSQL 索引子 (部分機器翻譯)。 如需詳細資訊，請參閱將向量欄位新增至搜尋索引 (部分機器翻譯)。

其也常用於開放原始碼架構，例如 LangChain (英文)。

向量搜尋概念

如果您不熟悉向量，本節將說明一些核心概念。

向量搜尋是資訊擷取的方法，其中文件和查詢會以向量表示，而不是純文字。 在向量搜尋中，機器學習模型會產生來源輸入的向量表示法，來源輸入可以是文字、影像或其他內容。 具有內容的數學表示法，可提供搜尋案例的通用基礎。 如果一切都是向量，則查詢可以在向量空間中找到相符項目，即使相關聯的原始內容與查詢的媒體或語言不相同也可以。

當可搜尋的內容以向量表示時，查詢可以在類似內容中找到接近的相符項目。 用於向量產生的內嵌模型知道哪些單字和概念是類似的，並會將產生的向量在內嵌空間中擺在一起。 例如，有關「雲朵」和「霧」的向量化來源文件更有可能出現在有關「水氣」的查詢中，因為這些項目具有相似的語意，即使其在詞彙上並不相符。

內嵌和向量化

內嵌是內容或查詢的特定類型向量表示法，其由機器學習模型所建立，可擷取文字或影像等其他內容之表示法的語意意義。 自然語言機器學習模型會針對大量資料進行定型，以識別單字之間的模式和關聯性。 在定型期間，其會了解如何在稱為「編碼器」的中繼步驟中，將任何輸入以實數向量來表示。 定型完成後，可以修改這些語言模型，讓中繼向量表示法成為模型的輸出。 產生的內嵌會是高維度向量，其中具有類似意義的單字在向量空間中會較為接近，如了解內嵌 (Azure OpenAI) (部分機器翻譯) 中所述。

向量搜尋在擷取相關資訊上的有效性，取決於內嵌模型在將文件和查詢的意義融合到所產生向量中的有效性。 最佳模型會針對其所代表的資料類型進行良好的定型。 您可以評估如 Azure OpenAI text-embedding-ada-002 的現有模型、自備直接在問題空間上定型的模型，或是微調一般用途模型。 Azure AI 搜尋服務不會對您選擇的模型施加限制，因此請為您的資料挑選最佳模型。

為了針對向量搜尋建立有效的內嵌，請務必將輸入大小限制納入考量。 建議您先遵循區塊化資料的指導方針 (部分機器翻譯)，再產生內嵌。 此最佳做法可確保內嵌能準確地擷取相關資訊，並實現更有效率的向量搜尋。

什麼是內嵌空間？

「內嵌空間」是向量查詢的主體。 在搜尋索引內，內嵌空間是填入來自相同內嵌模型之內嵌的所有向量欄位。 機器學習模型會藉由將個別單字、片語或文件 (用於自然語言處理)、影像或其他形式的資料對應到由代表高維度空間中座標的實數向量所組成的表示法，來建立內嵌空間。 在此內嵌空間中，類似的項目會放在一起，而不同的項目則位於更遠的地方。

例如，談論不同品種的狗的文件在內嵌空間中會叢集在一起。 關於貓的文件會聚集在一起，其會與狗的叢集距離較遠，但仍然共處於動物的範圍內。 像是雲端運算之類的不相似概念則會距離更遠。 實際上，這些內嵌空間是抽象的，且沒有妥善定義的人類可解讀意義，但其核心想法保持不變。

在向量搜尋中，搜尋引擎會掃描內嵌空間內的向量，以識別最接近查詢向量的向量。 這項技術稱為最近鄰項目搜尋。 最近鄰項目有助於將項目之間的相似性量化。 高度的向量相似性表示原始資料也是相似的。 為了促成快速的最近鄰項目搜尋，搜尋引擎會執行最佳化，或採用資料結構和資料分割，以減少搜尋空間。 每個向量搜尋演算法會針對最小延遲、最大輸送量、召回和記憶體進行最佳化，以不同的方式解決最近鄰項目問題。 若要計算相似性，相似性計量會提供計算距離的機制。

Azure AI 搜尋服務目前支援下列演算法：

  • 階層式導覽小型世界 (HNSW)：HNSW 是已針對高召回的低延遲應用程式進行最佳化的主要 ANN 演算法，其中資料散發是未知的或可能經常變更。 其會將高維度資料點組織成階層式圖表結構，以促成快速且可調整的相似性搜尋，同時允許在搜尋正確性和計算成本之間進行可調整的取捨。 因為演算法要求所有資料點都位於記憶體中，以便快速隨機存取，因此此演算法會取用向量索引大小 (部分機器翻譯) 配額。

  • 詳盡的 K 最近鄰項目 (KNN)：計算查詢向量與所有資料點之間的距離。 其會耗用大量運算，因此最適合較小的資料集。 因為演算法不需要快速隨機存取資料點，因此此演算法不會取用向量索引大小配額。 不過，此演算法會提供最近鄰項目的全域集合。

在索引定義內，您可以指定一或多個演算法，然後針對每個向量欄位指定要使用的演算法：

  • 建立向量存放區 (部分機器翻譯) 以在索引中和欄位上指定演算法。

  • 如需詳盡的 KNN，請使用 2023-11-01 (部分機器翻譯)、2023-10-01-Preview (部分機器翻譯)，或是以任一版本的 REST API 為目標的 Azure SDK 搶鮮版 (Beta) 程式庫。

在建立索引期間用來將索引初始化的演算法參數是不可變的，而且無法在建置索引之後變更。 不過，可以修改影響查詢時間特性的參數 (efSearch)。

此外，指定 HNSW 演算法的欄位也支援使用查詢要求 (部分機器翻譯) 參數 "exhaustive": true 進行詳盡的 KNN 搜尋。 但是相反的情況並不成立。 如果欄位已針對 exhaustiveKnn 編製索引，您就無法在查詢中使用 HNSW，因為促成有效搜尋的額外資料結構並不存在。

近似最近鄰項目

近似近鄰 （ANN） 搜尋是一種演算法類別，用於在向量空間中尋找相符專案。 這種演算法類別採用不同的資料結構或資料分割方法來大幅減少搜尋空間，以加快查詢處理的速度。

ANN 演算法會犧牲一些正確性，但提供可調整且更快速的近似最近鄰項目擷取，因此非常適合用來在新式資訊擷取應用程式中於正確性與效率之間取得平衡。 您可以調整演算法的參數，以微調搜尋應用程式的召回、延遲、記憶體和磁碟使用量需求。

Azure AI 搜尋服務針對其 ANN 演算法使用 HNSW。

下一步