你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn

基线 OpenAI 端到端聊天参考体系结构

Azure OpenAI 服务
Azure 机器学习
Azure 应用服务
Azure Key Vault
Azure Monitor

企业聊天应用程序能够通过对话交互来提升员工的能力。 这一点尤其如此,因为语言模型的持续进步,如 OpenAI 的 GPT 模型和 Meta 的 Llama 模型。 这些聊天应用程序包括:

  • 聊天用户界面(UI)。
  • 包含与用户查询相关的特定于域的信息的数据存储库。
  • 导致特定于域的数据生成相关响应的语言模型。
  • 监督组件之间的交互的业务流程协调程序。

本文提供了一个基线体系结构,可帮助你构建和部署使用 Azure OpenAI 服务语言模型的企业聊天应用程序。 体系结构使用提示流来创建可执行流。 这些可执行流协调工作流,从传入的提示到数据存储,以提取语言模型和其他必需的 Python 逻辑的地面数据。 可执行流部署到使用托管计算的托管联机终结点。

自定义聊天 UI 的托管遵循 基线应用服务 Web 应用程序 指南,了解如何在 Azure 应用服务上部署安全、区域冗余和高度可用的 Web 应用程序。 在该体系结构中,应用程序服务通过专用终结点的虚拟网络集成与 Azure 平台即服务 (PaaS) 解决方案通信。 在聊天 UI 体系结构中,应用服务通过专用终结点与托管联机终结点通信。 已禁用对 Azure AI Foundry 门户的公共访问。

重要

本文不介绍 基线应用服务 Web 应用程序中的组件或体系结构决策。 阅读本文,了解有关如何托管聊天 UI 的体系结构指南。

Azure AI Foundry 中心是使用 托管虚拟网络隔离 配置,需要批准所有出站连接。 在此配置中,将创建托管虚拟网络并建立托管专用终结点,以便连接到专用资源,例如工作区 Azure 存储、Azure 容器注册表和 Azure OpenAI。 这些专用连接在流创作和测试期间由部署到 Azure 机器学习计算的流使用。

中心是顶级 Azure AI Foundry 资源,提供一种集中方法,帮助管理多个项目的安全、连接和其他问题。 此体系结构仅需要一个项目用于其工作负荷。 如果有更多的体验需要不同的提示流,这些流使用不同的逻辑和潜在的不同的后端资源(如数据存储),则可以考虑在不同的项目中实现这些体验。

提示

GitHub 徽标。参考实现 展示 Azure 上的基线端到端聊天实现。 在生产的第一步中,你可以使用此实现作为自定义解决方案开发的基础。

体系结构

关系图,显示使用 OpenAI 的基线端到端聊天体系结构。

下载此体系结构的 Visio 文件

组件

此体系结构的许多组件与 基本的 Azure OpenAI 端到端聊天体系结构中的资源相同,。 以下列表突出显示了基本体系结构与基线体系结构之间的差异。

  • Azure OpenAI 用于这两种体系结构。 Azure OpenAI 是一项完全托管的服务,它提供对 Azure OpenAI 语言模型的 REST API 访问权限,包括 GPT-4、GPT-3.5-Turbo 和嵌入模型集。 基线体系结构使用企业功能,例如 虚拟网络和专用链接, 基本体系结构未实现。

  • Azure AI Foundry 是一个平台,可用于生成、测试和部署 AI 解决方案。 此体系结构使用 Azure AI Foundry 门户生成、测试和部署聊天应用程序的提示流业务流程逻辑。 在此体系结构中,Azure AI Foundry 为网络安全提供了 托管虚拟网络。 有关详细信息,请参阅本文中的 网络 部分。

  • Azure 应用程序网关 是第 7 层(HTTP/S)负载均衡器和 Web 流量路由器。 它使用基于 URL 路径的路由跨可用性区域分配传入流量,并卸载加密以提高应用程序性能。

  • Azure Web 应用程序防火墙 是一种云原生服务,可帮助保护 Web 应用免受 SQL 注入和跨站点脚本等常见攻击。 Web 应用程序防火墙可查看传入和传出 Web 应用程序的流量。 此可见性可帮助你监视和保护应用程序。

  • Azure 密钥保管库是可安全存储和管理机密、加密密钥与证书的服务。 它集中管理敏感信息。

  • Azure 虚拟网络 是一项服务,可用于在 Azure 中创建隔离且更安全的专用虚拟网络。 对于应用程序服务上的 Web 应用程序,需要使用虚拟网络子网才能使用专用终结点在资源之间进行网络安全通信。

  • Azure 专用链接 允许客户端直接从专用虚拟网络访问 Azure PaaS 服务,而无需使用公共 IP 地址。

  • Azure DNS 是 DNS 域的托管服务,它使用 Microsoft Azure 基础结构提供名称解析。 专用 DNS 区域提供了一种将服务的完全限定域名 (FQDN) 映射到专用终结点的 IP 地址的方法。

备选方法

此体系结构包括多个组件,这些组件可由其他 Azure 服务提供,这些组件可能更好地符合工作负荷的功能和非功能要求。

机器学习工作区和门户体验

此体系结构使用 Azure AI Foundry 门户 来生成、测试和部署提示流。 或者,可以使用 机器学习工作区。 这两个服务都有重叠的功能。 门户是设计提示流解决方案的好选择,但机器学习目前对某些功能有更好的支持。 有关详细信息,请参阅 详细功能比较。 建议不要混合和匹配门户和机器学习工作室。 如果可在 Azure AI Foundry 门户中完全完成工作,请使用门户。 如果需要机器学习工作室中的功能,请改用工作室。

