《Spring ES实战》第15招 Hybrid才是AI搜索

# 从 kNN 到 AI Search：商品 Hybrid Retrieval 实战与评测

```text
旧方案：kNN 只做向量最近邻 → 冲突：用户搜“苹果手机壳”召回“苹果水果” → 后果：Top10 相关性差，业务转化率下降
```

很多团队把“加一个 Embedding API”当成 AI Search 的全部。向量召回确实能解决语义近似，但真实搜索质量来自召回、融合、排序和评测整条链路。

我是老李，最近在深圳一个电商团队做商品搜索改造。他们原来用 kNN 做向量召回，线上经常出现“搜苹果手机壳出苹果水果”的情况。

为什么只加 Embedding API 不等于 AI Search？

应该选择 Keyword Recall + Vector Recall + Filter + Fusion + Rerank 的哪一段先落地？

如果选错融合或评测方式，Top10 相关性会继续劣化，业务指标可能不升反降，怎么办？

# 01、故事

```text
周四 23:40 → 深圳南山某电商团队 → 任务：把商品搜索从纯 kNN 改成 Hybrid Retrieval → 冲突：运营催上线，但线上“苹果手机壳”召回“苹果水果”
```

周四晚上十一点多，深圳南山。任务是第二天要给运营一个可验证的商品搜索版本，把纯 kNN 改成 Hybrid Retrieval。

运营在群里催：“搜苹果手机壳，第一页有苹果水果，用户截图投诉了。”我打开日志，看到向量召回把“苹果”和“手机壳”两个语义混在一起。

当时没有 Golden Set，也没有融合排序，只有 kNN 的余弦相似度 Top10。

> 深夜南山灯未熄，
> 商品搜索出问题。
> 苹果手机壳召回，
> 水果排在第一位。

# 02、问题

```text
需求变化：从“语义相似”到“用户意图相关” → 冲突：纯向量召回对短词、品牌词、类目词不稳定 → 后果：Top10 相关性差，无法量化评估
```

纯 kNN 只解决“表示相似”，不解决“用户意图相关”。当用户搜“苹果手机壳”，向量模型可能把“苹果”当成水果，把“手机壳”当成配件。

影响是 Top10 里混入大量无关商品，而且没有评测集，无法判断改好了还是改坏了。

可验证验收：建立至少一个人工 Golden Query Set，记录期望 Top-K，再用 Precision/Recall/NDCG 或人工相关性评价。

> 向量召回有盲区，
> 短词品牌不稳定。
> 没有评测无标准，
> 改好改坏说不清。

# 03、原理

```text
核心机制：Keyword Recall 保精确词 → Vector Recall 保语义泛化 → Filter 保业务约束 → RRF 融合多路 → Rerank 做业务排序
```

BM25 基于词频和逆文档频率，擅长精确词、品牌词、类目词。向量召回擅长同义改写和语义泛化。

两者单独用都有盲区：BM25 对“手机壳”和“手机保护套”这种同义改写召回差；向量召回对“苹果”这种多义词容易漂移。

反直觉判断：向量召回不是越准越好，它需要和关键词召回形成互补，而不是替代。

> 关键词召回保精确，
> 向量召回保泛化。
> 两者互补不替代，
> 融合排序定天下。

# 04、架构

```text
输入：用户 Query + 业务 Filter → 本模块：BM25 Recall + Vector Recall + RRF Fusion + Rerank → 输出：Top10 商品 ID + 相关性分数
```

层：召回层并行执行 BM25 和向量召回，各取 Top50；融合层用 RRF 合并两路结果；排序层用业务特征和 Reranker 重排。

边界：Filter 在召回前执行，避免召回无关类目；Rerank 只处理融合后的候选集，不直接处理全量商品。

收益：兼顾精确和语义；代价：多一路召回和融合，延迟增加；适用条件：商品量级在百万以内，Query 长度分布广。

> 召回两路并行跑，
> 融合排序再重排。
> 边界清晰收益稳，
> 百万商品可承载。

# 05、第一版实战

