生成式 AI 应用开发者工作流

开发可靠的生成 AI 应用程序（gen AI 应用）需要经过深思熟虑的规划、快速开发反馈评估循环和可缩放的生产基础结构。 此工作流概述了从初始概念证明（POC）到生产部署的建议步骤序列。

0. 先决条件

• 收集要求以验证第一代 AI 是否适合并识别约束。
• 设计解决方案体系结构。 请参阅 代理系统设计模式

1. 生成

• 准备数据源并创建必要的工具。
• 生成和验证初始原型（POC）。
• 部署到预生产环境。

2. 评估并迭代

• 收集用户反馈并衡量质量
• 通过基于评估优化代理逻辑和工具来修复质量问题。
• 采纳行业专家 (SME) 意见，不断提高代理系统的质量。

3. 生产

• 将 GEN AI 应用部署到生产环境。
• 监视性能和质量。
• 根据实际使用情况维护和改进。

此工作流应该是迭代的：在每个部署或评估周期之后，返回到前面的步骤来优化数据管道或更新代理逻辑。 例如，生产监视可能会显示新的要求，从而触发代理设计的更新和另一轮评估。 通过系统地遵循这些步骤并利用 Databricks MLflow 跟踪、代理框架和代理评估功能，可以构建能够可靠地满足用户需求、尊重安全性和符合性要求的高质量 GEN AI 应用，并随着时间的推移继续改进。

0. 先决条件

在开始开发生成式 AI 应用程序之前，一定要花时间正确完成以下事项：收集要求和设计解决方案。

收集要求 包括以下步骤：

• 验证 Gen AI 是否符合用例。
• 定义用户体验。
• 限定数据源的范围。
• 设置性能约束。
• 确定安全约束条件。

解决方案设计 包括：

• 规划数据管道。
• 确定必要的工具。
• 概述整个系统体系结构。

通过设置此基础，可为后续生成、评估和生产阶段设置明确的方向。

收集需求

定义清晰全面的用例要求是开发成功的第一代 AI 应用的关键第一步。 这些要求满足以下目的：

• 它们有助于确定 Gen AI 方法是否适合你的用例。
• 它们指导解决方案设计、实现和评估决策。

在开始时投入时间收集详细要求可以防止开发过程中出现重大挑战，并确保生成的解决方案满足最终用户和利益干系人的需求。 定义完善的要求为应用程序的生命周期后续阶段提供了基础。

用例是否适合生成式 AI？

在提交第一代 AI 解决方案之前，请考虑其固有优势是否符合你的要求。 生成式 AI 解决方案适合的一些示例包括：

• 内容生成： 该任务需要生成无法通过静态模板或简单的基于规则的逻辑实现的新内容或创造性内容。
• 动态查询处理： 用户查询是开放或复杂且需求灵活的上下文感知响应。
• 信息合成： 用例受益于组合或汇总各种信息来源以生成一致的输出。
• 代理系统：应用程序不仅需要生成文本来响应提示。 它可能需要能够：
  • 规划和决策： 制定多步骤策略以实现特定目标。
  • 执行作： 触发外部进程或调用各种工具来执行任务（例如，检索数据、进行 API 调用、运行 SQL 查询、执行代码）。
  • 维护状态： 跟踪跨多个交互的对话历史记录或任务上下文，以实现连续性。
  • 生成自适应输出： 根据以前的动作、更新的信息或改变的条件生成响应。

相反，在以下情况下，gen AI 方法可能并不理想：

• 该任务具有高度确定性，可以使用预定义的模板或基于规则的系统有效地解决。
• 整个信息的集合已经处于静态状态，或者适合包含在一个简单、封闭的框架内。
• 需要超低延迟（毫秒级）响应，并且无法承受生成处理带来的开销。
• 简单的模板化响应足以满足预期用例。

用户体验

定义用户如何与 gen AI 应用交互以及预期响应类型。

• 🟢 [P0] 典型请求： 典型用户请求的外观是什么？ 从利益干系人收集示例。
• 🟢 [P0] 预期响应： 系统应生成哪些类型的响应（例如，简短答案、长格式解释、创意叙述）？
• 🟡 [P1] 交互形式： 用户如何与应用程序交互（例如聊天界面、搜索栏、语音助理）？
• 🟡 [P1] 音调、风格、结构： 生成的输出应采用什么语气、风格和结构（正式、对话、技术、项目符号或连续散文）？
• 🟡 [P1]错误处理： 应用程序如何处理不明确、不完整或非目标查询？ 它应该提供反馈或请求澄清吗？
• ⚪ [P2] 格式要求： 输出是否有任何特定的格式或演示准则（包括元数据或补充信息）？

数据

确定将在 Gen AI 应用中使用的数据的性质、源和质量。

• 🟢 [P0] 数据源： 哪些数据源可用？
  • 对于每个源，请确定：
    • 数据是结构化还是非结构化数据？
    • 源格式（例如 PDF、HTML、JSON、XML）是什么？
    • 数据驻留在何处？
    • 有多少数据可用？
    • 应如何访问数据？
• 🟡 [P1] 数据更新： 数据更新的频率如何？ 有哪些机制可用于处理更新？
• 🟡 [P1] 数据质量： 是否存在已知质量问题或不一致问题？
  • 考虑是否需要对数据源进行任何质量监视。

