方法笔记
RAG 评估方法论：为什么 similarity score 不够
从标注集、Recall@K、MRR、NDCG 到人工复核，整理 RAG 检索质量的评估路径。
8 分钟
RAG 检索质量不能只看 similarity score。真正需要回答的是：相关内容有没有被召回、是不是足够靠前、排序是否符合人工标注，以及失败样本指向哪类调优动作。
RAG 检索评估项目把这个问题拆成标注集、Recall@K、MRR、NDCG 和失败样本复核。它不是为了追求漂亮分数，而是为了让模型、chunk、query rewrite 和 reranker 的取舍有对照依据。
Similarity score 不是质量指标
向量相似度只能说明 query 和文档在 embedding 空间里接近，不等于业务上相关。不同模型、不同归一化方式、不同数据分布下，分数本身也没有稳定可比性。
如果只看 similarity score，很容易把模型偏好误认为业务质量。系统可能给出高分但不相关的结果，也可能把真正有用的结果排在后面。
先准备小而可信的标注集
评估不一定从大数据集开始。对于垂直业务，20 到 50 条高质量 query 就可以暴露很多问题。关键是覆盖真实使用方式，而不是只覆盖模型容易命中的词。
每条 query 最好标注多个相关文档，并给出相关性等级。这样 NDCG 这类指标才有意义，也能区分“勉强相关”和“非常相关”。
- 覆盖精确查询、短查询、同义表达、跨领域查询和歧义表达。
- 记录为什么某个文档相关，为什么另一个文档不相关。
- 固定标注集版本，避免每次调参都改变基线。
三个指标回答三个问题
- Recall@K
- 有没有召回
- 相关结果是否进入候选集合。对 RAG 来说，没召回就不可能生成正确答案。
- MRR
- 第一个多早出现
- 相关结果是否足够靠前，避免用户和生成模型先看到噪声。
- NDCG@K
- 排序是否合理
- 排序是否尊重相关性等级，惩罚把高相关结果排到后面。
这三个指标分别回答召回、首个命中和排序质量。它们不是越多越好，而是要和业务问题对应起来。
失败样本比平均分更重要
指标能帮助你发现趋势，但不能替代失败样本分析。平均分上涨可能掩盖某类 query 的退化，比如短 query 变差、跨领域 query 变差，或者相关文档进入候选但排序靠后。
我更倾向在评估报告里同时写指标和失败 case。指标告诉你是否变好，失败 case 告诉你为什么还没好，也告诉你下一步应该改数据、改模型、改 query，还是改排序。
- 01
短 query 失败
优先检查 query expansion 或领域词补全。
- 02
同义表达失败
优先检查 embedding 模型和样本文档表达差异。
- 03
召回但排序低
优先评估 reranker，而不是继续调相似度阈值。
调优要有对照组
每次加入 query rewrite、reranker 或混合检索，都应该和 baseline 比较。否则你不知道提升来自新组件，还是来自数据偶然变化。
对照组要固定 embedding、索引、top-k 和标注集。一次只改变一个变量，评估结果才可解释。比如先固定 chunk 和 embedding，只比较是否加入 reranker；再固定 reranker，只比较 query rewrite。
RAG 系统的工程价值不在于用了多少方法，而在于能否证明这些方法确实解决了当前失败模式。
检查清单
- 标注集是否覆盖真实 query 类型，而不是只覆盖容易命中的词。
- 每条 query 是否有明确相关文档和相关性等级。
- Recall@K、MRR、NDCG 是否分别对应召回、首个命中和排序质量。
- 评估报告是否保留失败样本，而不是只展示平均分。
- 每次调优是否有 baseline 和单变量对照。
这份清单让 RAG 调优从“感觉更准了”变成可复查实验。即使标注集很小，只要版本固定、解释清楚，也能成为后续模型替换和参数调整的基线。
对应项目
对应项目是 RAG 检索系统评估。项目页展示评估脚本、指标和样例结果；这篇笔记补充方法论：为什么 similarity score 不够，为什么失败样本和对照组更重要。