如何评估 RAG 系统的效果？常用的评估指标有哪些？

面试考察点

1. 评估体系意识：面试官不光看你能不能搭系统，更想看你有没有能力把系统的好坏量化出来。RAG 上线后没有评估，等于盲飞。
2. 指标专业度：检索阶段和生成阶段分别该看哪些指标，你能不能说清楚？Faithfulness、Context Recall 这些词有没有听过？
3. 工程落地经验：RAGAS、DeepEval 这类评估框架用过没有？Java 选手知不知道 Spring AI 自带的 RelevancyEvaluator？还是只靠肉眼看一眼 "好像挺对"？
4. 踩坑反思：评估难在哪？为啥不能只看一个准确率？

核心答案

RAG 系统的评估，光凭一句 "回答看起来挺对" 是远远不够的。标准做法是把它拆成两段分别打分——检索（Retrieval） 和 生成（Generation），每段用一套指标去量化，最后再加上端到端评估。

主流做法是 LLM-as-a-Judge（让大模型当裁判）配合一份黄金数据集（Golden Dataset）跑自动化评估。工业界用得最多的 5 个核心指标：

一句话概括：检索看 "找得准不准"，生成看 "答得真不真"。

深度解析

一、为什么 RAG 评估这么难

普通 LLM 应用的评估已经够头疼了，RAG 还要再难一层。难就难在三点：

• 结果非确定性：同样一个输入，温度稍微一动答案就变了，没法用 "对/错" 简单二分
• 失败原因复杂：回答错了，可能是检索没找对，也可能是 LLM 瞎编，不拆开看，根本不知道锅扣谁头上
• 缺乏标准答案：像客服这种场景，压根没有 "唯一正确答案"，传统分类指标直接用不上

所以 RAG 评估的心法是：分而治之，每一段单独打分。RAG 的质量是木桶效应，检索和生成是相乘关系，一段是 0，整体就归零。

二、RAG 评估整体框架

这张图就是 RAG 评估的整体思路，核心就一件事：按链路拆开。下面一段段讲。

三、检索阶段指标：找得准不准

检索是 RAG 的地基，地基歪了，生成再强也撑不起来。

1. Context Recall（上下文召回率）

回答这样一个问题：应该被检索到的信息，实际检索到了多少？

算的办法是让 LLM 把标准答案拆成一条条独立事实，逐个去检索上下文里找，能找到的事实占比就是 Recall。这个指标直接反映你的 Embedding 模型、Chunk 策略、Top-K 设置做得怎么样。

生产环境建议目标：Context Recall > 0.8，低于这个数说明召回有缺口。

2. Context Precision（上下文精确率）

光召回还不够，排序也得对。Top-K 就那么多位置，相关内容得排前面，不相关的得往后挪。

Context Precision 看的就是：相关 Chunk 是不是都排在了不相关 Chunk 前面。这个指标主要看你 Reranker 调得好不好。

我之前做过一个项目，加了 Rerank 之后 Context Precision 从 0.62 直接拉到 0.85，Rerank 的效果立竿见影。

3. Context Relevancy（上下文相关性）

召回的 Top-K 个 Chunk 里，有多少是真的和问题相关的。

这个指标主要用来诊断 Chunk 大小合不合适。Chunk 切太大，里面混了一堆没用的东西，相关性就低；切太小，又会丢上下文。

4. 经典 IR 指标（传统信息检索那套）

如果你自己拿人工标注的数据来评估检索，下面这套老牌指标也能用：

面试经常问的一个点：MRR 和 NDCG 有啥区别？说白了，MRR 只看第一个命中的位置在哪，NDCG 会把所有命中位置的排序都算进去，所以 NDCG 更全面。

四、生成阶段指标：答得真不真

检索准了，还要看 LLM 有没有好好用上下文。

1. Faithfulness（忠实度）—— 最重要

答案里的事实，是不是都能在检索上下文里找到依据？

这个指标直接量化幻觉率。算法是把答案拆成一条条原子陈述（claim），逐个去上下文里找支撑，能找到支撑的比例就是 Faithfulness。

比如 Faithfulness = 0.95，意思是 95% 的陈述有依据，剩下 5% 是模型自己脑补的。生产环境一般定在 0.85 以上。

这一块特别重要，幻觉是 RAG 系统最大的坑。法律、医疗、金融这些高合规场景，Faithfulness 不达标根本上不了线。

2. Answer Relevancy（答案相关性）

答案有没有跑题？是不是真在回答用户的问题？

举个反例，用户问 "退货政策是什么"，模型来一句 "我们公司成立于 1998 年"，那 Answer Relevancy 就极低，就算这句事实没错也没用。

3. Answer Correctness（答案正确性）

