通过

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

基线 Azure AI Foundry 聊天参考体系结构

Azure OpenAI 服务
Azure AI 服务
Azure 应用程序服务
Azure Monitor

企业聊天应用程序可以通过与 AI 代理的对话交互为员工提供支持。 由于语言模型（如 OpenAI 的 GPT 模型和语义内核等业务流程 SDK）的持续进步，此功能越来越强大。 这些聊天应用程序通常包含以下组件：

  • 集成到大型企业应用程序的聊天用户界面（UI）。 它为用户提供与其他业务功能的对话体验。

  • 包含与用户查询相关的特定于域的信息的数据存储库。

  • 导致特定于域的数据生成相关响应的语言模型。

  • 一个业务流程协调程序或代理，用于监视数据源、语言模型和最终用户之间的交互。

本文提供了一个基线体系结构，可帮助你使用 Azure AI Foundry 和 Azure OpenAI 语言模型构建和部署企业聊天应用程序。 此体系结构使用 Azure AI Foundry 代理服务中托管的单个代理。 代理接收用户消息，然后查询数据存储以检索语言模型的地面信息。

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

重要

本文不介绍 基线应用服务 Web 应用程序体系结构中的组件或体系结构决策。 阅读该文章，获取有关如何托管包含聊天 UI 的 Web 应用程序的体系结构指南。

此体系结构使用 Foundry 代理服务标准代理设置 来实现企业级安全性、合规性和控制。 在此配置中，你将自带网络隔离网络和自己的 Azure 资源来存储聊天和代理状态。 应用程序组件与 Azure 服务之间的所有通信都通过专用终结点进行，这可确保数据流量保留在工作负荷的虚拟网络中。 来自代理的出站流量严格通过 Azure 防火墙路由，该防火墙强制实施出口规则。

小窍门

Foundry 代理服务参考实现展示了 Azure 上的基线端到端聊天实现。 它作为开发自定义解决方案的基础，当你走向生产。

建筑

显示使用 Azure AI Foundry 的基线端到端聊天体系结构的关系图。

下载此体系结构的 Visio 文件。

工作流程

  1. 应用程序用户与聊天 UI 交互。 请求通过 Azure 应用程序网关路由。 Azure Web 应用程序防火墙在将请求转发到后端应用服务之前会检查这些请求。

  2. 当 Web 应用程序收到用户查询或指令时，它将调用专用的代理。 Web 应用程序通过 Azure AI 代理 SDK 与代理通信。 Web 应用程序通过专用终结点调用代理，并使用其托管标识向 Azure AI Foundry 进行身份验证。

  3. 代理根据系统提示中的说明处理用户的请求。 为了满足用户的意图，代理使用配置的语言模型和连接的工具和知识存储。

  4. 代理通过专用终结点连接到专用网络中的知识存储（Azure AI 搜索）。

  5. 对外部知识存储或工具（如维基百科或必应）的请求会遍历 Azure 防火墙，以检查和出口策略强制实施。

  6. 代理连接到其配置的语言模型并传递相关上下文。

  7. 在代理将响应返回到 UI 之前，它会将请求、生成的响应和已咨询的知识存储列表保存到专用 内存 数据库中。 此数据库维护完整的会话历史记录，该历史记录使上下文感知交互能够让用户恢复与代理的对话，而不会丢失以前的上下文。

    Azure AI Foundry API 支持开发管理多个并发的上下文隔离对话的用户体验。

组件

此体系结构基于 基本的 Azure AI Foundry 聊天参考体系结构。 此体系结构引入了更多 Azure 服务，以满足企业对可靠性、安全性和运营控制的要求。 以下每个组件在生产企业聊天解决方案中扮演特定角色：

  • Foundry 代理服务 为聊天交互提供业务流程层。 它托管和管理执行以下任务的代理：

    • 处理用户请求
    • 协调对工具和其他代理的调用
    • 强制实施内容安全
    • 与企业标识、网络和可观测性集成

    标准代理设置可确保网络隔离并提供对数据存储的控制。 为代理状态、聊天历史记录和文件存储提供专用 Azure 资源，Foundry 代理服务专门管理这些资源。 工作负荷中的其他应用程序组件不应使用这些所需的资源。

    • Azure Cosmos DB for NoSQL 在订阅中托管此工作负荷的内存数据库（称为 enterprise_memory）。 此数据库存储代理的作状态，包括聊天线程和代理定义。 此设计可确保聊天历史记录和代理配置是隔离的、可审核的，并根据数据管理要求进行管理。 Foundry 代理服务管理数据库、其集合和数据。

    • 专用 Azure 存储帐户 存储聊天会话期间上传的文件。 在订阅中托管此帐户可提供精细的访问控制、审核功能以及数据驻留或保留策略的符合性。 Foundry 代理服务在这些容器中管理容器和数据生命周期。

    • 专用 AI 搜索 实例存储与代理对话中上传文件的可搜索分块索引。 它还存储创建代理时添加为知识源的静态文件。 Foundry 代理服务管理索引、架构和数据，并使用其自己的分块策略和查询逻辑。

  • 应用程序网关 充当发送到聊天 UI 的所有 HTTP 和 HTTPS 流量的安全可缩放入口点。 它提供传输层安全性（TLS）终止和基于路径的路由。 它还跨可用性区域分配请求，这些区域支持 Web 应用程序层的高可用性和性能。 其后端是托管应用程序代码的应用服务。

    • Azure Web 应用程序防火墙 与应用程序网关集成，以保护聊天 UI 免受常见的 Web 漏洞和攻击。 它会检查和筛选 HTTP 请求，该请求为面向公众的应用程序提供安全层。

    • Azure Key Vault 安全地存储和管理应用程序网关所需的 TLS 证书。 Key Vault 中的集中式证书管理支持自动轮换、审核和符合组织安全标准。 此体系结构不需要存储的密钥或其他机密。

  • Azure 虚拟网络 为所有组件提供网络隔离。 在专用虚拟网络中放置资源时，可以控制东西部和南北流量，强制分段，使流量保持专用，并启用入口和出口流的检查。 此设置可帮助你满足安全性和合规性要求。

  • Azure 专用链接 通过专用终结点将所有 PaaS 服务（例如 Azure Cosmos DB、存储、AI 搜索和 Foundry 代理服务）连接到虚拟网络。 此方法可确保所有数据流量都保留在 Azure 主干上，从而消除对公共 Internet 的暴露并降低攻击面。

  • Azure 防火墙 检查和控制来自虚拟网络的所有出站（出口）流量。 它强制实施基于完全限定的域名（FQDN）规则，以确保只有已批准的目标可访问。 此配置有助于防止数据外泄并满足网络安全要求。

  • Azure DNS 提供链接到虚拟网络的专用域名系统（DNS）区域。 此功能为专用终结点启用名称解析，这可确保所有服务到服务通信都使用专用 IP 地址，并保留在网络边界内。

  • 存储 将 Web 应用程序代码作为 ZIP 文件托管，以便部署到应用服务。 此方法支持安全、自动化的部署工作流，并将应用程序项目与计算资源分开。

