优化RAG之前，先建可比较的评估基线

RAG 能找到相关文档，回答看着也合理，演示顺利跑通，但这些还不足以证明一次优化有效。作者在 90 天 AI 工程学习的第 12 天讨论了一个工程问题：改检索、加重排、调切块之前，先记录当前系统的表现。

文章的结论很明确：先测量，再优化。它没有提供实测收益，却给出了一套适合文档问答系统的评估顺序，帮助团队分清质量提升、成本增加和主观感觉。

基线要测什么，为什么不能只看回答

基线（baseline）就是改动前的成绩单。后续实验使用相同的题目和指标，才有比较的依据。

作者建议先准备一个规模小、具有代表性的评估集。每个问题都要标明相关的源文档或文本块，以及支撑答案的证据。只保存一份参考答案不够，因为系统答错时，还需要判断是没有找到材料，还是拿到材料后生成出了问题。

评估分为三个层面：

• 检索质量看 Recall@K 和 MRR。Recall@K 关注前 K 条结果找回了多少相关内容；MRR 关注第一个相关结果排得有多靠前。
• 回答质量看 Faithfulness 和 Answer relevance。前者检查回答是否有检索上下文支持，后者检查回答是否真正回应了问题。
• 运行表现看 Latency 和 Cost per query，也就是查询耗时，以及检索上下文、生成答案所需的单次成本。

这些指标不能互相替代。找到了相关文档，不代表生成阶段一定用对证据；回答有依据，也不代表它回答了用户的问题。

检索指标和最终回答质量，需要分别检查。

作者在结尾提出，可以先建立检索基线，也可以先建立覆盖回答质量、延迟和成本的端到端基线，但没有给出统一选择。对完整的文档问答应用，至少保留这几个维度，才能看清一次改动的收益与代价。

一次只改一处，才能知道优化为什么有效

原文举了一个常见过程：系统起初使用稠密向量检索，随后加入混合检索、重排器（reranker），再调整切块策略。人工试用觉得答案更好，但检索是否改善、延迟增加多少、每次查询是否更贵，都还没有答案。

多个组件一起改，即使总分上涨，也很难知道是哪一步起作用。

作者建议按照固定顺序实验：建立基线，找出主要失败原因，只修改一个组件，用同一评估集重新运行，再比较质量、延迟和成本。收益值得付出代价，才保留改动。

例如，相关文档从未进入前五条结果，优先修改生成提示词，通常解决不了检索阶段的缺口。应该先处理找不到材料的问题。

重排器的例子也需要谨慎理解。如果加入它之后 Recall@5 不变，而 Faithfulness 提高，可以推测系统优先使用了更有帮助的上下文，但不能直接认定原因已经查明，还要检查具体查询和检索结果。

原文提到了「假设性的评估结果」，但所给文本没有列出具体数值，也明确说明这些不是基准测试结果。因此，这里只能讨论实验方法，不能引用任何提升幅度。

除了汇总指标，还要逐条查看失败问题、比较取回的文本块，并检查不同问题类型是否都受益。一个平均分，可能遮住某类问题的退步。

我的判断

这篇文章最有用的地方，是把 RAG 优化拉回了工程取舍：组件听起来更先进，不足以成为上线理由。新 embedding 模型可能改善检索，也可能增加延迟；重排器可能提高回答质量，也可能让每次请求更贵。

但它提供的是方法建议，没有实测数据，也没有不同方案的对照结果，不能据此认定某种组件组合更好。

落地时还有两个前提没讲透：评估集如何覆盖真实问题，Faithfulness 和 Answer relevance 又由谁、按什么标准判断。题目偏窄或评分不一致，比较结果就可能失真。

相比人工随手问几道题，固定评估集更便于重复比较；但「一次只改一处」也只是帮助归因的实验纪律，不能替代失败样本分析。文章自己对重排器效果的保留判断，恰好说明了这一点。

能拿来做什么

• 给现有文档问答应用保存一份评估集，为每个问题标注相关文档、文本块和答案证据，并记录改动前的检索、回答、耗时与成本表现。
• 调整切块策略、embedding 模型或重排器时，每轮只改一个组件，复用同一批问题，避免靠几次聊天体验决定是否保留。
• 遇到回答错误时，先检查相关材料是否进入前五条结果，再检查生成答案如何使用证据，把修改落到实际失败的阶段。
• 将失败查询和不同问题类型的结果保留下来，后续更新时同时检查整体收益与局部回退。