AI Know · 技术研究笔记
RAG 出错大多在切分、召回与引用，不在模型本身
切分粒度决定召回上限，过粗过细都会丢信息；检索排序比向量库选型更能决定答案质量；引用必须能回溯到原文位置，否则无法核对
三分钟读懂
先看结论，再决定是否深读
- RAG 出错大多在切分、召回与引用，不在模型本身
- 切分粒度决定召回上限，过粗过细都会丢信息
- 检索排序比向量库选型更能决定答案质量
- 引用必须能回溯到原文位置，否则无法核对
- 评测要覆盖长尾输入，否则上线后集中爆发
核心原理
RAG 的直觉是“给模型外挂知识库”，但工程上它是一个多阶段系统。文档解析、切分、向量化、索引、召回、重排、拼上下文、生成、引用标注，每一步都会引入误差，而且误差会逐级放大。切分把一段完整逻辑切断，召回就永远拿不到完整证据；召回排序把正确片段压到第 20 位，拼上下文时就被截断；引用标注只给文档名不给段落号，核对时就得人工翻整篇。
所以排查 RAG 问题时，应该先看证据链：模型回答里引用的那几句话，是否真的出现在被召回片段中？被召回片段是否来自正确文档的正确位置？如果这一步都过不了，换模型毫无意义。
技术细节
输入侧：切分与索引。 固定长度切分最省事，但最容易破坏语义。一份合同按 512 token 切，付款条件可能横跨两个块，召回时只能命中半句。更稳的做法是结构化切分：按标题层级、表格行、条款编号切，再对超长块做二次拆分，并在块首保留所属章节路径。元数据同样关键：文档版本、生效日期、权限标签、页码，都要随块存入索引，否则后续引用无法核对，越权也无法拦截。
推理/执行侧：召回与重排。 向量召回擅长语义相似，但对编号、专业缩写、精确匹配很弱。生产系统通常做混合召回：BM25 加向量，各取前 50，再交给重排模型打分，取前 5 到 8 条拼上下文。重排是性价比最高的一环，因为它直接决定进入上下文的是哪几条。上下文拼接也有讲究：按相关性排序、标注来源编号、控制总长度，避免把低分片段塞在中间干扰模型。
输出/评测侧：引用与核对。 生成时要求模型对每句结论标注来源编号，只允许使用给定片段，不允许外部知识。输出后做引用核对：把回答中的每个编号对应回片段，检查句子是否被片段支持。这一步可以用规则加小模型实现，不必每次都调大模型。评测集要分层：高频问题、长尾问题、跨文档问题、无答案问题。无答案问题最能暴露幻觉，因为模型被逼着编。
工程实践
- 先做引用核对，再调模型。 上线前建一套自动核对脚本：回答中的每条引用，必须能在对应片段中找到语义支持，支持率低于阈值就告警。这比盲目换模型更快定位问题。
- 切分按结构走，别按字数走。 优先解析标题、表格、条款，按语义单元切分，超长再拆。每个块带元数据：来源、页码、版本、权限。元数据完整，召回和引用才有基础。
- 混合召回加重排，设最小分数阈值。 BM25 加向量各取前 50，重排后取前 5 到 8。低于阈值的片段直接丢弃，宁可回答“未找到”，也不要让低质片段进入上下文。同时把阈值和重排分数记入日志，方便回溯。
风险边界
成本。 混合召回加重排会增加计算量，重排模型和大模型调用都是成本。缓解方式是缓存高频查询结果、对重排做批量推理、按查询复杂度动态决定是否重排。
幻觉。 即使给了上下文，模型仍可能编造。必须强制引用、要求无答案时明确说“未找到”，并用核对脚本过滤。
越权调用。 召回层要带权限过滤，用户只能检索其有权限的文档。权限校验放在索引查询阶段，不要放在生成之后，否则敏感片段已经进入上下文。
长尾输入。 错别字、口语、编号混排、跨语言查询，都会拉低召回。需要查询改写、同义词扩展和兜底策略，并单独建长尾评测集。
延迟。 多阶段流水线叠加，首字延迟容易升高。可以对召回和重排做并行、对上下文做流式拼接，先返回已确认的片段，再补充后续内容。
RAG 的竞争力不在模型参数，而在证据链的可核对程度。把切分、召回、引用三段做扎实，比换十次模型都有效。