檢索增強生成 （RAG） 是一種設計模式，通過添加信息檢索步驟、合併您的專有企業內容來制定答案，從而增強 ChatGPT 等聊天完成模型的功能。 對於企業解決方案，可以將生成式 AI 完全限定於您的企業內容。
使用的資訊擷取系統的決策相當關鍵，因為它會決定 LLM 的輸入。 資訊擷取系統應該提供：
編製索引策略可以按照您需要的頻率大規模載入和重新整理您的所有內容。
查詢功能和相關性微調。 系統應以滿足大型語言模型 （LLM） 輸入的令牌長度要求所需的簡短格式傳回 相關 結果。 查詢處理時間應該盡可能快。
資料和作業的安全性、全域觸達及可靠性。
與用於編製索引的內嵌模型整合，以及用於擷取的聊天模型或語言理解模型。
Azure AI 搜尋服務是 RAG 架構中經過驗證的資訊擷取解決方案。 其提供編製索引和查詢功能，以及 Azure 雲端的基礎結構和安全性。 透過程式碼和其他元件，您可以設計完整的 RAG 解決方案，其中包含透過專屬內容產生 AI 的所有元素。
您可以選擇 RAG 工作負載的兩種方法：代理程式擷取，或傳統 RAG 的原始查詢架構。
附註
不熟悉副手和 RAG 概念嗎？ 觀看向量搜尋及 Generative AI 應用程式的最先進擷取狀態。
具有代理檢索功能的現代 RAG
Azure AI 搜尋服務現在提供 代理程式擷取，這是專為 RAG 模式設計的特殊管線。 這種方法使用大型語言模型，將複雜的使用者查詢智慧地分解為重點子查詢，並並行執行它們，並傳回針對聊天完成模型最佳化的結構化回應。
代理檢索代表了從傳統的單查詢 RAG 模式到多查詢智能檢索的演變，提供：
- 使用對話歷史記錄進行情境感知查詢規劃
- 並行執行多個焦點子查詢
- 具有基礎設置資料、引文和執行中繼資料的結構化回應
- 內建語義排名，實現最佳相關性
- 可選的答案合成使用由 LLM 制定的答案來回應查詢。
你需要為這個流程新增物件：一個或多個知識來源、知識庫，以及你從應用程式代碼呼叫的檢索動作，例如與你的 AI 代理合作的工具。
對於新的 RAG 實作，建議您從 代理程式擷取開始。 對於現有的解決方案，請考慮遷移以利用提高的準確性和上下文理解。
Azure AI 搜尋服務的傳統 RAG 模式
RAG 解決方案可以使用原始查詢執行架構在 Azure AI 搜尋服務上實作。 使用此方法時，您的應用程式會將單一查詢要求傳送至 Azure AI 搜尋服務，搜尋引擎會處理要求，並將搜尋結果傳回給呼叫端。 對於查詢規劃或答案形成，無需繞道給 LLM 來處理。 回應中沒有查詢執行詳細資料，而且只有在索引中有提供父文件名稱或頁面的欄位時，才會將引文內建到回應中。 這種方法更快、更簡單，組件更少。 根據您的應用要求，它可能是最佳選擇。
以 Azure AI 搜尋服務為基礎的傳統 RAG 模式的高階摘要如下所示：
- 從使用者問題或要求開始 (提示)。
- 將它作為查詢要求傳送至 Azure AI 搜尋服務，以尋找相關資訊。
- 將排名最高的搜尋結果傳回 LLM。
- 使用 LLM 的自然語言理解和推理功能來產生初始提示的回應。
Azure AI 搜尋服務提供 LLM 提示字元的輸入，但不會定型模型。 在傳統的 RAG 模式中，沒有額外的訓練。 LLM 會使用公用資料預先定型，但會產生由擷取程式的資訊所增強的回應，在此案例中為 Azure AI 搜尋服務。
包含 Azure AI 搜尋服務的 RAG 模式具有下圖所示的元素。
- 適用於使用者體驗的應用程式 UX (Web 應用程式)
- 應用程式伺服器或協調器 (整合和協調層)
- Azure AI 搜尋服務 (資訊擷取系統)
- Azure OpenAI (適用於生成式 AI 的 LLM)
Web 應用程式提供使用者體驗、提供簡報、內容及使用者互動。 使用者的問題或提示從這裏開始。 輸入會透過整合層，先移至資訊擷取以取得搜尋結果，但也移至 LLM 來設定內容和意圖。
應用程式伺服器或協調器是整合程式碼，可協調資訊擷取與 LLM 之間的交接。 常見的解決方案包括 Azure 語意核心 或 LangChain 來協調工作流程。 LangChain 與 Azure AI 搜尋整合，可讓您更輕鬆地將 Azure AI 搜尋服務作為 擷取器 包含在工作流程中。 LlamaIndex 和 Semantic Kernel 為其他選項。
資訊擷取系統提供可搜尋的索引、查詢邏輯及承載 (查詢回應)。 搜尋索引可以包含向量或非向量內容。 雖然大部分的範例和示範都包含向量欄位，但並非必要的。 查詢是使用 Azure AI 搜尋服務中的現有搜尋引擎來執行，其可以處理關鍵字 (或字詞) 和向量查詢。 系統會根據您定義的結構描述，預先建立索引，並使用您從檔案、資料庫或儲存體來源的內容載入。
LLM 會收到原始提示，以及來自 Azure AI 搜尋服務的結果。 LLM 會分析結果並制訂回應。 如果 LLM 是 ChatGPT，則使用者互動可能包含多個對話回合。 Azure 解決方案最有可能使用 Azure OpenAI，但此特定服務沒有硬性相依性。
Azure 搜尋服務中可搜尋的內容
在 Azure AI 搜尋服務中，所有可搜尋的內容都會儲存在裝載於搜尋服務的搜尋索引中。 搜尋索引是針對具有毫秒響應時間的快速查詢所設計，因此其內部資料結構的存在就是為了支援該目標。 為此，搜尋索引會儲存索引編製內容，而不是整個內容檔案，例如整個 PDF 或影像。 在內部，資料結構包括 標記化文字的反向索引、內嵌的向量索引，以及需要逐字比對情況的未變更純文字 （例如，在過濾器、模糊搜尋、正則運算式查詢中）。
當您設定 RAG 解決方案的資料時，您會使用在 Azure AI 搜尋服務中建立和載入索引的功能。 索引包含重複或代表來源內容的欄位。 索引欄位可能是簡單的轉移 (來源文件中的標題或描述會變成搜尋索引中的標題或描述)，或者欄位可能包含外部流程的輸出，例如產生影像表示法或文字描述的向量化或技能處理。
由於您可能知道想要搜尋的內容類型，請考慮適用於每個內容類型的索引編製功能：
| 內容類型 | 索引編製為 | 特性 |
|---|---|---|
| 收發簡訊 | 權杖、未更改的文字 | 索引器可以從 Azure 儲存體和 Cosmos DB 等其他 Azure 資源提取純文字。 您也可以將任何 JSON 內容推送至索引。 若要修改正式發行前小眾測試版中的文字，請使用分析器和正規化程式，以在編製索引期間新增語彙處理。 如果來源文件缺少可能在查詢中使用的術語，同義字對應會很有用。 |
| 收發簡訊 | 向量 1 | 文字可以在索引子管線進行區塊化和向量化，或在外部進行處理，然後在您的索引中編製為向量欄位的索引。 |
| 圖片 | 權杖、未更改的文字 2 | OCR 和影像分析的技能可以處理文字辨識或影像特性的影像。 技能具有索引子需求。 |
| 圖片 | 向量 1 | 影像可以在索引子管線進行向量化，或在外部進行處理，以數學形式表示影像內容，然後在您的索引中編製為向量欄位的索引。 你可以使用 Azure Vision 多模態 或像 OpenAI CLIP 這樣的開源模型，在同一嵌入空間中向量化文字和圖片。 |
1 Azure AI 搜尋服務會提供整合式資料區塊化和向量化，但您必須依賴索引子和技能集。 如果您無法使用索引子，Microsoft 的語意核心或其他社群供應項目可透過完整的堆疊解決方案協助您。 如需顯示這兩種方法的程式碼範例，請參閱 azure-search-vectors-sample 存放庫。
2 圖像描述被轉換為可搜索的文本並添加到索引中。 影像本身不會儲存在索引中。 技能 是 對應用 AI 的內置支持。 對於圖片描述和語音化，索引流程會內部呼叫 Azure OpenAI 或 Azure Vision。 這些技能會將擷取的影像傳送進行處理，並接收作為經 Azure AI 搜尋服務編製索引的文字輸出。 技能也用於整合資料分塊和內嵌。
向量提供不同內容 (多種檔格式和語言) 的最佳安置方式，因為內容普遍以數學表示形式表達。 向量也支援相似度搜尋：配對最類似於向量查詢的座標。 相較於在標記化字詞上相符的關鍵字搜尋 (或字詞搜尋)，相似度搜尋比較細微。 如果內容或查詢中有模棱兩可或解譯需求，則這是較佳的選擇。
Azure AI 搜尋服務中的內容擷取
一旦您的資料位於搜尋索引中，您就可以使用 Azure AI 搜尋服務的查詢功能來擷取內容。
在非 RAG 模式中，查詢會從搜尋客戶端來回進行。 查詢會被提交，在搜尋引擎上執行，然後將回應傳回給用戶端的應用程式。 回應或搜尋結果只包含索引中找到的逐字內容。
在傳統 RAG 模式中，查詢和回應會在搜尋引擎和 LLM 之間進行協調。 使用者的問題或查詢會以提示轉送至搜尋引擎和 LLM。 搜尋結果會從搜尋引擎傳回，並重新導向至 LLM。 傳回使用者的回應是生成式 AI，可以是 LLM 的加總或答案。
在現代代理程式擷取 RAG 模式中，查詢和回應會與 LLM 整合，以協助查詢規劃和選擇性答案制定。 查詢輸入可以更豐富，包括聊天記錄以及使用者的問題。 LLM 會決定如何設定子查詢，以便為您已編製索引的內容提供最佳涵蓋範圍。 回應不僅包括搜尋結果，還包括查詢執行詳細資訊和來源文件。 您可以選擇性地包括答案組譯，在其他模式中，這發生在查詢管線之外。
以下是 Azure AI 搜尋服務中用來制訂查詢的功能：
| 查詢功能 | 目的 | 使用原因 |
|---|---|---|
| 代理程式搜尋 （預覽版） | 多個子查詢的平行查詢執行管線，傳回專為 RAG 工作負載和代理程式取用者設計的回應。 查詢可以是向量或關鍵字搜尋。 語意排名確保子查詢的最佳結果包含在最終回應結構中。 這是以 Azure AI 搜尋服務為基礎的 RAG 模式的建議方法。 | |
| 關鍵字搜尋 | 對文字和非向量數值內容的查詢執行 | 全文搜尋最適合完全符合，而不是相似符合。 全文搜索查詢會使用 BM25 演算法設定優先權，並支援透過評分設定檔進行相關性微調。 它也支援篩選和 Facet。 |
| 向量搜尋 | 在向量欄位上執行查詢以進行相似性搜尋，其中查詢字串是一個或多個向量。 | 向量可以使用任何語言來代表所有類型的內容。 |
| 混合式搜尋 | 結合上述任何或所有查詢技術。 向量和非向量查詢會以平行方式執行，並在統一的結果集中傳回。 | 精確度和召回率的最顯著提升是透過混合式查詢。 |
| 篩選與 Facet | 僅適用於文字或數值 (非向量) 欄位。 依據包含或排除準則減少搜尋介面區。 | 將精確度新增至您的查詢。 |
建構查詢回應
查詢的回應會提供 LLM 的輸入，因此搜尋結果的品質對於成功至關重要。 結果為表格式資料列集。 結果的組成或結構取決於：
- 決定回應中包含索引部分的欄位。
- 代表索引相符的資料列。
當屬性為「可擷取」時，欄位會出現在搜尋結果中。 索引結構描述中的欄位定義具有屬性，而那些定義會決定是否在回應中使用欄位。 全文或向量查詢結果中只會傳回「可檢索」欄位。 依據預設，會傳回所有「可擷取」欄位，但您可以使用「選取」來指定子集。 除了「可擷取」之外，欄位沒有限制。 欄位可以是任何長度或類型。 關於長度，Azure AI 搜尋服務中沒有欄位長度上限，但有 API 要求的大小限制。
資料列會與查詢相符，並依相關性、相似度或兩者進行排名。 依據預設，結果會限制在全文搜索的前 50 個相符項目，或向量搜尋的 k-near-neighbor 相符項目。 您可以變更預設值，以增加或減少最多 1,000 份文件的限制。 您也可以使用 top 和 skip 分頁參數將結果擷取為一系列分頁結果。
將相關性和召回率最大化
當您處理複雜的流程、大量資料並期望毫秒級回應時，每個步驟都必須增加價值並提高最終結果的品質，這一點至關重要。 在資訊擷取端，相關性微調是一項活動，可改善傳送給 LLM 結果的品質。 只有最相關的或最類似的相符文件應該包含在結果中。
以下是將相關性和召回率最大化的一些秘訣：
混合式查詢，其結合了關鍵詞 (非向量) 搜尋和向量搜尋，讓您在輸入相同時能得到最大的召回率。 在混合式查詢中，如果您在相同的輸入上加倍，文字字串及其向量對等項目會產生平行查詢進行關鍵詞和相似度搜尋，從統一結果集內的每個查詢類型傳回最相關的相符項目。
混合式查詢也可以是廣泛的。 您可以對詳細資訊區塊化內容執行相似度搜尋，也可以對名稱進行關鍵詞搜尋，全都在同一要求中進行。
透過下列方式支援相關性微調：
評分設定檔在特定搜尋欄位中或其他準則中找到相符項目時，會提升搜尋分數。
語意排名工具，其會重新排名初始結果集，方法是使用 Bing 中的語意模型來重新排序結果，以取得更適合原始查詢的語意。
用於微調的查詢參數。 您可以 提高向量查詢的重要性 ，或調整混合式查詢回應中 BM25 排名結果的數量 。 您也可以設定最小閾值，以從向量查詢中排除低評分結果。
在比較和基準測試中，搭配文字和向量欄位的混合式查詢加上語意排名，會產生最相關的結果。
整合程式碼和 LLM
包含 Azure AI 搜尋服務的 RAG 解決方案可以利用內建的資料區塊化和向量化功能，或者您可以使用語意核心、LangChain 或 LlamaIndex 等平台來建置自己的資料區塊化和向量化功能。
我們建議您使用 Azure OpenAI 示範 ，以取得具有 Azure OpenAI 和 Azure AI 搜尋服務的完整堆疊 RAG 聊天應用程式範例。
如何開始使用
有許多方法可以開始使用，包括程式碼優先解決方案和示範。
如需在 Agent 擷取和傳統 RAG 之間進行選擇的協助，請嘗試使用您自己的資料執行一些快速入門作業，以了解開發工作並比較結果。
請嘗試這個主動檢索快速入門，引導您了解 RAG 的新建議的方法。
請嘗試此傳統 RAG 快速入門 ，以示範透過搜尋索引與聊天模型整合查詢。
檢閱索引編製概念和策略以判斷您想要擷取和重新整理資料的方式。 決定是否要使用向量搜尋、關鍵字搜尋或混合式搜尋。 您需要搜尋的內容類型以及要執行的查詢類型決定了索引設計。
檢閱建立查詢以深入了解搜尋要求語法和需求。
附註
某些 Azure AI 搜尋服務功能適用於人為互動，且不適用於 RAG 模式。 具體而言，您可以跳過自動完成和建議等功能。 其他功能，例如 Facet 和 orderby 可能很有用，但在 RAG 情節中並不常見。