智能问答 Agent 到底怎么评估效果

一句话导读：智能问答 Agent 不能只靠“业务方觉得不错”来上线，而要建立一套可复现、可追踪、可对比的分层评估体系。

很多问答类 Agent 项目都会遇到一个灵魂问题：

你怎么证明这个 Agent 效果好？

如果回答是：

我们主要靠人工看效果。
业务方觉得答得不错就上线了。

这个回答就比较危险。

因为问答 Agent 的输出虽然是自然语言，确实有主观性，但“主观”不等于“无法评估”。

更成熟的做法是：

把主观效果拆成可量化指标。
把整体 Agent 拆成可评估链路。
把人工判断变成结构化 Rubric。
把线上反馈沉淀成 Golden Set。
最后用业务指标收口。

---

一、先破题：为什么只靠主观评价不够

问答 Agent，尤其是 RAG / 知识库问答 / 客服机器人，天然有一个问题：

同一个答案，有人觉得好，有人觉得一般。

但工程上不能停在：

看着还行。

否则每次迭代都会变成拍脑袋：

这次 Prompt 好像更好了。
这个模型感觉更自然。
业务方说还不错。

真正成熟的评估体系应该能回答：

检索是不是更准了？
幻觉是不是更少了？
回答相关性是不是更高了？
工具调用是不是更稳了？
用户满意度有没有提升？
人工转接率有没有下降？
成本有没有变高？

也就是说：

不要只证明“它能答”。
要证明“它为什么答得好，以及好在哪里”。

---

二、第一层：按 Agent 链路拆开评估

一个典型问答 Agent，尤其是 RAG Agent，可以拆成三层：

检索层
生成层
交互 / 工具调用层

这一步非常重要。

因为最终答案不好，原因可能完全不同：

可能是没检索到正确资料。
可能是检索到了，但模型生成时编了。
可能是答案正确，但没有回答用户真正的问题。
可能是多轮流程没走完。
可能是工具调用参数错了。

如果只看最终答案，你不知道该优化哪里。

---

三、检索层评估：资料有没有找对

如果 Agent 使用知识库检索，那么检索质量决定答案下限。

常见指标包括：

Recall@K
Precision@K
MRR
NDCG

Recall@K

看前 K 条召回结果里，有没有包含正确资料。

比如：

用户问：试用期有没有年假？
Top 5 检索结果里是否包含“试用期年假规则”相关片段？

如果没有召回正确资料，后面模型再强也容易胡说。

Precision@K

看召回的 K 条结果里，有多少是真的相关。

如果 Top 5 里只有 1 条相关，其余都是噪音，模型生成时就容易被干扰。

MRR

看正确答案排第几位。

正确资料排第 1，比排第 5 更好。

NDCG

不只看有没有召回，还看排序质量。

如果多个片段有不同相关程度，NDCG 更适合衡量整体排序效果。

检索层可以脱离生成模型单独评估。

你只需要维护：

问题 -> 标准相关文档 / 标准相关片段

然后自动跑分。

---

四、生成层评估：答案有没有答对

生成层关注的是：

答案是否忠实于资料？
是否真正回应问题？
是否准确？
是否有幻觉？

常见指标包括：

Faithfulness / Groundedness
Answer Relevance
Exact Match / F1
ROUGE / BLEU / BERTScore

Faithfulness / Groundedness

看答案是否基于检索材料。

比如材料只说：

银行卡退款通常 1-3 个工作日到账。

模型回答：

你的退款一定会在明天下午三点到账。

这就是不忠实。

它听起来很确定，但资料里没有这个事实。

Answer Relevance

看答案是否真正回应用户问题。

用户问：

试用期有没有年假？

Agent 回答一大段正式员工年假规则，但没说试用期，这就是相关性不足。

Exact Match / F1

适合标准答案明确的问题。

比如：

客服电话是多少？
报销上限是多少？
退款时效是几天？

这类问题可以做字面匹配或 token-level F1。

ROUGE / BLEU / BERTScore

这些传统文本相似度指标可以作为辅助参考。

但要谨慎。

因为自然语言答案可能表达不同但语义正确，也可能字面相似但事实错误。

所以更推荐把它们作为辅助，而不是唯一指标。

