做知识库问答，最容易翻车的环节往往不是模型，而是检索。用户问的问题，知识库里明明有答案，检索却把最相关的那一段漏掉了，模型只能拿一堆不相关的内容硬编，出来的答案驴唇不对马嘴。这类「知识库有料却答不准」的翻车，占了实际落地里的一大半。
检索不准不是玄学，拆开看就四类原因：切片切坏了、向量召回漏了、排序没排对、问题本身没写好。这篇把这四类原因一个一个说清，再给一套能直接上手的优化顺序。
原因一：切片把上下文切碎了
知识库要做向量检索，第一步是把长文档切成小块（chunk）。切多长、按什么切，直接决定检索质量。切太短，一段话被拦腰截断，语义不完整；切太长，一个 chunk 里塞进好几个话题，召回的相关性被稀释。更糟的是按固定字数硬切，把本来连着的「因为…所以…」切到了两个块里，模型拿到的是一个断句。
解法是按语义边界切，而不是按字数切。优先按段落、标题、列表这类天然边界分块，再给相邻的块留一点重叠，避免关键词正好落在切缝上。切完之后的块，要能被独立读懂——这是判断切片质量最朴素的标准。切片的边界如果改动了，一定要跑一轮 变更后验证清单，确认没把原来的好答案切坏。
原因二：向量召回漏掉了正确答案
向量检索靠的是语义相似度，但「语义相似」不等于「回答得上来」。用户问「怎么退押金」，知识库里写的是「押金返还流程」，向量可能因为措辞差异把这段排到了很后面，甚至直接漏掉。召回不足是知识库答不准最隐蔽的原因——它不报错，只是静默地漏。
解法是混合检索加召回兜底：向量召回和关键词召回（BM25）各跑一遍，结果取并集，让「同义词不同字」和「同字不同词」两种命中的内容都能进候选。召回阶段宁多勿少，先保证正确答案进了候选池，排序的事交给下一步。这一步的产出要有据可查，最好保留每次召回了哪些块的记录，方便事后追溯——这和 证据包 的思路一致：先留痕，再定位。
原因三：排序没把最相关的排到前面
召回捞回来几十个候选块，但模型能看的上下文有限，只能取最前面的几块。如果排序算法把真正相关的块排到了第十名开外，模型根本看不到它，答案照样翻车。只靠向量的原始相似度排序，经常被长文本、高频词「刷分」，真正命中的短而准的段落反而排后面。
解法是加一层重排序（rerank）。用专门的交叉编码器对「问题 + 候选块」逐对打分，这种打分方式比向量相似度更吃语义匹配，能把真正回答得了问题的块捞上来。重排之后，再给模型喂最靠前的几块。如果对排序结果没把握的高风险场景，别让 Agent 自己拍板，走 人工复核抽检，抽几条答案核对引用来源。
原因四：问题没写好就直接拿去检索
用户的原始问题，往往不适合直接扔进检索。口语化、指代不明、一句话里塞两个问题，都会让检索跑偏。比如用户问「那个功能好用吗」，这个「那个」指什么，检索根本无从下手。
解法是在检索前加一步 Query 改写：把口语问题改写成明确的检索意图，把「那个」还原成具体的功能名，把「好用吗」拆成可检索的事实问题。多轮对话时还要结合历史，把省略的主语补全。改写得越明确，检索命中率越高。这一点和知识库的长期维护是一体的——问题侧要改写，内容侧要防陈旧，两者都得抓，才能稳住准确率，具体可以参考 知识库陈旧内容巡检 的做法。
一套能直接上手的优化顺序
四个环节不要一把抓，按「成本从低到高、见效从快到慢」的顺序来：先做 Query 改写和混合召回，这两个改动小、见效快；再调切片策略，因为切片一变，历史向量要重建，成本高；最后上重排序，它最吃资源，但也最能把准确率顶上去。
每改一步，都用同一批问题做回归测试，看准确率是升了还是降了。别用「感觉准了」做判断，要有一份固定的测试集和打分标准。改到满意之后，再把这套检索流程固化下来，配合 质量门禁，让每一次变更都有据可查、可回退。
总结
知识库检索不准，拆开就四件事：切片按语义别按字数、召回用混合检索兜底、排序加一层 rerank、问题先改写再检索。优化的顺序是先从便宜好改的入手，再用固定测试集验证。把这四环补上，RAG 就能从「偶尔答得准」变成「稳定有据可查」，知识库才真正成了能用的资产，而不是一堆检索不到的文档。
