还在用tm？你OUT啦！

写

在前面

一提到用R做文本挖掘，小伙伴们最先想到的应该是tm包。的确，作为R平台文本挖掘的首选框架，tm包实现了将文本转换至向量的一切工作，tm甚至还可以实现停用词以及词频分析等一切简单的文本分析。然而tm却存在两个非常致命的缺点：首先，tm包的效率极为低下；其次，tm包由于开发时间早，为了兼容性背负着沉重的“历史包袱”，导致很多语法重复，阻碍了快速学习。

今天，大猫会向大家介绍一个新的文本处理框架：Quanteda。与个人开发的tm包相比，Quanteda由欧洲研究理事会（European Research Council）资助，一出生便含着金钥匙。Quanteda从底层开始重新设计了文本处理过程，在语法与性能上得到了巨大提升。

不

凡的出生

相较于tm包最早是由一个博士生为了完成自己的毕业论文而开发，Quanteda出生便含着金钥匙：他由Kenneth Benoit开发，并且有一个稳定的核心团队进行维护，同时受到欧洲研究理事会（European Research Council）的资助。Quanteda甚至拥有自己的网站，而且给人的感觉就特别专业，大家可以感受一下。

这是tm的主页，整个80年代网页的样子：

这是Quanteda的主页，采用了当前最流形的的扁平设计：

情

致的性能

相信用tm包处理过实际问题的小伙伴们都会明白用tm包处理大数据是一种怎样蛋疼的体验。虽然tm处理help文件中给出的那些样例数据集似乎就是一眨眼的事，但是一旦要处理的语料库增加值几十万甚至上百万条，那么你会发现永远也等不到执行完毕的那一天了。其中的根本原因就在于tm包在设计之初就存在大部分R包的通病：只求“get the work done”，对于性能则几乎不考虑。毕竟，最初大多数R包的开发者只是统计学家，并非是程序员，自然对于性能不那么苛求。但是随着R语言的普及以及大数据的兴起，这些陈旧R包的瓶颈便日益浮现。而此时对于原有包的修修补补并不能根本性解决为题，唯一的出路就是重新设计包，并将性能作为重要的目标融入在底层设计中。Quanteda就是在这样的背景下诞生的。

为了做到极致的性能，Quanteda做了如下努力 ：

内部使用stringi作为字符处理工具

01

stringi由C++写成，效率毋庸置疑，是目前R中最优秀的字符串处理包，没有之一。此外，Quanteda在设计之初就格外重视stringi的Unicode（UTF-8）实现，因而对于中文等Unicode字符的处理丝毫没有压力，这对于国内的小伙伴简直是个福音。嗯，用tm包处理过中文的小伙伴们一定能体会tm包下中文乱码是一种多么抓狂的体验。

内部基于data.table与Matrix包

02

data.table是目前R中数据处理性能最快的包，比原生的data.frame要快几十甚至上百倍。Quanteda在内部使用data.table进行大量文件的索引，同tm相比效率大大提升。data.table也是大猫自己使用最多的包，可以说不管什么包，只要底层用data.table重写，那么性能一定会有巨大提升。此外，Quanteda使用Matrix包来进行稀疏矩阵的运算。由于文本中的很多词出现频率不高，所以当文本转换为向量时会产生稀疏矩阵，稀疏矩阵会占用大量内存并降低性能。Matrix包则对于稀疏矩阵进行了很多优化，是当前计算稀疏矩阵最快的包。

统

一的语法

重新设计所带来的一个好处就是统一、简洁、灵活以及易学的语法。与此对照，tm包的语法背着沉重的的历史包袱。例如最早tm包使用Corpus来建立语料库，但由于Corpus的参数太多太复杂，于是有了后面精简的VCorpus和PCorpus。而且tm为了能够导入PDF以及数据库中的文本文件，使用了一个叫做“Source Control”的中间件。虽然这个中间件提升了tm包的灵活性，但同时也极大增大了系统开销，严重拖慢了运行速度。Quanteda内部由于使用了和tm不一样的语料库实现，所以语法和使用上都会比tm要来的简单，用作者话就是：

“Quantedacorpus structures are simpler objects than in tms, as are the document-feature matrix objects from quanteda, compared to the sparse matrix implementation found in tm.”

代

码样例

Quanteda主页上提供了中文的快速入门指南，包括一个实际操作的例子：分析四十九份中国总理的政府工作报告。下面放上若干代码截图，有兴趣的小伙伴可以直接访问Quanteda主页：quanteda.io