MindMeld中文文档--2.构建会话应用程序的不同方法[Different Approaches for Building Conversational Applications]

构建会话应用程序的不同方法

数十年来，开发者和研究者们一直在构建聊天机器人等会话应用程序。多年来，人们考虑了许多不同的战略。随着最近语音和聊天助手的普及和广泛应用，标准的方法出现了，以帮助定义构建有用的，生产质量的聊天机器人的最佳实践。本节概述了当今构建会话应用程序的一些最常见的方法，并描述了每种方法的优缺点。

基于规则的方法

在过去十年机器学习取得进展之前，会话应用程序通常是使用基于规则的方法构建的。不熟悉机器学习的开发人员通常从基于规则的逻辑开始实现。现在，有一些软件框架(如BotKit或Microsoft Bot Framework)可以帮助开发人员建立和运行简单的对话服务–为宿主消息处理逻辑和管道提供框架，以便与各种bot客户机端点集成。它们简化了设置服务器进程来监听各种传入文本消息的任务，并简化了与Slack或Facebook Messenger等流行客户端集成所需的工作。
使用基于规则的框架，开发人员负责实现核心逻辑来解释传入消息并返回有用的响应。此逻辑通常由一系列规则组成，这个规则为匹配指定模式的信息并返回响应。由于基于规则的框架不提供人工智能解析或分类传入消息的功能，因此开发人员必须手工编写所有消息处理和交互的逻辑。即使是简单的应用程序，通常也需要数百条规则来处理典型会话接口中的不同对话状态。
基于规则的方法通常是构建和启动语音或聊天助手的基本演示最快的方法。然而，从演示版转移到生产版，总是会暴露出大量的极端情况，每一种情况都必须使用不同的规则来处理。规则之间的冲突金和冗余使得这项工作更加复杂。即使对于简单的应用程序，不断增长的规则列表也可能使得很快变得复杂。经验丰富的开发人员熟悉基于规则的方法的缺陷，通常选择下面讨论的更复杂的方法之一。

基于云的nlp服务

在过去的几年里，出现了各种基于云的自然语言处理(NLP)服务，它们都希望减少构建基本语言理解能力相关的复杂性。这些服务旨在没有机器学习或NLP专业知识的开发人员能够创建有用的NLP功能。所有这些服务都提供了基于浏览器的控制台，帮助开发人员上传和注释培训示例。他们还简化了启动一个基于云的web服务来处理和解析自然语言请求的任务。这些服务通常由大型消费者互联网公司提供，以吸引开发人员上传他们的训练数据，从而帮助服务商在此过程中改进自己的人工智能会话产品。目前可用的NLP服务包括Amazon Lex，Google’s Dialogflow，Facebook‘s wit.ai，Microsoft LUIS，和IBM Waton Assistant。
基于云的NLP服务为开发人员提供了一种相对简单的方法来构建会话应用程序，而不需要机器学习知识。因此，它们可以成为组装演示或原型的最快方式，这些服务中有许多都提供了预先训练过的模型，用于一些受欢迎的消费者任务，比如查看天气，设置闹钟或计时器，更新待办事项或发送短信。这使得它们非常适合那些只需要复制普通消费者域而不需要进行定制的应用程序。由于这些服务提供预训练模型通常复制了广泛使用消费者虚拟助手中免费的功能，那些打算利用预训练模型将自己的业务货币化的公司可能会面临一场艰苦的斗争。
对于那些需要构建一个复杂演示应用程序，需要不同于一般的，预先训练的消费者域以外模型的公司来说，基于云的nlp服务通常不是最好的方法。构建针对特定应用程序或领域的语言理解模型需要对成千上万个有代表性的训练示例进行训练。基于云的NLP服务主要针对那些不太可能拥有大量训练数据的开发人员，通常用于小的数据集和简单的定制模型。此外，大多数基于云的NLP服务只支持基本的NLP任务，如意图分类和实体识别。在典型的会话工作流中若要实现其它处理步骤（如实体解析，语言解析，问答和知识库的创建），留给开发人员，最重要的是，对于那些无法或不愿将用户数据上传到云服务提供商的公司来说，这些NLP服务通常不是一个可行的选择。

机器学习工具包

从事NLP和会话应用的机器学习研究人员通常依赖于通用的高级机器学习工具包。这些工具包提供了最新算法的访问接口，包括LSTMs、RNNs、CNNs等深度学习模型。流行的机器学习工具包包括谷歌的Tensorflow和微软的Cognitive Toolkit。
对于机器学习的研究人员来说，这样的工具包是必不可少的，也是当今许多前沿人工智能研究的基础。但是，对于希望部署会话服务的公司来说，工具包通常提供不了什么帮助。首先，尽管它们提供了对最先进机器学习算法的访问，但对应用程序提供的代表性训练数据很少或没有，这使得开发人员自己去做所有创建和管理培训数据相关的繁重工作。其次，虽然算法可以访问低层次和深层的，但是没有简化构建会话接口任务的高级抽象。因此即使是最熟练的机器学习工程师也很少能够成功地使用当今的机器学习工具包构建出高质量的会话应用程序。

