【AI100 导读】虽然聊天机器人行业目前仍然处在起步阶段，但是其发展速度却非常快，现在也变得越来越重要。假如这些聊天机器人可以为广大用户带来便利，满足他们的期望，那么聊天机器人将会不可或缺。Google、Facebook、Microsoft、 IBM 以及 Amazon 等的科技巨头已经越来越看重聊天机器人了。本篇文章是对当下已经创建了聊天机器人的各个平台的分析。

虽然聊天机器人行业目前仍然处在起步阶段，但是其发展速度却非常快。最开始聊天机器人似乎只是一个噱头或者是营销策略，但是现在却变得日益重要，成为人类真正需要的东西。假如你想知道最近在流行什么电影，想知道附近有什么剧院，亦或是想观看某个预告片， 那么你可以使用一款名为 Fandango 的聊天机器人。假如你是一个 NBA 的球迷，想要了解比赛的看点与赛事安排，那么你可以使用 NBA 聊天机器人。同样的，如果你想知道关于美食与服装的信息呢？你又是否知道，当下诸多品牌都已经拥有了聊天机器人呢？这些聊天机器人可以帮助你订餐或从网上购买衣服。

不可否认的是，创建这些聊天机器人的动机确实是为了市场营销。但是，假如这些聊天机器人可以为广大用户带来便利，满足他们的期望，那么聊天机器人将会不可或缺。当下，诸如 Google、 Facebook、Microsoft、IBM 以及 Amazon 等的科技巨头已经越来越看重聊天机器人了，它们认为聊天机器人是一个重要的指标，未来将会起到至关重要的作用。

目前有大量的平台与工具可以用来创建聊天机器人。这些平台与工具的复杂性不尽相同，表现能力不同，集成能力也不同。假设你想要开发一款聊天机器人，那么接下来的这个问题将会价值一百万美元：在众多已有的开发平台中，哪一个平台最符合我的需要呢?

去年在 Tryolabs 我们进行了大量与聊天机器人有关的工作。每当我们开启一个新的项目时，都会重新考虑上面提到的那个问题。本文将会对其中的一些平台做出简单的概述，这些平台都是我们亲自研究并测试过的。聊天机器人的应用场景不同，所采用的最佳平台也将不同。正如那句谚语所说，闪光的不一定都是金子。我们的聊天机器人仍有不断提升的空间。有些时候，我们需要定制自然语言处理（NLP）与机器学习（ML）组件才能得到理想的结果。

通用的聊天机器人架构

首先，我们需要知道的是聊天机器人的内部工作机制。一般来说，用户负责提供输入，然后聊天机器人返回结果。原理很简单，但是实现起来却不是很容易。

理解用户的输入

假设你正在和一个旅游聊天机器人进行交互，你进行了如下的询问：

I want to fly to Venice, Italy from Paris, France, on January 31.

首先，聊天机器人需要理解输入的内容。对此，有两种主流的技术可以供我们使用：模式匹配与意图分类。

模式匹配方法需要一系列的输入模式。以上的输入内容能够与某种模式相匹配，例如：

I want to fly to <CITY> from <CITY> on <DATE>.

这种方法的优势在于：人类可以理解这种模式。因此，在一定程度上我们可以直接地进行输入建模。但是，采用这种方式的缺点是需要通过人工的手段来创建模式：这项任务是有难度的，在某些用户实例中进展的并不顺利。

意图分类方式依赖于机器学习技术。你需要一个样本集合来训练出一个分类器，该分类器会根据用户的输入，在所有可能的意图中进行选择。比如买票、查询航班状态、获取详细信息等等。

在任何一个案例中，例如上面所提到的案例，city 与 date 的概念对于理解输入的内容以及返回恰当答案的过程都至关重要。接下来，聊天机器人可能会在数据库中进行查询（或者在线查询），以找到在给定日期从威尼斯到巴黎的机票。因此，聊天机器人需要预先对输入的内容进行信息提取，以提取到那些重要的信息：地点、航空公司、机场、日期等等。

你需要谨记的是：输入分类与信息提取是两个关键性的概念。

