获课：shanxueit.com/13301/

RAG实战里，最难的不是召回，是让文档“切对了”

做RAG应用开发的人，大概都经历过这种场景：知识库明明有正确答案，但AI就是找不到，或者找出来的是错的。你折腾了半天召回策略、调了无数轮重排参数，最后发现问题出在最基础的环节——文档切片没切好。

RAG这条链路拆开来看就三件事：文档怎么切、怎么找、找到后怎么排。看起来简单，但每一步都有它自己的“坑”。今天不聊代码，聊聊我从实战里踩出来的体会。

切片：切太碎丢语义，切太长丢精度

文档切片是RAG的起点，也是最容易被低估的环节。很多人觉得“按固定字符数切不就完了”——结果就是一段完整的业务逻辑被拦腰切断，上下文全丢了。

切片的本质，是在两个互相冲突的目标之间找平衡。切得细，召回时命中率高，但每块包含的语义信息太少，模型很难理解完整语境；切得大，语义完整了，但检索精度下降，噪音太多。一个比较务实的策略是按语义边界切——比如Markdown按标题切、代码按函数切、PDF按段落边界切，而不是死磕固定长度。还可以用重叠窗口来弥补边界信息丢失，切的时候让相邻片段有部分重叠，确保关键信息不落在切缝上被丢掉。

还有一种做法是引入语义分割模型，让AI判断哪里是自然断句点。虽然开销大一点，但对长文档的切片质量提升很明显。

召回：不是“越多越好”，是“越准越好”

召回阶段最常见的问题有两种：召回不足（该找到的没找到）和召回过量（找来一堆不相干的）。前者让AI缺上下文，后者让重排环节压力过大。

解决召回不足，可以用多路召回策略——关键词召回（BM25）和向量召回并行，然后合并结果。BM25擅长处理精确术语匹配，向量召回擅长理解语义相似，两者互补能覆盖更多情况。召回过量的问题，则靠调整相似度阈值和限制召回数量来解决。还有一个容易被忽略的点：索引字段的设计。你在建向量库时，除了存文本向量，还把文档的元数据（比如类型、时间、来源）一起存进去，召回时用元数据做预过滤，能大幅缩小检索范围。

重排：把“相关”变成“有用”

召回阶段找出来的是“跟问题有点像”的片段，但“有点像”跟“真正有用”之间还差着一层。重排模型干的就是这件事——给召回来的候选片段重新打分，把最可能帮助模型回答问题的那几个排在前面。

为什么召回之后还需要重排？因为向量召回的相似度计算是粗粒度的，它看的是“这段话跟问题的语义接近程度”，而不是“这段话对回答问题有多大的信息增量”。一个片段可能语义上跟问题很接近，但内容是个空话套话，对回答毫无帮助；另一个片段语义距离稍远，但包含了回答问题所需的具体数据。重排模型能通过交叉编码更精细地判断每个片段的信息价值，把后者顶上去。

实战中比较有效的做法是用小模型做粗排（快速筛掉明显不相关的），再用大模型做精排（对剩下的几十个片段精细打分）。既控制了成本，又保证了精度。

还有一个容易被忽略的点

整套RAG流程跑通之后，别忘了反向验证——拿着最终生成的答案去反查它引用了哪些片段，看这些片段是否真的支撑了答案。如果答案里引用了某个具体数据，但召回片段里压根没有这个数据，那大概率是模型幻觉了。这种事后验证能帮你发现召回和重排环节的盲区，形成持续优化的闭环。

说到底，RAG的每一个环节都在做同一件事：在信息密度和语义完整度之间找到最佳平衡。切得好，检索就轻松；召回得准，重排就高效；排得对，最终答案就有据可依。把这套逻辑吃透了，RAG就算是入了门。