请考虑创建清单表来合并此信息，例如：

性能约束

了解生成式 AI 应用程序的性能和资源要求。

延迟

• 🟢 [P0] 时间到第一个标记： 在传递第一个输出令牌之前，可接受的最大延迟是多少？
  • 注意： 通常使用 p50（中值）和 p95（第 95 百分位）来测量延迟，以捕获平均和最差的性能。
• 🟢 [P0] 完成时间： 用户可接受的（完成时间）响应时间是什么？
• 🟢 [P0] 流式处理延迟： 如果响应已流式传输，是否可以接受更高的总体延迟？

可伸缩性

• 🟡 [P1]并发用户和请求： 系统应支持多少同时用户或请求？
  • 注意：可伸缩性通常以 QPS（每秒查询数）或 QPM（每分钟查询数）来衡量。
• 🟡 [P1] 使用模式： 使用情况预期流量模式、峰值负载或基于时间的峰值是什么？

成本约束

• 🟢 [P0] 推理成本限制： 推理计算资源的成本约束或预算限制是什么？

评估

确定如何随着时间推移评估和改进生成式人工智能应用。

• 🟢 [P0] 业务 KPI：应用程序应影响哪些业务目标或 KPI？ 定义基线值和目标。
• 🟢 [P0] 利益干系人反馈：谁将提供有关应用程序性能和输出的初始和持续反馈？ 确定特定的用户组或域专家。
• 🟢 [P0] 测量质量：将使用哪些指标（例如准确性、相关性、安全性、人工分数）来评估生成的输出的质量？
  • 在开发期间如何计算这些指标（例如，针对综合数据、手动策划的数据集）？
  • 如何在生产环境中测量质量（例如，记录和分析对真实用户查询的响应）？
  • 你对错误的总体容忍度是多少？ （例如，接受一定百分比的次要事实不准确，或者要求关键用例近 100% 正确性。）
  • 目的是从实际用户查询、综合数据或两者的组合中构建评估集。 随着系统的发展，此设置提供了一种评估性能的一致方法。
• 🟡 [P1] 反馈循环：如何收集用户反馈（例如，向上/向下大拇指、调查表单）以及用于推动迭代改进？
  • 规划反馈的审查和合并频率。

安全

确定任何安全和隐私注意事项。

• 🟢 [P0] 数据敏感度： 是否存在需要特殊处理的敏感数据元素或机密数据元素？
• 🟡 [P1] 访问控制： 是否需要实现访问控制来限制某些数据或功能？
• 🟡 [P1] 威胁评估和缓解措施： 应用程序是否需要防范常见的 GEN AI 威胁，例如提示注入或恶意用户输入？

部署

了解如何集成、部署、监视和维护 Gen AI 解决方案。

• 🟡 [P1] 集成： Gen AI 解决方案应如何与现有系统和工作流集成？
  • 确定集成点（例如 Slack、CRM、BI 工具）和所需的数据连接器。
  • 确定请求和响应在 GEN AI 应用和下游系统（例如 REST API、Webhook）之间流动的方式。
• 🟡 [P1] 部署： 部署、缩放和版本控制应用程序的要求是什么？ 本文介绍如何使用 MLflow、Unity 目录、 代理框架、 代理评估和模型服务在 Databricks 上处理端到端生命周期。
• 🟡 [P1] 生产监控和可观测性： 应用程序进入生产环境后，如何监控该应用程序？
  • 日志记录和跟踪：捕获完整执行跟踪。
  • 质量指标：持续评估实时流量的关键指标（如正确性、延迟、相关性）。
  • 警报和仪表板：为关键问题设置警报。
  • 反馈循环：将用户的正面或负面反馈纳入生产过程，以提前捕捉问题并推动迭代改进。

示例：

例如，请考虑这些注意事项和要求如何适用于 Databricks 客户支持团队使用的假设代理 RAG 应用程序：

解决方案设计

有关其他设计注意事项，请参阅 代理系统设计模式。

数据源和工具

设计第一代 AI 应用时，必须识别和映射驱动解决方案所需的各种数据源和工具。 这可能涉及结构化数据集、非结构化数据处理管道或查询外部 API。 下面是在 Gen AI 应用中合并不同数据源或工具的建议方法：

结构化数据

结构化数据通常驻留在定义完善的表格格式（例如 Delta 表或 CSV 文件）中，非常适合预先确定查询或需要基于用户输入动态生成的任务。 有关将结构化数据添加到 Gen AI 应用的建议，请参阅结构化 检索 AI 代理工具 。

非结构化数据

非结构化数据包括原始文档、PDF、电子邮件、图像和其他不符合固定架构的格式。 此类数据需要通过分析、分块和嵌入的组合进行额外的处理，才能在 gen AI 应用中进行有效查询和使用。 有关向 Gen AI 应用添加结构化数据的建议，请参阅针对 非结构化数据的生成和跟踪检索器工具 。

外部 API 和操作

在某些情况下，第一代 AI 应用可能需要与外部系统交互才能检索数据或执行作。 如果应用程序需要调用工具或与外部 API 交互，建议执行以下作：

• 使用 Unity 目录连接管理 API 凭据： 使用 Unity 目录连接安全地管理 API 凭据。 此方法可确保对令牌和机密进行集中管理和访问控制。
• 通过 Databricks SDK 调用：
  使用库中的http_requestdatabricks-sdk函数将 HTTP 请求发送到外部服务。 此函数利用 Unity 目录连接进行身份验证并支持标准 HTTP 方法。
