代理开发生命周期

本指南提供了一个起点，用于了解生成 AI 应用程序或代理的完整生命周期。 在整个本指南中，“代理”是 AI 支持的系统的一个伞式术语，包括简单的 LLM 调用、AI 函数和基于代理的实现。

开发生命周期概述

  1. 了解用例、范围和成功指标
  2. 生成初始代理
  3. 迭代优化代理质量
  4. 在生产之前与利益干系人保持一致
  5. 发布到生产环境并持续监视质量

1.了解用例、范围和成功指标

在开始构建任何东西之前，先明确这个智能体要做什么。 与利益相关者保持一致，包括将签署生产部署的人员。

  • 代理将处理哪些类型的输入（“域”或“范围”）？ 哪些用户将提交输入？
  • 代理应如何理想地响应常见输入？ 应使用哪些信息或上下文？
  • 哪些标准定义了良好或错误的响应：音调、准确性、完整性、响应长度、安全、引文或其他要求？
  • 生产中有哪些系统要求和约束：成本、延迟和可伸缩性？
  • 什么是潜在的故障模式，代理应如何处理它们：错误的用户输入、信息不足、指示错误答案的用户反馈或其他问题？

选择最简单的可行方法。 许多用例不需要复杂的代理系统或多代理系统。 在生成之前，请评估问题在复杂性连续性上的位置。 简单的确定性逻辑或批处理 AI 函数是否足够？ 如果需要动态工具调用、推理或协调，请考虑使用工具调用代理或多代理系统。 有关更深入的指导，请参阅 代理系统设计模式。

通过此基础，你可以：

  1. 确定代理所需的数据源和工具
  2. 编写反映预期行为的初始说明或提示
  3. 确定可以提供代表性示例和早期反馈的域专家或测试人员
  4. 创建对评估条件进行编码并加速迭代的自动法官

在这个阶段，你不需要完美的清晰度，你的理解将在迭代时得到改善。 但更强的早期协调，特别是在质量测量标准以及“生产就绪”定义这两方面，能显著加快后期的质量改进和核准过程。

2.生成初始代理

在用例和目标定义明确后，即可为代理建立原型。 Databricks 提供基于 UI 的引导路由和完全自定义的基于代码的路由，用于生成代理。

2.1. 准备数据和工具

代理通常使用数据和工具提供上下文和功能。 有关在 Databricks 上使用数据和工具的概述，请参阅 “将代理连接到工具 ”。

在创建新数据之前搜索现有数据和工具：

  • 浏览 Unity 目录 或 工作区搜索 中的可用数据，了解已存在的受管理资产。 这有助于了解创建新资产之前可用的上下文和功能。
  • 在 AI Playground 中，可以查看和选择已可用于代理的工具，例如 AI 搜索索引、MCP 服务器或 UC 函数。

根据需要创建和管理新资产：

所有这些数据资产和工具都在 Unity 目录中进行治理和版本控制，使它们在代理和应用程序中可发现和可重用。

2.2. 构建初始智能体

在生成自定义代理之前，请评估声明性 知识助手 代理、 AI 函数或现有 Databricks 解决方案加速器 是否已与用例匹配。 对于常见模式，这些引导式方法可以显著减少设置、提高默认质量和加快生产速度。

如果仍需要自定义代理，则新生成器应以最快的方式开始试验。 使用 AI Playground 在不 编写代码的情况下创建代理的原型。 借助 AI Playground，可以尝试不同的模型、执行提示工程和测试工具，以便快速了解数据质量、代理行为以及方法的潜力。 然后，可以将代理导出为代码，以便进一步进行自定义和迭代。

如果已有代理代码，可以将 现有代码引入 Databricks 并将其部署为 Databricks 应用。

在构建智能体时，提前规划评估和生成：

  • 使用 MLflow 跟踪 为代理进行仪表化，以记录和分析代理行为。
    • 在此阶段，请专注于功能正确性：确保代理以端到端方式运行，并可以访问所需的数据和工具。
    • Vibe 检查早期问题，例如错误的工具选择、缺少上下文或幻觉。
    • 稍后，这些记录将用于评估代理质量。
  • 在实现过程中，请考虑 为生产应用程序使用正确的身份验证方法。

3. 循环访问代理质量

