RAG 系统评测检索命中和答案正确要分开看一、RAG 失败不一定是模型回答差RAG 系统由检索和生成两部分组成。用户看到的是最终答案但答案错误可能来自多个环节问题改写失败、检索未命中、召回文档过多、排序不准、上下文截断、模型没有引用证据或者模型在证据不足时仍然编造。因此评测 RAG 时不能只给最终回答打分。更合理的做法是把检索质量和生成质量拆开评估。检索阶段关注是否找到了正确证据生成阶段关注是否基于证据回答、是否覆盖关键点、是否拒答不确定问题。这样才能知道优化方向是向量库、chunk 策略、rerank 模型还是 Prompt 和生成模型。二、评测链路问题、证据和答案要可追踪flowchart TD A[评测问题] -- B[检索系统] B -- C[TopK 文档] C -- D[Rerank] D -- E[生成模型] E -- F[最终答案] C -- G[检索指标] F -- H[生成指标]评测集应包含问题、标准答案、标准证据文档 ID 和必要的拒答样本。只有标准证据才能计算 RecallK、MRR、nDCG 等检索指标。只有拒答样本才能评估系统是否在知识库没有答案时保持克制。对于企业知识库建议使用真实用户问题和人工标注证据构建评测集。自动生成问题可以增加覆盖面但不能完全替代人工标注。生成问题往往过于贴近文档原文容易高估检索效果而真实用户提问通常含有缩写、口语和上下文省略。三、指标实现先计算检索是否命中下面示例展示 RecallK 的基本计算。它回答的是“正确证据是否出现在 TopK 结果中”。def recall_at_k(predicted_doc_ids, gold_doc_ids, k: int) - float: hits 0 for preds, golds in zip(predicted_doc_ids, gold_doc_ids): topk set(preds[:k]) gold_set set(golds) if topk gold_set: hits 1 return hits / max(len(gold_doc_ids), 1)如果 Recall5 很低优先排查 embedding 模型、chunk 切分、索引字段和查询改写。此时继续调 Prompt 通常没有意义因为模型没有拿到正确证据。如果 Recall5 很高但答案质量差再检查上下文拼接、证据排序、引用格式和生成模型。生成质量可以采用人工评估和模型辅助评估结合。人工评估更可靠但成本高模型评估效率高但需要校准。建议抽样人工复核模型评估结果计算一致性。如果评估器本身不稳定RAG 指标也不可信。四、实验变量一次只改一个因素RAG 优化容易同时修改多个因素例如换 embedding、改 chunk、加 rerank、调整 TopK 和 Prompt。这样虽然可能分数提升但无法知道是哪一项有效。严谨实验应一次只改一个变量固定数据集、固定生成模型、固定评估脚本并记录版本。还要关注延迟和成本。更大的 TopK、更强的 rerank 和更长的上下文通常能提高准确率但会增加响应时间和 token 消耗。工程上需要画出准确率、延迟和成本之间的曲线而不是只追求最高分。最后评测集要定期更新。知识库内容会变化用户问题分布也会变化。一个长期运行的 RAG 系统应把线上失败样本回流到评测集中让评测覆盖真实问题而不是只在初始样本上取得高分。五、总结RAG 评测要拆分检索命中和生成正确性。先确认正确证据是否被召回再讨论模型是否基于证据回答。标准证据、拒答样本、单变量实验和成本延迟曲线是让 RAG 优化可解释的基础。