倒排索引
一句话
搜索引擎的目录页。 正常索引是「文档 → 包含哪些词」，倒排索引反过来：「词 → 出现在哪些文档」。
类比
想象一本书：
- 正排索引（目录）：第 1 章讲什么、第 2 章讲什么……
- 倒排索引（书末索引）：「Agent」这个词出现在第 1 页、第 15 页、第 102 页……
你要找「Agent 相关的内容」，翻书末索引比翻全书快得多。
为什么需要它
全文检索的核心操作是：「用户输入一个词，找到所有包含这个词的文档」。如果没有倒排索引，每次都要遍历所有文档——数据量大时不可接受。有了倒排索引，直接 O(1) 查词 → O(n) 取文档列表。
在 RAG 体系中的位置
文档入库 → 分词 → 建倒排索引
↓
用户查询 → 分词 → 查倒排索引 → BM25 打分 → 返回文档它是 BM25 和 ElasticSearch 的底层基础设施。
应用场景
倒排索引的应用远不止搜索引擎：
| 场景 | 示例 |
|---|---|
| 全文搜索 | ES 的核心数据结构 |
| 标签系统 | 「标签 → 文章列表」就是倒排索引 |
| 日志分析 | 按错误码快速定位相关日志 |
横向对比
| 正排索引（MySQL） | 倒排索引（ES） | |
|---|---|---|
| 存储结构 | 行 → 字段值 | 词 → 文档 ID 列表 |
| 查「包含某词的文档」 | 全表扫描 LIKE | O(1) 查词 |
| 查「某文档的所有字段」 | O(1) 主键 | 需要额外存储 |
| 典型场景 | OLTP 事务 | 全文检索 |
优缺点
优点： 关键词查找极快，结构简单，ES 的核心竞争力来源 缺点： 需要额外存储（每个词都建索引），更新成本高（插入文档要重建索引），不支持模糊语义
小结
倒排索引是「搜索引擎为什么这么快」的答案。理解了倒排索引，你就能理解为什么 ES 比 MySQL LIKE 快几百倍——不是算法多聪明，是数据结构选对了。