RAG 项目很容易被讲成“文档切分、向量化、召回、生成”。这条链路没错，但如果面试官继续问“效果怎么评估”，只回答召回率或人工看一下，就会显得不够成熟。
RAG 评测的难点在于：召回到了资料，不代表答案正确；答案看起来流畅，不代表基于资料；模型拒答，不一定是失败，也可能是正确边界。一个能上线的 RAG 系统，需要围绕坏例持续迭代。
先判断资料是否可答
评估第一步不是模型，而是问题本身是否能被资料库回答。很多坏例不是模型能力问题，而是资料缺失、资料过期、权限限制或用户问题太模糊。如果资料里没有答案，正确行为可能是拒答或追问，而不是强行生成。
因此坏例集里最好标注问题类型：资料缺失、召回失败、排序失败、生成误用、权限不允许、问题不完整。不同类型对应不同修复动作。
召回率只是中间指标
召回率能告诉你正确资料有没有被找出来，但还不够。你还要看正确资料是否排在足够靠前的位置，是否包含完整上下文，是否被模型实际使用。对于长文档，命中一个相近片段可能仍然无法回答问题。
证据召回率：能说明的是正确资料是否进入候选，不能说明的是模型是否正确使用。前几条命中率：能说明的是资料是否排得足够靠前，不能说明的是答案是否表达准确。
- 答案一致性：能说明的是多次回答是否稳定，不能说明它是否真的符合业务规则。
- 拒答准确率：能说明的是边界是否守住，不能说明的是用户体验是否满意。
坏例回归是长期资产
每次线上出现错误回答，都应该沉淀成坏例。坏例里不要只保存用户问题和最终答案，还要保存召回片段、排序结果、提示词版本、模型版本和人工判断。否则下次改切分策略或提示词时，很难知道是变好了还是只碰巧修好一个案例。
一个成熟回答可以是：我会维护固定评测集和线上坏例集。固定评测集保证基础能力不退化，线上坏例集反映真实用户问题。每次调整召回、重排或提示词，都跑回归，看坏例是否减少，是否引入新的错误。
RAG 面试的高分点
RAG 的核心不是“接了向量库”，而是能让答案持续更可靠。面试里把资料可答性、证据召回、重排、生成约束、拒答边界和坏例回归串起来，就能明显区别于只做演示的项目。
评测还要区分离线和线上。离线评测适合稳定比较不同切分、召回和重排策略；线上反馈能暴露真实用户问题，比如用户连续追问、复制答案后又撤回、或者直接点踩。两者不能互相替代，离线指标好不代表线上体验一定好。
如果项目资源有限，可以先从小而稳定的评测集开始：选出几十个高频问题、边界问题和历史坏例，每次改动都跑一遍。这个习惯比一次性做一个复杂评测平台更实用，也更符合多数团队的落地节奏。