关于这篇文章档

RAG 程序上线只是起点，如何持续保证它的“聪明程度”才是挑战。这篇文章从评估动机出发，程序讲解 RAGAS 框架的工作原理。并提供基于 Spring Boot + LangChain4j 的完整 Java 可运行实现。

• ✅ RAGAS 四大主要指标的含义与计算逻辑
• ✅ LLM-as-Judge 评估原理详细说明
• ✅ DeepSeek / 通义千问 API 对接完整配置
• ✅ 自动化评估服务 + JUnit 可运行测试代码
• ✅ Micrometer 指标监控 + SSE 实时推送集成

. 你的 RAG 程序出了什么问题？

RAG 的“感觉好”陷阱

大多数团队上线 RAG 程序后靠两种方式判断质量：人工抽查几条对话，或者收集使用者投诉。这两种方式都有根本性缺陷——前者无法覆盖长尾场景，后者是事后止损。说起来，

更糟的是RAG 程序的问题往往隐而不发。大模型天生擅长“看起来很有道理”的回答。即使它悄悄混入了检索文档里没有的内容，使用者短期内也很难察觉。

flowchart LR
U --> R
R --> G
G --> A
subgraph 盲区
B1
B2
B3
end
style 盲区 fill:#ffebee
style U fill:#e3f2fd
style A fill:#e8f5e9

传统指标为什么不够用

工程师们尝试过 BLEU、ROUGE 等 NLP 指标，但这些指标在 RAG 场景下有严重局限。

LAGAS 的解法：用 LLM 评估 LLM

LAGAS由 Es et al. 在 年提出，主要思想是将评估本身也交给大语言模型来做——即 LMM-as-Judge 模式。 其实，S这做有几个优势：无需人工标注黄金答案、能理解语义而非仅匹配词汇、可以大规模自动化执行。

flowchart TB
subgraph 旧方式
R1 --> R2
R2 --> R3
end
subgraph ragas
E1 --> E2
E2 --> E3
E3 --> E4
end
style 旧方式 fill:#ffebee
style ragas fill:#e8f5e9

. LARAS 四大主要指标详细说明

LARAS 从检索和生成两个维度各拆出两个指标，构成一个 × 的评估矩阵。

忠实度—— 大模型有没有“加戏”？

生活类比： 就像法庭上要求证人“只陈述你亲眼所见”，忠实度要求 RAG 的答案“只来自检索到的内容”。

计算逻辑：

1. 将生成的答案拆解成多个独立声明
2. 对每条声明判断检索文档是否支持它
3. 忠实度 = 被支持声明数 / 总声明数

答案相关性——有没有答非所问？**生活类比**：你问“最近地铁站在哪”。对方回答“地铁程序建于1970年代”——内容是真的，但没有回答你的问题。**计算逻辑**：

1. 用评估 LLM 根据生成的答案反推**出若干个可能的问题**。
2. 计算这些反推问题与原始问题语义相似度 
3. 取平均值作为答案相关性得分 

这种 “反向生成” 方法巧妙地避免了直接比较难题，高分代表着答案直接、专注地解决原问题。