替代方案

此体系结构包括多个组件，这些组件可以替换为其他 Azure 服务或方法，具体取决于工作负荷的功能和非功能要求。 请考虑以下替代方案和权衡。

聊天业务流程

当前方法： 此体系结构使用 Foundry 代理服务 来协调聊天流，包括从知识存储提取地面数据以及调用 Azure OpenAI 模型。 Foundry 代理服务提供无代码的、不确定的业务流程。 它处理聊天请求、线程管理、工具调用、内容安全以及与标识、网络和可观测性的集成。 它提供本机内存数据库解决方案。

替代方法： 可以使用 语义内核 或 LangChain 等框架自行托管业务流程层。 使用这些框架来实现确定性、代码驱动的聊天流和自定义业务流程逻辑。

如果工作负荷需要以下功能，请考虑此替代方法：

  • 对业务流程序列、工具调用或提示工程的精细确定性控制

  • 与 Foundry 代理服务本身不支持的自定义业务逻辑或外部系统集成

  • 试验或安全部署做法的高级客户端请求路由

  • 与本机 Foundry 代理服务解决方案不同的自定义内存数据库解决方案

自承载业务流程提高了作复杂性，需要管理计算、缩放和安全性。

应用程序层组件

当前方法： 聊天 UI 前端网站托管在应用服务的 Web 应用功能上，该功能为 Web 应用程序提供托管的可缩放平台。 Web 应用与 Azure 网络和安全功能本机集成。

替代方法： 可以使用其他 Azure 托管的计算平台（例如 Azure 容器应用或 Azure Kubernetes 服务（AKS）来托管应用程序层。

如果工作负荷满足以下任一条件，请考虑此替代方法：

  • 另一个计算平台更好地支持某些用例，并在该平台上共置服务可以提高成本效益并简化作

  • 应用程序需要更复杂的缩放、业务流程或自定义网络

应用服务仍然是托管 Web 应用程序及其 API 时的首选选项。

地面数据（知识）存储

当前方法： 此体系结构使用 AI 搜索作为基础知识的主要数据存储。 它使用 AI 搜索矢量搜索和语义排名功能。

替代方法： 可以使用其他数据平台来记录知识，例如 Azure Cosmos DB、Azure SQL 数据库或其他联机事务处理（OLTP）数据存储。 数据平台取决于现有的数据资产、数据新鲜度要求和查询要求。

如果工作负荷满足以下任一条件，请考虑此替代方法：

  • 你已在现有事务或作数据库中管理基础知识

  • 需要 AI 搜索中不提供多模型或 SDK 支持

  • 需要与专用数据源或旧系统集成

矢量搜索通常用于检索扩充生成，但并非总是必需的。 有关详细信息，请参阅选择 Azure 矢量搜索服务。 在选择数据存储之前，请评估工作负荷的数据访问模式、延迟和可伸缩性需求。

预定义代理或动态创建的代理

当前方法： 参考实现使用静态定义的代理，该代理部署为 Azure AI Foundry 中的微服务。 代理的逻辑和数据源在部署时配置，在下次应用程序发布之前保持不变。 当代理行为和数据源稳定且通过 DevOps 进程进行控制时，此方法非常有效。

替代方法： 可以使用 Azure AI 代理 SDK 在运行时动态创建或修改代理。 此方法允许应用程序按需实例化代理、调整系统提示，或根据用户上下文或业务逻辑重新配置连接。

如果工作负荷需要以下功能，请考虑动态代理：

  • 每个用户或会话的个性化代理行为或数据源

  • 代理配置的频繁或编程更改

  • 针对高级用户体验的临时特定于上下文的代理支持

动态代理管理增加了灵活性，但也引入了生命周期管理的负担。 确保对代理创建、修改和清理具有适当的控制。

选择符合工作负载用户体验要求的代理方法。

注意事项

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

在工作负荷的设计阶段，将此体系结构和 AI 工作负载应用于 Azure 设计指南 。

可靠性

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

