一、快速原型和迭代
- 构建"最小可用闭环" ：先构建一个功能完整但尽量简单的原型（哪怕粗糙，也要能端到端跑通）。
- 用真实输入试运行：手动检查最终输出，通过审查追踪和中间输出，找出表现不佳的环节。
- 以观察结果定优先级：用事实驱动后续研发，避免"脑补式优化"。
二、错误分析与评估框架
错误分析
错误分析的核心是观察和量化，以找出工作流程中表现最差的组件。
-
检查追踪（Traces）和中间输出
-
定义：代理在运行过程中，每一步产生的中间输出的整体集合被称为追踪（trace），单个步骤的输出有时被称为 span。
-
方法：查看追踪，观察每个步骤的输出质量，先整体了解哪个组件出了问题。
-
示例：以科研资料查询 Agent 为例
- 步骤 1：生成搜索词——请人类专家判断搜索词是否合理。如果合理，则搜索关键词生成组件没问题。
- 步骤 2：网页搜索结果——检查返回的 URL 和文章质量。如果返回了过多非科学的博客或大众媒体文章，则搜索引擎是问题所在。
- 步骤 3：信息筛选——如果提供给 LLM 的文章有好有坏，但 LLM 选择了其中比较夺人眼球的水文，而非严肃的科研文章，那 LLM 的选型或提示词就是问题所在。
-
-
聚焦错误案例并量化
- 聚焦错误：将精力集中在最终输出不令人满意的少数案例上，而非那些运行良好的案例。
- 建立电子表格进行量化：为了更严谨地分析，可以建立电子表格，明确统计每个组件出现"错误"的频率。
- 错误的定义：某一步的输出明显差于人类专家在给定相同输入时应有的结果。
- 统计示例：记录所有被分析的错误案例中，搜索词不佳的比例、搜索结果不佳的比例等。
- 指导决策：若对搜索结果不满意的频率远高于对搜索词不满意的频率（如 45% vs 5%），工作重点就应放在改进网页搜索引擎或调整其参数上，而非更改搜索词的生成逻辑。
评估技巧
-
从快速而粗糙的评估开始：不要因为觉得评估是大型项目就不敢轻易建立，或花漫长的时间做理论调研。先用 10-20 个例子快速获得指标，辅助人工观察。
-
迭代改进评估：随着系统和评估的成熟，可增加评估集规模。若系统改进了但评估分数未提高，意味着需要改进评估本身。
-
评估模式（LLM 辅助评估 vs 人工校准评估） ：
- 对于答案唯一或有固定格式的场景（如发票日期提取），可通过人工标注真实值，使用代码和正则等方式验证准确性。
- 对于答案开放的场景（如文章观点提取），使用 LLM 作为裁判，通过统计观点覆盖率或打分的方式进行评估。
-
以专业人士的行为为灵感：对于自动化人类任务的系统，观察系统在哪些方面性能不如人类专家，以此作为下一阶段工作的重点。
三、系统性优化方法
优化 LLM 组件
-
改进提示词
- 增加明确指令：在提示词中指明资源和任务应有的规划路径，而非让 LLM 自行猜测。
- 使用少样本提示：添加具体的输入和期望输出示例。
-
尝试不同的 LLM：不要嫌麻烦，多测试几款 LLM，并使用评估（Evals）选择最适合特定应用的最佳模型。
-
任务分解：若单个步骤的指令过于复杂，导致 LLM 难以准确执行，考虑将任务分解为更小、更易于管理的步骤，例如拆分为生成步骤 + 反思步骤，或进行多次连续调用。
-
微调模型：这是最复杂、成本最高的选项。只有在穷尽其他方法后，仍需挤出最后几个百分点的性能改进时才考虑。它适用于更成熟且性能要求极高的应用。
优化非 LLM 组件
非 LLM 组件主要指网页搜索、RAG 检索、代码执行等。
-
调整参数或超参数
- 网页搜索：调整结果数量、日期范围等。
- RAG 检索：更改相似度阈值、文本分块大小等。
- 人物检测：调整检测阈值，权衡误报与漏报。
-
替换组件：尝试更换不同服务提供商，如不同的 RAG 搜索引擎、不同的 Web 搜索 API，找到最适合系统的方案。按笔者经验，在国内查询企业营收报表和财务信息时，百度搜索效果远超 Bing 或 Google；但查询学术资源时情况则完全相反。
优化延迟与速度
-
计时分析：详细记录工作流程中每个步骤所花费的时间（例如：LLM 1 耗时 7 秒，LLM 3 耗时 18 秒）。
-
定位瓶颈：通过时间线分析，确定耗时最长的组件，从而找到最大的提速空间。
-
优化手段：
- 并行化：考虑将网页抓取等可独立进行的步骤并行执行。
- 更换 LLM：尝试使用更小、更快（尽管可能稍不智能）的模型，或测试不同的 LLM 提供商，以找到返回 token 最快的服务。
优化成本
-
成本计算：计算工作流程中每个步骤的平均成本
- LLM：按输入和输出的 Token 长度收费。
- API：按调用次数收费。
- 计算/服务：根据服务器容量、服务费等计算。
-
定位瓶颈：确定成本贡献最大的组件。
-
优化手段：寻找更便宜的组件或 LLM 替代高成本组件，以最大化成本优化效果。
参考资料：