应用程序层组件

Azure 提供了多个托管应用程序服务,这些服务可用作聊天 UI 前端的应用程序层。 这些服务包括 计算选项容器解决方案。 例如,此体系结构分别对聊天 UI API 和提示流主机使用用于容器的 Web 应用和 Web 应用。 可以使用 Azure Kubernetes 服务(AKS)或 Azure 容器应用来实现类似的结果。 根据工作负荷的特定功能和非功能要求为工作负荷选择应用程序平台。

提示流托管

部署提示流不限于机器学习计算群集。 此体系结构通过应用服务中的替代解决方案来说明这一点。 流最终是可部署到任何与容器兼容的 Azure 服务的容器化应用程序。 这些选项包括 AKS、容器应用和应用服务等服务。 根据业务流程层的要求 选择 Azure 容器服务。

本文稍后将讨论如何考虑在备用计算上部署提示流托管的示例。

地面数据存储

此体系结构以 AI 搜索为线索,但你选择用于基础数据的数据存储是特定于工作负荷的体系结构决策。 许多工作负载使用多种语言,并且具有不同的源和技术来建立数据。 这些数据平台包括现有的联机事务处理数据存储、Azure Cosmos DB 等云原生数据库,以及 AI 搜索等专用解决方案。 矢量搜索是此类数据存储的一个常见特征,但这不是必需的。 有关详细信息,请参阅 为矢量搜索选择 Azure 服务

考虑

这些注意事项实施 Azure 架构良好的框架的支柱原则,即一套可用于改进工作负荷质量的指导原则。 有关详细信息,请参阅 Well-Architected Framework

在针对特定工作负荷的设计过程中,在 Azure AI 工作负载中应用此体系结构和设计指南。

可靠性

可靠性有助于确保应用程序能够履行对客户的承诺。 有关详细信息,请参阅可靠性设计评审核对清单

基线应用服务 Web 应用程序体系结构侧重于关键区域服务的区域性冗余。 可用性区域是区域中在物理上独立的位置。 在两个或多个实例之间部署时,它们为支持服务提供区域中的冗余。 当停机发生在一个区域中时,该区域中的其他区域可能不受影响。 该体系结构还有助于确保 Azure 服务的足够实例和配置分布在可用性区域。 有关详细信息,请参阅 基线高度可用的区域冗余 Web 应用程序

本部分从此体系结构中未在应用服务基线体系结构(包括机器学习、Azure OpenAI 和 AI 搜索)中解决的组件的可靠性。

流部署的区域冗余

企业部署通常需要做到区域冗余。 若要在 Azure 中实现区域冗余,资源必须支持 可用性区域,并且必须在实例控制不可用时至少部署三个资源实例或启用平台支持。 机器学习计算不支持可用性区域。 若要缓解数据中心级灾难对机器学习组件的潜在影响,必须在各个区域中建立群集,并部署负载均衡器以在这些群集之间分配调用。 你可以使用运行状况检查来帮助确保调用只会被路由到正常运行的群集。

机器学习计算群集的替代项包括 AKS、Azure Functions、容器应用和应用服务。 这些服务均支持可用性区域。 若要在不增加多区域部署复杂性的情况下实现提示流执行的区域性冗余,可以将流部署到其中一个服务。

下图显示了将提示流部署到应用服务的替代体系结构。 此体系结构使用应用服务,因为工作负载已将其用于聊天 UI,并且无法从将新技术引入工作负载中受益。 具有 AKS 经验的工作负荷团队应考虑在该环境中部署,尤其是在将 AKS 用于工作负荷中的其他组件时。

关系图,显示使用 OpenAI 的基线端到端聊天体系结构,并将提示流部署到应用服务。

以下数据流对应于上图:

  1. 流是在提示流中创作的,网络体系结构保持不变。 流作者通过专用终结点连接到 Azure AI Foundry 项目中的创作体验,托管专用终结点用于在测试流时连接到 Azure 服务。

  2. 这条虚线表示已将容器化可执行流推送到容器注册表。 此关系图不显示容器化流并推送到容器注册表的管道。 运行这些管道的计算必须具有对 Azure 容器注册表和 Azure AI Foundry 项目等资源的网络视线。

  3. 另一个 Web 应用部署到托管聊天 UI 的同一应用服务计划。 新的 Web 应用托管容器化提示流,该流并置在同一应用服务计划中。 此服务计划已至少运行三个跨可用性区域的实例。 加载提示流容器映像时,这些应用程序服务实例会通过专用终结点连接到容器注册表。

  4. 提示流容器需要连接到所有依赖服务才能执行流。 在此体系结构中,提示流容器连接到 AI 搜索和 Azure OpenAI。 仅向机器学习托管专用终结点子网公开的 PaaS 服务现在还需要在虚拟网络中公开才能从应用服务建立视线。

Azure OpenAI 中的可靠性

Azure OpenAI 不支持可用性区域。 若要缓解数据中心级灾难对 Azure OpenAI 中模型部署的潜在影响,必须将 Azure OpenAI 部署到各个区域,并部署负载均衡器以在区域之间分配调用。 你可以使用运行状况检查来帮助确保调用只会被路由到正常运行的群集。

