搜索与大模型中的分词：看似相同，实则迥异

引言：一个看似简单却深刻的问题

在搜索引擎和大模型的底层实现中，我们都会听到 "Tokenization"（分词/标记化）这个词。但它们是同一回事吗？

简单直接的回答是：不一样。

虽然都叫 "Tokenization"，但传统搜索引擎（如 ParadeDB、Elasticsearch、Postgres 的 tsvector）的分词与大模型（如 GPT、Claude）的分词在目的、原理和处理方式上都有本质的区别。

至于第二个常见问题："向量搜索既然有了语义理解，是不是就比传统分词搜索更好？" 答案是：互补，而不是完全替代。

本文将深入剖析这两个核心问题，帮助你理解现代搜索系统的底层逻辑。

一、传统搜索分词 vs. 大模型分词

1.1 传统搜索分词的原理与目的

传统搜索引擎中的 Tokenization 主要解决的是文本匹配问题。它的核心逻辑是基于语言学规则的归一化（Normalization），目的是提高搜索的召回率（Recall）。

参考 ParadeDB 的文章，传统搜索的分词管道包含以下步骤：

第一步：字符过滤（Character Folding）

```text 输入： "The full-text database jumped over the lazy café dog"

↓ 大小写转换 + 变音符号折叠

"the full-text database jumped over the lazy cafe dog" ```

这一步确保字符的标准化和一致性：

将所有字母转换为小写，使 `Database` 能匹配 `database`
折叠变音符号（如 `café` → `caf`，`résumé` → `resume`）

虽然可能引入误匹配（比如人名 `Olive` 会匹配到橄榄 `olive`），但大多数系统接受这种权衡：宁可误匹配，也不能漏掉结果。

第二步：分词（Tokenization）

```text ↓ 按空格和标点符号分割

[the, full-text, database, jumped, over, the, lazy, cafe, dog] ```

将过滤后的文本切分成可索引的单元。常见的分词器包括：

面向单词的分词器：在词边界处切分，适用于大多数搜索应用
部分单词分词器：使用 N-gram 创建重叠字符序列，适合自动补全和模糊匹配
结构化文本分词器：专门处理 URL、邮箱、文件路径等特定格式

第三步：去停用词（Stopword Removal）

```text ↓ 移除 "the", "and", "of", "are" 等常见词

[full-text, database, jumped, over, lazy, cafe, dog] ```

停用词出现在所有文档中，会稀释搜索结果的相关性。移除后，从 10 个 tokens 减少到 8 个，剩余的 tokens 携带更多语义权重。

注意：在支持 BM25 的系统中，停用词通常被保留，因为 BM25 公式会自动降低高频词的权重。

第四步：词干提取（Stemming）

```text ↓ 将单词还原为词根

[full, text, databas, jump, over, lazi, cafe, dog] ```

这是最关键的一步。基于 Martin Porter 1980 年提出的算法，现代词干提取器（如 Snowball）会：

`jump`, `jumps`, `jumped`, `jumping` → `jump`
`database` → `databas`
`lazy` → `lazi`

虽然结果可能看起来不像真实的单词，但这不重要——重要的是一致性。无论用户搜索 `jumping` 还是 `jumped`，都会被还原为 `jump`，从而匹配到包含 `jump` 的文档。

核心目的总结：

传统搜索分词的目标是匹配（Matching）。它通过语言学规则（词典、语法、词干提取）强制将不同形式的词合并，确保用户大概率能搜到想要的内容，即使这意味着牺牲一定的精确度。

1.2 大模型分词的原理与目的

大模型的 Tokenization（如 BPE、Tiktoken）解决的是完全不同的问题。它的核心目的是压缩与编码（Compression & Encoding），让数学模型能够高效处理文本。

与传统分词不同，LLM 分词是基于统计的，不考虑语言学规则。

核心算法：BPE（Byte Pair Encoding）的统计逻辑

