面试题 · 评估
搜索「评测集」匹配到口述回答，相关段落已展开。查看匹配内容 ↓
请详细阐述评估一个RAG（检索增强生成）系统效果的主要方法和指标。
RAG评估需分检索层、生成层、端到端三个维度展开：
关注"找得准不准、全不全"：
按学习路线查看教程、项目和面试题。
关注"答得对不对、好不好"：
传统NLP指标（有参考答案时）：
无参考答案指标（更实用）：
场景切入
假设我们做电商客服RAG，用户问‘这个充电宝支持快充吗？’，系统可能会从商品文档检索，也可能从对话历史里找，你怎么评估这个检索和生成的整体效果？
层层追问
RAG上线后，你怎么知道它好不好？……检索和生成是不是分开看？……那有没有一些自动化的指标能同时评估两者？
直球架构
评估一个RAG系统的效果，你从哪几个维度设计指标？检索层和生成层分别用什么指标？端到端评估你会怎么做？
这道题其实问的是，怎么把一个[[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可能今天准明天就不准了。这时候怎么持续维护评测集，其实比选指标更头疼。
总的来说，我更倾向把评估看成一套分层监控体系，而不是单个指标。每个层次选一两个最关键的指标，配上人工分析，才能真的落地。