很多同学搭完 RAG 之后，评测方式是：自己问几个问题，回答大概靠谱，就觉得「没问题了」。然后上线，用户反馈「答非所问」，问题单一个接一个。复盘下来发现——不是模型不行，是检索一开始就没捞到对的文档。
这个坑我见过太多次了。评估 RAG，光靠"感觉"是不够的。需要一套量化指标体系，把「检索好不好」和「回答对不对」分开来看。
这篇，我把 RAG 评估从头拆一遍：检索层的 Recall@K、MRR、NDCG，生成层的 RAGAS 四大指标，再到用 LangChain.js 搭一套评估 Pipeline。每一个指标，我会告诉你它量的是什么、什么时候用、踩过哪些坑。
01 RAG 评估的两层结构：检索 vs 生成，不能混为一谈
很多人问我：「我直接用 LLM 打个分，看回答质量不就好了？」
这个思路的问题在于：LLM 打分只能告诉你「最终答案好不好」，没法告诉你「是哪个环节出了问题」。就像一道菜不好吃，你不知道是食材不行还是厨师手艺差。
RAG 系统的链路是：Query → 检索层（Retriever）→ 召回文档块 → 生成层（Generator）→ 最终 Answer。
这两层的问题是独立的：
- 检索层问题：召回的文档和 Query 不相关；或者相关文档被排在第 10 名，前 3 名全是废文
- 生成层问题：相关文档召回了，但 LLM 没用到（幻觉）；或者答案风马牛不相及
评估体系也要分开：
| 评估维度 | 解决的问题 | 核心指标 |
|---|---|---|
| 检索层评估 | 召回的文档和 Query 相关吗？排序好不好？ | Recall@K、MRR、NDCG |
| 生成层评估 | LLM 用了召回内容吗？答案准确吗？ | RAGAS: Faithfulness、Answer Relevancy、Context Precision、Context Recall |
搞清楚这个分层，才知道下面的指标各管哪段链路。
02 Recall@K——你的答案在前 K 条里吗？
Recall@K 是最基础的检索指标，它回答的问题是：对于一个 Query，所有相关文档中，有多少比例出现在你召回的前 K 条里？
计算方式：Recall@K = 前K条里的相关文档数 / 总相关文档数
举个例子：你的知识库里有 5 篇和「Redis 集群方案」相关的文档。用户问了一个问题，你召回了 Top10，其中 4 篇是相关的，那么 Recall@10 = 4/5 = 0.8。
// ① Recall@K：前K条里有多少相关文档functionrecallAtK retrieved: string[], // 召回文档 ID 列表（按排名） relevant: string[], // 标注的相关文档 ID 集合 k: numbernumberconstslice0constnewSetconstfilterid =>haslengthreturnlength00lengthfunctionavgRecallAtK queries: Array<{ retrieved: string[]; relevant: string[] }>, k: numbernumberconstmapq =>recallAtKretrievedrelevantreturnreduce(a, b) =>0lengthconstretrieved"doc_3""doc_7""doc_1""doc_5""doc_9"relevant"doc_1""doc_3""doc_5"retrieved"doc_2""doc_8""doc_4""doc_6""doc_10"relevant"doc_2""doc_4"consolelog`Recall@3: ${avgRecallAtK(testData, 3).toFixed(3)}`// 0.667consolelog`Recall@5: ${avgRecallAtK(testData, 5).toFixed(3)}`// 1.000// ② MRR：第一个相关文档在第几名functionreciprocalRankretrieved: string[], relevant: string[]numberconstnewSetforlet0lengthifhasreturn11return0functionmeanReciprocalRank queries: Array<{ retrieved: string[]; relevant: string[] }>numberconstmapq =>reciprocalRankretrievedrelevantreturnreduce(a, b) =>0lengthRecall@K 的盲区：它只管「相关文档有没有被召回」，不管排序。第 1 名和第 10 名对它来说没区别。但在 RAG 里，你一般只把 Top3 塞给 LLM——如果相关文档都在 Top8-10，Recall@10=1.0 但实际没用。这就是为什么还需要 MRR。
MRR 的适用场景：当每个 Query 只有一个最正确答案时，MRR 很好用。MRR 的盲区：它只看第一个相关结果，如果一个 Query 有多个相关文档，后续排名的好坏它完全不管。
03 MRR——第一个相关文档在第几名？
MRR（Mean Reciprocal Rank），专门关注第一个相关文档出现的位置。
计算方式：MRR = (1/|Q|) × Σ (1 / rank_i)，其中 rank_i 是第 i 个 Query 下第一个相关文档的排名。
为什么用倒数？第 1 名相关 → 得分 1.0，第 2 名 → 0.5，第 5 名 → 0.2，第 10 名 → 0.1（几乎无用）。排名越靠后，得分衰减越快，惩罚越重。
上面 Recall@K 代码里已包含reciprocalRank和meanReciprocalRank的实现，下面直接看对比验证：
// 对比两种检索策略的 MRRconstretrieved"doc_x""doc_1""doc_3"relevant"doc_1"// 相关文档排第2retrieved"doc_2""doc_y""doc_z"relevant"doc_2"// 相关文档排第1constretrieved"doc_1""doc_x""doc_3"relevant"doc_1"// 相关文档排第1retrieved"doc_y""doc_2""doc_z"relevant"doc_2"// 相关文档排第2consolelog`Strategy A MRR: ${meanReciprocalRank(strategyA).toFixed(3)}`// 0.750consolelog`Strategy B MRR: ${meanReciprocalRank(strategyB).toFixed(3)}`// 0.750// 两个 MRR 一样！MRR 分不清「哪篇文档更靠前更好」，需要 NDCG 来区分04 NDCG——排序质量的全面评分
NDCG（Normalized Discounted Cumulative Gain），是最全面的检索排序指标。它同时考虑每个文档的相关性程度（可以分 0/1/2 等级）和文档所在位置（越靠前越值钱）。
原理：DCG@K = Σ (rel_i / log₂(i+1))，NDCG@K = DCG@K / IDCG@K（实际值 / 理想排序值），永远在 [0, 1] 之间。
// 计算 DCGfunctiondcgAtKrelevances: number[], k: numbernumberreturnslice0reduce(acc, rel, i) =>returnMathlog220// 计算 NDCG@KfunctionndcgAtK retrieved: string[], relevanceMap: Map<string, number>, k: numbernumberconstslice0mapid =>get0constArrayfromvaluessort(a, b) =>constdcgAtKconstdcgAtKreturn00// 验证：相关文档排名靠前 vs 靠后的差距constnewMap"doc_1"2// 高度相关"doc_3"1// 部分相关"doc_5"2// 高度相关const"doc_x""doc_y""doc_1""doc_3""doc_5"// 相关文档在后const"doc_1""doc_5""doc_3""doc_x""doc_y"// 相关文档在前consolelog`Strategy A NDCG@5: ${ndcgAtK(retrievalA, relevanceScores, 5).toFixed(3)}`consolelog`Strategy B NDCG@5: ${ndcgAtK(retrievalB, relevanceScores, 5).toFixed(3)}`// 策略B 明显高于策略A，这才是排序质量的差距什么时候用 NDCG：当你的知识库里有多个相关文档，且相关程度有差异（有的非常相关、有的一般相关）时，NDCG 是最全面的指标。比较两种检索策略（向量检索 vs 混合检索）时首选 NDCG。
05 RAGAS 四大指标——生成层这样量
上面三个指标都是检索层的。现在来看生成层——LLM 拿到召回的文档后，有没有用好？
RAGAS（Retrieval Augmented Generation Assessment）是目前最主流的 RAG 生成评估框架，四个核心指标各管一段链路：
| 指标 | 量的是什么 | 低了说明什么 |
|---|---|---|
| Faithfulness（忠实度） | 答案里的声明有多少来自 Context | LLM 在幻觉，凭空捏造 |
| Answer Relevancy（答案相关性） | 答案是否真正回答了 Query | 答非所问，离题了 |
| Context Precision（上下文精确率） | 召回文档里有用的比例 | 检索噪音太多 |
| Context Recall（上下文召回率） | 标准答案所需信息是否被覆盖 | 重要文档没有被召回 |
importChatOpenAIfrom"@langchain/openai"importPromptTemplatefrom"@langchain/core/prompts"constnewChatOpenAImodel"gpt-4o-mini"temperature0// Faithfulness：答案是否基于上下文，没有幻觉？asyncfunctionfaithfulnesscontext: string[], answer: stringPromisenumberconstPromptTemplatefromTemplate`你是一个严格的事实核查员。上下文：{context}答案：{answer}请判断答案中的每一个声明是否都能在上下文中找到依据。输出 JSON：{{"supported_claims": X, "total_claims": Y}} `constpipeconstawaitinvokecontextjoin"\n\n"constJSONparsecontentasstringreturnsupported_claimstotal_claims// Context Precision：召回的文档里有多少真正有用？asyncfunctioncontextPrecision query: string, contexts: string[], groundTruth: stringPromisenumberconstPromptTemplatefromTemplate`问题：{query}标准答案：{groundTruth}文档片段：{context}这个文档片段对回答该问题是否有帮助？输出 {{"useful": true/false}} `constpipelet0let0forlet0lengthconstawaitinvokecontextconstJSONparsecontentasstringif1return00四个指标的关系：Context Precision 和 Context Recall 评的是检索层给生成层「喂」的食材质量；Faithfulness 和 Answer Relevancy 评的是 LLM 怎么用这些食材做菜。四个数都高，才算一个好的 RAG 系统。
06 完整评估 Pipeline：从数据集构建到打分报告
光有指标没用，得有 Pipeline 跑起来。评估 RAG 的难点在于构建测试数据集——你需要有(query, contexts, answer, ground_truth)四元组。
有两种方法：人工标注（质量高，慢）和 LLM 自动合成（从已有文档自动生成 QA 对）。
importChatOpenAIfrom"@langchain/openai"importDocumentfrom"@langchain/core/documents"// Step 1: LLM 自动合成评估数据集asyncfunctionsynthesizeEvalDataset docs: Document[], numQuestions = 20PromiseArrayquerystringgroundTruthstringconstnewChatOpenAImodel"gpt-4o-mini"temperature0.3constforlet0constMathfloorMathrandomlengthconst`基于以下文档内容，生成一个有深度的问题和对应的标准答案（JSON）：文档：${doc.pageContent}输出：{"question": "...", "answer": "..."}`constawaitinvokeconstJSONparsecontentasstringpushquerygroundTruthreturn// Step 2: 批量跑评估，生成报告asyncfunctionrunRAGEval ragChain: any, evalDataset: Array<{ query: string; groundTruth: string; relevantDocIds: string[] }>, vectorStore: anyPromisevoidconstforconstofconstawaitinvokequeryqueryconstawaitsimilaritySearchquery10constmap(d: Document) =>metadataidasstringconstrecallAtKrelevantDocIds5constreciprocalRankrelevantDocIdsconstawaitfaithfulnesscontextsanswerpushfaithfulness// 汇总输出报告constavgkey: stringreduce(a, b) =>asany0lengthtoFixed3consolelog"\n===== RAG 评估报告 ====="consolelog`Recall@5: ${avg("recall5")}`consolelog`MRR: ${avg("mrr")}`consolelog`Faithfulness: ${avg("faithfulness")}`// 自动诊断ifparseFloatavg"recall5"0.7consolelog"⚠️ Recall@5 偏低 → 考虑增大 TopK 或换混合检索"ifparseFloatavg"faithfulness"0.8consolelog"⚠️ Faithfulness 偏低 → LLM 有幻觉，加强 System Prompt 约束"07 常见坑：评估 RAG 时最容易犯的 5 个错误
坑 1：用生产数据当测试集，但没有 ground truth
生产日志里有 query，但没有「正确答案」。直接用这些数据跑评估，Context Recall（需要知道「正确答案包含哪些信息」）根本没法算。解决：定期从生产 query 里抽样 50-100 条，人工标注，积累评估集。
坑 2：K 值设太大，掩盖真实问题
召回 Top20 算 Recall@20，几乎必然 >0.9，但你实际只把 Top5 喂给 LLM。应该用Recall@K 的 K = 你实际传给 LLM 的文档数。
坑 3：只看 Faithfulness，忽视 Context 质量
Faithfulness 高只说明 LLM 没有凭空捏造。但如果 Context 本身就是错误文档，Faithfulness=1.0 照样给出错误答案。要配合 Context Precision/Recall 一起看。
坑 4：用 BLEU/ROUGE 评估语义类 RAG
「他今年 30 岁」和「他今年而立之年」词汇重叠几乎为 0，但语义完全一致。BLEU/ROUGE 是词汇指标，RAG 评估请用 RAGAS，别用传统 NLP 指标。
坑 5：只在固定测试集上跑，从不更新
知识库在变，用户 query 分布在变。建议：每次知识库大更新后重跑评估，设置指标基准线，低于基准线自动触发报警。
08 三种场景的指标组合：到底该看哪几个数？
不同 RAG 场景的评估侧重点不一样：
| 场景 | 优先指标 | 原因 |
|---|---|---|
| 问答类（找唯一答案） | MRR + Faithfulness | 关心首位相关结果和答案准确性 |
| 知识库搜索（找多篇文档） | NDCG@10 + Context Precision | 排序质量 + 噪音控制 |
| 客服/对话类 | Recall@5 + Answer Relevancy + Faithfulness | 覆盖率 + 相关性 + 无幻觉 |
| 合规/内部文档 | Faithfulness（首要）+ Context Precision | 不能有幻觉，上下文要干净 |
// 根据场景快速配置评估器typeRAGScenario"qa""search""chatbot""compliance"interfaceEvalConfigprimaryMetricsstringretrievalKnumberwarningThresholdsRecordstringnumberconstscenarioConfigsRecordRAGScenarioEvalConfigqaprimaryMetrics"mrr""faithfulness"retrievalK5warningThresholdsmrr0.7faithfulness0.85searchprimaryMetrics"ndcg""contextPrecision"retrievalK10warningThresholdsndcg0.75contextPrecision0.7chatbotprimaryMetrics"recallAt5""answerRelevancy""faithfulness"retrievalK5warningThresholdsrecallAt50.75answerRelevancy0.8faithfulness0.85complianceprimaryMetrics"faithfulness""contextPrecision"retrievalK3warningThresholdsfaithfulness0.95contextPrecision0.85functioncreateEvaluatorscenario: RAGScenarioconstreturnasyncevaluateresults: Record<string, number>[]constavgkey: stringreduce(a, b) =>00lengthconstreportRecordstringstringforconstofprimaryMetricsconstavgconstwarningThresholds0`✅ ${score.toFixed(3)}``⚠️ ${score.toFixed(3)} (低于 ${threshold})`consolelog`\n[${scenario.toUpperCase()} 场景评估报告]`ObjectentriesforEach([k, v]) =>consolelog` ${k}: ${v}`总结
这篇我们把 RAG 评估从头拆了一遍：
- 分层评估是前提：检索层和生成层用不同指标，不能用一个数字代替所有，否则你不知道出问题的是检索还是生成
- Recall@K 看覆盖率，MRR 看首位相关，NDCG 看全局排序质量：三个检索指标是递进关系，场景越复杂选越全面的指标
- Faithfulness 是 RAG 的生命线：低于 0.85 就要警惕，LLM 可能在用训练数据里的「知识」作答，而不是你提供的文档
- Context Precision 和 Faithfulness 要配合看：Context 干净了，LLM 才有可能回答准确；只看其中一个，会漏掉另一层的问题
- 测试集要定期更新、场景对应指标：知识库变了评估集也要跟着变，合规场景优先 Faithfulness，搜索场景优先 NDCG
学AI大模型的正确顺序，千万不要搞错了
🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！
有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！
就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋
📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇
学习路线:
✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经
以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！
我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～
