RAG 评估方法论：为什么 similarity score 不够

向量相似度只能说明 query 和文档在 embedding 空间里接近，不等于业务上相关。不同模型、不同归一化方式、不同数据分布下，分数本身也没有稳定可比性。

如果只看 similarity score，很容易把模型偏好误认为业务质量。系统可能给出高分但不相关的结果，也可能把真正有用的结果排在后面。

所以评估要看排序结果和人工标注之间的关系，而不是盯着分数绝对值。

评估不一定从大数据集开始。对于垂直业务，20 到 50 条高质量 query 就可以暴露很多问题。关键是覆盖真实使用方式，而不是只覆盖模型容易命中的词。

每条 query 最好标注多个相关文档，并给出相关性等级。这样 NDCG 这类指标才有意义，也能区分“勉强相关”和“非常相关”。

标注集要随着业务变化更新，但不能每次调参都重写，否则评估基线会消失。

Recall@K 回答“相关结果有没有进入候选集合”。对于 RAG 来说，召回是底线，因为没召回就不可能生成正确答案。

MRR 回答“第一个相关结果出现得早不早”。如果相关结果总在第 5 位之后，用户和生成模型都会先看到噪声。

NDCG@K 回答“排序是否尊重相关性等级”。它比命中率更细，因为它会惩罚把高相关结果排到后面。

指标能帮助你发现趋势，但不能替代人工判断。特别是业务相关性、表达意图和文档可用性，仍然需要人看失败样本。

我更倾向在评估报告里同时写指标和失败 case。指标告诉你是否变好，失败 case 告诉你为什么还没好。

这也是 RAG 评估和普通脚本测试的区别：你不仅要知道 pass/fail，还要知道下一步应该改数据、改模型、改 query，还是改排序。

每次加入 query rewrite、reranker 或混合检索，都应该和 baseline 比较。否则你不知道提升来自新组件，还是来自数据偶然变化。

对照组要固定 embedding、索引、top-k 和标注集。一次只改变一个变量，评估结果才可解释。

RAG 系统的工程价值不在于用了多少方法，而在于能否证明这些方法确实解决了当前失败模式。