为了有效支持多个实例,我们建议将微调文件(例如异地冗余存储帐户)外部化。 此方法将每个区域的 Azure OpenAI 中存储的状态降到最低。 必须微调每个实例的文件才能托管模型部署。

在每分钟令牌 (TPM) 和每分钟请求 (RPM) 方面监视所需的吞吐量非常重要。 从配额中分配足够的 TPM 以满足部署需求,并阻止对已部署模型的调用受到限制。 可以在 Azure OpenAI 服务或服务前面部署 Azure API 管理等网关,并在发生暂时性错误和限制时将其配置为重试。 还可以使用 API 管理作为 断路器,以防止服务因调用而不知所措,并超出其配额。 有关详细信息,请参阅在多个 Azure OpenAI 部署或实例前使用网关

支持可用性区域的区域部署具有标准或更高定价层的的 AI Search,并部署三个或更多副本。 副本会自动均匀分布到各个可用性区域。

使用以下指南来确定适当的副本和分区数:

  • 监视 AI 搜索

  • 使用监视指标和性能分析来确定适当的副本数。 此方法可帮助你避免基于查询的限制和分区以及基于索引的限制。

Azure AI Foundry 中的可靠性

如果部署到机器学习托管联机终结点后面的计算群集,请考虑以下缩放指南:

  • 自动扩展联机终结点,确保有足够的容量来满足需求。 如果由于突发使用情况而没有足够的使用信号,请考虑过度预配。 此方法通过确保有足够的实例可用来帮助提高可靠性。

  • 根据 部署 指标(例如 CPU 负载和 终结点指标 请求延迟)创建缩放规则。

  • 为活动生产部署部署部署部署不超过三个实例。

  • 避免针对正在使用的实例进行部署。 改为部署到新部署,并在其他部署准备好接收流量后转移流量。

托管联机终结点充当托管计算的负载均衡器和路由器,这些托管计算在它们后面运行。 可以配置应路由到每个部署的流量百分比,前提是百分比增加 100%。 还可以部署托管联机终结点,其中 0% 流量路由到任何部署。

如果使用基础结构即代码(IaC)部署资源,包括托管联机终结点,则存在可靠性问题。 提供的参考实现中突出显示了此问题。 如果流量配置为路由到通过 CLI 或 Azure AI Foundry 门户创建的部署,并且执行包含托管联机终结点的后续 IaC 部署,即使它不会以任何方式更新托管联机终结点,终结点流量也会还原为路由 0% 流量。 实际上,此方案意味着在将流量调整回所需位置之前,无法访问已部署的提示流。

注意

如果将流部署到应用程序服务,则基线体系结构中的应用程序服务可扩展性指南同样适用。

多区域设计

此体系结构不用作多区域体系结构中的区域标记。 它在单个区域中提供高可用性,因为它完全使用可用性区域,但它缺少一些关键组件,使此设计为多区域解决方案做好准备。 此体系结构不包括以下组件和注意事项:

  • 全局入口和路由
  • DNS 管理策略
  • 数据复制或隔离策略
  • 主动-主动、主动-被动或主动冷指定
  • 故障转移和故障回复策略,以实现工作负荷的恢复时间目标和恢复点目标
  • 有关 Azure AI Foundry 中心资源中开发人员体验的区域可用性的注意事项

如果工作负荷需要多区域策略,则除了此体系结构中显示的设计外,还需要投资组件和作过程设计。 设计需要支持以下层的负载均衡或故障转移:

  • 接地数据
  • 模型托管
  • 业务流程层,这是此体系结构中的提示流
  • 面向客户端的 UI

还需要在可观测性、门户体验和负责任的 AI(例如内容安全)中保持业务连续性。

安全性

安全性提供针对故意攻击和滥用宝贵数据和系统的保证。 有关详细信息,请参阅可靠性设计审查检查表

此体系结构扩展了 基本 OpenAI 端到端聊天参考体系结构中实现的安全占用。 基本体系结构使用系统分配的托管标识和系统分配的角色分配。 此体系结构使用用户分配的标识和手动创建的角色分配。

除了基本体系结构实现的标识外围之外,此体系结构还实现网络安全外围。 从网络的角度来看,只能通过应用程序网关从 Internet 访问聊天 UI。 从身份的角度来看,聊天 UI 应对请求进行身份验证和授权。 尽可能使用托管标识向 Azure 服务验证应用程序。

本部分介绍密钥轮换和 Azure OpenAI 模型微调的网络和安全注意事项。

标识和访问管理

使用用户分配的托管标识时,请考虑以下指南:

  • 为以下 Azure AI Foundry 和机器学习资源创建单独的托管标识(如果适用):

    • Azure AI Foundry 中心
    • 用于流创作和管理的 Azure AI Foundry 项目
    • 如果流量已部署到托管联机端点,则使用已部署流中的联机终结点
  • 使用 Microsoft Entra ID 为聊天 UI 实现身份-访问控制

如果要隔离提示流的权限,请为不同的提示流创建单独的项目和联机终结点。 为每个项目和托管联机终结点创建单独的托管标识。 仅向提示流作者提供对所需项目的访问权限。

将用户加入 Azure AI Foundry 项目以执行创作流等功能时,请为所需的资源分配最低特权角色。

基于机器学习角色的访问角色