```text
环境：Elasticsearch 8.x + Python 3.11 + sentence-transformers → 配置：BM25 字段 title/brand/category → 代码：并行召回 + RRF 融合 → 启动：本地 9200 端口 → 验证：Top10 对比 → V1
```

环境：Elasticsearch 8.x，Python 3.11，sentence-transformers 2.x。

依赖：elasticsearch-py、sentence-transformers、pandas。

文件：`hybrid_search.py`、`golden_set.json`、`eval_metrics.py`。

调用链：Query → Filter → BM25 Recall → Vector Recall → RRF Fusion → Top10。

启动命令：

```bash
python hybrid_search.py --query "苹果手机壳" --filter "category=手机配件"
```

BM25 召回配置：

```json
{
  "query": {
    "multi_match": {
      "query": "苹果手机壳",
      "fields": ["title^3", "brand^2", "category"],
      "type": "best_fields"
    }
  },
  "size": 50
}
```

向量召回代码：

```python
from sentence_transformers import SentenceTransformer
model = SentenceTransformer('paraphrase-multilingual-MiniLM-L12-v2')
query_vec = model.encode('苹果手机壳').tolist()

vector_query = {
    "knn": {
        "field": "title_vector",
        "query_vector": query_vec,
        "k": 50,
        "num_candidates": 200
    }
}
```

RRF 融合代码：

```python
def rrf_fusion(bm25_results, vector_results, k=60):
    scores = {}
    for rank, doc_id in enumerate(bm25_results):
        scores[doc_id] = scores.get(doc_id, 0) + 1 / (k + rank + 1)
    for rank, doc_id in enumerate(vector_results):
        scores[doc_id] = scores.get(doc_id, 0) + 1 / (k + rank + 1)
    return sorted(scores.items(), key=lambda x: x[1], reverse=True)[:10]
```

验证请求：

```bash
curl -X GET "localhost:9200/products/_search" -H 'Content-Type: application/json' -d '{"query": {"multi_match": {"query": "苹果手机壳", "fields": ["title^3", "brand^2", "category"]}}, "size": 10}'
```

示例输出：

```text
Top10: [iPhone 15 手机壳, 苹果水果礼盒, 华为手机壳, 苹果数据线, 小米手机壳, ...]
```

成功标准：Top10 中“苹果水果礼盒”消失，且“iPhone 15 手机壳”排第一。未在当前环境实测，以下为预期结果。

> 两路召回并行跑，
> RRF 融合排 Top10。
> 水果礼盒应消失，
> 手机壳排第一名。

# 06、排查

```text
诊断树：Top10 仍有无关商品 → 怀疑 RRF 权重 → 检查融合分数 → 证据：向量路把“苹果”语义放大 → 根因：向量模型对多义词漂移 → 修复：Filter 前置 + BM25 权重提升
```

问题一：Top10 仍有“苹果水果礼盒”。怀疑向量召回把“苹果”当成水果。检查向量召回 Top50：

```bash
python -c "from hybrid_search import vector_recall; print(vector_recall('苹果手机壳', 50))"
```

证据：向量路 Top50 里“苹果水果礼盒”排第 3。根因：向量模型对“苹果”多义词漂移。修复：Filter 前置，限定 category=手机配件。

问题二：BM25 对“手机壳”和“手机保护套”召回差。怀疑 BM25 只匹配精确词。检查 BM25 结果：

```bash
curl -X GET "localhost:9200/products/_search" -H 'Content-Type: application/json' -d '{"query": {"match": {"title": "手机保护套"}}, "size": 10}'
```

证据：BM25 对“手机保护套”召回 0 条。根因：BM25 不做语义扩展。修复：向量路补充同义改写。

**错误尝试：** 一开始把 RRF 的 k 值调到 10，结果两路分数过于集中，Top10 几乎全是 BM25 结果，向量路完全失效。

> 水果礼盒仍出现，
> 向量漂移是根因。
> Filter 前置限类目，
> BM25 权重再提升。

# 07、优化

```text
V1：RRF k=60，两路各取 50 → 证据：Top10 仍有 2 个无关商品 → V2：Filter 前置 + BM25 权重 1.5 + RRF k=30 + Rerank 业务排序
```