BPE 本质上是一种数据压缩算法。它的逻辑是：在数太字节的数据中，哪些字符组合出现得最频繁？我就把它合并成一个 Token。

让我们用程序员最容易理解的方式来演示这个过程：

初始状态

假设我们有一个原始语料：

```text hug pug hug pug ```

一开始，我们只认识单个字符：

```text h u g _ p u g _ h u g _ p u g ```

第一轮统计

扫描整个语料，统计哪两个相邻符号出现频率最高：

`h` + `u`：2 次
`u` + `g`：4 次 ⬅️ 最高
`p` + `u`：2 次

合并 `u` + `g` → `ug`：

```text h ug _ p ug _ h ug _ p ug ```

第二轮统计

`h` + `ug`：2 次
`p` + `ug`：2 次

假设合并 `h` + `ug` → `hug`：

```text hug _ p ug _ hug _ p ug ```

这就是"基于统计"的含义：

模型根本不知道 `hug` 是"拥抱"，`ug` 是个词根。它只知道：在样本数据中，`u` 后面跟着 `g` 的概率极高，为了节省空间和计算量，我把它们打包成一个 ID。

为什么选择统计而非语言学？

如果不采用统计子词，有两种极端做法：

Character-level（按字切分）
- `apple` → `a`, `p`, `p`, `l`, `e`
- 问题：序列太长，占用宝贵的上下文窗口，推理速度慢
Word-level（按单词切分）
- 查牛津字典，字典里有的就是一个 Token
- 问题：OOV（Out Of Vocabulary）问题
- 遇到 `ChatGPT`, `k8s`, `uninstagrammable` 等新词时，模型只能标记为 `<UNK>`
Sub-word（基于统计的子词） ⬅️ LLM 的选择
- `uninstagrammable` → `un` + `insta` + `gram` + `mable`
- 优势：
  - 常见词（如 `apple`）：统计频率高，作为一个整体 token
  - 生僻词（如 `uninstagrammable`）：被拆解成常见词根，模型可以猜出意思

核心目的总结：

大模型分词的目标是预测与生成（Prediction）。它基于概率统计做数据压缩，不在乎语言学规则，只在乎"在这个数据集里，什么片段最常一起出现"。它保留了文本的原始形态（大小写、时态、空格），以便模型能生成流畅、符合语法的文本。

1.3 对比表格

特性	传统搜索分词	大模型分词
例子	`running` → `run`	`running` → `run`, `ning`（假设）
处理方式	语言学规则（词典、语法）	统计学规则（频率、字节对）
对同义词的处理	强行合并（Stemming）	分配不同 ID，靠 Embedding 拉近关系
主要目标	匹配（Matching）	预测与生成（Prediction）
保留原文信息	❌ 丢失（大小写、时态）	✅ 保留（为了生成质量）
可解释性	✅ 高（可以看到每个处理步骤）	❌ 低（统计黑盒）

二、既然有了向量搜索，为什么还需要传统分词？

你可能会问："如果向量搜索采用了语义理解，那它不是更好吗？"

确实，向量搜索（Dense Retrieval） 非常强大，它解决了"词不匹配但意匹配"的问题（比如搜"水果"，能搜出"苹果"）。

但是，它有两个致命的弱点，这正是 ParadeDB 这类数据库依然重视传统分词（Sparse Retrieval / BM25）的原因：

2.1 精确匹配（Exact Match）的缺失

向量搜索是"模糊"的，这在某些场景下是个问题：

场景 1：错误代码搜索

```text 用户搜索： "Error-Code-9921" ```

向量搜索：可能推荐 `Error-Code-500`（因为它们在语义上都是"错误代码"）
传统分词：精确锁定 `9921` 这个 token

当用户需要 100% 精确的关键词匹配时，向量搜索往往会失效。

场景 2：特定产品型号

```text 用户搜索： "iPhone 15 Pro Max" ```