与在基本体系结构中一样,系统会自动为系统分配的托管标识创建角色分配。 由于系统不知道你可能使用的中心和项目的哪些功能,因此它会创建支持所有潜在功能的角色分配。 根据用例,自动创建的角色分配可能会过度预配特权。 例如,当系统将参与者角色分配给容器注册表的中心时,中心可能只需要读取者访问控制平面。 如果需要限制最低特权目标的权限,则必须使用用户分配的标识。 你自己创建和维护这些角色分配。

由于管理所有所需分配的维护负担,此体系结构优先于绝对最低特权角色分配的操作卓越性。 必须使表中列出的所有工作分配。

托管的标识 范围 角色分配
中心托管标识 参与者 资源组
中心托管标识 中心 Azure AI 管理员
中心托管标识 容器注册表 参与者
中心托管标识 密钥保管库 参与者
中心托管标识 密钥保管库 管理员
中心托管标识 存储帐户 读者
中心托管标识 存储帐户 存储帐户参与者
中心托管标识 存储帐户 存储 Blob 数据参与者
中心托管标识 存储帐户 存储文件数据特权参与者
中心托管标识 存储帐户 存储表数据参与者
项目托管标识 集成 Azure AI 管理员
项目托管标识 容器注册表 参与者
项目托管标识 密钥保管库 参与者
项目托管标识 密钥保管库 管理员
项目托管标识 存储帐户 读者
项目托管标识 存储帐户 存储帐户参与者
项目托管标识 存储帐户 存储 Blob 数据参与者
项目托管标识 存储帐户 存储文件数据特权参与者
项目托管标识 存储帐户 存储表数据参与者
联机终结点托管标识 集成 Azure 机器学习工作区连接机密
联机终结点托管标识 集成 AzureML 指标编写器
联机终结点托管标识 容器注册表 ACRPull
联机终结点托管标识 Azure OpenAI 认知服务 OpenAI 用户
联机终结点托管标识 存储帐户 存储 Blob 数据参与者
联机终结点托管标识 存储帐户 存储 Blob 数据读者
App 服务(将提示流部署到App 服务时) Azure OpenAI 认知服务 OpenAI 用户
门户用户(提示流开发) Azure OpenAI 认知服务 OpenAI 用户
门户用户(提示流开发) 存储帐户 存储 Blob 数据参与者(使用条件访问)
门户用户(提示流开发) 存储帐户 存储文件数据特权参与者

请务必了解,Azure AI Foundry 中心跨项目共享 Azure 资源,例如存储帐户和容器注册表。 如果你的用户只需要访问项目子集,请考虑对支持它们的 Azure 服务使用 角色分配条件,以提供对资源的最低特权访问权限。 例如,存储中的 Blob 支持角色分配条件。 如果用户需要访问项目子集,请使用角色访问条件来限制这些项目使用的 Blob 容器的权限,而不是按容器分配权限。 每个项目都有一个唯一的 GUID,用作该项目中使用的 Blob 容器名称的前缀。 该 GUID 可用作角色分配条件的一部分。

中心需要 Contributor 中心资源组的访问权限,以便它可以创建和管理中心和项目资源。 Contributor 访问权限还允许中心控制平面访问资源组中的任何资源。 在单独的资源组中创建与中心及其项目不直接相关的任何 Azure 资源。 建议为使用自管理 Azure AI Foundry 中心的工作负荷团队创建至少两个资源组。 一个资源组包含中心、其项目及其所有直接依赖项,例如 Azure 容器注册表和 Key Vault。 其他资源组包含工作负荷中的其他所有内容。

建议尽量减少工作负荷中其他组件对中心作所需的 Azure 资源使用。 例如,如果需要将机密存储为工作负荷的一部分,则应从与中心关联的密钥保管库实例创建单独的 Key Vault 实例。 只有中心应使用中心密钥保管库来存储中心和项目机密。

确保对于每个不同的项目,其依赖项的角色分配不提供对门户用户和托管联机终结点托管标识不需要的资源的访问权限。 例如, Cognitive Services OpenAI User Azure OpenAI 的角色分配授予对该资源的所有部署的访问权限。 无法限制流作者或托管联机终结点托管标识,这些标识具有该角色分配给 Azure OpenAI 中的特定模型部署。 对于这些方案,我们建议为每个项目部署 Azure OpenAI 和 AI 搜索等服务,不要将资源部署到流作者或托管联机终结点托管标识不应有权访问的服务。 例如,仅将模型部署到项目需要访问的 Azure OpenAI 实例。 仅将索引部署到项目应有权访问的 AI 搜索实例。

网络

除了基于标识的访问之外,网络安全也是使用 OpenAI 的基线端到端聊天体系结构的核心。 网络体系结构可在高级别上确保:

  • 聊天 UI 流量仅存在一个安全入口点。
  • 筛选网络流量。
  • 传输中的数据通过传输层安全性进行端到端加密。
  • 通过使用专用链接将流量保持在 Azure 中,可最大限度地减少数据外泄。
  • 网络资源通过网络分段进行逻辑分组和相互隔离。
网络流

关系图,显示使用 OpenAI 的基线端到端聊天体系结构中的编号流。