• 利用 Unity Catalog 函数：
  在 Unity Catalog 函数中包装外部连接，以添加自定义预处理或后处理逻辑。
• Python 执行程序工具：
  若要使用 Python 函数动态执行数据转换或 API 交互的代码，请使用内置的 Python 执行程序工具。

示例：

内部分析应用程序从外部财务 API 检索实时数据。 应用程序使用：

• 用于安全存储 API 凭据的 Unity 目录外部连接。
• 自定义 Unity 目录函数包装 API 调用以添加预处理（如数据规范化）和后处理（如错误处理）。
• 此外，应用程序还可以 通过 Databricks SDK 直接调用 API。

实施方法

开发 Gen AI 应用时，有两个主要选项来实现代理的逻辑：利用开源框架或使用 Python 代码生成自定义解决方案。 下面是每种方法的优缺点细分。

使用框架（如 LangChain、LlamaIndex、CrewAI 或 AutoGen）

优点：

• 现成组件： 框架附带现成的工具，可用于提示管理、链接调用以及与各种数据源集成，从而加速开发。
• 社区和文档： 受益于社区支持、教程和常规更新。
• 常见设计模式： 框架通常提供明确的模块化结构来协调常见任务，从而简化整体代理设计。

缺点：

• 增加了抽象化：开源框架通常会引入抽象层，而这些抽象层对于特定用例来说可能没有必要。
• 对更新的依赖项： 你可能依赖于框架维护人员进行 bug 修复和功能更新，这可能会降低快速适应新要求的能力。
• 潜在的开销： 如果应用程序需要精细的控制，则额外的抽象可能会导致自定义挑战。

使用纯粹的Python

优点：

• 灵活性： 通过纯 Python 进行开发，可以完全根据需求定制实现，而无需受到框架的设计决策的约束。
• 快速适应： 可以根据需要快速调整代码并合并更改，而无需等待外部框架的更新。
• 单纯： 避免不必要的抽象层，这可能会导致更精简、性能更高的解决方案。

缺点：

• 增加开发工作量： 从头开始构建可能需要更多时间和专业知识来实现专用框架可能提供的功能。
• 重新发明轮子： 你可能需要自行开发常用功能（如工具链或提示管理）。
• 维护责任： 所有更新和 bug 修复都成为你的责任，这对复杂的系统来说可能很困难。

最终，你的决策应以项目的复杂性、性能需求和所需的控制级别为指导。 这两种方法本质上都不优越;每个选项都提供不同的优势，具体取决于你的开发偏好和战略优先级。

1. 构建

在这个阶段，你将解决方案设计转化为一个实际运行的生成式 AI 应用程序。 与其提前完善一切，不如从最小的概念证明（POC）开始，快速测试。 这样，便可以尽快部署到预生产环境，收集来自实际用户或中小企业的代表查询，并根据实际反馈进行优化。

生成过程遵循以下关键步骤：

a。 准备数据和工具： 确保所需的数据可访问、分析和准备检索。 实现或注册 Unity Catalog 函数和连接（例如检索 API 或外部 API 调用），以供您的代理使用。 b. 生成代理： 从简单的 POC 方法开始，协调核心逻辑。 选项c. 质量检查： 在向更多用户公开应用之前验证基本功能。 d。 部署预生产代理： 使 POC 可供测试用户和主题专家进行初始反馈。 e。 收集用户反馈： 使用实际用法来确定改进区域、所需的其他数据或工具，以及下一次迭代的潜在优化。

a。 准备数据和工具

在解决方案设计阶段，你将初步了解应用所需的数据源和工具。 在此阶段，只需给予最少关注：只需专注于获得足够的数据来验证 POC。 这可确保快速迭代，而无需对复杂管道进行大量前期投资。

数据

1. 标识具有代表性的数据子集
   • 对于 结构化数据，请选择与初始方案最相关的键表或列。
   • 对于 非结构化数据，请仅对一部分代表性文档进行索引编制优先级。 将基本分块/嵌入管道与 马赛克 AI 矢量搜索 配合使用，以便代理可以根据需要检索相关的文本区块。
2. 设置数据访问
   • 如果需要应用进行外部 API 调用，请使用 Unity 目录连接安全地存储凭据。
3. 验证基本覆盖范围
   • 确认所选数据子集能够充分解决计划测试的用户查询。
   • 保存任何其他数据源或复杂转换，以供将来的迭代。 你当前的目标应该是证明基本可行性和收集反馈。

工具

设置数据源后，下一步是实现和注册代理在运行时将调用的工具到 Unity 目录。 工具是一种 单交互函数，例如 SQL 查询或外部 API 调用，代理可以调用该函数进行检索、转换或作。

数据检索工具

• 受约束的结构化数据查询： 如果查询已修复，请将它们包装在 Unity 目录 SQL 函数或 Python UDF 中。 这让逻辑保持集中且可发现。
• 开放式结构化数据查询： 如果查询更开放，请考虑设置 Genie 空间 来处理文本到 SQL 查询。
• 非结构化数据帮助程序函数： 对于在马赛克 AI 矢量搜索中存储的非 结构化数据，请创建一个非结构化数据检索工具 ，代理可以调用该工具来提取相关的文本区块。

