4.6 解决识别到的问题

在跑了评估，找到问题后，就要开始着手修改了。本节介绍的正是如何改善系统中不同组件的效果。

对于非 LLM 组件，比如网页搜索、RAG 检索、代码执行、传统 ML 模型来说，改进方式非常多样。

• 调整参数或超参数：
  • 网页搜索： 调整结果数量、日期范围等。
  • RAG 检索： 更改相似度阈值、文本分块大小等。
  • 人物检测： 调整检测阈值，以权衡误报和漏报。
• 替换组件： 尝试更换不同的服务提供商，如不同的 RAG 搜索引擎、不同的 Web 搜索 API找到最适合系统的一个。按笔者经验，在国内查询企业营收报表和财务信息，使用百度搜索的效果就远超Bing或Google，但查询学术资源却完全相反。

对于LLM 组件，改进主要围绕输入、模型本身和工作流程结构展开。

• 改进提示词：增加明确指令（在提示词中指明一些资源和任务应有的规划路径，而不是让LLM自己猜）；使用少样本提示 (添加具体的输入和期望输出示例)
• 尝试不同的 LLM： 不要嫌麻烦，多测试几款 LLM，并使用评估 (Evals) 来选择最适合特定应用的最佳模型。
• 任务分解：如果单个步骤的指令过于复杂，导致 LLM 难以准确执行，考虑将任务分解为更小的、更易于管理的步骤，比如拆成生成步骤 + 反思步骤，或连续多次调用。
• 微调模型：这是最复杂、成本最高的选项。只有在穷尽所有其他方法后，仍需要挤出最后几个百分点的性能改进时才考虑。它适用于更成熟且性能要求极高的应用。

如果你之前也做过类似工作，那你一定拥有一定程度的模型选择直觉

拥有对不同 LLM 能力的直觉，能使开发者更高效地选择模型和编写提示词。这样的直觉要如何培养？

1. 频繁试玩不同模型： 经常测试新的闭源和开源模型，观察它们在不同查询上的表现。

2. 建立个人评估集： 使用一套固定的评估任务来校准不同模型的能力。

3. 阅读他人的提示词： 大量阅读从业者、专家或开源框架中的提示词，了解不同任务/模型/场景下的最佳实践，提高自己编写提示词的能力。

4. 在工作流程中尝试： 实际在Agent工作流程中尝试不同的模型，查看追踪 (Traces) 和组件/端到端评估，观察它们在特定任务中的性能、价格和速度的权衡。