# 向量不是新终点：Elasticsearch 语义搜索与 BM25 的工程取舍

```text
旧方案：BM25 只匹配字面词，语义相近但用词不同就召回失败
冲突：用户搜“适合经常出差程序员的轻便背包”，商品描述写“通勤电脑包”
后果：语义相关商品大量漏召回，转化率下降，运营被迫手工维护同义词表
```

很多团队把向量搜索单独做成 AI Demo，演示完就搁置。真正的问题是：它如何进入现有搜索主链路，而不是另起炉灶。

我是老李，这几年在电商搜索团队里反复遇到同一个矛盾：业务方希望搜索“懂意思”，但线上故障又总来自“懂意思”带来的不可控。

为什么精确词匹配仍然不能被向量召回替代？

当语义召回与关键词召回冲突时，应该选择合并、分层还是替换？

如果选错，线上搜索会出现什么后果？

# 01、故事

```text
周二 14:30→搜索项目室→任务：上线语义搜索提升长尾查询召回→冲突：测试集召回提升，但品牌词开始串味
```

那天下午两点半，搜索项目室里投影仪亮着。任务是让“适合经常出差程序员的轻便背包”这类长尾查询，能召回描述为“通勤电脑包”的商品。

我打开 Kibana 跑了一版 kNN 查询，语义结果确实漂亮。可运营同学立刻发来截图：搜“ThinkPad X1 Carbon 背包”，第一条变成了某品牌通用内胆包。

会议室安静了几秒。语义搜索把品牌词“ThinkPad X1 Carbon”也当成语义向量去近似匹配了。

> 长尾查询像雾，
> 字面匹配漏掉真意。
> 向量补上缺口，
> 品牌词却开始漂移。

# 02、问题

```text
需求变化：从“字面匹配”到“理解意图”→冲突：语义召回与精确召回互相干扰→后果：品牌、型号、订单号等精确查询失准
```

旧方案里，BM25 对“ThinkPad X1 Carbon 背包”能精确命中标题和属性字段。引入向量后，如果只按 kNN 分数排序，精确词信号会被稀释。

影响很直接：用户搜品牌和型号时，看到的是“差不多”的商品，而不是“就是它”。这会造成客诉和退款率上升。

可验证的验收标准是：品牌词、型号词、订单号查询的 Top1 命中率不得低于旧版；长尾语义查询的召回率至少提升 20%。

> 字面是锚，
> 语义是帆。
> 锚若被拔起，
> 船会漂向无关。

# 03、原理

```text
核心机制：BM25 做精确召回，dense_vector 做语义召回，两者分数独立计算后再融合
```

Elasticsearch 的 dense_vector 字段存储 embedding，kNN 查询用相似度函数找近邻。

semantic_text 字段则把 embedding 生成和查询转换封装得更简单。

反直觉的一点是：向量相似度高不代表用户想找它。用户搜“轻便背包”，向量可能召回“轻便行李箱”，因为语义接近，但类目已经错了。

所以向量召回必须配合 Metadata Filter，例如 tenant、category、brand 等结构化条件，把语义搜索限制在业务边界内。

> 向量量的是近，
> 不是量的是对。
> 近是数学，
> 对是业务。

# 04、架构

```text
输入：用户查询字符串 + tenant/category 过滤条件→本模块：BM25 召回 + kNN 语义召回 + 分数融合→输出：带业务过滤的排序结果
```

架构上分三层：查询解析层负责识别精确词和语义意图；召回层同时走 BM25 和 kNN；融合层用 RRF 或加权分数合并。

收益是长尾查询召回明显提升，代价是索引体积增大、查询延迟增加、embedding 模型需要维护。

适用条件是：有大量自然语言描述文本，且用户查询用词与商品描述用词经常不一致。纯 SKU 或订单号查询场景不适合。

> 一条查询两条路，
> 字面走倒排，
> 语义走向量。
> 最后在融合处会合。

# 05、第一版实战

