AI 测试开发面试高频题："你们怎么评测 RAG 系统的质量？"
答"看回答得对不对"只能算及格。这篇讲一次真实的"答非所问"故障是怎么定位到检索层的，以及黄金数据集 + 分层评测怎么搭。
一、真实故障：机器人编造了一条退款政策
某家电企业的智能客服上线了 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 Dataset
from ragas import evaluate
from 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 才是及格的 RAG。
五、面试追问，你答得上来吗
- 黄金数据集要多少条才够？——答：不在多在分布。首批 100~300 条覆盖核心高频场景就能跑起来，之后靠 bad case 回流持续增长；评测价值的增长来自"踩过的坑都在里面"，而不是数量本身。
- 线上 RAG 效果突然变差，你怎么定位是哪一层的问题？——答：按金字塔从上往下拆：先看 context_recall/precision 判断检索层是否漏召回或召回噪音；检索正常再看 faithfulness 判断生成层是否编造；最后看 answer_relevancy 判断 query 理解和改写。每层有每层的修法，混在一起查就是灾难。
- faithfulness 评测本身也是大模型打分，怎么信它？——答：用人工标注的子集（比如 50 条）校准裁判：人判"编造"而裁判放过的，说明裁判提示词要调；定期对齐裁判与人工的一致率，把它当成一个需要被测试的组件。
下一篇预告：《改了一行 Prompt，用例全红了——Prompt 回归测试与 CI 门禁》
