2014-11-16
今天阅读了Jasper的系列博客文本分类技术，写得很不错，浅显易懂，于是做了些摘录。
“文本分类入门”相关的几篇博客
文本分类有个重要前提：即只能根据文章的文字内容进行分类，而不应借助诸如文件的编码格式，文章作者，发布日期等信息。
文本分类核心的问题便转化为用哪些特征表示一个文本才能保证有效和快速的分类。
向量模型（俗称的VSM，向量空间模型）成了适合文本分类问题的文档表示模型。在这种模型中，一篇文章被看作特征项集合来看，利用加权特征项构成向量进行文本表示，利用词频信息对文本特征进行加权。它实现起来比较简单，并且分类准确度也高，能够满足一般应用的要求。
而实际上，文本是一种信息载体，其所携带的信息由几部分组成：如组成元素本身的信息（词的信息）、组成元素之间顺序关系带来的信息以及上下文信息（更严格的说，还包括阅读者本身的背景和理解）。对于扩充文档表示模型所包含的信息量，人们也做过有益的尝试，例如被称为LSI（Latent Semantic Index潜在语义索引）的方法，就被实验证明保留了一定的语义信息。
训练阶段要解决的第一个问题，即如何选取那些最具代表性的词汇（更严格的说法应该是，那些最具代表性的特征）。对这个问题的解决，有人叫它特征提取，也有人叫它降维。
特征提取实际上有两大类方法。一类称为特征选择（Term Selection），指的是从原有的特征（那许多有用无用混在一起的词汇）中提取出少量的，具有代表性的特征，但特征的类型没有变化（原来是一堆词，特征提取后仍是一堆词，数量大大减少了而已）。另一类称为**特征抽取（Term Extraction）**的方法则有所不同，它从原有的特征中重构出新的特征（原来是一堆词，重构后变成了别的，例如LSI将其转为矩阵，文档生成模型将其转化为某个概率分布的一些参数），新的特征具有更强的代表性，并耗费更少的计算资源。
对中文文本来说，首先要经历一个分词的过程，就是把连续的文字流切分成一个一个单独的词汇。
中文分词的效果对文本分类系统的表现影响很大，因为在后面的流程中，全都使用预处理之后的文本信息，不再参考原始文本，因此分词的效果不好，等同于引入了错误的训练数据。分词本身也是一个值得大书特书的问题，目前比较常用的方法有词典法，隐马尔科夫模型和新兴的CRF方法。
英文只需要通过空格和标点便很容易将一个一个独立的词从原文中区分出来。不过，英文文本还有进一步简化和压缩的空间。我们都知道，英文中同一个词有所谓词形的变化（相对的，词义本身却并没有变），例如名词有单复数的变化，动词有时态的变化，形容词有比较级的变化等等，还包括这些变化形式的某种组合。而正因为词义本身没有变化，仅仅词形不同的词就不应该作为独立的词来存储和和参与分类计算。去除这些词形不同，但词义相同的词，仅保留一个副本的步骤就称为**“词根还原”**。
一般来说类别之间的关系都是可以表示成树形结构，这意味着一个类有多个子类，而一个子类唯一的属于一个父类。这种类别体系很常用，却并不代表它在现实世界中也是符合常识的，举个例子，“临床心理学”这个类别应该即属于“临床医学”的范畴，同时也属于“心理学”，但在分类系统中却不便于使用这样的结构。想象一下，这相当于类别的层次结构是一个有环图，无论遍历还是今后类别的合并，比较，都会带来无数的麻烦。
“SVM”相关的几篇博客
SVM 方法有很坚实的理论基础，SVM 训练的本质是解决一个二次规划问题（Quadruple Programming，指目标函数为二次函数，约束条件为线性约束的最优化问题），得到的是全局最优解，这使它有着其他统计学习技术难以比拟的优越性。SVM 分类器的文本分类效果很好，是最好的分类器之一。同时使用核函数将原始的样本空间向高维空间进行变换，能够解决原始样本线性不可分的问题。其缺点是核函数的选择缺乏指导，难以针对具体问题选择最佳的核函数；另外SVM 训练速度极大地受到训练集规模的影响，计算开销比较大。
“特征选取”相关的几篇博客
为分类文本作处理的特征提取算法也对最终效果有巨大影响，而特征提取算法又分为特征选择和特征抽取两大类，其中特征选择算法有互信息，文档频率，信息增益，开方检验等等十数种。
对于开方检验，开方值越大则说明越应该作为特征被选中。
“Java中的字符集编码”相关的几篇博客
面向字符和面向字节中的所谓“面向”什么，是指这些类在处理输入输出的时候，在哪个意义上保持一致。如果面向字节，那么这类工作要保证系统中的文件二进制内容和读入JVM内部的二进制内容要一致。不能变换任何0和1的顺序。因此这是一种非常“忠实于原著”的做法。
这种输入输出方式很适合读入视频文件或者音频文件，或者任何不需要做变换的文件内容。
而面向字符的IO是指希望系统中的文件的字符和读入内存的“字符”（注意和字节的区别）要一致。例如我们的中文版WindowsXP系统上有一个GBK的文本文件，其中有一个“汉”字，这个字的GBK编码是0xBABA（而UTF-16编码是0x6C49），当我们使用面向字符的IO把它读入内存并保存在一个char型变量中时，我希望IO系统不要傻傻的直接把0xBABA放到这个char型变量中，我甚至都不关心这个char型变量具体的二进制内容到底是多少，我只希望这个字符读进来之后仍然是“汉”这个字。
关于网页编码
说到GB2312和GBK就不得不提中文网页的编码。尽管很多新开发的Web系统和新上线的注重国际化的网站都开始使用UTF-8，仍有相当一部分的中文媒体坚持使用GB2312和GBK，例如新浪的页面。其中有两点很值得注意。
第一，html中meta标签的部分，常常可以见到
charset=GB2312
这样的写法，很不幸的是，这个“charset”其实是用来指定页面使用的是什么字符集编码，而不是使用什么字符集。例如你见到过有人写“charset=UTF-8”，见到过有人写“charset=ISO-8859-1”，但你见过有人写“charset=Unicode”么？当然没有，因为Unicode是一个字符集，而不是编码。
然而正是charset这个名称误导了很多程序员，真的以为这里要指定的是字符集，也因而使他们进一步的误以为UTF-8和UTF-16是一种字符集！（万恶啊）好在XML中已经做出了修改，这个位置改成了正确的名称：encoding。
第二，页面中说的GB2312，实际上并不真的是GB2312（惊讶么？）。我们来做个实验，例如找一个GB2312中不存在的汉字“亸”（这个字确实不在GB2312中，你可以到GB2312的码表中去找，保证找不到），这个字在GBK中。然后你把它放到一个html页面中，试着在浏览器中打开它，然后选择浏览器的编码为“GB2312”，看到了什么？它完全正常显示！
结论不用我说你也明白了，浏览器实际上使用的是GBK来显示。 新浪的页面中也有很多这样的例子，到处都写charset=GB2312，却使用了无数个GB2312中并不存在的字符。这种做法对浏览器显示页面并不成问题，但在需要程序抓取页面并保存的时候带来了麻烦，程序将不能依据页面所“声称”的编码进行读取和保存，而只能尽量猜测正确的编码。