RAG：检索能补事实，补不了推理

准备五十个真实问题，人工标出答案在哪一段，看检索命中率。命中率低于七成，先修文档。

三步，每步都可能出错

切块：把文档切成小段。切大了检索不准，切小了上下文不全，跨段的信息直接丢。

检索：按问题找最相关的几段。找错了，后面全错，而且模型不会告诉你它没找到。

生成：基于这几段回答。它可能读错，也可能在段落之间自己补一句。

三步里最难调的是切块。按固定字数切最省事，也最毁结构。按小节切、保留标题，效果好很多。

还有一种常见错误：把表格按行切开，一行一段，语义全丢。表格整块保留。

答案就在某一两段里。查制度、查参数、查条款、查产品说明。

知识更新频繁，重训模型不现实。政策、价格、库存这类天天变的东西，检索比重训快得多。

需要给出处。RAG 天然能带来源，这在客服、法务、医疗辅助场景里是硬需求。

三个条件满足，RAG 的投入产出比通常不错。

还有一个隐含条件：提问方式相对固定。用户问法千奇百怪时，检索命中率会明显下降。

问题需要跨多份文档推理。比如“这三份合同里哪份的违约责任对我们最有利”，检索只能给你三段，比较和判断还得模型做，而它做得并不稳。

知识本身不在文档里。文档只写了流程，没写为什么这么定，你问原因，它只能编。

文档质量差。扫描件、表格、口语记录，切块之后语义碎片化，检索出来的段落连人都读不懂。

还有一种：问题太泛。“帮我总结一下公司的情况”，检索无从下手。

某团队做了个制度问答，用户问“出差住宿标准是多少”，系统答“按职级报销”。

听起来对，其实没用。因为制度里写的是“总监级以下每晚上限六百，以上八百”，检索到的却是概述段。

问题出在切块：概述段和明细段被切开了，检索命中了更“像问题”的那段。

修法很土：把明细表整块保留，标题带上“住宿标准”，再给它更高的检索权重。改完之后答案就具体了。

补充一句RAG 的效果，七成取决于文档整理，三成取决于模型。先把文档理顺，再谈调参。

RAG 和长上下文怎么选？

单份、一次性的用长上下文；多份、反复查的用 RAG。两者也能一起用，先检索再塞进长窗口。

检索不准怎么调？

先看切块，再看有没有加关键词检索，最后才考虑换 embedding 模型。顺序别反。

怎么评估效果？