第 7 章：RAG 与知识链路评测
第 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 | 知识库 | 关键业务规则是否被覆盖 |
客服 Agent 的退款政策评测不能只看 Answer Correctness。如果最终答错，需要知道是 Recall@K 失败、Context Recall 不足，还是 Faithfulness 失败。
7.4 RAG Case 的证据结构
一个 RAG Eval Case 至少应包含：
| 字段 | 说明 |
|---|---|
| query | 用户问题 |
| scenario | 业务场景 |
| gold_evidence | 期望召回的证据片段 |
| expected_answer | 期望行为或答案要点 |
| retrieved_chunks | 实际召回片段 |
| context | 进入模型的上下文 |
| answer | 模型最终回答 |
| citation | 回答引用 |
| Rubric | 评分规则 |
| knowledge_version | 知识库版本 |
| index_version | 索引版本 |
示例：
case_id: rag_refund_member_001
query: 我用了优惠券只退一件商品，积分会扣回吗？
scenario: 会员部分退款
gold_evidence:
- refund_policy_member_points_v3#section_2
- coupon_refund_allocation_v5#section_4
expected_answer:
- 说明优惠券按商品分摊
- 说明积分可能按实际保留金额调整
- 无法确认订单明细时调用工具或转人工
knowledge_version: refund_kb_20260701
index_version: refund_index_20260701_02
有了 gold evidence，才能独立评价召回和生成。
7.4.1 Gold Evidence 的标注原则
Gold evidence 不是把参考答案写长一点，而是标出“支撑正确回答所必需的证据”。它决定了 RAG 评测能否从最终答案退回到知识链路。
标注时应遵守四个原则。
第一，证据要足够具体。不要只标注文档 ID，而要标到章节、条款、表格行或政策片段。否则 Recall@K 看似通过，实际进入上下文的可能只是同一文档中的无关内容。
第二，证据要包含适用条件。退款政策中的“7 天无理由”如果没有商品品类、拆封状态、活动规则和生效时间，就不足以支撑复杂回答。
第三，证据要区分必要证据和补充证据。必要证据缺失会导致回答不可靠，补充证据可以改善解释质量但不一定阻断发布。
第四，证据要记录版本和时间。客服政策、会员权益、促销规则都可能变化。没有有效期，评测系统无法判断模型引用的是当前规则还是历史规则。
| 证据类型 | 作用 | 例子 |
|---|---|---|
| 必要证据 | 支撑核心结论 | 部分退款时优惠券按商品分摊 |
| 条件证据 | 限定适用范围 | 仅适用于未超过签收 7 天的订单 |
| 反例证据 | 防止过度概括 | 拆封耳机不适用无理由退货 |
| 时效证据 | 判断规则是否有效 | 政策自 2026-07-01 起生效 |
| 审批证据 | 决定是否转人工 | 高金额退款需人工审批 |
好的 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 链路失效模式与指标表
| 链路环节 | 失效模式 | 指标 |
|---|---|---|
| 文档解析 | 表格、标题、条件丢失 | 解析完整率、结构保留率 |
| Chunk | 规则切散、噪声混入 | Chunk 完整性、边界正确率 |
| 索引 | 文档未入库、版本错配 | 索引覆盖率、版本一致性 |
| 召回 | 正确证据未进入 TopK | Recall@K |
| Rerank | 正确证据排名低 | MRR、NDCG |
| 上下文 | 截断、污染、缺条件 | Context Recall / Precision |
| 生成 | 不忠实、无依据承诺 | Faithfulness、Correctness |
| 引用 | 引用不支持答案 | Citation Accuracy |
这张表用于把 RAG 错误定位到具体链路。
7.11 交付物二：RAG Eval Case Schema
case_id:
scenario:
query:
query_metadata:
user_type:
channel:
business_line:
gold_evidence:
- document_id:
section_id:
text:
effective_time:
expected_behavior:
retrieved_chunks:
context:
answer:
citations:
versions:
document_version:
index_version:
embedding_model:
retriever_version:
reranker_version:
prompt_version:
metrics:
recall_at_k:
mrr:
faithfulness:
answer_correctness:
citation_accuracy:
rubric:
Schema 的核心是把证据、上下文、答案和版本放在同一个 Case 中，支持后续归因。
7.12 常见误区
7.12.1 只看最终答案
最终答案错了，不能说明是检索错还是生成错。必须保留中间证据。
7.12.2 没有 gold evidence
没有标准证据，就无法评价召回质量。
7.12.3 忽略知识版本
政策类问题必须记录知识版本和生效时间，否则评测结论不可解释。
7.12.4 把引用当成可信保证
模型给出引用，不代表引用支持答案。引用本身也要评测。
7.13 本章小结
RAG 评测的关键，是把知识回答错误拆解到文档解析、Chunk、索引、召回、排序、上下文、生成和引用各环节。
客服 Agent 回答过期政策时，团队不能只看最终回答，而要追踪正确证据是否存在、是否入索引、是否召回、是否进入上下文，以及模型是否忠实使用。
下一章，我们将评测范围从知识链路扩展到工具调用、记忆管理和工作流编排，完成 Agent 系统的全组件评测框架。