RAG 评估笔记：把召回质量与回答质量分开检查

1. 先建立可以解释的评测集#

评测问题不应该只有问题和标准答案，还应保留：

• 问题依赖的原始文档；
• 能支持答案的证据片段；
• 容易被误召回的相似片段；
• 问题类型，例如事实查询、跨段归纳、表格读取或多跳推理；
• 无法从知识库回答的拒答样例。

只有知道“证据应该在哪里”，召回率和引用正确性才有可解释的依据。否则评估很容易退化成用另一个模型判断回答“看起来像不像对”。

2. 检索阶段关注证据是否到场#

对每个问题，我会记录 BM25、向量检索、融合排序和重排后的候选列表，并检查：

• 正确证据是否进入候选集合；
• 它在哪个阶段被提升或过滤；
• 专有名词、数字和原句是否更依赖关键词检索；
• 语义改写是否更依赖向量检索；
• top-k 增大后，噪声是否淹没有效片段。

如果候选阶段没有正确证据，应优先检查解析、切块、索引和查询改写；如果候选中有、重排后消失，则问题更可能出在融合策略、阈值或重排模型。

3. 上下文组装也需要单独检查#

检索结果正确，不代表最终 Prompt 中仍然正确。常见问题包括：

• 片段被截断，关键限定条件丢失；
• 多个来源合并时顺序混乱；
• 表格行列关系被转成无法理解的纯文本；
• 引用编号与实际片段错位；
• 总 token 超限后，最重要的证据被后加入的内容挤出。

我会保存最终送入模型的上下文快照，并让引用编号与文档、页码或块 ID 建立稳定映射。

4. 生成阶段不只看答案相似度#

回答评估至少可以拆成：

• 正确性：结论是否与证据一致；
• 完整性：问题要求的要点是否覆盖；
• 忠实度：是否加入证据中不存在的断言；
• 引用正确性：引用是否真正支持对应句子；
• 拒答能力：证据不足时是否明确说明边界。

开放式问题不适合只使用字符串匹配。可以结合规则、人工抽查和模型评审，但模型评审也应看到问题、证据、回答和清晰的评分标准。

5. 用失败类型推动迭代#

我更关心错误分布，而不是孤立的总分：

1
解析缺失 → 切块断裂 → 未召回 → 重排丢失
2
    → 上下文截断 → 生成偏离 → 引用错位

每一类错误对应不同的修复位置。把所有问题都交给 Prompt，会让短期样例看起来改善，却难以形成稳定、可重复的工程进步。

6. 迭代时的最小记录#

• 评测集版本和知识库版本；
• embedding、切块和索引配置；
• 各阶段候选与最终上下文；
• 模型、Prompt 和采样参数；
• 失败分类与人工复核记录。

RAG 评估的目的不是得到一个好看的数字，而是让每次改动都能回答：它改善了哪类问题，又可能牺牲了什么。