自然语言处理或者自然语言理解的终极之道：聊天机器人？！

网上看到下面这段文字，让我这样的自然语言处理小辈激动不已。找个时间好好学习一下这个Cleverbot的后台机制，特别是它的自动学习机制。曾经设想过这样的东西，但没有想明白学习机制。这次得好好学习咯。

----------------------------------------------------------------

智能机器人Cleverbot是怎样炼成的？

1988年，英国人罗洛卡彭特（Rollo Carpenter）开始着手这一人工智能研究项目，1997年将机器人Cleverbot接入互联网，使其不断地向访问者学习"知识"，增长自己的"才干"，直到今年9月才获得初步的成功。请见："Cleverbot: Artificial Intelligence of the Future, or Just a Jerk?"一文，此文发表于2011年7月18日。

由此可见，机器学习是构建网络智能机器人的基础，不会自动学习，谈何智能机器人？但是，怎么让机器"自动学习"？这就是一个实质性的问题。这个智能机器人研究项目一干就是二十几年，与我们某些"核高基"研究项目的"短视"相比，不可同日而语也。乌呼！

VI下DoxygenToolkit生成注释非常方便

曾几何时，我在Eclipse下进行Java编程时，对于生成Javadoc有过一个非常棒的插件。将光标放置到函数内部或者文件头部，按下快捷键就可以得到相关的符合Javadoc或者Doxygen标准的相关注释。当时对程序编写注释是一件非常舒服的事情，而且最终生成的文档也非常的漂亮。

从去年2月开始完全转入Linux环境后，我开始纯粹的C++编程，不管采用哪种编程IDE，都没有找回那种编写注释的感觉了。今天，这种感觉重新回来了。那就是VI下的DoxygenToolkit。在文件头输入DoxAuthor命令就能自动插入作者信息，输入DoxLic就能自动插入版权信息，更为强大的是在类或者函数的头部输入Dox命令就能得到标准的注释模板，而且一些域已经很好的自动补全了。

配合Doxygen生成的html网页或者latex pdf文档看起来都是相当的专业。

参考链接：

Vim自动文档插件--DoxygenToolkit http://hi.baidu.com/david_jlu/blog/item/44c1413340121f45ad4b5f90.html

vim中两个实用插件doxygen和projects的安装与使用  http://yaronspace.cn/blog/archives/682

doxygen+VIM文档实用指南for C/C-liked Programmers http://blog.csdn.net/clarkZHUO/article/details/1471573

看来以后在VI下的编程时间会不断增加，还得熟悉一些相关插件，争取实现手指在键盘上飞的感觉。标记于此。

我的机器翻译学习经历以及即将开启的词对齐学习

统计机器翻译的第一步就是词对齐，随后抽取短语表，然后根据短语表进行翻译解码，中间会根据语言模型来选取最优的翻译结果。整个统计机器翻译的各个步骤都有很多人在不断的深入研究，从mt-archieve这个网页（http://www.mt-archive.info/subjects.htm）可以见识到相关论文的增长速度。面对如此海量的论文，对于一个统计机器翻译的新手，究竟该何去何从呢？这个问题长时间的困扰了我。

去年年初博士毕业后开始接触统计机器翻译。好友张慧一开始就建议我仔仔细细从零开始实现一个机器翻译的系统，可以完全从词对齐开始实现全部的步骤，也可以针对解码器从零开始实现解码功能，经过这个阶段后才能真正领悟统计机器翻译的魅力以及其中的症结。由于项目的压力，我只能抽出业余时间来完成这个计划。起初是想从零开始实现解码器，经过一个多月的业余开发，我的解码器可以得到和moses的最基本stack解码一模一样的各种概率输出。当时我小小的兴奋了一下，感觉对机器翻译总算有了一点点感觉。但是随着翻译句子长度的增加，我的解码器速度变得非常的慢，比起moses的速度差远了，内存开销方面我的解码器也比moses差很多。后续我开始研究moses的各种加速技术以及节省内存开销的方法。在网上四处转悠后发现了kenlm这个比srilm好很多的语言模型工具包。熟练使用后，我把kenlm的代码改装替换掉了我的解码器的语言模型，也同时替换掉了我的项目里使用的语言模型，当时我项目使用的decoder在内存开销方面节省了很多。随着更进一步的优化，我对stack解码器相关的技术了解了更多。当我开始尝试编写cube pruning解码方法时，开始被项目项目相关的其他事宜占用全部的时间，随后我的解码器业余时间研发计划就被搁置下来。仔细算来，我的这个事项居然被耽搁了半年多了。

随着对统计机器翻译的认识不断深入，我越发觉得如果想深入研究机器翻译或者从事相关的开发工作，词对齐方面的研究必不可少。给我造成这种直觉的直接原因，是我原本想准备完成一项短语表过滤的研究任务。但是随着调研和各种对比实验的深入，我发现单纯从已有的低质短语表出发，很难找到更加有效的过滤方法。更加fundamental的方法是进行更好的词对齐以及后续的短语抽取。这个路子可能才是解决问题的思路。