```text
环境：Elasticsearch 8.15+→配置：dense_vector 索引→代码：写入 embedding→启动：执行 kNN 查询→验证：语义召回→V1
```

先确认环境版本。Elasticsearch 8.15 已支持 semantic_text，但 dense_vector 更通用。以下用 dense_vector 演示，版本需按当前官方文档核验。

创建索引：

```json
PUT /products
{
  "mappings": {
    "properties": {
      "name": { "type": "text" },
      "description": { "type": "text" },
      "description_vector": {
        "type": "dense_vector",
        "dims": 768,
        "index": true,
        "similarity": "cosine"
      },
      "tenant": { "type": "keyword" },
      "category": { "type": "keyword" },
      "brand": { "type": "keyword" }
    }
  }
}
```

写入文档前，需要把 description 转成 768 维向量。这里用 Python 调用本地 embedding 模型生成向量，再写入 ES：

```python
from elasticsearch import Elasticsearch
from sentence_transformers import SentenceTransformer

model = SentenceTransformer('BAAI/bge-base-zh-v1.5')
es = Elasticsearch("http://localhost:9200")

docs = [
    {
        "name": "轻量通勤电脑包",
        "description": "适合经常出差的程序员使用，可容纳14英寸笔记本，轻便防泼水",
        "tenant": "tenant_a",
        "category": "背包",
        "brand": "CityPack"
    },
    {
        "name": "商务双肩包",
        "description": "大容量旅行背包，适合通勤和短途出差",
        "tenant": "tenant_a",
        "category": "背包",
        "brand": "UrbanGo"
    }
]

for doc in docs:
    doc["description_vector"] = model.encode(doc["description"]).tolist()
    es.index(index="products", document=doc)
```

执行 kNN 查询：

```json
POST /products/_search
{
  "knn": {
    "field": "description_vector",
    "query_vector_builder": {
      "text_embedding": {
        "model_id": ".multilingual-e5-small",
        "model_text": "适合经常出差程序员的轻便背包"
      }
    },
    "k": 10,
    "num_candidates": 50,
    "filter": {
      "bool": {
        "must": [
          { "term": { "tenant": "tenant_a" } },
          { "term": { "category": "背包" } }
        ]
      }
    }
  }
}
```

示例输出：

```text
命中：轻量通勤电脑包，分数 0.91
命中：商务双肩包，分数 0.78
```

V1 成功标准：语义相近但字面不同的商品能进入 Top10，且 tenant/category 过滤生效。未在当前环境实测，以下为预期结果。

> 向量写入索引，
> 查询转成数字。
> 过滤先划边界，
> 语义只在圈内。

# 06、排查

```text
诊断树：语义召回异常→先查过滤条件→再查向量生成→最后查相似度阈值
```

第一个问题：搜“ThinkPad X1 Carbon 背包”时，通用内胆包排到第一。怀疑是 kNN 分数主导了排序。

检查查询：

```json
GET /products/_search
{
  "query": {
    "match": { "name": "ThinkPad X1 Carbon 背包" }
  }
}
```

证据：BM25 查询能精确命中品牌商品，但 kNN 查询把“ThinkPad”当成语义概念，召回一堆笔记本配件。根因是纯 kNN 查询没有保留精确词信号。

修复：把 BM25 和 kNN 合并，用 RRF 融合。

第二个问题：部分商品 description 为空，写入时报错。检查发现 embedding 模型对空字符串返回了 None。

```bash
curl -s "http://localhost:9200/products/_count" -H 'Content-Type: application/json' -d '{"query":{"exists":{"field":"description"}}}'
```

证据：空 description 的文档没有写入 description_vector。根因是写入脚本缺少空值保护。修复：空 description 跳过向量生成，只写文本字段。

**错误尝试：** 一开始把 kNN 的 k 调到 100，想让语义结果更多。结果延迟翻倍，精确词问题更严重。

> 先查边界，
> 再查向量。
> 最后查阈值，
> 顺序别乱。

# 07、优化

