分词器详解

简介: 分词器将文本转为模型可处理的数字序列,主流算法有BPE、WordPiece和SentencePiece。BPE高效但中文支持弱;WordPiece用于BERT,适合英文;SentencePiece语言无关,支持中日文。实战中常用SentencePiece处理中文,Hugging Face工具处理英文。面试需掌握算法差异、中文分词策略、词汇表设计及OOV问题解决。

🎯 概述
分词器(Tokenizers)是将文本转换为模型可理解的数字序列的关键组件,直接影响模型的性能和效率。
🏗️ 主流分词算法
1️⃣ BPE (Byte Pair Encoding)
原理:通过合并高频字符对来构建词汇表
优点:
● 有效处理未登录词
● 词汇量可控
● 多语言支持好
缺点:
● 可能产生不完整的词
● 对中文支持有限
实现示例:
from tokenizers import Tokenizer
from tokenizers.models import BPE

tokenizer = Tokenizer(BPE(unk_token="[UNK]"))
2️⃣ WordPiece
原理:基于最大似然估计逐步合并词片段
特点:
● Google开发,用于BERT
● 在词前添加##标记子词
● 更适合英文
示例:
"playing" -> ["play", "##ing"]
3️⃣ SentencePiece
原理:将文本视为Unicode序列,不依赖空格分词
优势:
● 语言无关性
● 支持中文、日文等无空格语言
● 可逆转换
配置示例:
import sentencepiece as spm

spm.SentencePieceTrainer.train(
input='input.txt',
model_prefix='tokenizer',
vocab_size=32000,
model_type='bpe'
)
📊 算法对比
特性 BPE WordPiece SentencePiece
分词粒度 子词 子词 子词/字符
语言支持 英文为主 英文为主 多语言
空格处理 依赖空格 依赖空格 不依赖空格
训练速度 快 中等 慢
模型大小 小 中等 大
🎯 实战应用
中文分词最佳实践

使用SentencePiece处理中文

import sentencepiece as spm

训练中文分词器

spm.SentencePieceTrainer.train(
input='chinese_corpus.txt',
model_prefix='chinese_sp',
vocab_size=32000,
character_coverage=0.995, # 覆盖99.5%字符
model_type='bpe'
)

使用分词器

sp = spm.SentencePieceProcessor(model_file='chinese_sp.model')
tokens = sp.encode('大模型面试宝典', out_type=str)
print(tokens) # ['大', '模型', '面试', '宝典']
英文分词示例

使用Hugging Face Tokenizers

from transformers import AutoTokenizer

tokenizer = AutoTokenizer.from_pretrained('bert-base-uncased')
tokens = tokenizer.tokenize("transformer architecture")
print(tokens) # ['transform', '##er', 'arch', '##itecture']
🔍 技术细节
词汇表构建流程

  1. 预处理:清洗文本,标准化
  2. 训练:基于语料库学习分词规则
  3. 验证:检查分词质量
  4. 优化:调整超参数
    特殊标记处理
    ● [PAD]:填充标记
    ● [UNK]:未知词标记
    ● [CLS]:分类标记
    ● [SEP]:分隔标记
    ● [MASK]:掩码标记(用于MLM)
    📚 深入阅读
    ● 注意力机制详解
    ● 主流大模型结构
    🎯 面试重点
  5. BPE和WordPiece的区别?
  6. 如何处理中文分词?
  7. 词汇表大小如何选择?
  8. OOV(未登录词)问题如何解决?
相关文章
|
7月前
|
机器学习/深度学习 自然语言处理 算法
主流分词算法
分词器将文本转为模型可处理的数字序列,主流算法有BPE、WordPiece和SentencePiece。BPE高效但中文支持弱;WordPiece用于BERT,适合英文;SentencePiece语言无关,支持中文。实战中需根据语言选择算法,并合理设置词汇表大小与特殊标记,解决OOV等问题。
|
8月前
|
Prometheus 运维 监控
监控没做好,DevOps等于裸奔:Prometheus + ELK 的“稳态运营秘籍”
监控没做好,DevOps等于裸奔:Prometheus + ELK 的“稳态运营秘籍”
391 26
|
7月前
|
机器学习/深度学习 传感器 数据采集
MATLAB实现滚动轴承故障诊断(外圈故障)
MATLAB实现滚动轴承故障诊断(外圈故障)
|
6月前
|
机器学习/深度学习 人工智能 自然语言处理
AI时代的“义务教育”:深度拆解LLM预训练核心原理与PyTorch源码实现
本文深入解析大模型预训练核心,以Qwen2.5为例,从Tokenizer、RoPE位置编码到GQA注意力机制,拆解LLM如何通过海量数据“炼”成。涵盖架构演进、关键技术与代码实现,带你手把手理解大模型“义务教育”阶段的底层逻辑。
472 7
|
8月前
|
存储 物联网 Serverless
云栖实录|理想汽车基于 Hologres + Flink 构建万亿级车联网信号实时分析平台
理想汽车携手阿里云Hologres+Flink,构建万亿级车联网实时分析平台。应对海量数据高并发、低延迟挑战,实现写入性能提升200%、计算成本降低40%,支撑数字孪生、智能诊断等核心场景,打造稳定、弹性、低成本的下一代数据底座。
869 7
云栖实录|理想汽车基于 Hologres + Flink 构建万亿级车联网信号实时分析平台
|
7月前
|
人工智能 JSON 数据挖掘
大模型应用开发中MCP与Function Call的关系与区别
MCP与Function Call是大模型应用的两大关键技术。前者是跨模型、标准化的通信协议,实现多工具动态集成;后者是模型调用外部函数的内置机制。MCP如同“蓝牙协议”,支持多设备互联互通,具备高兼容性与扩展性;Function Call则像“语音助手”,依赖特定模型完成具体任务。二者在功能上互补:MCP构建通用接口层,解耦模型与工具;Function Call负责意图解析与指令生成。
|
7月前
|
自然语言处理
主流大模型结构
本文介绍了四大模型架构:Encoder-Decoder、Decoder-Only、Encoder-Only和Prefix-Decoder,涵盖代表模型与应用场景。详解GPT系列演进、LLaMA发展及主流中文大模型,并对比GPT-4、LLaMA-3、Qwen等在架构、参数量与上下文长度等方面的异同。
|
7月前
|
算法
模型压缩与量化
模型压缩通过量化、稀疏化、知识蒸馏等技术,减小模型体积与计算开销,助力大模型在端侧部署。涵盖INT8/INT4、GPTQ、SmoothQuant等方法,平衡压缩比、精度与速度,并支持实战量化加载,提升推理效率。
|
7月前
|
存储 机器学习/深度学习 编解码
预训练技巧
预训练是大模型的核心基础,涵盖混合精度、分布式训练、ZeRO优化、FlashAttention等关键技术,通过高效计算与显存优化,实现大规模模型的快速稳定训练。
|
7月前
|
存储 供应链 前端开发
前端知识回顾与页面搭建
今日开启前端开发实战,打通数据库增删改查与页面展示,实现业务闭环。通过构建新浪新闻及无畏契约商城页面,系统学习HTML、CSS布局与JavaScript交互,掌握工程搭建、样式优先级、盒子模型及AI工具辅助开发,完成从理论到实践的跨越。