API 调用工具

• 外部 API 调用： 可以使用 Databricks SDK 的 方法直接http_request。
• 可选包装器： 如果需要实现预处理或后处理逻辑（例如数据规范化或错误处理），请将 API 调用包装在 Unity 目录函数中。

保持最小

• 仅从基本工具开始： 专注于单个检索路径或有限的一组 API 调用。 您可以在迭代过程中添加更多内容。
• 以交互方式验证： 在将每个工具合并到代理系统中之前（例如，在笔记本中）独立测试。

原型工具准备就绪后，继续生成代理。 代理协调这些工具来回答查询、提取数据并根据需要执行作。

b. 生成代理

准备好数据和工具后，可以生成响应传入请求（如用户查询）的代理。 若要创建初始原型代理，请使用 Python 或 AI实验场。 执行以下步骤：

1. 从简单开始
   • 选择基本设计模式： 对于 POC，请从基本链（如固定步骤序列）或单个工具调用代理（LLM 可以动态调用一两个基本工具）开始。
     • 如果方案与 Databricks 文档中的示例笔记本之一相符，请以该代码为框架来开发。
   • 最小提示：此时请控制住过度设计提示的冲动。 保持说明简洁，与初始任务直接相关。
2. 整合工具
   • 工具集成： 如果使用链式设计模式，调用每个工具的步骤将进行硬编码。 在工具调用代理中，提供 架构 ，以便 LLM 知道如何调用函数。
     • 在将工具合并到代理系统并测试端到端之前，验证隔离中的工具是否按预期执行。
   • 护栏： 如果代理可以修改外部系统或运行代码，请确保具有基本的安全检查和防护措施（例如限制调用数或限制某些作）。 在 Unity 目录函数中实现这些内容。
3. 使用 MLflow 跟踪和记录代理
   • 跟踪每个步骤： 使用 MLflow 跟踪 捕获每步输入、输出和已用时间，以调试问题和度量性能。
   • 记录代理： 使用 MLflow 跟踪 记录代理的代码和配置。

在这个阶段， 完美不是目标。 你需要一个简单且可以正常运行的代理，以便从测试用户和领域专家那里获取早期反馈。 在预生产环境中将其开放之前，下一步是进行快速质量检查。

选项c. 质量检查

在向更广泛的预生产受众公开代理之前，请先运行一次未上线的“达标”质量检查，以在将代理部署到终结点之前找出重大问题。 在此阶段，通常不会有一个大型可靠的评估数据集，但你仍然可以执行快速传递，以确保代理在少数示例查询上按预期方式运行。

1. 在笔记本中以交互方式测试
   • 人工检查：人工致电代理，提出客服需求。 请注意它是否检索正确的数据，正确调用工具，并遵循所需的格式。
   • 检查 MLflow 跟踪： 如果已启用 MLflow 跟踪，请查看分步遥测。 确保代理选择合适的工具，优雅地处理错误，并且不会产生意外的中间请求或结果。
   • 检查延迟： 请注意每个请求的运行时间。 如果响应时间或令牌使用率过高，可能需要修剪步骤或简化逻辑，才能继续推进。
2. 可行性检查
   • 这可以在笔记本或者AI游乐场中完成。
   • 一致性和正确性： 代理的输出对测试的查询是否有意义？ 是否有明显的不准确或缺少详细信息？
   • 边缘事例： 如果尝试了一些偏离常规的查询，代理是否仍然逻辑地回应，或者至少优雅地失败（例如，礼貌地拒绝回答，而不是生成不合逻辑的输出）？
   • 提示遵守： 如果提供了高级说明（如所需的音调或格式设置），代理是否遵循这些说明？
3. 评估“足够好”的质量
   • 如果目前对测试查询受到限制，请考虑生成综合数据。 请参阅 “创建评估集”。
   • 解决主要问题： 如果发现重大缺陷（例如，代理反复调用无效的工具或输出无稽之谈），请在向更广泛的受众公开这些问题之前解决这些问题。 请参阅 常见质量问题以及如何解决这些问题。
   • 决定可行性： 如果代理满足一小部分查询的基本可用性和正确性，则可以继续作。 否则，请优化提示、修复工具或数据问题并重新测试。
4. 规划后续步骤
   • 跟踪进展： 记录你决定暂时推迟的任何不足之处。 在预生产中收集实际反馈后，你可以重新审视这些内容。

如果一切看起来都可行，可以进行有限的推出，则可以将代理部署到预生产环境。 后续 阶段将进行全面的评估过程，尤其是在拥有更真实的数据、SME 反馈和结构化评估集之后。 目前，请专注于确保代理可靠地演示其核心功能。

d。 部署预生产代理

代理满足基线质量阈值后，下一步是在预生产环境中托管它，以便你可以了解用户如何查询应用并收集其反馈来指导开发。 此环境可以是 POC 阶段的开发环境。 主要要求是环境可供选择内部测试人员或领域专家访问。

1. 部署代理
   • 记录和注册代理： 首先， 将代理记录 为 MLflow 模型， 并将其注册 到 Unity 目录中。
   • 使用代理框架进行部署： 使用代理框架获取已注册的代理 并将其部署 为模型服务终结点。
