RAG系统效果不好，很多团队第一反应是换更大的生成模型。但检索质量差的根因往往不在生成层，而在召回链路。如果Top-K结果里根本没有正确答案，生成模型再强也无力回天。检索调优应当被当成独立的工程问题来对待，而不是盲目调Prompt。

以下是一条不绑定任何特定产品的调优路径。核心原则只有一条：用评估数据说话，每次只改变一个变量。

先建立可重复的评估集

没有评估集，调优就是猜谜。调优前需要先构造一批有代表性的问题，并标注每个问题对应的标准文档或文档片段。数量不需要追求大，但覆盖面要足够：短问题、长问题、含专有名词的问题、含代词的问题，以及跨越多个文档段落的问题，都要包含。

评估时不要只看最终生成答案是否正确，要单独观察检索器的召回情况。常用指标是Recall@K、MRR和NDCG。它们能帮助区分两种截然不同的失败：一种是检索结果里根本没有正确答案，需要回到召回链路优化；另一种是正确答案已经在Top-K里，但生成层没有利用好，需要调整上下文组织或生成策略。这一步能把问题定位精准，避免在错误层面上做无用功。

分块策略：先于Embedding被低估

很多调优工作直接从换Embedding开始，但实际更常出现的瓶颈是分块不当。分块大小直接影响向量的语义质量：块太小，语义信息碎片化，一个完整知识被拆断；块太大，向量表示被无关内容稀释，不同文档的相似度区分度下降。理想的块边界应当落在语义完整的位置，比如段落结束、章节标题之后。对于Markdown、HTML这类有结构的文档，先按结构拆分，再对过长块做二次切分，往往比简单按字符数硬切更有效。

分块还需要考虑是否设置重叠。一点重叠可以缓解边界上下文丢失，但重叠过多会增加存储和检索成本。这里没有普适的最优值，同一个语料在不同分块配置下，检索表现可能差异很大。正确的做法是把分块配置列入对照实验：生成多组分块方案，在评估集上分别测试，用Recall指标决定保留哪一组。

Embedding模型：榜单只是起点

Embedding模型的选择没有“绝对最好”，只有“在你这批语料上最好”。不同模型对文本长度上限、领域术语、语言类型和相似度计算方式的处理都不一样。公开榜单能给出参考，但无法代表你的业务语料分布。

评估时，至少关注三个变量：一是模型能接受的文本长度是否覆盖你的分块尺寸；二是向量维度与后续向量库检索的适配性；三是相似度计算方式是否和模型训练时一致。实践中的一个常见问题是，语料包含大量业务术语或内部缩写，通用Embedding模型对这些词的表征不够敏感。如果换用更大模型或领域模型仍然没有明显改善，则要考虑在业务数据上做Embedding微调，但这一步需要提前衡量数据准备和训练成本是否值得。

无论选择哪个模型，都要在同一个评估集下，与当前baseline直接对比。不要因为某个模型在某个公开任务上分数更高，就直接迁移到生产环境。

检索策略：不能只靠向量相似度

向量检索擅长处理语义相关，但专有名词、型号、代码片段、缩写这类场景，关键词精确匹配往往更稳定。单一向量检索容易在这些场景下漏召回。一个常见的做法是多路召回：一路走向量语义检索，一路走BM25等词频检索，再把两路结果做归一化合并。多路召回能在保持语义泛化的同时，兜住精确匹配的要求。

Top-K参数也值得检查。K太小，答案容易落在窗口外；K太大，噪声会淹没真正的答案，并把重排序和生成阶段的成本一起推高。合理的K值取决于分块粒度和问题复杂度，还是需要通过评估集扫描。不要默认沿用某个框架的默认值。

重排序：用两阶段逼近精度

第一轮检索要同时兼顾速度与召回，通常使用双塔类模型，把文本压缩成稠密向量。这个表示适合做海量候选召回，但精度有限。重排序的价值在于，用更精细的模型对候选结果进行二次打分。

实现上，第一轮先召回一个相对宽的范围，比如Top几十到上百，第二轮再用交叉编码器模型逐段计算query与文档的匹配度，返回Top N。交叉编码器能同时建模问句与文档间的细粒度交互，精度通常更高，但计算成本也显著更高。因此重排序的候选集合大小必须受响应时间预算约束。候选越大，延迟越高。应在满足延迟要求的前提下，尽可能给重排序提供足量候选。

需要提醒的是，重排序不是必须的。如果语料规模不大，或者检索质量问题主要来自分块，过早引入重排序会让链路复杂化。先验证前几个环节，再决定是否加。

查询改写：解决“问不清楚”的问题

用户输入往往带口语、缺省和指代。比如“它怎么部署”中的“它”指代不明，直接拿去检索很难命中。查询改写的目标是，把原始问题改成更适合检索的形式。常见实现包括：扩展同义词或别名，补充上下文名词，将问题模板化为更完整的语句。

另一种思路是HyDE，即让模型先根据问题生成一个假设性回答，再用这个生成文本来检索。这个方法的假设是，假设性回答比原问题更能命中相关文档。但它的效果依赖生成质量，生成内容一旦偏离，反而会把检索引向错误方向。是否启用，应当由评估集上的召回率变化决定，而不是凭直觉。

建议的调优顺序

综合看下来，一个推荐的执行顺序是：

第一步，构建评估集，测出当前baseline的Recall@K。第二步，对比分块策略，选出语义完整性最好的配置。第三步，在同一分块下横向对比Embedding模型。第四步，引入多路召回，测试是否能补足精确匹配。第五步，评估重排序的收益和延迟代价。第六步，再考虑查询改写和HyDE是否值得。

每一步只改变一个变量，保留所有指标记录。这样团队能够清楚看到每个环节的边际贡献，也能在将来换语料时快速复现调优过程。检索质量调优本质上是一个持续迭代的实验工程，不存在一劳永逸的默认配置。