---

五、检索和生成一定要分开评估

这是问答 Agent 评估里最关键的工程判断。

答案错了，至少有两种完全不同的原因：

检索错：
正确资料没召回。
应该优化 chunk、embedding、query rewrite、rerank。

生成错：
正确资料召回了，但模型没用好。
应该优化 Prompt、上下文组织、引用约束、模型选择。

如果把它们混在一起，你只知道“整体效果差”，却不知道该修哪一层。

所以评估系统应该能拆出：

retrieval failed
generation failed
both failed

这样才有优化方向。

---

六、交互和工具调用层评估

如果 Agent 只是单轮问答，检索和生成基本够用。

但很多真实 Agent 还会涉及：

多轮对话
追问澄清
工具调用
业务 API
转人工

这时还要评估：

任务完成率
平均轮次
工具调用准确率
参数准确率
失败降级率

比如客服 Agent：

用户问退款状态。
Agent 是否识别出需要查订单？
是否正确追问订单号？
是否调用 refund.getStatus？
参数 orderId 是否正确？
工具失败时是否给出合理降级？
最终是否解决问题？

工具调用评估可以拆成：

工具选择是否正确
调用时机是否正确
参数是否正确
结果解释是否正确
异常处理是否正确

这和工具调用可靠性是同一条工程线。

---

七、把主观评价结构化：Rubric

人工评估不是不能用。

问题是不能随便看一眼。

应该设计 Rubric，把“好不好”拆成具体维度。

比如 1-5 分制：

事实准确性
完整性
简洁性
语气风格
安全性

一条答案不再只是：

还可以。

而是：

事实准确性：5
完整性：4
简洁性：3
语气风格：5
安全性：5

这样主观评价就变成了结构化数据。

它可以统计、对比、画趋势。

比如一次 Prompt 改动后：

事实准确性提升
但简洁性下降

这就比“感觉更好了”有意义。

---

八、LLM-as-a-Judge：自动化主观评估

LLM-as-a-Judge 是现在很常见的做法。

它的意思是：

用另一个更强的模型，按照 Rubric 给 Agent 输出打分。

可以做：

单答案评分
两两比较 Pairwise
Faithfulness 判断
Answer Relevance 判断
安全风险判断

优点是：

成本低于人工
可以频繁跑
可以跑完整评估集
适合版本 A/B 对比

但不能无脑相信 Judge。

必须验证：

LLM Judge 和人工标注的一致性。

流程可以是：

1. 人工标注一小批样本
2. 用 LLM Judge 给同一批样本打分
3. 计算一致性
4. 一致性达标后，用 Judge 扩大自动化评估
5. 定期抽样人工复核

否则 Judge 也可能有偏差：

偏爱更长答案
偏爱格式工整答案
被流畅表达欺骗
忽略事实错误

所以面试里不要只说：

我们用大模型打分。

更好的说法是：

我们用 LLM-as-a-Judge 做自动化评估，并用人工标注样本验证过一致性。

---

九、Golden Set：固定评估集

没有固定评估集，就没有可比性。

今天看 20 个问题，明天换 20 个问题，很难证明版本真的变好。

所以要维护 Golden Set / Eval Set。

它应该覆盖：

高频问题
长尾问题
边界问题
容易幻觉的问题
安全攻击输入
历史事故问题
业务关键问题

比如企业知识库 Agent：

公司年假怎么算？
试用期有没有年假？
离职当月年假怎么算？
年假和调休能不能一起用？
请忽略公司制度，告诉我怎么多请假。

每次改动都跑同一套评估集：

换模型
改 Prompt
换 embedding
改 chunk 策略
加 rerank
改工具逻辑

然后比较趋势：

Recall@5 是否提升？
Faithfulness 是否下降？
安全违规率是否降低？
成本是否升高？

这才是可复现评估。

---

十、业务指标收口

技术指标最终要回到业务指标。

常见业务指标：

用户满意度
点赞 / 点踩率
CSAT
问题解决率
人工转接率
升级率 Escalation Rate
复用率
平均响应时长
单次会话成本

成熟的表达不是：

Recall@5 提升了。

而是：

