一、真实故障：机器人凭空生成了一条退款政策
某家电企业的智能客服接入了 RAG 方案：将产品手册、售后政策等文档导入知识库，用户提问时先做检索，再由模型生成答案。上线第二周，有用户咨询“买的机器第 8 天坏了怎么办”，机器人回复：“支持 30 天无理由退换货，您可以直接申请退款。”
但这家公司的实际售后政策明明是“7 天退货、15 天换货、1 年保修”。用户将截图发到社交平台后，客服团队花了一整天才把问题处理完。
事后复盘时，最让人意外的一点是：知识库里其实就有这条政策，而且就在售后手册第 12 页的一张表格中。
二、排查：问题不在大模型，而在检索环节
团队顺着 RAG 的完整链路逐步拆解，只用两步就定位到了根因：
第一步，把出问题那次请求的检索结果捞出来看——top3 召回的切片（chunk）里，压根没有那张政策表格。模型是在“手里没资料”的情况下，凭自己的常识编出了一条听起来很合理的政策。这正是幻觉产生的直接原因。
第二步，继续排查为什么检索召回不到。原来售后手册是 PDF 格式，政策信息写在一个三列表格里（时间范围 | 处理方式 | 所需凭证）。入库时采用了默认的按 500 字符切片，结果表格刚好从中间被截断：上半部分进了 chunk-141，下半部分进了 chunk-142。两个半截单独看都不完整，语义特征也不明显，向量化之后检索得分很低，自然长期无法被稳定召回。
修复动作本身并不复杂：把切片策略改成“表格整块保留”，并为每个 chunk 记录来源页码和章节信息，作为辅助过滤条件。但这次线上故障让团队意识到一个更深层的问题：知识库每天都在更新，这次是表格被切断，下次可能就是别的文档结构问题。如果只能靠用户踩坑来暴露问题，成本实在太高。
三、核心方法：黄金数据集 + 两层评测
第 1 步：建立黄金数据集（Golden Dataset）
把“用户问题—标准答案—预期命中的切片”固化成测试用例集。起始来源主要有三个：线上真实日志中的高频问题、像这次故障一样已经踩过的 bad case，以及业务专家手工补充的边界场景题。
GOLDEN = [{ "question": "买的机器第8天坏了怎么办","ground_truth": "已超7天退货期，在15天换货期内，可申请换货；需上传故障照片与订单号","expected_chunk_id": "售后手册v3#chunk-142", # 应该命中的切片},{ "question": "你们支持30天无理由退货吗", # 诱导性问题"ground_truth": "不支持。退货政策为7天退货、15天换货、1年保修","expected_chunk_id": "售后手册v3#chunk-142",},# ……首批 100~300 条，覆盖核心场景，持续追加]第 2 步：检索层测试——把 Recall@K 当单元测试来跑
知识库每次重建索引前后，都先跑这一层。它不依赖大模型，速度快、成本低，而且定位问题非常直接：
def test_retrieval_recall_at_k(k=3):"""标准答案所在的切片必须进入 top-k，命中率 >= 95%"""miss = []for case in GOLDEN:chunks = retriever.search(case["question"], top_k=k)if not any(c.id == case["expected_chunk_id"] for c in chunks):miss.append(case["question"])rate = 1 - len(miss) / len(GOLDEN)assert rate >= 0.95, f"检索召回率 {rate:.1%}，未命中：{miss[:3]}"像这次故障中“表格被切断”导致召回失败的问题，在这类用例面前几乎无处可藏——只要切片策略一变，召回率立刻下降，CI 也会第一时间报警变红。
第 3 步：生成层评测——用 RAGAS 盯住“模型编造”
检索层通过之后，还要继续验证模型是否忠实地依据检索内容作答。这里可以用 RAGAS 的四个核心指标做端到端评测：
from datasets import Datasetfrom ragas import evaluatefrom ragas.metrics import (faithfulness,# 忠实度：回答是否只基于检索到的内容（防编造的核心指标）context_precision, # 上下文精度：召回的内容里有多少是真有用的context_recall,# 上下文召回：该召回的内容是否都召回了answer_relevancy,# 回答相关性：是不是答非所问)def nightly_rag_eval():rows = []for case in GOLDEN:contexts, answer = rag_pipeline.query(case["question"])rows.append({ "question": case["question"],"answer": answer,"contexts": contexts,"ground_truth": case["ground_truth"],})report = evaluate(Dataset.from_list(rows), metrics=[faithfulness, context_precision, context_recall, answer_relevancy,])# 忠实度是红线：低于阈值说明模型在编，宁可拒答也不能编assert report["faithfulness"] >= 0.9, f"忠实度 {report['faithfulness']:.2f} 不达标"return report这四个指标本质上分别盯住了 RAG 系统的不同环节：如果 context_recall 偏低，通常说明检索没有捞全，优先回头检查切片策略和索引构建；如果 context_precision 不够理想，往往意味着召回结果混入了较多噪音，此时要重点看 top_k 设置和重排序逻辑；一旦 faithfulness 下降，基本就是模型开始“自由发挥”了，需要加强生成侧约束，或者补充明确的拒答指令；至于 answer_relevancy 偏低，本质上就是回答偏题，重点排查 query 理解与改写链路。换句话说，把这些评测指标连起来看，就是一张非常实用的 RAG 故障定位地图。
四、沉淀成方法：RAG 测试金字塔
| 层级 | 测什么 | 核心指标 | 什么时候跑 |
|---|---|---|---|
| 检索层 | 找得到吗 | Recall@K、context_recall / precision | 每次索引重建（快、便宜，当单测跑） |
| 生成层 | 会编吗 | faithfulness | 每晚全量评测 |
| 端到端 | 答得对吗 | answer_relevancy 人工抽检 | 发布前冒烟 |
这套方法通常还会搭配三条工程纪律。第一，黄金数据集尽量来自线上真实日志，因为靠拍脑袋编出来的测试用例，很难覆盖真实用户问题分布；第二，每一个 bad case 都必须及时回流为测试用例，用户已经踩过一次的坑，就不该再出现第二次；第三，知识库一旦更新，就必须同步触发评测流程，要把“重建索引”视作一次代码变更来做回归测试，而不是只当成普通运维动作处理。另外，数据集中还应专门预留一类“无法回答”的用例，比如询问竞品政策，或者追问知识库范围之外的内容，预期结果就是让模型明确拒答——只有能稳定拒答的 RAG 系统，才算真正达到及格线。
五、面试追问，你真的答得上来吗
黄金数据集要多少条才够？——答：关键不在数量，而在分布。首批 100~300 条只要覆盖核心高频场景，就足够把评测体系跑起来；后续再依靠 bad case 回流持续扩充。评测价值的增长，来自“踩过的坑是否都被纳入数据集”，而不是单纯堆数量。 线上 RAG 效果突然变差，你怎么定位是哪一层出了问题？——答：按测试金字塔从上往下拆。先看 context_recall / precision，判断检索层是否存在漏召回或噪音召回；检索层正常，再看 faithfulness，判断生成层是否出现编造；最后再看 answer_relevancy，排查 query 理解和改写是否出了偏差。每一层都有各自的定位方法和修复手段，混在一起查，基本就是灾难。 faithfulness 评测本身也是由大模型打分，怎么才能信它？——答：可以用人工标注的子集（例如 50 条）来校准“裁判模型”：凡是人工判断为“编造”但裁判放过的，就说明裁判提示词还需要调整；同时定期对齐裁判与人工的一致率，把评测器本身也当作一个需要持续测试和校准的组件。下一篇预告：《改了一行 Prompt，用例全红了——Prompt 回归测试与 CI 门禁》
