RAG 的关键不是检索，而是证据链

RAG 常被概括为“先从知识库检索，再让模型回答”。这个描述忽略了中间多个可能失真的环节：问题可能没有表达清楚，文档可能切错，召回结果可能相似却无关，模型也可能忽略证据继续依赖已有记忆。

可靠的 RAG 不是给模型更多文字，而是建立一条能够回答“答案依据来自哪里”的证据链。

一、问题是否适合直接检索

用户问题经常包含省略、指代和多个子任务。直接把原句送入检索器，可能得到字面相似却无法回答的片段。问题改写应保留原始意图，并记录改写前后内容，避免系统在用户看不到的地方改变问题。

二、切片决定了证据能否保持完整

固定长度切片简单，却可能把定义、条件和例外拆开。较大的切片保留语境，但会带来更多干扰。切片策略应根据文档结构设计，并保留标题、章节、来源和版本等元数据。

三、召回与重排解决不同问题

召回阶段追求不要漏掉潜在证据，重排阶段再判断哪些候选最能回答当前问题。如果只看向量相似度，关键词重复的片段可能排在真正答案前面。

评测时应分开记录“正确证据是否进入候选集”和“正确证据是否排在足够靠前的位置”，否则无法判断应该改向量、改查询还是改重排器。

四、生成必须被证据约束

把片段放进提示词并不能保证模型使用它。提示应明确要求仅依据提供材料回答、标注引用，并在证据不足时拒绝推断。生成后还要验证引用是否真的支持对应句子，而不是只检查链接是否存在。

五、用失败分类替代笼统准确率

• 问题理解错误：查询偏离原始意图。
• 知识缺失：知识库没有正确资料或版本过期。
• 召回失败：正确片段没有进入候选集。
• 重排失败：正确片段位置过低，被截断或忽略。
• 生成失败：证据充分但回答仍出现无依据内容。
• 引用失败：答案正确但引用无法支持具体陈述。

这套分类让优化有明确对象，也避免把所有问题都归因于“模型不够强”。

六、一个最小可验收闭环

1. 为每个测试问题准备可核对的参考证据。
2. 保存原始问题、改写查询和候选片段。
3. 记录召回位置、重排分数和最终上下文。
4. 检查答案中的每项事实是否被引用支持。
5. 证据不足时验证系统是否明确拒答。