共用方式為

擷取擴增生成 (RAG) 模式中的 LLM 和 Azure OpenAI (預覽版)

  • 發行項

重要

這是預覽功能。 此資訊涉及預先發行功能，可能會在正式發行前大幅修改。 對於此處提供的資訊，Microsoft 不做任何明示或默許的擔保。

本文提供在擷取擴增生成 (RAG) 模式內容中使用大型語言模型 (LLM) 和 Azure OpenAI 的說明性範例。 具體來說，其中探討如何在主權著陸區域中運用這些技術，同時也對重要的護欄進行考量。

案例

常見案例是使用 LLM，透過擷取擴增生成 (RAG) 模式使用您自己的資料來參與交談。 此模式可讓您利用 LLM 的推理能力，並根據您的特定資料產生回應，無需對模型進行微調。 有助於將 LLM 緊密整合至您現有的商務程序或解決方案中。

Cloud for Sovereignty - AI 和 LLM 參考架構

Microsoft Cloud for Sovereignty 提供參考架構，說明主權登陸區域 (SLZ) 中的一般擷取擴增生成 (RAG) 架構。 其中概述一般和建議的實作技術選擇、術語、技術原則、通用設定環境以及適用服務的組合。

主權 AI 及 LLM 設定的參考架構。

下載此參考架構圖的可列印 PDF。

關鍵階段/資料流程如下所示：

應用程式登陸區域

在管理群組階層中，這些服務放置在非機密管理群組內的訂閱中。

資料來源和轉換管線

資料來源和轉換管線通常存在於組織中，以用於業務範圍營運。 將 LLM 應用程式 (例如 RAG 實作) 與現有資料整合時，這些應用程式會成為新的工作負載。

為了確保資料流程控制，參考架構建議資料來源使用與資料網域保持一致的資料登陸區域，並將資料轉換管線放置在靠近這些資料來源的位置，以建立 LLM 應用程式所使用的資料產品。 此方法可確保精確管理佈建至單獨託管 LLM 架構解決方案的資料。

資料轉換元件利用不同的技術和服務，將資料轉換成一種格式，基於 LLM 的應用程式會透過語義或向量搜尋來搜尋和使用這這種格式。 這些管線可以獨立運作，也可以使用 AI 服務 (例如 Azure AI 服務或 OpenAI) 轉換要放入向量搜尋或語意搜尋資料庫的資料。

使用 AI 服務時，網路對等互連一律透過其私人端點提供這些服務 (透過中樞或直接使用)。 基於治理、安全性和合規性原因，資料轉換元件有權決定向 LLM 工作負載的搜尋資料庫提供哪些資料以及以何種格式提供。

資料轉換元件可以使用各種類型的資料來源向 LLM 工作負載所依賴的搜尋資料庫提供結果最佳的資料。 視客戶環境而定，這些資料來源可以是 SQL 資料庫、資料湖，甚至是代管自訂資料解決方案的虛擬機器。

協調器應用程式不能直接存取資料來源，而是這些資源只能從虛擬網路的私人邊界內提供。 這會強制直接整合 Microsoft Azure 虛擬網路 (例如，VM 的情況也是如此)、Private Link 服務或虛擬網路服務端點 (僅限在 Private Link 或直接虛擬網路整合無法使用時)。

AI 和 LLM 相關元件應做為工作負載託管在其本身位於公司或線上管理群組下的訂閱中 (取決於是否需要公用存取)。 這些元件是：

Azure OpenAI 服務封裝 LLM (例如 GPT) 和文字內嵌 (例如 Ada) 的作業，使其可透過 OpenAI 提供的標準 API 來存取協調器應用程式。

協調器應用程式做為提供 API 或 UX 介面的前端，並協調整合建置基於 RAG 之體驗所需的不同步驟。 通常是 Web 應用程式或 Web API。 這些步驟通常包括：

  • 從語意搜尋引擎提取資料以進行提示錨定
  • 從資料來源中提取資料以進行提示錨定
  • 將不同的要求正確鏈結至 LLM

協調器應用程式維護發送要求和接收回應的歷程記錄，以確保 Azure OpenAI 服務根據先前的互動進行錨定。 例如，在類似聊天的體驗 (例如 ChatGPT 或 Bing 聊天) 中，調協器應用程式維護或快取交談工作階段的歷程記錄，讓 LLM 服務後端在交談流程中加以考量。

在線上環境中，協調器應用程式端點必須是唯一透過受 Web 應用程式防火牆和 DDoS 防護服務保護的公用端點提供的端點。 如果託管於沒有公用端點的公司環境中，則協調器不是在直接整合至虛擬網路的服務 (例如虛擬機器或 VM 擴展集) 上託管，就是使用支援 Private Link 或虛擬網路服務端點的服務 (與 Azure App Services 的情況一樣)。