基线应用服务 Web 应用程序体系结构介绍了从最终用户到聊天 UI 的入站流,以及从应用服务到 Azure PaaS 服务 流。 本节重点介绍机器学习联机终结点流。 它从在基线应用服务 Web 应用程序中运行的聊天 UI 到部署到机器学习计算的流:

  1. 来自应用程序服务托管聊天 UI 的调用会通过专用终结点路由到机器学习联机终结点。
  2. 联机终结点将调用路由到运行已部署流的服务器。 联机终结点既充当负载均衡器,又充当路由器。
  3. 对部署的流所需的 Azure PaaS 服务的调用通过托管专用终结点进行路由。
流入机器学习

在此体系结构中,禁用对机器学习工作区的公共访问。 用户可以通过专用访问访问工作区,因为体系结构遵循机器学习工作区配置的专用终结点。 专用终结点在整个体系结构中使用,以补充基于标识的安全性。 例如,应用程序服务托管聊天 UI 可以连接到未公开到公共 Internet(包括 Azure 机器学习终结点)的 PaaS 服务。

还需要专用终结点访问才能连接到机器学习工作区进行流创作。

关系图,显示用户通过跳转框连接到机器学习工作区以创作流 OpenAI。

此图显示了通过 Azure Bastion 连接到虚拟机(VM)跳转框的提示流作者。 作者可以从跳转盒通过与跳转盒位于同一网络中的专用终结点连接到机器学习工作区。 作者还可以通过 Azure ExpressRoute 或 VPN 网关和虚拟网络对等互连连接到虚拟网络。

从 Azure AI Foundry 托管虚拟网络流向 Azure PaaS 服务

建议将 Azure AI Foundry 中心配置为 托管虚拟网络隔离,这需要批准所有出站连接。 此体系结构遵循这一建议。 经批准的出站规则有两种。 所需的出站规则 适用于解决方案所需的资源,例如容器注册表和存储。 用户定义的出站规则 适用于工作流使用的自定义资源,例如 Azure OpenAI 或 AI 搜索。 必须配置用户定义的出站规则。 创建托管虚拟网络时配置所需的出站规则。 首次使用托管虚拟网络时,会按需部署托管虚拟网络,并且从此持续。

出站规则可以是外部公共终结点的专用终结点、服务标记或 FQDN。 在此体系结构中,通过专用链接建立与 Azure 服务的连接。 此体系结构不包括一些常见作,这些作可能需要配置 FQDN 出站规则、下载 pip 包、克隆 GitHub 存储库或从外部存储库下载基本容器映像。

由Microsoft管理的 Azure 防火墙实例实现出站 FQDN 控制,并部署到 Azure AI Foundry 托管网络。 如果需要仅控制 HTTP(端口 80)或 HTTPS(端口 443)出口流量,请选择基本定价层。 如果出口流量需要自定义协议或端口,请选择标准定价层。 此体系结构使用基本定价层,因为唯一的出口流量是端口 443 上的 HTTPS 终结点。

虚拟网络分段和安全

此体系结构中的网络具有独立子网,用于以下目的:

  • 应用程序网关
  • 应用程序服务集成组件
  • 专用终结点
  • Azure Bastion
  • 跳转盒 VM
  • 计分
  • 训练和评分子网

    注意

    训练和评分子网旨在使你能够使用自己的计算资源进行训练和推理。 但是,此体系结构使用托管计算,不执行任何训练。

每个子网都有一个网络安全组(NSG),该组将这些子网的入站和出站流量限制为仅需要流量。 下表显示了基线添加到每个子网的 NSG 规则的简化视图。 该表提供了规则名称和函数。

子网 入站流量 出站流量
snet-appGateway 聊天 UI 用户源 IP 地址(如公共 Internet)的津贴,以及服务所需的项目。 访问应用服务专用终结点和服务所需的项。
snet-PrivateEndpoints 仅允许来自虚拟网络的流量。 仅允许到虚拟网络的流量。
snet-AppService 仅允许来自虚拟网络的流量。 允许访问专用终结点和 Azure Monitor。
AzureBastionSubnet 请参阅 使用 NSG 访问和 Azure Bastion 请参阅 使用 NSG 访问和 Azure Bastion
snet-jumpbox 允许来自 Azure Bastion 主机子网的入站远程桌面协议和安全外壳协议。 允许访问专用终结点。
snet-agents 仅允许来自虚拟网络的流量。 仅允许到虚拟网络的流量。
snet-training 仅允许来自虚拟网络的流量。 仅允许到虚拟网络的流量。
snet-scoring 仅允许来自虚拟网络的流量。 仅允许到虚拟网络的流量。

明确拒绝所有其他流量。

实现虚拟网络分段和安全性时,请考虑以下几点。

密钥轮换

在此体系结构中,机器学习托管联机终结点使用基于密钥的身份验证,因此请务必:

  • 将密钥存储在安全存储(如 Key Vault)中,以便从授权客户端进行按需访问,例如托管提示流容器的 Azure Web 应用。

  • 实施密钥轮换策略。 如果手动轮换密钥,请创建密钥过期策略,并使用 Azure Policy 监视密钥是否已轮换。

OpenAI 模型微调

如果在实现中微调 OpenAI 模型,请考虑以下指南:

  • 如果上传训练数据进行微调,请使用 客户管理的密钥 加密这些数据。

  • 如果在存储(如 Azure Blob 存储)中存储定型数据,请使用客户管理的密钥进行数据加密、用于控制对数据的访问的托管标识,以及用于连接到数据的专用终结点。

通过策略进行治理

