搭好 RAG 只是开始：改了 chunk 大小、换了 embedding 模型、加了 rerank，效果是变好还是变坏？靠”问几个问题感觉一下”无法支撑决策。RAG 评估要把它变成可量化、可回归的工程流程。本文按”评什么 → 用什么指标 → 怎么建评测集 → 怎么进 CI”展开。

评什么：三层指标体系

第一层：检索质量（召回的 chunk 对不对）

  • Recall@k：正确答案所在 chunk 是否进入 top-k——最核心指标
  • MRR / Hit Rate：正确 chunk 的排名位置
  • 上下文精度（context precision）：召回内容中相关段落占比（噪声多会干扰生成）

第二层：生成质量（基于召回内容答得好不好）

  • 忠实度（faithfulness）：答案的每个论断是否都能由召回上下文支持——幻觉的直接度量
  • 答案相关性（answer relevancy）：答案是否切题
  • 引用正确性：给出的出处是否真包含该信息

第三层：端到端业务指标

  • 任务成功率 / 人工满意度评分 / 客服场景的解决率与转人工率

三层分离的价值：答案错时能定位是”没查到”（检索层）还是”查到了但编了”（生成层），改法完全不同。

用什么评：LLM-as-judge 与工具链

人工评全部用例太贵，主流做法是用强模型当裁判（LLM-as-judge）按上述维度打分：

  • RAGAS：提供 faithfulness/context precision/answer relevancy 等开箱指标
  • TruLens / DeepEval：反馈函数 + 可视化追踪
  • 自建裁判 prompt：给”问题+上下文+答案”，要求逐论断核对引用并输出结构化分

裁判模型本身要校准：抽 10% 用例人工复核裁判分，一致性不足就改裁判 prompt 或换裁判模型。

评测集怎么建

  • golden set：100-300 条”问题 + 标准答案 + 答案来源 chunk/文档 ID”三元组；来源标注是检索指标的地面真相
  • 覆盖四类问题：事实单跳、多文档综合、需要拒答的（知识库没有的）、表述变体（同义改写）
  • 防泄漏：评测集文档版本固定，知识库更新时评测集同步审订；评测问题不能出现在知识库的 FAQ 里（否则测的是背诵而非检索）
  • 持续扩充：线上 badcase 定期回流进评测集——评测集是活资产

进 CI：每次变更跑回归

把评估做成流水线：chunk 策略 / embedding / rerank / prompt 任何变更 → 自动跑 golden set → 输出三层指标对比报告 → 指标回超阈值（如 Recall@5 降 2 个点）即阻断合并。RAG 系统的”单元测试”就是这套回归。

常见误区

  • 只评端到端不评检索：坏在检索的锅被生成层背，优化方向全错
  • 评测集太小（<50）：指标波动大于真实差异，结论不可信
  • 用生成模型自评自建知识库的内容：同模型偏见互相放大
  • 忽略拒答类用例：RAG 最容易在”不知道”时自信胡说，这类用例专测诚实度

RAG 评估的本质是把”感觉好用”翻译成三层可回归的数字：检索看 Recall@k 与上下文精度，生成看忠实度，业务看任务成功率；配上 golden set 与 CI 回归，RAG 才从 demo 变成可维护的系统。