评估与测试 (Evaluation)

Agent 最大的麻烦，不是它偶尔答错，而是它的错误很难用传统软件测试那一套完全兜住。

昨天还能跑通的流程，今天可能因为：

• prompt 改了一句
• 检索结果顺序变了
• 模型版本升级了
• 工具响应结构变了

整条链路的行为就跟着飘。只要你准备把 Agent 真正推向生产环境，评估体系就不是可选项，而是上线前的基本盘。

#1. 为什么普通 Unit Test 不够

传统单元测试擅长验证确定性逻辑：

assert add(1, 1) == 2

但 Agent 的问题在于，很多关键输出不是确定字符串，而是“语义上对不对”“步骤上对不对”“有没有用错工具”“有没有乱编”。

所以你会发现，单纯断言最终文本往往不够。评估 Agent 时，通常至少要拆成几层：

• 最终答案是否合理
• 中间工具调用是否正确
• 检索结果是否相关
• 结构化输出是否符合协议

#2. LLM-as-a-Judge：为什么大家最后都会用它

很多输出没法靠字符串精确匹配判断，只能让另一个模型来做近似裁判。

这就是 LLM-as-a-Judge 的核心思路：不是判断“字面一不一样”，而是判断“意思是不是对上了”。

#示例：评估客服回答的准确性

输入：

• Question: "如何重置密码？"
• Ground Truth (标准答案): "点击登录页的'忘记密码'链接。"
• Agent Answer: "亲，您可以在登录页面找到忘记密码的按钮哦。"

裁判 Prompt:

"请对比 Agent Answer 和 Ground Truth。虽然措辞不同，但核心语义是否一致？如果是，输出 1，否则输出 0。"

#3. RAGAS：做 RAG 时很常用的一套指标

RAG 系统最常见的问题，不只是答错，而是“看起来答得很像对，但其实没基于检索内容”。RAGAS 这类框架之所以有价值，就是因为它把这些模糊问题拆成了可评分的维度。

1. Faithfulness (忠实度): 回答是否完全基于检索到的 Context？（检测幻觉）
2. Answer Relevance (回答相关性): 回答是否解决了用户的问题？
3. Context Precision (上下文精确度): 检索到的文档中有多少是有用的？

#使用 RAGAS（Python）

python复制
from ragas import evaluate
from ragas.metrics import faithfulness, answer_relevancy
from datasets import Dataset

data = {
    'question': ['How to reset password?'],
    'answer': ['Go to login page and click forgot password.'],
    'contexts': [['Reset password guide: 1. Go to login...']],
    'ground_truth': ['Click forgot password on login screen.']
}

dataset = Dataset.from_dict(data)

results = evaluate(
    dataset = dataset,
    metrics = [faithfulness, answer_relevancy]
)

print(results)
# {'faithfulness': 0.99, 'answer_relevancy': 0.95}

#4. 建立回归测试集（Golden Dataset）

如果你只靠“我手动问了几个问题，感觉还行”，那基本挡不住回归。

更靠谱的做法，是维护一套黄金数据集。它不一定要很大，但必须覆盖真实高频场景，比如：

• 最常见的用户问题
• 最容易误答的边界问题
• 历史上真的翻过车的问题
• 权限、拒答、异常路径这类非 happy path

每次改 Prompt、改工具、换模型、调检索参数，都跑一遍。这样你至少知道系统是变好了，还是只是“看起来更会说了”。

一个实用的经验是：

• 小系统先从 20 到 30 条核心样本开始
• 稳定以后再慢慢扩到 100 条以上
• 每次线上出新问题，就回灌进测试集

这样黄金数据集才会越来越像你的真实业务。

#5. 评估不要只看最终答案

这是很多团队最容易犯的错误。

如果你只看最终 answer，很可能错过中间链路的问题。更完整的评估通常会分成几类：

#输出层评估

• 最终回答是否正确
• 语气和格式是否符合要求
• 有没有越权内容

#过程层评估

• 工具调用顺序是否合理
• 是否调用了不该调用的工具
• 重试次数是否异常

#检索层评估

• 召回内容相关不相关
• 正确片段有没有排到前面
• 回答有没有真的引用到召回内容

#业务层评估

• 有没有影响真实用户体验
• 是否会触发错误流程
• 成本和延迟是否可接受

这几层拆开以后，定位问题会快很多。

#6. 一个更接近生产环境的评估流程

如果你准备把 Agent 做上线，我更建议把评估流程做成固定动作：

1. 离线跑黄金数据集
2. 看结构化指标，例如准确率、faithfulness、工具错误率
3. 抽样人工复核高风险案例
4. 小流量放量
5. 持续收集线上失败案例，回灌测试集

这套流程并不花哨，但非常实用。很多 Agent 系统最后不稳定，不是因为缺一个新框架，而是因为根本没有持续评估闭环。

#小结

Evals 最核心的价值，不是让你得到一个漂亮分数，而是让系统迭代时有抓手。

• 没有评估，你改 prompt 基本就是碰运气
• 只有最终答案评估，不足以定位链路问题
• 黄金数据集和线上失败回灌，才会让系统越来越稳

Agent 这类系统想摆脱“炼丹感”，靠的基本就是评估体系。