会话AI平台

在过去几年，随着会话应用程序的兴起出现了一种新的技术，面向需要创建高质量会话体验的公司和开发人员。会话式人工智能平台是为创建会话应用程序（如语音或聊天助手）的任务而优化的机器学习平台。在提供传统机器学习工具包的灵活性和高级功能的同时，也特别适合简化构建生产会话接口的任务。MindMeld被广泛认为是一个领先的AI对话平台。
AI对话平台不同于纯粹的机器学习平台，因为它们提供了在典型的会话工作流中为机器学习步骤设计的工具。例如：意图分类，实体识别，实体解析，问题回答和对话管理等工具是AI对话平台中常见的组件。与基于云的NLP服务不同的是，AI对话平台是为熟悉数据科学最佳实践的机器学习工程师设计的。因此，AI对话平台提供了更先进的工具和更大的灵活性通过大型训练集来训练和分析自定义语言理解模型。与基于云的NLP服务不同，会话人工智能平台不需要将培训数据上传到共享的云基础设施。相反，它们提供了一个灵活和通用的平台，确保数据集和训练模型在本地管理，并始终保存应用程序开发者的知识产权。

过好才算好

有这么多种方法来构建会话应用程序，公司很难知道哪种方法是最好的。最优方法是超过用户体验的性能阙值。确定这个可接受的基线水平可能是一项特别令人困惑或艰巨的任务。
会话接口对于许多在Web或本机应用程序方面有经验的开发人员来说代表了一种新的用户界面范例，这种范例是不熟悉和不直观的。与传统的GUI相比，会话界面是不可被原谅的。在一个传统的GUI中，视觉元素提供了一种机制来引导用户通向积极体验的交互路径。对于会话接口，没有这样的视觉指南存在。相反，用户通常会看到一个麦克风按钮或一个文本提示，并期望从头找出如何用语言表达所需的请求。面对如此开放的提示和如此少的上下文，许多用户会不知所措。更糟糕的是，用户往往会提出一些系统设计时没有考虑到的问题，导致结果徒劳无功，令人沮丧。
第一次构建会话接口的开发人员常常试图遵循它们从构建传统GUI中了解到的知识。这意味着通过构建一个最小可行的产品（MVP）来捕获设想功能的一小部分，然后将MVP提交给用户测试。对于会话接口，这种方法几乎都失败了。通常将训练数据的子集来构建会话最小实现接口。例如，考虑使用训练数据的１０％构建MVP，这个程序只能理解用户调用应用程序时使用的１０％种典型语言变体。因此，当提交应用程序进行用户测试时，十分之九的用户将在第一次请求时失败，这种糟糕的表现可能很快为你的项目敲响丧钟。
事实证明，快速而粗略的原型和有限规模的用户测试在评估会话应用程序的效果方面不是特别有用。准确度量性能的唯一方法是大规模的分析来确定度量可能的用户交互的长尾性能，这种衡量方法正是Siri、Cortana、Google Assistant、和Alexa等流行的商业虚拟助手所依赖的衡量方法。这种方法首先需要有足够多的“ground truth”数据集来反应所有可能用户交互模式中的最大份额。其次，它需要自动测试，使用“ground truth”数据，以确保足够高的用户查询百分比返回一个可接受的响应。
用户在评估会话接口时是不宽容的，他们希望把要求说出来，就像和别人说话一样。然后他们期望系统能像人类一样准确地做出反应。这通常意味着会话应用程序必须近乎完美。在实践中，当一个会话界面不能达到95%的准确率时，用户可能会认为该程序是愚蠢的，便不再会使用它。
请遵循以下指导原则，以确保您的会话接口符合会话应用程序的独特特征，并在投入使用之前满足可接受性的最低阈值。

1	选择一个熟悉的真实交互用例，以便用户直观地知道要问的问题的类型。选择一个不现实或不正确的用例，即使是最聪明的应用程序也会崩溃。
2	生成足够大的"ground truth"训练数据集，以确保能够捕捉和测量绝大多数用户交互。
3	使用大规模分析来确保您的应用程序在可能的用户交互长尾中获得至少95%的准确性。抽查和小规模用户测试不能暴露出可能严重损害到整体准确性的长尾情况。