分享方式：

Azure AI 搜尋服務中的整合式資料區塊化和內嵌

  • 文章

整合向量化是 Azure AI 搜尋服務中索引編製和查詢管線的延伸。 其新增下列功能：

  • 編製索引期間的資料區塊化
  • 編製索引期間的文字到向量轉換
  • 查詢期間的文字到向量轉換

資料區塊化並非硬式需求，但除非您的原始文件很小，否則需要區塊化才能符合內嵌模型的權杖輸入需求。

向量轉換是單向：文字到向量。 針對查詢或結果並沒有向量到文字轉換 (例如，您無法將向量結果轉換成人類可讀取的字串)。

整合式數據區塊化和向量化可加速開發，並將數據擷取和查詢時間期間的維護工作降到最低，因為設定和管理的外部元件較少。 這項新功能現已正式推出。

在編製索引期間使用整合向量化

針對資料區塊化和文字到向量轉換，您會相依於下列元件：

在查詢中使用整合向量化

針對查詢期間的文字到向量轉換，您會相依於這些元件：

元件圖

下圖顯示整合向量化的元件。

整合向量化工作流程中的元件圖表。

工作流程是索引子管線。 索引子會呼叫 Azure OpenAI 或 Azure AI 服務或自訂程式碼，從支援的資料來源擷取資料，並起始資料擴充 (或套用的 AI)，以進行文字到向量轉換或其他處理。

此圖表著重於整合向量化，但您的解決方案並不限於此清單。 您可以新增更多技能以取得 AI 擴充、建立知識存放區、新增語意排名、新增相關性微調和其他查詢功能。

可用性和價格

整合向量化適用於所有區域和階層。 不過，如果您使用 Azure OpenAI 和 Azure AI 技能與向量化工具，請確定 Azure AI 多服務帳戶可在與 Azure AI 搜尋服務相同的區域中使用。

如果您使用自訂技能與 Azure 裝載機制 (例如 Azure 函式應用程式、Azure Web 應用程式和 Azure Kubernetes)，請檢查依區域提供的 Azure 產品頁面以取得功能可用性。

資料區塊化 (文字分割技能) 是免費的，且可在所有區域中的所有 Azure AI 服務上使用。

注意

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

整合向量化支援哪些案例？

  • 將大型文件細分成區塊，適用於向量和非向量案例。 針對向量，區塊可協助您符合內嵌模型的輸入條件約束。 針對非向量案例，您可能會有聊天樣式的搜尋應用程式，其中 GPT 會組合來自已編製索引區塊的回應。 您可以使用向量化或非向量化區塊進行聊天樣式搜尋。

  • 建置向量存放區，其中所有欄位都是向量欄位，而文件識別碼 (搜尋索引的必要項目) 是唯一的字串字位。 查詢向量存放區以擷取文件識別碼，然後將文件的向量欄位傳送至另一個模型。

  • 結合向量和文字欄位以進行混合式搜尋，無論是否包含語意排名。 整合向量化可簡化向量搜尋支援的所有案例 (部分機器翻譯)。

使用整合向量化的時機

我們建議使用 Azure AI Studio 內建的向量化支援。 如果此方法不符合您的需求，您可以使用 Azure AI 搜尋服務的程式設計介面來建立能叫用整合向量化的索引子和技能。

如何使用整合向量化

針對僅限查詢的向量化：

  1. 將向量化工具新增至 (部分機器翻譯) 索引。 其應該是與用來在索引中產生向量的內嵌模型相同的內嵌模型。
  2. 將向量化工具指派給向量設定檔，然後將向量設定檔指派給向量欄位。
  3. 制定向量查詢 (部分機器翻譯)，以指定要向量化的文字字串。

