Elasticsearch混合搜索深度解析(上):问题发现与源码探索

发布于:2025-07-12 ⋅ 阅读:(22) ⋅ 点赞:(0)

引言

最近在生产环境中遇到了一个令人困惑的问题:一个包含主查询(query)和KNN查询(knn)的混合搜索请求,当移除KNN部分后,查询结果发生了显著变化。这违背了我对Elasticsearch混合搜索机制的认知,于是决定深入源码一探究竟。

问题背景

查询场景

我们的业务场景是学术文献搜索,需要同时支持关键词匹配和语义相似性搜索。查询结构如下:

{
    "query": {
        "bool": {
            "must": [
                {
                    "query_string": {
                        "fields": [
                            "title_tks^10",
                            "title_sm_tks^5", 
                            "important_kwd^30",
                            "important_tks^20",
                            "content_ltks^2",
                            "content_sm_ltks"
                        ],
                        "type": "best_fields",
                        "query": "research^0.0345 domain^0.0345 filler^0.0345...",
                        "boost": 1
                    }
                }
            ],
            "boost": 0.05
        }
    },
    "from": 0,
    "size": 50,
    "_source": ["doc_id"],
    "knn": {
        "field": "q_vec",
        "k": 50,
        "similarity": 0.01,
        "num_candidates": 100,
        "query_vector": [...],
        "filter": {
            "bool": {
                "must": [
                    {
                        "query_string": {
                            "fields": [...],
                            "query": "research^0.0345 domain^0.0345...",
                            "boost": 1
                        }
                    }
                ],
                "boost": 0.05
            }
        },
        "boost": 1
    }
}

关键参数说明

  • 主查询boost: 0.05(权重较低)
  • KNN查询boost: 1(权重较高)
  • KNN参数: k=50, num_candidates=100
  • 分页: from=0, size=50

问题现象

  1. 有KNN查询: 返回50条结果,包含特定的学术文献
  2. 无KNN查询: 返回50条结果,但内容完全不同
  3. 结果差异: 两种查询的结果重叠度极低,几乎完全不同

初步假设与困惑

我的初始理解

基于对Elasticsearch混合搜索的认知,我认为:

  1. KNN和主查询独立执行
  2. 无rank配置时,KNN结果被丢弃
  3. 最终结果只来自主查询
  4. KNN的filter不会影响主查询

实际观察的矛盾

但实际观察到的现象与我的理解完全矛盾:

  1. KNN的filter确实影响了最终结果
  2. 有无KNN查询结果差异巨大
  3. 这无法用"KNN结果被丢弃"来解释

开始源码探索

第一步:定位关键类

首先在Elasticsearch 8.11源码中搜索混合搜索相关的类:

# 搜索混合搜索相关类
find . -name "*.java" -exec grep -l "hybrid\|knn.*query\|query.*knn" {} \;

第二步:找到DfsQueryPhase

通过搜索发现,混合搜索的关键处理逻辑在DfsQueryPhase.java中:

// server/src/main/java/org/elasticsearch/action/search/DfsQueryPhase.java
public class DfsQueryPhase {
    
    private ShardSearchRequest rewriteShardSearchRequest(ShardSearchRequest request) {
        // 这里是关键逻辑
    }
}

第三步:分析DFS阶段

DFS(Distributed Fetch Search)阶段是混合搜索的第一个关键阶段:

// DFS阶段处理KNN查询
for (DfsKnnResults dfsKnnResults : knnResults) {
    // 收集KNN结果
    knnResults.add(dfsKnnResults);
}

第四步:发现SubSearch机制

DfsQueryPhase.rewriteShardSearchRequest()方法中,发现了关键逻辑:

// 关键发现:KNN结果被转换为SubSearch
for (DfsKnnResults dfsKnnResults : knnResults) {
    KnnScoreDocQueryBuilder query = new KnnScoreDocQueryBuilder(
        dfsKnnResults.getField(), 
        dfsKnnResults.getKnnResults()
    );
    subSearchSourceBuilders.add(new SubSearchSourceBuilder(query));
}

// 清空knnSearch,保留sub_searches
source = source.shallowCopy()
    .subSearches(subSearchSourceBuilders)
    .knnSearch(List.of());

关键发现

发现1:KNN结果不会被丢弃

重要发现: 即使没有rank配置,KNN结果也不会被丢弃,而是通过SubSearch机制保留在最终查询中。

发现2:SubSearch的作用机制

通过进一步分析SearchService.java,发现SubSearch的处理逻辑:

// SearchService.java 第1458-1464行
if (source.rankBuilder() != null) {
    List<Query> queries = new ArrayList<>();
    for (SubSearchSourceBuilder subSearchSourceBuilder : source.subSearches()) {
        queries.add(subSearchSourceBuilder.toSearchQuery(context));
    }
    // rank处理逻辑
} else {
    // 无rank时的处理逻辑
}

发现3:分数合并机制

从文档中确认了分数合并的公式:

// docs/reference/search/search-your-data/knn-search.asciidoc 第325行
score = 0.9 * match_score + 0.1 * knn_score

初步结论

通过源码分析,我开始理解问题的根源:

  1. KNN结果确实被保留:通过SubSearch机制
  2. 分数合并机制:query分数×0.05 + knn分数×1
  3. Filter影响:KNN的filter直接影响向量搜索范围

下一步探索

虽然有了初步发现,但还有很多细节需要深入:

  1. SubSearch的具体执行机制
  2. 分数合并的详细实现
  3. Filter的传递路径
  4. 最终排序和分页的处理

这些问题将在下篇中继续深入分析。

经验总结

1. 不要轻信文档的表面描述

官方文档可能简化了复杂的内部机制,需要结合源码才能真正理解。

2. 源码是最好的老师

当遇到无法解释的现象时,直接查看源码往往能找到答案。

3. 保持怀疑精神

即使是对"常识"的认知,也要敢于质疑和验证。

下篇预告

在下篇中,我将继续深入分析:

  • SubSearch的详细执行机制
  • 分数计算和合并的具体实现
  • Filter的影响路径
  • 完整的执行流程图
  • 性能优化建议

敬请期待!


网站公告

今日签到

点亮在社区的每一天
去签到