在真正把 RAG 系统用于生产之前，多数人对“评估”这件事的优先级其实放的比较低。
那时更多关注的是功能是否完整、链路是否跑通，而不是系统在长期运行中的稳定性和可信度。
直到系统开始被真实用户频繁使用，问题才逐渐暴露出来：
有些回答非常准确，有些却明显不可靠，但很难用一句话解释清楚原因。
更关键的是，当问题出现时，并没有一套清晰的方法去判断——
到底是检索阶段出了问题，还是生成阶段本身存在不稳定性。
这篇文章并不是对现有 RAG 评估方法的系统性综述，而是基于多个真实项目中逐步形成的一套工程化经验总结。
它不追求形式上的完整，而更强调：在实际工程环境中，这些评估方法是否真的能指导决策。
一、一个先行结论：多数问题并非出在生成阶段
在不少团队中，RAG 系统效果不佳时，第一反应往往是：
- 调整 Prompt
- 更换模型
- 引入更复杂的系统提示或约束
这些手段有时确实有效，但在我经历的多个项目中，一个反复出现的事实是：
❝
「当生成结果长期不稳定时，根本原因往往并不在生成模型，而在更前面的检索阶段。」
❞
如果检索结果本身已经偏离用户问题，那么无论模型能力多强，生成阶段都只能在错误上下文中“自圆其说”。
这类问题的危险之处在于：「系统不会直接失败，而是逐渐变得“不值得信任”。」
二、RAG 评估的拆分方式：以定位问题为核心
在工程实践中，我并不追求评估框架的形式优雅，而更关心它是否有助于快速定位问题。
最终我形成了一种相对简单的拆分顺序：
- 先评估检索
- 再评估生成
- 最后观察端到端表现
这个顺序并非理论最优，但在实践中非常稳定。
如果直接从端到端结果入手，往往只能看到“效果变差了”，却很难判断问题具体出在哪一层。
三、检索评估：RAG 系统中最值得投入精力的部分
在当前阶段，我几乎把检索评估视为 RAG 项目的前置条件。
如果这一层缺乏基本的量化认知，后续所有调优都很容易陷入盲目尝试。
3.1 实际使用的核心指标
在多数项目中，我关注的指标并不多，主要集中在以下几项：
- Recall@5 / Recall@10
- MRR
- NDCG@10
选择这些指标并非出于学术完整性，而是因为它们与工程决策之间存在直接映射关系。
- 「Recall@10」 ：对我而言回答的是一个非常具体的问题：
正确文档是否有机会进入模型的上下文窗口。如果答案是否定的，那么生成阶段的正确性就失去了讨论基础。 - 「MRR」 ：则用于暴露排序层面的问题。
在一些系统中，相关文档虽然能被检索到，但长期处于靠后位置，模型更容易被前部“次相关”内容干扰。 - 「NDCG」 ：更多用于需要区分相关性强弱的场景，在排序策略调整时会提供额外参考。也可以考虑用相关性（Relevance）来替代该指标，在 4.1 小节有详细介绍。
如果资源有限，我通常建议优先确保 Recall 和 MRR 的可控性。
3.2 在缺乏标注数据的情况下如何推进
“没有 ground truth，无法评估”是一个非常常见的阻力。
但从工程角度来看，这更多是一个程度问题，而非是非问题。
我在实践中采用过几种方式：
「小规模人工标注」
不追求覆盖面，只关注系统最容易出问题的查询类型。
几十条高质量样本，往往比大量弱标签更有价值。
「基于 LLM 的相关性判断」
让模型对 query 与文档之间的相关性进行打分，并给出简要理由。
这类结果不适合用作绝对指标，但在对比不同版本的检索策略时非常有效。
「弱规则辅助判断」
例如标题命中、关键词覆盖率或业务标签匹配。这些方法不精细，但可以作为早期信号。
总体而言，检索评估并不要求一开始就做到精确，但必须做到“可持续”。
四、生成评估：在 RAG 场景下，需要重新理解“相关性”
在早期阶段，我也尝试过沿用传统生成任务中的评估思路，例如通过 BLEU、ROUGE 或语义相似度来衡量输出质量。但在 RAG 系统中，这类指标很快暴露出局限性。
问题并不在于指标本身是否“科学”，而在于它们默认了一个前提：
「生成模型面对的是一个已经正确的问题—上下文对。」
而在 RAG 中，这个前提本身往往并不成立。
因此，在实际工程中，我逐渐将生成评估的关注点，从“答案像不像标准答案”，转移到几个更基础、但也更关键的问题上。
4.1 关于相关性：需要拆成两个不同层面
在 RAG 评估中，“相关性（Relevance）”这个概念经常被混在一起使用，但在工程实践中，我更倾向于将其明确拆成两个层面：
「第一层：召回片段与问题的相关性」
这一层本质上仍然属于检索质量，但它直接影响生成阶段的可控性。
如果召回内容本身与问题偏离，即便模型生成的答案在语言层面看起来合理，也往往是在“围绕错误上下文进行发挥”。
在一些问题分析中，我见过这样的情况：
- 生成答案与问题表面相关
- 但其依据的文档，与问题的核心约束并不匹配
如果不单独评估“召回片段 ↔ 问题”的相关性，这类问题在生成评估中很容易被掩盖。当然这个相关性评估是需要在检索阶段就进行的。
「第二层：答案与问题 / 召回片段的相关性」
这是更接近传统生成评估的部分，但在 RAG 中需要额外关注一个点：
答案是否忠实地反映了检索内容，而不是对问题进行泛化回答。
这两个层面的相关性，在评估时应当被明确区分，否则很难判断问题究竟出在检索侧还是生成侧。
4.2 忠实度仍然是生成评估中的核心约束
相比“相关性”，我个人在 RAG 项目中对“忠实度（Faithfulness）”的关注度更高。
原因很现实：
在多数业务场景中，用户对错误信息的容忍度，远低于对不完整信息的容忍度。
因此，在生成评估中，我通常优先回答以下问题：
- 生成内容是否完全基于检索片段
- 是否引入了检索中不存在的事实
- 是否对原文含义进行了扩展或重解释
这类问题并不容易用规则完全覆盖，因此在工程上，借助 LLM 进行辅助判断是一种相对务实的选择。 如 RAGAs 框架的设计理念就是如此。
五、评估流程的现实版本：不要指望一次评估把问题说清楚
如果从工程落地的角度回看，大多数 RAG 项目的评估流程，最终都会走向一种“非理想形态”。
不是因为工程师不专业，而是因为现实系统里存在太多不可控因素：数据分布在变、问题类型在变、模型版本在变，甚至连“什么算好答案”本身都会随业务阶段发生变化。
在这种前提下，我个人并不太认同那种“一套评估体系覆盖所有阶段”的设计思路。
在实际项目中，我更倾向于将评估拆成几个目的明确、但覆盖面有限的阶段性检查：
-
「在检索侧」，评估的目标并不是“召回是否完美”，而是确认：
❝
「系统是否在持续地把明显无关的内容喂给生成模型」
❞
-
「在生成侧」，重点也不是语言质量，而是：
❝
「模型是否在稳定地产生不可接受的事实性错误」
❞
只要这两个问题没有被控制住，端到端评估往往只是在重复放大已有问题，很难给出新的工程结论。
六、关于评估指标：不是越多越好，而是越“敢用”越好
这是我在 RAG 项目中感受最明显的一点。
很多评估体系在设计阶段看起来非常完整：
相关性、忠实度、覆盖率、多样性、上下文利用率……
指标本身都没有问题，问题在于——它们很少真的被用来做决策。
在一次项目复盘中，我们团队曾经花了不少时间维护一套评估面板，但后来逐渐发现：
- 指标变化与线上效果之间的因果关系并不清晰
- 当指标变差时，很难据此直接定位应当修改哪一层策略
- 最终，评估结果更多是“被看见”，而不是“被使用”
从那之后，我对评估指标的态度变得更加保守。
我现在更关注的是：
- 这个指标变差到什么程度，我会真的去改系统？
- 它能否明确指向某一个可操作的工程调整？
- 如果今天删掉这个指标，是否会对决策造成实质影响？
如果答案是否定的，那这个指标即便再“合理”，在工程上也值得被简化，甚至被移除。
七、评估的最终价值：不是提高分数，而是提前暴露系统失效方式
很多关于 RAG 评估的讨论，最终都会落在“如何让指标更好看”上。
但从工程负责人的角度来看，我更关心另一件事：
❝
「这个系统在什么情况下会出问题？」
❞
是面对跨文档问题时？
是面对时间敏感信息时？
还是在上下文稍微变长之后，开始出现稳定幻觉？
如果评估体系无法回答这些问题，那么即便分数看起来不错，也很难让我对系统的可控性产生信心。
因此，在后期阶段，我往往会有意引入一些“并不友好”的评估方式，例如：
- 刻意使用边界问题或异常输入
- 观察系统是否出现模式化错误，而不是单点失败
- 更关注错误是否具有一致性，而非错误率本身
这些评估方式并不优雅，也很难标准化，但它们往往更贴近系统真实的失效路径。
从这个角度看，RAG 评估并不是为了证明系统“已经足够好”，
而是为了让工程团队在系统变复杂之前，就已经知道它可能会以什么方式失控。
