RAG 匹配系统需要评估，而不只是检索

RAG 系统最常见的误区是把“能返回结果”当作“质量不错”。真正有用的是能否稳定命中相关内容，并且在不同 query 类型上保持可解释的指标。

如果没有 Recall@5、MRR 或 NDCG 这类指标，调参只是在凭感觉移动阈值。

相似度分数本身没有业务意义，重要的是候选是否进入前几位、相关文档是否足够早出现，以及在人工复核中能不能持续复现。

所以我更愿意把评估写成一套小而清楚的实验，而不是堆更多检索技巧。

抽象 query、短 query 和跨领域 query 往往是失败来源。它们会告诉你是 chunk、embedding、query 改写还是 reranker 需要调整。

评估的价值不是分数本身，而是把下一步该改哪里说清楚。

如果失败集中在短 query，可能需要 query expansion；如果失败集中在同义表达，可能需要更合适的 embedding 模型；如果相关结果进了候选但排序靠后，reranker 才更有意义。

小规模评估不是问题，问题是标注是否覆盖真实查询类型。30 条 query 如果覆盖精确匹配、语义模糊、短 query、跨领域和歧义表达，往往比随手跑 100 条相似 query 更有价值。

标注时最好写下为什么这个文档相关、为什么另一个不相关。这样后面指标变化时，不会只看到分数涨跌，还能判断业务上是否真的变好。

RAG 评估的核心是把主观判断变成可复查记录。只要这个记录能复现，后面的模型替换、参数调整和 reranker 接入才有比较基线。

很多 RAG 系统一开始就想加 query rewrite、hybrid search、reranker 和多路召回，但没有 baseline 时，复杂方案只会让问题更难定位。

我更倾向先做最小可复现 baseline：固定数据、固定 embedding、固定 top-k、固定指标。确认失败模式后，再决定下一步加什么。

工程上真正有说服力的不是用了多少组件，而是你能解释为什么这个组件应该出现在这里。