一、真实故障：机器人编造了一条退款政策

某家电企业的智能客服上线了 RAG：把产品手册、售后政策文档灌进知识库，用户提问时先检索再生成。

上线第二周，有用户问“买的机器第 8 天坏了怎么办”，机器人答：“支持 30 天无理由退换货，您可以直接申请退款。”

实际上这家公司的政策是“7 天退货、15 天换货、1 年保修”。

用户截图发到社交平台，客服团队花了一整天善后。

复盘时最反直觉的一点是：知识库里明明有这条政策，就在售后手册第 12 页的一张表格里。

二、排查：问题不在模型，在检索

团队沿着 RAG 的链路拆开看，两步就定位了问题。

第一步：先看检索结果

把出问题那次请求的检索结果捞出来后发现，top3 召回的切片（chunk）里，根本没有那张政策表格。

模型是在“手里没有资料”的情况下，靠自己的常识编了一个听起来很合理的政策。

这就是幻觉的直接来源。

第二步：再查为什么召回不到

原来售后手册是 PDF，政策写在一个三列表格里（时间范围 | 处理方式 | 所需凭证）。

入库时用的是默认的按 500 字符切片，表格恰好被从中间切断：上半截进了 chunk-141，下半截进了 chunk-142。

每个半截单独看都不完整，语义也不突出。向量化之后检索得分很低，永远轮不到它们被召回。

修复动作本身不复杂：切片策略改成“表格整块保留”，并给每个 chunk 记录来源页码和章节做辅助过滤。

但这次故障让团队意识到一个更根本的问题：知识库天天在更新，这次是表格被切断，下次可能是别的坑。

靠用户踩雷来发现问题，代价太大了。

三、核心代码：黄金数据集 两层评测

第 1 步：建黄金数据集（Golden Dataset）

把“问题—标准答案—应该命中哪个切片”固化成用例集。

起始来源就三个：

• 线上真实日志里的高频问题
• 这次故障这种踩过的坑
• 业务专家手工补的边界题

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

这四个指标，其实各自盯着不同环节。

• 如果 context_recall 偏低，通常意味着检索没捞全，优先回头检查切片和索引。
• 如果 context_precision 不理想，往往说明召回里混进了不少噪音，这时候就该看 top_k 和重排序。
• faithfulness 一旦偏低，基本就是模型开始“自由发挥”了，需要补生成侧约束或加入拒答指令。
• 如果 answer_relevancy 偏低，本质上就是答偏了题，重点排查 query 改写。

说白了，这些指标连在一起看，就是一张很实用的故障定位地图。

四、沉淀成方法：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 门禁》