向量模型分词与截断机制详解：从文本到向量的完整旅程
向量模型分词与截断机制详解：从文本到向量的完整旅程
一句话总结：文本进入模型前，先经分词器切成 token，再按窗口大小截断，最后编码为固定维度向量。顺序不可颠倒，截断默认"保前弃后"。
一、核心流程：三步走
你的输入文本 ↓ 【Step 1】分词器（Tokenizer）切分 → 变成 token 序列（如 1000 个 token） ↓ 【Step 2】窗口截断（Truncation） → 超过 512？保前弃后，截成 512 个 ↓ 【Step 3】模型编码（Encoding） → 通过 Pooling 压成固定维度向量（如 768 维）关键认知：分词 → 截断 → 编码，这个顺序不可颠倒。
二、Step 1：分词器——谁来切、怎么切
2.1 分词器是谁？
分词器是模型配套的工具，不是模型本身，也不是人工干预。它通常以vocab.txt或tokenizer.json文件形式存在，内含几万个预定义的 token。
2.2 分词规则从哪来？
| 来源 | 说明 |
|---|---|
| 预训练语料统计 | 高频组合优先成词（如"中国"比"中"+"国"更常一起出现） |
| 词典文件 | 训练前就定好的 token 列表 |
| 算法类型 | WordPiece、BPE、SentencePiece 等策略不同 |
2.3 同一句话，不同分词器结果不同
| 输入 | BERT-wwm | GPT BPE | 中文优化模型 |
|---|---|---|---|
| “中国我爱你” | ['中国', '我', '爱', '你']（4个） | ['中', '国', '我', '爱', '你']（5个） | 可能['中国我爱你']（1个） |
结论：分词器是"独裁者"，怎么切它说了算。
三、Step 2：窗口截断——超长的怎么处理
3.1 为什么需要截断？
Transformer 模型的注意力机制计算复杂度是O(n²)，token 越多越慢。因此模型在训练时就设定了最大处理长度（窗口大小）。
3.2 常见窗口大小
| 模型 | 窗口（token 数） | 约等于汉字数 |
|---|---|---|
| BERT-base | 512 | ~300-400 字 |
| GPT-3.5 | 4096 | ~2000-3000 字 |
| GPT-4 | 128K | ~6-8 万字 |
3.3 截断策略：默认"保前弃后"
原始文本（1000 token）： [token_1][token_2]...[token_512][token_513]...[token_1000] ↓ 截断线 送入模型（512 token）： [token_1][token_2]...[token_512] ← 后面 488 个直接消失| 策略 | 做法 | 适用场景 |
|---|---|---|
| 前截断（默认） | 保留前 N 个，后面全扔 | 开头有主题句、关键词 |
| 后截断 | 保留后 N 个，前面全扔 | 结尾有结论 |
| 两头截断 | 前后各留一点，中间扔掉 | 特殊需求 |
重要：模型不会报错，静默丢弃，对后半截内容毫无感知。
四、Step 3：编码——为什么维度固定
4.1 从变长到定长
文本长度千变万化，但下游任务（相似度计算、聚类、检索）需要定长输入。
模型通过Pooling（池化）完成转换：
输入文本 → Tokenizer 分词 → Transformer 编码 → Pooling 池化 → 固定维度向量 3字 3个token 3×768矩阵 取平均/取CLS 1×768向量 5字 4个token 4×768矩阵 取平均/取CLS 1×768向量 1000字 被截断到512token 512×768矩阵 取平均/取CLS 1×768向量4.2 常见池化策略
- Mean Pooling：对所有 token 向量取算术平均
- CLS Pooling：取特殊标记
[CLS]对应的向量（BERT 系列） - Last Token Pooling：取最后一个 token 的向量（GPT 系列）
无论中间有多少 token，最终都是 1 × hidden_size。
五、常见误区澄清
| 误区 | 真相 |
|---|---|
| “字数越多，向量维度越高” | ❌ 维度由模型架构固定，与输入长度无关 |
| “不超过窗口大小就不会被分词” | ❌ 分词是必做步骤，永远发生 |
| “先截断再分词” | ❌ 必须先分词才能知道超没超窗 |
| “长文本信息量更大，所以向量更丰富” | ❌ 超窗部分被丢弃，信息反而丢失 |
| “中文一个字对应向量一维” | ❌ 模型处理的是 token，且经过高维非线性变换 |
六、工程实践建议
6.1 中文场景选模型
| 需求 | 推荐模型 |
|---|---|
| 通用中文语义 | bge-large-zh-v1.5、gte-large-zh |
| 短文本匹配 | piccolo-base-zh |
| 不要用 | 原版 BERT（对中文分词弱、语义差） |
6.2 长文本处理策略
以RAG 报警知识库为例：
报警记录 A："传送带电机过载，温度异常升高..."（超长） ↓ 方案1：Chunking 分块 → 切成多段 < 512 token，分别编码 方案2：摘要优先 → 先 LLM 提取关键信息，再编码 方案3：关键信息前置 → 写记录时，结论放开头，细节放后面6.3 生产环境注意事项
- 锁定模型版本：换模型 = 换分词器 = 向量空间变化，需重新建库
- 监控 token 数：预估文本长度，避免关键信息被截断
- 测试截断影响：对比完整文本 vs 截断后的向量相似度差异
七、总结
| 问题 | 答案 |
|---|---|
| 分词是谁做的？ | 分词器（Tokenizer），模型配套工具 |
| 分词规则谁定？ | 预训练时的语料统计和词典文件 |
| 超窗会怎样？ | 默认保前弃后，后面 token 直接丢弃 |
| 为什么维度固定？ | Pooling 机制将变长 token 序列压缩为定长向量 |
| 正确顺序是？ | 分词 → 截断 → 编码，不可颠倒 |
延伸阅读：如果你正在构建 RAG 系统，下一步可以深入了解文本分块（Chunking）策略（按句子、按语义、按固定 token 数）以及向量量化（如何把 768 维浮点向量压缩为更低维表示，节省 90% 存储空间）。