RAG 检索质量评估不是召回越多越好一、Recall 高了业务指标反而跌了RAG 系统上线三个月后团队做了一次召回优化。把向量检索的 top_k 从 5 提升到 20Chunk 切分从 512 Token 缩小到 256 Token还加了 BM25 稀疏检索做混排。评估数据很好看Recall20 从 0.72 升到了 0.91。几乎完美——理论上用户 91% 的问题正确答案都已经在上下文里了。但业务指标说出来就不那么好看了。答案准确率从 86% 掉到了 79%用户平均对话轮数反而增加了 1.3 轮。为什么召回提升反而让效果变差原因很直接召回 20 个 Chunk 塞进上下文窗口模型迷失在了噪声里。越多不相关的文本越容易让模型产生幻觉或给出冗长回答。RAG 不是捞得越多越好而是在噪声和信号之间找到平衡点。基础设施不需要漂亮话它需要可测量的指标和可复现的结论。二、检索质量的四维度评估框架RAG 检索质量需要从四个维度评估而不是一个 Recallflowchart LR Q[用户问题] -- R[检索模块] R -- C{检索结果} C -- M1[Recallbr/正确答案是否被检索到] C -- M2[Precisionbr/检索结果中有效答案的占比] C -- M3[MRRbr/正确答案的排序位置] C -- M4[NDCGbr/综合排序质量评分]Recall召回率正确答案出现在检索结果中的比例。这是底线指标回答不了的问题就不可能答对。但 Recall 单独用没有意义——把整个知识库全返回 Recall 就是 100%。Precision精确率检索结果中真正相关的文本占比。Precision 低了上下文里夹带大量噪声模型容易产生幻觉。MRRMean Reciprocal Rank平均倒数排名第一个正确答案的排名位置的倒数。MRR 关注排序质量——正确答案排在第 1 位比排在第 10 位有价值得多。NDCGNormalized Discounted Cumulative Gain考虑多个正确答案以及它们的排序位置。NDCG 比 MRR 更能反映多答案场景下的检索质量。这四个指标之间存在天然的权衡。增大 top_k 能提高 Recall 但会降低 Precision。减少 Chunk 大小能提高 Precision 但可能切断完整语义。没有哪个指标是绝对的好取决于业务场景问答场景优先 MRR 和 Precision用户只需要一个准确答案摘要场景优先 Recall 和 NDCG需要覆盖多方信息客服场景Precision Recall少而精比多而杂更重要三、检索质量评估工具实现package rag import ( fmt math sort ) // RetrievalResult 单条检索结果 type RetrievalResult struct { ChunkID string Score float64 // 检索相关度分数 IsRelevant bool // 人工标注是否相关 } // EvalResult 检索质量评估结果 type EvalResult struct { Recall float64 Precision float64 MRR float64 NDCG float64 } // EvaluateRetrieval 计算四个检索质量指标 func EvaluateRetrieval(results []RetrievalResult, totalRelevant int) EvalResult { if len(results) 0 { return EvalResult{} } relevantCount : 0 var firstRelevantRank int -1 var dcg, idcg float64 for i, r : range results { if r.IsRelevant { relevantCount // MRR: 记录第一个相关结果的排名1-based if firstRelevantRank -1 { firstRelevantRank i 1 } // DCG 分母用 log2排序从 1 开始 dcg 1.0 / math.Log2(float64(i2)) } } // 计算理想情况下的 DCG——所有相关结果都排在前面 for i : 0; i totalRelevant i len(results); i { idcg 1.0 / math.Log2(float64(i2)) } // 计算四个指标 recall : 0.0 if totalRelevant 0 { recall float64(relevantCount) / float64(totalRelevant) } precision : 0.0 if len(results) 0 { precision float64(relevantCount) / float64(len(results)) } mrr : 0.0 if firstRelevantRank 0 { mrr 1.0 / float64(firstRelevantRank) } ndcg : 0.0 if idcg 0 { ndcg dcg / idcg } return EvalResult{ Recall: recall, Precision: precision, MRR: mrr, NDCG: ndcg, } } // EvaluateWithTopK 评估不同 top_k 下的检索质量 // 帮助选择最优的 top_k 值 func EvaluateWithTopK(allResults []RetrievalResult, totalRelevant int, ks []int) map[int]EvalResult { results : make(map[int]EvalResult) for _, k : range ks { if k len(allResults) { k len(allResults) } results[k] EvaluateRetrieval(allResults[:k], totalRelevant) } return results } // FormatEvalReport 格式化评估报告 func FormatEvalReport(queryResults map[string]map[int]EvalResult) string { var report string for query, kResults : range queryResults { report fmt.Sprintf(Query: %s\n, query) for k, eval : range kResults { report fmt.Sprintf( top_k%d | Recall%.3f Precision%.3f MRR%.3f NDCG%.3f\n, k, eval.Recall, eval.Precision, eval.MRR, eval.NDCG, ) } } return report } // FindOptimalTopK 找到综合得分最高的 top_k // 权重可以按业务场景调整 func FindOptimalTopK(queryResults map[string]map[int]EvalResult, ks []int) (int, float64) { bestK : ks[0] bestScore : 0.0 for _, k : range ks { var totalScore float64 count : 0 for _, kResults : range queryResults { if eval, ok : kResults[k]; ok { // 加权得分MRR 权重 0.4NDCG 权重 0.3Precision 权重 0.2Recall 权重 0.1 score : 0.4*eval.MRR 0.3*eval.NDCG 0.2*eval.Precision 0.1*eval.Recall totalScore score count } } if count 0 { avgScore : totalScore / float64(count) if avgScore bestScore { bestScore avgScore bestK k } } } return bestK, bestScore }关键设计点四个指标一次性计算。EvaluateRetrieval接收标注好相关性的一组结果同时输出 Recall、Precision、MRR、NDCG避免多次遍历。EvaluateWithTopK评估不同 top_k。在实际项目中这个方法用于找到最优的 top_k——通常在 5 到 20 之间。最佳值往往不是最大也不是最小。指标加权策略可配置。FindOptimalTopK按场景调整权重问答场景调高 MRR 权重摘要场景调高 Recall 权重。标注成本是最大的工程约束。评估集需要人工标注每条查询的相关 Chunk。建议从线上日志中采样构建标注集逐步积累到 500-1000 条。四、评估驱动的调优策略先固定评估集再调参数。在没有评估集的情况下调 top_k、Chunk 大小、Embedding 模型等于闭着眼睛开车。标注集是唯一可以信赖的裁判。Chunk 大小的选择有上限。Chunk 越小Precision 通常越高单个 Chunk 更精确但 Recall 会下降完整语义被切碎。实践的合理区间是 256-1024 Token。太大噪声多太小语义不完整。混合检索不一定更好。BM25 向量重排序在很多场景有效但增加了检索延迟 50-200ms。如果你的向量检索 Recall 已经超过 0.85加 BM25 的收益可能不足以抵消延迟代价。用评估框架量化决策而不是凭直觉。关注检索了但模型没用的比例。这是比 Recall 更重要但容易被忽略的指标。如果检索结果的 40% 在最终回答中完全没被引用说明上下文窗口被浪费了。此时应该减少 top_k而不是增加。端到端评估回环。检索质量评估只是中间站在。最终的裁判是端到端指标答案准确率、用户满意度、转人工率。如果检索指标优化后端到端指标没有同步提升说明瓶颈不在检索环节。五、总结RAG 检索质量不能只看 Recall。四维度评估框架Recall、Precision、MRR、NDCG覆盖了召回覆盖度、精确度、排序质量三个关键维度。核心实践先构建标注评估集再调参用EvaluateWithTopK量化选择最优 top_kChunk 大小在 256-1024 Token 区间实验关注检索但未引用的噪声比例检索指标优化后必须验证端到端业务指标同步提升。评估不是一次性工作而是持续迭代的基线能力。