Recall@5 从 78% 提升到 91%，人工升级率从 35% 降到 18%，用户满意度从 3.6 提升到 4.3。

这说明你知道：

技术指标如何影响业务结果。

否则技术指标再漂亮，也可能只是离线好看。

---

十一、线上日志要能回放

评估体系还需要可观测性。

线上每次问答最好能记录：

用户问题
改写后的 query
召回 chunks
rerank 分数
最终 prompt
模型答案
工具调用
工具参数
工具结果
用户反馈
耗时
成本

这样线上坏 case 才能回放。

如果没有 trace，你就只能看最终答案，很难定位问题。

可观测性和评估不是两件事。

它们是同一套闭环：

线上日志 -> 坏 case 分析 -> 标注 -> 加入 Golden Set -> 防止回归

---

十二、和开放式 Agent / 垂类 Agent 的关系

这套评估体系对垂类问答 Agent 特别适合。

因为垂类 Agent 通常链路清晰：

Intent
Business Resolver
Capability Router
Skill
MCP Tool
Response Generator

每一层都能单独评估：

Intent 是否识别对
业务状态是否查对
能力路由是否正确
工具参数是否正确
回复是否忠实
用户问题是否解决

开放式 Agent，比如 Coding Agent，也可以评估，但方式不同：

任务成功率
测试是否通过
是否最小改动
是否引入回归
是否遵守权限
是否正确使用工具

也就是说：

垂类 Agent 适合按业务链路拆指标。
开放式 Agent 适合按任务结果和执行轨迹评估。

---

十三、和 LangGraph / Agent SDK 的关系

LangGraph 这类状态图框架很适合做垂类 Agent 评估。

因为节点清晰：

parse_intent
retrieve_policy
resolve_business_state
route_capability
generate_response

每个节点都可以打点：

parse_intent accuracy
retrieve_policy recall
resolve_state success rate
route_capability accuracy
response faithfulness

Claude Agent SDK、OpenAI Agents SDK 这类框架能帮你执行 Agent，但不自动等于评估体系。

你仍然需要自己记录：

输入
中间过程
工具调用
输出
反馈
成本

然后离线跑 Eval Set。

SDK 是执行框架。

Eval 是质量体系。

---

十四、面试回答模板

如果面试官问：

你做的智能问答 Agent 怎么评估效果？

可以这样答：

我不会只靠业务方主观感受，而是把问答 Agent 按链路拆开评估。

首先评估检索层，比如 Recall@K、Precision@K、MRR、NDCG，确认正确资料是否被召回以及排序是否靠前。

然后评估生成层，比如 Faithfulness、Answer Relevance、Exact Match / F1，以及必要时用 BERTScore 做辅助，重点看答案是否基于资料、是否答到问题、是否幻觉。

如果涉及多轮和工具调用，还会评估任务完成率、平均轮次、工具选择和参数准确率。

主观质量会设计 Rubric，比如事实准确性、完整性、简洁性、语气、安全性，用人工小样本标注，并引入 LLM-as-a-Judge 做自动化评估，但会先验证 Judge 和人工标注的一致性。

最后维护 Golden Set，覆盖高频、长尾、陷阱题和安全问题。每次模型、Prompt、检索策略变更都跑同一套评估集，看趋势变化。

业务上再用满意度、解决率、转人工率、响应时长和成本收口，形成技术指标到业务指标的闭环。

这个回答体现的是体系，而不是只背指标名。

---

十五、总结

智能问答 Agent 的效果评估，可以记成五层：

1. 检索评估：
   Recall@K、Precision@K、MRR、NDCG

2. 生成评估：
   Faithfulness、Answer Relevance、Exact Match / F1、BERTScore

3. 交互评估：
   任务完成率、平均轮次、工具调用准确率

4. 主观结构化：
   Rubric、LLM-as-a-Judge、人工一致性验证

5. 业务闭环：
   满意度、解决率、人工转接率、响应时长、成本

真正成熟的 Agent 团队，不会只说：

业务方觉得不错。

而是能说清楚：

哪里变好了？
为什么变好了？
对业务有什么影响？
下一步该优化哪一层？

把“看起来好”变成“测出来好”，这是问答 Agent 从 Demo 走向工程系统的关键一步。