Azure Databricks 上的 RAG (擷取擴增產生)

代理程式架構由 Databricks 上的一套工具組成，旨在協助開發人員建立、部署和評估生產品質的 AI 代理程式，例如 檢索增強生成 (RAG) 應用程式。

本文涵蓋什麼是 RAG，以及在 Azure Databricks 上開發 RAG 應用程式的優點。

代理程式架構可讓開發人員使用端對端 LLMOps 工作流程，快速逐一查看 RAG 開發的所有層面。

需求

• 您必須為工作區啟用 Azure AI 支援的 AI 輔助功能。
• 代理程式應用程式的所有元件都必須位於單一工作區中。 例如，在 RAG 應用程式的情況下，服務模型和向量搜尋執行個體必須位於相同的工作區中。

什麼是 RAG?

RAG 是一種生成式 AI 設計技術，可增強具有外部知識的大型語言模型 (LLM)。 這項技術會以下列方式改善 LLM：

• 專屬知識：RAG 可以包含最初不用來訓練 LLM 的專屬資訊，例如備忘、電子郵件和文件，以回答特定領域問題。
• 最新資訊：RAG 應用程式可以提供 LLM 來自更新資料來源的資訊。
• 引用來源：RAG 可讓 LLM 引用特定來源，讓使用者驗證回應的事實正確性。
• 資料安全性和存取控制清單 (ACL)：檢索取步驟的設計目的是根據使用者認證選擇性地檢索個人或專屬資訊。

複合式 AI 系統

RAG 應用程式是複合式 AI 系統的範例：它會結合 LLM 與其他工具和程式來擴充 LLM 的語言功能。

最簡單的形式是 RAG 應用程式會執行下列動作：

1. 檢索： 使用者的要求可用來查詢外部資料存放區，例如向量存放區、文字關鍵字搜尋或 SQL 資料庫。 目標是取得 LLM 回應的佐證資料。
2. 增強：檢索的資料會與使用者的要求結合，通常會使用具有其他格式和指示的範本來建立提示。
3. 生成： 提示會傳遞至 LLM，然後生成查詢的回應。

非結構化與結構化 RAG 資料

RAG 架構可以搭配非結構化或結構化佐證資料使用。 您搭配 RAG 使用的資料取決於您的使用案例。

非結構化資料： 沒有特定結構或組織的資料。 包含文字和影像或多媒體內容的文件，例如音訊或視訊。

• PDF
• Google/Office 文件
• Wiki
• 影像
• 影片

結構化資料： 以特定結構描述排列的資料列和資料行中的表格式資料，例如資料庫中的資料表。

• BI 或資料倉儲系統中的客戶記錄
• 來自 SQL 資料庫的事務資料
• 從應用程式 API 的資料 (例如 SAP、Salesforce 等)

下列各節說明非結構化資料的 RAG 應用程式。

RAG 資料管線

RAG 資料管線會預先處理和編製索引檔，以便快速且準確地檢索。

下圖顯示使用語意搜尋演算法之非結構化資料集的範例資料管線。 Databricks 作業會協調每個步驟。

1. 資料擷取 - 從專屬來源擷取資料。 將此資料儲存在 Delta 資料表或 Unity 目錄磁碟區中。
2. 文件處理：您可以使用 Databricks 作業、Databricks 筆記本和差異即時資料表來執行這些工作。
   • 剖析原始文件： 將原始資料轉換成可使用的格式。 例如，從 PDF 集合擷取文字、資料表和影像，或使用光學字元辨識技術從影像擷取文字。
   • 擷取中繼資料：擷取文件中繼資料，例如文件標題、頁碼和網址，以更準確地協助檢索步驟查詢。
   • 區塊文件：將資料分割成符合 LLM 內容視窗的區塊。 檢索這些焦點區塊，而不是整個文件，可讓 LLM 更具針對性的內容來產生回應。