基线应用服务 Web 应用程序体系结构侧重于关键区域服务的区域性冗余。 可用性区域在物理上是单独的位置，可在区域中部署两个或多个实例时提供冗余。 如果一个区域遇到故障时间，则该区域中的其他区域可能不受影响。 该体系结构还会跨可用性区域分发 Azure 服务的实例和配置。 有关详细信息，请参阅 基线高度可用的区域冗余 Web 应用程序。

本部分介绍应用服务基线体系结构中未涵盖的组件的可靠性，特别是 Azure AI Foundry 和 AI 搜索。

业务流程层中的区域冗余

企业部署通常需要区域性冗余，以最大程度地降低区域级故障导致服务中断的风险。 在 Azure 中，区域冗余意味着使用支持 可用性区域 的资源并部署至少三个实例，或启用直接实例控制不可用的平台级冗余。

在此体系结构中，Azure AI Foundry 托管 Foundry 代理服务功能。 代理的可靠性取决于 Foundry 代理服务依赖项的可用性，这些依赖项是 Azure Cosmos DB、存储和 AI 搜索。 Foundry 代理服务管理这些服务中的数据，但在订阅中配置其可靠性。

若要实现业务流程层的区域性冗余，请遵循以下建议：

如果代理与其他特定于工作负荷的依赖项（例如自定义工具连接或外部知识存储）集成，请确保这些依赖项满足可用性和冗余要求。 任何单区域或非破坏依赖项都可能会破坏业务流程层的整体可靠性。

AI Foundry 门户及其数据平面 API 和 Foundry 代理服务功能不提供区域冗余的直接控制。

Azure AI Foundry 模型托管的可靠性

Azure AI Foundry 通过多个部署选项提供模型即服务（MaaS）托管。 这些选项主要支持配额和吞吐量管理，而不是区域中的传统高可用性。 标准模型部署在单个区域中运行，不支持可用性区域。 若要实现多数据中心可用性，必须使用全局或数据区域模型部署。

对于企业聊天方案，请部署 预配的数据区域 和数据 区域标准 模型。 配置 溢出 以处理过多流量或故障。 如果工作负荷不需要低延迟或严格的地理数据驻留和处理，请使用全局部署实现最大复原能力。

Azure AI Foundry 不支持用于模型部署的高级负载均衡或故障转移机制，例如轮循路由或 断路器。 如果需要在区域内进行精细冗余和故障转移控制，请在托管服务外部托管模型访问逻辑。 例如，可以使用 Azure API 管理生成自定义网关。 此方法允许实现自定义路由、运行状况检查和故障转移策略。 但它也会提高运营复杂性，并将该组件的可靠性的责任转移到团队。

还可以将网关前端模型公开为代理的自定义基于 API 的工具或知识存储。 有关详细信息，请参阅在多个 Azure OpenAI 部署或实例前使用网关。

AI 搜索中用于企业知识的可靠性

在 支持可用性区域的区域中使用标准定价层或更高版本部署 AI 搜索。 配置至少三个副本，以确保服务跨单独的可用性区域分发实例。 此配置提供对区域级别故障的复原能力，并支持搜索作的高可用性。

若要确定工作负荷的最佳副本和分区数，请使用以下方法：

  • 使用内置指标和日志监视 AI 搜索。 跟踪查询延迟、限制和资源使用情况。

  • 使用监视指标和性能分析来确定适当的副本数。 此方法有助于避免对查询量过高、分区不足或索引限制进行限制。

  • 通过避免定期索引或索引错误中断来确保索引可靠性。 在验证数据完整性后，请考虑将索引编制到脱机索引，并从实时索引交换到重新生成的索引。

Azure 防火墙中的可靠性

Azure 防火墙是此体系结构中的关键出口控制点，但表示所有出站流量的单一故障点。 若要缓解此风险，请在区域中 的所有可用性区域 部署 Azure 防火墙。 如果某个区域不可用，此配置有助于维护出站连接。

如果工作负荷需要大量并发出站连接，请使用多个公共 IP 地址配置 Azure 防火墙。 此方法跨 多个 IP 地址前缀分配源网络地址转换（SNAT）连接，从而减少 SNAT 端口耗尽的风险。 SNAT 耗尽 可能会导致代理和其他工作负荷组件的间歇性或完全的出站连接丢失，这可能会导致功能停机或性能下降。

监视 SNAT 端口使用情况和防火墙运行状况。 如果观察到连接故障或吞吐量问题，请查看防火墙指标和日志，以确定和解决 SNAT 耗尽或其他瓶颈。

将 Foundry 代理服务依赖项与类似的工作负荷组件隔离

若要最大程度地提高可靠性和最大程度地减少故障的爆破半径，请严格隔离 Foundry 代理服务依赖项与使用同一 Azure 服务的其他工作负荷组件。 具体而言，不要在代理服务和其他应用程序组件之间共享 AI 搜索、Azure Cosmos DB 或存储资源。 而是为代理服务的所需依赖项预配专用实例。

这种分离提供两个关键优势：

  • 它包含单个工作负荷段的故障或性能下降，这可以防止跨不相关的应用程序功能产生级联影响。

  • 它使你能够应用目标作过程，例如备份、还原和故障转移。 这些进程针对使用这些资源的工作负荷流的特定可用性和恢复要求进行了优化。

例如，如果聊天 UI 应用程序需要在 Azure Cosmos DB 中存储事务状态，请为此预配单独的 Azure Cosmos DB 帐户和数据库，而不是重用 Foundry 代理服务管理的帐户或数据库。 即使成本或运营简单性促使资源共享，影响不相关的工作负荷功能的可靠性事件的风险也超过了大多数企业方案中的潜在节省。

重要

