RAG 做出来不算完，用 Ragas 给它打个分：四个核心指标怎么读
RAG 项目最常见的状态是：演示时效果惊艳，上线后用户总说「它有时候瞎编」。问题出在没人量化它——你知道它有时错，但不知道错在「检索没找到」还是「生成没照着检索」。Ragas 这个评测框架就是给 RAG 做体检的：它把系统拆成检索与生成两段，分别打分。 四个核心指标怎么读 Faithfulness（忠实度）：回答里的每一个论断，能不能在检索回来的上下文里找到依据。这个分低，就是模型在脱离材料编造——幻觉问题出在生成端。 Answer Relevancy（回答相关性）：回答有没有真正回应问题。问东答西，这个分就掉。 Context Precision（上下文精度）：检索回来的片段里，相关的是不是排在前面。 Context Recall（上下文召回）：该被找到的信息，到底找回来了多少。 关键在于：Faithfulness 低是生成问题，Context Recall 低是检索问题。两个问题的修法完全不同——前者改提示词、换更强的生成模型，后者要补数据、调分块、改检索。不打分，你连该修哪头都不知道。 怎么落地 准备几十条带标准答案的问答对（从真实用户问题里挑），用 pip install ragas，把问题、检索片段、回答喂进 evaluate()，它就能出这几项分数。之后每次改分块策略、换 embedding 模型，跑一遍对比，数值升降一目了然。 判断 RAG 的下一步不是「再接一个 reranker」，而是「先知道自己哪里差」。没有指标的优化是许愿。把 Ragas 接进迭代流程，让每一次改动都有分可看，RAG 才从「感觉不错」变成「能被验收」的工程系统。 补一个操作细节：评测本身也要花 token。Ragas 用一个模型当裁判去打分，几十条样例跑一次就是一笔小开销。建议把评测安排在夜间批量跑，别挂进实时请求链路——它是体检工具，不是运行时组件。分数趋势稳定后，甚至可以只在改了关键配置时才跑全量，平时抽查即可。 没有指标的优化是许愿，有了分数，RAG 才能从「感觉不错」变成「可被验收」。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：RAG评估