【ElasticSearch 基础】倒排索引、IK 分词、BM25 一次搞懂

正向索引：MySQL 的方式#

假设你有一张笔记表：

1
| id | title       | content                     |
2
|----|-------------|-----------------------------|
3
| 1  | 今天早上跑步  | 沿江慢跑，状态不错            |
4
| 2  | 今天晚上跑步  | 夜跑 5 公里，拉伸后恢复很快    |
5
| 3  | 今天早上骑车  | 绕西湖骑行 20 公里            |

你要搜「跑步」，MySQL 的做法是：

1
SELECT * FROM notes WHERE content LIKE '%跑步%';

它从第 1 行开始，逐行扫描 content 字段，看有没有”跑步”这两个字。

1000 行还好，100 万行就崩了。

这就是正向索引的本质：文档 → 关键词。存档的思路来查，越查越慢。

倒排索引：ES 的方式#

ES 在写入文档时，会先把每篇文档的内容按词拆开，建一张反过来的表：

1
词条         文档 ID 列表
2
─────────────────────────
3
"今天"    -> [1, 2, 3]
4
"早上"    -> [1, 3]
5
"跑步"    -> [1, 2]     ← 搜"跑步"，直接在这里拿结果
6
"骑车"    -> [3]
7
"晚上"    -> [2]

这就是倒排索引：关键词 → 文档。搜什么词，直接翻表，不用遍历。

用更直观的比喻：

1
正向索引 = 图书馆的书架
2
  → 找包含"跑步"的书，要从第 1 排翻到第 100 排，一本一本看
3

4
倒排索引 = 书店的索引卡片柜
5
  → 拉开"跑步"的抽屉，卡片上写着 [书1, 书2, 书99]，直接去拿

O(1) 找到关键词的位置，再按相关性排序返回 Top K。 这就是 ES 能在海量文本下做到毫秒级检索的根本原因。

语义检索 vs 词条检索#

这两个失败案例说明了边界：

• 字面相近但实际不同（如产品型号、错误码、合同编号）→ 走 ES 词条检索
• 字面不同但语义相近（如自然语言问句、同义词、近义词）→ 走 Milvus 语义检索

向量检索是怎么做的#

Milvus 的核心是把文本转成向量（一个高维数字数组），然后在向量空间里找”距离最近”的几个向量。

1
"杭州旅游"  → [0.12, 0.87, 0.34, ...]  ← 这两个向量在空间里距离很近
2
"西湖攻略"  → [0.13, 0.85, 0.36, ...]  ← 所以语义检索能命中
3

4
"errorCode=5001" → [0.91, 0.02, 0.67, ...]  ← 这两个向量距离很远
5
"errorCode=5002" → [0.90, 0.02, 0.68, ...]  ← 但字面上只差一个数字

向量是由 Embedding 模型（如 text-embedding-ada-002）生成的，它能捕捉语义，但对精确字符不敏感。这就是为什么向量检索在处理精确实体时会”漂移”。

为什么 RAG 需要两者都有#

实际生产中的 RAG 系统，基本都是混合检索：

1
用户输入
2
  ├─ ES 词条检索  → 召回精确匹配的文档
3
  └─ Milvus 语义检索 → 召回语义相近的文档
4
         ↓
5
    结果合并去重
6
         ↓
7
    Rerank 精排
8
         ↓
9
    Top K 文档 → 拼 Prompt → LLM 回答

只用向量检索：精确实体、代码、编号容易漂移，召回结果不可靠。 只用词条检索：自然语言问句、同义词、近义词容易漏掉，召回率低。 两者结合：互补覆盖，召回质量显著提升。

两种模式#

IK 提供两种分词模式，适用于不同场景：

ik_max_word — 最细粒度，写入时用

1
输入："Elasticsearch全文检索入门"
2

3
输出：Elasticsearch / 全文检索 / 全文 / 文检 / 检索 / 入门

穷举所有可能的词语组合。“全文检索”会被拆成 全文检索、全文、检索 三个词条，全部建入倒排索引。