其中一個更常見的案例：索引編製期間的資料區塊化和向量化：

  1. 針對支援的資料來源建立資料來源 (部分機器翻譯) 連線，以進行索引子型索引編製。
  2. 建立呼叫文字分割技能的技能以進行區塊化，以及 AzureOpenAIEmbeddingModel 或另一項內嵌技能來對區塊進行向量化。
  3. 建立針對查詢時間指定向量化工具 (部分機器翻譯) 的索引 (部分機器翻譯)，並將其指派給向量欄位。
  4. 建立索引子 (部分機器翻譯) 以透過索引編製來驅動從資料擷取到技能執行的所有項目。 建議您依照排程執行索引子，以挑選已變更的文件或因節流而遺漏的任何文件。

選擇性地，針對進階案例建立次要索引，其中已區塊化的內容會位於一個索引中，而非區塊化的內容會位於另一個索引中。 已區塊化索引 (或次要索引) 對於 RAG 應用程式來說很實用。

提示

在 Azure 入口網站中嘗試新的 [Import and vectorize data] \(匯入並向量化資料\) 精靈 (部分機器翻譯)，以在撰寫任何程式碼之前探索整合向量化。

保護向量化工具和模型的連線

如果您的架構需要略過網際網路的私人連線，您可以在查詢期間建立技能在編製索引和向量化工具期間所使用的內嵌模型共用私人連結連線。

共用私人連結僅適用於 Azure 對 Azure 連線。 如果您要連線到 OpenAI 或其他外部模型，則連線必須透過公用網際網路進行。

針對向量化案例，您會使用：

  • openai_account 用於內嵌裝載在 Azure OpenAI 資源上的模型。

  • sites 會將存取的模型內嵌為自訂技能或自訂向量化工具。 sites 群組識別碼適用於應用程式服務和 Azure Functions，您可以用來裝載非 Azure OpenAI 內嵌模型的內嵌模型。

限制

請確定您了解 Azure OpenAI 針對內嵌模型的配額和限制 (部分機器翻譯)。 Azure AI 搜尋服務具有重試原則，但如果配額用盡，重試就會失敗。

Azure OpenAI 每分鐘語彙基元限制是針對每個訂用帳戶的每個模型。 如果您同時針對查詢和索引編製工作負載使用內嵌模型，請記住這一點。 可能的話，請遵循最佳做法 (部分機器翻譯)。 針對每個工作負載使用個別的內嵌模型，並嘗試在不同的訂用帳戶中加以部署。

在 Azure AI 搜尋服務上，請記住層級和工作負載都具有個別的服務限制 (部分機器翻譯)。

整合向量化的優點

以下是整合向量化的一些主要優點：

  • 沒有個別的資料區塊化和向量化管線。 程式碼較容易撰寫和維護。

  • 自動化的端對端索引編製。 當來源 (例如在 Azure 儲存體、Azure SQL 或 Cosmos DB 中) 的資料變更時，索引子可以透過選擇性的 AI 擴充、資料區塊化、向量化和索引編製，透過整個管線 (從擷取到文件萃取) 來移動那些更新。

  • 批次處理和重試邏輯是內建的 (不可設定)。 Azure AI 搜尋具有內部重試原則，以便節流因 Azure OpenAI 端點超出內嵌模型的權杖配額而出現的錯誤。 我們建議將索引子放在排程上 (例如每 5 分鐘一次)，儘管有重試原則，索引子都能處理 Azure OpenAI 端點所節流的任何呼叫。

  • 將區塊化內容投影到次要索引。 次要索引的建立方式，和任何搜尋索引的建立方式都相同 (具有欄位和其他建構的結構描述)，但是其會由索引子搭配主要索引一起填入。 來自每個來源文件的內容，會在相同的索引編製執行期間流向主要和次要索引中的欄位。

    次要索引適用於問答或聊天樣式應用程式。 次要索引包含更特定相符項目的細微資訊，但父索引有更多資訊，且通常可能會產生更完整的答案。 在次要索引中找到相符項目時，查詢會從主要索引傳回父文件。 例如，假設使用一個大型 PDF 做為來源文件，主要索引可能會有基本資訊 (標題、日期、作者、描述)，而次要索引則具有可搜尋內容的區塊。

下一步