对用户的应答

一旦聊天机器人理解了用户输入内容的含义，就可以根据当前输入的内容与会话的上下文选择或生成某种应答。

静态响应

最简单的方式是运用静态响应的方式来应对每个用户的输入，最终确定一个变体列表。这些静态响应可以是模板的方式，例如：The flight time is <ft> hours, 其中 <ft> 是一个变量，是聊天机器人计算得出的航班飞行时间。

动态响应

动态响应是一种完全不同的方式，运用某些资源（例如知识库）来获取一系列的响应，并对这些响应进行打分，以挑选出最佳的响应。这种方式特别适合问答系统的聊天机器人。

生成响应

如果你拥有对话方面的庞大语料库，那么就可以使用深度学习技术训练一个生成模型，即根据输入的内容生成相应的答案。你大概需要上百万个的例子才能达到比较理想的结果，有时这些结果也会出乎你的预料。但是使用这种方法是很有趣的。人们正在广泛研究这个课题，这个课题极具前瞻性，受到人们的追捧。

不要忘记会话的上下文

仅仅知道当前的输入内容，用户并不能得到正确的结果。要想建模成功，为聊天机器人建立起正确的逻辑思维，上下文的概念不容忽视。例如，一个用户输入以下文字：

How many bags can I bring with me?

假如聊天机器人知道票的详细信息，那么它就只会回答这个问题。一般来说，信息已经存在于会话的上下文中了。当然，每一个聊天机器人对于上下文概念的都有自己理解，并判断信息是否值得存储。

当下的聊天机器人平台

在你选择一个研发平台的时候，你要先弄明白你要创建的是哪个类型的聊天机器人。这是一个目标导向的聊天机器人？还是会话聊天机器人？亦或者是拥有很强会话能力的目标导向的聊天机器人呢？

在商业领域中，目标导向的聊天机器人，或者说是交易聊天机器人是最常见的聊天机器人。它协助用户完成任务，例如买票、订餐或者是获取详细具体信息。

会话聊天机器人的作用是与用户进行对话，它不需要深刻理解用户说话的内容，不需要记住关于会话的所有内容，只需要模仿对话就可以了。会话机器人的用处是什么？娱乐是一个方面，但是你也可以创建一个回答经典常见问题的聊天机器人。为用户提供更为动态灵活的回答。

在澄清这一点之后，我们将现有平台分为三类：

• 不需要编程的平台。

• 面向会话的平台。

• 由科技巨头支持的平台。

这并不是一个正式的分类，仅仅是其中一种分类方式或者说是分组方式。

无编程的平台

这些平台面向的对象是无编程技术的用户，即使你没有编程技术、机器学习或者自然语言处理的专业知识，你依然可以很轻松的创建聊天机器人。用户并不需要关心技术细节。

当下存在许多的无编程平台，我们在这里就不一一列举了。在 Tryolabs 中，我们测试了其中的一些平台，对它们的利弊有了大概了解，我们测试的平台包括：Chatfuel、 ManyChat、OctaneAi、Massively 以及 Motion.ai。

我们首先要了解的是，这些平台都是面向任务的，最常见的例子类似于“订购披萨”。我们发现，即使这些平台乍看起来非常相似，但其在成熟度、GUI 可用性以及自然语言处理能力上均存在很大的不同。

优势

• 可以快速创建一个聊天机器人。

• 非常容易掌握。

• 适用于简单的机器人研发。

劣势

• 平台众多，并且这些平台的成熟度不同，稳定性也不同。

• 有时候 GUIs 不容易被人理解，假如聊天机器人的逻辑变复杂的话，将会很难处理。

• 自然语言处理的能力很低或者干脆没有。例如，一些平台无法进行信息提取。因此，假如输入了类似“I’m in Boston”这样的短语，这些平台无法提取出“城市 Boston”（位置实体）的信息。

• 不适用于复杂的机器人研发。

结论

在我们看来，无编程平台不适合大型商业项目。会话不能太复杂，并且无法整合类似于 NLP 与 ML 的特定组件等外部资源。

