上一篇讲了 Tracing——让单次 run 可见。但 Tracing 只解决「这一次」的问题。整体质量怎么衡量？改了 prompt、换了模型，到底变好还是变差？这需要评估（Evaluation）。
这一篇讲评估：怎么用数据集量化 Agent/RAG 的质量，而不是凭感觉调参。
凭感觉调参的问题
很多人调 LLM 应用是凭感觉：改了 prompt，跑几个例子，感觉「好像好点了」，就上线。这个做法的问题：
- 样本太小：跑几个例子，可能刚好是改对了的，不代表整体
- 主观：「感觉好点」不客观，不同人感觉不同
- 不可对比：这次改和上次改，谁更好？说不清
评估要解决的，就是把「调参有没有变好」从感觉变成可量化的数据。
评估的核心：数据集 + 批量测
评估的核心思路：准备一个测试数据集，批量跑，量化结果。
- 准备数据集：一组「问题 + 期望（答案/相关文档）」的样本
- 批量跑：用你的 Agent/RAG 跑整个数据集
- 打分：对每个结果打分（对/错、相关度、准确率）
- 汇总：得到整体的量化指标
有了量化指标，「改 prompt 有没有变好」就有了客观依据：改之前跑一次得 75 分，改之后跑一次得 82 分——确实变好了，上线。而不是「感觉好点」。
数据集从哪来
测试数据集是评估的基础。来源：
- 真实问题：从线上日志里收集用户真实问过的问题（最有价值）
- 人工构造：根据业务场景手写一批典型问题
- 模型生成：让模型基于你的文档生成问题和答案（量大，但要人工抽检）
最佳实践是以真实问题为主，人工/生成为辅。真实问题反映用户真实问法，最有代表性。
怎么打分
打分是评估的难点。LLM 输出不是简单的对/错，怎么评判？
几种打分方式：
- 精确匹配：输出和期望答案完全一样（适合结构化输出）
- 包含判断：输出是否包含关键信息（适合事实类问答）
- LLM 当裁判：用另一个 LLM 判断输出好不好（最灵活，适合开放性回答）
- 人工评估：人来看（最准，但慢）
最常用的是「LLM 当裁判」——用一个强模型评判你 Agent 的输出。虽然不完美，但能规模化，是当前评估开放性回答的主流方式。
评估什么：不止「答得对」
评估的维度不止「答得对不对」：
| 维度 | 评估什么 |
|---|---|
| 准确性 | 答案对不对 |
| 相关性 | RAG 检索的文档相不相关 |
| 忠实度 | 有没有瞎编（hallucination） |
| 延迟/成本 | 快不快、贵不贵 |
一个生产级应用，这几个维度都要评估。光看「答得对」不够——答得对但慢得要命、或瞎编但听着像对的，都不行。
评估要持续做
评估不是一次性的，要持续做。每次改动（改 prompt、换模型、加工具），都跑一次评估对比。这形成了一个闭环：
改 → 跑评估 → 看指标 → 决定保留还是回退
这个闭环是 LLM 应用质量能持续提升的基础。没有评估，改动就是瞎调；有评估，改动才有方向、有依据。
收束：评估让优化有依据
这一篇讲了评估：
- 凭感觉调参有样本小、主观、不可对比的问题
- 评估 = 数据集 + 批量跑 + 打分 + 汇总
- 数据集以真实问题为主
- 打分常用「LLM 当裁判」
- 多维度：准确、相关、忠实、延迟成本
- 要持续做，形成改-评估-决策闭环
下一篇讲 Replay 调试——agent 时代的断点调试。
关于十三Tech
我是十三，All in AI Agent 方向的架构师，专注 AI 工程实践。我相信 AI 是程序员的最佳搭档。
如果你想跟完这套「图解 LangChain」，欢迎关注公众号 「十三Tech」。全系列 42 篇，会按认识基础、LangGraph 状态机、Agent 与 middleware、RAG 检索、Tools/MCP/记忆、生产化收束这条线更新。
