[中文|英文]

BytePiece

BytePiece是一个基于字节的Unigram分词器，采用纯Python实现，更易于阅读和扩展。由于采用了新的训练算法，通常能够比现有的分词器获得更高的压缩率，同时支持多进程加速训练。此外，它直接操作文本的UTF-8字节，几乎不进行任何预处理，因此更加纯粹和语言无关。

博客：

特性

理想的分词器及其训练算法应具备以下特点：

无损重构
高压缩率
语言无关
数据驱动
训练友好

目前主流的SentencePiece基本上已经具备上述特性，但仍存在一些问题。例如：它支持BPE和Unigram两种算法，BPE压缩率通常更高，但训练极慢且非常耗内存；它仍对文本进行了少量与语言相关的预处理，因此在"语言无关"这一点上并不够纯粹。此外，它是用C++编写的，对大多数用户来说是一个黑盒，不利于研究和修改。

BytePiece设计了一种新的基于**字节N-gram语言模型（BNLM）**的训练方法，能够获得更高压缩率的词表，同时支持多进程训练，在相同语料下比SentencePiece的BPE训练明显更快。代码采用纯Python实现，方便大家阅读和二次修改。此外，BytePiece还提供了比Subword Regularization更高效的随机分词算法。

原理

BytePiece并非简单地基于字节和多进程重写现有的Unigram模型，而是为Unigram设计了新的训练方案，这是它能够获得更高压缩率的关键原因之一。

新的训练方案基于N-gram语言模型的新词发现算法，首次提出于作者7年前的博客《【中文分词系列】 5. 基于语言模型的无监督分词》，详细内容请移步阅读。

关于新的随机分词算法，可以参考《随机分词浅探：从Viterbi Decoding到Viterbi Sampling》和《随机分词再探：从Viterbi Sampling到完美采样算法》。

安装

BytePiece只能在Python3上运行，使用了pyahocorasick来加速训练过程。由于BytePiece是基于字节的，而PyPi上的pyahocorasick是基于Unicode的，因此不能直接使用，需要按照以下方式安装基于字节的pyahocorasick版本：

# 如果已经安装，请先卸载
pip uninstall pyahocorasick

# 直接从git编译安装，注意要传入环境变量AHOCORASICK_BYTES
AHOCORASICK_BYTES=1 pip install git+https://github.com/WojciechMula/pyahocorasick.git

然后安装Cython：

pip install Cython

安装完成后，就可以使用pip安装BytePiece了：

pip install bytepiece==0.6.3

使用

BytePiece的所有源代码实际上就是一个单文件，包含Trainer和Tokenizer两个类，分别用于训练和分词。

训练

训练Tokenizer只需要导入Trainer类：

from bytepiece import Trainer

然后准备训练语料。BytePiece支持不一次性将所有语料读入内存，但由于BytePiece训练需要遍历两遍数据，所以不支持Generator输入，而是要写成Iterator的形式，例如：

import json

class corpus:
    def __iter__(self):
        f = 'data_sample.json'
        with open(f) as f:
            for l in f:
                yield json.loads(l)['text']  # 每次返回一个Unicode字符串

然后就可以正式开始训练了：

trainer = Trainer(order=6, max_vocab_size=100000, min_count=32)
trainer.train(corpus(), workers=64, batch_size=1000)
trainer.save('bytepiece.model')

这里的order就是n-gram语言模型的阶数，建议默认使用order=6；max_vocab_size是词表的最大尺寸，注意由于去除冗余的原因，最终得到的词表大小可能不会精确等于max_vocab_size，而是可能略小于该值；min_count是token的最低出现频次，数据量大时可以适当调高，通常不会明显影响训练结果；workers是并行训练的进程数，可以充分利用机器的所有核心；batch_size是批处理大小，不会影响训练结果，一般情况下无需修改，如果发现CPU利用率不足可以适当调大。

