你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
Azure 上 AI 工作负载的应用程序设计
创建具有 AI 函数的应用程序时，需要考虑许多选择。 独特的功能和非功能要求（例如，用例是传统的机器学习、生成性、确定性或 AI 类型的组合）可帮助你缩小有关设计的高级决策范围。 当你从高级设计区域移动到较低级别的设计区域时，你将考虑这些选择。
如 入门 一文中所述，无论是构建自己的模型还是使用预生成模型，都是要做出的第一个重要决策之一。 使用预生成模型时，请考虑以下几点：
目录源。 浏览 Hugging Face 模型中心、TensorFlow 中心以及 Azure AI Foundry 门户的模型目录等存储库，以查找预训练模型。 这些平台为各种任务提供了广泛的模型目录。
许可。 确保模型的许可条款符合你的安全、合规性和应用程序目标，尤其是在你计划分发应用程序或将其与其他服务集成时。
关键组件。 查看模型的体系结构、训练数据、性能和许可，以确定它是否针对任务或域进行了微调。
有关选择托管平台的指导，请参阅 模型托管和推断平台的注意事项。
本文介绍在做出有关技术和方法决策时要考虑的常见设计领域和因素。
建议
下表总结了本文中提供的建议。
| 建议 | 说明 |
|---|---|
| 确定现成的解决方案的优先级。 | 只要可行，请使用平台即服务（PaaS）解决方案来处理工作负荷功能。 尽可能使用预生成和预先训练的模型来最大程度地减少工作负荷和运营团队的操作和开发负担。 |
| 从客户端中抽象函数和功能。 | 通过设计后端服务来处理诸如速率限制和故障转移操作等跨领域问题，从而使客户端尽可能精简。 |
| 阻止访问数据存储。 | AI 系统中的代码不应直接访问数据存储。 通过 API 层路由所有数据请求。 应专门为所需任务生成 API。 |
| 隔离模型。 | 与数据存储一样，使用 API 层充当向模型发出的请求的网关。 某些 PaaS 解决方案（如 Azure OpenAI 服务和Azure 机器学习使用此 SDK）。 许多工具（如 prompt flow）都具备将 API 部署到服务中的原生支持。 |
| 设计可独立部署的组件。 | AI 模型、数据管道、前端组件和微服务（如数据预处理、特征提取和推理）应独立部署，以优化工作负荷的灵活性、可伸缩性和可操作性。 |
容器化组件
为了确保独立可部署的组件完全独立且能够简化部署，请考虑容器化作为设计策略的一部分。 应容器化以下组件：
微服务。 应容器化处理应用程序的特定功能（例如数据处理、模型推理和用户身份验证）的各个微服务。 此方法可实现独立的部署和缩放，并有助于更高效的更新和维护。
AI 模型。 容器化 AI 模型，以确保所有依赖项、库和配置捆绑在一起。 此方法将模型环境与主机系统隔离，以防止版本冲突，并帮助确保不同部署环境中的一致行为。
数据处理管道。 任何在模型推理之前或之后进行的数据处理任务，例如数据清理、数据转换和特征提取，都应该被容器化。 此方法增强了可重现性，并简化了依赖项的管理。
基础结构服务。 提供基础结构支持的服务（如数据库和缓存层）也可以受益于容器化。 容器化这些服务有助于保持版本一致性，并有助于更轻松地缩放和管理这些组件。
将 AI 组件与其他工作负荷组件并置
有几个很好的理由将 AI 组件与其他工作负荷组件并置，但这样做有利弊。 您可能会因为以下原因选择将组件放在一起：
延迟敏感度。 当低延迟很重要时，将 AI 组件与其他服务（如 API 托管）并置。 例如，如果需要实时推理来增强用户体验，将 AI 模型放置在靠近 API 的地方可以最大程度地减少检索结果所需的时间。
数据邻近度。 当 AI 模型需要频繁访问特定数据集（例如搜索索引）时，并置这些组件可以提高性能并减少数据传输开销，从而加快处理和推理。
资源利用率。 如果特定组件具有互补的资源需求，例如 CPU 和内存，则并置这些组件可以优化资源使用情况。 例如，需要大量计算的模型可以与同时需求较低的服务共享资源。
权衡利弊。在决定是否归置组件时需要考虑权衡利弊。 你可能会失去独立部署或缩放组件的能力。 增加事件的潜在影响范围也可能会增加故障风险。
评估生成 AI 解决方案中的业务流程协调程序的使用
业务流程协调程序通过协调 AI 解决方案中不同组件之间的通信来管理工作流，否则在复杂工作负荷中将难以管理。 如果工作负荷具有以下任何特征，建议将业务流程协调程序构建到设计中：
复杂工作流。 工作流涉及多个步骤，例如预处理、模型链或后处理。
条件逻辑。 需要根据模型输出动态做出决策，例如将结果路由到不同的模型。
缩放和资源管理。 需要使用基于需求的模型缩放来管理大容量应用程序的资源分配。
状态管理。 你需要管理用户交互的状态和内存。
数据检索。 需要能够从索引中检索扩充数据。
使用多个模型的注意事项
当工作负荷使用多个模型时，业务流程协调程序至关重要。 业务流程协调程序根据用例将数据和请求路由到相应的模型。 规划模型之间的数据流，确保一个模型的输出可用作另一个模型的输入。 规划可能涉及数据转换或扩充过程。
业务流程和代理
对于生成式 AI 工作负载，请考虑采用基于代理（有时称为 代理）的设计方法，以向业务流程添加可扩展性。 代理提供上下文绑定功能。 它们与微服务共享许多特征，并与业务流程协调程序一起执行任务。 业务流程协调程序可以将任务发布到代理池，或者代理可以向业务流程协调程序注册功能。 这两种方法都允许协调器动态确定如何在代理之间拆分和路由查询。
当拥有一个具有多个不断演变的功能的通用 UI 界面时，强调自主性的方法是理想选择，因为这些功能可以被插入到体验中，以便随着时间的推移向流程中添加更多技能和基础数据。
对于具有许多代理的复杂工作负荷，允许代理动态协作，而不是使用业务流程协调程序来分解任务并分配它们，这更高效。
业务流程协调程序和代理之间的通信应遵循主题队列模式，其中代理是主题的订阅者，业务流程协调程序通过队列发送任务。
使用代理方法最适合业务流程模式，而不是 编舞模式。
有关详细信息，请参阅 业务流程平台的注意事项。
评估 API 网关的使用
Azure API 管理等 API 网关 抽象函数与 API 分离，从而将请求服务和 API 之间的依赖关系分离。 API 网关为 AI 工作负载提供以下优势：
多个微服务。 需要强制实施一致的策略（例如速率限制和身份验证）时，网关可帮助你管理多个 AI 模型终结点。
流量管理。 网关通过管理请求、缓存响应和分发负载来帮助高效管理高流量应用。
安全性。 网关为网关后面的 API 提供集中式访问控制、日志记录和威胁防护。
使用 AI 应用程序设计模式
在 AI 应用程序中，已经建立了几个常见的设计模式。 可以使用它们来简化设计和实现。 这些设计模式包括：
模型集成。 此设计模式涉及合并来自多个模型的预测，通过缓解各个模型的弱点来提高准确性和稳定性。
微服务体系结构。 将组件分离为可独立部署的服务可以提高可伸缩性和可维护性。 它使团队能够同时处理应用程序的不同部分。
事件驱动的体系结构。 使用事件触发操作能够实现解耦组件，并通过实时处理使系统更具响应性且适应数据变化。
RAG 模式和分块策略
Retrieval-Augmented 生成（RAG）模式将生成模型与检索系统相结合，使模型能够访问外部知识源以提高上下文和准确性。 有关此模式的深入指导，请参阅 设计并开发 RAG 解决方案 系列文章。 有两种 RAG 方法：
实时。 此方法在请求时动态检索相关信息，以确保始终使用最新数据。 它适用于需要实时上下文的方案，但它可能会引入延迟。
预先计算（缓存）。 此方法涉及缓存检索结果，以便通过提供预计算数据来减少响应时间。 它适用于可存储一致的数据的高需求方案。 数据可能不会反映最新的信息，这可能会导致相关性问题。
使用 RAG 模式时，定义完善的分块策略对于优化工作负荷的性能效率至关重要。 从设计和开发 RAG 解决方案系列中提供的指南开始。 下面是一些要考虑的其他建议：
实现动态分块策略，根据数据类型、查询复杂性和用户要求调整区块大小。 这样做可以提高检索效率和上下文保留。
合并反馈循环，以基于性能数据优化分块策略。
通过维护链接到地面源的元数据和唯一标识符来保留区块的数据世系。 清晰的数据血统文档有助于确保用户了解数据来源、其转换以及它对输出的贡献。
何时使用设计模式
当用例满足所描述的条件时，请考虑使用这些设计模式：
复杂工作流。 在多个 AI 模型之间具有复杂的工作流或交互时，RAG 或微服务等模式有助于管理复杂性并确保组件之间的清晰通信。
可伸缩性要求。 如果应用程序的需求波动，微服务等模式使各个组件能够独立缩放以适应不同的负载，而不会影响整个系统性能。
数据驱动型应用程序。 如果应用程序需要广泛的数据处理，事件驱动的体系结构可以提供实时响应性和高效的数据处理。
注意
较小的应用程序或 POC 通常不会受益于这些设计模式。 应为简单起见设计这些应用程序。 同样，如果你有资源（预算、时间或人头）约束，则使用一个简单的设计，以后可以重构是比采用复杂设计模式更好的方法。
选择正确的框架和库
框架和库的选择与应用程序设计紧密相连。 它们会影响性能、可伸缩性和可维护性。 但是，设计要求可能会限制框架选择。 例如，使用语义内核 SDK 通常鼓励基于微服务的设计，其中每个代理或函数封装在其自己的服务中。 选择框架和库时，请考虑以下因素：
应用程序要求。 应用程序的要求（如实时处理或批处理）可能会限制框架的选择。 例如，如果应用程序需要低延迟，则可能需要使用具有异步功能的框架。
集成需求。 设计可能需要与其他系统或服务进行特定的集成。 如果框架不支持必要的协议或数据格式，则可能需要重新考虑设计或选择其他框架。
团队专业知识。 开发团队的技能集可以限制框架选择。 依赖于不太熟悉框架的设计可能会导致开发时间和复杂性增加，因此你可能想要使用更熟悉的工具。
设计标识、授权和访问策略
一般来说，你应该采用像你平常在设计应用程序时那样的方式来处理标识、授权和访问。 应使用标识提供者（如 Microsoft Entra ID）来管理这些区域。 但是，许多 AI 应用程序具有独特的挑战，需要特别考虑。 有时，通过系统保持访问控制列表（ACL）具有挑战性甚至不可能，除非进行新的开发。
请参阅设计安全多租户 RAG 推理解决方案的指南，了解如何向文档和区块添加安全修整元数据。 此修整可以基于安全组或类似的组织构造。
考虑非功能要求
由于 AI 技术固有的因素，工作负荷可能具有非功能要求，这会带来挑战。 以下是一些常见的非功能要求及其挑战：
模型推理的延迟 / 超时。 AI 应用程序通常需要实时或近乎实时的响应。 设计为低延迟至关重要。 它涉及优化模型体系结构、数据处理管道和硬件资源。 实施缓存策略并确保有效的模型加载对于避免超时并提供及时响应至关重要。
令牌或请求吞吐量限制。 许多 AI 服务对令牌数或请求吞吐量施加限制，尤其是基于云的模型。 针对这些限制进行设计需要仔细管理输入大小、在必要时批处理请求，并可能实施速率限制或排队机制来管理用户期望并防止服务中断。
成本和退款应用场景。 设计成本透明度涉及实现使用情况跟踪和报告功能，以方便退款模型。 这些功能使组织能够跨部门准确分配成本。 退款管理通常由 API 网关处理，例如 Azure API 管理。