为了帮助确保与安全性保持一致,请考虑使用 Azure Policy 和网络策略,使部署符合工作负荷的要求。 通过策略使用平台自动化可减轻手动验证步骤的负担,并帮助确保治理,即使绕过管道也是如此。 请考虑以下安全性策略:

  • 在 Azure AI 服务和密钥库等服务中禁用密钥或其他本地身份验证访问。

  • 需要对网络访问规则或 NSG 进行特定配置。

  • 需要加密,例如使用客户管理的密钥。

Key Vault 的 Azure AI Foundry 角色分配

Azure AI Foundry 托管标识需要控制平面(Contributor)和数据平面(Key Vault Administrator)角色分配。 这些分配使此标识能够读取和写入 Azure Key Vault 中存储的所有机密、密钥和证书。 如果工作负荷使用 Azure AI Foundry 以外的服务,这些服务需要访问 Key Vault 中的机密、密钥或证书,则工作负荷或安全团队可能更喜欢 Azure AI Foundry 中心托管标识无权访问这些项目。 在此方案中,请考虑为 Azure AI Foundry 中心和其他 Key Vault 实例部署专用于工作负荷的其他部分的 Key Vault 实例。

成本优化

成本优化侧重于减少不必要的开支和提高运营效率的方法。 有关详细信息,请参阅成本优化设计评审核对清单

要查看此方案的定价示例,请使用 Azure 定价计算器。 需要自定义示例以匹配使用情况,因为此示例仅包含此体系结构使用的组件。 方案中最昂贵的组件是 DDoS 防护和作为托管联机终结点的一部分部署的防火墙。 其他值得注意的成本包括聊天 UI、提示流计算和 AI 搜索。 优化这些资源以降低成本。

计算

提示流支持多个选项来托管可执行流。 这些选项包括机器学习、AKS 和应用服务中的托管联机终结点。 其中每个选项都有自己的计费模型。 选择的计算会影响解决方案的总体成本。

Azure OpenAI

Azure OpenAI 是一种基于消耗的服务,因此,将需求与供应相匹配是控制成本的主要方法。 若要在 Azure OpenAI 中执行此作,需要使用方法的组合:

  • 控制客户端。 客户端请求是消耗模型中的主要成本来源,因此控制客户端行为至关重要。 所有客户端都应:

    • 获得批准。 避免以支持免费访问的方式公开服务。 通过网络和标识控制(如密钥或基于角色的访问控制)限制访问。

    • 自我控制。 要求客户端使用 API 调用提供的令牌限制约束,例如max_tokens和max_completions。

    • 在实际情况下使用批处理。 查看客户端,确保客户端正确批处理提示。

    • 优化提示输入和响应长度。 较长的提示会消耗更多令牌,这会增加成本。 缺少足够上下文的提示有助于模型产生良好的结果。 创建简明扼要的提示,提供足够的上下文,让模型能够生成有用的响应。 确保优化响应长度的限制。

  • 仅在必要时使用 Azure OpenAI场。 只应在预生产实例上使用场,以便这些活动不会产生生产成本。

  • 选择正确的 AI 模型。 选择的模型会影响 Azure OpenAI 的总体成本。 所有模型都各有优缺点,并且价格也各不相同。 为用例使用正确的模型,以帮助防止在成本较低的模型产生可接受的结果时对更昂贵的模型过度追加。 此聊天参考实现使用 GPT 3.5-turbo 而不是 GPT-4 来节省模型部署成本,同时获得足够的结果。

  • 了解计费断点。 微调按小时收费。 为了获得最大效率,请使用该小时中的尽可能多的时间来改进微调结果,然后再达到下一计费小时。 同样,映像生成 100 个图像的成本与一个图像的成本相同。 最大限度地发挥价格突破点的优势。

  • 了解计费模型。 Azure OpenAI 还可通过预配的吞吐量产品/服务在基于承诺的计费模型中使用。 有了可预测的使用模式后,如果预购计费模型在使用量上更具成本效益,请考虑切换到此预购计费模型。

  • 设置预配限制。 按模型将所有预配配额仅分配给预期属于工作负荷的模型。 在启用动态配额时,已部署模型的吞吐量不受此预配配额限制。 配额不直接映射到成本,这些成本可能会有所不同。

  • 监视即用即付使用情况。 如果使用即用即付定价,请监视 TPM 和 RPM 的使用情况。 使用该信息来告知体系结构设计决策,例如要使用的模型,并优化提示大小。

  • 监视预配的吞吐量使用情况。 如果使用 预配的吞吐量,请监视 预配管理的使用情况,以帮助确保未使用购买的预配吞吐量。

  • 管理成本。 按照有关将成本管理功能与 OpenAI 配合使用 的指导,以监视成本、设置预算并创建警报,以通知利益干系人风险或异常情况。

卓越运营

卓越运营涵盖部署应用程序并使其在生产环境中运行的运营流程。 有关详细信息,请参阅设计卓越运营的审查清单

内置提示流运行时

与基本体系结构一样,此体系结构使用自动运行时来最大程度地减少作负担。 自动运行时是机器学习中的无服务器计算选项,可简化计算管理,并将大部分提示流配置委托给运行中应用的 requirements.txt 文件和 flow.dag.yaml 配置。 此选项是低维护、临时和应用程序驱动的。 此体系结构使用计算实例运行时或外部化计算,这需要工作负荷团队管理计算的生命周期。 当工作负荷要求超过自动运行时选项的配置功能时,应使用计算实例运行时。

监视