如果出于成本或作原因将特定于工作负荷的数据与代理的依赖项并置，则永远不会与 Foundry 代理服务创建的系统托管数据（例如集合、容器或索引）直接交互。 这些内部实现详细信息是未经记录的，不会通知更改。 直接访问可能会中断代理服务或导致数据丢失。 始终使用 Foundry 代理服务数据平面 API 进行数据作，并将基础数据视为不透明和仅监视。

多区域设计

此体系结构使用可用性区域实现单个 Azure 区域中的高可用性。 这不是多区域解决方案。 它缺少区域复原和灾难恢复所需的以下关键要素（DR）：

  • 全局入口和流量路由
  • 用于故障转移的 DNS 管理
  • 跨区域的数据复制或隔离策略
  • 主动-主动、主动-被动或主动冷指定
  • 区域故障转移和故障回复过程，以满足恢复时间目标（RTO）和恢复点目标（RPO）
  • 考虑开发人员体验的区域可用性，包括 Azure AI Foundry 门户和数据平面 API

如果工作负荷需要业务连续性（如果发生区域性服务中断），则必须在此体系结构之外设计和实现额外的组件和作流程。 具体而言，需要解决每个体系结构层的负载均衡和故障转移问题，包括以下方面：

  • 地面数据（知识存储）
  • 模型托管和推理终结点
  • 业务流程或代理层
  • 面向用户的 UI 流量和 DNS 入口点

还必须确保可观测性、监视和内容安全控制在整个区域保持运行和一致。

此基线体系结构缺少多区域功能，因此区域中断可能会导致工作负荷内的服务丢失。

灾难恢复

聊天体系结构包含有状态组件，因此 DR 规划至关重要。 这些工作负载通常需要内存存储来存储活动或暂停的聊天会话。 它们还需要存储补充数据，例如添加到聊天线程的文档或图像。 代理业务流程层还可能维护特定于聊天流的状态。 在此体系结构中，Foundry 代理服务使用 Azure Cosmos DB、存储和 AI 搜索来保留作和事务状态。 此状态跨组件的生命周期和耦合决定了 DR 策略和恢复作。

对于 Foundry 代理服务，请确保可以将所有依赖项恢复到一致的时间点。 此方法有助于跨三个外部依赖项维护事务完整性。

以下建议解决了每个服务的 DR 问题：

  • Azure Cosmos DB：为enterprise_memory数据库启用连续备份。 此设置提供具有七天的 RPO 的时间点还原（PITR），其中包括代理定义和聊天线程。 定期测试还原过程，确认它是否满足 RTO，并且还原的数据仍可供代理服务使用。 始终还原到同一帐户和数据库。

  • AI 搜索： AI 搜索缺少内置还原功能，不支持直接索引作。 如果发生数据丢失或损坏，则必须联系Microsoft支持人员获取索引还原方面的帮助。 此限制可能会显著影响 RTO。 如果聊天 UI 不支持文件上传，并且没有将静态文件用作知识的代理，则可能不需要 AI 搜索的 DR 计划。

    为企业基础知识维护单独的定期更新真相来源。 这种做法可确保在必要时重新生成索引。

  • 存储： 如果有异地冗余存储帐户，请对 Foundry 代理服务使用的 Blob 容器使用 客户管理的故障转移 。 此设置允许你在发生区域性服务中断期间启动故障转移。 如果仅使用区域冗余存储，请联系Microsoft支持人员还原数据。 此过程可能会扩展 RTO。 与 AI 搜索一样，如果聊天 UI 不支持文件上传，并且没有将静态文件用作知识的代理，则可能不需要 Blob 容器的 DR 计划。

  • 事务一致性： 如果工作负荷中的状态存储引用 Azure AI 代理标识符（例如线程 ID 或代理 ID），则协调所有相关数据存储之间的恢复。 仅还原依赖项的子集可能会导致孤立或不一致的数据。 设计 DR 流程，以维护工作负荷与代理服务状态之间的引用完整性。

  • 代理定义和配置： 将代理 定义为代码。 在源代码管理中存储代理定义、连接、系统提示和参数。 这种做法使你能够从已知良好的配置重新部署代理（如果丢失业务流程层）。 避免通过 AI Foundry 门户或数据平面 API 对代理配置进行未跟踪的更改。 此方法可确保已部署的代理保持可重现性。

在迁移到生产环境之前，请生成恢复 Runbook，以解决应用程序拥有状态和代理拥有状态中的故障。

安全

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

此体系结构扩展了 基本 Azure AI Foundry 聊天参考体系结构中建立的安全基础。 主要区别是添加网络安全外围以及基本体系结构中的标识外围。 从网络的角度来看，应用程序网关是唯一公开 Internet 的资源。 它使聊天 UI 应用程序可供用户使用。 从身份的角度来看，聊天 UI 应对请求进行身份验证和授权。 尽可能使用托管标识向 Azure 服务验证应用程序。

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

标识和访问管理

此体系结构主要使用系统分配的托管标识进行服务到服务身份验证。 还可以使用用户分配的托管标识。 在任一情况下，都应用以下原则：

  • 按资源和函数隔离标识。 为以下组件预配不同的托管标识：

    • Azure AI Foundry 帐户
    • 每个 Azure AI Foundry 项目
    • Web 应用程序
    • 任何自定义业务流程协调程序或集成代码

  • 仅当该资源必须作为客户端向另一个 Azure 服务进行身份验证时，才向 Azure 资源分配标识。

  • 使用适合用途的标识类型。 尽可能对应用程序和自动化使用 工作负荷标识 ，并为 AI 代理使用 代理标识 。