向量搜索：可能推荐 `Samsung Galaxy S24`（因为都是"高端旗舰手机"）
传统分词：精确匹配所有关键词

2.2 领域外词汇（Out-of-Distribution）

场景：专有名词或项目代号

```text 用户搜索： "Project-X-Alpha" ```

向量搜索：如果这个词不在训练数据中，模型不知道它的语义，生成的向量可能是混乱的
传统分词：只看字面，只要文档里有 `Project-X-Alpha`，就能搜出来

对于公司内部项目代号、特定行业缩写、新造的技术术语，传统分词的优势无可替代。

2.3 可解释性（Explainability）

向量搜索：是一个黑盒。你不知道为什么这篇文章排在第一位，因为是高维空间的数学距离
传统分词：非常清晰。因为这篇文章包含了 5 次你搜索的关键词，所以它排在前面

在企业级应用中，可解释性往往很重要。用户需要知道"为什么我得到这个结果"。

三、现代搜索的终极形态：混合搜索（Hybrid Search）

现在的搜索技术（包括 RAG 系统）通常不会二选一，而是采用 Hybrid Search（混合搜索）：

3.1 混合搜索的三大组件

``` 用户查询 "如何优化数据库查询性能" ↓ ┌────┴────┐ │ │ 关键词搜索向量搜索（BM25）（Embedding） │ │ └────┬────┘ ↓ 重排序（Rerank） ↓ 最终结果 ```

1. 关键词搜索（BM25/Token-based）

职责：精确匹配

处理专有名词、ID、精确短语
例如：数据库名称、错误代码、API 函数名
优势：高召回率，不会漏掉包含关键词的文档

2. 向量搜索（Embedding-based）

职责：语义理解

处理同义词、模糊描述、概念搜索
例如：搜"性能优化"，能找到"加速"、"提速"、"优化"相关的内容
优势：理解用户意图，即使不使用精确的关键词

3. 重排序（Rerank）

职责：精细排序

将两者的结果合并
使用更精细的模型（如 Cross-Encoder）对候选文档打分
考虑多样性、新鲜度、用户偏好等因素

3.2 实际案例

假设用户在技术文档中搜索：

```text "如何加速数据库查询" ```

关键词搜索会找到：

包含"数据库"、"查询"的文档（精确匹配）
但可能遗漏使用"优化"、"提速"、"性能"等同义词的文章

向量搜索会找到：

讨论"数据库性能优化"的文档（语义相似）
讨论"查询提速技巧"的文章（意图匹配）
但可能遗漏包含特定技术术语的精确文档

混合搜索的优势：

召回：关键词搜索确保不会漏掉包含技术术语的文档
语义：向量搜索找到用词不同但意思相关的文档
精确：重排序模型综合考虑多种信号，给出最相关的结果

四、大模型分词的有趣现象（副作用）

因为是基于统计的压缩，LLM 分词有时会出现违反人类直觉的行为，这也解释了 LLM 的某些"Bug"：

4.1 数字处理能力的弱点

你问 LLM `100 + 200`，它通常没问题。但对于大数字，表现可能不佳。

原因：在分词器眼里，数字不是"数值"，而是"高频字符串"。

`123456` 可能被切分为 `12` 和 `3456`（假设语料里 3456 经常一起出现）
这导致模型在做数学运算时，实际上是在做字符串补全，而不是真正的算术逻辑

4.2 代码缩进与空格

对于 Python 开发者，空格很重要。

在统计分词中，常见的缩进（如 2 个空格、4 个空格）经常被合并成一个独立的 Token
例如，GPT 的分词器可能专门有一个 Token ID 代表 ` `（4 个空格）
副作用：这也是为什么 LLM 写代码通常格式是对的，因为它把缩进当成了一个"积木块"

4.3 多语言的不公平

这纯粹是统计数据的来源决定的：

