把文档塞进向量库就算 RAG？先过这三道召回关

摘要：RAG 答不准，多数团队第一反应是换更大的模型。但真正拉低准确率的，往往是切分、召回和上下文编排这三步。先量出 recall@k，再决定要不要换模型，能省下大部分试错成本。

一套 RAG 系统上线后最常见的场景是：用户问得明明白白，模型却回答"文档中没有相关信息"。把日志拉出来看，答案明明就在知识库里，只是没被检索到。模型拿到的是不相关的片段，再强的推理能力也无从发挥。

一、第一关：切分方式决定了语义是否完整
很多团队的第一步是把 PDF 按固定字数切开，500 字一段。这种做法在合同、财报、产品手册上问题很直接：一条免责条款被切成两半，一张对比表的表头与数据分属两个 chunk，检索命中其中一半，模型看到的是残缺信息。反过来，段太大同样不行：两千字一个 chunk 会同时包含多个主题，向量被平均成一个模糊的方向，命中精度反而下降。经验区间是 200 到 500 个 token，但结构边界优先于长度指标。

更稳的做法是按文档结构切分，优先识别标题层级、段落边界和表格区域；必须按长度切时，保留 10% 到 15% 的重叠，并给每个 chunk 附上所属章节路径。这一步几乎不增加成本，却常把答案命中率从"找不到"变成"找得到"。

二、第二关：单靠向量检索，精确匹配会漏
向量检索擅长语义相近，但对型号、错误码、订单号、法条编号这类精确词项并不敏感。用户搜"HG-3200 报错 E104"，与文档里的表述在语义空间里可能相距很远，相似度反而低于一段泛泛的概述。

通用解法是混合检索：BM25 负责字面命中，向量负责语义泛化，两路各取前 20 条，用 RRF（倒数排名融合）合并，k 取 60。融合后再统一排序，能同时兼顾"提到的词"和"意思接近"。中文场景还要注意分词，错误码、英文缩写应加入自定义词典，避免被切碎。另一个隐形坑是 embedding 模型的语言与领域不匹配：用英文语料为主训练的模型处理中文工单，排序经常失真，换模型之前应先用同一批问题做对比。

三、第三关：重排与上下文预算
召回 20 条不等于全部塞给模型。一是上下文越长，中间位置的信息越容易被忽略，这是"lost in the middle"现象，相关段落放在开头或结尾的效果明显好于放在中间；二是无关片段会稀释注意力，也抬高成本。

实际做法是两段式：粗排召回 20 到 50 条，再用 cross-encoder 重排模型精排，取前 5 条进入上下文；把最相关的放在最前，并附上来源标注。重排模型不必很大，几百 MB 的 cross-encoder 就能明显改善排序，延迟通常只增加几十毫秒。这样既控制了 token 预算，也让答案更容易被追溯。

四、用数据判断该修哪一环
建议先建一个 50 到 100 条的问题集，覆盖事实查询、跨文档对比、无法回答三类，再分别量三个指标：recall@5（正确答案是否进入前 5）、答案命中率、幻觉率。如果 recall@5 只有 0.6，换模型没有意义，先修切分与召回；如果 recall@5 已到 0.9 而答案仍不准，才轮到提示词与模型能力。

这套评测还有一个副作用：问题集本身就是回归测试集，改切分策略、换 embedding 模型、调 top-k 都能立刻看到影响，而不是靠个别案例拍脑袋。

结语
RAG 的本质是把"找资料"和"写答案"拆开，找资料这一半做不好，模型再强也只是在错的基础上加工。把切分、混合召回、重排三关过一遍，再用量化指标定位瓶颈，通常比直接换一个大模型更省钱，也更快见效。

标签：RAG, 向量检索, 大模型应用, 检索增强, 工程实践