与基本体系结构一样,所有服务都配置了诊断功能。 除应用服务之外的所有服务都配置为捕获所有日志。 应用服务配置为捕获 AppServiceHTTPLogsAppServiceConsoleLogsAppServiceAppLogsAppServicePlatformLogs。 在生产环境中,所有日志可能过多。 根据操作需求优化日志流。 对于此体系结构,Azure AI Foundry 项目使用 AmlComputeClusterEventAmlDataSetEventAmlEnvironmentEventAmlModelsEvent 机器学习日志。

评估生成自定义警报(例如 Azure Monitor 基线警报中找到的警报),以获取此体系结构中的资源。 例如:

请务必监视 Azure OpenAI 模型部署的令牌使用情况。 在此体系结构中,提示流通过与 Application Insights 的集成跟踪 令牌使用情况

语言模型操作

基于 Azure OpenAI 的聊天解决方案的部署(如此体系结构)应遵循使用提示流和 Azure DevOps 的 genAIOps GenAIOps 中的指南,并使用提示流和 GitHub GenAIOps。 此外,它必须考虑持续集成和持续交付(CI/CD)和网络安全体系结构的最佳做法。 以下指南介绍了基于 GenAIOps 建议实现流及其关联的基础结构。 此部署指南不包括前端应用程序元素,这些元素与 基线高度可用的区域冗余 Web 应用程序体系结构保持不变。

开发

提示流在 Azure AI Foundry 门户中或通过 Visual Studio Code 扩展提供基于浏览器的创作体验。 这两个选项都将流代码存储为文件。 使用门户时,文件存储在存储帐户中。 在 VS Code 中工作时,文件存储在本地文件系统中。

若要遵循协作开发 最佳做法,请维护联机源代码存储库(如 GitHub)中的源文件。 此方法可帮助跟踪代码更改、在流作者之间协作,并与 部署流集成, 用于测试和验证所有代码更改。

对于企业开发,请使用 VS Code 扩展提示流 SDK/CLI 进行开发。 提示流作者可以从 VS Code 生成和测试其流,并将本地存储的文件与联机源代码管理系统和管道集成。 基于浏览器的体验专为探索性开发而设计,但你可以将其与源代码管理系统集成。 可以从 Files 面板中的流页下载流文件夹,解压缩文件夹并将其推送到源代码管理系统。

计算

使用用于测试其他软件项目的相同方法测试聊天应用程序使用的流。 指定和断言语言模型输出的单个正确答案非常困难,但你可以使用语言模型来评估响应。 考虑对语言模型流程实现以下自动评估:

  • 分类准确性 评估语言模型是否提供正确或不正确的分数,并聚合结果以生成准确性等级。

  • 一致性 评估模型的预测答案中的句子的编写程度,以及句子如何相互连贯地相互连接。

  • 流利 评估模型的语法和语言准确性的预测答案。

  • 基于上下文 基于预配置的上下文评估模型的预测答案的依据程度。 即使语言模型响应正确,如果无法针对给定上下文验证这些响应,则不会使响应停止。

  • 相关性 评估模型的预测答案与所问问题的答案的一致程度。

实现自动评估时,请考虑以下指南:

  • 从评估中得出分数,并根据预定义的成功阈值对其进行度量。 使用这些分数报告测试是在管道中通过还是失败。

  • 其中一些测试需要输入预先配置的问题、上下文和基本事实的数据。

  • 包括足够的问答对,以帮助确保测试结果可靠。 建议至少包含 100-150 对。 这些问题和答案也称为 黄金数据集。 可能需要大量的对,具体取决于数据集的大小和域。

  • 避免使用语言模型来生成黄金数据集中的任何数据。

部署流

图中显示提示流的部署流。

以下数据流对应于上图:

  1. 提示工程师或数据科学家打开一个功能分支,可在其中处理特定任务或功能。 提示工程师或数据科学家使用 VS Code 的提示流循环访问流,并定期提交更改并将这些更改推送到功能分支。

  2. 在本地开发和试验完成后,提示工程师或数据科学家会从功能分支打开拉取请求(PR)到主分支。 PR 触发 PR 管道。 此管道可快速进行质量检查,其中应包括:

    • 执行试验流。
    • 执行配置的单元测试。
    • 编译代码库。
    • 静态代码分析。
  3. 管道可以包含一个步骤,要求至少一名团队成员在合并之前手动批准 PR。 审批者不能是提交者,他们必须具有及时的流专业知识,并熟悉项目的要求。 如果 PR 未获批准,则合并就会被阻止。 如果 PR 已批准,或者没有审批步骤,功能分支将合并到主分支中。

  4. 合并到主分支会触发开发环境的生成和发布过程。

    一个。 CI 管道从合并触发到主分支。 CI 管道执行 PR 管道中的所有步骤,并执行以下步骤:

    • 实验流
    • 评估流
    • 检测到更改时,机器学习注册表中的流注册

    b. CI 管道完成,然后触发 CD 管道。 该流执行以下步骤:

    • 将流从机器学习注册表部署到机器学习联机终结点
    • 运行面向联机终结点的集成测试
    • 运行面向联机终结点的冒烟测试
  5. 审批流程内置于发布升级过程中。 批准后,CI/CD 过程会重复,以测试环境为目标。 步骤 a.b. 相同,但用户验收测试在测试环境中冒烟测试后运行。

  6. CI/CD 进程在验证和批准测试环境后将发布提升到生产环境。

  7. 在发布到实时环境中后,将执行监视性能指标和评估已部署语言模型的作任务。 这些任务包括:

    • 数据偏移检测。
    • 基础结构观察。
    • 成本管理。
    • 将模型的性能与利益干系人沟通。