如果训练语料 90% 是英文，那么英文单词 `Optimization` 可能就是一个 Token（1 个 ID）
但中文的`最优化`，因为在语料库里占比低，可能被切成`最`、`优`、`化`（3 个 ID）
后果：同样的含义，中文通常比英文消耗更多的 Token，导致：
- API 调用成本更高
- 占用的上下文窗口更多
- 等长文本能包含的信息量更少

五、总结

5.1 核心观点回顾

传统搜索分词（如 ParadeDB）
- 目标：为了让人搜得到
- 方法：懂语言规则（`run` = `running`）
- 优势：高召回率、精确匹配、可解释性强
大模型分词（如 Tiktoken）
- 目标：为了让机器算得快
- 方法：基于概率统计做数据压缩
- 优势：处理生僻词、多语言、生成流畅文本
向量搜索 vs. 传统分词
- 向量搜索不是"更好"，而是"互补"
- 精确匹配、专有名词、可解释性，依然是传统分词的强项
现代搜索系统
- 采用混合搜索（Hybrid Search）
- 关键词搜索 + 向量搜索 + 重排序
- 在召回、语义、精确之间取得平衡

5.2 实践建议

如果你在构建搜索系统：

对于技术文档、代码搜索：优先使用传统分词
对于自然语言问答：加入向量搜索
对于复杂场景：考虑混合搜索

如果你在优化 LLM 应用：

理解分词器的行为，避免在 prompt 中使用容易产生异常切分的方式
对于多语言应用，注意不同语言的 token 效率差异
对于数学计算、精确匹配任务，不要完全依赖 LLM

5.3 Tokenize 之后的下一步是什么？

理解了分词的原理后，一个自然的问题是：Tokenize 完成之后，下一步该做什么？

答案取决于你的应用场景：

场景一：传统搜索 → 建立倒排索引

原始文本 → 分词 → [tokens] → 倒排索引

下一步是建立倒排索引，例如：

[full-text] → [doc1, doc3, doc5]
[database]  → [doc2, doc4]
[jump]      → [doc1]

这样用户搜索时，可以快速找到包含这些 token 的文档。这是 Elasticsearch、ParadeDB 等搜索引擎的核心机制。

场景二：大模型 → 生成 Embedding

原始文本 → 分词 → [token IDs] → Embedding → 向量

下一步是生成 Embedding（向量化），将离散的 token 转换为连续的向量表示，用于：

语义理解
向量搜索
上下文计算

场景三：现代混合搜索 → 两者并行

用户查询
    ↓
┌───┴───┐
│       │
关键词  向量
(BM25)  (Embedding)
│       │
└───┬───┘
    ↓
  重排序
    ↓
 最终结果

核心观点：Tokenize 是起点，但不是终点。根据需求选择后续路径，或者两者结合。

5.4 展望

随着搜索技术的发展，我们可能会看到：

更智能的混合搜索算法，自动平衡关键词和语义信号
专门的代码分词器，解决编程语言的特殊需求
多语言公平的 tokenizer，减少语言偏差

但无论技术如何演进，理解底层原理都是构建高质量系统的基础。ParadeDB 讨论的分词和大模型的分词虽然同名，但它们解决的是不同的问题，在搜索系统中都扮演着不可替代的角色。

📚 下一篇：Embedding - 从 Token 到向量

在理解了 Tokenization 的本质之后，下一步就是探索 Embedding（嵌入） 的世界。它将离散的 token 转换为连续的向量，让机器能够理解语义关系。

下一篇我们将深入探讨：

什么是 Embedding？为什么需要它？
Word2Vec、GloVe、BERT、OpenAI Embedding 的演进历程
向量空间中的语义魔法：为什么"国王 - 男人 + 女人 = 女王"？
Embedding 在搜索、推荐、RAG 系统中的实际应用
如何选择和评估不同的 Embedding 模型

敬请期待《Embedding：从 Token 到语义向量》