跳到正文

RAG 失败场景诊断

RAG 失败类型及其诊断指标，补充适用边界与工程取舍

原题：请详细阐述评估一个RAG（检索增强生成）系统效果的主要方法和指标。

评估与监控 · 小鹏真题

30 秒回答

  1. 区分检索评估和生成评估两个层面
  2. 掌握经典指标如Recall@K、MRR、BLEU、ROUGE
  3. 理解端到端评估框架RAGAS的核心指标
  4. 知道人工评估与自动评估的权衡

回答与解析

答案要点

  • 区分检索评估和生成评估两个层面
  • 掌握经典指标如Recall@K、MRR、BLEU、ROUGE
  • 理解端到端评估框架RAGAS的核心指标
  • 知道人工评估与自动评估的权衡
  • 了解业务场景下的定制化评估需求

RAG评估需分检索层、生成层、端到端三个维度展开：

一、检索评估（Retrieval Metrics）

关注"找得准不准、全不全"：

  • Recall@K：正确答案在Top-K检索结果中的比例，RAG最核心指标
  • Precision@K：Top-K中相关文档的比例
  • MRR（平均倒数排名）：正确答案排名的倒数均值，反映排序质量
  • NDCG：考虑文档相关性分级的精细排序指标

二、生成评估（Generation Metrics）

关注"答得对不对、好不好"：

传统NLP指标（有参考答案时）：

  • BLEU/ROUGE：n-gram匹配度，适合事实性问答
  • BERTScore：语义相似度，比n-gram更鲁棒

无参考答案指标（更实用）：

  • RAGAS框架：Faithfulness（忠实度，答案是否基于检索内容）、Answer Relevance（答案相关性）、Context Relevance（上下文相关性）
  • Self-check：让模型自己判断答案是否有幻觉

三、端到端与业务评估

  • 端到端准确率：完整问答链路的正确率
  • 延迟与成本：检索耗时、Token消耗
  • 人工抽检：Bad case分析，建立错误分类体系（检索失败/理解错误/幻觉/格式问题）

实践建议

  1. 分层监控：线上先卡检索Recall，再优化生成质量
  2. 构建评估集：从真实日志采样，覆盖高频Query和边界Case
  3. A/B测试：检索策略、Prompt、重排序模型的对比实验

口语版讲法(约4分钟)

  • 评估RAG要分层，检索和生成分开看
  • 检索层核心是Recall@K，业务场景决定用什么
  • 生成层用RAGAS框架最实用，Faithfulness是关键
  • 端到端要结合人工抽检，关注失败分类

这道题其实问的是，怎么把一个RAG系统的效果真正量化出来，而不是凭感觉说好不好。我的思路是把它拆成两层来看，检索层和生成层，因为这两步出错的模式完全不同，评估方法也得分开。

先说检索层，核心就是看召回准不准，最关键的指标是 Recall@K。举个例子，客服系统里用户查退款政策，如果正确答案在Top 3检索结果里，就算召回成功。Recall@K直接决定了后面生成的上限，如果没召回，后面做得再好也没用。其他像Precision@K、MRR这些，更多是调优排序质量时用的，但真正上线我会优先盯Recall@K。这里有个前提，就是你的评测集里得标注了正确答案对应的文档ID，不然算不了。很多项目倒在这一步，标注成本被低估了。

生成层就比较复杂了。传统的方法比如BLEU、ROUGE，适合有标准答案的场景，比如产品手册问答，但放到开放域对话里就不太行了，因为答案可以多样。所以我更倾向用 RAGAS 这套框架，它不依赖标准答案，而是从三个维度打分：Faithfulness（忠实度）、Answer Relevance（答案相关性）、Context Relevance（上下文相关性）。其中 Faithfulness 是最重要的，它衡量答案有没有基于检索来的文档，有没有瞎编。说白了，就是防幻觉。你可以这么理解，检索层把食材找回来，生成层负责做菜，Faithfulness 就是看菜里有没有加不该加的东西。

端到端评估也不能只看这两个指标。实际业务里我会搭配人工抽检，尤其是Bad case分析。比如电商场景下，用户问满减政策，如果系统答错了，得归类是检索没找到对的文档，还是模型理解错了，还是格式问题。建立这个错误分类体系，比堆指标更有用。另外，延迟和Token成本也得监控，毕竟线上系统不是跑分高就行。

这里有一个常见失败场景：很多人只盯着Recall@K和Faithfulness，但忽略了 Context Relevance。比如检索回来一堆相关但不聚焦的文档，模型可能被带偏，答得又长又乱。上线我会特别关注这个，如果Context Relevance低，说明检索策略太宽了，得调Chunk大小或者加Rerank。

所以我的做法是，先用Recall@K卡住检索底线，再拿RAGAS的Faithfulness优化生成质量，最后靠人工抽检兜底。不过这里有个延伸点：如果业务场景里文档更新很频繁，比如政策每周变，那评测集的时效性就成了大问题，Recall@K可能今天准明天就不准了。这时候怎么持续维护评测集，其实比选指标更头疼。

总的来说，我更倾向把评估看成一套分层监控体系，而不是单个指标。每个层次选一两个最关键的指标，配上人工分析，才能真的落地。

关键一句:文档频繁更新时，评测集的时效性维护比选指标更关键

面试官还可能这样问

  1. 问法 1 · 场景切入

    假设我们做电商客服RAG，用户问‘这个充电宝支持快充吗？’，系统可能会从商品文档检索，也可能从对话历史里找，你怎么评估这个检索和生成的整体效果？

  2. 问法 2 · 层层追问

    RAG上线后，你怎么知道它好不好？……检索和生成是不是分开看？……那有没有一些自动化的指标能同时评估两者？

  3. 问法 3 · 直球架构

    评估一个RAG系统的效果，你从哪几个维度设计指标？检索层和生成层分别用什么指标？端到端评估你会怎么做？

同模块相关题目