为什么需要对RAG做评测？

一个基于RAG的系统想要构建，其实不难，尤其是现在有很多成熟的工具，比如Dify，Coze这些，你可以直接上传一个文档，就能实现一个简单的RAG了。但是效果到底怎么样的？没人知道。 而且，一个RAG的系统和普通的LLM问答还不一样，普通的问答你只需要关心问题和答案之间是否是有关，答案是否有帮助就行了。而一个RAG系统中三个要素，分别是问题、答案以及检索资料。所以，我们需要有一套方法论来针对问题和答案、问题和检索资料、检索资料和答案之间的组合做全面评估。 所以，一个RAG系统，只要有了评测之后，才能对客使用。RAG系统进行评测，本质上是为了解决一个核心问题：如何确保你的 AI 系统不是在“碰运气”，而是真正稳定、可靠且可用。 RAG 评测主要有以下几个关键原因： 1. 打破“能用”的幻觉，发现潜在缺陷。在 Demo 阶段，问几个简单问题，模型往往能给出看似不错的答案，让人误以为系统已经“可用”。但一旦进入真实业务场景（如企业知识库、客服问答），问题就会暴露无遗： - 明明有答案却没找出来（检索漏召回）。 - 找到了答案却还在胡编乱造（生成层幻觉）。 - 回答本身没错，但速度太慢或成本太高（工程性能差）。评测能帮你撕开“能回答”的表象，看到系统在严肃场景下的真实表现。 2. 精准定位瓶颈，实现科学优化。RAG 是一个包含“检索”和“生成”的链路系统，错误在流水线中是“乘法关系”而非“加法关系”（例如检索准确率 80% × 生成准确率 80% = 端到端准确率仅 64%）。如果不做评测，你只知道系统“答错了”，却不知道错在哪。通过评测，可以将问题拆解并定位到具体环节，从而对症下药： - 检索层失败：如果评测发现是检索没召回关键证据，或者排序把正确答案压得太靠后，你需要优化的是向量数据库、切分策略或重排序模型。 - 生成层失败：如果检索到了正确文档，但模型依然无视上下文自己瞎编，你需要调整的是提示词约束、降低模型温度或优化引用机制。 3. 建立质量闭环，防止版本倒退。成熟的 RAG 开发需要像软件工程一样严谨。评测体系（特别是离线回归测试集）能帮助你建立质量闭环： - 版本对比：当你更换了嵌入模型或调整了参数，评测能告诉你系统整体是变好了还是变差了。 - 回归测试：确保新的迭代没有把之前已经修复的问题重新引入，防止系统“按下葫芦浮起瓢”。 4. 规避关键行业的致命风险。在客服闲聊等场景，答错可能只是体验不佳；但在医疗、金融、法律等关键行业，RAG 系统的错误可能带来严重后果： - 医疗：遗漏关键病症信息或编造药物剂量可能导致误诊。 - 金融/法律：引用了过期的旧政策或虚构法律条款，可能引发严重的合规风险与法律纠纷。科学的评估体系是保障这些高风险场景下系统可靠性的“生命线”。 5. 平衡质量、成本与用户体验。一个准确但响应极慢、或者单次查询成本极高的系统，在生产环境中是无法落地的。评测不仅关注答案的准确性（如忠实度、相关性），还要关注端到端的工程指标（如 P95 延迟、吞吐量、每千次查询成本），确保系统在保证质量的前提下，具备商业上的可持续性。