
> AI 测试开发面试高频题："你们怎么评测 RAG 系统的质量？"
> 答"看回答得对不对"只能算及格。这篇讲一次真实的"答非所问"故障是怎么定位到检索层的，以及黄金数据集 + 分层评测怎么搭。

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

某家电企业的智能客服上线了 RAG：把产品手册、售后政策文档灌进知识库，用户提问时先检索再生成。上线第二周，有用户问"买的机器第 8 天坏了怎么办"，机器人答："支持 30 天无理由退换货，您可以直接申请退款。"

实际上这家公司的政策是"7 天退货、15 天换货、1 年保修"。用户截图发到社交平台，客服团队花了一整天善后。

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

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

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

第一步，把出问题的那次请求的检索结果捞出来——top3 召回的切片（chunk）里，根本没有那张政策表格。模型是在"手里没有资料"的情况下，靠自己的常识编了一个听起来很合理的政策。这就是幻觉的直接来源。

第二步，查为什么召回不到。原来售后手册是 PDF，政策写在一个三列表格里（时间范围 | 处理方式 | 所需凭证）。入库时用的是默认的按 500 字符切片，表格恰好被从中间切断：上半截进了 chunk-141，下半截进了 chunk-142。每个半截单独看都不完整、语义也不突出，向量化之后检索得分很低，永远轮不到它们被召回。

修复动作本身不复杂：切片策略改成"表格整块保留"，并给每个 chunk 记录来源页码和章节做辅助过滤。但这次故障让团队意识到一个更根本的问题：**知识库天天在更新，这次是表格被切断，下次可能是别的坑，靠用户踩雷来发现问题，代价太大了。**

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

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

把"问题—标准答案—应该命中哪个切片"固化成用例集。起始来源就三个：线上真实日志里的高频问题、这次故障这种踩过的坑、业务专家手工补的边界题。

```python
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 当单元测试跑

知识库每次重建索引，先跑这一层。它不调用大模型，快、便宜、定位准：

```python
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 的四个指标做端到端评测：

```python
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。**

## 五、面试追问，你答得上来吗

1. 黄金数据集要多少条才够？——答：不在多在分布。首批 100~300 条覆盖核心高频场景就能跑起来，之后靠 bad case 回流持续增长；评测价值的增长来自"踩过的坑都在里面"，而不是数量本身。
2. 线上 RAG 效果突然变差，你怎么定位是哪一层的问题？——答：按金字塔从上往下拆：先看 context_recall/precision 判断检索层是否漏召回或召回噪音；检索正常再看 faithfulness 判断生成层是否编造；最后看 answer_relevancy 判断 query 理解和改写。每层有每层的修法，混在一起查就是灾难。
3. faithfulness 评测本身也是大模型打分，怎么信它？——答：用人工标注的子集（比如 50 条）校准裁判：人判"编造"而裁判放过的，说明裁判提示词要调；定期对齐裁判与人工的一致率，把它当成一个需要被测试的组件。

---

下一篇预告：《改了一行 Prompt，用例全红了——Prompt 回归测试与 CI 门禁》


AI 测试开发面试高频题："你们怎么评测 RAG 系统的质量？" 答"看回答得对不对"只能算及格。这篇讲一次真实的"答非所问"故障是怎么定位到检索层的，以及黄金数据集 + 分层评测怎么搭。

RAG 上线后为什么总"答非所问"？黄金数据集与检索质量评测

人工智能

算法

测试

RAG系统评测不能只看回答对错，需构建黄金数据集+分层评测体系。本文通过真实故障案例，展示如何用Recall@K定位检索层问题，用RAGAS四指标监控生成层幻觉，建立测试金字塔实现持续质量保障。

单元测试

回归测试

代码解释

2026上云采购 | AI焕新·智启新局

lexiang

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

RAG 上线后为什么总"答非所问"？黄金数据集与检索质量评测-腾讯云开发者社区-腾讯云

RAG 上线后为什么总"答非所问"？黄金数据集与检索质量评测

RAG 上线后为什么总"答非所问"？黄金数据集与检索质量评测

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