2. 推理表
   • 代理框架会自动将请求、响应和跟踪以及元数据存储在每个服务终结点的 Unity Catalog 的 推理表 中。
3. 保护和配置
   • 访问控制：限制对 测试组（SME、核心用户）的端点访问。 这可确保受控的使用，并避免意外的数据泄露。
   • 身份验证： 确认正确配置了任何必需的机密、API 令牌或数据库连接。

你现在有一个受控的环境，用于收集有关真实查询的反馈。 快速与代理交互的方法之一是在 AI Playground 中，可以在其中选择新创建的模型服务终结点并查询代理。

e。 收集用户反馈

将代理部署到预生产环境后，下一步是收集真实用户和中小企业的反馈，以发现差距、发现不准确之处并进一步优化代理。

1. 使用审阅应用

   • 使用代理框架部署代理时，将创建一个简单的聊天样式 审阅应用 。 它提供了一个用户友好的界面，测试人员可以提出问题并立即对代理的响应进行评分。
   • 所有请求、响应和用户反馈（大拇指向上/向下、书面注释）都会自动记录到 推理表，以便以后轻松进行分析。

2. 使用监视 UI 检查日志

   • 在 监视 UI 中跟踪投票/下票或文本反馈，以查看测试人员发现哪些响应特别有用（或无帮助）。

3. 吸引域专家

   • 鼓励中小企业模拟典型和不寻常的情境。 域知识有助于呈现微妙的错误，例如策略错误解释或缺失数据。
   • 保留问题清单，涉及从轻微的提示调整到较大的数据管道重构的所有方面。 在继续之前，确定要优先修复的问题。

4. 策展新的评估数据

   • 将值得注意或有问题的交互转换为测试用例。 随着时间的推移，这些构成更可靠的评估数据集的基础。
   • 如果可能，请为这些情况添加正确答案或预期答案。 这有助于在后续评估周期中测量质量。

5. 基于反馈进行迭代

   • 应用诸如小提示变更或新的防护措施等快速修复，以解决现时的问题。
   • 对于更复杂的问题，例如需要高级多步骤逻辑或新数据源，在投资重大体系结构更改之前收集足够的证据。

通过利用“审阅应用”、“推理表日志”和“SME 见解”提供的反馈，此预生产阶段有助于呈现关键差距，并迭代优化代理。 在此步骤中收集的实际交互为构建结构化评估集奠定了基础，使你能够从即席改进过渡到更系统的质量度量方法。 解决定期问题并稳定性能后，你将为生产部署做好充分准备，并进行可靠的评估。

2. 评估并迭代

在预生产环境中测试 Gen AI 应用后，下一步是系统地测量、诊断和优化其质量。 此“评估和迭代”阶段将原始反馈和日志转换为结构化评估集，使你能够反复测试改进并确保应用满足准确性、相关性和安全性所需的标准。

此阶段包括以下步骤：

• 从日志收集实际查询： 将推理表中的高值或有问题的交互转换为测试用例。
• 添加专家标签： 在可能的情况下，将这些案例的真实性或风格和政策准则附加到这些案例，以便更客观地衡量正确性、基础性和其他质量维度。
• 利用代理评估：使用内置的 LLM 判定或自定义检查来量化应用质量。
• 迭代： 通过优化代理的逻辑、数据管道或提示来提高质量。 重新运行评估，确认是否已解决关键问题。

请注意， 即使 Gen AI 应用在 Databricks 外部运行，这些功能也能正常工作。 通过将 MLflow 跟踪功能集成到代码中，可以从任何环境中收集跟踪数据，并在 Databricks 数据智能平台中统一这些数据，以便进行统一评估和监控。 随着你继续整合新的查询、反馈和 SME 见解，评估数据集将成为支撑持续改进周期的生存资源，确保你的第一代 AI 应用保持可靠、可靠且符合业务目标。

一个。 评估代理

在预生产环境中运行代理后，下一步是系统地测量其性能，使其性能超出临时氛围检查。 Mosaic AI 代理评估使你能够创建评估集、使用内置或自定义 LLM 评判器运行质量检查，并快速循环访问问题领域。

离线和在线评估

评估第一代 AI 应用程序时，有两种主要方法：脱机评估和联机评估。 开发周期的这一阶段侧重于脱机评估，即实时用户交互之外的系统评估。 稍后在讨论在生产环境中监视代理时，将介绍联机评估。

团队往往在开发人员工作流程中过度依赖“氛围测试”，非正式地尝试一些查询，并主观判断响应是否看起来合理。 虽然这提供了一个起点，但它缺乏构建生产质量应用程序所需的严格性和覆盖范围。

相比之下，适当的脱机评估过程执行以下操作：

• 在更广泛的部署之前建立质量基线，从而创建明确的指标以改进为目标。
• 确定需要注意的特定弱点，这超越了仅测试预期用例的局限性。
• 通过自动比较各版本的性能来优化应用时，检测质量回归。
• 提供定量指标 ，以演示利益干系人改进情况。
• 帮助在用户之前发现边缘情况 和潜在故障模式。
• 降低将性能不佳的代理部署到生产环境的风险。

从长远来看，投入时间进行脱机评估会带来显著回报，帮助你持续提供高质量的反馈。

创建评估集

评估集是衡量第一代 AI 应用性能的基础。 与传统软件开发中的测试套件类似，这种代表性查询和预期响应集合将成为质量基准和回归测试数据集。

