RAG 评估：答错了，是检索的错还是生成的错？

  假如，你给自己的 Agent 接了一个 RAG 知识库，问了一个知识库相关的问题，它答错了。接下来你会怎么处理？

  你可能会这样做：改提示词、换个更强的模型、把 chunk_size 从 500 调到 800、把 top_k 从 3 加到 5。改完再问一遍，没问题就收工了。

  问题是你压根不知道是哪一步坏了，也不知道这次改动是真的有效，还是碰巧。下次换个问题，可能又崩。

  这里错误可以出在两个完全不同的地方——可能是检索压根没把该给的资料捞回来，也可能是资料给对了、生成时自己跑偏了。

  评估要解决的就是这件事，哪一步不正常，测量一下就知道，而不是全靠“再问一遍试试”。

RAG 三元组

  RAG 有个很好用的评估框架，叫 RAG 三元组（RAG Triad）。它的思路是：一次问答里其实只有三样东西——问题、检索到的上下文、最终的答案，那就两两之间各查一遍。

  三条边，对应三个指标：

这三个指标能直接定位病因：

• 上下文相关性低 → 检索坏了，后面再强的模型也救不回来；
• 忠实度低 → 生成在瞎说，资料明明给了它，它自由发挥；
• 答案相关性低 → 答非所问，或者只答了一半；

  忠实度和答案相关性最容易混，看一个例子：用户问“法国在哪里，首都是哪里？”，答案是“法国在西欧”。这句话完全出自资料，忠实度很高，但它只答了一半，答案相关性很低。

  一个查有没有瞎说，一个查有没有答到点。分开看，才知道该去修提示词还是修检索。

检索评估

  这里直接沿用信息检索那套指标就行。使用之前，得先有一份标注数据集：一批问题，以及每个问题真正相关的文档是哪些。常用的有三个：

• Precision@k：捞回来的前 k 条里，有多少是真相关的——衡量准，高就说明噪声少；
• Recall@k：该找到的相关文档，找回来了多少——衡量全，高就说明没漏；
• MRR：第一条正确答案排在第几位——只关心“一击命中”的场景特别适合；

  这里有个躲不过的权衡：准和全，通常只能挑一个。把 top_k 调小、门槛调高，准了但容易漏；调大、放宽，全了但杂质进来。先用大 k 保证不漏，再用重排把准捞回来。

生成评估

  生成这一环没有标准答案可比，现在主流做法是用一个中立的、能力强的模型来当裁判。

  以忠实度为例，裁判的活儿干得挺细：先把答案拆成一条条独立的断言，然后拿着上下文逐条核对——这条有依据、这条没有，最后算被证实的比例。这个分数因此有了具体含义：它等于答案里有多少比例是有据可查的。

  还有一条走了很多年的老办法，就是盯着词面重叠看：把生成答案和参考答案按 n-gram 逐项对比。ROUGE 更关注“该覆盖的内容是不是都覆盖到了”，BLEU 更在意“生成出来的表述准不准确”，METEOR 则是想在两者之间尽量做个平衡。它们的优点很直接：客观、成本低、结果也容易复现；但短板同样明显，那就是几乎不理解语义——哪怕只是换一种说法、意思完全一样，分数也可能立刻掉下去。

  实践里的组合：便宜的先筛，贵的精评。用词汇重叠和检索指标做大批量回归，挑出可疑的样本再交给 LLM 裁判细看。

指标比较

  评估最实际的价值，是让两个方案能被摆在一起比。

  打个比方：同一批问题下，句子窗口检索的忠实度 53.3%、相关性 66.7%，而常规分块只有 0.0% 和 6.7%。“小块检索更准”这个大家都听过的说法，到这里才第一次变成了具体的数字。

  对于常规分 0.0% 这种极端值别急着当结论。它更可能说明那批测试问题或者那套配置本身有问题，而不是“分块差了一百倍”。评估会告诉你哪儿不对，但它自己也可能不对——测试集太小、问题太偏、裁判模型有偏见，都会把分数带跑。

  工具方面记住三个定位：

一句话总结

  答错了别急着改提示词——先分清是检索没捞对，还是生成在瞎说，还是压根没答到点。三元组的意义不在于打出漂亮的分数，而在于让每次优化都能说清自己改进了什么。