RAG系统效果不好很多团队第一反应是换更大的生成模型。但检索质量差的根因往往不在生成层而在召回链路。如果Top-K结果里根本没有正确答案生成模型再强也无力回天。检索调优应当被当成独立的工程问题来对待而不是盲目调Prompt。以下是一条不绑定任何特定产品的调优路径。核心原则只有一条用评估数据说话每次只改变一个变量。先建立可重复的评估集没有评估集调优就是猜谜。调优前需要先构造一批有代表性的问题并标注每个问题对应的标准文档或文档片段。数量不需要追求大但覆盖面要足够短问题、长问题、含专有名词的问题、含代词的问题以及跨越多个文档段落的问题都要包含。评估时不要只看最终生成答案是否正确要单独观察检索器的召回情况。常用指标是RecallK、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的RecallK。第二步对比分块策略选出语义完整性最好的配置。第三步在同一分块下横向对比Embedding模型。第四步引入多路召回测试是否能补足精确匹配。第五步评估重排序的收益和延迟代价。第六步再考虑查询改写和HyDE是否值得。每一步只改变一个变量保留所有指标记录。这样团队能够清楚看到每个环节的边际贡献也能在将来换语料时快速复现调优过程。检索质量调优本质上是一个持续迭代的实验工程不存在一劳永逸的默认配置。 RAG检索质量差？从分块策略、Embedding到重排序的调优路径
RAG系统效果不好很多团队第一反应是换更大的生成模型。但检索质量差的根因往往不在生成层而在召回链路。如果Top-K结果里根本没有正确答案生成模型再强也无力回天。检索调优应当被当成独立的工程问题来对待而不是盲目调Prompt。以下是一条不绑定任何特定产品的调优路径。核心原则只有一条用评估数据说话每次只改变一个变量。先建立可重复的评估集没有评估集调优就是猜谜。调优前需要先构造一批有代表性的问题并标注每个问题对应的标准文档或文档片段。数量不需要追求大但覆盖面要足够短问题、长问题、含专有名词的问题、含代词的问题以及跨越多个文档段落的问题都要包含。评估时不要只看最终生成答案是否正确要单独观察检索器的召回情况。常用指标是RecallK、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的RecallK。第二步对比分块策略选出语义完整性最好的配置。第三步在同一分块下横向对比Embedding模型。第四步引入多路召回测试是否能补足精确匹配。第五步评估重排序的收益和延迟代价。第六步再考虑查询改写和HyDE是否值得。每一步只改变一个变量保留所有指标记录。这样团队能够清楚看到每个环节的边际贡献也能在将来换语料时快速复现调优过程。检索质量调优本质上是一个持续迭代的实验工程不存在一劳永逸的默认配置。