声明本篇博客是以吴恩达的【Agent智能体】教程为基础并对其中的内容做了笔记整理以及个人收获的总结。问题引入你应该把精力集中在哪些方面来优化工作流程答案衡量团队效率和水平的最大指标之一就是他们是否能够有条不紊地进行错误分析从而指导你将精力集中在最关键的地方。所以这篇文章主要讲解的是如何进行错误分析。先看一个例子例子Research Agent研究智能体这个评估结果表展示了智能体在处理不同 Prompt提示词时的表现和存在的 Issues问题黑洞科学研究漏掉了近期新闻大量报道的高调研究成果。西雅图租房vs买房表现得还不错。水果采摘机器人没有提到该领域的领先设备公司。结论智能体“有时会遗漏人类本应指出的关键信息”。这构成了错误分析的表象——我们知道结果不完美但还不知道问题出在哪一步。针对上一张图中发现的“遗漏信息”问题这张图提出了具体的假设性归因Possible causes。将整体的失败拆解到了工作流的每一个节点上Bad search terms?搜索词太差是不是第一个 LLM 提取的搜索关键词不够精准导致一开始方向就错了Low quality search results?搜索结果质量低是不是搜索 API 本身返回的结果就不包含那些重要信息Poor selection of sources?信息源筛选不佳是不是搜索结果里其实有重要信息但在“挑选最好的 5 个来源”时LLM 把关键文章漏掉了Bad reasoning over texts?文本推理能力差是不是关键文章都被正确抓取了但在最后一步“写草稿”时LLM 没能理解或总结出重点“Examine traces to better understand each step in the workflow”检查运行轨迹以更好地理解工作流中的每一步有些团队会凭借直觉选择其中一个环节来优化跟改进其实更好的方法是进行错误分析深入理解工作流程中的每一步可以经常检查模型的推理过程记录也就是每一步之后的中间输出结果跟debug差不多 这样可以判断哪个环节的表现不佳。下面看一个例子检查运行轨迹Looking at traces术语理解所有中间步骤的整体输出集合通常被称为该智能体运行的“追踪Trace”单步输出有时候被称为“跨度Span”检查每一个步骤第一步LLM 生成搜索词 (灰色框)日志显示模型生成了 “Black hole theories Einstein”、“New physics black holes” 等词。诊断没有明显的逻辑错误。第二步执行网页搜索 (绿色框) —— 问题日志显示搜索引擎返回的结果是“小学生破解了30年的黑洞谜题来自 astrokidnews.com 星际儿童新闻”还有“Bob Lee在院子里看到天空有亮光…”。诊断这里的搜索结果质量极差Low quality search results。系统抓取到了大量不靠谱的八卦新闻、儿童读物或个人博客根本没有触及真正的科学前沿报道。第三步筛选最佳信息源 (灰色框) —— 问题日志显示负责“挑选5个最佳来源”的 LLM竟然把这些极其离谱的网址比如spacefunnews.com太空趣味新闻、astronautme.com作为权威资料挑了出来。诊断信息源筛选逻辑Poor selection of sources也存在大问题。大模型没有能力辨别哪些是学术期刊哪些是地摊文学。这样我们就可以得出结论如果你只看最终输出的文章你可能会觉得“这个写文章的大模型太笨了连近期大热的黑洞新闻都不知道”。但看了 Trace 之后你立刻就能知道根本不是最后一步写文章的模型不行而是它吃进去的“食材”全是垃圾Garbage in, garbage out。后续优化的优先级立刻就清晰了限制搜索源不要用通用的 Google 搜索而是让web search工具专门去检索 arXiv、Nature、Science 等学术网站或主流新闻媒体。优化筛选 Prompt在“挑选5个最佳来源”那一步强烈要求 LLM 过滤掉非学术后缀或名字看起来像娱乐新闻的网站。这张图生动地说明了直觉往往会骗人只有深入查看 Trace才能找到真正的 Bug 所在。建一个表格统计错误发生的位置这叫做基于数据的错误量化分析 (Quantitative Error Analysis)。我们来拆解这张图1.建立错误矩阵 (Error Matrix)图中的表格不再是单次运行的记录而是一个综合的测试评估表每一行 (Rows)代表测试集里的一个具体 Prompt测试用例。每一列 (Columns)依然代表工作流中的各个独立步骤搜索词生成、获取搜索结果、挑选最佳信息源等。单元格内容记录了在批量跑测试时每个用例具体是在哪一步出现问题的以及具体原因。比如“黑洞科学”这一行错误出在【搜索结果】列原因是“博客太多学术论文太少”。比如“水果采摘机器人”在【搜索词】列就出错了词太宽泛导致【搜索结果】列也错了搜出了小学生网站。2.图表底部的数字这张图最有价值的信息是表格底部红色的百分比5%, 45%, 10%…这是将成百上千个测试用例跑完后统计出的各步骤总体错误率【生成搜索词】环节只占了总错误的5%。【获取搜索结果】环节居然占了总错误的45%【挑选 5 个最佳来源】占了10%。3.这张图带来的巨大工程价值指明优化方向在软件工程和 AI 开发中资源算力、人力、时间永远是有限的。这张图完美解决了团队开会时最常争吵的问题“我们接下来该优化哪里”看完这个统计图结论呼之欲出绝对不要把时间浪费在去抠“生成搜索词”的 Prompt 上了它只占 5% 的问题甚至也不用急着去优化“挑选来源”的模型。目前整个系统的最大瓶颈Bottleneck在【获取搜索结果】这一步45%团队接下来的 Action Item行动计划立刻就明确了是不是用的搜索引擎 API 不对比如把通用的 Bing Search 换成 Google Scholar 或专门的学术 API。是否需要在搜索工具里强制加上限定词过滤器比如过滤掉.com域名只留.edu或.org。是否需要引入混合检索Hybrid Search或者 RAG 技术来提升召回质量总结这三张图连在一起构成了一个极具专业水准的大模型 Agent 开发方法论直观感知发现最终结果不好。微观定性Trace拆解工作流深入查看单次调用的中间结果弄清错误是如何发生的。宏观定量Counting Errors批量运行测试统计各环节的错误比例找出最大瓶颈集中火力进行优化。错误分析的建议Develop a habit of looking at traces养成查看运行轨迹的习惯不要只看最终结果要习惯性地去翻看系统运行的中间日志Traces。解析这是解决“黑盒化”的第一步。就像我们前面看的第二张图一样只有打开 Trace你才能看到模型到底生成了什么搜索词、外部工具返回了什么原始数据。这要求开发者在搭建 Agent 时必须接入日志监控工具如 LangSmith 等让每一次调用都“有迹可循”。Carry out error analysis to figure out what component performed poorly, leading to a poor final output进行错误分析找出导致最终输出不佳的具体组件当结果很差时要顺藤摸瓜找出到底是哪一个特定的步骤组件掉了链子。解析这一步强调的是“定位根因”。因为在复杂的工作流中错误是会放大的级联错误。最终文章写得烂可能不是因为负责写文章的 LLM 差而是因为第一步的检索工具给了一堆垃圾信息。必须精准定位到具体的“案发地点”。Use error analysis output to decide where to focus efforts利用错误分析的结果决定将精力集中在哪里根据你统计出来的错误数据来决定接下来的开发工作该把时间花在哪个环节上。解析这完美对应了我们刚才那张“统计错误率 (45%, 10%, 5%)”的表格开发资源时间和算力是宝贵的你要把精力投入到 ROI投资回报率最高的地方。如果数据告诉你 45% 的错误都来自“搜索结果质量低”那你就应该把整个团队的精力都放在优化搜索引擎上而不是去瞎调其他环节的代码。总结这三条建议构建了一个闭环看日志 - 定位错误组件 - 集中火力解决最大痛点。如果这篇文章对你有帮助欢迎点赞、评论、关注、收藏。你们的支持是我前进的动力
【Agent智能体19 | 构建AI工作流的技巧-错误分析】
声明本篇博客是以吴恩达的【Agent智能体】教程为基础并对其中的内容做了笔记整理以及个人收获的总结。问题引入你应该把精力集中在哪些方面来优化工作流程答案衡量团队效率和水平的最大指标之一就是他们是否能够有条不紊地进行错误分析从而指导你将精力集中在最关键的地方。所以这篇文章主要讲解的是如何进行错误分析。先看一个例子例子Research Agent研究智能体这个评估结果表展示了智能体在处理不同 Prompt提示词时的表现和存在的 Issues问题黑洞科学研究漏掉了近期新闻大量报道的高调研究成果。西雅图租房vs买房表现得还不错。水果采摘机器人没有提到该领域的领先设备公司。结论智能体“有时会遗漏人类本应指出的关键信息”。这构成了错误分析的表象——我们知道结果不完美但还不知道问题出在哪一步。针对上一张图中发现的“遗漏信息”问题这张图提出了具体的假设性归因Possible causes。将整体的失败拆解到了工作流的每一个节点上Bad search terms?搜索词太差是不是第一个 LLM 提取的搜索关键词不够精准导致一开始方向就错了Low quality search results?搜索结果质量低是不是搜索 API 本身返回的结果就不包含那些重要信息Poor selection of sources?信息源筛选不佳是不是搜索结果里其实有重要信息但在“挑选最好的 5 个来源”时LLM 把关键文章漏掉了Bad reasoning over texts?文本推理能力差是不是关键文章都被正确抓取了但在最后一步“写草稿”时LLM 没能理解或总结出重点“Examine traces to better understand each step in the workflow”检查运行轨迹以更好地理解工作流中的每一步有些团队会凭借直觉选择其中一个环节来优化跟改进其实更好的方法是进行错误分析深入理解工作流程中的每一步可以经常检查模型的推理过程记录也就是每一步之后的中间输出结果跟debug差不多 这样可以判断哪个环节的表现不佳。下面看一个例子检查运行轨迹Looking at traces术语理解所有中间步骤的整体输出集合通常被称为该智能体运行的“追踪Trace”单步输出有时候被称为“跨度Span”检查每一个步骤第一步LLM 生成搜索词 (灰色框)日志显示模型生成了 “Black hole theories Einstein”、“New physics black holes” 等词。诊断没有明显的逻辑错误。第二步执行网页搜索 (绿色框) —— 问题日志显示搜索引擎返回的结果是“小学生破解了30年的黑洞谜题来自 astrokidnews.com 星际儿童新闻”还有“Bob Lee在院子里看到天空有亮光…”。诊断这里的搜索结果质量极差Low quality search results。系统抓取到了大量不靠谱的八卦新闻、儿童读物或个人博客根本没有触及真正的科学前沿报道。第三步筛选最佳信息源 (灰色框) —— 问题日志显示负责“挑选5个最佳来源”的 LLM竟然把这些极其离谱的网址比如spacefunnews.com太空趣味新闻、astronautme.com作为权威资料挑了出来。诊断信息源筛选逻辑Poor selection of sources也存在大问题。大模型没有能力辨别哪些是学术期刊哪些是地摊文学。这样我们就可以得出结论如果你只看最终输出的文章你可能会觉得“这个写文章的大模型太笨了连近期大热的黑洞新闻都不知道”。但看了 Trace 之后你立刻就能知道根本不是最后一步写文章的模型不行而是它吃进去的“食材”全是垃圾Garbage in, garbage out。后续优化的优先级立刻就清晰了限制搜索源不要用通用的 Google 搜索而是让web search工具专门去检索 arXiv、Nature、Science 等学术网站或主流新闻媒体。优化筛选 Prompt在“挑选5个最佳来源”那一步强烈要求 LLM 过滤掉非学术后缀或名字看起来像娱乐新闻的网站。这张图生动地说明了直觉往往会骗人只有深入查看 Trace才能找到真正的 Bug 所在。建一个表格统计错误发生的位置这叫做基于数据的错误量化分析 (Quantitative Error Analysis)。我们来拆解这张图1.建立错误矩阵 (Error Matrix)图中的表格不再是单次运行的记录而是一个综合的测试评估表每一行 (Rows)代表测试集里的一个具体 Prompt测试用例。每一列 (Columns)依然代表工作流中的各个独立步骤搜索词生成、获取搜索结果、挑选最佳信息源等。单元格内容记录了在批量跑测试时每个用例具体是在哪一步出现问题的以及具体原因。比如“黑洞科学”这一行错误出在【搜索结果】列原因是“博客太多学术论文太少”。比如“水果采摘机器人”在【搜索词】列就出错了词太宽泛导致【搜索结果】列也错了搜出了小学生网站。2.图表底部的数字这张图最有价值的信息是表格底部红色的百分比5%, 45%, 10%…这是将成百上千个测试用例跑完后统计出的各步骤总体错误率【生成搜索词】环节只占了总错误的5%。【获取搜索结果】环节居然占了总错误的45%【挑选 5 个最佳来源】占了10%。3.这张图带来的巨大工程价值指明优化方向在软件工程和 AI 开发中资源算力、人力、时间永远是有限的。这张图完美解决了团队开会时最常争吵的问题“我们接下来该优化哪里”看完这个统计图结论呼之欲出绝对不要把时间浪费在去抠“生成搜索词”的 Prompt 上了它只占 5% 的问题甚至也不用急着去优化“挑选来源”的模型。目前整个系统的最大瓶颈Bottleneck在【获取搜索结果】这一步45%团队接下来的 Action Item行动计划立刻就明确了是不是用的搜索引擎 API 不对比如把通用的 Bing Search 换成 Google Scholar 或专门的学术 API。是否需要在搜索工具里强制加上限定词过滤器比如过滤掉.com域名只留.edu或.org。是否需要引入混合检索Hybrid Search或者 RAG 技术来提升召回质量总结这三张图连在一起构成了一个极具专业水准的大模型 Agent 开发方法论直观感知发现最终结果不好。微观定性Trace拆解工作流深入查看单次调用的中间结果弄清错误是如何发生的。宏观定量Counting Errors批量运行测试统计各环节的错误比例找出最大瓶颈集中火力进行优化。错误分析的建议Develop a habit of looking at traces养成查看运行轨迹的习惯不要只看最终结果要习惯性地去翻看系统运行的中间日志Traces。解析这是解决“黑盒化”的第一步。就像我们前面看的第二张图一样只有打开 Trace你才能看到模型到底生成了什么搜索词、外部工具返回了什么原始数据。这要求开发者在搭建 Agent 时必须接入日志监控工具如 LangSmith 等让每一次调用都“有迹可循”。Carry out error analysis to figure out what component performed poorly, leading to a poor final output进行错误分析找出导致最终输出不佳的具体组件当结果很差时要顺藤摸瓜找出到底是哪一个特定的步骤组件掉了链子。解析这一步强调的是“定位根因”。因为在复杂的工作流中错误是会放大的级联错误。最终文章写得烂可能不是因为负责写文章的 LLM 差而是因为第一步的检索工具给了一堆垃圾信息。必须精准定位到具体的“案发地点”。Use error analysis output to decide where to focus efforts利用错误分析的结果决定将精力集中在哪里根据你统计出来的错误数据来决定接下来的开发工作该把时间花在哪个环节上。解析这完美对应了我们刚才那张“统计错误率 (45%, 10%, 5%)”的表格开发资源时间和算力是宝贵的你要把精力投入到 ROI投资回报率最高的地方。如果数据告诉你 45% 的错误都来自“搜索结果质量低”那你就应该把整个团队的精力都放在优化搜索引擎上而不是去瞎调其他环节的代码。总结这三条建议构建了一个闭环看日志 - 定位错误组件 - 集中火力解决最大痛点。如果这篇文章对你有帮助欢迎点赞、评论、关注、收藏。你们的支持是我前进的动力
