第 8 章:评估:调研类任务没标准答案,怎么定义「好」
讲清调研型 Agent 为什么难评估、要评什么(结果质量 + 过程质量)、LLM-as-a-Judge 怎么用又有哪些坑,以及怎么防止「刷分」、怎么把评估结果回流到训练形成闭环
📊 学习时长:60-75 分钟 🎯 完成后能力:讲清调研型 Agent 为什么难评估、要评什么(结果质量 + 过程质量)、LLM-as-a-Judge 怎么用又有哪些坑,以及怎么防止「刷分」、怎么把评估结果回流到训练形成闭环 🔗 关联面试题:5 道(覆盖 5 个角度,见 Part 3)
🧭 这是最后一块拼图:前面把 Agent 从「为什么」一路做到「上线」,但有个问题一直没正面回答:怎么知道它做得好不好? 调研类任务没有唯一标准答案,这让评估格外难。本章就把评估的原理、方法、陷阱讲透。
这一章你会学到什么
- ✓ 想清一个根本难题:分类任务有标准答案,调研报告这种开放任务「好」在哪、怎么量
- ✓ 搞懂评估的两个层面:结果质量(对不对、有没有幻觉)和过程质量(步骤合不合理)
- ✓ 掌握 LLM-as-a-Judge:用强模型当裁判怎么打分、它有哪些偏见(位置 / 长度 / 自我偏好)、怎么缓解
- ✓ 理解评估最大的陷阱:Goodhart 定律(指标一旦成为目标就会被刷),以及怎么防
- ✓ 建立「评估 → 训练」的闭环视角:评估发现的弱点,正是下一轮补数据、重训的方向
本章按三段式组织:
段落 给谁看 内容 占比 🚀 Part 1 · 主线实战 零基础,想先看懂 为什么难评估 + 评什么 + rubric 打分小实验 ~45% 🎯 Part 2 · 面试深度 想讲透、备战面试 LLM-as-a-Judge / 偏见 / 基准 / 防刷分 / 评估闭环 + 私货 ~45% 🏆 Part 3 · 验收串题 检验学到位没 关联面试题 + 自检清单 ~10%
🚀 Part 1 · 主线实战 ｜ ~45% 这部分先想清「为什么调研任务难评估」,再用一个零依赖小实验,看懂怎么把「主观感觉」变成「结构化分数」。
先讲个真实场景(这是本章的「为什么」)
Agent 上线了,有人问你:「它做得好不好?」你怎么回答?
如果是分类任务,简单:有标准答案,算个准确率就行。但调研型 Agent 面对的是**「中小规模 RAG 项目,向量库选 Milvus、Qdrant 还是 pgvector」这种开放问题,它产出的是一份几百字、带十几条引用的选型报告**。这份报告好不好?
没有唯一标准答案。两份结论相近的报告,可能一份引用扎实、一份在编数据;一份覆盖全面、一份漏了关键维度(比如只比性能,没提运维成本)。「跑通了」不等于「做得好」,流畅漂亮的报告可能恰恰在一本正经地胡说。
更麻烦的是:调研是个多步过程,光看最终报告还不够,中间「该不该多查一步、有没有交叉验证」的过程质量也得评。
评估难,但不评估更危险:你根本不知道改一版到底是变好还是变坏,优化就成了盲人摸象。本章讲的就是:怎么给这种开放任务,建立一套靠谱的评估。
概念:评估两个层面(结果质量 + 过程质量)
调研 Agent 的评估,要同时看「交出来的东西」和「怎么做出来的」:
- 结果质量(评最终报告):答案正确性、引用准确性(说的有没有出处、出处对不对)、覆盖全面性、有没有幻觉(编造事实)、结构可读性。
- 过程质量(评调研轨迹):步骤是否合理、有没有该查不查 / 反复空查、工具用得对不对、效率高不高。
两个层面缺一不可:只看结果,你不知道它是「真调研出来的」还是「蒙对的」;只看过程,你不知道它最后给的东西到底对不对。
🛠️ 跟着做:一个零依赖的 rubric 打分小实验
开放质量没法「一个数」搞定,但可以拆成多个维度、各给权重、加权汇总,把「主观感觉」变成「结构化分数」。这正是后面 LLM-as-a-Judge 的打分逻辑(只是这里我们手填分,看清机制)。新建 rubric_score.py:
# 零依赖,演示「把一份开放式调研报告的质量,从主观感觉变成结构化分数」
# 4 个评估维度,各有权重;给某份报告在每个维度打分(0~1),加权汇总
rubric = [
# (维度, 权重, 这份报告的得分)
("引用准确性(说的有没有出处、出处对不对)", 0.35, 0.5),
("覆盖全面性(关键维度有没有遗漏)", 0.25, 0.8),
("无幻觉(有没有编造事实)", 0.30, 0.4),
("结构与可读性", 0.10, 0.9),
]
total = sum(w * s for _, w, s in rubric)
print(f"{'维度':<32}{'权重':>6}{'得分':>6}{'加权':>8}")
print('-' * 58)
for name, w, s in rubric:
print(f"{name:<32}{w:>6.0%}{s:>6.2f}{w*s:>8.3f}")
print('-' * 58)
print(f"{'加权总分':<32}{'':>6}{'':>6}{total:>8.3f}")
THRESHOLD = 0.7
print(f"\n阈值 {THRESHOLD} → 判定:{'通过' if total >= THRESHOLD else '不通过'}")
print(f"\n这份报告读着流畅(结构 0.90),但引用只有 0.50、还有幻觉(0.40)")
print(f"若只看单一维度,危险的报告会被「读着不错」蒙混过去")
运行
python rubric_score.py
你应该看到(确定性输出):
维度 权重 得分 加权
----------------------------------------------------------
引用准确性(说的有没有出处、出处对不对) 35% 0.50 0.175
覆盖全面性(关键维度有没有遗漏) 25% 0.80 0.200
无幻觉(有没有编造事实) 30% 0.40 0.120
结构与可读性 10% 0.90 0.090
----------------------------------------------------------
加权总分 0.585
阈值 0.7 → 判定:不通过
这份报告读着流畅(结构 0.90),但引用只有 0.50、还有幻觉(0.40)
若只看单一维度,危险的报告会被「读着不错」蒙混过去
看懂了关键:这份报告读着很流畅(结构 0.90),但它引用不准、还有幻觉。想象这是一份「中小规模 RAG 项目向量库选型」的报告——读着头头是道,但它引的 Milvus 性能数字是错的、还编了个 Qdrant 根本没有的特性,你照着它选型就踩坑了。如果只用「读着顺不顺」这一个维度评,它能拿高分蒙混过去;一旦拆成多维度加权,「引用准确性 0.35 + 无幻觉 0.30」这两个要害项权重占了 65%,报告立刻不及格。多维度加权,就是为了不让一两个表面优点掩盖致命缺陷。
🐛 跑不通看这里:纯标准库,不该报错。注意权重和维度是要针对你的任务精心设计的,这里的数字只是示意。
📌 说清楚:这是教学示意。真实评估里,每个维度的分不是手填的,而是由 LLM-as-a-Judge(下一节)或规则自动打出来。这里手填,是为了让你先看清「多维加权」这个机制本身;为什么这么评、坑在哪,下面接着讲。
🧭 你刚才看到的,等于真实系统的什么? 你手填的「得分」= 真实系统里 Judge 模型或规则给每个维度打的分;你设的「权重」= 你对「这个任务什么最重要」的判断。把开放质量拆成带权重的维度,这个思路和工业界的评估框架(以及 RAG 的评估)完全一致。
🎯 Part 2 · 面试深度 ｜ ~45% 这部分把自动化评估的方法和陷阱讲透。这些是 Agent / RAG 评估的高频考点,也是最容易暴露「有没有真做过」的地方。
2.1 LLM-as-a-Judge:用强模型当裁判
人工评估准,但贵且慢:几百上千条轨迹靠人一条条看,迭代根本跟不上。两种评估方式各有取舍:
主流做法是用自动评估扛量、人工评估抽检校准。自动评估的主力就是 LLM-as-a-Judge:用一个更强的模型(比如 GPT-4 级别),按你给的 rubric 去给每份报告 / 每条轨迹打分。
- 怎么做:给 Judge 一个明确的打分 prompt(评分维度、每档的标准、要不要给理由),让它输出结构化分数。
- 优点:可扩展、快、便宜、一致性比多个人工标注者还高。
- 关键:Judge 的 prompt(rubric)质量,直接决定评估质量。模糊的 rubric 会得到模糊的分。
2.2 LLM-as-a-Judge 的坑:裁判也有偏见
Judge 是模型,就带模型的偏见。不知道这些坑,评出来的分会系统性失真:
- 位置偏好:做 A / B 两份对比打分时,Judge 会系统性地偏向某个固定位置(多数模型偏向靠前,但具体方向因模型 / 任务而异)。缓解:打乱顺序、正反各评一次取平均,把位置因素抵消掉。
- 长度偏好:Judge 倾向于认为更长的答案更好(哪怕在灌水)。缓解:rubric 里明确「简洁也是优点」,或控制长度变量。
- 自我偏好:Judge 倾向于偏爱和自己风格相近(尤其同家模型生成)的答案。缓解:用不同家的模型当 Judge、或用多个 Judge 投票。
业内行话:面试聊评估,能主动说出「LLM-as-a-Judge 有 position bias、length bias、self-preference bias,我会用打乱顺序 + pairwise 比较 + 多 Judge 来缓解」,面试官立刻知道你真用过它,而不是只听过这个词。
2.3 评估基准:固定一把尺子
评估要可比,就得有一把固定的尺子:一个精心构造的评估集(一批有代表性的调研问题 + 参考答案 / 评分标准)。
- 评估集怎么建:覆盖不同场景、不同难度、不同问题类型(回扣第 5 章的数据分布思想),才能反映真实能力而非偏科。
- 静态 vs 动态:固定评估集方便对比每一版,但用久了模型会针对它过拟合(无论有意无意),分数虚高。所以要定期更新评估集、加入新问题,保持它的「区分度」。
2.4 最大的陷阱:Goodhart 定律与刷分
这是评估里最深刻的一个坑,一句话:「当一个指标变成了目标,它就不再是一个好指标。」(Goodhart 定律)
体现在 Agent 上:如果你拿某个评估指标去训练(回扣第 6 章 GRPO 的 reward),模型会专门学着迎合这个指标,而不是真的变好。比如:
- 你奖励「引用数量多」,模型就堆砌无关引用。
- 你用某个 Judge 打分当 reward,模型就学会迎合那个 Judge 的偏好(比如写得又长又啰嗦),哪怕内容没变好。
这其实就是第 6 章说的 reward hacking 在评估侧的镜像。怎么防:多维度评估(不让单一指标主导)、定期更换 / 扩充评估集、引入对抗样本、关键节点保留人工抽检。评估和被评估的模型,是一场持续的博弈。
2.5 评估闭环:评完不是结束,是下一轮的开始
评估真正的价值,不是给一个分数,而是指出弱点、驱动下一轮迭代:
- 怎么定位弱点:把评估集的分数按「维度 × 问题类别」拆成一张表看,哪个格子分数低,弱点就在哪。比如发现「某类选型场景 × 引用准确性」这一格明显偏低,就锁定了一个具体短板,而不是只知道「总分有点低」。
- 怎么变成数据:针对这个短板定向构造该类的种子问题 + 让 Teacher 跑出对应轨迹(回扣第 5 章),补进训练集 → 重训(回扣第 6 章)→ 再用评估集验证那一格是否真的涨了。
- 如此循环。整个项目从第 1 章到第 8 章,在这里闭环成一个飞轮:为什么做 → 架构 → 工具 → 记忆 → 数据 → 训练 → 上线 → 评估 → 回到数据。
讲师私货:很多人把评估当成「最后跑个分」的收尾步骤,其实评估是整个迭代飞轮的方向盘。一个能讲清「我怎么评估、评估发现了什么、怎么根据评估结果反推去补数据重训」的人,展示的是完整的工程闭环思维,这正是大厂最看重的「能自己驱动项目变好」的能力。这也是这个项目最值钱的地方:它不是一堆孤立的技术点,而是一条会自我改进的完整链路。
🧭 这一章到这儿:评估的难点、评什么、LLM-as-a-Judge 与它的偏见、防刷分、闭环飞轮,这一章都讲透了。
🏆 Part 3 · 验收串题 ｜ ~10%
关联面试题(5 道,覆盖 5 个角度)
- 【评估体系设计】 设计一套完整的评估体系来衡量一个 Agent / RAG 系统的性能。
- 【评测集选择】 你在项目里用过哪些评测数据集?为什么选它们、它们如何反映模型能力?
- 【评估关键指标】 RAG 系统的评估体系里,最重要的评估指标 / 维度有哪些?
- 【幻觉评估与缓解】 怎么有效评估并缓解大模型生成内容里的幻觉?
- 【子任务贡献评估】 复杂目标的 Agent 里,怎么评估一个子任务的完成对最终目标的贡献?
自检清单
- 能讲清调研型 Agent 为什么难评估(开放任务无标准答案、跑通≠做好、过程也要评)
- 能说出评估的两个层面(结果质量 / 过程质量)和结果质量的关键维度(引用准确、无幻觉)
- 能讲清 LLM-as-a-Judge 怎么用,以及它的三个偏见(位置 / 长度 / 自我)和缓解办法
- 能讲清 Goodhart 定律 / 刷分:指标成为目标就会被迎合,以及多维度 / 换评估集 / 人工抽检怎么防
- 能讲清「评估 → 补数据 → 重训」的闭环,以及评估是迭代飞轮的方向盘
🎉 恭喜,你走完了整个 Deep Research Agent 项目! 从第 1 章「为什么需要它」,到执行框架、工具、记忆、数据、训练、上线,再到这一章的评估闭环,你已经完整理解了一个调研型 Agent 从 0 到上线再到持续迭代的全链路。这条链路上的每一个环节,都是 Agent 岗面试的硬核考点;而能把它们串成一个会自我改进的飞轮讲清楚,正是区别「调过模型的人」和「能落地项目的人」的地方。