很多人第一次做 RAG，把时间全花在换向量模型上，效果却没什么变化——因为瓶颈几乎总在检索：切得太碎、只按相似度召回、把不相关的内容一起塞给模型。这一篇按「先保证召回，再谈模型」的顺序讲。
先判断：你到底需要 RAG，还是长上下文
| 情况 | 建议 |
|---|---|
| 资料总量小（几十页以内），每次都要全看 | 直接塞进上下文，最简单也最准 |
| 资料多但每次只用到其中一两段 | RAG，只带相关片段，成本与准确率都更好 |
| 需要跨多篇做归纳对比 | RAG 召回多条 + 明确要求逐条引用来源 |
| 资料频繁变化、要求强时效 | RAG（索引可增量更新），长上下文每次都贵 |
四条链路，问题通常出在第 3 条
- ① 切分（chunking）
- 把文档切成检索单元：太长会掺入无关内容，太短会丢上下文
- ② 向量化（embedding）
- 把片段转成向量；换模型必须重建整个索引
- ③ 检索（retrieval）
- 按问题找片段：召回决定上限，这一步最值得投入
- ④ 生成（generation）
- 把 Top-K 片段连同问题交给模型，并要求引用来源
切分：按结构切，不要按字数切
- 优先按文档自身结构切：标题层级、章节、表格整块保留；
- 单块目标 300～800 字，两端留 10% 重叠，避免答案被切断在边界上；
- 每块带元数据：文档名、章节路径、更新时间、权限标签——这些既是过滤条件，也是让模型能引用来源的依据；
- 表格与代码单独成块：切碎后语义全失，是最常见的错误。
检索：只做向量相似度是不够的
- ① 混合检索向量（语义相似）＋ 关键词（BM25 类）。专有名词、编号、型号这类查询靠向量往往召回不到，靠关键词反而一击命中。
- ② 重排（rerank）先粗召回 30～50 条，再用重排模型取前 5 条交给生成。重排通常比换更大的生成模型带来更明显的提升。
- ③ 元数据过滤按时间、部门、版本号先过滤再检索，比让模型从一堆过期文档里挑要可靠得多。
- ④ 控制进入上下文的总量Top-K 不是越大越好：无关片段会稀释注意力，还按输入 token 收费。
怎么评估：20 条问题就够开工
- ① 准备问题集从真实提问里抽 20 条，覆盖「答案在单篇」「需要跨两篇」「资料里没有」三类。
- ② 分别记两个指标召回率（正确片段有没有被检索出来）与答案正确率（最终回答对不对）。前者低就去改切分与检索，后者低才轮到换模型。
- ③ 回归测试每次调整切分、模型或 Top-K，都把这 20 条重跑一遍；凭感觉调参一定会退步。
| 症状 | 多半原因 | 先改哪里 |
|---|---|---|
| 答案总是差一点、漏掉关键句 | 切分把答案切断或切太碎 | 按结构切、加重叠 |
| 问型号/编号就答错 | 只用了向量检索 | 加关键词混合检索 |
| 答非所问、扯到别的文档 | Top-K 过大或没有元数据过滤 | 重排 + 过滤 + 缩小 K |
| 资料里没有也硬答 | 提示词没约束 | 明确「无依据就直说没有」 |
| 换了模型效果没变化 | 瓶颈在检索 | 回到召回率指标 |
上线前再看三件事
- 索引更新：文档改版后旧片段必须能失效，否则模型会引用过期内容；
- 权限隔离：不同用户能检索到的片段范围要在检索层过滤，不能靠模型自觉；
- 引用可回溯：返回时带上文档名与章节，用户能自己核对——这既是信任来源，也是最有效的排错方式。
常见问题
RAG 和微调该选哪个？
需要「记住事实」用 RAG，需要「改变说话方式或输出格式」用微调。事实会变、需要引用来源的场景，微调既贵又难更新；而语气、格式、分类口径这类稳定能力，微调更划算。
向量库必须用专门的产品吗？
小规模（几万片段以内）用本地向量索引或数据库扩展就足够，数据量到百万级再考虑专门的向量数据库。先跑通链路，再换存储。
为什么检索结果看起来相关，答案还是错的？
常见原因是片段里缺少回答所需的上下文（被切断），或一次给了太多互相矛盾的片段。先看「正确片段是否被召回」，再看模型有没有被要求逐条引用来源。