可以通过多种补充方法生成评估集：

1. 将推理表日志转换为评估示例

   最有价值的评估数据直接来自实际使用情况。 预生产部署生成了包含请求、代理响应、工具调用和检索上下文的推理表日志。

   将这些日志转换为评估集具有以下优点：

   • 实际覆盖范围： 包括你可能没有预料到的不可预知的用户行为。
   • 关注问题：可以专门筛选负面反馈或响应缓慢。
   • 代表性分布： 捕获不同查询类型的实际频率。

2. 生成综合评估数据

   如果没有特选的用户查询集，可以 自动生成综合评估数据集。 这一“入门套装”提问可帮助你快速评估代理是否：

   • 返回一致、准确的答案。
   • 以正确的格式进行响应。
   • 尊重结构、音调和政策准则。
   • 正确检索上下文（适用于 RAG）。

   合成数据通常并不完美。 把它想象成一个临时的垫脚石。 你还需要：

   • 让中小企业或领域专家评审和修剪任何无关或重复的查询。
   • 稍后使用实际使用情况日志替换或扩充它。

3. 手动整理查询

   如果不想依赖综合数据，或者还没有推理日志，请识别 10 到 15 个实际查询或代表性查询，并从这些查询创建评估集。 代表性查询可能来自用户面试或开发人员集思广益。 即使是简短的特选列表也会暴露代理响应中的明显缺陷。

这些方法不是相互排斥的，而是互补的。 有效的评估集随着时间推移而发展，通常合并来自多个源的示例，包括：

• 从手动策划的示例开始，测试核心功能。
• （可选）添加综合数据以扩大覆盖范围，然后再获得实际用户数据。
• 在实际日志可用时逐渐引入。
• 使用反映不断变化的使用模式的新示例不断刷新。

评估查询的最佳做法

在创建评估集时，有意包括各种查询类型，如下所示：

• 预期和意外的使用模式（例如很长或短的请求）。
• 潜在的滥用尝试或提示注入攻击（例如尝试揭示系统提示）。
• 需要多个推理步骤或工具调用的复杂查询。
• 具有最少或模糊信息的边缘事例（如拼写错误或模糊查询）。
• 表示不同用户技能级别和背景的示例。
• 用于测试响应中潜在偏差的查询（如“比较公司 A 与公司 B”）。

请记住，评估集应随应用程序一起增长和发展。 发现新的故障模式或用户行为时，请添加具有代表性的示例，以确保代理在这些方面继续改进。

添加评估条件

每个评估示例都应有评估质量的条件。 这些标准充当对代理响应进行度量的标准，从而跨多个质量维度实现客观评估。

基本事实或参考答案

评估事实准确性时，有两种主要方法：预期事实或参考答案。 每个策略在评估策略中都有不同的用途。

使用预期事实（建议）

expected_facts方法涉及列出应出现在正确响应中的关键事实。 有关示例，请参阅示例评估集，其中包含request、responseguidelines和expected_facts。

此方法具有显著优势：

• 允许灵活地在响应中表达事实。
• 使中小企业更容易提供基本真相。
• 在确保核心信息存在的同时，适应不同的响应样式。
• 支持跨模型版本或参数设置进行更可靠的评估。

内置的正确性判断会检查代理的响应是否包含这些基本事实，无论措辞、顺序或额外内容如何。

使用预期响应（可选）

或者，可以提供 完整的参考答案。 此方法在以下情况下最有效：

• 你有专家创建的黄金标准答案。
• 响应的确切措辞或结构很重要。
• 你正在评估高度管控上下文中的响应。

Databricks 通常建议使用 expected_facts 而不是 expected_response，因为它提供更大的灵活性，同时仍确保准确性。

样式、语气或策略符合性指南

除了事实准确性之外，可能需要评估响应是否遵循特定样式、语气或策略要求。

仅供指南

如果主要关注的是强制实施样式或策略要求，而不是事实准确性，则可以 提供没有预期事实的准则：

# Per-query guidelines
eval_row = {
    "request": "How do I delete my account?",
    "guidelines": {
        "tone": ["The response must be supportive and non-judgmental"],
        "structure": ["Present steps chronologically", "Use numbered lists"]
    }
}

# Global guidelines (applied to all examples)
evaluator_config = {
    "databricks-agent": {
        "global_guidelines": {
            "rudeness": ["The response must not be rude."],
            "no_pii": ["The response must not include any PII information (personally identifiable information)."]
        }
    }
}

LLM 评判器的准则解释这些自然语言说明，并评估响应是否符合这些说明。 这特别适用于主观质量维度，如语气、格式设置和遵守组织策略。

结合基本事实和准则

为了进行全面的评估，可以将事实准确性检查与样式准则相结合。 请参阅包含 request、response、guidelines 和 expected_facts 的示例评估集。 此方法可确保响应既真实准确，又符合组织的通信标准。

使用预先记录的响应

如果已从开发或测试中捕获请求-响应对，则可以直接评估它们，而无需重新调用代理。 这适用于：

• 分析代理行为中的现有模式。
• 针对以前的版本对性能进行基准测试。
• 通过不重新生成响应来节省时间和成本。
• 评估在 Databricks 外部运行的代理。