工作原型存在后，下一阶段是衡量、理解和提高质量的紧密循环。 Databricks 将 MLflow 评估 置于此循环的中心，由 MLflow 跟踪、评估数据集和 LLM 评委支持。

自动评分器和 LLM 评委提供规模和一致性，但 人类反馈 对于验证现实世界的有用性和理解微妙的失败至关重要。 人工反馈还指导 LLM 法官的开发和校准。 随着代理的成熟，人工反馈通常进入三个阶段：

  1. 早期开发人员和利益相关者验证
  2. 更广泛的领域专家评审
  3. 最终用户反馈

3.1. 验证早期行为

开发人员和一小组利益干系人或领域专家可以提供快速的早期反馈。 在进行扩展测试和评估之前，确保代理在显而易见的情况下做出正确的决定。

在原型开发阶段，开发人员常常通过手动查询代理完成非正式的“状态检查”，以确认代理能够端到端地运行并按照预期表现。 借助 MLflow 跟踪 UI，开发人员可以直接将反馈或期望附加到 跟踪，以标记质量问题、标记成功的示例，以及记录未来评估和迭代的笔记。

部署内部原型后， “审阅应用聊天”UI 提供了一个简单的 UI 来收集反馈。 与一小部分开发人员或领域专家共享原型的聊天 UI，他们可以提出合理和有问题的查询。

MLflow 跟踪记录交互和反馈，以生成结果的初始数据集。 使用 MLflow UI 或代码分析跟踪 ，以了解代理的性能和行为。 如果结果不好或意外，请使用跟踪进行调试：

  • 分析代理中的质量问题，例如工具滥用、幻觉或缺少上下文。 应用修复，例如提示调优、工具使用或数据。 请参阅 3.4。修复问题并重新验证改进。
  • 在迭代过程中，可以使用跟踪数据集作为代表性的用户输入来为您的新原型生成跟踪记录。
  • 重复此循环：运行、检查、修复和重新运行，直到代理按预期处理所有或大多数代表性输入。
  • 以后的迭代可能会发现和解决更多问题。 质量改进是迭代的，不限于这一早期阶段。

在此步骤之后，可以确信原型在常见情况下的行为合理，并在投入更广泛的测试之前达到合理的质量水平。

3.2. 扩展测试和反馈

在原型在简单情况下工作后，通过扩大 beta 测试人员集并收集更多自定义反馈来扩展质量评估。 此阶段揭示了意外主题、误解的查询、工具和检索差距或新兴使用模式等盲点。 它还扩展了评估数据集。

  • 向更广泛的利益干系人和领域专家或 beta 版最终用户推出应用程序。 随着智能体暴露于更广泛的使用模式，纳入他们的反馈。
  • 使用 “审阅应用”标记会话 和自定义架构来捕获更详细的反馈和期望，以获取专家反馈。
  • 通过同步人工反馈和标记的跟踪来生成 评估数据集 ，并准备在下一步进行系统评估和监视。
  • 若要进一步扩充评估数据集，请考虑 生成综合评估集。

3.3. 系统地进行质量评估和故障排除

随着评估数据集变得越来越大且更加多样化，你需要结构化和更自动化的方法来检测问题、显示最重要的故障并了解根本原因。

在实践中，可能会将数据划分为两种类型的评估数据集：

  • 回归测试：具有高质量 AI 响应的数据有助于定义预期行为。 使用这些数据集来验证新版本的代理是否在一组广泛且多样化的预期方案中继续运行良好。
  • 以问题为中心的调试：具有低质量 AI 响应的数据可能包括各种不需要的行为。 隔离表现出相同类型低质量行为的跟踪组，以便了解根本原因并迭代有针对性的修复。

下面的工具有助于生成和分析这两种类型的评估数据集。

运行回归测试

  • 通过选择具有高质量 AI 响应或人类期望的代表性数据子集来生成回归测试。
  • 使用 内置或自定义 LLM 评委和评分器定义评估标准。 自动化评估既可以单独使用 LLM 来评估响应质量，也可以将响应与参考标准响应或期望结果进行比较。
  • 对新版本的代理运行评估，以确保更新不会降低以前良好的行为。

识别低质量响应的类型

提高自动检测的准确性

