RAG Eval：Retrieval、Faithfulness 与 Citation Accuracy

RAG 上线后，最危险的状态不是“质量差”，而是团队不知道质量为什么变好或变差。

改了 chunk，答案好像更完整；换了 embedding，召回好像更准；加了 rerank，少数问题变好了，但延迟变高；prompt 改了以后引用更多，却不一定更准确。如果没有评估，团队只能靠几个样例和主观感觉调系统。

RAG Eval 的目标不是追求一个万能分数，而是把链路拆开评估：检索有没有找到证据，答案有没有忠于证据，引用有没有支撑结论。

这篇文章聚焦三个落地指标：

retrieval precision / recall：检索候选是否又准又全。
faithfulness：答案是否被检索证据支持。
citation accuracy：引用是否准确支撑对应句子。

提出问题：RAG 质量为什么不能靠感觉判断

假设一个企业内部知识助手已经上线，服务客服和售前团队。

团队每周都会更新产品文档、发布说明和内部 SOP，也会根据用户反馈调整 prompt、chunk、embedding 模型和 rerank 参数。使用量从每天几十次增长到几千次。

上线后出现几类争议：

客服说“新版检索更差了”，但工程看平均相似度变高了。
产品说“引用覆盖率提高了”，但一线发现很多引用点开后不支持答案。
加了 rerank 后复杂问题变好，简单问题变慢。
文档更新后，旧政策仍然偶尔出现在答案里。

如果只看用户点赞率，太粗；如果只看最终答案，无法定位根因。需要一个能把检索、生成和引用分层拆开的评估体系。

分析问题：把评估对象拆成链路指标

RAG Eval 本身包含抽取、检索、判断和审核。

问题类型	评估对象	常见指标	谁来判断
检索	候选片段是否包含黄金证据	recall@k、precision@k、MRR、nDCG	标注人员、领域专家、规则辅助
生成	答案是否忠于证据	faithfulness、unsupported claim rate	LLM-as-judge + 人工抽检
引用	引用是否支撑对应句子	citation accuracy、citation coverage	人工标注、LLM 预判
拒答	资料不足时是否拒答或追问	abstention accuracy	人工标注
回归	改动前后是否退化	pass rate、分类型指标	自动报告 + owner 审批

模型可以做初筛评分，但高风险样本、争议样本和评估器本身都需要人工校准。Eval 不是把判断外包给另一个模型，而是建立一套可复核的质量流程。

收益/成本判断

RAG Eval 的收益包括：

能定位问题发生在召回、排序、生成还是引用。
能比较 chunk、embedding、hybrid、rerank、prompt 的改动收益。
能防止文档更新或模型升级造成质量回退。
能把用户反馈变成可复用样本。
能让产品、工程和业务专家围绕同一组指标讨论。

成本包括：

构建和维护评估样本集。
标注黄金证据、答案和引用关系。
设计 LLM-as-judge prompt、人工抽检和一致性标准。
评估运行费用、报告系统和 CI/灰度集成。
处理指标之间的冲突，例如 recall 提高但 precision 下降。

什么时候简单人工抽查足够？

如果 RAG 还在原型阶段、知识库小、使用量低、答案只供内部参考，人工每周抽查几十条 trace，配合用户反馈就可以起步。

什么时候简单关键词或向量足够？

如果评估样本显示问题主要靠明确标题、错误码、接口名或政策编号命中，并且 precision@k 和人工抽查都稳定，关键词检索就足够。若问题主要是自然语言表达差异，但知识库条件简单、相似文档少、recall@k 稳定，单路向量检索也可以继续使用。Eval 的作用不是逼团队升级架构，而是证明简单方案在当前风险和样本分布下确实够用。

什么时候需要工程化 Eval？

当系统进入生产、文档频繁更新、prompt 和检索参数经常改、答案会对外使用，或者团队需要证明一次改动没有回退，就应该建立固定评估集、自动评分、人工抽检和上线门禁。

列举方案：从抽查到自动回归

RAG Eval 不必一开始就做成完整平台。可以从人工抽查和小样本开始，再逐步增加检索指标、faithfulness、citation accuracy、拒答评估和上线门禁。

Retrieval Precision / Recall

检索评估要回答两个问题：

该找到的证据有没有找到：recall。
找到的候选里有多少是有用的：precision。

最常见的形式是 recall@k 和 precision@k。

例如一个问题的黄金证据是文档片段 A 和 C。系统返回 top-5：A、B、D、E、F。