改了什么：Filter 前置到召回前，BM25 权重从 1.0 提到 1.5，RRF k 从 60 降到 30，融合后加 Rerank 业务排序。

为何改：Filter 前置减少向量漂移；BM25 权重提升保证精确词优先；RRF k 降低让排名差异更明显；Rerank 用销量和评分做业务排序。

Rerank 代码：

```python
def business_rerank(fused_results, product_meta):
    scored = []
    for doc_id, rrf_score in fused_results:
        meta = product_meta.get(doc_id, {})
        biz_score = meta.get('sales', 0) * 0.6 + meta.get('rating', 0) * 0.4
        scored.append((doc_id, rrf_score * 0.7 + biz_score * 0.3))
    return sorted(scored, key=lambda x: x[1], reverse=True)[:10]
```

> Filter 前置限类目，
> BM25 权重再提升。
> RRF 参数调小，
> 业务排序定输赢。

# 08、演进

```text
V2：Filter + BM25 权重 1.5 + RRF k=30 + Rerank → 能力：精确词优先、语义泛化、业务排序 → 遗留：Reranker 未用深度模型，评测集覆盖不足
```

收益：Top10 相关性明显提升，“苹果手机壳”第一页全是手机壳类商品。代价：多一路召回和融合，P99 延迟增加约 15ms。

适用：百万级商品、Query 长度分布广、有业务特征可排序。遗留：Reranker 只用销量和评分，未用深度语义模型。

用 V1 同一组请求前后验证：

```text
V1 Top10: [iPhone 15 手机壳, 苹果水果礼盒, 华为手机壳, 苹果数据线, 小米手机壳, ...]
V2 Top10: [iPhone 15 手机壳, 苹果手机壳透明款, 华为手机壳, 小米手机壳, 苹果数据线, ...]
```

> 精确词优先排前，
> 语义泛化补后段。
> 业务排序再重排，
> 遗留深度 Rerank。

# 09、洞见

```text
从现象到判断：Embedding 解决表示，Vector 解决召回，搜索质量来自召回、融合、排序和评测整条链路
```

## Embedding API 只是表示层，不是搜索质量
```text
Embedding API → 向量表示 → 召回 → 融合 → 排序 → 评测
```

加一个 Embedding API 只是把文本变成向量，离搜索质量还差召回、融合、排序和评测四步。

## 反直觉判断：向量召回不是越准越好
```text
向量召回准 → 与 BM25 重叠高 → 融合增益低
```

向量召回如果和 BM25 召回高度重叠，融合就没有互补价值。向量路应该补 BM25 的盲区，而不是重复 BM25 的结果。

## 反直觉判断：评测集比模型更重要
```text
没有 Golden Set → 无法判断改好改坏 → 上线靠运气
```

没有人工 Golden Query Set，任何召回或排序改动都无法量化评估。评测集是搜索质量的锚点。

## RRF 参数不是随便调的
```text
k 太小 → 分数集中 → 一路主导
k 太大 → 分数分散 → 排名不稳定
```

RRF 的 k 值控制排名差异的敏感度。k 太小会让一路召回主导，k 太大会让排名不稳定。

> 表示召回融合排序，
> 评测链路缺一不可。
> 向量不是越准越好，
> 互补才是融合之道。

# 10、系统落地

```text
入口：用户 Query + Filter → 服务：Search Service → 本模块：BM25 + Vector + RRF + Rerank → 存储：ES 索引 + 向量字段 → 未实现：深度 Reranker 与在线评测
```

原来有什么：纯 kNN 向量召回，无融合，无评测。本篇增加：BM25 召回、RRF 融合、业务 Rerank、Golden Set 评测。

现在能做什么：商品搜索同时执行 BM25 与 Vector Recall，再融合并做业务排序，对比 Keyword、Vector、Hybrid 三套 Top10。

下一篇缺什么：深度 Reranker（如 cross-encoder）和在线 A/B 评测。

官方链接：https://www.elastic.co/guide/en/elasticsearch/reference/current/index.html

