【Agent智能体20 | 构建AI工作流的技巧-组件级评估】
声明：本篇博客是以吴恩达的【Agent智能体】教程为基础，并对其中的内容做了笔记整理以及个人收获的总结。
经常使用错误分析法，但当做出一些判断之后，我们会发现除了端到端的评估之外，通常还需要评估整个端到端系统之外的各个独立的组件，这样可以更高效的改进那些通过错误分析你决定要重点关注的组件，这一篇就是要介绍“组件级评估”
例子：Research Agent（依旧研究智能体的例子）
“端到端评估”的意思是：只看最终产出的“初稿”质量来评判整个系统的好坏。
这个研究智能体有时候会遗漏关键信息，但是如果问题出现在网页搜索，那么每次更换网页搜索引擎时，都需要重新运行整个工作流程，这样可以获得不错的性能指标，但是这种评估方式成本较高。
假设你在测试图中表格里的第一个问题（关于黑洞科学），发现最终生成的文章“遗漏了关键信息”。你怀疑是因为“网页搜索”这个环节用的搜索引擎不够好，想要换一个试试。
如果在“端到端”模式下测试，你每次更换搜索引擎，都要把后续的“提取资料（Fetch 5 best sources）”和“写初稿（Write essay draft）”全部重新跑一遍。这意味着你要为后续所有无关模块的 LLM API 调用（Token消耗）买单，不仅浪费金钱，还非常耗时。
此外这个工作流很复杂即使网页搜索稍有提升，其他组件的随机性可能会引入噪声，这会让网页搜索质量小幅提升难以察觉。
这是多步 LLM 工作流中最容易出现的问题，被称为级联误差（Cascading Errors）与随机性噪声：
- 多环节的随机性：大模型本身的输出具有一定的随机性。
- 信号被掩盖：假设你通过优化搜索词或者更换搜索引擎，让“网页搜索”的准确率提升了 5%（这通常是个不错的微小进步）。但是，到了最后一步负责写初稿的 LLM 那里，如果它这次恰好“发挥失常”（由于大模型的随机性），最终写出来的文章依然很差。
- 错误归因：你看了一眼最终糟糕的文章，就会错误地认为“我刚才对搜索引擎的优化是没有效果的”。这就是文中提到的“其他组件的随机性引入了噪声，让网页搜索的小幅提升难以察觉”。
一种更好的工程实践是这样的：不应该只依赖端到端评估，而应该引入“组件级评估（单元测试）”。因此除了只用端到端评估外，可以专门为网页搜索组件构建评估方法：
为网页搜索组件构建评估方法
“Evaluate web search tool only”（仅评估网页搜索工具）
- 意味着在测试时，我们切断了后续所有的 LLM 步骤（不提取最佳来源，也不写初稿）。只要网页搜索一出结果，我们就直接对这个结果进行评分。这样彻底避免了后续 LLM 随机性带来的“噪声”，同时也大大节省了 token 成本
如何进行具体的评估？（三个要点）
步骤一：Create a list of gold standard web resources（建立一份权威网页资源清单）
- 对于测试集里的每一个问题（比如“最近的黑洞科学研究”），人类专家需要提前人工搜索并确认，哪些网址是最高质量、最权威的答案来源。这些被人工确认的优质网址就是所谓的“黄金标准”（Ground Truth / 真实标签）。
步骤二：Write code that calculates how many results correspond to gold standard websites e.g. F1-score（编写代码计算命中率，例如使用 F1 分数）
- 当你的智能体执行搜索时，它会返回一堆网页链接。此时，不需要让人或者大模型去读这些链接，而是直接写一段简单的代码，对比“智能体搜出的链接”和“黄金标准链接库”的重合度。
- F1-score：这是一个机器学习中常用的准确度指标。它综合考量了“搜出来的链接里有多少是对的”以及“黄金标准里有多少被成功搜出来了（召回率）”。这个过程是纯代码比对，速度极快且成本几乎为零。
步骤三：Track as you vary hyperparameters…（在调整超参数时追踪评估结果）
- 解释：既然现在我们有了一个快速、便宜且客观的评分标准（F1分数），我们就可以放开手脚去优化这个组件了。
- 你可以随意更改“超参数（hyperparameters）”，比如：把搜索引擎从 Google 换成 Bing、修改返回的搜索结果数量（比如从只看前5条改为看前10条）、或者添加时间限制（只搜最近一年的新闻）。
- 每次修改后，跑一遍自动化测试，看看 F1 分数是上升了还是下降了。这样就能精准、清晰地感知到每一次微小优化带来的实际提升。
在宣布任务完成之前，建议再进行一次端到端评估，确保在优化网页搜索系统一段时间之后，确实提升了整体系统的性能，但程遂步调整这些参数的过程中，可以只评估单个组件，而不是反复的端到端评估。
总结：组件级评估（Component-level evaluations）的优势
- 提供更清晰的错误信号，避免系统“噪声”（Can provide clearer signal for specific errors (Avoid the noise in end-to-end system)）
- 当你在传统的“端到端”测试中发现最终生成的文章质量很差时，你很难立刻搞清楚到底是哪一步出了问题——是 LLM 生成的搜索词不好？是搜索引擎返回的结果太差？还是最后润色文章的 LLM 产生了幻觉？这就是所谓的“系统噪声”，其他模块的随机性掩盖了真正的问题所在。
- 而采用“组件级评估”后，如果你单独测试“网页搜索”模块，一旦评分（比如 F1 分数）下降，你能100% 确定就是搜索环节或者你调整的搜索参数出了问题。
- 让团队更高效地进行针对性优化（More efficient for focused team to optimize (Work on smaller, more targeted problems faster)）
- 复杂的智能体工作流往往需要团队协作。如果每次测试都必须跑通整个流程，不仅耗时耗钱，还会导致开发瓶颈（比如负责搜索的工程师必须等负责写作的工程师把代码调通才能测试）。
- 有了“组件级评估”，庞大的工程可以被拆解。团队可以分工合作：一组人专门优化“搜索工具”，另一组人专门优化“文本总结”。他们可以各自对着自己模块的测试集和脚本进行高频测试，不需要依赖其他模块的运行。这种将大目标拆解为“更小、更有针对性的问题”的做法，能够大幅提升团队的迭代和研发速度。
思考：如何将这个组件真正的变得更好，下一篇会详细介绍！
如果这篇文章对你有帮助，欢迎点赞、评论、关注、收藏。你们的支持是我前进的动力！