Azure AI Foundry 门户员工访问权限

将员工加入 Azure AI Foundry 项目时，请为其角色分配所需的最低权限。 使用Microsoft Entra ID 组和基于角色的访问控制（RBAC）强制分离职责。 例如，将代理开发人员与处理微调任务的数据科学家区分开来。 但是，请注意限制和风险。

Azure AI Foundry 门户使用服务的标识而不是员工标识运行许多作。 因此，具有有限 RBAC 角色的员工可能能够查看敏感数据，例如聊天线程、代理定义和配置。 此 AI Foundry 门户设计可能会无意中绕过所需的访问约束，并公开比预期更多的信息。

若要降低未经授权的访问风险，请在生产环境中将门户使用情况限制为具有明确运营需求的员工。 对于大多数员工，在生产环境中禁用或阻止访问 Azure AI Foundry 门户。 而是使用自动化部署管道和基础结构作为代码（IaC）来管理代理和项目配置。

将 Azure AI Foundry 帐户中的创建新项目视为特权作。 通过门户创建的项目不会自动继承已建立的网络安全控制，例如专用终结点或网络安全组（NSG）。 这些项目中的新代理会绕过预期的安全外围。 仅通过受控的可审核的 IaC 流程强制创建项目。

Azure AI Foundry 项目角色分配和连接

若要在标准模式下使用 Foundry 代理服务，项目必须具有对 Foundry 代理服务依赖项的管理权限。 具体而言，项目的托管标识必须在存储帐户、AI 搜索和 Azure Cosmos DB 帐户上具有提升的角色分配。 这些权限提供对这些资源的几乎完全访问权限，包括读取、写入、修改或删除数据的能力。 若要维护最低特权访问，请将工作负荷资源与 Foundry 代理服务依赖项隔离开来。

单个 AI Foundry 项目中的所有代理共享相同的托管标识。 如果工作负荷使用需要访问不同资源集的多个代理，则最低权限原则要求为每个不同的代理访问模式创建单独的 Azure AI Foundry 项目。 这种分离允许你仅向每个项目的托管标识分配所需的最低权限，从而降低过度或意外访问的风险。

从 Azure AI Foundry 中建立与外部资源 的连接 时，请使用 Microsoft基于 Entra ID 的身份验证（如果可用）。 此方法无需维护预共享机密。 限制每个连接，以便只有拥有项目可以使用它。 如果多个项目需要访问同一资源，请在每个项目中创建单独的连接，而不是跨项目共享单个连接。 这种做法强制实施严格的访问边界，并防止将来的项目继承不需要的访问权限。

避免在 Azure AI Foundry 帐户级别创建连接。 这些连接适用于帐户中的所有当前和将来项目。 他们无意中授予对资源的广泛访问权限，违反最低特权原则，并增加未经授权的数据泄露风险。 仅首选项目级连接。

网络

除了基于标识的访问之外，此体系结构还需要网络机密性。

网络设计包括以下安全措施：

  • 所有聊天 UI 流量的单一安全入口点，可最大程度地减少攻击面

  • 通过使用 NSG、Web 应用程序防火墙、用户定义的路由和 Azure 防火墙规则的组合筛选入口和出口网络流量

  • 使用 TLS 对传输中的数据进行端到端加密

  • 为所有 Azure PaaS 服务连接使用专用链接实现网络隐私

  • 网络资源的逻辑分段和隔离，每个主要组件分组的专用子网都支持精细的安全策略

网络流

显示基线应用服务 Web 应用程序体系结构和 Foundry 代理服务网络流的两个网络流的关系图。

基线应用服务 Web 应用程序体系结构概述了从用户到聊天 UI 的入站流，以及从应用服务流到 Azure PaaS 服务的流。 本部分重点介绍代理交互。

聊天 UI 与 Azure AI Foundry 中部署的代理通信时，会发生以下网络流：

  1. 应用服务托管的聊天 UI 通过专用终结点向 Azure AI Foundry 数据平面 API 终结点发起 HTTPS 请求。

  2. 当代理访问 Azure PaaS 服务（例如服务依赖项、自定义知识存储或自定义工具）时，它会将来自委托子网的 HTTPS 请求发送到这些服务的专用终结点。

  3. 当代理访问虚拟网络外部的资源（包括基于 Internet 的 API 或外部服务）时，强制通过 Azure 防火墙从委托子网路由这些 HTTPS 请求。

专用终结点通过补充基于标识的安全性作为此体系结构中的关键安全控制。

流入 Azure AI Foundry

此体系结构仅允许通过 Azure AI Foundry 专用链接的流量来禁用对 Azure AI Foundry 数据平面的公共访问。 可以通过 门户网站访问大部分 Azure AI Foundry 门户，但所有项目级功能都需要网络访问。 门户依赖于 AI Foundry 帐户的数据平面 API，这些 API 只能通过专用终结点访问。 因此，开发人员和数据科学家必须通过跳转框、对等虚拟网络或 ExpressRoute 或站点到站点 VPN 连接访问门户。

调用模型推理时，与代理数据平面（例如从 Web 应用程序或外部业务流程代码）进行的所有编程交互也必须使用这些专用终结点。 专用终结点在帐户级别定义，而不是项目级别。 因此，帐户中的所有项目共享同一组终结点。 不能在项目级别分段网络访问，并且所有项目共享相同的网络公开。

若要支持此配置，请为以下 Azure AI Foundry FQDN API 终结点设置 DNS：

  • privatelink.services.ai.azure.com
  • privatelink.openai.azure.com
  • privatelink.cognitiveservices.azure.com

