企业聊天应用程序能够通过对话交互来提升员工的能力。 由于 OpenAI 的 GPT 模型和 Meta 的 LLaMA 模型等语言模型的不断进步，情况尤其如此。 这些聊天应用程序包括聊天用户界面 (UI)、包含与用户查询相关的特定于域信息的数据存储库、对特定领域数据进行推理以生成相关响应的语言模型，以及负责监督这些组件之间交互的业务流程协调程序。
本文提供了生成和部署使用 Azure OpenAI 语言模型的企业聊天应用程序的基线体系结构。 该体系结构采用 Azure 机器学习提示流来创建可执行流。 这些可执行流程协调了从传入提示到数据存储的工作流程，以便为语言模型获取基础数据以及其他所需的 Python 逻辑。 可执行流将部署到托管联机终结点后面的机器学习计算群集。
自定义聊天用户界面 (UI) 的托管遵循基线应用程序服务 Web 应用程序指南，用于在 Azure 应用程序服务上部署安全、区域冗余和高度可用的 Web 应用程序。 在该体系结构中，应用程序服务通过专用终结点的虚拟网络集成与 Azure 平台即服务 (PaaS) 解决方案通信。 聊天 UI App 服务通过专用终结点与托管联机终结点通信。 禁用对机器学习工作区的公共访问。
重要
本文不讨论基线应用程序服务 Web 应用程序中的组件或体系结构决策。 请阅读这篇文章，了解如何托管聊天 UI 的体系结构指导。
机器学习工作区配置了托管虚拟网络隔离，要求所有出站连接都要经过批准。 使用此配置可创建一个托管虚拟网络以及托管专用终结点，这些终结点支持连接到工作场所 Azure 存储、Azure 容器注册表和 Azure OpenAI 等专用资源。 这些专用连接在流创作和测试期间使用，以及部署到 Azure 机器学习计算的流。
提示
本文以参考实现提供支持，展示了 Azure 上的基线端到端聊天实现。 在生产的第一步中，你可以使用此实现作为自定义解决方案开发的基础。
体系结构
下载此体系结构的 Visio 文件。
组件
此体系结构的许多组件与基线应用程序服务 Web 应用程序中的资源相同，因为在这两种体系结构中，用来托管聊天 UI 的方法是一样的。 本节中突出显示的组件主要用于生成和协调聊天流的组件，以及数据服务和可公开语言模型的服务。
机器学习服务是一项完全托管的云服务，可用于大规模训练、部署和管理机器学习模型。 此体系结构使用机器学习的其他几项功能，用于开发和部署由语言模型提供支持的 AI 应用程序的可执行流：
存储用于持久保存提示流源文件，以便进行提示流开发。
使用 容器注册表，可在专用注册表中为所有类型的容器部署生成、存储和管理容器映像与项目。 在此体系结构中，流会被打包为容器映像并存储在容器注册表中。
Azure OpenAI 是一项完全托管的服务，提供对 Azure OpenAI 语言模型（包括 GPT-4、GPT-3.5-Turbo 和嵌入模型集）的 REST API 访问。 在此体系结构中，除了模型访问之外，它还用于添加常见的企业功能，例如虚拟网络和专用链接、托管标识支持和内容筛选。
Azure AI 搜索是一种云搜索服务，支持全文搜索、语义搜索、矢量搜索和混合搜索。 AI 搜索包含在该体系结构中，因为它是聊天应用程序背后流中常用的服务。 AI 搜索可用于检索与用户查询相关的数据并编制索引。 提示流可实现 RAG 检索增强生成模式，以便从提示中提取相应的查询，查询 AI 搜索，并将结果用作 Azure OpenAI 模型的基础数据。
机器学习提示流
企业聊天应用程序的后端通常遵循类似于以下流的模式：
- 用户在自定义聊天用户界面 (UI) 中输入提示。
- 该提示由接口代码发送到后端。
- 由后端从提示中提取用户意向，包括问题或指令。
- （可选）后端确定保存与用户提示相关数据的数据存储
- 后端查询相关数据存储。
- 后端将意向、相关基础数据和提示中提供的任何历史记录发送到语言模型。
- 后端返回结果，以便显示在 UI 上。
后端可以采用任意数量的语言来实现，并部署到各种 Azure 服务。 此体系结构使用器学习提示流，因为它提供了一种简化的体验，可以生成、测试和部署在提示、后端数据存储和语言模型之间协调的流。
提示流运行时
机器学习可以直接托管两种类型的提示流运行时。
自动运行时：一个无服务器计算选项，用于管理计算的生命周期和性能特征，并允许对环境进行流驱动的自定义。
计算实例运行时：工作负荷团队必须在其中选择性能特征的始终可用计算选项。 此运行时提供对环境的更多自定义和控制。
提示流也可以托管在主机容器主机平台上机器学习计算的外部。 此体系结构使用应用程序服务来演示外部托管。
网络
除了基于身份的访问，网络安全也是使用 OpenAI 的基线端到端聊天体系结构的核心。 网络体系结构可在高级别上确保：
- 聊天 UI 流量只有单一安全入口点。
- 筛选网络流量。
- 传输中的数据使用传输层安全性 (TLS) 进行端到端加密。
- 通过使用专用链接将流量保持在 Azure 中，可最大限度地减少数据外泄。
- 网络资源通过网络分段进行逻辑分组和相互隔离。
网络流
此图中的两个流包含在基线应用程序服务 Web 应用程序体系结构中：从最终用户到聊天 UI (1) 的入站流，以及从应用程序服务流到 Azure PaaS 服务 (2)。 本节重点介绍机器学习联机终结点流。 以下流程从基线应用程序服务 Web 应用程序中运行的聊天 UI 到部署到机器学习计算的流程：
- 来自应用程序服务托管聊天 UI 的调用会通过专用终结点路由到机器学习联机终结点。
- 联机终结点将调用路由到运行已部署流的服务器。 联机终结点既充当负载均衡器，又充当路由器。
- 对部署的流所需的 Azure PaaS 服务的调用会通过托管专用终结点来进行路由。
流入机器学习
在此体系结构中，禁用对机器学习工作区的公共访问。 用户可以通过专用访问访问工作区，因为体系结构遵循机器学习工作区配置的专用终结点。 事实上，专用终结点在整个体系结构中被用来补充基于身份的安全性。 例如，应用程序服务托管聊天 UI 可以连接到未公开到公共 Internet（包括 Azure 机器学习终结点）的 PaaS 服务。
连接到机器学习工作区进行流创作也需要使用专用终结点访问。
此图显示了通过 Azure Bastion 连接到虚拟机跳转框的提示流作者。 作者可以从跳转盒通过与跳转盒位于同一网络中的专用终结点连接到机器学习工作区。 与虚拟网络的连接也可以通过 ExpressRoute 或 VPN 网关和虚拟网络对等互联来实现。
从机器学习托管虚拟网络流向 Azure PaaS 服务
我们建议将机器学习工作区配置了托管虚拟网络隔离，要求所有出站连接都要经过批准。 此体系结构遵循这一建议。 经批准的出站规则有两种。 所需的出站规则是解决方案正常运行所需的资源，例如容器注册表和存储。 用户定义的出站规则适用于工作流要使用的自定义资源，例如 OpenAI 或 AI 搜索。 必须配置用户定义的出站规则。 创建托管虚拟网络时配置所需的出站规则。
出站规则可以是外部公共终结点的专用终结点、服务标记或目标完全限定域名 (FQDN)。 在此体系结构中，将通过专用链接连接到 Azure 服务，例如容器注册表、存储、Azure 密钥保管库、Azure OpenAI 服务和 AI 搜索。 尽管不在此体系结构中，但一些常见操作可能需要配置 FQDN 出站规则，如下载 pip 包、克隆 GitHub 存储库或从外部存储库下载基础容器映像。
虚拟网络分段和安全
此体系结构中的网络具有独立子网，用于以下目的：
- 应用程序网关
- 应用程序服务集成组件
- 专用终结点
- Azure Bastion
- 跳转盒虚拟机
- 训练 - 不用于此体系结构中的模型训练
- 计分
每个子网都有一个网络安全组 (NSG)，可将这些子网的入站和出站流量限制为仅限所需的流量。 下表显示了基线添加到每个子网的 NSG 规则的简化视图。 该表提供了规则名称和函数。
| 子网 | 入站 | 出站 |
|---|---|---|
| snet-appGateway | 为聊天 UI 用户源 IP（如公共 Internet）已预留的空间，以及服务所需的项目。 | 访问应用程序服务专用终结点，以及服务所需的项目。 |
| snet-PrivateEndpoints | 仅允许来自虚拟网络的流量。 | 仅允许到虚拟网络的流量。 |
| snet-AppService | 仅允许来自虚拟网络的流量。 | 允许访问专用终结点和 Azure Monitor。 |
| AzureBastionSubnet | 请参阅使用 NSG 访问和 Azure Bastion 的指南。 | 请参阅使用 NSG 访问和 Azure Bastion 的指南。 |
| snet-jumpbox | 允许来自 Azure Bastion 主机子网的入站远程桌面协议 (RDP) 和 SSH。 | 允许访问专用终结点 |
| snet-agents | 仅允许来自虚拟网络的流量。 | 仅允许到虚拟网络的流量。 |
| snet-training | 仅允许来自虚拟网络的流量。 | 仅允许到虚拟网络的流量。 |
| snet-scoring | 仅允许来自虚拟网络的流量。 | 仅允许到虚拟网络的流量。 |
明确拒绝所有其他流量。
在实现虚拟网络分段和安全性时，请考虑以下几点。
使用属于带公共 IP 地址的应用程序网关的子网为虚拟网络启用 DDoS 保护。
向每个子网添加 NSG（如果可能）。 使用最严格的规则来启用完整的解决方案功能。
使用应用程序安全组对 NSG 进行分组。 对 NSG 进行分组可简化复杂环境的规则创建。
内容筛选和滥用监视
Azure OpenAI 包括一个内容筛选系统，该系统使用分类模型运行来检测和防止输入提示和输出完成中特定类别的潜在有害内容。 这些潜在有害内容的类别包括仇恨、性、自残、暴力、亵渎和越狱（旨在绕过语言模型约束的内容）。 你可以为每个类别配置筛选内容的严格程度，选项包括低、中或高。 该参考体系结构采用严格的方法。 根据要求调整设置。
除了内容筛选之外，Azure OpenAI 还实现了滥用监视功能。 滥用监视是一种异步操作，旨在检测和减少重复出现的内容和/或行为，这些内容和/或行为表明服务的使用方式可能违反了 Azure OpenAI 行为准则。 如果数据高度敏感，或者有内部政策或适用的法律法规阻止为检测滥用情况而处理数据，则可以请求滥用监视和人工审查豁免。
可靠性
基线应用程序服务 Web 应用程序体系结构侧重于关键区域服务的区域冗余。 可用性区域是区域中在物理上独立的位置。 当跨区域部署两个或多个实例时，它们会在区域内为支持服务提供冗余。 当一个区域出现停机时，该区域内的其他区域可能仍不受影响。 该体系结构还确保有足够的 Azure 服务实例和这些服务的配置分布在各个可用性区域。 有关详细信息，请参阅查看该指南的基线。
本节将从此体系结构中未在应用程序服务基线中解决的组件（包括机器学习、Azure OpenAI 和 AI 搜索）的角度来解决可靠性问题。
流部署的区域冗余
企业部署通常需要做到区域冗余。 要在 Azure 中实现区域冗余，资源必须支持可用性区域，并且必须至少部署三项资源实例，或者在实例控制不可用时启用平台支持。 目前，机器学习计算不支持可用性区域。 为了减轻数据中心级灾难对机器学习组件的潜在影响，有必要在不同地区建立群集，并部署负载均衡器以便在这些集群之间分配调用。 你可以使用运行状况检查来帮助确保调用只会被路由到正常运行的群集。
部署提示流并不局限于机器学习计算群集。 可执行流是一个容器化应用程序，可以部署到任何与容器兼容的 Azure 服务。 这些选项包括 Azure Kubernetes 服务 (AKS)、Azure Functions、Azure 容器应用和应用程序服务等服务。 这些服务均支持可用性区域。 要实现提示流执行的区域性冗余，而不增加多区域部署的复杂性，则应将流部署到其中一个服务。
下图显示将提示流部署到应用程序服务的另一种体系结构。 之所以在此体系结构中使用应用程序服务，是因为工作负荷已将其用于聊天 UI，在工作负荷中引入新技术不会带来任何好处。 有 AKS 使用经验的工作负荷团队应考虑在该环境中进行部署，尤其是在工作负荷的其他组件也使用 AKS 的情况下。
图中对该体系结构中的重要区域进行了编号：
流仍在机器学习提示流中编写，机器学习网络体系结构保持不变。 流作者仍通过专用终结点连接到工作区创作体验，而托管专用终结点则用于在测试流时连接到 Azure 服务。
这条虚线表示已将容器化可执行流推送到容器注册表。 图中未显示将流容器化并推送到容器注册表的管道。
在同一个应用程序服务计划中还部署了另一个已经托管聊天 UI 的 Web 应用。 新的 Web 应用托管着容器化提示流，它们共存于同一应用程序服务计划中，而该计划已至少运行三个实例，分布在不同的可用性区域。 加载提示流容器映像时，这些应用程序服务实例会通过专用终结点连接到容器注册表。
提示流容器需要连接到所有依赖服务才能执行流。 在此体系结构中，提示流容器连接到 AI 搜索和 Azure OpenAI。 现在，仅向机器学习托管专用终结点子网公开的 PaaS 服务也需要在虚拟网络中公开，以便从应用程序服务建立连接。
Azure OpenAI - 可靠性
Azure OpenAI 目前不支持可用性区域。 要减轻数据中心级灾难对 Azure OpenAI 中模型部署的潜在影响，必须将 Azure OpenAI 部署到不同的区域，同时部署负载均衡器以便在各区域之间分配调用。 你可以使用运行状况检查来帮助确保调用只会被路由到正常运行的群集。
为有效支持多个实例，建议将微调文件外部化，例如转移到异地冗余 Azure 存储帐户。 这种方法最大限度地减少了每个区域存储在 Azure OpenAI 中的状态。 仍必须微调每个实例的文件才能托管模型部署。
在每分钟令牌 (TPM) 和每分钟请求 (RPM) 方面监视所需的吞吐量非常重要。 确保从配额中分配的足够 TPM 以满足部署需求，并阻止对已部署模型的调用受到限制。 Azure API 管理等网关可部署在 OpenAI 服务之前，并可在出现暂时性错误和限制的情况下进行重试配置。 API 管理还可以用作断路器，以防止服务因超出其配额的调用而过载。
AI 搜索 - 可靠性
在支持可用性区域的区域部署具有标准或更高定价层的的 AI Search，并部署三个或更多副本。 副本会自动均匀分布到各个可用性区域。
请考虑以下指南来确定适当的副本和分区数：
使用监视指标、日志和性能分析来确定适当的副本数量以避免基于查询的限制，并确定分区数量以避免基于索引的限制。
机器学习 - 可靠性
如果部署到机器学习托管联机终结点后面的计算群集，请考虑以下有关扩展的指南：
自动扩展联机终结点，确保有足够的容量来满足需求。 如果由于突发使用导致使用信号不够及时，则应考虑超量预配，以防止可用实例太少而影响可靠性。
积极的生产部署应部署不少于三个实例。
避免针对正在使用的实例进行部署。 改为部署到一个新的部署，并在部署准备好接收流量后将流量转移过来。
注意
如果将流部署到应用程序服务，则基线体系结构中的应用程序服务可扩展性指南同样适用。
安全性
此体系结构同时实现了网络和身份安全外围。 从网络的角度来看，唯一可以从 Internet 访问的是通过应用程序网关访问聊天 UI。 从身份的角度来看，聊天 UI 应对请求进行身份验证和授权。 在可能的情况下，使用托管标识对 Azure 服务应用程序进行身份验证。
本节介绍身份验证和访问控制管理，以及密钥轮换和 Azure OpenAI 模型微调的安全注意事项。
标识和访问管理
以下指南扩展了应用程序服务基线中的身份验证和访问控制管理指南：
- 在适用的情况下为以下机器学习资源创建单独的托管标识：
- 用于流创作和管理的工作区
- 用于测试流的计算实例
- 如果流量已部署到托管联机端点，则使用已部署流中的联机终结点
- 使用 Microsoft Entra ID 为聊天 UI 实现身份-访问控制
基于机器学习角色的访问角色
可以使用五个默认角色来管理对机器学习工作区的访问权限：AzureML 数据科学家、AzureML 计算操作员、读取者、参与者和所有者。 除了这些默认角色，还有一个 AzureML 学习工作区连接机密读取者和一个 AzureML 注册表用户，可授予对工作区机密和注册表等工作区资源的访问权限。
此体系结构遵循权限最小原则，只在需要时为前述身份分配角色。 请考虑以下角色分配。
| 托管的标识 | 范围 | 角色分配 |
|---|---|---|
| 工作区托管标识 | 资源组 | 参与者 |
| 工作区托管标识 | 工作区存储帐户 | 存储 Blob 数据参与者 |
| 工作区托管标识 | 工作区存储帐户 | 存储文件数据特权参与者 |
| 工作区托管标识 | 工作区密钥保管库 | Key Vault 管理员 |
| 工作区托管标识 | 工作区容器注册表 | AcrPush |
| 联机终结点托管标识 | 工作区容器注册表 | AcrPull |
| 联机终结点托管标识 | 工作区存储帐户 | 存储 Blob 数据读者 |
| 联机终结点托管标识 | 机器学习工作区 | AzureML 工作区连接机密读取者 |
| 计算实例托管标识 | 工作区容器注册表 | AcrPull |
| 计算实例托管标识 | 工作区存储帐户 | 存储 Blob 数据读者 |
密钥轮换
此体系结构中有两个服务使用基于密钥的身份验证：Azure OpenAI 和机器学习托管联机终结点。 由于你对这些服务使用基于密钥的身份验证，因此请务必：
将密钥存储在密钥保管库等安全存储中，以便从授权客户端（例如托管提示流容器的 Azure Web 应用）进行按需访问。
实施密钥轮换策略。 如果手动轮换密钥，则创建密钥过期策略并使用 Azure 策略来监视密钥是否已轮换。
OpenAI 模型微调
如果在实现过程中微调 OpenAI 模型，请考虑以下指南：
如果上传训练数据进行微调，请考虑使用客户托管密钥来加密这些数据。
如果在 Azure Blob 存储等存储中存储训练数据，请考虑使用客户托管密钥来进行数据加密，使用托管标识来控制对数据的访问，并使用专用终结点来连接到数据。
通过策略进行治理
为了确保与安全性保持一致，请考虑使用 Azure Policy 和网络策略，使部署符合工作负荷的要求。 通过策略使用平台自动化可减轻手动验证步骤的负担，并确保即使绕过管道，也可确保治理。 请考虑以下安全性策略：
- 在 Azure AI 服务和密钥库等服务中禁用密钥或其他本地身份验证访问。
- 需要对网络访问规则或 NSG 进行特定配置。
- 需要加密，例如使用客户管理的密钥。
成本优化
成本优化是关于寻找减少不必要的费用和提高运营效率的方法。 有关详细信息，请参阅成本优化设计评审核对清单。
要查看此方案的定价示例，请使用 Azure 定价计算器。 需要对示例进行定制以符合自己的使用情况，因为本示例仅包含体系结构中的组件。 方案中最贵组件是聊天 UI 和提示流计算及 AI 搜索。 优化这些资源，可节省最大成本。
计算
机器学习提示流支持多种托管可执行流的选项。 这些选项包括机器学习、AKS、应用程序服务和 Azure Kubernetes 服务中的托管联机终结点。 其中每个选项都有自己的计费模型。 计算选择会影响解决方案的总体成本。
Azure OpenAI
Azure OpenAI 是一种基于消费的服务，与任何基于消费的服务一样，控制需求与供应是控制成本的首要手段。 具体来说，要在 Azure OpenAI 中做到这一点，需要综合运用多种方法：
控制客户端。 在消耗模型中，客户端请求是成本的主要来源，因此控制客户行为至关重要。 所有客户端都应：
获得批准。 避免以支持免费访问的方式公开服务。 通过网络和身份控制，如密钥或基于角色的访问控制 (RBAC)，限制访问。
自我控制。 要求客户端使用 API 调用提供的令牌限制约束，如 max_tokens 和 max_completions。
在可行的情况下使用批处理。 查看客户端，确保它们对提示进行了适当的批处理。
优化提示输入和响应长度。 较长的提示会消耗更多的令牌，从而增加成本，但缺少足够上下文的提示无助于模型产生良好的结果。 创建简明扼要的提示，提供足够的上下文，让模型能够生成有用的响应。 同样，要确保优化响应长度的限制。
Azure OpenAI 操场的使用应视需要在预生产实例上进行，因此这些活动不会产生生产成本。
选择正确的 AI 模型。 模型选择对 Azure OpenAI 的总体成本也有很大影响。 所有模型都各有优缺点，并且价格也各不相同。 对用例使用正确的模型，确保在成本较低的模型产生可接受的结果时，不会在较昂贵的模型上花费过多。 在此聊天参考实现中，GPT 3.5-Turbo 是在 GPT-4 上选择的，以节省大约一个数量级的模型部署成本，同时获得足够的结果。
了解计费断点。 微调按小时收费。 为了达到最高效率，需要尽可能多地利用每小时可用的时间来改善微调结果，同时避免不知不觉就进入下一个计费周期。 同样，生成 100 个图像的成本与生成 1 个图像的成本相同。 最大限度地发挥价格突破点的优势。
了解计费模型。 Azure OpenAI 还可通过预配的吞吐量产品/服务在基于承诺的计费模型中使用。 有了可预测的使用模式后，如果根据使用量计算出这种预购计费模式更符合成本效益，则考虑改用这种模式。
设置预配限制。 确保所有预配配额只分配给预期属于工作负荷的模型（基于每个模型）。 在启用动态配额时，已部署模型的吞吐量不受此预配配额限制。 配额并不直接与成本挂钩，并且成本可能会有所不同。
监视即用即付使用情况。 如果使用即用即付定价，请监视 TPM 和 RPM 的使用情况。 用这些信息来告知体系结构设计决策，比如要使用的模型，以及优化提示大小。
成本管理。 遵循有关将成本管理功能与 OpenAI 配合使用的指南，以便监视成本、设置预算以管理成本，并创建警报以通知利益干系人风险或异常情况。
卓越运营
卓越运营概述了部署应用程序并使其在生产环境中保持运行的运营流程。 有关详细信息，请参阅设计卓越运营的审查清单。
机器学习 - 内置提示流运行时
为了最大限度地减少操作负担，自动运行时是机器学习中的无服务器计算选项，简化了计算管理并将大部分提示流配置委托给正在运行的应用程序的requirements.txt文件和flow.dag.yaml配置。 因此，此选项的维护、临时性和应用程序驱动性较低。 使用计算实例运行时或外部化计算（如在此体系结构中）需要更多工作负荷团队管理的计算生命周期，并且当工作负荷要求超过自动运行时选项的配置功能时，应选择此生命周期。
监视
为所有服务配置诊断。 除机器学习和应用程序服务外，所有服务都配置为捕获所有日志。 机器学习诊断配置为捕获审核日志，即记录客户与数据或服务设置交互的所有资源日志。 应用程序服务被配置为捕获 AppServiceHTTPLogs、AppServiceConsoleLogs、AppServiceAppLogs 和 AppServicePlatformLogs。
评估为此体系结构中的资源（例如 Azure Monitor 基线警报中找到的资源）生成自定义警报。 例如：
语言模型操作
基于 Azure OpenAI 的聊天解决方案（如本体系结构）的部署应遵循使用提示流和 Azure DevOps 的 LLMOps以及 GitHub中的指南。 此外，还必须考虑持续集成和持续交付 (CI/CD) 以及网络安全体系结构的最佳实践。 以下指南介绍了基于 LLMOps 建议实现流及其关联的基础结构。 此部署指南不包括前端应用程序元素，它们与基线高度可用的区域冗余 Web 应用程序体系结构中的元素相同。
开发
机器学习提示流可在机器学习工作室中或通过 Visual Studio Code 扩展提供基于浏览器的创作体验。 这两个选项将流代码存储为文件。 使用 Azure 机器学习工作室时，文件会被存储在存储帐户中。 在使用 Microsoft Visual Studio Code 服务时，文件会存储在本地文件系统上。
为了遵循协作开发的最佳做法，源文件应在联机源代码存储库（如 GitHub）中维护。 这种方法有助于跟踪所有代码更改、流作者之间的协作以及与测试并验证所有代码更改的部署流的集成。
对于企业开发，应使用 Microsoft Visual Studio Code 扩展和提示流 SDK/CLI 进行开发。 提示流作者可以从 Microsoft Visual Studio Code 生成和测试其流，并将本地存储的文件与联机源代码管理系统和管道集成。 虽然基于浏览器的体验非常适合探索性开发，但对于某些工作，它可以与源代码管理系统集成。 可以从 Files 面板中的流页面下载流文件夹，然后将其解压缩并推送到源代码管理系统。
计算
像测试其他软件项目一样测试聊天应用程序中使用的流。 指定和断言语言模型输出的单个“正确”答案非常困难，但你可以使用语言模型本身来评估响应。 考虑对语言模型流程实现以下自动评估：
分类准确性：评估语言模型提供的分数“正确”还是“不正确”，并聚合结果以生成准确性等级。
一致性：评估模型的预测答案中句子的编写好坏程度，以及它们如何相互保持连贯。
流畅性：评估模型预测答案的语法和语言准确性。
以上下文为基准：评估模型根据预配置的上下文预测答案的准确程度。 即使语言模型做出正确响应，但如果不能根据给定的上下文进行验证，那么响应也是没有根据的。
相关性：评估模型预测的答案与所提问题的吻合程度。
实现自动评估时，请考虑以下指南：
从评估中得出分数，并根据预定义的成功阈值对其进行度量。 使用这些分数来报告管道中的测试通过/失败。
其中一些测试需要输入预先配置的问题、上下文和基本事实的数据。
包含足够的问答对，以确保测试结果可靠，建议至少包含 100-150 个问答对。 这些问答对被称为“黄金数据集”。可能需要更大的数据规模，具体取决于数据集的大小和领域。
避免使用语言模型来生成黄金数据集中的任何数据。
部署流
提示工程师/数据科学家会打开一个功能分支，在其中可以处理特定任务或功能。 提示工程师/数据科学家使用 Microsoft Visual Studio Code 的提示流循环访问流，定期提交更改并将这些更改推送到功能分支。
本地开发和实验完成后，提示工程师/数据科学家会从功能分支向主分支打开一个拉取请求。 拉取请求 (PR) 会触发 PR 管道。 此管道可快速进行质量检查，其中应包括：
- 执行试验流
- 执行配置的单元测试
- 编译代码库
- 静态代码分析
管道可以包含一个步骤，要求至少一名团队成员在合并之前手动批准 PR。 审批者不能是提交者，他们必须拥有提示流专业知识，并熟悉项目要求。 如果 PR 未获批准，则合并就会被阻止。 如果 PR 已或批准，或者没有审批步骤，则功能分支合并到主分支中。
合并到主分支会触发开发环境的生成和发布流程。 具体而言：
- CI 管道从合并到主分支触发。 CI 管道会执行 PR 管道中完成的所有步骤，并执行以下步骤：
- 实验流
- 评估流
- 检测到更改时，在机器学习注册表中注册流
- CD 管道会在 CI 管道完成后触发。 该流执行以下步骤：
- 将流从机器学习注册表部署到机器学习联机终结点
- 运行面向联机终结点的集成测试
- 运行面向联机终结点的冒烟测试
发布升级流程中包含审批过程 - 经批准后，执行步骤 4.a 中所述的 CI 和 CD 流程。 并且会以测试环境为目标重复步骤 4.b。 步骤 a.和 b. 相同，只是用户验收测试会在测试环境中冒烟测试后运行。
执行步骤 4.a 中所述的 CI 和 CD 流程。 然后运行 4.b.，以便在测试环境得到验证和批准后，将发布推广到生产环境。
发布到实时环境后，将执行监视性能指标和评估已部署语言模型的操作任务。 这包括但不限于：
- 检测数据偏移
- 观察基础结构
- 管理成本
- 将模型的性能传达给利益干系人
部署指南
可以使用机器学习终结点在将模型发布到生产环境时灵活地部署模型。 请考虑以下策略，以确保最佳的模型性能和质量：
蓝/绿部署：使用此策略，可以在将所有流量定向到新部署之前，将新版本的 Web 服务安全地部署到有限的用户组或请求。
A/B 测试：蓝/绿部署不仅能有效安全地推出变更，还可用于部署新行为，让一部分用户能够评估变更的影响。
在管道中包含作为提示流一部分的 Python 文件的 Lint 分析。 Lint 分析会检查是否符合样式标准以及错误、代码复杂性、未使用的导入和变量命名。
将流部署到网络隔离机器学习工作区时，请使用自托管代理将项目部署到 Azure 资源。
机器学习模型注册表只应在模型发生更改时更新。
语言模型、流和客户端 UI 应松散耦合。 可以并且应该对流和客户端 UI 进行更新，但不能影响模型，反之亦然。
在开发和部署多个流时，每个流都应有自己的生命周期，这样才能在将流从试验阶段推广到生产阶段时获得松散耦合的体验。
基础结构
在部署基线 Azure OpenAI 端到端聊天组件时，预配的某些服务在体系结构中是基础性和永久性的，而其他组件本质上更具有临时性，其存在与部署有关。
基础组件
此体系结构中的某些组件的生命周期超出了任何单个提示流或任何模型部署的范围。 这些资源通常由工作负荷团队作为基础部署的一部分部署一次，并在新增、删除或更新提示流或模型部署时进行维护。
- 机器学习工作区
- 机器学习工作区的存储帐户
- 容器注册表
- AI 搜索
- Azure OpenAI
- Azure Application Insights
- Azure Bastion
- 用于跳转盒的 Azure 虚拟机
临时组件
某些 Azure 资源更紧密地耦合到特定提示流的设计。 此方法允许这些资源绑定到组件的生命周期，并在此体系结构中成为临时资源。 当工作负荷发生变化时，例如添加或删除流量或引入新模型时，Azure 资源会受到影响。 这些资源会被重新创建，而之前的实例会被删除。 其中有些资源是直接的 Azure 资源，有些则是包含在其服务中的数据平面表现形式。
如果机器学习模型注册表中的模型发生更改，应将其作为为 CD 管道的一部分进行更新。
作为 CD 管道的一部分，容器映像应在容器注册表中更新。
如果部署引用不存在的终结点，则会在部署提示流时创建机器学习终结点。 该终结点需要更新才能关闭公共访问。
在部署或删除流时，机器学习终结点的部署会被更新。
在创建新终结点时，必须使用终结点的密钥来更新客户端 UI 的密钥库。
性能效率
性能效率是指工作负荷能够有效扩展以满足用户对它的要求。 有关详细信息，请参阅性能效率设计评审核对清单。
本节将从 Azure 搜索、Azure OpenAI 和机器学习的角度介绍性能效率。
Azure 搜索 - 性能效率
按照指南分析 AI 搜索中的性能。
Azure OpenAI - 性能效率
确定应用程序是否需要预配的吞吐量或使用共享托管或消耗模型。 预配的吞吐量可为 OpenAI 模型部署确保预留处理能力，为模型提供可预测的性能和吞吐量。 此计费模型与共享托管或消耗模型不同。 消费模式是尽力而为的，可能会受到平台上嘈杂的邻居或其他压力源的影响。
对于预配吞吐量，监视预配托管利用率
Azure 机器学习 - 性能效率
如果将机器学习模型部署到联机终结点：
按照有关如何自动扩展联机终结点的指导进行操作。 这样做可以与需求保持密切一致，而无需过度预配，尤其是在低使用率期间。
为联机终结点选择适当的虚拟机 SKU 以满足性能目标。 测试较少实例计数和较大 SKU 与较大实例计数和较小 SKU 的性能，以找到最佳配置。
部署此方案
要部署并运行参考实现，请按照 OpenAI 端到端基线参考实现中的步骤进行操作。
作者
本文由 Microsoft 维护， 它最初是由以下贡献者撰写的。
- Rob Bagby | 模式和做法 - Microsoft
- Freddy Ayala | 云解决方案架构师 - Microsoft
- Prabal Deb | 高级软件工程师 - Microsoft
- Raouf Aliouat | 软件工程师 II - Microsoft
- Ritesh Modi | 首席软件工程师 - Microsoft
- Ryan Pfalz | 高级解决方案架构师 - Microsoft
要查看非公开的 LinkedIn 个人资料，请登录到 LinkedIn。