有关在评估数据帧中提供相关列的详细信息，请参阅 示例：如何将以前生成的输出传递给代理评估。 马赛克 AI 代理评估使用这些预先捕获的值，而不是再次调用代理，同时仍应用相同的质量检查和指标。

评估条件的最佳做法

定义评估条件时：

1. 具体和客观： 定义明确且可衡量的标准，以便不同的评估者可以类似地解释。
   • 请考虑添加自定义指标来衡量你关心的质量标准。
2. 关注用户价值： 优先考虑符合用户最重要需求的标准。
3. 从简单开始：从一组核心条件开始，随着对质量需求的逐步了解而扩展。
4. 平衡覆盖范围： 包括满足质量不同方面（例如事实准确性、风格和安全）的标准。
5. 根据反馈进行迭代： 根据用户反馈和不断变化的要求优化条件。

有关生成高质量评估数据集的详细信息，请参阅 开发评估集的最佳做法 。

运行评估

现在你已准备好一个包含查询和条件的评估集，可以使用 mlflow.evaluate() 来运行评估。 此函数处理整个评估过程，从调用代理到分析结果。

基本评估工作流

运行基本评估只需几行代码。 有关详细信息，请参阅 运行评估。

触发评估时：

1. 对于评估集中的每一行，mlflow.evaluate() 执行以下操作：
   • 致电代理并提出问题（如果尚未提供应答）。
   • 应用内置的 LLM 判定来评估质量维度。
   • 计算操作指标，如令牌使用和延迟。
   • 记录每个评估的详细理由。
2. 结果会自动记录到 MLflow，创建：
   • 逐行评估质量。
   • 所有示例的聚合指标。
   • 用于调试和分析的详细日志。

自定义评估

可以使用其他参数根据特定需求定制评估。 该 evaluator_config 参数允许执行以下操作：

• 选择要运行的内置评判器。
• 设置适用于所有示例的全局准则。
• 为法官配置阈值。
• 提供几个示例来指导评估器评估。

有关详细信息和示例，请参阅 示例。

评估 Databricks 外部的代理

代理评估的一项强大功能是能够评估部署在任何地方的生成式 AI 应用，而不仅仅是在 Databricks 上。

哪些判定适用

默认情况下，代理评估会根据评估集中提供的数据自动 选择相应的 LLM 评委 。 有关如何评估质量的详细信息，请参阅 LLM 法官如何评估质量。

分析评估结果

运行评估后，MLflow UI 提供可视化效果和见解来了解应用的性能。 此分析可帮助你识别模式、诊断问题并确定改进的优先级。

浏览评估结果

运行 mlflow.evaluate(), 后打开 MLflow UI 时，将找到多个互连视图。 有关如何在 MLflow UI 中导航这些结果的信息，请参阅 使用 MLflow UI 查看输出。

有关如何解释故障模式的指导，请参阅 b.改进代理和工具。

自定义 AI 判定和指标

虽然内置评判程序涵盖许多常见检查（例如正确性、样式、策略和安全性），但您可能需要评估与应用性能有关的特定领域方面。 自定义评委和指标允许你扩展评估功能，以满足独特的质量要求。

自定义 LLM 判定

有关如何从提示创建自定义 LLM 法官的详细信息，请参阅 从提示创建 AI 法官。

自定义判定擅长评估从类似人的判断中获益的主观或细微质量维度，例如：

• 领域特定的合规性（法律、医疗、财务）
• 品牌语音和沟通风格。
• 文化敏感性和适当性。
• 复杂的推理质量。
• 专业书写惯例。

法官的输出与内置评委一起出现在 MLflow UI 中，并提供了解释评估的相同详细理由。

自定义指标

若要进行更编程的确定性评估，可以使用修饰器创建自定义指标 @metric 。 请参阅 @metric 修饰器。

自定义指标非常适合：

• 验证格式验证和架构符合性等技术要求。
• 检查特定内容的存在或缺失。
• 执行定量度量，例如响应长度或复杂性分数。
• 实现特定于业务的验证规则。
• 与外部验证系统集成。

b. 改进代理和工具

运行评估并确定质量问题后，下一步是系统地解决这些问题以提高性能。 评估结果提供有关代理失败位置和方式的宝贵见解，使你能够进行有针对性的改进，而不是随机调整。

常见质量问题以及如何解决这些问题

LLM 评估器的评估结果指向代理系统中的特定故障类型。 本部分探讨这些常见的故障模式及其解决方案。 有关如何解释 LLM 法官输出的信息，请参阅 AI 法官输出。

质量迭代最佳做法

在迭代改进时，请维护详细的文档记录。 例如：

1. 对你的更改进行版本管理
   • 使用 MLflow 跟踪记录每个重大迭代。
   • 在中央配置文件中保存提示、配置和密钥参数。 确保已使用代理记录此日志。
   • 对于每个新部署的代理，请在存储库中保留 更改日志 ，详细说明更改的原因。
2. 记录有效和无效的内容
   • 记录成功和失败的方法。
   • 请注意每个更改对指标的具体影响。 链接回代理评估 MLflow 运行。
3. 与利益干系人保持一致
   • 使用评审应用验证中小企业的改进。
     • 使用审阅者说明向审阅者传达更改。
   • 若要并行比较不同版本的代理，请考虑在 AI Playground 中创建多个代理终结点并使用模型。 这使用户能够向单独的终结点发送相同的请求，并并行检查响应和跟踪。

