RAG系统输出质量下滑，常见诱因是检索阶段拿回了大量无关信息。碰到这种场景，很多团队会直接换一个更强的Embedding模型——但如果没有先定位瓶颈，这可能只是用算力换直觉。
检索质量不是一个独立指标，而是由分块策略、查询改写、Embedding模型、以及排序逻辑共同决定。这篇文章给出一个可执行的调优路径：先构建评估集，再用同样的评估集逐项优化分块、查询改写、Embedding和重排序。所有改动都在统一指标上度量，避免“感觉好但不知好在哪里”。
一、没有评估集，调优就是摸黑
评估集的价值在于把检索质量问题变成可复现的数字。建议从真实业务中抽取至少100条查询，覆盖常见用户问题、长句、短词、实体密度高的场景。对每条查询标注“应该被检索出来”的文档ID，如果业务资源有限，可以只标记1个最相关文档，但多个相关文档的情况更能反映召回能力。
评估脚本可以计算以下三个指标：
- Recall@K：前K条结果中出现相关文档的比例，K通常取5或10；
- MRR（Mean Reciprocal Rank）：第一个相关文档排名的倒数平均值；
- NDCG（Normalized Discounted Cumulative Gain）：考虑排序位置与相关等级的综合指标。
输出结果后，不要只看指标高低，要做错误分析。把未召回的相关文档捞出来，看它们为什么没进入TopK：是被分块切坏了？还是查询本身太模糊？还是Embedding的语义空间无法覆盖这种表达？这决定了下一步调什么。
二、分块策略：最便宜有效的优化
分块是最容易被忽略却影响极大的环节。固定字数的分块操作简单，但会切断段落间的语义链路。例如：“该方案的成本包括硬件采购”和“软件授权两大部分”被切成两块，检索“项目成本构成”时，两块都不完全匹配。
调整分块时，建议关注三点：
- 块大小（chunk_size）与检索粒度：块越小，匹配越精确，但容易丢失上下文；块越大，信息完整但噪声也多。常见起点在300-500个中文字符左右，具体需要根据文档类型实验。
- 块重叠（chunk_overlap）：让相邻块保留一定重复区域，可以在大概率上避免关键信息被分割。重叠区域可设为50-100个字符。
- 对齐语义单元：对标题、段落、表格等结构化内容优先做切分，而不是一刀切。例如把“销售报告”“技术规格”等小节作为整体。
在同一个评估集上，固定其他变量，只调整分块参数，如果Recall@K明显上升，说明问题出在分块。调分块不涉及模型推理，成本低，应该排在最前面。
三、查询改写：用LLM拓宽召回入口
向量检索依赖查询与文档在语义空间的接近。用户口语化的查询与书面文档天然存在表达差异，比如“这玩意怎么弄”和“如何安装部署此系统”。直接用原始查询检索，召回效果通常会打折扣。
一种普遍做法是用LLM做查询改写。具体可以尝试以下策略：
- 扩展式改写：把简略表达补全成完整描述，比如“深圳居住证续签”改为“深圳居住证续签需要什么材料、流程是什么”。
- 生成多个子查询：将复杂或包含多意图的查询拆成2-3个独立查询，分别检索后再合并结果。
- 控制改写幅度：改写不是重写，保留原文的关键实体与限定词，否则容易语义漂移。
需要警惕的是：改写不一定带来正向收益。有些原始查询已经是领域内精准表达，改写反而引入无用信息。因此必须在评估集上对比原始查询与改写后查询的指标。如果加入改写后Recall@K下降或基本持平，则没必要保留。
四、Embedding模型：用业务数据说话，不依赖公开榜单
当分块和查询改写调整到位，召回率仍无法满足要求时，才是更换Embedding模型的时机。
更换模型的动力来自两种场景：一是现有模型在领域专有名词或行业表述上表现不佳；二是检索场景包含多语言、代码或长文本，需要特殊的向量空间。
评估Embedding模型时，要注意：
- 公开榜单的任务分布和你的实际场景常常不同，不能直接作为选型依据。
- 使用与线上一致的分块和查询改写流程，在自有评估集上对比Recall@K、MRR。
- 尝试领域微调模型：通用模型在垂直领域往往不够，如果业务语料特点明显，可以选用在相关语料上继续预训练过的模型。
- 控制变量：同一时间只更换一个模型，并确保评估集不变。
这里有一个常见的误区：把“模型维度更高”等同于“检索效果更好”。维度高低不是检索效果的唯一决定因素；需在同一评估集上对比评测，避免以维度判断模型优劣。真正重要的是模型在业务数据上是否产生了紧凑且有判别力的向量分布。
五、重排序：把“相关”从模糊变成精确
如果相关文档进入了Top100但Top10里被大量无关结果占据，问题可能出在初选排序，但也可能由分块、查询改写或候选集不足导致，需要结合错误分析定位。向量检索的相似度计算是粗粒度交互，难以理解复杂语义细节。这时可以考虑加一个重排序阶段。
工程上常见方案：
- 两段式检索：先用轻量向量检索召回Top50或Top100，再用更强的重排序模型在这个候选集上重新打分，截取Top5-10进入生成。
- 重排序模型的选择：优先考虑能建模查询-文档交互的模型，但交互层深度与效果并非必然正相关，需要结合具体模型和任务验证，同时推理成本也会随复杂度上升。
- 混合检索：把BM25等关键词匹配得分与向量相似度加权结合，能提升实体和精确匹配场景下的表现。例如产品型号“A12B-X3”在向量空间中往往被语义展开，导致精确检索失败。
引入重排序后，除了观察Recall@K，还要关注Top1和Top5准确率，因为生成质量主要取决于最终进入上下文的前几个片段。
六、调优顺序与持续迭代
综合以上，推荐的调优顺序是：
- 构建评估集，跑通当前检索链路，记录基线指标；
- 调整分块策略，观察Recall@K变化；
- 实验查询改写，保留正向收益策略；
- 对比Embedding模型，确认当前模型是否够用；
- 最后引入重排序或混合检索，优化排序精度。
这个顺序的核心逻辑是：先解决低成本的、结构性的问题，再考虑引入高成本模型。每一步只调整一个变量，以免指标变化时不知道是哪个改动带来的。
同时，评估集需要持续更新。线上用户的反馈和bad case应定期加入评估集，否则调优可能只对历史问题有效，对新的用户表达无能为力。把检索日志、生成质量评分、用户点击行为关联起来，可以形成反馈闭环。
几句总结
RAG的检索质量是系统工程。换Embedding模型只是其中一环，而且未必是最优解。更可靠的做法是先建立评估集，用数据定位问题，再按分块、查询改写、Embedding、重排序的顺序逐步调优。过程不炫酷，但对生产系统而言，它比“玄学调参”更经得起验证。