智能搜索系统的升级复盘——从 Elasticsearch 到混合检索的检索质量提升一、搜索系统的核心指标不是结果有多快而是用户有没有找到公司在 2021 年上线了基于 Elasticsearch 的全文搜索初期表现不错。但随着知识库文档量从 10 万增长到 300 万搜索质量开始下滑。运营反馈用户搜索活动报名截止日期时前十名里只有两条相关用户不得不点好几次下一页。技术排查发现两个问题一是关键词匹配的局限性——用户输入怎么修改密码和文档标题密码重置操作指引之间缺乏语义关联二是相关性排序的退化——热门文档在 TF-IDF 模型下持续获得高排名新发布的精准文档被淹没。单纯调优 ES 的 analyzer、同义词词典和 function_score 权重召回率从 62% 提升到了 71%但仍达不到业务对前十名中至少 8 条相关的期望。结合当时向量检索技术的成熟度我们决定引入混合检索的方案。二、混合检索架构关键词 语义各取所长混合检索的架构并不复杂核心有三个阶段。第一阶段是查询理解对用户的输入做分词、实体识别和意图分类对于明确的关键词查询如文档编号、错误码倾向关键词通路对于长文本描述性查询如怎么解决登录超时倾向语义通路。第二阶段是并行检索ES 做 BM25 全文检索向量数据库做 dense embedding 的近似最近邻搜索两者各自返回 Top 50。第三阶段是融合排序先用 RRFReciprocal Rank Fusion算法对两路结果做加权融合再通过 LLM 做最终的精准重排。向量编码模型我们选的是 BGE-large-zh-v1.5在 MTEB 中文测评集上表现稳定。文档的 Chunk 策略也做了调整原来按 512 字切分发现很多技术文档的核心原理介绍前后横跨了好几个 chunk语义信息被截断。后来改成了按章节标题切分加 128 字 overlap 的策略但每个 chunk 的长度上限仍保持在 1024 token 以内以保证编码质量超出部分按段落做软切割。三、融合排序的 Java 实现RRF 算法的多路召回融合下面展示 RRF 融合算法的核心实现。RRF 是一种简单的多路排序融合方法不需要知道每路的原始分数只根据候选文档在各路中的排名位置来重新打总分。public class RrfFusion { private static final int K 60; // RRF 常量控制排名衰减速率 /** * 融合多路召回结果 * param recallChannels 各路召回结果key 为通路名称value 为按排序排列的文档 ID 列表 * return 融合后的文档 ID 排序列表 */ public ListString fuse(MapString, ListString recallChannels) { MapString, Double fusionScores new HashMap(); for (Map.EntryString, ListString channel : recallChannels.entrySet()) { ListString docIds channel.getValue(); for (int rank 0; rank docIds.size(); rank) { String docId docIds.get(rank); double score 1.0 / (K rank 1); fusionScores.merge(docId, score, Double::sum); } } // 按融合分数降序排列 return fusionScores.entrySet().stream() .sorted(Map.Entry.String, DoublecomparingByValue().reversed()) .map(Map.Entry::getKey) .collect(Collectors.toList()); } }在实际落地中统一的交通管制逻辑在融合阶段也做了工程优化。当两路召回结果重叠度很低时Jaccard 相似度 0.1说明用户描述可能与任一单路都不太匹配这时触发 LLM 改写查询将原始 query 拆解为 2-3 个子查询后重新检索。当某一路召回结果为空时只依赖另一路结果不做融合。重排序阶段通过 LLM 做精细排序但不是对每条候选都送进模型。我们是取融合结果的 Top 20 候选以三元组形式query document title key sentences送入 LLM要求 LLM 给出 0-10 分相关性评价然后按分数重新排序。这里的关键是用摘要代替全文来降低 token 消耗——对每条文档预先用规则或小模型提取 3 条关键句供重排序使用。四、效果衡量与持续调优混合检索上线后核心指标提升显著Top 10 的相关文档命中率从 71% 提升到 93%平均首次点击位置从第 7 位提前到第 3 位搜索的无结果率从 8% 降到 1.2%。但技术的改进不能只看上线当天——我们建立了离线评估集包含 500 条真实用户搜索及其标注的相关文档每次索引策略或编码模型变更前都在评估集上跑一遍确保新策略在所有大类上的表现至少不低于基线。索引更新策略也做了优化。原来每天凌晨全量重建向量索引耗时要 4 小时。后来改为增量更新加周期重建新增文档实时编码进向量库修改的文档标记为过期同时生成新向量后替换删除的文档直接移除。每周末做一次全量索引验证检查向量一致性和覆盖率。五、总结从纯 ES 到混合检索的升级本质上是把搜索从关键词匹配扩展为关键词 语义理解。RFF 融合算法简单有效向量编码质量和 Chunk 策略决定了语义检索的上限LLM 重排序是提升精准度的最后一环。搜索系统的持续改进不能靠直觉必须建立离线评估基准用数据说话。
智能搜索系统的升级复盘——从 Elasticsearch 到混合检索的检索质量提升一、搜索系统的核心指标不是结果有多快而是用户有没有找到公司在 2021 年上线了基于 Elasticsearch 的全文搜索初期表现不错。但随着知识库文档量从 10 万增长到 300 万搜索质量开始下滑。运营反馈用户搜索活动报名截止日期时前十名里只有两条相关用户不得不点好几次下一页。技术排查发现两个问题一是关键词匹配的局限性——用户输入怎么修改密码和文档标题密码重置操作指引之间缺乏语义关联二是相关性排序的退化——热门文档在 TF-IDF 模型下持续获得高排名新发布的精准文档被淹没。单纯调优 ES 的 analyzer、同义词词典和 function_score 权重召回率从 62% 提升到了 71%但仍达不到业务对前十名中至少 8 条相关的期望。结合当时向量检索技术的成熟度我们决定引入混合检索的方案。二、混合检索架构关键词 语义各取所长混合检索的架构并不复杂核心有三个阶段。第一阶段是查询理解对用户的输入做分词、实体识别和意图分类对于明确的关键词查询如文档编号、错误码倾向关键词通路对于长文本描述性查询如怎么解决登录超时倾向语义通路。第二阶段是并行检索ES 做 BM25 全文检索向量数据库做 dense embedding 的近似最近邻搜索两者各自返回 Top 50。第三阶段是融合排序先用 RRFReciprocal Rank Fusion算法对两路结果做加权融合再通过 LLM 做最终的精准重排。向量编码模型我们选的是 BGE-large-zh-v1.5在 MTEB 中文测评集上表现稳定。文档的 Chunk 策略也做了调整原来按 512 字切分发现很多技术文档的核心原理介绍前后横跨了好几个 chunk语义信息被截断。后来改成了按章节标题切分加 128 字 overlap 的策略但每个 chunk 的长度上限仍保持在 1024 token 以内以保证编码质量超出部分按段落做软切割。三、融合排序的 Java 实现RRF 算法的多路召回融合下面展示 RRF 融合算法的核心实现。RRF 是一种简单的多路排序融合方法不需要知道每路的原始分数只根据候选文档在各路中的排名位置来重新打总分。public class RrfFusion { private static final int K 60; // RRF 常量控制排名衰减速率 /** * 融合多路召回结果 * param recallChannels 各路召回结果key 为通路名称value 为按排序排列的文档 ID 列表 * return 融合后的文档 ID 排序列表 */ public ListString fuse(MapString, ListString recallChannels) { MapString, Double fusionScores new HashMap(); for (Map.EntryString, ListString channel : recallChannels.entrySet()) { ListString docIds channel.getValue(); for (int rank 0; rank docIds.size(); rank) { String docId docIds.get(rank); double score 1.0 / (K rank 1); fusionScores.merge(docId, score, Double::sum); } } // 按融合分数降序排列 return fusionScores.entrySet().stream() .sorted(Map.Entry.String, DoublecomparingByValue().reversed()) .map(Map.Entry::getKey) .collect(Collectors.toList()); } }在实际落地中统一的交通管制逻辑在融合阶段也做了工程优化。当两路召回结果重叠度很低时Jaccard 相似度 0.1说明用户描述可能与任一单路都不太匹配这时触发 LLM 改写查询将原始 query 拆解为 2-3 个子查询后重新检索。当某一路召回结果为空时只依赖另一路结果不做融合。重排序阶段通过 LLM 做精细排序但不是对每条候选都送进模型。我们是取融合结果的 Top 20 候选以三元组形式query document title key sentences送入 LLM要求 LLM 给出 0-10 分相关性评价然后按分数重新排序。这里的关键是用摘要代替全文来降低 token 消耗——对每条文档预先用规则或小模型提取 3 条关键句供重排序使用。四、效果衡量与持续调优混合检索上线后核心指标提升显著Top 10 的相关文档命中率从 71% 提升到 93%平均首次点击位置从第 7 位提前到第 3 位搜索的无结果率从 8% 降到 1.2%。但技术的改进不能只看上线当天——我们建立了离线评估集包含 500 条真实用户搜索及其标注的相关文档每次索引策略或编码模型变更前都在评估集上跑一遍确保新策略在所有大类上的表现至少不低于基线。索引更新策略也做了优化。原来每天凌晨全量重建向量索引耗时要 4 小时。后来改为增量更新加周期重建新增文档实时编码进向量库修改的文档标记为过期同时生成新向量后替换删除的文档直接移除。每周末做一次全量索引验证检查向量一致性和覆盖率。五、总结从纯 ES 到混合检索的升级本质上是把搜索从关键词匹配扩展为关键词 语义理解。RFF 融合算法简单有效向量编码质量和 Chunk 策略决定了语义检索的上限LLM 重排序是提升精准度的最后一环。搜索系统的持续改进不能靠直觉必须建立离线评估基准用数据说话。