和标准答案比，对不对。这是有参考答案（reference-based）的指标，通常用语义相似度加事实一致性一起算。

注意：不是所有场景都有标准答案，所以这个指标不是必选。

五、评估方法：三种打分方式怎么选

光知道指标还不够，还得知道这些分数是怎么算出来的。主流方法就三种：

生产环境一般是这么做的：先人工标注一份 Golden Dataset（通常 100~500 条），日常迭代就用 LLM-as-a-Judge 跑自动化评估，关键节点再回到人工抽检。

LLM-as-a-Judge 自己也有几个坑：

• 评估模型尽量选强模型（GPT-4 / Claude Sonnet 级别），别用同一个模型自己评自己
• 注意位置偏见（Position Bias），评估时选项顺序要打乱
• 分数最好连续化（0~1），别只让模型出二分类

六、主流评估框架（含 Java 代码示例）

Python 阵营：RAGAS / DeepEval

• RAGAS（Retrieval-Augmented Generation Assessment）：业界最知名的 RAG 评估框架，最早提出无参考（reference-free）评估，不用标准答案也能算 Faithfulness 和 Answer Relevancy
• DeepEval：思路跟 RAGAS 差不多，但集成了 pytest，能把评估直接跑在 CI/CD 里，工程化更顺
• TruLens：偏可观测性，适合做在线监控
• LangSmith：LangChain 官方的评估加监控平台

Java 阵营：Spring AI 自带的 Evaluator

这是 Java 选手面试的加分项。Spring AI 在 spring-ai-core 里内置了一套评估体系，核心是 Evaluator 接口：

@FunctionalInterface
public interface Evaluator {
    EvaluationResponse evaluate(EvaluationRequest evaluationRequest);
}

官方给了两个开箱即用的实现：

1. RelevancyEvaluator —— 答案相关性评估

判断 LLM 的回答有没有跑题、有没有偏离检索上下文。内部用的就是 LLM-as-a-Judge，Prompt 是一个简单的 YES/NO 判定。

@SpringBootTest
class RagEvaluationTest {

    @Autowired
    private ChatModel chatModel;

    @Autowired
    private VectorStore pgVectorStore;

    @Test
    void evaluateRelevancy() {
        String question = "Spring AI 支持哪些向量数据库？";

        // 1. 构造 RAG Advisor，走一遍完整的检索增强流程
        RetrievalAugmentationAdvisor ragAdvisor = RetrievalAugmentationAdvisor.builder()
                .documentRetriever(VectorStoreDocumentRetriever.builder()
                        .vectorStore(pgVectorStore)
                        .topK(5)
                        .build())
                .build();

        // 2. 发起提问，拿到检索上下文 + 模型回答
        ChatResponse chatResponse = ChatClient.builder(chatModel).build()
                .prompt(question)
                .advisors(ragAdvisor)
                .call()
                .chatResponse();

        // 3. 组装评估请求：用户问题 + 检索上下文 + 模型回答
        EvaluationRequest evaluationRequest = new EvaluationRequest(
                question,
                chatResponse.getMetadata().get(RetrievalAugmentationAdvisor.DOCUMENT_CONTEXT),
                chatResponse.getResult().getOutput().getText()
        );

        // 4. 用 RelevancyEvaluator 评估，isPass() 为 true 才算合格
        RelevancyEvaluator evaluator = new RelevancyEvaluator(ChatClient.builder(chatModel));
        EvaluationResponse evaluationResponse = evaluator.evaluate(evaluationRequest);

        assertThat(evaluationResponse.isPass()).isTrue();
    }
}

RelevancyEvaluator 默认的 Prompt 就是问模型 "这个回答和上下文一致吗，回答 YES 或 NO"。如果想自定义评估规则，可以用 .promptTemplate() 传自己的模板进去，但 query、response、context 这三个占位符得留着。

2. FactCheckingEvaluator —— 事实核查（反幻觉）

专门用来检测幻觉。判断一个陈述（claim）能不能在上下文（document）里找到逻辑支撑。

@Test
void testFactChecking() {
    // 用 Bespoke-Minicheck 这种专用小模型做事实核查，成本低
    OllamaApi ollamaApi = new OllamaApi("http://localhost:11434");
    ChatModel miniCheckModel = new OllamaChatModel(ollamaApi,
            OllamaChatOptions.builder()
                    .model(OllamaOptionsModel.BESPOKE_MINICHECK)
                    .numPredict(2)
                    .temperature(0.0)
                    .build());

    FactCheckingEvaluator evaluator = new FactCheckingEvaluator(ChatClient.builder(miniCheckModel));

    String context = "Earth 是距离太阳第三近的行星，目前已知唯一存在生命的天体。";
    String claim  = "Earth 是距离太阳第四近的行星。";  // 故意写错的陈述

    EvaluationRequest request = new EvaluationRequest(
            context, Collections.emptyList(), claim);

    EvaluationResponse response = evaluator.evaluate(request);

    // 这条 claim 在 context 里没有依据，所以 isPass() 应该是 false
    assertFalse(response.isPass(), "这条陈述不应该被上下文支撑");
}