3. 內嵌區塊 - 內嵌模型會取用區塊，以建立稱為向量內嵌之資訊的數值表示法。 向量代表文字的語意意義，而不只是表面層級關鍵字。 在此案例中，您會計算內嵌，並使用模型服務來提供內嵌模型。
4. 內嵌記憶體 - 將向量內嵌和區塊的文字儲存在與向量搜尋同步的差異資料表中。
5. 向量資料庫 - 作為向量搜尋的一部分，內嵌和中繼資料會編製索引並儲存在向量資料庫中，以供 RAG 代理程式輕鬆查詢。 當使用者進行查詢時，其要求會內嵌到向量中。 然後，資料庫會使用向量索引來尋找並傳回最類似的區塊。

每個步驟都牽涉到會影響 RAG 應用程式品質的工程決策。 例如，在步驟 (3) 中選擇正確的區塊大小可確保 LLM 會收到特定但內容化的資訊，同時在步驟 (4) 中選取適當的內嵌模型，可決定檢索期間傳回的區塊正確性。

Databricks 向量搜尋

計算相似度通常會耗費大量計算成本，但 Databricks 向量索引等向量搜尋會透過有效率地組織內嵌來最佳化這一點。 向量搜尋會快速排名最相關的結果，而不會個別比較每個內嵌與使用者的查詢。

向量搜尋會自動同步新增至差異資料表的新內嵌，並更新向量搜尋索引。

什麼是 RAG 代理程式？

檢索增強生成 (RAG) 代理程式是 RAG 應用程式的關鍵部分，可整合外部資料檢索來增強大型語言模型 (LLM) 的功能。 RAG 代理程式會處理使用者查詢、從向量資料庫檢索相關資料，並將此資料傳遞至 LLM 以產生回應。

LangChain 或 Pyfunc 之類的工具會透過連接輸入和輸出來連結這些步驟。

下圖顯示聊天機器人的 RAG 代理程式和用來建置每個代理程式的 Databricks 功能。

1. 查詢前置處理 - 使用者提交查詢，然後預先處理，使其適合查詢向量資料庫。 這可能牽涉到將要求放在範本中，或擷取關鍵字。
2. 查詢向量化 - 使用模型服務，使用用來在資料管線中內嵌區塊的相同內嵌模型來內嵌要求。 這些內嵌可讓您比較要求與前置處理區塊之間的語意相似度。
3. 檢索階段 - 檢索程式 (負責擷取相關資訊的應用程式) 會採用向量查詢，並使用向量搜尋執行向量相似度搜尋。 最相關的資料區塊會根據其與查詢的相似性來排名和檢索。
4. 提示增強 - 檢索程式會結合檢索的資料區塊與原始查詢，以提供 LLM 的其他內容。 系統會仔細將提示結構化，以確保 LLM 了解查詢的內容。 LLM 通常會有範本來將回應格式化。 調整提示的這個程序稱為提示工程。
5. LLM 生成階段 - LLM 會使用檢索結果所擴充的增強查詢來產生回應。 LLM 可以是自訂模型或基礎模型。
6. 後續處理 - LLM 的回應可處理以套用其他商業規則、新增引文，或根據預先定義的規則或條件約束來精簡產生的文字

此程式可能會套用各種護欄，以確保符合企業原則。 這可能包括篩選適當的請求、在存取資料來源前檢查使用者權限，以及對產生的回應使用內容管理技術。

生產層級 RAG 代理程式開發

使用下列功能快速迭代代理程式開發：

使用任何程式庫和 MLflow 建立和記錄代理程式。 將代理程式參數化，以快速實驗及迭代代理程式開發。

使用權杖串流和要求/回應記錄的原生支援，以及內建的檢閱應用程式，將代理程式部署至生產環境，以取得代理程式的使用者意見反應。

代理程式追蹤可讓您記錄、分析及比較代理程式程式碼中的追蹤，以偵錯並瞭解代理程式如何回應要求。

評估與監視

評估和監視有助於判斷 RAG 應用程式是否符合您的品質、成本和延遲需求。 評估會在開發期間發生，而監視會在應用程式部署至生產環境時發生。

非結構化資料的 RAG 有許多影響品質的元件。 例如，資料格式化變更可能會影響檢索的區塊，以及 LLM 產生相關回應的能力。 因此，除了整體應用程式之外，請務必評估個別元件。

如需詳細資訊，請參閱什麼是 Mosaic AI 代理程式評估？。

區域可用性

如需代理程式架構的區域可用性，請參閱具有有限區域可用性的功能