此外，从0.4.1版本开始新增isolate_digits参数，默认为False，当设置为True时，可以确保将所有阿拉伯数字都切分为单个字符：

trainer = Trainer(order=6, max_vocab_size=100000, min_count=32, isolate_digits=True)

从0.6.0版本开始新增ensure_unicode参数，能够保证所有的多字节token都可以还原为unicode。由于目前结果显示启用ensure_unicode后，训练得到的模型压缩率通常还更高，所以默认设置为True。当设置为False时（等同于0.6.0之前的版本），多字节token可能需要使用decode(errors='ignore')才能还原为unicode：

trainer = Trainer(order=6, max_vocab_size=100000, min_count=32, ensure_unicode=True)

分词

训练完成后，参考使用方式：

from bytepiece import Tokenizer

tokenizer = Tokenizer('bytepiece.model')
text = '今天天气不错'

tokens = tokenizer.tokenize(text)  # 返回bytes类型的列表
print(b' '.join(tokens).decode(errors='ignore'))  # 可视化分词结果
ids = tokenizer.encode(text)  # 返回tokens对应的ids
print(tokenizer.decode(ids))  # 重新将ids解码为unicode文本
ids = tokenizer.encode(text, iter=True)  # 返回ids的generator

tokens = tokenizer.tokenize(text, alpha=0.2)  # 随机tokenize
print(b' '.join(tokens).decode(errors='ignore'))  # 可视化分词结果

对比

小数据量对比：

	训练时间↓	最大内存占用↓	压缩率↑	分词速度↑
SP-BPE	55.3分钟	5.2GB	4.80	5.47
SP-Unigram	1.6分钟	2.5GB	4.73	7.84
BytePiece	6.5分钟	4.3GB	5.05	2.50

大数据量对比：

	训练时间↓	最大内存占用↓	压缩率(同源)↑	压缩率(异源)↑	分词速度↑
SP-BPE	19.21小时	97GB	4.52	4.46	1.27
SP-Unigram	2.02小时	384GB	4.51	4.48	5.55
BytePiece	2.24小时	51GB	5.39	4.51	1.92

压缩率的单位是"bytes/token"，即平均每个token对应的字节数；速度的单位是"M bytes/second"，即平均每秒可以切分的字节数（以百万为单位）。其他细节请参考这里。

第一个表格的数据集平均长度较短，BytePiece同时慢于SP-BPE和SP-Unigram；在第二个表格中，语料的平均长度普遍更长，出现了BytePiece的速度优于SP-BPE的结果。这说明BPE的分词速度受长度影响比较明显，也说明经过Cython加速的BytePiece分词速度，速度上已经可以跟SentencePiece相比较。

下载

下载开源的BytePiece模型请移步到models。

转换

0.6.2版开始引入convert_to_sentencepiece方法，支持将ensure_unicode版模型转为sentencepiece模型，并用sentencepiece加载：

from bytepiece import Tokenizer
tokenizer1 = Tokenizer('bytepiece.model')
tokenizer1.convert_to_sentencepiece('bytepiece_sp.model')

import sentencepiece as spm
tokenizer2 = spm.SentencePieceProcessor('bytepiece_sp.model')

tokenizer1.encode('今天天气不错')
tokenizer2.encode('今天天气不错')

对于大部分输入，两个版本的模型都能够获得相同的分词结果和相同的编码ids。但无论如何，bytepiece和sentencepiece的处理逻辑不完全一样，bytepiece更加纯粹一些，而sentencepiece加了很多莫须有的预处理操作，这导致两个版本的模型无法完全对齐。目前已知的问题之一是，当输入包含多个连续换行符(\n)时，分词结果可能会有分歧。

引用

@misc{bytepiece2023,
  title={BytePiece: A more pure and effective tokenizer},
  author={Jianlin Su},
  year={2023},
  howpublished={\url{https://github.com/bojone/bytepiece}},
}