```text
V1：纯 kNN 查询→证据：品牌词漂移、延迟升高→V2：BM25 + kNN 双路召回 + RRF 融合
```

改动核心是查询结构。不再单独发 kNN，而是用 bool 查询同时走 match 和 kNN，再用 RRF 合并。

```json
POST /products/_search
{
  "query": {
    "bool": {
      "should": [
        {
          "match": {
            "name": {
              "query": "ThinkPad X1 Carbon 背包",
              "boost": 2.0
            }
          }
        },
        {
          "knn": {
            "field": "description_vector",
            "query_vector_builder": {
              "text_embedding": {
                "model_id": ".multilingual-e5-small",
                "model_text": "ThinkPad X1 Carbon 背包"
              }
            },
            "k": 10,
            "num_candidates": 50,
            "boost": 0.5
          }
        }
      ],
      "filter": [
        { "term": { "tenant": "tenant_a" } },
        { "term": { "category": "背包" } }
      ]
    }
  },
  "rank": {
    "rrf": {
      "window_size": 50,
      "rank_constant": 20
    }
  }
}
```

为何改：BM25 保留精确词信号，kNN 补充语义召回，RRF 不依赖分数绝对值，避免向量分数和 BM25 分数不可比的问题。

> 两条路都走，
> 分数各自算。
> 排名再合并，
> 精确词不散。

# 08、演进

```text
V2：双路召回 + RRF→能力：精确词与语义词都能召回→遗留：embedding 模型更新、阈值调优、跨语言场景
```

用 V1 同一组请求验证：搜“适合经常出差程序员的轻便背包”，语义商品仍在前排；搜“ThinkPad X1 Carbon 背包”，品牌商品回到 Top1。

收益是长尾查询召回提升，精确查询不退化。代价是查询复杂度增加，需要维护两套召回逻辑。

遗留问题：embedding 模型升级后需要重建向量；相似度阈值需要按类目调优；跨语言语义搜索需要多语言模型。

> 能力增加了，
> 代价也来了。
> 不是替代，
> 是补位。

# 09、洞见

```text
从现象到判断：向量召回不是新终点，而是倒排索引的新召回方式
```

## 向量搜索不能替代关键词搜索
```text
精确词→BM25 锚定；语义词→kNN 补充
```
品牌、型号、订单号等精确词，用户期望的是“完全匹配”，不是“差不多”。BM25 在这类查询上更可靠，向量只适合自然语言描述类查询。

## 反直觉判断：语义相似不等于业务相关
```text
向量近→数学近；业务对→类目对
```
向量模型只衡量语义距离，不懂业务边界。没有 Metadata Filter，语义搜索会把“轻便背包”召回成“轻便行李箱”。

## 反直觉判断：分数融合比单一召回更稳定
```text
BM25 分数与向量分数不可比→RRF 只比排名
```
直接加权相加会因为分数分布不同而偏向某一方。RRF 用排名融合，避免分数尺度问题，工程上更稳。

## 向量是召回方式，不是搜索终点
```text
倒排索引→精确召回；dense_vector→语义召回；融合→最终排序
```
把向量当成一种新的召回信号接入现有搜索链路，比另起炉灶做 AI 搜索更务实。

> 向量不是终点，
> 是倒排的新枝。
> 精确词仍靠锚，
> 语义词靠帆。

# 10、系统落地

```text
入口：搜索 API→服务：查询解析与融合→本模块：BM25 + kNN + RRF→存储：dense_vector 索引→未实现：模型版本管理与自动重建
```

原来只有 BM25 字面搜索。本篇增加了 dense_vector 字段、embedding 生成、kNN 查询和 RRF 融合。

现在能做什么：长尾语义查询能召回字面不同但语义相关的商品，同时品牌词等精确查询不退化。

下一篇缺什么：embedding 模型版本管理、向量索引自动重建、相似度阈值自动调优。官方文档见 Elasticsearch 官网文档首页。

> 入口还是那个入口，
> 服务多了一条路。
> 存储多了向量，
> 模型管理还缺。