部署指南

可以使用机器学习终结点以在将模型发布到生产环境时灵活地部署模型。 请考虑以下策略来帮助确保高模型性能和质量:

  • 在将所有流量定向到新部署之前,使用蓝绿部署安全地将新版本的 Web 服务部署到有限的用户组或请求。

  • 使用 A/B 测试部署新行为。 A/B 测试允许部分用户评估更改的影响。

  • 在管道中包含作为提示流一部分的 Python 文件的 Lint 分析。 Lint 分析会检查是否符合样式标准以及错误、代码复杂性、未使用的导入和变量命名。

  • 将流部署到网络隔离的机器学习工作区时,使用自承载代理将项目部署到 Azure 资源。

  • 仅当模型发生更改时,才更新机器学习模型注册表。

  • 确保语言模型、流和客户端 UI 松散耦合。 你应该能够更新流和客户端 UI,而不会影响模型,反之亦然。

  • 开发和部署多个流时,每个流都应有自己的生命周期。 此方法有助于在将流从试验提升到生产环境时保持松散耦合。

基础结构

部署基线 Azure OpenAI 端到端聊天组件时,某些预配的服务是体系结构中的基础和永久性服务。 其他组件的生命周期与部署相关联。 托管虚拟网络是基础虚拟网络,在创建计算实例时会自动预配,因此需要考虑以下组件。

基础组件

此体系结构中的某些组件存在生命周期,该生命周期超出了任何单个提示流或模型部署的范围。 这些资源通常部署一次,作为工作负荷团队的基础部署的一部分。 然后,工作负荷团队独立于创建、删除或更新提示流或模型部署来维护这些资源。 这些组件包括:

  • 机器学习工作区。
  • 机器学习工作区的存储帐户。
  • 容器注册表。
  • AI 搜索。
  • Azure OpenAI。
  • Application Insights。
  • Azure Bastion。
  • 跳转框的 Azure VM。
临时组件

某些 Azure 资源与特定提示流的设计更紧密地耦合。 此方法允许这些资源绑定到组件的生命周期,并成为此体系结构中的临时资源。 当工作负荷发生变化时,例如添加或删除流量或引入新模型时,Azure 资源会受到影响。 这些资源将重新创建,并删除以前的实例。 其中一些资源是 Azure 资源,有些资源是包含服务中的数据平面表现形式。

  • 机器学习模型注册表中的模型应更新(如果更改),作为 CD 管道的一部分。

  • 作为 CD 管道的一部分,容器映像应在容器注册表中更新。

  • 如果部署引用不存在的终结点,则会在部署提示流时创建机器学习终结点。 该终结点需要更新才能关闭公共访问

  • 在部署或删除流时,机器学习终结点的部署会被更新。

  • 在创建新终结点时,必须使用终结点的密钥来更新客户端 UI 的密钥库。

按需托管虚拟网络

首次创建计算实例时,会自动预配托管虚拟网络。 如果使用 IaC 部署中心,并且 Bicep 中没有 Azure AI Foundry 计算资源,则不会部署托管虚拟网络,并且连接到 Azure AI Foundry 门户时收到错误。 需要在 IaC 部署后 手动预配托管虚拟网络

资源组织

如果有一个场景,中心由工作负荷团队以外的团队集中拥有,则可以选择将项目部署到单独的资源组。 如果使用 IaC,可以通过在 Bicep 中设置其他资源组,将项目部署到单独的资源组。 如果使用门户,可以将 defaultWorkspaceResourceGroup 下的 workspaceHubConfig 属性设置为要在其中创建项目的资源组。

性能效率

性能效率是指工作负荷能够高效地缩放以满足用户需求。 有关详细信息,请参阅性能效率设计评审核对清单

本部分从 AI 搜索、Azure OpenAI 和机器学习的角度介绍了性能效率。

按照指南分析 AI 搜索中的性能

Azure OpenAI 中的性能效率

  • 确定应用程序是否需要预配的吞吐量或使用共享托管或消耗模型。 预配的吞吐量有助于确保 OpenAI 模型部署的保留处理容量。 预留容量可为模型提供可预测的性能和吞吐量。 此计费模型与共享托管或消耗模型不同。 消耗模型是尽最大努力的,可能会受到平台上干扰邻居或其他问题的影响。

  • 对于预配吞吐量,监视预配托管利用率

机器学习中的性能效率

如果将机器学习模型部署到联机终结点:

  • 按照有关如何自动扩展联机终结点的指导进行操作。 自动缩放可帮助你与需求紧密保持一致,而无需过度预配,尤其是在低使用率期间。

  • 为联机终结点选择适当的 VM SKU 以满足性能目标。 若要查找最佳配置,请测试较低实例计数和更大的 SKU 与更大的实例计数和较小的 SKU 的性能。

部署此方案

若要部署和运行此引用实现,请按照 OpenAI 端到端基线引用实现中的步骤作。

作者

Microsoft维护本文。 以下参与者撰写了本文。

要查看非公开的 LinkedIn 个人资料,请登录到 LinkedIn。

下一步

Azure 登陆区域中的 Azure OpenAI 基线