深度｜打造聊天机器人：评估现有平台的优点和局限
选自：Tryolabs
作者：Javier Wed
参与：朱朝阳、Rick R、黄小天
聊天机器人（chatbot）行业仍然处于它的早期阶段，但正已惊人的速度增长着。起初看起来像是时尚或市场营销策略的聊天机器人正成为消费者真正的需要。你想知道你所在地区、附近的剧院正流行什么电影吗，或者看一个简短的预告片？你可以使用Fandango bot。你是NBA球迷吗，想获得比赛亮点和及时更新？或许你可以试一下NBA’s bot。关于食物或衣服呢，你见没见过现在有多少品牌有聊天机器人允许你能够轻松上网购买食物或者浏览衣物？
Fandango bot：https://www.facebook.com/fandango/
NBA’s bot：https://www.facebook.com/nba/
不可否认，聊天机器人的背后确实有市场营销的目的，但是如果聊天机器人达到了使用者的期望值，它们将成为许多使用场景里必不可少的工具。从技术巨头（例如谷歌、Facebook、微软、IBM和亚马逊）给予聊天机器人的重视程度就可看出这项技术在未来将扮演极其重要的角色。
现如今有巨多复杂程度、表达能力、集成能力各不相同的平台和工具供开发聊天机器人使用。让我们假设你想要开发一个聊天机器人。你面临的价值百万美元的问题是：在所有的平台里，哪一个最能满足我的需求？
去年我们在Tryolabs就聊天机器人方面做了许多研究，每一个新项目诞生时我们都会面临这个问题。在这篇文章中，我们会概述一些我们学习和测试过的平台。我们将会看到，取决于聊天机器人的使用场景，一些平台会比其他的更合适。我们还将会看到聊天机器人依然有提升空间，因为闪闪发光的并不总是金子，并且定制化的自然语言处理和机器学习组成部分将会用来达到我们想要的效果。
通用聊天机器人架构
首先要了解的是聊天机器人内部是如何工作的。基本是给定一个用户输入，聊天机器人就会返回一个响应。原理很简单，但实践起来就不那么容易了。
理解使用者的意图
假设你正问一个旅游机器人以下问题：
I want to fly to Venice, Italy from Paris, France, on January 31首先，机器人需要理解你的输入。有两种主要的技术来达到这个目的：模式匹配和意图分类。
模式匹配方法需要输入模式可能的列表，以上输入可能会匹配到如下的模式：
I want to fly to <CITY> from <CITY> on <DATE>
这种方法的好处就是模式可以被人类解读，所以对输入建模阶段以某种方式上说可以是直截了当的。问题在于模式是人工构建的：这不是一项琐碎的任务并且在一些真实使用场景里并不能很适用。
内容分类方法依赖于机器学习的技术。你需要一个样本集来训练一个在给定用户输入时能从所有可能的内容（例如，买票、检查航班状态、获取详细信息等）中选择的分类器。
在任何场景中，上述例子的城市和日期对于理解输入并返回一个合适的答案是非常关键的。聊天机器人可能会在数据库（或者在线查询）中查找在给定日期从威尼斯到巴黎的机票。因此，聊天机器人需要对输入进行信息提取来获得重要的实体：位置、航班、机场、日期等等。
对输入进行分类和从中提取信息是你需要时刻谨记的两个重要观念。
对用户反馈
一旦聊天机器人理解了用户说的什么，它能够基于当前输入和交流的情境选择或生成一个回复。
静态回复
最简单的方式是静态回复，对每一个用户输入，最终都会有不同的列表。这些静态回复可以是模板，比如The flight time is <ft>hours，<ft>是聊天机器人计算出的一个变量。
动态回复
另外一个不同的方法是使用资源（例如知识库）来获取可能回复的列表，然后对它们打分以选择更好的回复。如果你的聊天机器人主要是一个问答（QA）系统，那么这种方法就非常合适。
生成式回复
如果你有大的对话样本语料库，你可以用深度学习技术来训练一个在给定输入下会生成答案的生成式模型。你将需要百万级别的样本来达到一个比较好的质量，有时候结果也不可预判，但是测试这种方法看看能发生什么是很有趣的。这是一个不断发展的研究科目，有很大的研究潜力，非常激动人心。
不要忘了对话的语境
仅基于目前的输入还不足以提供给用户正确的答案。为实现聊天机器人的逻辑，对于语境的关注是非常重要的。例如，如果用户键入以下的输入:
How many bags can I bring with me?
聊天机器人仅能够在它知道票的细节时回答问题。典型来说，这种信息之前存储在了交流的情景中。当然，每一个聊天机器人必须对它自己的语境建模和决定记忆的重要信息。
现有平台
在你选择一个平台之前，你必须知道你要开发的是何种类型的聊天机器人——是面向目标的机器人，还是对话机器人，又或者是面向目标的有非常强的对话能力的聊天机器人？
一个面向目标的或者事务型的聊天机器人是商业出现频率最为频繁的一种聊天机器人。
交流类型的聊天机器人重点关注与用户的交流。它不需要深入理解用户说的什么和记住交流的所有情景，它只需要效仿一段对话。那么聊天机器人用来干什么呢？娱乐可以是一个原因，但是，比如说，你可以打造一个聊天机器人用以替代经典的FAQ，提供给用户更动态的体验。
讲清楚了这个，从现有的平台中我们能区分出三种家族:
面向对话的平台
由技术巨头支持的平台
这不是一个正规的分类而是分组或对平台编目录的方式。
非编程平台
它们是面向非技术人员的平台。通常来说，即使没有编程能力、没有机器学习或自然语言处理专业知识，也可以比较容易地编程一个聊天机器人。其中的关键思想是用户没必要担心技术细节。
有非常多的非编程平台，在这里把它们都列出来是不可能的。在Tryolabs我们已经测试了一些，知道了它们的优点和缺点：
Chatfuel：https://chatfuel.com/
ManyChat：https://manychat.com/
Octane Ai：http://octaneai.com/
Massively：http://www.massively.ai/
Motion.ai：https://www.motion.ai/
第一个要说的就是它们都是面向任务型的，最常用的例子是“订一份披萨”。我们发现即使第一眼看上去是非常相同，在成熟度、图形用户界面可用度和自然语言处理能力方面也有很大的不同。
优点
你可以快速开发一个聊天机器人
它们有一个很低的学习曲线
开发简单聊天机器人非常理想
缺点
不同程度不同稳定性的平台非常多。
有些时候图形用户界面并不很容易理解，而且当聊天机器人逻辑变化更复杂时，也难以驾驭。
上述平台没有或很少有自然语言处理的能力。例如，一些平台不能提取信息。因此，给定一个短语比如”I'm in Boston”，他们不能提取城市波士顿(wei zhi实体)存在这个事实(实体)。
对于一些复杂的聊天机器人来说他们不太合适。
结论
从我们的观点来看，非编程平台无法处理大型商业工程项目。交流不能非常复杂，而且通常来说集成外部资源比如自然语言处理和机器学习的特殊组件是不可能的。
然而，非编程平台对于小项目来说是非常好的选择，例如，经常快速地为脸谱页添加一个聊天机器人的功能。所以你可能想试一试看看它们能为你做什么。
对话平台
The main goal here is to allow the user to have a conversation with the bot, without considering a task-oriented scenario. These platforms typically use specification languages such as AIML (Artificial Intelligence Markup Language) to model the interactions with the user. The example below shows how to code interactions with AIML.
对话平台的主要目的是允许用户与机器人进行对话而不用考虑一些任务导向的情况。这些平台通常使用诸如 AIML（Artificial Intelligence Markup Language，人工智能标记语言） 等规范语言来模拟与用户之间的交互。下面这个例子展示了如何运用 AIML 来编写这种交互。
当用户说：“my dog’s name is Max”，聊天机器人就会识别该模式并提取狗的名字。必须指出的是，这种通过文本匹配进行信息提取的方式与 NLP（自然语言处理，Natural Language Processing）提取信息的能力比起来是非常简单的。聊天机器人会回复“That is interesting that you have a dog named Max”。随后，如果用户询问该狗的名字，聊天机器人就会回答“Your dog’s name is Max”。
这类平台中最著名的一个例子是 Pandorabots（http://www.pandorabots.com/）。
优点
AIML 是一个标准。
它创建对话非常灵活。
缺点
对于人工创建的模式， 用 AIML 难以进行扩展。
信息提取能力有限。
并不真正适用于面向任务的机器人
总结
虽然你不会去用这些平台创建一个聊天机器人来订餐或买票，但你会发现用它们来快速建模一个娱乐聊天机器人是非常有趣的，例如它可以取代常见问题解答（FAQ）服务并提供更好的用户体验。
科技巨头们建立的平台
这些平台由科技巨头公司所开发，并且不知何故，它们已经成为了一个标准，或至少正在成为一个标准：
Api.ai (Google)
Wit.ai (Facebook)
LUIS (Microsoft)
Watson (IBM)
Lex (Amazon)
这些巨头们试图同时拥有低学习曲线和强劲表现。
出于多种原因，在 Tryolabs我们将注意力集中于 Api.ai 和 Wit.ai。在我们的印象中，LUIS 和 Watson 提出了一个比我们所需要的更复杂（并且最终更强大）的框架。至于 Amazon Lex，我们写这篇文章时还未获得其有限的预览权限 。
我们不打算对 Api.ai 和 Wit.ai 做详尽的对比或去深入研究每一个平台，而是为你们提供我们的经验反馈。当你在建模一个聊天机器人时会立即明白，其中最难的部分之一便是建模对话流（conversation flow）。基本上是它定义了聊天机器人的行为。让我们看看 Api.ai 和 Wit.ai 是如何处理这个关键部分的。
Api.ai
聊天机器人的行为
意图（Intents） 和语境（Contexts）是使用 Api.ai 来塑造聊天机器人行为的重要概念。Intents 创建了用户的聊天内容与 bot 所应采取的行动之间的联系。Contexts 是字符串值，用于根据先前的请求来区分出可能含有不同意思的新请求。
总的说来，在 Api.ai 接收到一条用户请求，它首先会被分配去确定该请求是否匹配某个已知内容。Api.ai 提出用一个默认回退意图（“Default Fallback intent”）来处理不匹配任何用户意图（Intents）的请求。
Api.ai 接口
你可以通过指定一个激活的语境列表来限定一条意图的匹配。同时意图的匹配可以创建和删除语境。
在上面的例子中，当用户说“I would like to order a large pizza”，此请求所匹配的意图名为order，它可以创建一个名为ordering的语境。用户指明了披萨的类型、大小等参数后，你就可以创建一个名为 pizza_selected（保持 ordering 的context处于激活状态）的语境。然后，如果用户说：“What is the delivery time?”该机器人就会匹配一个名为get_order_info的意图，其前提是名为pizza_selected
的语境存在。
这一套意图&语境机制使得创建可建模大而复杂的 flow 的状态机成为可能。然而你无法建模这种情况——意图只有在某个语境不存在时才能被匹配。这是 Api.ai 目前的一个局限性，我们认为他们将很可能会致力于该问题的研究。
实体（Entities）
你可以定义自己的实体并使用平台推荐的实体。在上面的“order a pizza”例子中，比萨的类型和大小是用户定义的实体，而地址和数量是系统实体。
填槽（Slot-filling）能力
这是令 Api.ai 兼具灵活性和强大性能的一个关键因素。填槽允许你对给定的意图进行标示——哪些字段发挥作用以及它们是否为必填项。
有了填槽，你就不必亲自处理丢失的信息，因为这是在 Api.ai 端进行的。在上面的例子中，Api.ai 会询问每个必填字段直到它被用户填上：比萨的类型和大小、地址和交货时间。
你可以看到，“number”字段可能是意图的一部分，却不是必填项。
服务器尺寸编码
当然，要为你的聊天机器人定义完整的逻辑，你需要在服务器端添加一些自定义编码。Api.ai 提出了一种 webhook 集成，使编码变得非常简单。基本上，Api.ai 将来自一个匹配意图上的信息传递给网页服务器，并从中得到一个结果。一个非常有用的功能是：发送到 Api.ai 中的结果可以在文本和语音水平上改变语境和聊天机器人的回复，因此你不仅可以实施服务器端的逻辑，还可以在一定程度上修改聊天机器人端的逻辑。你可以决定让哪个意图来调用 webhook，以及是否要在填槽期间调用 webhook。该组合是进行聊天机器人行为定制化的一个强大而灵活的工具。
优点
Api.ai 提出了使用意图和语境的一种强大方法去建模大而复杂的流。
填槽是一个集成特性。因此可以通过聊天机器人去解决一大部分逻辑编码，从而减少了服务器端的编码工作。
域（Domains）可用，它是处理几个常见用例和应用程序（例如闲聊、常识、航班时刻表、提醒…）的规范。
提出用“Training” 单元（公测中）来利用案例训练聊天机器人。
若干平台的一个集成：Facebook Messenger、Slack、Twitter、Telegram...
缺点
无法于 context 存在时阻止 intent 的匹配。
训练区块仍处于公测中。
Wit.ai
聊天机器人的行为
使用 Wit.ai 塑造聊天机器人行为的关键概念是 stories。每个 story 都代表了一个可能的对话案例。应当指出的是，“intent”不再是一个概念，而是一个非强制性用户实体。这是对 Wit.ai 影响较大的一个改变，它出于这样一个事实，即一个复杂的聊天机器人需要很多能够以某种方式被划分为 stories 的 intents。
Bot 开发者基本上是通过举例的方式来教 Wit.ai。下面的思想是，当一个用户写了“相似的（similar）”请求时，Wit.ai 就会对其进行处理，提取实体并应用开发人员所定义的逻辑。
Wit.ai 接口
一个故事可以被看作是一个用户意图表。你可以添加分支，该分支由特定变量值的存在与否等条件所触发，并可从用户输入中提取。这允许你定义一个对话流。此外，你还可以使用书签机制在意图及故事之间跳跃。
你可以使用“Bot sends”命令（基本上是函数的调用）来与服务器端进行交互。有趣的是，你可以在一个短语中设置实体的角色。例如这句话“I want to fly to Venice, Italy from Paris, France, on January 31”，你可以规定说第一个城市是始发地而第二个城市为目的地。
实体（Entities）
Wit.ai 允许你自己定义实体或使用预定义的实体。
服务器尺寸编码
Wit.ai 提出了一种 webhook 集成：它将每个“Bot sends”命令中的信息传递到一个网页服务器中，并从中得到一个结果。通常你会在服务器端创建或扩展对话语境。发送到 Wit.ai 的结果可以对聊天机器人端所使用的情境变量进行添加、修改和删除。
优点
“故事”（story）这一概念很强大。
Wit.ai 允许使用分支和行动条件来控制对话流（例如，只在某些特定变量被定义时才显示此消息）。
为实体分配角色有助于服务器端的处理进程。
提出了“理解”（Understanding）单元来用样本去训练聊天机器人。
无法被聊天机器人处理的请求会被单独列出，那儿有一个“收件箱”（Inbox）供开发者训练机器人。
缺点
还在公测中。
即使 “故事”是一个很强大的概念，也存在难以控制对话流以及机器人倾向于误解用户请求的情况。
目前的限制：伴随自然语言处理（NLP）和机器学习（ML）的改进
正如我们已经看到的，尤其是对于 Api.ai 和 Wit.ai 来说，要塑造一个聊天机器人就需要提供逻辑和语言资源，后者主要是输入/输出短语与实体。而这对于小型聊天机器人来说应该不成问题，但如果你打算处理很多专业术语及短语变体，那么你就应该考虑使用自然语言处理和机器学习。我们来举几个这种情况下的应用案例。
单数和复数形式
如果你想让你的聊天机器人提取“pizzas”作为一个实体，那么仅仅定义“pizza”是不够的，你还需要提供“pizzas”。
Api.ai 有一个功能叫做“自动拓展（automatic expansion）”，而 Wit.ai 有称为“自由文本（free-text）”的实体。这些机制会尝试基于单词语境来捕捉新条目。所以如果你已经使用短语来训练你的聊天机器人，比如“I’d like to order a pizza”，那么它很可能会认为在“I’d like to order 3 pizzas”这句话中，单词“pizzas”是一个实体。不过该功能的准确性取决于训练过程，而你无法得知它会带来多大的干扰。
一个有把握的选择是为每个概念同时提供其单数和复数形式，可使用自然语言处理工具中的 inflectors 来生成它们。
同义词、上位词和下位词（概念上外延更广/窄的主题词）
假设这样一种情况，用户想要一瓶汽水，但你的聊天机器人只知道具体的名目，诸如可口可乐或百事可乐，它们是汽水的下位词。存在很多自然语言处理资源可以用来处理英语中的上位词、同义词和下义词，比如词库（Thesaurus）和本体（Ontologies），但它们通常针对的是一些通用语言。因此，可口可乐作为一个非常具体的域名，就不太可能属于这种资源。
你可以尝试去找到一个适合你的问题的现有词库，或自建一个词库。领域专家建立的资源价格昂贵但精确度高。你可以使用机器学习来创造语言资源，而深度学习技术则完全可以满足你的个人使用需求。
情感分析
你想为你的聊天机器人加入一定程度的情绪反应吗？那么，你可以尝试在服务器端执行情感分析来快速适应响应。
然而这个任务如果使用 Api.ai 或 Wit.ai 则难以进行。如果你想得到一个非常灵活且语料丰富的聊天机器人，或许你应该考虑从零开始进行开发。
总结/最后的思考
显然，聊天机器人呈上升趋势，而我们在 Tryolabs 目睹了其快速增长的需求。如果做对了，这条用户沟通渠道就能够为你增加订单机会、提供一个更好的用户体验以及节约成本。然而实现过程绝非易事。
目前有大量的平台可以帮助你创建一个聊天机器人。其中一些平台已经利用所获取的不同使用情况而被建立起来，所以很明显，根据你的聊天机器人所针对的业务情况，有些平台可能会比其它平台更合适你。为了帮助你挑选出最佳的工具，我们回顾了现有聊天机器人搭建服务方的一些优势及劣势。
如果你打算建立一个复杂的聊天机器人，那么你应该认真考虑一下稳定性、可扩展性和灵活性这三个方面。倘若你不够重视人类语言的复杂性，一次谈话很快就能偏离正轨。你可能需要从零开始建立自己的解决方案，或使用一个工具组合来解决一般的自然语言处理问题（即 Api.ai），以及为更强大的功能而选择自定义服务器端逻辑。
总之，聊天机器人生态系统发展很快，许多现有平台所发布的功能日新月异 。截至今天，很显然当你雄心勃勃地试图建立一个能够处理复杂对话并采取行动（即付款）的聊天机器人时，你不能 100% 地依靠平台，还需要定制化自然语言处理的发展。深度学习技术的最新进展可能在不久的将来会有很大帮助，我们对此非常期待。