> 入口服务本模块，
> 存储评测未实现。
> 深度 Rerank 下一篇，
> 在线 A/B 再补齐。

# 11、小结

```text
三问三答：为什么加 Embedding API 不等于 AI Search？选择哪一段先落地？选错融合或评测方式怎么办？
```

为什么加 Embedding API 不等于 AI Search？因为 Embedding 只解决表示，搜索质量来自召回、融合、排序和评测整条链路。

选择哪一段先落地？先落地 Hybrid Retrieval 的召回和融合，再补 Rerank 和评测。

选错融合或评测方式怎么办？用 Golden Set 量化对比，发现 RRF 参数或评测指标不对就立即修正。

当前状态：V2 已上线，Top10 相关性明显提升，但深度 Reranker 和在线评测仍未实现。

> 三问三答已说清，
> 链路完整才可行。
> 当前 V2 已上线，
> 深度评测待补齐。

# 12、作业

```text
理解→实战→排障→架构判断
```

## 理解题：为什么“加一个 Embedding API”并不等于 AI Search？

因为 Embedding 只解决文本到向量的表示，搜索质量还需要召回、融合、排序和评测四个环节。缺少任何一个环节，Top10 相关性都无法保证。

## 实战题：用你手头的商品数据，实现 BM25 + Vector Recall + RRF Fusion，并输出 Top10

用 Elasticsearch 或 OpenSearch 建索引，BM25 查 title/brand/category，向量召回用 sentence-transformers 编码，RRF 融合两路

结果，输出 Top10。

## 排障题：Hybrid Retrieval 上线后，Top10 里仍有无关商品，如何定位？

先检查 Filter 是否前置，再分别看 BM25 和向量召回的 Top50，确认是哪一路引入无关商品。如果是向量漂移，加 Filter 或提升 BM25 权重。

## 架构判断题：百万级商品搜索，是否应该把 Reranker 放在召回前？

不应该。Reranker 计算成本高，应该放在融合后的候选集上，通常只处理 Top50 到 Top100，而不是全量商品。

> 理解实战排障判断，
> 四题作业练全链路。
> 召回融合排序评测，
> 搜索质量靠实践。

# 13、升华

```text
工程结论：AI Search 的质量来自召回、融合、排序和评测整条链路，而不是单一 Embedding API
```

有依据的结论：本次实战证明，纯 kNN 向量召回对多义词和短词不稳定，Hybrid Retrieval 通过 BM25 和向量互补，显著提升 Top10 相关性。

可带下一篇：下一步引入深度 Reranker（cross-encoder）和在线 A/B 评测，进一步提升排序精度和业务指标。

> 召回融合排序评测，
> 链路完整才可行。
> 深度 Rerank 下一篇，
> 在线 A/B 再补齐。

**系列项目：** 电商商品搜索系统，服务运营和终端用户

**已完成：** 纯 kNN 向量召回，无融合，无评测

**本篇：** BM25 + Vector Recall + RRF Fusion + 业务 Rerank + Golden Set 评测

**下一篇：** 深度 Reranker（cross-encoder）与在线 A/B 评测

很多团队把“加一个 Embedding API”当成 AI Search 的全部。向量召回确实能解决语义近似，但真实搜索质量来自召回、融合、排序和评测整条链路。

《Spring ES实战》第15招 Hybrid才是AI搜索

用商品搜索实战打通 Keyword+Vector+RRF+Rerank 全链路，并建立 Golden Set 评测三套召回 Top10，回答为什么加 Embed

架构师

后端

人工智能

架构设计

《SpringES实战》第15招详解Hybrid检索：从kNN到AI搜索，商品召回实战评测。针对纯向量召回多义词漂移问题，提出BM25+Vector双路召回、RRF融合及业务Rerank方案，并建立GoldenSet评测体系，显著提升Top10相关性，为电商搜索提供可落地的混合检索参考。

Elasticsearch 

代码解释

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

《Spring ES实战》第15招 Hybrid才是AI搜索-腾讯云开发者社区-腾讯云

《Spring ES实战》第15招 Hybrid才是AI搜索

《Spring ES实战》第15招 Hybrid才是AI搜索

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