聊天机器人为什么这么难？

首先，来明确一下讨论范围。



聊天机器人（chatbot 或 conversational AI）可以分成面向任务（task-oriented）的和面向非任务（non-task-oriented）两类。



面向任务的聊天机器人有明确的任务，比如设闹钟，比如订机票，比如推销房地产（误）。我们日常用到的 Siri 或 Alexa 大部分功能，就是这种。



对于它们，能让人在完成任务过程中的精神压力越小就越好：适应人类颠三倒四的思维，不多说不该说的话，不少说该说的话。



另一类是面向非任务的，简而言之，就是闲聊。对它们的评价标准，就跟与人聊天一样，能让人聊得越投入就越好。



当然这个边界也未必明确，比如闲聊的某一个阶段可能可以被分解成讲一个笑话、说一条新闻这样的小任务。



今天我们讨论的是后者。



张居正提出“考成法”时说：



若询事而不考其终，兴事而不加屡省，上无综核之明，人怀苟且之念。虽使尧舜为君，禹皋为佐，恐亦难以底绩而有成也。



在我看来，聊天机器人也正如吏治，目前的瓶颈是缺少了一个有说服力的自动化的测评方法。



最有说服力的方法自然是，找一堆人与聊天机器人聊天，然后打分。当然，这很昂贵。我读研究生时曾有幸在这种方式下开发、测评了聊天机器人，多亏了财大气粗、流量充沛的某赞助公司。饶是如此，也难以大规模比较和快速迭代。



因此，目前业内常用的一些评价标准，往往都是挪用自自然语言处理的其他领域的自动化方法，比如信息论的困惑度（perplexity），比如机器翻译的BLEU。它们能反映我们对好的对话的一部分要求，比如双方说的内容接近，比如句子本身通顺，但难以真的被作为黄金标准。



如果有这样一个智能的评价系统，给一段对话，能自动打出一个合情合理的分数，就好了。



我们当时刚好有大量与我们的聊天机器人的对话脚本和打分数据，就用机器学习训练了一个根据对话脚本打分的评价系统。最后的成品可以用来得到一些定性的观点，比如“对话越长，这个对话往往就更好”。但完全无法与真人的评分相提并论。



如果有这样一个更智能的评价系统，给一个聊天机器人，能自动生成无数段对话，然后打出分数，就更好了。



有人可能会质疑，要是真有一个自动化的方法来评价聊天机器人，这个自动化的方法本身岂不是也得要像这个聊天机器人一样智能？



这个问题可以从两个角度说。



一方面，这个自动化的方法可以不智能，甚至可以用人工。



人工的自动化方法？是的。



同样是面对变化万千的自然语言，让我们来看看信息检索是怎么解决这个测评这个问题的。



信息检索，也就是搜索，最典型的任务是根据一个意图（比如“了解黄石国家公园的历史”），给定一组关键词（如“黄石 历史”）作为输入，从一堆文章中，选最符合这个意图的几篇文章，按相关程度排好，返回。



我们只要事先找人标好，在这堆文章里，哪些最符合这个意图，就是一道测试题了。有了这道测试题，我们就可以比较各个搜索引擎返回的结果，哪个命中率高，哪个就更厉害。



一道题当然有运气成分，那就可以多出几题，就变成了一个测试集，甚至成为业界的锦标赛，比如TREC。



这个和单纯的手动打分有什么区别？



这个可复现。



单纯的手动打分意味着，每当有人新提出一个信息检索的算法，就得找人来打分。这既不经济，因为得重新花钱招志愿者来做实验；也不公平，因为不能保证他们的评分标准和之前的人一样。



而有了上述的测试集，只要跑一下就能与别人做比较了。



方便往往能激发无限的生产力。自动化打分方法的魅力在于，它可以反过来用这个分数来优化你的算法（“妈妈再也不用担心我的学习！”）——



在信息检索中，排序学习（Learning to Rank）就是最好的例子。一个搜索引擎像一辆变速自行车，调节几个旋钮就能改变它的性状。既然能几乎零成本地进行测评，我们就能反复调节它的无数个旋钮，调到能拿最高分的最佳状态。



但聊天机器人比信息检索难的是，信息检索中，用户的表现是判断检索出的文本是否满足查询的意图，相当于选择甚至判断题。但聊天是简答题，范围一大，数据就太稀疏了。



另一方面，这个评价方法怎么就不能像聊天机器人一样智能了？就像鸡生蛋蛋生鸡的问题，不管过程怎么头疼，我们今天想吃鸡就吃鸡，想吃蛋就吃蛋。聊天机器人或许能跟它的评价系统协同进化，螺旋式上升。



机器学习背景的朋友可能会联想到生成式对抗网络（GAN，generative adversarial network），它能通过让两个神经网络相互博弈进行非监督学习。



但还是那句话，人类对话的可能性太多，这个空间太稀疏。具体怎样做才能得到实际可行的结果，就要等未来的有识之士了！



自从毕业后就没太关注这个领域，只是近来闲聊聊起这个话题，有感而写。不尽不实之处，还请多指教。



本文首发于我的博客“青菜年糕汤”上。我每周会写一篇技术或非技术的原创博文，不定期选择性转发到InfoQ。想要第一时间读到完整的文章（如《五十年前的一桩公案：数据库关系模型的流行史》），不妨扫描博客中的二维码关注我的公众号。