目的：追求高召回率。 用户不管搜”检索”还是”全文检索”，都能命中这篇文档。

ik_smart — 最粗粒度，搜索时用

1
输入："Elasticsearch全文检索入门"
2

3
输出：Elasticsearch / 全文检索 / 入门

按最合理的语义单元切割，不重叠，不多拆。

目的：追求高精确率。 搜索”全文检索”直接匹配词条，不会因为多个重叠组合而引入噪音。

为什么写入和搜索用不同的模式#

这是一个很经典的设计思路：

• 写入时用 ik_max_word：把所有可能的词条都建进倒排索引，保证任何搜法都能命中（高召回）
• 搜索时用 ik_smart：把用户输入按语义单元切割，精准匹配词条，不引入噪音（高精确）

两者配合，才能在召回率和精确率之间取得平衡。

在 Kibana Dev Tools 里跑两行就能直观感受区别：

1
POST /_analyze
2
{
3
  "analyzer": "ik_max_word",
4
  "text": "Elasticsearch全文检索入门"
5
}
6

7
POST /_analyze
8
{
9
  "analyzer": "ik_smart",
10
  "text": "Elasticsearch全文检索入门"
11
}

自定义词典#

IK 内置词典是静态的，遇到新词、专有名词（比如产品名、人名、行业术语）可能切错。

ES 支持挂载自定义词典文件，把你的专有词汇加进去：

1
ElasticSearch
2
向量检索
3
大语言模型
4
RAG

这在做垂直领域的搜索系统时非常重要——通用词典认不出你的行业术语，召回结果会很差。

先说 TF-IDF 的问题#

BM25 是 TF-IDF 的改进版，先理解 TF-IDF 的局限，才能理解 BM25 为什么更好。

TF-IDF 由两部分组成：

• TF（词频，Term Frequency）：一个词在文档中出现的次数越多，相关性越高
• IDF（逆文档频率，Inverse Document Frequency）：一个词在所有文档中越少见，权重越高

TF-IDF 的问题是线性思维：

一篇文档里出现 100 次”跑步” = 相关性是出现 1 次的 100 倍

这不合理。一篇文章堆砌了 100 次同一个词，不见得比认真写了 10 次的更相关——它更可能是在刷排名。

另一个问题是没有考虑文档长度：一篇 10 万字的书里出现 10 次”跑步”，和一篇 100 字的笔记里出现 10 次”跑步”，TF-IDF 给的分数一样。但显然后者更相关。

BM25 的三个核心策略#

BM25（Best Match 25，第 25 次迭代的最佳匹配算法）用三个策略解决了上面的问题：

策略 1：词频饱和（TF Saturation）

BM25 对词频做了非线性处理——词频增加到一定程度后，分数增长趋于平缓，不再线性增长。

1
TF-IDF：出现 100 次 = 出现 1 次的 100 倍分数
2
BM25：  出现 100 次 ≈ 出现 10 次的分数（边际递减）

防止通过堆砌关键词刷排名。

策略 2：文档长度归一化（Length Normalization）

BM25 引入了文档长度参数，对长文档的词频做惩罚：

1
100 字笔记出现 5 次"跑步" vs 10 万字书出现 5 次"跑步"
2
→ 笔记的分数更高（密度更大，更相关）

让长文档和短文档在同一个公平基准上比较。

策略 3：稀有词权重更高（IDF 加权）

这一点和 TF-IDF 类似，但计算方式更精确：

1
"的" 出现在 99% 的文档里 → IDF 极低，几乎不贡献分数
2
"IK分词器" 只出现在 0.1% 的文档里 → IDF 极高，大幅提升相关性

区分信息含量，高频停用词不会污染排序结果。

一句话记住 BM25#

BM25 = 词频减速 + 文档长度纠正 + 稀有词加权

不是”词出现多少就加多少分”，而是一套非线性的公平打分体系。

ES 默认使用 BM25，不需要手动配置任何参数。大多数场景静默生效。

RAG 是什么#

