RAG 评测怎么做：先准备一套真实测试问题

RAG 知识库能回答几个问题，不代表可以上线。真正的评测要看：能不能召回正确资料，回答是否忠于资料，是否带来源，找不到答案时会不会承认，权限边界是否正确，更新文档后是否仍然稳定。新手最该做的第一件事，是准备一套真实测试问题。

这篇是草稿，可以和 RAG 文档切分怎么做、Dify 知识库怎么搭 一起使用。

适合谁

适合已经有 RAG demo，但不知道效果是否能交付的人。你可能能让模型回答问题，但没有系统评测记录。

也适合给客户做知识库验收的人。客户要看到的不只是演示，而是可复查的测试结果。

不适合谁

不适合只靠感觉判断的人。回答看起来流畅，不代表来源正确。

如果资料还没有整理，先做文档治理，再谈评测。脏资料会让评测结果没有意义。

测试集怎么准备

先从真实用户问题开始。客服记录、员工提问、搜索词、培训问题、产品 FAQ 都可以作为来源。

每个问题要标注正确来源。没有正确来源，就很难判断 RAG 是否答对。

问题类型

测试集至少包含常见问题、模糊问题、同义表达、找不到答案、过期资料、权限问题和多步骤问题。

不要只准备标准问法。真实用户会口语化、打错字、问一半、混合多个意图。

召回评测

召回评测看检索阶段是否找到正确资料。正确片段有没有出现在 Top-K 结果里，是评测的第一层。

如果召回失败，要先检查切分、embedding、向量库、metadata 和过滤条件。

回答评测

回答评测看模型是否基于资料回答，是否编造，是否遗漏条件，是否引用来源，是否能拒绝没有依据的问题。

不要只看答案是否顺口。RAG 的价值是“有依据地回答”。

权限评测

企业知识库必须测试权限。不同角色问同一个问题，应该看到不同资料范围，或者在无权限时被拒绝。

权限错误比普通回答错误更严重。上线前必须单独测试。

回归测试

每次更新文档、换 embedding、改切分、改提示词、换模型，都应该用同一套测试集重跑。

没有回归测试，系统变好还是变差只能靠感觉。

常见错误

常见错误是只拿几个标准问题演示，不做找不到答案和权限问题测试。演示问题通常太理想，真实用户会问模糊问题、错别字问题、多意图问题。另一个错误是只看答案，不看检索来源。

交付记录里要包含测试集、正确来源、模型回答、检索片段、是否通过、失败原因和修复建议。客户看到这份记录，才知道知识库不是凭感觉验收。

风险提醒

评测集本身也会过期。产品规则、公司制度、价格和流程变化后，测试集要同步更新。

不要把测试结果写得像绝对保证。它只能说明在当前资料和测试集下表现如何。

具体步骤

第一步，收集 30 到 100 个真实问题。

第二步，为每个问题标注正确来源和预期结果。

第三步，分别检查召回、回答、引用和权限。

第四步，记录失败原因和优化方向。

第五步，把测试集作为上线和回归工具。需要评测表或人工协助，可以从 工具导航 进入。

发布前复核点

发布前要补一张评测表样例，包含问题、正确来源、检索片段、模型回答、是否通过、失败原因和下一步修复。这样文章才能从概念变成可执行模板。

还要补一个失败案例。比如检索到了错误来源、答案没有引用、找不到答案却硬答。失败案例比成功演示更有价值，因为读者真正需要的是排查方法。

给客户交付时，可以把评测结果分成三类：已经通过的问题，需要补资料的问题，需要改系统的问题。这样客户不会把所有失败都理解成模型差。有些失败其实是文档缺失，有些是权限配置，有些才是检索或生成链路要优化。

免责声明

本文是 RAG 评测入门草稿，不构成具体工具或指标建议。不同项目需要不同测试集和评估标准，正式发布前需要结合真实业务复核。涉及企业资料时，请由专业人员参与。