RAG 评测入门：检索层与生成层分开打分

「感觉变好了」不算数

改了切块、换了 embedding 模型、加了重排序——每个改动之后，团队里总会有人说「感觉顺多了」。但 RAG 的失败分散在检索与生成两层，凭感觉既发现不了回归，也定位不了问题：答案变差，是检索没捞到材料，还是模型没用好捞到的材料？没有分层评测，这个问题永远靠猜，每次改动都是在赌。

评测的第一原则因此是：**检索层与生成层分开打分。**好消息是，两层各有便宜可靠的指标，评测集从几十条真实问题起步就够用。

检索层：命中与名次

检索层评测不需要跑生成模型，成本低、定位准，最常用的两个指标：

recall@k（命中率）：人工标注「哪一块包含答案」，看它有没有进 top-k。衡量「别漏」。@k 的 k 要与线上配置一致——k=3 上线的系统，没有资格拿 k=10 的评测数字安慰自己。
MRR（Mean Reciprocal Rank，平均倒数排名）：第一个命中块排在第几位，取倒数再平均：排第 1 记 1 分，排第 3 记 1/3 分。衡量「别乱」——命中了但总排在后面，模型读到的第一印象就是错的材料。

评测集怎么来？从真实用户问题出发，人工标注答案所在块：一题标出一块或多块「能回答此题」的块。几十条就能开始用，先覆盖高频与易错场景，再随 badcase 持续扩充。上一篇的「20 题验收法」正好是种子——验收时你已经在人工看命中块了，顺手把结论记下来就是标注，边际成本很低。

生成层：忠实、相关、用尽

检索材料在手，生成层回答三个问题：

忠实度（faithfulness）：答案是否只基于检索到的内容？材料里没有的数字、事件，模型是不是自己补的？这是防幻觉的主指标，也是 RAG 相对裸模型的核心卖点——配上检索之后它理应显著更高。
答案相关性（answer relevance）：答的是所问吗？还是顾左右而言他、长篇跑题、答一半漏一半？
上下文利用率：检索回来的材料里，有多少真被用进了答案。利用率长期偏低，说明召回夹带大量噪音，问题其实又回到了检索层。

这三个指标没有标准答案可比对，主流做法是 LLM-as-judge：用一个模型按固定评分细则给答案打分。

LLM-as-judge：好用，但要驯服

judge（裁判模型）要配齐三样东西才可靠：

固定 rubric（评分细则）：每个分档写清判据，例如「忠实度 5 分 = 所有事实性陈述都能在给定材料中找到依据；1 分 = 多数陈述无依据」。细则不固定，打分就是抽卡。
固定输出格式：先列依据、再给分数，最好要求 JSON 输出，程序才能批量收集、设阈值告警。
人工抽检校准：judge 自带已知偏差——偏爱长答案、偏爱与自己措辞相似的答案、对「谨慎但没正面回答」过于宽容。定期抽一批人工复核，发现系统性偏差就修 rubric。

还有一条纪律：裁判不要用被评测的同一个模型，至少换个版本，避免「自我打分手松」。

评测即 CI

评测集的价值在回归：每次改切块、换 embedding、加重排、调提示词，都跑同一套评测集，把 recall@k、MRR、忠实度、相关性记进历史曲线。指标跌了立刻能看见，而不是等用户投诉。更进一步是评测进 CI：流水线自动跑评测脚本，关键指标跌破阈值就挡住合并——把「别改坏」从口头约定变成机器把关。

症状速查表

症状	先查	病因与处方
答不准、动辄说不知道	recall@k	漏检：查切块、上混合检索（见前两篇）
一本正经地胡编	忠实度	生成越界：收紧「材料没有就说不知道」的约束，换更稳的模型
啰嗦、跑题、答非所问	答案相关性	任务理解偏了：修提示词；也常见于排序太差、好材料排太后
答案对但出处乱标	引用核对	元数据缺失或错位：回到切块，让出处随块走

小结

分层评测是 RAG 的仪表盘：recall@k 与 MRR 盯检索，忠实度与相关性盯生成；LLM-as-judge 把打分成本降到可承受，但要靠固定 rubric 与人工抽检驯服；评测集从几十条真实问题起步，随 badcase 生长，最终长进 CI。至此，流水线的每一环都有了量化抓手。下一篇是系列收官：当问题需要跨文档串联多步事实，向量检索会成片失灵——看看知识图谱与 GraphRAG 怎么补这块短板。