通过

检索增强生成 (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 服务或 Azure OpenAI）来转换数据以放入向量搜索或语义搜索数据库。

当使用 AI 服务时，网络对等互连会始终通过服务的专用终结点使其可用（通过中心或直接）。 出于治理、安全性和合规性原因，数据转换组件有权确定为 LLM 工作负荷向搜索数据库提供哪些数据以及以何种格式提供。

数据转换组件可以使用各种数据源为 LLM 工作负荷所依赖的搜索数据库提供具有最佳结果的数据。 这些数据源可以是 SQL 数据库、数据湖，甚至可以是托管自定义数据解决方案的虚拟机，具体取决于客户环境。

数据源应不会由业务流程协调程序应用直接访问，但这些资源应仅在虚拟网络的专用边界内可用。 这将要求直接集成 Microsoft Azure 虚拟网络（例如，使用 VM）、专用链路服务或虚拟网络服务终结点（仅当专用链接或直接虚拟网络集成不可用时）。

AI 和 LLM 相关组件应作为工作负荷托管在公司或在线管理组下其自己的订阅中（取决于是否需要公共访问）。 这些组件包括：

Azure OpenAI 服务 封装了 GPT 等 LLM 和 Ada 等文本嵌入的操作，使其可以通过 Azure OpenAI 提供给 Orchestrator 应用程序的标准 API 进行访问。

业务流程协调程序应用作为前端，具有基于 API 或 UX 的接口，并协调构建基于 RAG 的体验所需的不同步骤。 通常它是一个 Web 应用程序或 Web API。 这些步骤通常包括：

  • 从语义搜索引擎拉取数据作为提示基础
  • 从数据源拉取数据作为提示基础
  • 将不同的请求正确链接到 LLM

Orchestrator 应用程序会维护发送的请求和收到的响应的历史记录，以确保 Azure OpenAI 服务根据之前的交互进行接地。 例如，在 ChatGPT 或 Bing Chat 等类似聊天的体验中，业务流程协调程序应用会维护或缓存对话式会话的历史记录，让 LLM 服务后端在对话流中加以考虑。

在在线环境中，业务流程协调程序应用终结点应是唯一通过受 Web 应用程序防火墙和 DDoS 防护服务保护的公共终结点提供的终结点。 如果托管在公司环境中，没有公共终结点，业务流程协调程序托管在直接集成到虚拟网络的服务上（如虚拟机或 VM 规模集），或者使用支持专用链接或虚拟网络服务终结点的服务（如 Azure 应用服务）。

Search Services 以经过优化的格式提供来自各种数据源的数据，以便有效地使用 LLM 服务。 Microsoft 建议将矢量化和语义搜索相结合，以实现基于搜索服务的提示基础的最佳效果，其由 Azure AI 搜索提供支持。 使用语义排名可以通过使用语言理解对搜索结果进行排名，显著提高搜索的相关性。 这改善了 RAG 应用程序的用户体验，因为在向 LLM 发送请求之前，通过来自搜索服务的更好的搜索结果，提示基础会变得更加准确。

AI 服务的组合可用于通过业务流程协调程序为最终用户创建自定义体验，或优化数据引入过程。 想象一下，使用 Azure AI 文档智能等表单识别器服务从表单中提取结构化信息，并有效地处理和汇总用户输入。 然后，此服务可以与 LLM 协作，从那些已识别的表单输入汇总关键发现结果。 另一个场景涉及使用文档识别器服务将各种格式的文档（如 PDF 或 word 文档）转换为文本。 随后，LLM 文本嵌入服务可以将识别出的文本矢量化以进行进一步分析。

为所有组件部署专用链接服务 ，以便只能在专用环境中访问所有服务。 唯一的例外可能是业务流程协调程序应用，如果托管在在线登陆区域，可能在 Web 应用程序防火墙或类似服务之后公开提供。

基础结构组件

基础结构组件可以作为工作负荷的一部分托管，或在中心或标识订阅中集中托管。

主权登陆区域实施的中央基础结构组件是平台连接中心，它是每个主权登陆区域部署提供的虚拟网络。 它被放在平台管理组内的连接订阅中。

共享网络组件 放置在中心虚拟网络中。 这些组件通常包括：

  • ExpressRoute 线路 或 VPN 网关 ，用于连接到公司、机构或组织的企业网络。

  • 可以使用设备或 Azure Firewall 产品的组合（包括 Web Application Firewall）来实施防火墙 。 这些解决方案支持流量检查、筛选和路由。

  • DDoS 防护 组件，用于保护工作负载免受分布式拒绝服务攻击。

  • 私有 DNS 区域 ，适用于整个虚拟数据中心环境中使用的所有类型的服务，并通过登录区域实现。

  • 虚拟网络对等互连 ，用于通过中心网络连接各种工作负载（如数据源、转换和 LLM 组件）的虚拟网络。

  • 策略 可根据需要控制通过 Hub 防火墙的流量。

注意事项

参考体系结构图显示了一个有代表性的示例体系结构，包含主权登陆区域背景下基于 LLM RAG 的工作负荷的典型组件。 有几个注意事项需要记住，在前几节中没有介绍。

符合架构良好的框架和云采用框架的原则

在前几节中，简要介绍了与架构良好的框架 (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 集群、专用链接或虚拟网络服务终结点。 虚拟网络服务终结点应尽可能由专用链接替代。

除了封装之外，还必须禁用所有服务的公共访问。 最后，应该启用使用 Azure Policy 的策略实施，以永远不会为无法建立相应拒绝策略的服务意外启用公共访问。 深层防御策略会为所有服务启用相应的审核功能。

静态和传输中加密

Azure 中的大多数服务都支持传输中加密和静态加密功能。 可用时，为所有服务启用静态和传输中加密。 启用最新的 TLS 版本（当前为 TLS 1.2）进行传输加密。

托管标识

对所有服务和服务到服务通信使用托管标识，以避免管理凭据的机密。

Key Vault 中的密钥轮换

每当需要证书等安全资产时，在 Key Vault 中为这些机密启用密钥轮换，以保持合规性。

网络与应用程序安全组

在有主权的安全环境中，强制使用网络安全组 (NSG) 和应用程序安全组 (ASG)。 缺少安全组会导致部署不合规。 通常的 SSL 端口对 LLM/RAG 工作负荷所依赖的大多数服务都很有用，因为它们基于 HTTPS。 从源到搜索和矢量数据库的数据引入需要特定端口。 公司登陆区域中不允许使用公共 IP。 所有服务必须只能在虚拟网络中访问，这需要使用专用链接或虚拟网络服务终结点来提供 PaaS 服务。

更多安全和主权护栏

前面几节中针对您的基础结构和应用程序设计介绍的最重要和最明显的护栏即使在主权或 Azure 登陆区域之外也可以重复使用。 其他全局策略与集中管理的资源关联，如 Log Analytics 工作区或企业级登陆区域中的 Microsoft Sentinel 部署。 在基础结构和应用程序设计过程中，考虑这些集中管理的资源至关重要。 忽视这些可能会导致部署后付出额外的工作量和时间。 所幸，Azure 的策略合规功能可以在部署后识别不合规的资源。 而且，主权和 Azure 登陆区域都为大量资源提供 DeployIfNotExists 策略，从而进一步简化了此过程。

此类护栏的一些示例如下：

  • 激活登录到集中管理的 Log Analytics 工作区。

  • 与 Azure 安全中心或 Microsoft Defender for Cloud 集成。

  • 与安全信息和事件管理 (SIEM) 套件（如 Microsoft Sentinel）集成。

  • 与集中管理的防火墙、Web 应用程序防火墙或 DDoS 防护集成。

这些只是您在初始部署后可能确定为要求的几个护栏。 我们建议您在测试登陆区域测试您的部署，并将这些护栏的实现迭代集成到您的基础结构和应用程序代码库中。 如果这不能完全实现，可以使用 DeployIfNotExists 策略在部署后处理其中的很多护栏。

部署此场景

要在主权登陆区域内利用基于检索增强生成 (RAG) 模式的大型语言模型 (LLM) 和 Azure OpenAI，您需要首先部署和配置主权登陆区域 (SLZ)，并应用主权基准计划。 有关 SLZ 及其所有功能的详细概述，请参阅 GitHub 上的主权登陆区域文档。

SLZ 提供了一个环境，通过策略和策略集、安全强制执行以及用于部署工作负荷和应用程序的一致基准基础结构来提供护栏。 SLZ 基于 Azure 登陆区域，并通过特定于主权要求的防护和安全控制对其进行扩展。

为了帮助客户加快实现价值的速度，同时帮助他们实现合规性目标，Microsoft Cloud for Sovereignty 包括可以以可重复方式一致地部署和操作的即用型工作负荷模板。 这些工作负荷模板与主权基准策略计划、Cloud for Sovereignty 策略组合和 Azure 登陆区域默认策略保持一致。

信息助手代理模板

信息助手代理模板为组织构建自己的自定义生成式 AI 功能提供了一个起始指向，以将 Azure OpenAI 的功能扩展到组织用户及其域数据，而无需微调模型。 您可以在 Cloud for Sovereignty 中部署它，并将它与本文中提供的参考体系结构和指南保持一致。 代理模板助手信息与使用 安全模式 部署配置的 Sovereign Landing Zone Online 管理组范围兼容。 即将推出对 Corp 管理组范围的支持。

代理模板是代码、文档和教育资源的组合，免费提供给客户和合作伙伴，有助于加快价值实现速度。

有关如何部署和配置 Information 助手的更多信息，请参阅 GitHub 上的 Information 助手代理模板 文档。 有关您可以使用此代理模板实现的使用案例，请参阅 信息助手视频。