第 7 章：RAG 与知识链路评测
本页导航
7.1 知识库更新了，为什么 Agent 还在回答过期政策
客服团队发布了新的退款政策。知识库后台显示文档已经上传，运营也确认内容正确。可是客服 Agent 在线上仍然回答过期政策。
这类问题不能简单归为“RAG 效果差”。RAG 是一条链路，错误可能发生在任何环节：
- 文档上传了，但解析失败。
- 文档解析了，但 Chunk 切分破坏了语义。
- Chunk 已经生成，但索引没有刷新。
- 索引刷新了，但 Query 没有召回正确片段。
- 召回正确片段了，但 Rerank 排到了后面。
- 正确片段进入上下文，但模型没有忠实使用。
- 回答正确，但引用指向了错误条款。
RAG 评测的核心，是把“知识回答错了”拆成可诊断链路。
7.2 RAG 链路拆解
一个典型 RAG 链路包含八个环节。
图 7-1 RAG 链路评测点图
flowchart LR
A["文档解析"] --> B["Chunk切分"]
B --> C["Embedding/Index"]
C --> D["Query改写"]
D --> E["召回TopK"]
E --> F["Rerank重排"]
F --> G["上下文组装"]
G --> H["生成与引用"]
| 环节 | 作用 | 常见失败 |
|---|---|---|
| 文档解析 | 将 PDF、网页、表格等转为可检索文本 | 表格丢失、标题层级丢失、乱码 |
| Chunk | 将文档切成检索单元 | 切散规则、混入无关内容、粒度过粗 |
| Embedding / Index | 建立向量或混合索引 | 索引未刷新、版本错配 |
| Query 改写 | 将用户问题改成检索查询 | 丢失实体、过度改写、未扩展同义词 |
| 召回 | 找到候选知识片段 | 正确片段未进入 TopK |
| Rerank | 对候选片段重排 | 正确片段被排低 |
| 上下文组装 | 将片段放入模型上下文 | 截断、顺序不当、证据污染 |
| 生成与引用 | 基于上下文回答并给出依据 | 不忠实、引用错位、无依据承诺 |
评测要能分别观察这些环节，而不是只看最终答案。
7.3 组件指标
RAG 指标可以分为检索侧、上下文侧和生成侧。
| 指标 | 所属环节 | 含义 |
|---|---|---|
| Recall@K | 召回 | 正确证据是否进入 TopK |
| MRR | 召回 / 排序 | 正确证据排名是否靠前 |
| Context Precision | 上下文 | 放入上下文的信息是否相关 |
| Context Recall | 上下文 | 必要证据是否完整进入上下文 |
| Faithfulness | 生成 | 回答是否忠实于上下文 |
| Answer Correctness | 生成 | 回答是否满足业务正确性 |
| Citation Accuracy | 引用 | 引用是否支持答案 |
| Coverage | 知识库 | 关键业务规则是否被覆盖 |
Recall@K、MRR 等检索指标有较成熟的信息检索定义；Context Precision、Context Recall、Faithfulness 和 Answer Correctness 在不同 RAG 评测框架中的计算方法可能不同，有的依赖人工标注，有的依赖模型生成问题或 Judge 判断。报告除指标名外，还应记录公式或评判 Prompt、Evaluator 版本、所需参考证据和聚合方式。同名指标口径不同，分数不可直接横向比较。
Answer Correctness 无法独自解释客服 Agent 的退款政策错误。最终答错时，还要区分 Recall@K 失败、Context Recall 不足和 Faithfulness 失败。
7.4 RAG Case 与运行证据
RAG 评测需要同时保存设计契约和运行证据，但两者属于不同对象：
| 对象 | 字段 | 说明 |
|---|---|---|
| RAG Case | query、scenario、gold_evidence、expected_answer | 定义问题和正确证据边界 |
| RAG Case | context_policy、citation_requirement、Rubric | 定义上下文、引用和评判要求 |
| RAG Case | knowledge_version、index_requirement | 定义适用知识版本和索引条件 |
| Case Result | retrieved_chunks、context、answer、citations | 保存本次 Run 的实际输出 |
| Evaluation Result | recall、MRR、faithfulness、citation_accuracy | 保存各 Evaluator 的判断和证据 |
示例：
下面只展示定位召回与生成问题所需的最小字段，便于首次阅读。7.11 节汇总 RAG 专项字段，第 12 章定义跨类型通用 Case 契约；项目填写和交换以配套《RAG Eval Case 工作表》为准。三者分别承担教学示例、专项增量和可执行工作表职责。
case_id: rag_refund_member_001
input: 我用了优惠券只退一件商品，积分会扣回吗？
scenario: 会员部分退款
gold_evidence:
- refund_policy_member_points_v3#section_2
- coupon_refund_allocation_v5#section_4
expected_behavior:
- 说明优惠券按商品分摊
- 说明积分可能按实际保留金额调整
- 无法确认订单明细时调用工具或转人工
environment_requirements:
corpus_version: refund_kb_20260701
effective_at: 2026-07-08
有了 gold evidence，才能独立评价召回和生成。
7.4.1 Gold Evidence 的标注原则
Gold evidence 标出“支撑正确回答所必需的证据”，其作用不同于扩写参考答案。它决定了 RAG 评测能否从最终答案退回到知识链路。
标注时应遵守四个原则。
第一，证据要足够具体。不要只标注文档 ID，而要标到章节、条款、表格行或政策片段。否则 Recall@K 看似通过，实际进入上下文的可能只是同一文档中的无关内容。
第二，证据要包含适用条件。退款政策中的“7 天无理由”如果没有商品品类、拆封状态、活动规则和生效时间，就不足以支撑复杂回答。
第三，证据要区分必要证据和补充证据。必要证据缺失会导致回答不可靠，补充证据可以改善解释质量但不一定阻断发布。
第四，证据要记录版本和时间。客服政策、会员权益、促销规则都可能变化。没有有效期，评测系统无法判断模型引用的是当前规则还是历史规则。
| 证据类型 | 作用 | 例子 |
|---|---|---|
| 必要证据 | 支撑核心结论 | 部分退款时优惠券按商品分摊 |
| 条件证据 | 限定适用范围 | 仅适用于未超过签收 7 天的订单 |
| 反例证据 | 防止过度概括 | 拆封耳机不适用无理由退货 |
| 时效证据 | 判断规则是否有效 | 记录政策生效时间；示例日期不构成真实政策声明 |
| 审批证据 | 决定是否转人工 | 高金额退款需人工审批 |
好的 gold evidence 能让 RAG 评测回答三个问题：正确知识是否存在，是否被召回，是否被忠实使用。
7.5 文档解析与 Chunk 评测
很多 RAG 问题发生在检索前。
政策文档经常包含表格、脚注、适用条件和例外条款。如果解析后丢失结构，后续检索再强也很难召回正确知识。
文档解析评测应检查：
- 标题层级是否保留。
- 表格是否转成可理解文本。
- 条件和例外是否与主规则绑定。
- 生效时间是否保留。
- 附件、脚注和链接是否处理。
Chunk 评测应检查：
| 问题 | 影响 |
|---|---|
| Chunk 过短 | 条件和结论分离 |
| Chunk 过长 | 检索噪声增加 |
| 边界错误 | 例外条款与主规则断开 |
| 缺少元数据 | 无法按业务线、时间和版本过滤 |
客服退款政策中，“优惠券分摊规则”和“会员积分扣回规则”如果被切到不同无关联 Chunk，模型就可能只看到其中一半。
7.6 召回与排序评测
召回评测的基本问题是：正确证据是否被找到。
对于每个 Query，应检查：
- 正确证据是否进入 Top1、Top3、Top5、Top10。
- 正确证据排名是否稳定。
- 无关片段是否挤占上下文。
- Query 改写是否保留关键实体。
- 过滤条件是否错误排除了正确文档。
Rerank 评测关注：正确片段是否被排到足够靠前的位置。
| 问题 | 可能修复方向 |
|---|---|
| 正确片段未召回 | Query 改写、Embedding、混合检索、索引 |
| 正确片段召回但排名低 | Rerank、业务特征、相似度策略 |
| 无关片段很多 | 过滤、元数据、负样本、Query 路由 |
| 新政策无法召回 | 索引刷新、版本切换、文档同步 |
召回和排序要和知识库版本绑定。否则团队无法判断是策略问题还是数据版本问题。
7.7 上下文组装与生成忠实性
正确 Chunk 被召回，不代表最终回答正确。
上下文组装可能出现：
- 正确片段被截断。
- 正确片段位置太靠后。
- 多个片段互相冲突。
- 缺少生效时间和适用条件。
- 用户问题中的关键实体没有和证据对齐。
生成阶段则关注模型是否忠实使用上下文。
评测可以设计两个对照：
- 给模型正确上下文，看它是否能回答正确。
- 给模型含干扰证据的上下文，看它是否能拒绝错误片段。
如果正确上下文下仍答错，问题更可能在生成忠实性、Prompt 约束或模型能力。如果上下文没有正确证据，问题更可能在 RAG 前链路。
7.8 引用评测
引用不是装饰。企业场景中，引用是可审计证据。
引用评测要判断：
| 维度 | 问题 |
|---|---|
| 存在性 | 回答是否给出引用 |
| 准确性 | 引用片段是否支持答案 |
| 完整性 | 关键结论是否都有证据 |
| 粒度 | 引用是否足够具体 |
| 时效性 | 引用是否来自有效版本 |
客服 Agent 如果回答“积分会扣回”，引用却指向物流退货时效，这种回答不能通过忠实性评测。
7.9 知识库版本与血缘
RAG 评测需要记录知识链路版本。
| 版本字段 | 说明 |
|---|---|
| document_version | 业务文档版本 |
| parser_version | 解析器版本 |
| chunk_strategy | Chunk 策略 |
| embedding_model | Embedding 模型 |
| index_version | 索引版本 |
| retriever_version | 召回策略版本 |
| reranker_version | 重排模型或规则版本 |
| prompt_version | 生成 Prompt 版本 |
没有这些信息，RAG 分数变化无法解释。客服政策更新后回答仍错，到底是文档没进库、索引没刷新，还是召回策略没命中，只能结合版本血缘判断。
7.9.1 知识冲突与时效治理
企业知识库很少是干净的单一事实源。真实系统中经常同时存在客服 SOP、法务条款、运营活动规则、商品品类例外、历史公告和临时补充说明。因此，RAG 评测需要覆盖知识冲突。
常见冲突包括：
| 冲突类型 | 示例 | 评测要求 |
|---|---|---|
| 新旧政策冲突 | 新政策写 7 天，旧政策写 15 天 | 必须识别生效时间和版本 |
| 通用与例外冲突 | 通用可退，耳机拆封不可无理由退 | 必须优先使用适用条件更具体的证据 |
| 渠道规则冲突 | App 与线下门店规则不同 | 必须结合用户渠道和订单来源 |
| 活动规则冲突 | 大促券和普通券退款规则不同 | 必须检索活动规则而非只看退款总则 |
| 人工审批冲突 | 政策允许退，但金额超过自动化上限 | 必须触发人工审批 |
因此，RAG Case 不应只包含 query 和 answer，还应包含适用上下文：用户身份、订单渠道、商品品类、活动类型、时间点、金额等级和审批边界。没有这些条件，评估器会把“看似正确的通用回答”误判为通过。
知识冲突不应完全交给模型临场判断。知识链路要提供可判定的元数据：生效时间、失效时间、业务线、优先级、适用范围、审批要求和数据 Owner；评测再验证这些元数据是否被召回、进入上下文并影响最终回答。
7.10 交付物一：RAG 链路失效模式与指标表
7.2 节用于理解链路与失败现象，本表用于把失败转成指标和诊断动作，是章内权威速查版。指标名称不能脱离数据标注和计算口径使用；Recall@K、MRR、忠实性与引用准确率的定义以本章和术语表为准。
| 链路环节 | 失效模式 | 指标 |
|---|---|---|
| 文档解析 | 表格、标题、条件丢失 | 解析完整率、结构保留率 |
| Chunk | 规则切散、噪声混入 | Chunk 完整性、边界正确率 |
| Embedding / Index | 文档未入库、版本错配 | 索引覆盖率、版本一致性 |
| Query 改写 | 实体、条件或业务意图丢失 | 实体保留率、改写忠实度 |
| 召回 | 正确证据未进入 TopK | Recall@K |
| Rerank | 正确证据排名低 | MRR、NDCG |
| 上下文组装 | 截断、污染、缺条件 | Context Recall / Precision |
| 生成与引用 | 不忠实、无依据承诺、引用错位 | Faithfulness、Correctness、Citation Accuracy |
这张表用于把 RAG 错误定位到具体链路。
7.11 交付物二：RAG Eval Case Schema
case_id:
case_version:
scenario:
input:
query_metadata:
user_type:
channel:
business_line:
gold_evidence:
- document_id:
section_id:
text:
effective_time:
expected_behavior:
context_policy:
citation_requirement:
environment_requirements:
corpus_version:
effective_at:
evaluation_metrics:
- recall_at_k
- mrr
- faithfulness
- answer_correctness
- citation_accuracy
rubric:
这份 Schema 只描述可复用的 RAG Case。实际召回、上下文、答案和引用写入第 18 章定义的 Case Result；指标值、判断理由和证据写入 Evaluation Result。三者通过 run_id、case_id 和 case_version 关联，历史结果不得回写覆盖 Case。
本表只列 RAG 相对通用 Case 新增的字段，不另行定义 owner、risk_level、evaluator_config 等治理字段；这些通用字段以第 12 章和配套工作表为准。
7.12 常见误区
7.12.1 只看最终答案
最终答案错了，仍无法区分检索错误和生成错误。中间证据用来完成这一步定位。
7.12.2 没有 gold evidence
没有标准证据，就无法评价召回质量。
7.12.3 忽略知识版本
政策类问题需要记录知识版本和生效时间，否则评测结论不可解释。
7.12.4 把引用当成可信保证
模型给出引用，不代表引用支持答案。引用本身也要评测。
7.13 方法依据与延伸阅读
- RAGAS: Automated Evaluation of Retrieval Augmented Generation：提出面向 RAG 的 Context Relevance、Faithfulness 等自动评测思路。
- ARES: An Automated Evaluation Framework for Retrieval-Augmented Generation Systems：展示使用校准过的模型评估 Context Relevance、Answer Faithfulness 和 Answer Relevance，并结合统计推断的方案。
这些框架提供可复用思路，不构成统一行业标准。企业使用时仍需用领域人工标签校准 Evaluator，并保留具体计算口径。
7.14 本章小结
RAG 评测的关键，是把知识回答错误拆解到文档解析、Chunk、Embedding / 索引、Query 改写、召回、Rerank、上下文组装、生成与引用八个环节。
客服 Agent 回答过期政策时，团队要沿知识链路回查：正确证据是否存在、是否入索引、是否召回、是否进入上下文，以及模型是否忠实使用。
下一章，我们将评测范围从知识链路扩展到工具调用、记忆管理和工作流编排，完成 Agent 系统的全组件评测框架。