-
Notifications
You must be signed in to change notification settings - Fork 987
FAQ
Welcome to the pkuseg-python wiki!
我们发布此工具包的初衷是想给大家提供多领域分词模型。这样大家可以不用再受限于单一领域语料的预训练模型，而是可以根据自己的领域特点来自由地选择不同的预训练模型。目前工具包支持新闻领域分词、网络领域分词、旅游领域分词、医药领域分词、混合领域分词。
同时，多领域的模型可以更有针对性的分词，较现有的通用模型在多领域中有优势。这是其它工具包没有完成的地方，我们想补上这一个缺口，为大家提供已经训练好的、可以较为简单使用、可以直接获得的模型，免去自己重新训练的周折。
pkuseg是一个新的考虑实用性、但基于科研代码的分词工具包，在代码质量、错误处理、兼容性、鲁棒性诸多方面还有很多需要解决的问题。我们在这方面的经验有限，但我们会尽可能、逐步解决大家提到的、关心的问题。
pkuseg-python主要基于经典的CRF模型，辅以我们提出的ADF训练方法(Sun, et al., 2012)和我们精调的特征，以实现更快的训练速度、更高的测试效果和更好的泛化能力：
- 在CRF模型中，特征选取对分词结果和分词性能有着不小的影响，获得一套效果好、泛化能力较强、分词速度适中的特征往往需要耗费大量时间。我们的代码中包含了这样一套精调的特征，在领域内的训练和测试表明，pkuseg使用的特征可以有效提升不同语料的测试集上的效果。
- ADF训练方法则可以加快训练速度和收敛效果，为DIY用户、希望自己训练模型的用户提供较好的训练体验。
在接下来的版本中，我们计划迁移C#版本中的深度学习模型(Xu and Sun, 2016)，但具体施工日期仍需要确定。
这很有可能是因为您的代码具有全局语句并以非交互模式运行。如果全局语句没有使用if __name__ == '__main__' 保护，当Python多进程模块使用非fork方式创建子进程时，全局语句会被执行多次。Python在不同平台上多进程的默认进程创建方式不同，在Linux上为fork，在Windows上为spawn，因而这种错误经常会在Windows平台上出现。这是Python本身的限制，我们建议当使用多Python多进程功能时，无论在什么操作系统平台，请一定使用if __name__ == '__main__'条件保护您的全局语句。
为了便于比较，我们重新使用其它工具提供的训练接口在细领域的数据集上进行训练，用训练得到的模型进行中文分词。
我们选择Linux作为测试环境，在新闻数据(MSRA)、混合型文本(CTB8)、网络文本(WEIBO)数据上对不同工具包进行了准确率测试。我们使用了第二届国际汉语分词评测比赛提供的分词评价脚本。其中MSRA与WEIBO使用标准训练集测试集划分，CTB8采用随机划分。对于不同的分词工具包，训练测试数据的划分都是一致的；即所有的分词工具包都在相同的训练集上训练，在相同的测试集上测试。对于需要训练的模型，如THULAC和pkuseg，在所有数据集上，我们使用默认的训练超参数。
具体对比结果，请见README。由于对比环境是”实验室环境“，测试语料不能涵盖所有情形，实际文本上的结果可能有差异。
我们选用了混合领域的CTB8语料的训练集进行训练，同时在其它领域进行测试，以模拟模型在“黑盒数据”上的分词效果。选择CTB8语料的原因是，CTB8属于混合语料，理想情况下的通用性会更好；而且在测试中我们发现在CTB8上训练的模型，所有工具包跨领域测试都可以获得更高的平均效果。以下是跨领域测试的结果：
| CTB8 Training | MSRA | CTB8 | PKU | All Average | OOD Average | |
|---|---|---|---|---|---|---|
| jieba | 82.75 | 87.14 | 87.12 | 85.68 | 85.67 | 85.18 |
| THULAC | 83.50 | 94.56 | 89.13 | 91.00 | 89.55 | 87.88 |
| pkuseg | 83.67 | 95.69 | 89.67 | 91.19 | 90.06 | 88.18 |
其中，All Average显示的是在所有测试集(包括CTB8测试集)上F-score的平均，OOD Average (Out-of-domain Average)显示的是在除CTB8外其它测试集结果的平均。
可以看出，细分领域分词结果显著好于跨领域分词效果，但在跨领域分词时，pkuseg也可以取得相对更好的效果。根据我们的测试，训练集泛化效果的排名从到到底分别为：CTB8，WEIBO，MSRA。该结果仅供参考。
我们建议使用默认模型，其“开箱”效果在跨领域测试集上相对更好。新版的pip包默认模型已经更换为混合数据集训练的通用模型。
在前期工作中，我们的测评主要基于开放的语料，如MSR与WEIBO，以及质量有保证的、但收费的语料，如CTB8。由于测试数据有限，对于一些特殊样本的处理还存在问题，我们将努力提升在特殊样本上的分词效果。
在之前的代码中，我们默认提供了MSRA的预训练模型，并开启了一个词典；这些设定没有经过细致讨论，一定程度上影响了开箱体验。在最新的pip包中我们已更正了这些设定。感谢各位的测试和提醒！
我们拟在近期推出一个实现上更为高效的版本，届时欢迎大家进行使用！
如果您发现对文件分词时，多进程比单进程速度要慢，那么很有可能您使用的Windows操作系统。这很大程度上是Python自身导致的，如果您需要使用多进程功能，我们建议您使用基于Linux的系统，或者用于分词量足够大的文件。在后续的更为高效的版本中，这一现象有望得到缓解。
以下为具体解释。由于目前工具包完全使用Python实现，由于Python多进程自身的限制，会出现以下现象：
- 在Windows下多进程创建只能使用spawn方式。这意味着进程空间需要重建，模块需要重新加载，子进程执行参数需要通过进程间通信方式(IPC)传递。
- 在Linux下多进程默认使用fork方式创建。这意味着子进程共享父进程空间，模块不需要重新加载，子进程执行参数可以不通过IPC传递(这是Python内部的实现方式)。
由于我们需要传递给子进程分词模型，Windows下进程创建代价会远远大于Linux下进程创建代价。经过我们测试当任务量较小时，Windows下进程创建时间可能会数倍大于实际分词时间。在我们的硬件平台上，对308KB的文件在Windows下使用10进程分词，实际计算时间仅占总时间4.35%，进程创建时间则占到了77.58%，模型加载时间占到16.61%；10进程总时间接近于单进程的1.5倍。在Linux对同样的文件进行10进程分词，其中多进程计算部分提速6.65倍。
因而，在windows系统我们建议当文件足够大时再使用多进程分词；在Linux的系统，不管文件大小都可以使用多进程分词并且可以得到有效提速。