recall@5 = 1/2，因为两个黄金证据只找到了 A。
precision@5 = 1/5，因为五个候选只有 A 有用。

在 RAG 里，recall 往往先于 precision。因为正确证据不在候选里，模型基本无法生成可靠答案。但 precision 太低也会带来问题：噪声进入上下文，模型可能忽略正确证据或混合错误条件。

除了 precision/recall，还可以看：

指标	适合回答的问题	注意点
recall@k	黄金证据是否进入前 k 个候选	需要标注黄金证据
precision@k	前 k 个候选噪声多不多	相关性标准要清晰
MRR	第一个正确证据排第几	适合单一答案问题
nDCG	多个候选有不同相关等级时排序好不好	标注成本更高
no-answer accuracy	没有资料时是否避免乱召回	需要负样本

Retrieval Eval 的关键不是追求某个固定阈值，而是按问题类型分层看。错误码问题、政策问题、综合判断问题的合理 k 值和质量标准不同。

Faithfulness

faithfulness 衡量答案是否忠于给定证据。

一个答案可能表达流畅、逻辑完整、用户喜欢，但其中某些结论并没有被检索片段支持。这就是不 faithful。

例如证据写的是：

私有化部署下，回调地址变更需要在管理后台提交申请，由技术支持确认后生效。

模型回答：

私有化部署可以直接在配置文件中修改回调地址，重启服务后生效。

这个答案可能看起来像排查建议，但它违背证据。

落地 faithfulness 可以按 claim 评估：

把答案拆成关键 claim。
对每个 claim 判断是否被证据支持。
统计 unsupported claim rate。
对高风险 claim 进行人工复核。

可以用 LLM-as-judge 做初筛，但需要注意：

judge 只能基于给定证据判断，不能使用模型常识补充。
prompt 要区分“支持”“矛盾”“证据不足”。
需要抽样人工复核 judge 的一致性。
对法规、合同、财务、医疗等高风险领域，不应只靠自动 judge。

Citation Accuracy

citation accuracy 衡量引用是否准确支撑对应内容。

它和 faithfulness 相关，但不是一回事。答案可能整体 faithful，却把引用挂在错误句子后面；也可能引用覆盖率很高，但很多引用只是泛化相关。

引用评估至少看三件事：

引用存在：引用 ID 是否对应真实片段。
引用相关：引用片段是否和句子主题相关。
引用支撑：引用片段是否足以支持该句关键结论。

例如：

私有化 2.8 版本不支持自动轮转密钥，需要升级到 2.9 后开启。[doc-17]

如果 doc-17 只说明“2.9 支持密钥轮转”，没有说明“2.8 不支持”，这个引用只能支持后半句，不能支持前半句。

常用指标包括：

指标	含义	风险
citation coverage	有多少关键句带引用	覆盖高不代表引用准
citation accuracy	引用是否支撑对应句子	标注成本较高
citation precision	所有引用中有效引用占比	需要定义有效引用
citation recall	应引用的关键 claim 是否都引用	需要拆 claim

落地时可以先要求“关键结论必须带引用”，再逐步做句子级引用校验。不要把整段答案统一挂一个引用当作合格。

评估样本怎么建

一个可用的 RAG Eval 样本至少包含：

用户问题。
用户身份或权限上下文。
标准答案或答案要点。
黄金证据片段 ID。
不应使用的干扰片段。
是否应拒答。
问题类型和风险等级。

示例：

{
  "id": "rag-private-deploy-callback-001",
  "question": "私有化 2.8 回调地址校验失败怎么排查？",
  "userRole": "support_internal",
  "expectedAnswerPoints": [
    "确认私有化版本为 2.8",
    "检查管理后台回调地址配置",
    "需要技术支持确认变更后生效"
  ],
  "goldEvidenceIds": ["doc-private-2-8-callback", "sop-callback-change"],
  "distractorEvidenceIds": ["doc-public-cloud-callback"],
  "shouldAbstain": false,
  "type": "version_deployment_condition",
  "risk": "medium"
}

样本来源可以分四类：

高频真实问题：覆盖主要使用量。
高风险问题：政策、合同、权限、对外承诺。
历史失败问题：线上错答、用户差评、人工纠正。
对抗样本：无资料、条件冲突、权限不足、旧政策干扰。

不要只收“系统应该能答”的样本。负样本和拒答样本同样重要，否则系统会学会每次都强行回答。

Eval 落地流程