然而，这些平台适用于小型项目。例如，将聊天机器人的功能快速添加到 Facebook 页面。你可以试着了解一下这些平台，看看哪些平台适合自己。

会话平台

该类平台的主要目标就是使用户可以和机器人进行会话，不需要考虑面向任务的场景。这些平台通常会使用规范语言来创建与用户进行交互的模型，比如 AIML（人工智能标记语言）。下面的这个例子将向我们展示如何使用 AIML 编码交互过程。

当用户说出“我家小狗的名字叫 Max”的时候，聊天机器人将会识别出该句话的模式，并提取出狗的名字。需要特别指出的是，假如我们使用 NLP 信息提取，那么这种文本匹配的方式将会十分的简单。接下来，聊天机器人将会回答“你小狗的名字叫 Max，真有意思。”稍后，假如用户向机器人询问自己小狗的名字，那么聊天机器人就能回答出“你家狗的名字是 Max。”

优势

• AIML 是标准的。

• 创建对话非常的灵活。

劣势

• 假如是手动构建模式，那么很难进行扩展。

• 信息提取能力受限。

• 并不适合面向任务的聊天机器人。

结论

你无法使用这些平台创建一个可以订餐或者买票的聊天机器人，但是却非常适用于快速创建娱乐性的聊天机器人。与此同时，由这些平台创建的聊天机器人可以回答经典问题，带来更好的用户体验。

科技巨头支持的平台

这些平台是由科技巨头研发出来的，在某种程度上已经成为标准化的存在。或者说，即将成为标准化的存在：

• Api.ai（Google，https://api.ai/）

• Wit.ai（Facebook，https://wit.ai/）

• LUIS（Microsoft，https://www.luis.ai/）

• Watson（IBM，https://www.ibm.com/watson/）

• Lex（Amazon，https://aws.amazon.com/lex/）

这些平台正在努力降低学习成本并尽可能的提高聊天机器人的会话性能。

由于各种各样的原因，在 Tryolabs 中，我们只对 Api.ai 与 Wit.ai 进行了实验。我们认为 LUIS 和 Watson 对于我们要进行的实验来说，是稍微显得有些复杂的框架（虽然最终效果更好）。至于亚马逊的 Lex，我们在写这篇文章的时候还不能访问 Limited Preview。

在本篇文章中，我们不打算详尽比较 Api.ai 和 Wit.ai 的方方面面，也不打算深入探索这两个平台，仅仅谈一下我们的体验反馈情况。在你打算创建一个聊天机器人模型的时候，你会立即明白，对话流的建模是其中最为艰难的部分之一，甚至可以说是最为困难的部分。一般来说，对话流的建模就是要定义聊天机器人的行为表现。接下来我们将介绍 Api.ai 与 Wit.ai 是如何处理这个关键部分的。

Api.ai

聊天机器人的行为

意图与语境是使用 Api.ai 对聊天机器人行为进行建模的关键因素。意图负责建立起用户输入与机器人所采取的行动之间的联系。语境是字符串值，根据先前的请求，用于区分可能有不同含义的请求。

一般来说，在 Api.ai 接收用户请求的时候，它首先要进行分类，以确定是否符合已知的意图。Api.ai 提出了“Default Fallback intent”概念，用来处理无法匹配用户意图的情况。

Api.ai 接口

你可以通过指定活动的语境列表，来限制意图匹配。与此同时，意图匹配既能创建也能销毁语境。

例如上面我们所提到的一个例子——“我要订一个大披萨”。这个请求匹配一个名为 order 的意图，该 order 会创建名为 ordering 的语境。当用户输入披萨的类型、大小等等信息的时候，你就可以创建一个名为 pizza_selected 的语境（同时，ordering 语境依然处于活动状态）。稍后，假如用户询问“配送时间是什么时候？”，聊天机器人会匹配一个名为 get_order_info 的意图，但是 get_order_info 的意图必须在 pizza_selected 语境存在的情况下才能生成。

这种意图与语境的机制，使我们可以创建状态机，该状态机能够模拟大型的复杂流。然而，当某个语境并不存在的时候，你并不能创建该语境下的意图。这就是 Api.ai 目前的缺陷。我们认为，Api.ai 未来很有可能会致力于攻克这一缺陷。