生产上一个建议：事实核查尽量用 Bespoke-Minicheck 这种专用小模型，跑一次比 GPT-4 便宜太多，大规模幻觉检测用大模型烧不起那个钱。

如果想跑更完整的 RAGAS 指标（比如 Faithfulness、Context Recall），Java 阵营目前的选项是：① 自己用 Spring AI 的 ChatClient 实现 LLM-as-a-Judge ② 通过 ProcessBuilder 调 Python 的 RAGAS 脚本 ③ 用社区封装的 langchain4j-eval。这块 Java 生态确实不如 Python，面试时候直接说就行，反而显得你心里有数。

七、生产环境的评估闭环

光有评估指标还不够，成熟的玩法是把评估跑成一个闭环：

这张图就是一个完整的评估闭环，几个关键点：

• 离线评估：每次改 Prompt、换 Embedding、调 Chunk 大小，都拿 Golden Dataset 跑一遍回归
• CI/CD 集成：把评估指标卡进发布流水线，指标掉了就不让发
• 在线监控：上线后采样真实流量做评估，收集用户 👍/👎 反馈，反哺回 Golden Dataset

这个闭环才是面试官想听的，评估不是一次性的事，得持续跑。

八、一个常被忽略的事实

我在网上看过一个真实案例，挺值得聊聊：离线评估分数高，并不等于生产就稳。

某个法律 RAG 系统，离线 Faithfulness 跑到 0.91，数据挺漂亮。结果上线三周，客户反馈每 6 条回答里就有 1 条出问题。原因出在哪？离线评估集都是规规矩矩的 "好问题"，而生产环境用户提问千奇百怪，口语化、错别字、跨领域什么都有，离线分数压根预测不了线上表现。

所以离线评估和在线监控一个都不能少，这也就是评估闭环的价值。

面试高频追问

1. 追问一：Faithfulness 和 Answer Relevancy 有什么区别？

   Faithfulness 看的是答案有没有背离上下文（也就是幻觉），Answer Relevancy 看的是答案有没有回答用户的问题。完全可能答得很忠实但跑题（Faithfulness 高、Answer Relevancy 低），也可能答得很切题但全靠瞎编（Faithfulness 低、Answer Relevancy 高）。

2. 追问二：为什么不能用准确率（Accuracy）一个指标？

   RAG 的答案是非确定性的，又没有唯一标准答案，准确率本身就难算。加上 RAG 失败是多环节的，单一指标根本定位不了瓶颈。必须分阶段加多指标一起看。

3. 追问三：LLM-as-a-Judge 自己评估自己，靠谱吗？

   不太靠谱。建议用更强的模型评弱模型，或者干脆换一个不同的模型来评。同一个模型自评，会有偏爱自己输出的偏见。

4. 追问四：检索效果不好，怎么定位是检索还是生成的问题？

   看 Context Recall 和 Faithfulness 这两个数。Context Recall 低，说明该召回的没召回，问题在检索；Context Recall 高但 Faithfulness 低，说明检索没问题，是模型在瞎编，锅在生成。

5. 追问五：评估数据集怎么构建？

   • 人工标注（最准但慢）
   • LLM 合成：让大模型基于知识库文档生成 (问题, 答案, 相关 Chunk) 三元组，快是快，质量得筛
   • 生产日志采样：把真实用户问题捞出来人工补标，这个最有代表性

常见面试变体

• "你做过的 RAG 项目，Faithfulness 能做到多少？怎么提上去的？"
• "RAGAS 框架你了解哪些指标？"
• "上线后怎么持续监控 RAG 效果？"
• "Faithfulness 和 Answer Correctness 有什么区别？"
• "如何用 Spring AI 做自动化评估测试？"

记忆口诀

检索三件套（召回、精确、相关），生成看两样（忠实、相关）；离线跑回归，在线盯监控。

更短的版本：检索准不准，生成真不真，闭环跑评估。

总结

RAG 评估的核心就是分阶段量化：检索阶段看 Context Precision / Recall / Relevancy 加上经典 IR 指标，生成阶段看 Faithfulness 和 Answer Relevancy；方法上以 LLM-as-a-Judge 配合 Golden Dataset 为主，配合 Spring AI 的 RelevancyEvaluator / FactCheckingEvaluator 可以很快落地。面试时候重点讲 "分阶段评估 + 闭环监控"，再丢一个踩坑案例（比如离线高分线上翻车），基本这题就稳了。