「吴恩达Agentic AI模块4简报」工作流开发与优化
概要
本简报深入剖析了构建和优化 Agentic AI 工作流的系统化、迭代化流程。核心理念是避免长时间的理论构思，而是通过快速构建一个“粗糙但可用”的初始系统来启动开发周期。该流程强调在“构建”和“分析”之间进行持续循环，通过严谨的评估与错误分析来指导开发方向，从而实现高效、有针对性的系统改进。
关键要点
- 迭代式开发循环： 成功的 Agentic AI 系统开发并非线性过程，而是一个在构建、评估、分析和改进之间不断循环的迭代过程。首先构建一个基本原型，然后通过分析其输出来发现问题，从而为下一步的构建工作指明方向。
- 评估（Evals）是核心驱动力： 建立评估体系是衡量进展和驱动改进的关键。评估应从简单的“端到端评估”开始，针对系统在特定方面的不足（如日期提取不准、文本长度超标）创建小规模的测试集（例如 10-20 个样本），以量化改进效果。
- 系统的错误分析： 为了确定应优先处理哪个系统组件，必须进行系统的错误分析。开发者应专注于系统出错的案例，审查每个步骤的“迹线”（traces），即中间输出，并使用电子表格等工具统计每个组件导致错误的频率。这能以数据驱动的方式揭示真正的瓶颈，避免凭直觉做出耗时且无效的决策。
- 组件级评估的重要性： 当错误分析指向特定组件时，建立“组件级评估”能极大提升优化效率。它能为该组件提供一个清晰、无干扰的性能信号，使得开发者可以快速迭代调整（如更换API、调整超参数），而无需每次都运行完整且昂贵的端到端评估。
- 优化策略的多样性： 针对不同组件的问题，需要采用不同的解决策略。对于非 LLM 组件，可以通过调整参数或更换工具来改进；对于基于 LLM 的组件，方法包括优化提示词、更换模型、分解任务，乃至在必要时进行模型微调。
- 成本与延迟的后期优化： 在系统输出质量达标之前，成本和延迟应是次要考虑因素。一旦系统性能稳定，可通过对工作流各环节进行基准测试，精确找出成本和时间开销最大的部分，然后有针对性地进行优化。
总之，高效的 Agentic AI 工作流开发依赖于一套严谨的分析方法论，它能将开发者的精力引导至最能提升系统整体性能的地方。
1. 核心开发理念：从快速原型到迭代优化
构建 Agentic AI 系统的首要原则是快速行动。与其花费数周时间进行理论探讨和假设，不如尽快构建一个“粗糙但可用”（quick and dirty）的初始系统。这个原型不必完美，但它提供了一个可供观察和分析的实体。
关键步骤：
- 快速构建原型：以安全、负责任的方式（如避免数据泄露）快速搭建一个端到端的系统。
- 手动审查输出：运行原型并审查一小批（如 10-20 个）样本的最终输出。
- 识别错误模式：通过审查，识别系统常见的失败模式。例如，在发票处理工作流中，可能会发现系统经常混淆“发票开具日期”和“付款截止日期”。
- 确定优化焦点：这种初步分析能够揭示系统的主要弱点，从而帮助开发者决定应将精力集中在哪个方面进行评估和改进。例如，如果日期混淆是主要问题，那么就应该优先建立一个衡量日期提取准确率的评估体系。
“我发现，在开发一个 Agentic AI 系统时，很难预先知道它在哪里会运行良好，在哪里会表现不佳，因此也很难知道应该将精力集中在哪里。所以，一个非常普遍的建议是，先尝试构建一个哪怕是粗糙的系统，这样你就可以试用并观察它，看看哪些地方可能还没有达到你期望的效果，从而更有针对性地进行进一步开发。” Andrew Ng
2. 评估（Evals）：衡量和驱动系统改进
一旦确定了系统的关键弱点，下一步就是建立评估（Evals）体系来量化问题并跟踪改进进度。评估是推动系统性能提升的基石。
端到端评估的构建
端到端评估衡量的是从用户输入到最终输出的整个系统的性能。构建方法取决于具体应用场景和发现的错误模式。
- 案例 1：发票处理（提取截止日期）
- 问题：系统经常混淆日期。
- 评估构建：
- 创建测试集：选取 10-20 张发票，手动记录下每张发票正确的“付款截止日期”，形成“真实标签”（ground truth）。
- 标准化输出：在提示词中要求 LLM 始终以标准格式（如 YYYY-MM-DD）输出日期。
- 编写评估代码：使用代码（如正则表达式）从 LLM 的输出中提取日期，并将其与真实标签进行比对。
- 计算准确率：通过计算匹配正确的百分比来衡量系统性能，并以此为指标来迭代优化提示词或系统其他部分。
- 案例 2：营销文案助手（控制文本长度）
- 问题：生成的文案经常超过 10 个词的长度限制。
- 评估构建：
- 创建测试集：准备 10-20 个需要生成文案的产品图片和查询。
- 编写评估代码：运行系统，然后编写代码计算每个输出文案的单词数量。
- 衡量合规率：将单词数与 10 个词的目标进行比较，统计符合要求的比例。这个案例的特点是没有逐例的真实标签，所有样本共享同一个目标（长度小于等于10）。
- 案例 3：研究助手（确保内容完整性）
- 问题：生成的文章有时会遗漏该领域专家认为至关重要的关键信息点。
- 评估构建：
- 创建测试集：设计多个研究主题（如“黑洞科学的最新突破”），并为每个主题手动编写 3-5 个“黄金标准讨论点”（gold standard discussion points）。
- 使用 LLM-as-a-judge：由于关键点的表述方式多种多样，简单的代码匹配难以胜任。因此，可以利用另一个 LLM 作为“裁判”，让它判断系统生成的文章覆盖了多少个黄金标准讨论点。
- 量化得分：提示词可以要求 LLM 裁判返回一个 JSON 对象，其中包含一个 0-5 的分数和解释，从而为每个样本生成一个量化评估结果。
评估方法的分类框架
评估方法可以根据两个维度进行分类，形成一个 2x2 的框架，这有助于系统性地思考如何为特定应用设计评估。
| 客观评估（代码） | 主观评估（LLM-as-a-judge） |
|---|---|
| 有逐例真实标签 | 发票日期提取：每个发票有唯一的正确截止日期，可通过代码精确匹配。 |
| 研究助手内容完整性 | 每篇文章有不同的黄金标准讨论点，需要 LLM 的理解能力来判断是否覆盖。 |
| 无逐例真实标签 | 营销文案长度检查：所有文案共享同一个长度标准（如10个词），可通过代码计算。 |
| 图表生成质量评估 | 所有图表都遵循同一套标准（如“坐标轴标签是否清晰”），需要 LLM 根据这套标准进行评估。 |
评估设计的实用技巧
- 从粗糙的评估开始： 不要因为追求完美的评估体系而陷入停滞。一个包含 10-20 个样本的简单评估就足以启动迭代过程。
- 持续迭代评估体系： 随着开发的深入，评估体系也需要不断完善。如果评估指标的变化与你对系统性能的直观判断不符，这通常意味着需要改进评估本身，例如增加样本量或改变评估方法。
- 以人类专家为基准： 寻找系统性能不如人类专家的领域，这往往是改进工作的灵感来源。
3. 错误分析：精确定位问题的根源
当端到端评估显示系统性能不佳时，下一步是找出导致问题的具体组件。Agentic 工作流通常包含多个步骤，错误分析的目的是系统性地定位瓶颈，避免凭直觉进行低效的尝试。
核心方法：
- 关注失败案例： 将系统表现良好的案例放在一边，集中分析那些最终输出不令人满意的案例。
- 审查“迹线”（Traces）： 深入研究工作流中每一步的中间输出（也称为“span”）。例如，在研究助手中，需要审查生成的搜索词、搜索引擎返回的 URL 列表、被选中下载的文章列表等。
- 建立归因电子表格： 创建一个电子表格来系统地记录错误。对于每个失败案例，逐一检查每个组件的输出，判断其表现是否“不合格”（subpar），即是否远差于人类专家在该环节的表现。
- 统计错误频率： 完成分析后，统计每个组件被标记为“出错”的频率。这可以明确指出哪个组件是最大的问题来源。
- 案例：研究助手
- 问题：文章遗漏关键点。
- 可能原因：搜索词生成不佳、网页搜索引擎质量差、选择下载文章的环节出错、或最终总结时忽略了信息。
- 分析结果：通过电子表格统计发现，生成搜索词的错误率为 5%，而网页搜索结果的错误率高达 45%。这表明问题主要出在网页搜索引擎本身，而非生成搜索词的 LLM。因此，团队应优先考虑更换或调整搜索引擎，而不是优化提示词。
- 案例：客户邮件响应
- 问题：最终生成的邮件草稿不令人满意。
- 可能原因：LLM 生成的数据库查询语句错误、数据库本身数据损坏、或 LLM 撰写邮件的环节出错。
- 分析结果：统计显示，75% 的问题源于 LLM 生成的数据库查询不正确。这为团队指明了最优先的改进方向。
4. 组件级评估：实现高效的局部优化
在通过错误分析确定了需要改进的关键组件后，建立一个专门针对该组件的评估体系（Component-level Eval）可以显著提高开发效率。
为什么需要组件级评估？
- 信号更清晰： 端到端评估会受到工作流中其他组件随机性的干扰，这可能掩盖你对目标组件所做的微小改进。组件级评估则能提供一个关于该组件性能的、无噪声的直接信号。
- 成本更低、速度更快： 每次调整都运行完整的端到端工作流可能既耗时又昂贵。只评估单个组件则快得多。
- 便于团队协作： 如果不同团队负责不同组件，组件级评估为每个团队提供了明确的、可独立优化的指标。
构建方法（以网页搜索组件为例）
- 定义“黄金标准”： 为一系列查询请求，由专家手动整理出一份“黄金标准网页资源”列表。
- 创建评估指标： 使用信息检索领域的标准指标（如 F1 分数）来衡量搜索组件返回的结果与黄金标准列表的重合度。
- 快速迭代： 利用这个评估体系，开发者可以快速尝试不同的搜索引擎、调整返回结果的数量、限定日期范围等超参数，并立即看到这些改动对搜索质量的影响。
5. 解决已识别问题的策略
一旦定位了问题组件并建立了评估方法，就可以着手进行改进。
改进非 LLM 组件
- 调整参数/超参数： 许多非 LLM 工具都有可调参数，如 RAG 系统中的相似度阈值或分块大小，网页搜索中的返回结果数量等。
- 替换组件： 直接尝试使用不同的工具或服务提供商，例如更换不同的搜索引擎或 RAG 库。
改进基于 LLM 的组件
- 优化提示词（Prompting）：
- 增加明确指令：使指令更加清晰、具体。
- 使用少样本提示（Few-shot Prompting）：在提示词中提供一或多个“输入-期望输出”的示例，引导 LLM 更好地理解任务。
- 尝试不同的 LLM： 不同模型的能力各异。通常，更大、更前沿的模型在遵循复杂指令方面表现更佳。
- 分解任务： 如果一个步骤的指令过于复杂，LLM 可能难以完全遵循。可以将其分解为多个更简单的子步骤，由多个 LLM 调用串联完成。
- 微调（Fine-tuning）模型： 这是一个更复杂且成本更高的选项，通常作为最后的手段。当其他方法都无法将性能提升至所需水平时（例如从 95% 提升到 98%），可以考虑使用自有数据对模型进行微调。
培养对 LLM 的直觉
要高效地选择和使用 LLM，培养关于不同模型能力的直觉至关重要。
- 经常试用新模型： 无论是闭源还是开源模型，都应积极试用，了解其长短。
- 阅读他人的提示词： 通过阅读开源项目、网上分享或与同行交流，学习优秀的提示词编写实践。
- 在工作流中进行实验： 利用评估体系，在自己的应用中系统性地测试不同模型，以了解它们在性能、速度和成本上的权衡。
6. 成本与延迟优化
通常，成本和延迟的优化应在系统输出质量得到保证之后进行。
优化方法论
- 基准测试（Benchmarking）： 对工作流中的每一步进行计时和成本计算，以精确识别瓶颈。
- 延迟： 记录每个组件（如 LLM 调用、API 请求）的平均执行时间。
- 成本： 根据 API 定价（如每 token 费用、每次调用费用）计算每个步骤的平均成本。
- 针对性优化： 根据基准测试结果，将优化精力集中在开销最大的组件上。
- 降低延迟： 可以尝试并行化操作（如同时抓取多个网页），或为耗时长的 LLM 步骤换用更小、更快的模型或响应更快的 API 提供商。
- 降低成本： 在不显著影响质量的前提下，为成本最高的步骤换用更便宜的 LLM 或 API。
7. 完整的开发流程总结
Agentic AI 系统的开发是一个非线性的、在“构建”和“分析”之间不断切换的循环过程。随着系统的成熟，分析的深度和严谨性也在不断提升。
开发阶段的演进：
- 初期： 快速构建端到端系统 -> 手动审查输出和迹线，形成直观感受。
- 发展期： 建立小规模的端到端评估（10-20 个样本） -> 使用量化指标指导系统级和组件级的调整。
- 成熟期： 进行系统的错误分析 -> 精确定位问题组件，制定更有针对性的开发计划。
- 深度优化期： 为关键组件构建组件级评估 -> 实现对特定组件的高效、快速迭代。
一个常见的误区是花费过多时间在“构建”上，而忽视了“分析”。实际上，高质量的分析（如错误分析、评估体系建设）是确保构建工作高效且方向正确的关键。虽然市面上有许多用于监控和日志记录的工具，但由于 Agentic 工作流的高度定制化特性，开发者往往需要构建符合自身应用特定问题的定制化评估方案。