实体

你可以定义自己的实体，也可以使用平台提供的实体。上面我们所提及的“订披萨”例子当中，披萨的类型与大小就是我们自定义的实体，而地址与数量则是系统定义的实体。

插槽的填充能力

插槽的填充能力是 Api.ai 的关键之处，它使得 Api.ai 兼具灵活性与强大的功能性。针对给定的意图，插槽填充允许你来确定起作用的字段，并且可以决定是否为强制性的。

这是一种很好的方式。使用这种方式，你就不必去处理丢失的信息，因为它是在 Api.ai 端完成的。在上面所提及的那个例子中，Api.ai 会要求用户填写所有必填的字段：披萨的类型、大小、地址以及配送时间。正如你所看见的那样，“数量”字段可以是意图的一部分，但不是必须的。

服务器端编码

当然，如果你想为自己的聊天机器人定义完整逻辑，那么就需要在服务端添加一些自定义的编码。Api.ai 提出了一个名为 webhook 的集成方案，该方案使得服务器端编码变得非常简单。总的来说就是，Api.ai 将匹配意图的信息传递给 web 服务器，并从 web 服务器获得结果。其中非常有用的一个特性是：在结果返回给 Api.ai 后，该结果既能在文本水平也能在语音水平上，改变语境以及聊天机器人的响应。因此，你不仅可以实现服务器端的逻辑，你也可以在某种程度上改变聊天机器人端的逻辑。假如 webhook 在插槽填充处理期间被调用，那么你可以决定哪一个意图应该调用 webhook。我们可以使用这个强大而灵活的工具来定制我们的聊天机器人得行为。

优势

• 通过使用意图与语境，Api.ai 提出了一种模拟大型复杂流的强大方法。

• 插槽填充是一种集成特性，因此可以通过合理设计聊天机器人端的逻辑部分，来减轻服务器端的编码压力。

• 域是可用的，即这种规范可用来处理常见用例与应用（例如：闲聊、知识问答、航班时刻表、事件提醒……）。

劣势

• 假如存在语境，则不可以阻止意图匹配。

• 训练部分仍然处于测试阶段。

Wit.ai

聊天机器人行为

对于 Wit.ai，Stories 是对聊天机器人行为建模的关键概念，每一个 story 都代表着一个可能的对话样例。需要指出的是，“意图”不再是一个概念，而是一个非强制性的用户实体。这个改变对 Wit.ai 产生了更大的影响。之所以会提出这种想法，是因为复杂的聊天机器人需要大量的意图，而这些意图可以根据 story 进行分组。

总体来说，聊天机器人的开发者基本都是在根据样例来教导 Wit.ai。当用户输入“相似的”请求时，Wit.ai 会处理这些请求、提取实体并应用开发人员定义的逻辑。这一过程见下图：

Wit.ai 接口

每个 Story 都可以看成是一张带有用户意图的图表，你可以在诸如特定变量值存在或不存在的条件下添加分支，这些变量是从用户输入中提取而来的。这样一来，你就可以定义一个会话流。此外，还存在一个书签机制，该机制既可以用在意图之间的跳转，也可以用在 Story 之间的跳转。

为了可以和服务器端进行交互，你需要使用“Bot sends”的命令，用来调用函数。非常有意思的一点是，你可以在短语中设置实体角色。例如，在“我打算在一月三十一号从法国巴黎飞往意大利威尼斯”这句话中，你可以声明第一个城市是出发地，第二个城市是目的地。

实体

Wit.ai 允许你自定义实体，或者使用预定义的实体。

服务器端编码

Wit.ai 提出了名为 webhook 的集成方案：它将所有的“Bot sends”命令信息传送给 web 服务器，并从服务器端获取结果。在服务器端，你需要创造或者扩展会话语境。发送给 Wit.ai 的结果能够增加、修改、删除聊天机器人端的语境变量。

优势

• Story概念功能强大。

• 通过使用分支以及动作发生条件（比如，仅在定义了一些特定变量时才显示此消息），我们可以控制对话流。