虽然可以主要使用人工反馈开始构建评估数据集，但可以使用自动化检测来扩大评估。 在迭代过程中，投资于针对你的应用程序和域定制的 LLM 评判员或基于代码的评分器。

有效解决根本原因问题

确定失败后，需要确定它发生的原因。

  • 使用 MLflow 跟踪 手动检查代理推理的每个步骤：
    • 选择了哪些工具
    • 如何使用工具输入和输出
    • 检索是否返回了相关上下文
    • 模型响应如何影响下游决策
  • 应用 MLflow AI 见解 或 代理评判 来分析踪迹并指出可能的原因，如错误的基础理解、错误的提示词结构或不正确的工具参数。
  • 比较 MLflow 评估 UI 中的版本，以查看问题在迭代之间是回归还是持续存在。

此步骤的理想结果是对失败的原因、失败的原因以及如何修复它进行结构化理解。 自动化和特定于应用程序的评判员允许你在智能体变得更强大、测试集更复杂时自信地迭代。

3.4. 修复问题并重新验证改进

正如问题特定于应用程序一样，必须根据应用程序定制修补程序。 常见修复的示例包括：

  • 提示优化：手动优化代理的说明，或使用 数据驱动的提示优化。 对于更广泛的代理优化（例如优化多步骤推理或工具使用），请使用 DSPy 优化。
  • 工具和数据：当追踪显示事实缺失或基础不稳时，改进工具或检索流程。
  • 路由：当跟踪显示调用了错误的工具或子代理时，请改进工具或代理元数据、提示或路由模型。
  • 护栏：响应违反安全规则或泄漏信息时，请在代理中使用 AI 网关防护栏 或自定义防护措施。
  • 回退：使用备用 API 终结点或回退响应等回退机制正常处理极端情况、缺失数据或 API 调用失败。

在迭代修复方案时，请使用 提示注册表 记录各个版本，以便更轻松地进行比较和回归测试。

对提示、检索、工具、数据或智能体其他部分的每个修复都应按照发现它的方式进行验证。 在同一评估数据集上重新运行新的代理版本，以确认问题已修复，并且未引入任何回归。

4.在生产之前与利益干系人保持一致

在将代理发布到实际环境中之前，团队需要对其当前功能、限制和衡量质量有共同的理解。 达到这一点通常需要 在步骤 3 中多次迭代和质量改进。 在此阶段，将技术信号（如评估指标、系统指标和示例跟踪）转换为业务上下文，最终确定代理是否真正“就绪”。

  • 将评估结果转换为明确的业务信号：以相关方可以采取行动的语言总结评估结果的准确性、稳定性、安全性和已知限制。
  • 确认满足标准化质量检查：确保候选版本的所需评估指标、回归检查和数据集覆盖率阈值通过。
  • 验证操作准备情况并获取登录：查看监视设置、防护措施和推出计划。 在生产之前记录风险和验收标准。

5. 发布到生产环境并持续监控质量

达到生产阶段是一个重要的里程碑！ 这意味着智能体已准备好面向真实用户和实际影响。 同时，生产也是新周期的开始。 代理上线后，它会进入持续监视和改进，因为实际使用情况将呈现新行为、边缘事例和问题。

  • 收集 生产环境中最终用户的反馈。 将用户反馈链接到特定跟踪，以便可以与模型行为一起进行分析。 你可以通过将反馈记录为附加到原始跟踪的评估来实现这一点。
  • 利用 AI 网关 进行防护、路由和一致的日志记录。 确保可以根据实际流量评估每个新的代理版本，而不会发生操作摩擦。
  • 通过对采样的生产跟踪运行评估来监控实时流量上的质量。 确认新版本的性能至少与以前的版本一样好，并在用户提交新类型查询时寻找新问题。 持续监视使代理在发展过程中可靠、安全且符合业务需求。 MLflow 提供监视仪表板，但由于 跟踪可以存储在 Unity 目录中，因此你可以自定义仪表板和警报：
  • 根据生产见解采取行动
    • 对于高风险用例，请将监控与自动或受限回滚机制链接，以解决关键问题。
    • 在下一次迭代中运用您的生产洞察力。 将实际故障转换为新的评估数据，并返回到 评估和调试循环 ，以生成下一个更好的代理版本。

其他资源

  • Last updated on