3. 生产

在迭代评估和改进应用后，你已达到满足要求的质量级别，并已准备好进行更广泛的使用。 生产阶段涉及到将优化后的代理部署到生产环境，并实施持续监视，以随时间推移维护质量。

生产阶段包括：

• 将代理部署到生产环境： 设置具有适当安全性、缩放和身份验证设置的生产就绪终结点。
• 监视生产中的代理： 建立持续的质量评估、性能跟踪和警报，以确保代理在实际使用中保持高质量和可靠性。

这会创建一个持续反馈循环，其中监视见解可进一步改进，你可以测试、部署并继续监视这些改进。 此方法可确保应用在整个生命周期内保持高质量、合规且符合不断发展的业务需求。

a。 将代理部署到生产环境

完成全面评估和迭代改进后，即可将代理部署到生产环境。 [Mosaic AI 代理框架](/generative-ai/agent-framework/build-gen AI-apps.md#agent-framework) 通过自动处理许多部署问题来简化此过程。

部署过程

将代理部署到生产环境涉及以下步骤：

1. 在 Unity Catalog 中将代理记录并注册为 MLflow 模型。
2. 使用代理框架部署代理。
3. 为您的代理需要访问的任何依赖资源配置身份验证。
4. 测试部署以验证生产环境中的功能。
   • 模型服务终结点准备就绪后，可以在 AI Playground 中与代理交互，可在其中测试和验证功能。

有关详细实现步骤，请参阅 为生成式 AI 应用程序部署代理。

生产部署注意事项

迁移到生产环境时，请记住以下关键注意事项：

性能和缩放

• 根据预期的使用模式平衡成本与性能。
• 请考虑为间歇性使用的代理启用缩放到零，以降低成本。
• 根据应用程序的用户体验需求了解延迟要求。

安全和治理

• 为所有代理组件确保在 Unity 目录级别进行适当的访问控制。
• 尽可能对 Databricks 资源使用内置身份验证直通。
• 为外部 API 或数据源配置适当的凭据管理。

集成方法

• 确定应用程序如何与代理交互（例如，使用 API 或嵌入式接口）。
• 请考虑如何在应用程序中处理和显示代理响应。
  • 如果客户端应用程序需要其他上下文（例如源文档引用或置信度分数），请将代理设计为在其响应中包含此元数据（例如，使用 自定义输出）。
• 规划代理不可用时的错误处理和回退机制。

反馈集合

• 在初始推出期间利用评审应用获取利益干系人反馈。
• 在应用程序界面中直接收集用户反馈的设计机制。
  • 为从评审应用收集反馈而创建的反馈终结点也可以由外部应用程序用来提供有关代理的反馈。 请参阅提供有关已部署代理的反馈。
• 确保反馈数据流入评估和改进过程。

b. 监视生产中的代理

将代理部署到生产环境后，必须持续监视其性能、质量和使用模式。 与具有确定性功能的传统软件不同，第一代 AI 应用在遇到实际输入时，可能会表现出质量偏差或意外行为。 通过有效的监视，可以尽早检测问题、了解使用模式，并不断提高应用程序的质量。

设置代理监视

马赛克 AI 提供内置 监视功能 ，使你可以跟踪代理的性能，而无需生成自定义监视基础结构：

1. 为已部署的代理创建监视器。
2. 根据流量和监视需求配置采样率和频率。
3. 选择质量指标 以自动评估采样的请求。

关键监视维度

一般情况下，有效的监视应涵盖三个关键维度：

1. 运营指标

   • 请求量和请求模式。
   • 响应延迟。
   • 错误率和类型。
   • 令牌使用情况和成本。

2. 质量指标

   • 与用户查询的相关性。
   • 检索的上下文中的基度。
   • 安全和准则遵循。
   • 整体质量合格率。

3. 用户反馈

   • 显式反馈（向上/向下大拇指）。
   • 隐式信号（后续问题，中断的对话）。
   • 上报到支持渠道的问题。

使用监控用户界面

监视 UI 通过两个选项卡提供跨这些维度的可视化见解。

• “图表”选项卡：查看请求量、质量指标、延迟和随时间推移的错误的趋势。
• “日志”选项卡：检查单个请求和响应，包括其评估结果。

筛选功能使用户能够搜索特定查询或按评估结果进行筛选。 有关详细信息，请参阅什么是适用于生成式 AI 的湖屋监视？。

创建仪表板和警报

用于全面监视：

• 使用存储在评估跟踪表中的监视数据生成自定义仪表板。
• 为关键质量或运营阈值设置警报。
• 与主要利益干系人安排定期质量评审。

持续改进周期

监测在能够反馈到改进过程中时最为有价值。

1. 通过监视指标和用户反馈确定问题。
2. 将有问题的示例导出 到评估集。
3. 诊断根本原因，使用 MLflow 跟踪分析和 LLM 判断结果（如常见质量问题及其解决方法中讨论的内容）。
4. 针对扩展评估集开发和测试改进。
5. 部署更新并监视 影响。

这种 迭代的闭合循环方法 有助于确保代理根据实际使用模式继续改进，同时保持高质量，同时适应不断变化的要求和用户行为。 借助代理监视，可以深入了解代理在生产中的表现，从而能够主动解决问题并优化质量和性能。