下图显示了 AI 开发人员如何通过 Azure Bastion 连接到虚拟机（VM）跳转盒。 在该跳转框中，作者可以通过同一网络中专用终结点访问 Azure AI Foundry 门户中的项目。

显示用户如何通过 Azure Bastion 连接到跳转盒 VM 的关系图。

控制来自 Azure AI Foundry 代理子网的流量

此体系结构通过虚拟网络中的委托子网路由来自 Foundry 代理服务功能的所有出站（出口）网络流量。 此子网充当代理所需的三个服务依赖项以及代理使用的任何外部知识源或工具连接的唯一出口点。 此设计有助于减少业务流程逻辑中的数据外泄尝试。

通过强制此出口路径，可以完全控制出站流量。 可以将精细 NSG 规则、自定义路由和 DNS 控制应用到离开服务的所有代理流量。

代理服务使用虚拟网络的 DNS 配置来解析专用终结点记录和所需的外部 FQDN。 此设置可确保代理的请求生成 DNS 日志，这些日志支持审核和故障排除。

附加到代理出口子网的 NSG 会阻止所有入站流量，因为不应发生合法的入口。 出站 NSG 规则仅允许访问虚拟网络中的专用终结点子网和传输控制协议 （TCP） 端口 443，用于 Internet 绑定流量。 NSG 拒绝所有其他流量。

为了进一步限制 Internet 流量，此体系结构将 UDR 应用到子网，该子网通过 Azure 防火墙定向所有 HTTPS 流量。 防火墙控制代理可以通过 HTTPS 连接访问的 FQDN。 例如，如果代理只需要 使用必应 公共 API 访问地面，请将 Azure 防火墙配置为允许从此子网到 api.bing.microsoft.com 端口 443 上的流量。 所有其他出站目标均被拒绝。

虚拟网络分段和安全

此体系结构通过将每个主要组件组分配到其自己的子网来细分虚拟网络。 每个子网都有一个专用的 NSG，该 NSG 仅将入站和出站流量限制为组件所需的流量。

下表汇总了每个子网的 NSG 和防火墙配置。

使用情况或子网名称 入站流量 （NSG） 出站流量 （NSG） UDR 到防火墙 防火墙出口规则
专用终结点
snet-privateEndpoints		 虚拟网络 不允许流量 是的 不允许流量
应用程序网关
snet-appGateway		 聊天 UI 用户源 IP 地址，例如公共 Internet，以及服务所需的源 专用终结点子网和服务所需的项 否 -
应用服务
snet-appServicePlan		 不允许流量 专用终结点和 Azure Monitor 是的 到 Azure Monitor
Foundry 代理服务
snet-agentsEgress		 不允许流量 专用终结点和 Internet 是的 仅允许代理使用的公共 FQDN
跳转盒 VM
snet-jumpBoxes		 Azure Bastion 子网 专用终结点和 Internet 是的 VM 根据需要
生成代理
snet-buildAgents		 Azure Bastion 子网 专用终结点和 Internet 是的 VM 根据需要
Azure Bastion
AzureBastionSubnet		 请参阅 NSG 访问和 Azure Bastion 请参阅 NSG 访问和 Azure Bastion 否 -
Azure 防火墙
AzureFirewallSubnet
AzureFirewallManagementSubnet		 无 NSG 无 NSG 否 -

此设计通过 NSG 规则或在 Azure 防火墙中默认显式拒绝所有其他流量。

在此体系结构中实现网络分段和安全性时，请遵循以下建议：

  • 在应用程序网关公共 IP 地址上部署 Azure DDoS 防护 计划，以缓解批量攻击。

  • 将 NSG 附加到支持它的每个子网。 应用尽可能严格的规则，而不会中断所需的功能。

  • 向所有受支持的子网应用 强制隧道 ，以便出口防火墙可以检查所有出站流量。 即使在不需要出口的子网上使用强制隧道。 此方法添加了一个深度防御措施，可防止有意或意外滥用子网。

通过策略进行治理

若要与工作负荷的安全基线保持一致，请使用 Azure Policy 和网络策略来确保所有工作负荷资源都满足你的要求。 通过策略实现平台自动化可降低安全配置偏移的风险，并帮助减少手动验证活动。

请考虑实施以下类型的安全策略来加强体系结构：

  • 在 Azure AI 服务和 Key Vault 等服务中禁用基于密钥或其他本地身份验证方法。

  • 需要显式配置网络访问规则、专用终结点和 NSG。

  • 需要加密，例如客户管理的密钥。

  • 限制资源创建，例如限制区域或资源类型。

成本优化

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

此 Azure 定价估算 提供此体系结构的定价示例。 此示例仅包含此体系结构中的组件，因此对其进行自定义以匹配使用情况。 方案中最昂贵的组件是 Azure Cosmos DB、AI 搜索和 DDoS 防护。 其他值得注意的成本包括聊天 UI 计算和应用程序网关。 优化这些资源以降低成本。

Foundry 代理服务

使用标准部署时，必须在自己的 Azure 订阅中预配和管理服务的依赖项。