# 11、小结

```text
三问三答：精确词为何不能替代→语义与精确冲突怎么办→选错会怎样
```

第一问：精确词匹配不能被向量替代，因为品牌、型号、订单号需要完全匹配，向量只保证语义近似。

第二问：语义与精确冲突时，选择双路召回加 RRF 融合，而不是替换或简单加权。

第三问：选错会导致品牌词漂移、客诉上升、延迟翻倍。当前状态是 V2 双路召回已上线，精确词 Top1 命中率保持，长尾召回提升。

> 三问有了答，
> 路也走通了。
> 不是替代，
> 是补位。

# 12、作业

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

## 理解题：为什么 BM25 在品牌词查询上比 kNN 更可靠？
BM25 基于词项匹配，品牌词在标题和属性字段中通常以精确词形式出现，倒排索引能直接命中。kNN 把品牌词转成向量后，会与语义相近但不完全相同的商品混淆，导致排序漂移。

## 实战题：给 products 索引增加 semantic_text 字段，并实现一个带 category 过滤的语义查询。
semantic_text 字段会自动处理 embedding 生成和查询转换。

创建索引时把 description 映射为 semantic_text，写入文档时无需手动生成向量。

查询时用 semantic 查询并加 filter 条件限制 category。

需按当前官方文档核验具体语法。

## 排障题：语义搜索上线后，某类目商品全部消失，如何排查？
先检查 filter 条件是否把该 category 排除，再查 embedding 生成是否失败导致向量字段为空，最后确认 kNN 查询的 num_candidates 是否太小导致召回不足。

用 exists 查询检查向量字段覆盖率。

## 架构判断题：订单号查询是否应该引入向量召回？
不应该。订单号是精确标识符，用户期望完全匹配。向量召回会引入无关订单，增加延迟且降低准确率。订单号查询应继续使用 term 或 keyword 精确匹配。

> 理解是根，
> 实战是干。
> 排障是枝，
> 架构是果。

# 13、升华

```text
工程结论：向量搜索的价值在于补位，不在于替代
```

有依据的结论是：在电商搜索中，BM25 负责精确召回，向量负责语义召回，两者通过 RRF 融合，才能在提升长尾召回的同时不伤害精确查询。

下一篇可以继续做 embedding 模型版本管理与向量索引自动重建，把语义搜索从“能跑”推进到“可维护”。

> 倒排是根，
> 向量是枝。
> 根深枝才茂，
> 搜索才可靠。

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

**已完成：** BM25 字面搜索、类目与租户过滤

**本篇：** dense_vector 语义召回、kNN 查询、BM25+kNN 双路融合

**下一篇：** embedding 模型版本管理与向量索引自动重建

很多团队把向量搜索单独做成 AI Demo，演示完就搁置。真正的问题是：它如何进入现有搜索主链路，而不是另起炉灶。

《Spring ES实战》第14招 向量进入搜索主线

把 dense_vector、kNN 与 semantic_text 纳入主流搜索链路，用真实商品语义召回对比 BM25，并讲清精确词为何仍需倒排索引。

架构师

后端

开发工具

数据库

向量搜索不是新终点，而是倒排索引的新召回方式。精确词用BM25锚定，语义词用kNN补充，双路召回加RRF融合更稳定。品牌词等精确查询必须完全匹配，向量只适合自然语言描述类查询。语义相似不等于业务相关，需配合MetadataFilter限定边界。融合比替换更务实，避免分数尺度问题。

代码解释

Python

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

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

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

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

社区新版编辑器体验调研

《Spring ES实战》第14招 向量进入搜索主线-腾讯云开发者社区-腾讯云

《Spring ES实战》第14招向量进入搜索主线

《Spring ES实战》第14招向量进入搜索主线

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

《Spring ES实战》第14招 向量进入搜索主线

《Spring ES实战》第14招 向量进入搜索主线

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

《Spring ES实战》第14招向量进入搜索主线

《Spring ES实战》第14招向量进入搜索主线