RAG 量化评测方案：召回率/精准率人工测试集落地

做 RAG 项目的人大多有过这种经历：改了个分块策略，自己问了几个问题，感觉"好像变好了"，然后就上线了。这种全凭主观感觉的评测方式，最大的问题是——你根本不知道问题出在哪。是分块切碎了？还是检索没召回？还是模型生成了幻觉？全是一笔糊涂账。

我后来把评测这件事量化了，才真正摸到 RAG 优化的门道。

先搞懂评测的两类核心指标

RAG 的评测其实分两大块：检索质量和生成质量。检索质量看的是"搜出来的资料准不准"，生成质量看的是"基于资料生成的回答对不对"。两块的指标不一样，要分开测。

检索质量的核心指标是召回率（Recall）和精准率（Precision）。召回率衡量的是"该召回的有没有召回全"——相关片段漏掉了，回答就会残缺、答非所问。精准率衡量的是"召回来的干不干净"——无关的噪声混进来了，模型就会被带偏，回答逻辑混乱。两个指标一个管"够不够"，一个管"纯不纯"，都得看。

更进一步，还有 MRR（平均倒数排名）和 NDCG（归一化折损累计增益）这类排序类指标，它们衡量的是"正确答案排得靠不靠前"。对于只取 Top-K 的 RAG 来说，正确片段排在第 1 位和第 5 位，效果差很多，所以排序指标也值得关注。比如 Top-5 命中率，就是"正确答案在前 5 个结果里的比例"，这个指标很直观。

生成质量的评测更复杂一些。基础做法是人工打分，看回答的忠实性（有没有忠实于资料）、相关性（答没答到点上）、完整性（有没有遗漏）。更进阶的是用 LLM-as-judge——让另一个大模型当裁判，对回答按几个维度打分。它有偏差，但胜在快、可规模化，配合人工抽查用。

评测怎么落地

评测的落地方法是这样的：根据业务场景，人工构建 30~50 条真实的高频问题，每一条都标注好它对应的标准答案片段，形成一个标准测试集。然后批量跑检索链路，统计每道题的命中、漏召、误召情况，最后算出全局的召回率和精准率。

这里有个关键点：测试集要贴近真实用户的问题，而不是你自己编的理想问题。因为 RAG 的难点恰恰在"用户问法五花八门"，如果测试集是理想化的，评测结果就会虚高。构建测试集时，一定要收集真实的用户 query——包括那些问法绕、带口语、有错别字的问题，这些才是真正检验系统水平的。

测试集还有两个要求：一是覆盖面要广，把各种类型的问法都覆盖到；二是要"冻结"——定下来之后不要频繁改，否则没法做回归对比。每次调整系统，都用同一套测试集跑，才能看到真实的效果变化。

用指标定位问题

有了指标，定位问题就有方向了：

如果召回率偏低，就往分块策略、检索权重、Top-K 这些方向调——通常是该捞的没捞上来。如果精准率偏低，就往重排阈值、语料清洗、检索范围这些方向调——通常是捞上来一堆没用的。

这里有个判断技巧：召回率低，说明"检索的入口"有问题，要么分块把语义切碎了，要么 embedding 模型不匹配你的领域；精准率低，说明"检索的结果"太脏，要么语料里有噪声，要么重排没过关。先判断问题在哪一端，再动手调，才不会瞎调一通。

还有一件事特别重要：回归测试。每次改完，都要把之前跑过的同一套测试集再跑一遍，看三件事——以前对的题现在还不对、以前错的题有没有修好、有没有引入新错误。我见过太多人调一个参数修好一个问题，结果把另三个问题搞坏了，还不自知。回归测试就是防止"按下葫芦浮起瓢"的。

指标不是全部

最后提醒一句，召回率和精准率只是基础指标，不是全部。还要看最终回答有没有正确引用资料、没有资料的时候会不会正确拒答、检索排名稳不稳定、不同语言格式下表现是否一致。指标的作用是帮你发现问题，真正解决还得结合分块、语料质量、检索权重、重排阈值和 Prompt 一起调。

别靠感觉，让数据说话，这是 RAG 从 demo 走向可用的分水岭。一套好的评测体系，就是 RAG 项目的"仪表盘"——没有它，你就是在黑灯瞎火里开车。