向量模型换了三次，检索还是不准：RAG 里真正被忽略的那一层

一个反复上演的场景

产品经理抱怨：“知识库答不对，换个更强的模型吧。” 工程师换了模型，效果没变；再换，还是没变。

问题通常不在生成端，而在检索端——大模型只是把检索到的错误片段组织得很流畅而已。RAG 的上限由召回决定，而召回的命门是 embedding 和切分策略，这两块恰恰最少被认真评测。

向量模型要看的不是榜单排名

MTEB 榜首每周都在换，但榜单分数和业务效果相关性很弱：榜单测的是通用语义相似，而你的场景满是编号、型号、缩写、中英混排。

真正该看的四个维度：

1. 语言与领域匹配度 中文技术文档、法律条文、医疗记录分布差异极大。在英文通用语料上训好的模型，对”退火工艺参数”这类词的距离计算可能完全失效。优先选中文与垂直领域有明确训练数据的模型。

2. 维度与成本的乘积 1024 维与 3072 维的召回差异在多数业务里小于 2 个点，存储与检索成本却差 3 倍。真正的分水岭是”要不要 rerank”——接了重排序后，粗排模型的边际收益快速衰减。

3. 指令前缀与查询/文档不对称 不少模型要求 query 加 query: 、document 加 passage: 前缀，漏掉就掉 5~10 个点，也最容易造成”新模型还不如旧模型”的错觉。

4. 最大输入长度 它决定了你的 chunk 能有多大。512 token 上限的模型，遇到整页表格就只能硬切，句子断裂后语义全丢。

切分策略比模型更能拉开差距

实测经验：相同模型下，把固定长度切分换成结构感知切分，召回命中率常能提升 15% 以上。

具体做法：

• 先按文档结构（标题层级、表格、代码块）切，再在结构内按长度切
• 每个 chunk 前拼接所属章节标题路径，如「产品手册 > 故障排查 > 错误码E102」
• 保留 10~15% 重叠，避免答案跨边界被切断
• 表格单独成块并转 Markdown，不要与正文混切

第二点尤其关键：它把”这个片段讲的是什么”这个上下文信息直接编码进了向量，成本几乎为零。

一套两小时能跑完的自测方法

别凭感觉选模型。准备 50 条真实问题，人工标注对应的正确 chunk（半天，但一劳永逸）：

1. 对每个候选模型，用你的 query 检索 top-5
2. 统计 Recall@5（正确 chunk 是否在结果里）和 MRR（正确结果排第几）
3. 记录 P95 检索延迟和单次成本

多数情况下你会发现：前三名的 Recall@5 差距不超过 5 个点，但延迟差 3 倍、价格差 10 倍。这时选”够用且便宜”的那个，把预算投到 rerank 和 chunk 质量上，回报更高。

什么时候该微调 embedding

只有一种情况值得：领域专有名词多，且通用模型区分度明显不足（表现为相近但不相关的文档频繁混召回）。用几百对正负样本做对比学习即可见效，成本远低于微调生成模型。但请先确认 chunking 与 rerank 都已优化——顺序错了，投入就是浪费。

小结

RAG 调优的正确顺序是：查询理解 → 切分 → embedding → rerank → 生成。 大多数人从最后一环开始改，所以反复失败。下次检索不准时，先别急着换模型，去翻一下你的 chunk 长什么样。