RAG 项目最危险的时刻不是检索失败而是团队说「感觉比上一版好」。感觉无法回归、无法对比、无法向老板证明投入产出。这篇讲怎么把 RAG 的效果评估从玄学变成工程。评估集是第一生产力先建评估集五十到一百条真实业务问题每条配上要点式标准答案。三个来源按优先级排线上真实用户问题脱敏、业务专家的高频问题清单、产品经理的边界测试问题故意刁难的。要点式标准答案是关键——不要求全文一致只要求答案必须覆盖的关键信息点。大模型的回答天然千变万化逐字对比没有意义。三个层次的指标第一层检索质量。标准答案对应的文档块有没有被检索进 top-K这是命中率recallKRAG 效果的天花板就在这里——检索都召不回生成再好也是编。第二层生成忠实度。回答的内容是否都能从检索到的资料中找到依据有没有资料里没有的编造可以用另一个模型做裁判对照资料检查每个论断人工抽检校准裁判的可靠性。第三层端到端质量。最终回答是否覆盖了标准答案的要点是否直接回答了问题而不是绕圈子这块用大模型按维度打分准确性、完整性、简洁性各一到五分人工抽检百分之十校准。回归流水线把评估做成脚本任何改动换切块参数、换 embedding 模型、调提示词之后跑一遍输出三层数据与上一版的对比。十分钟出报告效果提升与回退一目了然。两个实践细节评估集要随业务演进定期扩充新上线的知识域补新题不同改动分开评测记录才能归因——一次改了切块又换了模型涨了不知道谁之功跌了不知道谁之过。现实预期评估建设大约占 RAG 项目总投入的两成回报却是整个迭代周期。见过最多的失败模式就是团队对着单个 case 反复调参一周上线后发现整体命中率反而降了三个点——没有评估集这种事发现不了。