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