倒排索引入门：搜索引擎如何从词找到文档

我曾经把“倒排索引入门：搜索引擎如何从词找到文档”学成了一组互不相干的名词和代码。具体表现是：我最初使用搜索引擎只关注查询接口，直到自己做站内搜索，才真正关心一段文本怎样被拆词、建索引和召回。后来我尝试只保留一个问题：它到底在减少哪一种重复工作？顺着这个问题，整块知识才稳定下来。

倒排索引是搜索引擎的核心思想。普通阅读文档时，是从文档里找词；倒排索引反过来，从词找到包含它的文档。

它从哪里来

倒排思想可以从书籍索引和词语索引追溯：读者不是逐页寻找一个词，而是从词条直接跳到页码。计算机信息检索把页码换成文档 ID，并继续加入词频、位置、压缩与排名，形成现代搜索引擎的基础结构。

倒排索引是什么

图：倒排索引把关键词映射到文档列表，从而快速搜索

普通文档：

doc1: Java 哈希 表
doc2: 数据结构 哈希
doc3: 搜索 引擎

倒排后：

哈希 -> doc1, doc2
Java -> doc1
搜索 -> doc3

建索引流程

一个简化搜索系统通常包含：

1. 文档采集。
2. 文本清洗。
3. 分词。
4. 去停用词。
5. 构建倒排表。
6. 查询时取 posting list。
7. 合并结果并排序。

Posting List

倒排表中，每个词对应的文档列表叫 posting list。真实系统里，posting list 不只保存文档 ID，还可能保存：

• 词频。
• 词在文档中的位置。
• 字段来源，比如标题、摘要、正文。
• 文档权重。
• 更新时间。

这些信息用于相关性排序和高亮摘要。

查询流程

如果用户搜索“数据结构 哈希”，系统可能会：

1. 对查询分词。
2. 找到“数据结构”和“哈希”的 posting list。
3. 求交集或并集。
4. 根据标题命中、词频、位置、时间等因素排序。
5. 返回摘要和高亮片段。

和数据库 LIKE 的区别

LIKE '%关键词%' 会扫描大量文本，数据量大时性能差。倒排索引提前把词和文档关系建好，查询时直接根据词找文档。

这也是为什么博客全站搜索不能只靠简单 LIKE。小站可以先用数据库全文索引，后续内容变多后，可以接入 Meilisearch、Typesense、Elasticsearch 等专门搜索服务。

我的分析

倒排索引是“数据结构服务产品体验”的典型例子。它不是算法题里的孤立结构，而是搜索功能背后的核心模型。你这个博客后面如果文章很多，全站搜索体验要提升，就可以沿着倒排索引、分词、高亮、相关性排序继续演进。

面试题

1. 倒排索引为什么适合全文搜索？
2. Posting List 通常保存哪些信息？
3. 搜索结果为什么需要相关性排序？
4. 数据库 LIKE 和倒排索引有什么区别？
5. 小型博客搜索如何逐步演进到专业搜索服务？