RAG 系统评测：检索命中和答案正确要分开看

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 和必要的拒答样本。只有标准证据，才能计算 Recall@K、MRR、nDCG 等检索指标。只有拒答样本，才能评估系统是否在知识库没有答案时保持克制。

对于企业知识库，建议使用真实用户问题和人工标注证据构建评测集。自动生成问题可以增加覆盖面，但不能完全替代人工标注。生成问题往往过于贴近文档原文，容易高估检索效果，而真实用户提问通常含有缩写、口语和上下文省略。

三、指标实现：先计算检索是否命中

下面示例展示 Recall@K 的基本计算。它回答的是“正确证据是否出现在 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)

如果 Recall@5 很低，优先排查 embedding 模型、chunk 切分、索引字段和查询改写。此时继续调 Prompt 通常没有意义，因为模型没有拿到正确证据。如果 Recall@5 很高但答案质量差，再检查上下文拼接、证据排序、引用格式和生成模型。

生成质量可以采用人工评估和模型辅助评估结合。人工评估更可靠，但成本高；模型评估效率高，但需要校准。建议抽样人工复核模型评估结果，计算一致性。如果评估器本身不稳定，RAG 指标也不可信。

四、实验变量：一次只改一个因素

RAG 优化容易同时修改多个因素，例如换 embedding、改 chunk、加 rerank、调整 TopK 和 Prompt。这样虽然可能分数提升，但无法知道是哪一项有效。严谨实验应一次只改一个变量，固定数据集、固定生成模型、固定评估脚本，并记录版本。

还要关注延迟和成本。更大的 TopK、更强的 rerank 和更长的上下文通常能提高准确率，但会增加响应时间和 token 消耗。工程上需要画出准确率、延迟和成本之间的曲线，而不是只追求最高分。

最后，评测集要定期更新。知识库内容会变化，用户问题分布也会变化。一个长期运行的 RAG 系统，应把线上失败样本回流到评测集中，让评测覆盖真实问题，而不是只在初始样本上取得高分。

五、总结

RAG 评测要拆分检索命中和生成正确性。先确认正确证据是否被召回，再讨论模型是否基于证据回答。标准证据、拒答样本、单变量实验和成本延迟曲线，是让 RAG 优化可解释的基础。