后续我阅读了近两年来的关于词对齐的论文，最近在reading group上主讲的《An Unsupervised Model for Joint Phrase Alignment and Extraction 》、《Feature-Rich Language-Independent Syntax-Based Alignment for Statistical Machine Translation 》、《Bayesian Word Alignment for Statistical Machine Translation》让我对词对齐任务有了进一步深入的认识。词对齐的根本目的是为了抽取短语，好的短语可以产生好的翻译。有人也在绕过词对齐，而直接作短语对齐。细数mt-archieve上的词对齐论文，几百篇的数量让人惊讶。

我想深入的学习词对齐这个点，力争在词对齐上有所突破后再向短语对齐方向努力，进而再结合解码过程中的特点来实现一种新型的短语抽取和解码过程直接相关的翻译系统。这个计划需要好好执行。

接下来的词对齐学习，我想就从Jorg Tiedemann今年5月刚出版的《Bitext Alignment》开始吧。153页的薄册子，希望能在半个月内能看完。给自己加油 :)

9月27，而立？！

今天是个特殊的日子，查了一下，居然发现历史上的今天居然这么多事情：

1961年9月27日――刘德华出生。

1971年9月27日――李亚鹏，中国男演员

1974年9月27日――许美静，新加坡歌手

1979年9月27日，世界旅游组织第3次代表大会确定每年的9月27日为世界旅游日

1991年9月27日，微软研究院成立。

1998年9月Google公司成立。Google官方确认的生日是9月27日。

补充几条：

1981年9月27日，俺出生了，感谢父母赐予我生命并养育我成人；还有我的两位好友（方天、姜晓飞）也是这一天出生的。

2011年9月27日，俺而立之年的开始，感谢诸位朋友（Paul, Devi, Wenliang, Xiangyu, Xinyan, Nancy, Yufeng）中午为我准备的生日Party，也感谢中华从南京带来的盐水鸭（中华是我指导的第一位实习生，今早初次见面）。还要感谢一大堆在网上送来生日祝福的朋友们。还要感谢我的太太，早上传统的生日煮鸡蛋和长寿面还是那么的美味。

人生步入了新的阶段，为了心中的梦想，为了新的十年，努力！

机器学习的特征工程应该是领域知识转换的过程

脚趾甲动完手术，今天上午最后一次去诊所。我告诉医生，因为走路包扎的纱布完全脱落过一次。医生说对于我这种小手术，他最喜欢听到这样的事情发生，因为那就意味着伤口附近的肿痛消失了。

这让我想到了机器学习里的特征抽取，很多时候特征不能乱想，应该有实际的意义，就像"纱布完全脱落"可以作为肿痛消失的特征。说到底，特征工程应该是个领域知识转换的过程，这样的机器学习才会有效有意义。

针对我正在做的机器翻译，我得学些人工翻译方面的书籍了。

冰糖蒸梨--润喉止咳化痰养生

冰糖蒸梨具有润喉止咳化痰之养生食疗功效，对于经常说话的人，例如教师，具有很好的滋养作用。

一、最简便的加工方法：将梨去核切块，冰糖撒于其上，隔水蒸5-8分钟。

二、最传统的加工方法：将生梨从中间一剖二，去核；将冰糖（加川贝粉效果更佳）放入 半个生梨心中，用牙签将两个半个生梨"恢复"原样；隔水蒸约一个小时。

三、最时尚的加工方法：川贝舂碎，雪梨去芯，切成两半。将所有材料放入炖盅，以慢火炖一个小时。注意，这个方法最时尚的地方在于，不是隔水炖，而是隔着红酒炖。在川贝和冰糖的渗透下，梨原本晶莹剔透的玉色会一点点地在红酒和火力的熏染下变成暗红，房间里慢慢地弥漫出混合着果香的红酒味儿，打开炖盅时，冰糖和川贝已经就着蒸汽和梨汁化了，里面一定是一汪稠稠的羹，那种烹饪的感觉是如此奇妙。

不弄清程序的上下文环境容易出错：针对Moses的tunning解决一个重要Bug

最近发现我在服务器上运行的moses的tunning偶尔会出现不能得到结果的现象，居然两次发现moses tunning出来的moses-tunned.ini缺少参数。这个问题似乎从来没有出现过，仔细的检查的moses的参数处理的perl脚本，居然发现原因是moses的tunning出来的weight可能有科学计数法，例如-6.62728e-05。但是reuse-weight.perl中在识别这些weight时都是默认为纯小数的，例如-6.62728。在不能匹配科学计数法的数字时自然就会丢掉某些weight，导致后续的测试程序出现问题。

这个Bug较为隐蔽，似乎接触moses的两年多来都没有遇到过，仔细想想，肯定是以前tunning的结果的weight都是纯小数，最近的一些语料上的运行才出现了这个对极小数采用科学计数法的问题。

通过修改Perl匹配小数的正则表达式，这个Bug解决掉了，程序终于能畅快的继续运行了。

这个小事，让我想到一个问题，那就是写程序的时候往往会出现对输入输出数据的相关假设，编程人员务必需要仔细对各种输入情况进行考虑，最好的方法就是编写各种各样的测试用例来保证结果的正确性。