以下建议说明如何优化这些所需服务的成本：

  • Foundry 代理服务管理 Azure Cosmos DB 上的请求单位（RU）分配。 若要降低长期成本，请为 Azure Cosmos DB 购买预留容量。 使预留与预期的使用持续时间和量保持一致。 请记住，如果工作负荷的使用模式发生重大变化，预留容量需要提前承诺，并且缺乏灵活性。

  • 如果聊天方案不需要文件上传，请在应用程序中排除此功能。 在这种情况下，请应用以下配置更改：

    • 对存储帐户使用本地冗余存储（LRS）层。
    • 使用单个副本配置 AI 搜索，而不是建议的三个副本。

  • 使用 SDK 或 REST API 定期删除未使用的代理及其关联的线程。 过时的代理和线程会继续使用存储，并可以增加 Azure Cosmos DB、存储和 AI 搜索的成本。

  • 对工作负荷不需要的依赖资源禁用功能，例如以下功能：

    • AI 搜索中的语义排名器
    • Azure Cosmos DB 中的网关和多区域写入功能

  • 若要避免跨区域带宽费用，请在 Foundry 代理服务所在的同一 Azure 区域中部署 Azure Cosmos DB、存储和 AI 搜索。

  • 避免将特定于工作负荷的数据并置到 Foundry 代理服务使用的同一 Azure Cosmos DB 或 AI 搜索资源中。 在某些情况下，可以共享这些资源以减少 RU 或搜索单元中未使用的容量，从而降低成本。 只有在对可靠性、安全性和性能权衡进行彻底风险评估后，才考虑资源共享。

代理知识和工具

Foundry 代理服务以不确定的方式运行代理逻辑。 它可能会为每个请求调用任何连接的知识存储、工具或其他代理，即使该资源与用户查询无关。 此行为可能导致对外部 API 或数据源的不必要的调用、增加每个事务的成本，并引入使预算预测复杂化的不可预知的使用模式。

若要控制成本和维护可预测的行为，请应用以下策略：

  • 仅连接可能用于大多数代理调用的知识存储、工具或代理。 避免连接很少需要的资源，或者每次调用会产生高成本的资源，除非这些资源至关重要。

  • 仔细设计和优化系统提示，以指示代理尽量减少不必要的或冗余的外部调用。 系统提示应引导代理仅对每个请求使用最相关的连接。

  • 使用 Azure AI Foundry 遥测来监视代理访问的外部 API、知识存储或工具、访问它们的频率以及关联的成本。 定期查看此遥测数据，以确定意外的使用模式或成本峰值，并根据需要调整系统提示。

  • 请注意，非确定性调用可能会使成本预测变得困难，尤其是在与按流量计费的 API 集成时。 如果需要可预测的成本，请考虑使用确定性代码自行托管业务流程协调程序。

Azure OpenAI 模型

Azure AI Foundry 中的模型部署使用 MaaS 方法。 成本主要取决于使用情况或预配前分配。

若要控制此体系结构中的消耗模型成本，请使用以下方法的组合：

  • 控制客户端。 客户端请求在消耗模型中驱动大多数成本，因此控制代理行为至关重要。

    若要减少不必要的使用，请执行以下作：

    • 批准所有模型使用者。 不要以允许不受限制的访问的方式公开模型。

    • 通过代理逻辑等max_tokensmax_completions强制实施令牌限制约束。 此控件仅在自承载业务流程中可用。 Foundry 代理服务不支持此功能。

    • 优化提示输入和响应长度。 较长的提示会消耗更多令牌，这会增加成本。 缺少足够上下文的提示可降低模型有效性。 创建简明扼要的提示，提供足够的上下文，让模型能够生成有用的响应。 确保优化响应长度的限制。

      此级别的控制仅在自承载业务流程中可用。 Foundry 代理服务不提供足够的配置来支持此功能。

  • 为代理选择正确的模型。 选择满足代理要求的最低成本模型。 除非这些模型至关重要，否则请避免使用更高的成本模型。 例如，参考实现使用 GPT-4o 而不是更昂贵的模型，并实现足够的结果。

  • 监视和管理使用情况。 使用 Microsoft成本管理和 模型遥测来跟踪令牌使用情况、设置预算，以及为异常创建警报。 定期查看使用模式，并根据需要调整配额或客户端访问。 有关详细信息，请参阅 规划和管理 Azure AI Foundry 的成本。

  • 使用正确的部署类型。 对不可预知的工作负荷使用即用即付定价，并在使用稳定且可预测的情况下切换到预配的吞吐量。 建立可靠的基线时，请合并这两个选项。

  • 限制场使用。 若要防止计划外生产成本，请仅将 Azure AI Foundry场的使用限制为预生产环境。

  • 请仔细规划微调和图像生成。 这些功能具有不同的计费模型。 它们按小时或每批计费。 计划使用情况，使其与计费间隔保持一致，避免浪费。

网络安全资源

此体系结构需要 Azure 防火墙作为出口控制点。 若要优化成本，请使用 Azure 防火墙的基本层，除非其余工作负荷组件需要高级功能。 更高的层会增加成本，因此，只需在需要时使用它们。

如果组织使用 Azure 登陆区域，请考虑使用共享防火墙和分布式拒绝服务（DDoS）资源来延迟或降低成本。 具有类似安全性和性能要求的工作负荷可以从共享资源中受益。 确保共享资源不会带来安全或作风险。 此体系结构 部署在 Azure 登陆区域中，使用共享资源。

卓越运营

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

以下卓越运营指南不包括前端应用程序元素，这些元素与 基线高度可用的区域冗余 Web 应用程序体系结构相同。

代理计算

Microsoft完全管理 Azure AI 代理 REST API 和业务流程实现逻辑的无服务器计算平台。 自承载业务流程可以更好地控制运行时特征和容量，但必须直接管理该平台的第 2 天作。 评估方法的约束和职责，以了解为支持业务流程层而必须实现的第 2 天作。

在这两种方法中，必须管理状态存储，例如聊天历史记录和代理配置，以便进行持续性、备份和恢复。

监测

