很多人第一次搭 RAG，是把文档切一切、丢进向量库、把相似度最高的几段塞给模型，结果答非所问，却不知道问题出在向量化、召回还是排序。这篇不讲 RAG 全貌，只把检索这一段拆成三个可独立调整的环节，给每一步的判断标准和排查顺序，让人能定位到底是哪一步拖了后腿。
很多人第一次搭 RAG，流程是：文档切一切、丢进向量库、把相似度最高的几段塞给模型，结果答非所问。这时候最容易犯的错是笼统地说「检索不行」，然后胡乱调参数。实际上检索是三层可独立调整的环节——向量化、召回、排序，每层出问题的症状不一样，定位方法也不一样。
这篇只讲检索这一段，不讲 RAG 全貌。目标很实在：让你遇到烂答案时，能按顺序判断到底是哪一环拖了后腿，而不是凭感觉换模型。下面按三个环节拆，最后给一套排查顺序。
第一步：文档切分与向量化
切分颗粒度直接决定检索上限。切太碎，一段话被拆成几个没有主语的片段，召回后模型拼不出上下文；切太大，一个片段里混了好几个主题，向量被稀释，相似度排名就不准。务实的做法是先按文档结构切：标题成段、段落成段、表格单独成块，结构切完再按字数上限兜底拆分，不要一上来就按固定字数硬切。
- 结构优先
- 先按标题、段落、表格的自然边界切，再用长度限制兜底
- 保留定位
- 每个片段必须记住它来自哪个文件、哪一页、哪一节，否则召回后无法回溯原文
- 清洗前置
- 页眉页脚、乱码、重复导航先在入库前去掉，脏数据向量化后无法挽回
embedding 模型选型看三件事：是否支持中文和你的目标语种、维度和调用成本、以及后面要不要搭配重排模型。具体有哪些候选、各自什么特点，到 /embeddings 对照当时的模型清单，不要凭记忆选。文档本身格式太乱、连清洗都过不去的，先看 /stacks/vector-dbs 里关于入库流程的说明。
第二步：召回——别只靠一种相似度
单一向量召回有个天生短板：专有名词、产品编号、缩写很容易被语义近似的结果淹没。你搜一个具体型号，返回的却是一堆「意思相近」的段落。解决办法不是调相似度阈值，而是加一路关键词检索并行，两路各自取前若干条，再合并去重。
| 召回方式 | 擅长 | 容易漏 |
|---|---|---|
| 向量召回 | 换种说法也能找到的语义相近内容 | 精确编号、专有名词、缩写 |
| 关键词召回 | 字面完全匹配的词、编号、代码 | 同义改写、口语化提问 |
| 两路合并 | 覆盖面最广，是多数场景的默认起点 | 合并后候选池需要控制大小 |
- 两路召回各自取前若干条再合并，候选池不是越大越好，池子太大排序模型会失效
- 多语言或多来源语料要决定分开建索引还是混建，混建容易让某一种语言长期占优
- 验收方式是拿一批真实问题看正确答案有没有进候选池：进了候选却没进最终结果，问题在排序；根本没进候选，问题在向量化或召回
- 合并去重时按什么字段判重（片段 id 还是原文位置）要提前定，不然同一段会重复占位
第三步：排序与过滤——把最该看的顶上来
粗排通常用向量相似度快速过一遍，精排再用重排模型或交叉编码器细看。重排确实更准，但它会加延迟、加成本，所以要先量出不加重排时的基线效果，再决定加不加。如果候选本来就少、问题很简单、或者对延迟极其敏感，加重排只会更慢。
- 先量基线固定一批问题，记录不加重排时的最终答案质量，作为对照
- 再加精排接入重排模型后跑同一批问题，比较提升幅度和延迟变化，值不值自己判断
- 标定阈值相似度分数不是跨模型可比的绝对值，换了 embedding 或重排模型，原阈值必须重新标定
- 做配额控制拼上下文前处理重复占位：同一文档的多个片段、过旧的资料，都要限制它占的名额
过滤阈值要谨慎设。很多人拿一个看起来合理的相似度分数当硬门槛，但换模型后这个门槛就失效了，直接把正确答案拦在外面。阈值应该是跑过回归集之后标定出来的，不是拍脑袋定的。
怎么判断问题出在哪一环：排查顺序与验收
检索质量不能靠感觉。固定一批真实问题做回归集，每次只改一个环节，记录命中率和最终答案质量，别一次改三处，否则不知道是哪处起作用。语料更新、切分规则改动、换 embedding 模型，都会让效果漂移，所以要长期盯着。
- 第一步先看原始文档有没有被正确切分，片段本身是不是完整的
- 第二步看正确答案在不在召回候选里，不在就往向量化和召回查
- 第三步看排序后正确答案排在第几，在候选里但排名靠后就是排序问题
- 最后才怀疑生成模型，前提是前三步都验干净
- 改 prompt 能掩盖一部分检索问题，但掩盖不等于解决，先把检索验收干净
如果你的问题是「不知道该查哪些项」，到 /knowledge-base-corpus-audit 对照自查清单过一遍。那里不讲理论，只列检查项，适合当成体检表用。
检索出问题，先分环节，再改参数；顺序错了，改哪儿都是碰运气。下一步把上面的排查顺序固定成团队里的验收流程，顺便到站内核对当时可用的 embedding 与向量库清单，别让选型凭记忆拍板。→
常见问题
向量化是不是必须用最贵的 embedding 模型？
不一定。很多场景里切分方式和召回策略的影响比模型档位更大。先用中等档位的模型跑通链路，量出基线，再换更强的模型做 A/B 对比，看提升是否值得增加的成本和延迟。换模型后要重新标定相似度阈值。
召回回来的内容都对，但答案还是不准，问题在哪？
先别急着换模型。按顺序查：切分有没有把一句话劈成两半、召回条数是不是太多把关键段挤出上下文、排序后同一文档的片段是不是重复占位、拼上下文时有没有加冲突或过时的资料。这几步排完，再考虑生成侧的提示词。
小团队做 RAG，检索这块要投多少人？
先跑通最小链路：一种切分、一种 embedding、单路召回加阈值过滤，用真实问题验收。跑通后再按痛点加，比如专有名词查不准就加关键词召回，排序差就加重排。不要一开始就把所有环节堆满，否则出问题无法定位是哪一环导致的。