一个可执行的流程可以这样设计：

每周从线上 trace、用户反馈和业务专家处收集样本。
标注黄金证据、答案要点、问题类型和风险等级。
每次修改 chunk、索引、embedding、rerank 或 prompt 后跑固定评估集。
生成分层报告：检索、faithfulness、引用、拒答、延迟和成本。
对自动 judge 低置信或高风险样本做人工复核。
设定上线门禁：关键指标不能低于基线，核心样本不能回退。
把线上错答加入回归集。

决策判断：评估深度要匹配风险

场景条件	推荐方案	不推荐方案	判断理由	额外成本
原型期、低风险、使用量小	人工抽查 trace + 简单样本表	复杂自动评测平台	先发现主要失败类型	人工时间
检索经常漏资料	retrieval recall@k + 黄金证据标注	只看最终答案	需要定位召回问题	证据标注
检索噪声多、答案被干扰	precision@k + nDCG / MRR	只调 top-k	排序和噪声需要分开看	相关性分级
答案常过度推断	faithfulness claim 评估	用户点赞率	点赞不能证明证据支持	claim 拆分和 judge
引用不可信	citation accuracy + 句子级引用	只统计引用覆盖率	有引用不等于引用准	引用标注
频繁改索引和 prompt	自动回归 + 上线门禁	人肉试几个 case	需要防止质量回退	CI、报告、阈值
高风险专业场景	自动评估 + 专家抽检 + 审计	全自动 LLM judge	责任边界和误判成本高	专家时间和流程

反模式

第一种反模式：用一个总分代表 RAG 质量。

总分会掩盖根因。一个版本可能 retrieval recall 提升、citation accuracy 下降；另一个版本可能答案更短但更 faithful。需要分层指标。

第二种反模式：只评估正样本。

如果所有样本都有答案，系统会倾向于强答。必须加入无资料、权限不足、条件冲突和过期资料的样本。

第三种反模式：把 LLM-as-judge 当绝对真相。

自动 judge 可以提效，但也会误判、受 prompt 影响、对专业细节不稳定。需要人工校准、抽检和争议样本复盘。

第四种反模式：只看引用覆盖率。

覆盖率只能说明答案看起来更可追溯，不能说明引用支撑结论。citation accuracy 才能发现“引用不准”。

第五种反模式：Eval 和线上 trace 脱节。

评估集如果长期不吸收线上失败，就会越来越像考试题，而不是生产质量保障。

结论收束：Eval 上线前工程清单

场景边界：评估是否覆盖主要用户、权限、知识来源和风险等级。
样本结构：问题、黄金证据、答案要点、负样本、拒答标记是否完整。
检索指标：是否按问题类型看 recall@k、precision@k、MRR 或 nDCG。
生成指标：是否拆 claim 判断 faithfulness 和 unsupported claim。
引用指标：是否做 citation coverage 和 citation accuracy，而不只看引用数量。
自动评估：LLM-as-judge prompt、模型版本、温度和评分标准是否固定。
人工复核：高风险、低置信、争议样本是否有人审。
回归门禁：索引、chunk、embedding、rerank、prompt 改动是否触发评估。
可观测性：线上是否记录 query、候选、上下文、答案、引用、反馈和延迟。
成本延迟：评估是否同时报告检索耗时、模型调用成本和超时率。
样本更新：线上错答、用户差评和业务新政策是否进入回归集。

小结

RAG Eval 的价值不是给系统打一个漂亮分数，而是让团队知道该改哪里。

retrieval precision/recall 负责判断证据有没有找对；faithfulness 负责判断答案有没有忠于证据；citation accuracy 负责判断引用是否真的支撑结论。三者合在一起，才能覆盖“找不到、找错、找到了没用上、引用不准”这几类核心失败。

原型期可以从人工抽查和小样本开始。生产期、对外使用、高风险或频繁迭代的 RAG 系统，必须建立固定评估集、自动回归、人工抽检和线上反馈闭环。

#RAG Eval：Retrieval、Faithfulness 与 Citation Accuracy

#提出问题：RAG 质量为什么不能靠感觉判断

#分析问题：把评估对象拆成链路指标

#收益/成本判断

#列举方案：从抽查到自动回归

#Retrieval Precision / Recall

#Faithfulness

#Citation Accuracy

#评估样本怎么建

#Eval 落地流程

#决策判断：评估深度要匹配风险

#反模式

#结论收束：Eval 上线前工程清单

#小结