与基本体系结构类似，所有服务的诊断数据配置为发送到工作负荷的 Log Analytics 工作区。 应用服务以外的所有服务捕获所有日志。 在生产环境中，可能不需要捕获所有日志。 例如，聊天 UI 应用程序可能只需要AppServiceHTTPLogs、AppServiceConsoleLogs、AppServiceAppLogs和AppServicePlatformLogsAppServiceAuthenticationLogs。 根据操作需求优化日志流。

评估此体系结构中资源的自定义警报，例如 Azure Monitor 基线警报中的自定义警报。 请考虑以下警报：

根据模型部署监视令牌的使用情况。 在此体系结构中，Azure AI Foundry 通过与 Application Insights 的集成跟踪 令牌使用情况 。

跳转框和生成代理 VM 位于高度特权的位置，为这些 VM 提供网络视线，以观察体系结构中所有组件的数据平面。 确保这些 VM 发出足够的日志，以了解它们何时使用、谁使用它们以及它们执行的作。

代理版本控制与生命周期

除非专门将应用程序设计为在运行时动态创建和删除代理，否则将每个代理视为聊天工作负荷中的独立可部署单元。 这些代理的生命周期管理要求与工作负荷中的其他微服务类似。

若要防止服务中断，请通过实现以下方法确保安全且受控的代理部署：

  • 将代理定义为代码。 始终在源代码管理中存储代理定义、连接、系统提示和配置参数。 这种做法可确保可追溯性和可重现性。 避免通过 Azure AI Foundry 门户进行未跟踪的更改。

  • 自动执行代理部署。 使用工作负荷的持续集成和持续部署（CI/CD）管道。 使用 Azure AI 代理 SDK 从联网生成代理生成、测试和部署代理更改。

    首选可以独立部署的代理管道进行小型增量更改。 但是，确保在需要协调更新时，管道可以灵活地将它们与应用程序代码一起部署。 若要支持此方法，请将聊天 UI 代码和聊天代理松散耦合，以便更改一个组件不需要同时更改另一个组件。

  • 在生产之前进行测试。 在预生产环境中验证代理行为、提示和连接。 使用自动化和手动测试的组合来捕获代理行为的回归、安全问题和意外更改。

    Foundry 代理服务中定义的代理行为不确定，因此必须确定如何衡量和维护所需的质量级别。 创建并运行测试套件，用于检查对现实用户问题和方案的理想响应。

  • 版本和跟踪代理。 将清除版本标识符分配给每个代理。 维护哪些代理版本处于活动状态的记录及其依赖项，例如模型、数据源和工具。 首选将新的代理版本与现有代理版本一起部署，以实现用户或会话的渐进式推出、回滚和控制迁移。

  • 规划故障回复。 Azure AI Foundry 不提供对代理蓝绿或 Canary 部署的内置支持。 如果需要这些部署模式，在代理 API 前面实现路由层（例如 API 网关或自定义路由器）。 此路由层允许在代理版本之间以增量方式转移流量，监视影响，并在准备就绪时执行完全切换。

  • 协调代理删除。 删除代理时，请与应用程序的状态管理和用户体验要求协调该过程。 适当处理活动聊天会话。 根据工作负荷的功能要求，你可以迁移会话、将用户固定到旧代理版本，或要求用户启动新会话。

性能效率

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

本部分介绍 AI 搜索、模型部署和 Azure AI Foundry 的性能效率。

在 Foundry 代理服务中，不会控制发送到索引的特定查询，因为代理是无代码的。 若要优化性能，请专注于可在索引中控制的内容。 观察代理通常如何查询索引，并应用指南来 分析和优化 AI 搜索中的性能。

如果仅索引服务器优化无法解决所有瓶颈，请考虑以下选项：

  • 将与 AI 搜索的直接连接替换为你拥有的 API 的连接。 此 API 可以实现针对代理的检索模式优化的代码。

  • 重新设计业务流程层以使用 自承载替代方法 ，以便可以在自己的业务流程协调程序代码中定义和优化查询。

模型部署中的性能效率

  • 确定应用程序是否需要 预配的吞吐量 ，也可以使用共享（消耗）模型。 预配的吞吐量提供预留容量和可预测的延迟，这对于具有严格服务级别目标的生产工作负荷非常重要。 消耗模型提供最努力的服务，并可能受到干扰邻居的影响。

  • 监视 预配管理的使用情况 ，以避免过度预配或预配不足。

  • 选择满足推理延迟要求的聊天模型。

  • 在代理所在的同一数据区域中部署模型，以最大程度地减少网络延迟。

Azure AI 代理性能

Azure AI 代理在不支持自定义性能优化的无服务器计算后端上运行。 但是，仍可以通过代理设计提高性能：

  • 最大程度地减少连接到聊天代理的知识存储和工具的数量。 每个额外的连接可能会增加代理调用的总运行时，因为代理可能会为每个请求调用所有配置的资源。

  • 使用 Azure Monitor 和 Application Insights 跟踪代理调用时间、工具和知识存储延迟以及错误率。 定期查看此遥测数据，以确定知识或工具连接速度缓慢。

  • 设计系统提示，引导代理高效使用连接。 例如，指示代理仅在需要时才查询外部知识存储，或避免冗余工具调用。

  • 监视在高峰使用期间可能会影响性能的服务限制或配额。 监视限制指示器（如 HTTP 429 或 503 响应），即使无服务器计算自动缩放也是如此。

部署此方案

若要部署并运行此参考实现，请按照 Foundry 代理服务聊天基线参考实现中的部署指南进行作。

供稿人

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

主要作者：

其他参与者：

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

后续步骤