RAG（Retrieval-Augmented Generation，检索增强生成）的核心思路是：

不让 LLM 凭记忆回答，而是先从知识库里检索相关内容，再把检索结果拼进 Prompt，让 LLM 基于真实资料回答。

这解决了 LLM 的两个核心问题：

• 幻觉：LLM 不知道的事情会编造答案
• 时效性：LLM 的训练数据有截止日期，无法回答最新信息

完整的 RAG 通路#

1
                    ┌─────────────────────────────────┐
2
                    │           知识库构建阶段            │
3
                    └─────────────────────────────────┘
4
原始文档（PDF/MD/网页）
5
        ↓
6
    文本切片（Chunking）
7
    ┌───────────────────────────────────────────────┐
8
    │  将长文档切成适合检索的片段（通常 200-500 字）    │
9
    └───────────────────────────────────────────────┘
10
        ↓                            ↓
11
  ES 写入                       Milvus 写入
12
  ik_max_word 分词               Embedding 模型生成向量
13
  建倒排索引                      建向量索引
14
        ↓                            ↓
15
  词条检索库                     语义检索库
16

17

18
                    ┌─────────────────────────────────┐
19
                    │           在线检索阶段             │
20
                    └─────────────────────────────────┘
21
用户输入："ES 的 BM25 算法是什么"
22
        ↓
23
    ┌───────────────────────────────────────────────┐
24
    │  并行发起两路检索                               │
25
    └───────────────────────────────────────────────┘
26
        ↓                            ↓
27
  ES 词条检索                    Milvus 语义检索
28
  ik_smart 分词查询               Embedding 生成查询向量
29
  BM25 打分排序                   余弦相似度排序
30
  召回 Top 20                    召回 Top 20
31
        ↓                            ↓
32
    ┌───────────────────────────────────────────────┐
33
    │  结果合并去重（RRF 或加权融合）                  │
34
    └───────────────────────────────────────────────┘
35
        ↓
36
    Rerank 精排（Cross-Encoder 模型）
37
    ┌───────────────────────────────────────────────┐
38
    │  对合并后的候选文档重新打分，选出最相关的 Top 5   │
39
    └───────────────────────────────────────────────┘
40
        ↓
41
    Top 5 文档片段
42
        ↓
43
    拼入 Prompt
44
    ┌───────────────────────────────────────────────┐
45
    │  System: 你是一个技术助手，基于以下资料回答问题   │
46
    │  Context: [Top 5 文档片段]                     │
47
    │  User: ES 的 BM25 算法是什么                   │
48
    └───────────────────────────────────────────────┘
49
        ↓
50
    LLM 生成回答

每个环节的作用#

为什么 Rerank 是必要的#

ES 和 Milvus 各自召回 20 条，合并后有 30-40 条候选文档（去重后）。

直接把 40 条都塞进 Prompt 会超 token 限制，而且 LLM 处理太长的上下文时注意力会分散，回答质量下降。

Rerank 模型（Cross-Encoder）会对每一对「查询 + 文档」重新打分，选出最相关的 Top 5。

它比 ES 的 BM25 和 Milvus 的余弦相似度都更准确，因为它能同时看到查询和文档的完整内容，而不是分别编码后再比较。

代价是速度慢——所以只用在最后的精排阶段，不用在初始召回阶段。

RAG 的真正价值#

RAG 不只是”给 LLM 加了个搜索”，它解决的是 LLM 在生产环境中最核心的可靠性问题：

1
没有 RAG：LLM 凭记忆回答 → 幻觉、过时信息、无法溯源
2
有了 RAG：LLM 基于检索到的真实文档回答 → 可溯源、可更新、可控

对于企业级应用，RAG 还有一个关键价值：私有知识库。

LLM 的训练数据是公开的，但企业的内部文档、产品手册、合同、代码库是私有的。RAG 让 LLM 能够访问这些私有知识，而不需要重新训练模型（成本极高）。

这就是为什么 ES + Milvus + Rerank 这套混合检索架构，是目前生产级 RAG 系统的标准配置。