搜尋服務以最佳化格式提供各種資料來源的資料，以便有效率地用於 LLM 服務的提示錨定。 微軟提出向量化與語意搜尋的組合，以在搜尋服務 (由 Azure AI 搜尋支援) 的基礎上取得提示錨定的最佳效果。 使用語意排名可使用語言理解對搜尋結果進行排名，以適度改善搜尋相關性。 這會改善 RAG 應用程式的使用者體驗，因為在發送要求至 LLM 之前，透過搜尋服務獲得更好的搜尋結果，提示錨定變得更加準確。

您可以使用 AI 服務的組合，透過協調器為終端使用者建立自訂體驗，或最佳化資料擷取程序。 想像一下，使用表單識別器服務 (例如 Azure AI 文件情報) 從表單擷取結構化資訊，有效率地處理和彙總使用者輸入。 此服務可接著與 LLM 共同作業，以彙總這些已辨識表單輸入的主要發現。 另一個案例涉及使用文件識別器服務將各種格式的文件 (例如 PDF 或 Word 文件) 轉換成文字。 LLM 文字內嵌服務隨後可以將這段已辨識文字向量化以供進一步分析。

Private Link 服務針對所有元件進行部署，讓所有服務都只能在私人環境中存取。 唯一的例外可能是協調器應用程式，如果將其託管於線上登陸區域中，則可能會在 Web 應用程式防火牆或類似服務背後公開提供。

基礎結構元件

基礎結構元件可以做為工作負載的一部分託管，也可以集中託管於中樞或身分識別訂閱。

主權登陸區域實作的中央基礎結構元件是平台連接中樞，這是每個主權登陸區部署提供的虛擬網路。 該元件放置在平台管理群組內的連線能力訂閱中。

共用網路元件放置在中樞虛擬網路中。 這些元件通常包括：

  • ExpressRoute 線路或 VPN 閘道，用於連線至公司、機構或組織的公司網路。

  • 防火牆可以使用設備或 Azure 防火牆供應項目組合 (包括 Web 應用程式防火牆) 進行實作。 這些解決方案支援流量檢查、篩選和路由。

  • DDoS 保護元件，用於保護工作負載免受分散式阻斷服務攻擊。

  • 私人 DNS 區域，適用於透過登陸區域實作的整個虛擬資料中心環境使用的所有類型的服務。

  • 虛擬網路對等互連，用於透過中樞網路連接各種工作負載 (例如資料來源、轉換和 LLM 元件) 的虛擬網路。

  • 原則在需要時控制通過中樞防火牆的流量。

考量因素

參考架構圖顯示代表性範例架構，涉及主權登陸區域內容中以 LLM RAG 為基礎之工作負載的一般元件。 有幾個要注意的考量事項，前面幾節沒有介紹這些事項。

與 Well-Architected Framework 和雲端採用架構中的原則保持一致

在先前章節中，已簡要提及一些與 Well-Architected Framework (WAF) 和雲端採用架構 (CAF) 相關的一致性層面。 請務必注意，所有架構決策都必須完全符合 CAF 和 Azure 登陸區域、CAF 雲端規模分析和 WAF 的核心原則，包括有關 Azure OpenAI 的 WAF 觀點。

雖然處理護欄是登陸區域環境中的標準程序，但對於 LLM 和 AI 工作負載，必須在多個方面進行其他考量。 設計和定義工作負載訂閱的基礎結構時，最好遵循 Azure 安全性基準合規性和主權基準原則計畫標準。

對於這些標準中以 LLM RAG 為基礎的應用程式，要強調的首要考量事項如下：

資料落地和區域選擇

主權對資料落地提出嚴格需求，因此可能會將部署限制在 SLZ 中的特定 Azure 區域。 為 LLM 工作負載選擇區域受所需服務可用性的限制：

  • 驗證 Azure OpenAI 和 Azure AI 搜尋是否可在您基於資料落地和/或鄰近性原因而託管資料和工作負載的目標區域中使用。 此外，從效能角度來看，這些服務對終端使用者的應用程式體驗非常重要。

  • 其次，在查看 Azure OpenAI 時，個別 LLM 模型的可用性也很重要，因為並非所有模型在所有區域中都同樣可用。

  • 如果資料來源或其他認知服務在指定的目標區域中無法使用，則可以根據資料落地需求在其他區域中尋找和操作。 不過，基於效能原因，Azure OpenAI 服務和 Azure AI 搜尋必須與協調器應用程式位於相同區域。

網路

公司環境中不允許公用端點。 因此，所有服務都必須封裝在虛擬網路中。 視服務而定，可能會提供直接封裝功能，例如 VM 或 AKS 叢集、Private Link 或虛擬網路服務端點。 最好盡可能以 Private Link 取代虛擬網路服務端點。

