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