• 分配角色到实体有助于服务器端处理。

• “Understanding”部分是使用例子来训练聊天机器人。

• 拥有“收件箱”，收件箱中列出了聊天机器人无法处理的请求，因此研发人员可以教导机器人。

劣势

• Stories仍处于测试阶段。

• 尽管Stories功能强大，但是并不适合那些难以控制对话流的案例。在这些案例中，我们创建的机器人很容易误解用户的请求。

目前的局限性：使用自然语言处理与机器学习进行改进

正如我们所了解到的，要想创建一个聊天机器人模型，我们需要提供逻辑以及语料库（主要的输入与输出短语以及实体）。Api.ai 与 Wit.ai 都需要使用这种方式。对于小型聊天机器人来说可能不是很困难，但是假如你要处理很难的术语以及拥有众多变量的短语，那么你就需要考虑使用 NLP 与 ML 了，下面我们将介绍几个比较有用的例子。

单数与复数形式

假如你想让你的聊天机器人能够提取出“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 的自然语言处理工具。

同义词、上义词以及下义词

假设用户询问苏打水，但是你的聊天机器人只知道具体的术语，比如说可口可乐或者百事可乐（这些都是苏打水的下义词）。同义词、上义词以及下义词都可以用英语的形式来进行处理，因为有很多的 NLP 资源可供使用。我们称这些资源为词库与本体。这些资源通常是一般性的语言。因此类似于可口可乐这种非常具体的领域术语来说，不太可能成为这种资源的一部分。

你可以尝试寻找用已存在的词库来处理你的问题，或者自己创建。由领域专家创建的资源虽然昂贵，但是非常准确。通过使用机器学习技术，特别是深度学习技术，你可以创建语言资源，这些资源对于你的实例来说足够的好。

情感分析

你想让自己的聊天机器人拥有一定的情绪反应吗？那么你可以尝试在服务器端进行情感分析，并采取相应的反应。

然而，仅仅使用 Api.ai 或者 Wit.ai 很难完成这个目标。假如你想有一个活灵活现的聊天机器人，那么你就需要考虑从头开始研发它。

结论

很明显，聊天机器人是大势所趋。在 Tryolabs 中，我们见证了对聊天机器人的需求正在快速地增长。假如处理得当，这种与用户交流的方式能够增加用户的参与度、给予用户更好的体验并能节省更多的成本。然而，训练出真正好用的聊天机器人是非常困难的。

目前有大量的平台可以帮助你创建聊天机器人。其中，有一些平台是根据特定的需求而创建出来的。因此很明显，你需要根据你的聊天机器人所要处理的业务，从中选出更适合自己的那些平台。为了帮助你挑选最好的工具，我们已经在文中总结了现有服务对于创建聊天机器人的优势与劣势。

假如你打算创建一个复杂的聊天机器人，你应该综合考虑稳定性、可扩展性以及灵活性等因素。如果你没有足够重视人类语言的复杂性，那么对话结果将会很差。你可能需要从零开始创建自己的解决方案，或者使用某种组合，即一般 NLP 问题解决工具加上定制的服务器端逻辑（该服务器端拥有更为强大的功能）。

总之，聊天机器人的生态系统发展迅速，大量的平台每天都会发布新的功能。截止到今天，仍然很明显的是，你要想创建一个功能强大的聊天机器人（可以处理复杂的会话并采取相应的行动，比如支付），那么你就不能完全依靠平台，你仍然需要考虑定制的 NLP。最近深度学习技术有了很大的进步，很有可能在不远的将来为我们带来巨大的帮助，我们都热切地盼望着这一天的到来。

本文作者 Javier Couto 是一名研究工程师，在行业和学术界的国际研究项目方面有超过12年的经验，获得了巴黎索邦大学的自然语言处理博士学位，目前是一位机器学习爱好者。

本文由 AI100 编译，转载需得到本公众号同意。

编译：AI100

原文链接：https://tryolabs.com/blog/2017/01/25/building-a-chatbot-analysis--limitations-of-modern-platforms/