除了封裝之外，還必須為所有服務停用公用存取。 最後，必須啟用使用 Azure 原則的原則強制，絕不能讓無法建立相應拒絕原則的服務，意外啟用公用存取。 縱深防禦策略的目的是要為所有服務啟用相應的稽核功能。

待用和傳輸中加密

Azure 中的大多數服務都支援傳輸中和待用加密功能。 在所有服務 (如果可用) 中啟用待用加密和傳輸中加密。 啟用最新 TLS 版本 (目前為 TLS 1.2) 以進行傳輸加密。

受控識別

對所有服務和服務到服務通訊使用受控識別，以避免管理認證的祕密。

Key Vault 中的金鑰變換

每當需要憑證等安全性資產時，都要為 Key Vault 中的這些祕密啟用金鑰變換，以保持合規性。

網路和應用程式安全性群組

在擁有主權的安全環境中，強制使用網路安全性群組 (NSG) 和應用程式安全性群組 (ASG)。 缺少安全性群組會導致部署不符合規範。 一般 SSL 連接埠對於 LLM / RAG 工作負載所依賴的大多數服務都很有用，因為這些連接埠以 HTTPS 為基礎。 從來源到搜尋及向量資料庫的資料擷取需要特定的連接埠。 公司登陸區域中不允許公用端點。 所有服務都必須只能在虛擬網路中存取，這需要為 PaaS 服務使用 Private Link 或虛擬網路服務端點。

更多的安全性和主權護欄

前面章節中介紹基礎結構和應用程式設計的最重要和最明顯護欄，即使在主權或 Azure 登陸區域之外也可以重複使用。 其他全域原則已繫結至集中管理資源，例如企業級登陸區域中的 Log Analytics 工作區或 Microsoft Sentinel 部署。 在基礎結構和應用程式設計程序中，將這些集中管理資源納入考量至關重要。 如果忽略這一點，就會在部署後花費更多的精力和時間。 值得慶幸的是，Azure 的原則合規性功能可以在部署後識別不符合規範的資源。 此外，主權和 Azure 登陸區域皆為大量資源提供 DeployIfNotExists 原則，進一步簡化此程序。

以下是一些此類護欄的範例：

  • 啟動對集中管理 Log Analytics 工作區的記錄功能。

  • 與 Azure 資訊安全中心或適用於雲端的 Microsoft Defender 整合。

  • 與安全性資訊與事件管理 (SIEM) 套件 (例如 Microsoft Sentinel) 整合。

  • 與集中管理防火牆、Web 應用程式防火牆或 DDoS 保護整合。

這些只是幾個可能在初次部署後確定為需求的護欄。 建議您在測試登陸區域中測試部署，並反覆將這些實現的護欄整合到基礎結構和應用程式的程式碼基底中。 如果這並非完全可行，則可以在部署後使用 DeployIfNotExists 原則解決其中許多護欄。

部署此案例

若要在主權登陸區域中利用大型語言模型 (LLM) 以及基於擷取擴增生成 (RAG) 模式的 Azure OpenAI，您首先必須部署和設定主權登陸區域 (SLZ)，並套用主權基準原則計劃。 如需有關 SLZ 及其所有功能的詳細概觀，請參閱 GitHub 上的主權登陸區域文件。

SLZ 提供一個環境，其中透過原則和原則集、安全性強制以及用於部署工作負載和應用程式的一致基準基礎結構來提供護欄。 SLZ 是以 Azure 登陸區域為基礎建立，並透過特定主權需求的相關護欄及安全性控制項進行擴充。

為了協助客戶縮短價值實現時間，同時協助他們達成合規性目標，Microsoft Cloud for Sovereignty 提供可隨時使用的工作負載範本，這些範本可以透過可重複的方式進行一致部署和操作。 工作負載範本遵循主權基準原則計劃、Cloud for Sovereignty 原則組合和 Azure 登陸區域預設原則進行調整。

資訊小幫手加速器

資訊小幫手是解決方案加速器，為組織提供一個自行建置自訂生成式 AI 功能的起點，以將 Azure OpenAI 的強大功能擴展到組織使用者及其私人網域資料。 您可將其部署在 Cloud for Sovereignty 中，並遵循本文中提供的參考架構和指引進行調整。 建議您將此加速器部署在內部工作負載的公司登陸區域中，並遵循指引，安全地部署至線上登陸區域以供公用存取。

加速器是免費提供給客戶和合作夥伴的程式碼、文件與教育資源組合，可協助加快價值實現時間。

如需有關如何部署和設定資訊小幫手加速器的詳細資訊，請參閱 GitHub 上的資訊小幫手文件。 如需可使用此加速器實現的使用案例，請參閱資訊小幫手影片。