实用Bot开发指南：基于Node.js与Bot框架设计并构建聊天机器人
Practical Bot Development: Designing and Building Bots with Node.js and Microsoft Bot Framework
［美］ 西蒙·罗兹加（Szymon Rozga） 著
陶 阳 董晓宁 吴吉庆 译
第1章
聊天机器人概述
最近几年，聊天机器人（chat bot）及人工智能（Artificial Intelligence，AI）成了科技行业的热门话题和大众最感兴趣的内容之一。聊天机器人是使用自然语言进行交互的计算机程序。它们正在做越来越多的事情，从预定比萨到买衣服，再到停车罚单申诉、谈判等。最初，开发一个聊天机器人和开发带有消息平台的系统一样，没有简单的方法来代表代码中的对话流。但当微软创建了Bot框架和Bot Builder SDK时，这种情况发生了变化。微软为开发者创建了一个丰富的开发环境，该开发环境使开发者得以从与各独立通道集成的关注中解放出来，并专注于编写执行聊天机器人需要完成的对话任务的代码。微软提供的Bot Builder SDK提供了一种开发对话体验的通用方法；Bot Connector实现了把通用消息格式转换成特定通道的业务逻辑。
这也使聊天机器人开发对广大开发者来说变得更加容易和便捷。工程师不再需要了解输入输出与诸如Facebook的Messenger API或Slack的Web API之类的开发接口进行集成的细节。相反，开发人员只需专注于核心的机器人逻辑和对话体验，其余的事情由微软提供的开发工具来解决。
Bot Builder SDK支持.NET和Node.js，并且以MIT开源软件许可协议在GitHub上开发维护。微软的机器人开发团队在版本开发以及响应开发者提出的各种问题方面非常积极活跃，同时他们对新手非常友好。
2017年12月，微软宣布Bot框架和语言理解智能服务（Language Understanding Intelligence Service，LUIS）在Azure门户对开发者公开发布。LUIS是微软提供的自然语言服务，它使开发者开发的机器人能够理解自然语言，具备对话方面的智能；Bot框架现在也称为Azure Bot Service，二者含义相同。顾名思义，Azure Bot Service现在是Microsoft Azure云产品的成熟部分。此外，微软还提供了免费的服务层次，因此我们可以根据自己的内容来使用框架。本书所有的样例和技术都可以在Azure上免费试验。
过去几年，微软、Facebook、Google等科技巨头以及很多小型公司一直在致力于创建最好且最易于使用的聊天机器人开发框架（chat bot development framework）。可以看到，这个领域的变化性很强，各种框架来来去去，似乎日新月异。然而尽管领域一直在动态变化，微软的Bot框架始终是开发功能强大、快速且灵活的聊天机器人的最佳平台。我很激动能带大家使用此工具进行聊天机器人开发之旅。
1.1 对机器人的期望
两年多以来，我与客户的大部分沟通都集中在讨论机器人功能，它们是什么以及（尤其重要的是）它们不是什么。事实上，当前的现状是人们在很大程度上可能会把聊天机器人的能力与人工智能混淆。原因很容易理解：一些聊天机器人使用丰富的自然语言功能，这使人们对它们有更高、更多的期望；此外，基于语音的数字助理（如Cortana、Alexa和Google智能助理）出现在人们的家中，并且人们会将其当作真人来进行对话。那么，聊天机器人为什么不能展现出更多的智能呢？
除此以外，相关新闻也激发了人们极大的兴趣。比如，IBM的Watson在美国著名的益智问答电视节目《Jeopardy》上进行挑战；谷歌大脑（Google Brain）团队在语言翻译方面使用深度学习所取得的成绩登上了《纽约时报》专题；自动驾驶技术；AlphaZero仅使用四个小时学习如何下国际象棋便打败了世界第一国际象棋引擎Stockfish。
这些新闻加大了社会对这些技术的投资和兴趣，也预示着我们正走向人工智能驱动的人机交互方式。AI领域的技术发展改变了我们的交互方式，同样改变了我们对技术的期望和要求，为设备赋予人的属性和能力变得越来越普遍。科幻小说家阿西莫夫的“机器人三定律”是机器人遵守的一套可以确保机器人友善待人而不会追逐伤害人类的规则，认知和科幻领域中的思想家一直在努力解决该定律所述内容的可能性。目前在现实世界中已经有一些明确而具体的人工智能实例，我们离科幻小说里的那种现实似乎更加接近了。
然而，现实与人工智能在一些非常具体的问题领域所取得的成就并不相符。尽管我们已经在自然语言处理、计算机视觉、情感检测等方面取得了巨大飞跃，但我们还没有把握将这些技术组合在一起来形成一个类似人的智能，即通用人工智能（Artificial General Intelligence，AGI）。同样，让聊天机器人实现通用人工智能也不是一个切实可行的目标。对于每一篇庆祝人工智能领域巨大成就的文章，都有一篇相关的文章对该技术的炒作进行了抨击，并且举出实例说明为什么这种类型的AI距离完美、通用的人工智能依旧任重而道远（比如那篇展示计算机视觉算法在文中所有实例图像上均无法正确分类的文章）。因此，对于任何被媒体炒作的技术，我们必须为其设定合理的期望和要求。
机器人在和用户对话时能达到具有人类水平的智能吗？答案是不能！给定相应的技术和任务，机器人可以很好地完成这些任务吗？答案是当然可以！本书旨在为读者提供必要的技能，以构建引人注目、引人入胜且有用的聊天机器人。工程师可以自己决定在开发聊天机器人的过程中加入多少最新的AI技术。不过，这些技术对于一个好的聊天机器人来说也不是必需的。
1.2 什么是聊天机器人
在最基本的层面上，聊天机器人（在本书后续内容中简称为机器人）是一种计算机程序，可以将用户的自然语言作为输入并将文本或富媒体作为输出返回给用户。用户通过消息传递应用与聊天机器人交流，比如Facebook Messenger、Skype、Slack等；或者通过语音唤醒设备进行交流，比如Amazon Echo、Google Home以及由微软Cortana提供支持的Harmon Kardon Invoke等。
图1-1展示的是我们使用微软Bot框架构建的第一个机器人。该机器人在输入信息前加上“echo:”前缀，再返回给用户，在Bot框架上可以轻松实现这种像Hello World一样简单的业务。
这个机器人非常基础，而且没什么功能。我们可以继续创建一个Youtube机器人，它接受用户的文本输入，搜索该主题的视频，并将视频的链接返回给用户（如图1-2和图1-3所示）。
和图1-1的机器人一样，Youtube机器人只能做一件事，也非常基础。它的逻辑是通过与YouTube API集成，将用户的文本输入用作搜索参数，然后将Bot框架中称为卡片（card）的内容返回给用户，我们将在本书的后面部分对此进行探讨。给用户提供图像可以使应用更丰富、更具吸引力，这些应用很有趣，但依然非常基础。
Youtube机器人的代码实现如下，它向Youtube发送请求，并将接收的响应从YouTube格式转换成Bot框架的卡片格式。
我们还可以继续创建第三个机器人，给定一段陈述，它能区分出这段陈述是中性的、积极的还是消极的，并进行相应的应答，如图1-4所示。这个机器人和前面两个例子一样简单：我们调用情感REST API获取情感得分值，并使用该得分值作为答案进行应答，该机器人的实现代码不再赘述。
根据该示例可以看出，在机器人中集成AI是一件容易的事。另外，机器人不必拘泥于提问-应答模式（question-response pattern），也能主动和用户沟通，比如我们可以创建一个欺诈报警的机器人，如图1-5所示。
机器人可以更多地由任务驱动。例如，日历机器人可以创建约会、查看是否有时间、编辑或删除约会，并将用户的个人日历进行归纳总结，如图1-6所示。
上面的例子都是一些简单任务，下面我们将把自然语言理解功能纳入到机器人中。
1.3 为什么是现在
为什么机器人现在变得越来越重要？其实，在以前的应用程序中就存在机器人的影子，比如IRC和美国在线（AOL）的Instant Messenger。IRC机器人诞生时间比较早，我也在IRC上试过与很多机器人进行交互。由于当时在技术方面积淀不深，我最初认为有一个真实的人回应我的信息，但我很快意识到是一个程序在答复我写的东西；和IRC机器人交互得越多，我越觉得这种交互就像是在执行某些命令行操作。然而，这在当时都是非常小众的技术，并且人们也不需要每天都和机器人交互，因此当时的机器人根本没必要满足能用自然语言进行交互的需求。
现在，新技术带来了与以前完全不同的交互方式，新技术主要有以下三种：AI技术、将消息应用程序（messaging app）作为智能对话平台的理念，以及语音唤醒的对话接口。
1.3.1 人工智能取得的进步
纵观整个20世纪，计算机科学家、生物学家、语言学家和经济学家在认知、人工智能、人工生命、机器学习和深度学习等领域取得了巨大进步。用计算机程序执行计算机指令的概念，通用图灵机（Universal Turing Machine），存储代码并通过接收输入和产生输出来执行代码的计算机体系结构的思想，以及冯·诺依曼体系结构，这些都是人类历史中的新兴“标准”，但也是我们利用计算机进行工作的基石。1943年，McCulloch和Pitts在论文“A Logical Calculus of the Ideas Immanent in Nervous Activity”中首次发表神经网络（neural network）的思想。1950年，科幻小说家阿西莫夫在小说《我，机器人》中从想象的角度总结了“机器人三定律”。同年，第一篇描述计算机如何下象棋的论文“Programming a Computer for Playing Chess”发表了，论文作者Claude Shannon同时也开创了信息论这一计算机学科领域。1960年以来，计算机科学研究中所取得的进步令人兴奋，从媒体封面对最新AI应用的报道就可见一斑。
自1960年以来，机器学习和使用算法构建模型的特性都得到了提升，并且更加可用；Python机器学习库scikit-learn和谷歌Tensor Flow的开发者社区活跃度非常高，文档支持十分完善；科技巨头公司在提升计算能力方面不断加大投入，以保证能用可接受的合理时间完成一些计算密集型任务；Microsoft、Amazon、Google、IBM通过不同的方式投入云平台的建设中，并且下一步在云上提供机器学习算法。比如在编写本书时，微软认知服务（Microsoft Cognitive Service）仅提供30多个API供开发者调用。开放的API包括人脸识别、情感检测、内容审核、光学字符识别（OCR）等计算机视觉工具，也包括诸如自然语言处理、语言和文本分析、自然语言理解等工具，甚至还包括推荐引擎（recommendation engine）、语义搜索（sematic search）等检索和知识理解工具。开发者通过合理的成本就能接入微软认知服务、实现更强大的功能，这种可用性使得目前的智能系统在大众的生活中越来越普遍，同时也是我们在开发机器人时利用的最重要的底层基础设施。我们将在第10章介绍微软认知服务。
1.3.2 作为智能对话平台的消息应用程序
移动消息应用近年来非常流行和普及，Snapchat、Slack、Telegram、iMessage、FB Messenger、WhatsApp以及微信（WeChat）成为用户手机移动端上最常用的应用程序，它们的使用率甚至超过了像Facebook这样的社交网络。Business Insider分析显示，移动消息应用的使用率在2015年第一季度首次超过社交网络，并持续至今。我们也发现亚洲的消息应用程序（如微信和LINE）已经找到了通过聊天应用增加使用率的方式，以及从流量中获利的方式；Apple、Twitter和Facebook等公司通过向开发人员开放开发者接口甚至集成支付功能等方式一直在引领潮流。总体而言，开放消息平台访问接口的趋势十分流行。
在消息平台上托管机器人可以吸引更多开发者加入；应用程序开发需要考虑用户体验（UX），而机器人开发者不需要像移动应用开发者那样关注内存管理、UI动画交互等内容，只需关注机器人和用户之间的对话即可。值得注意的是，机器人并不仅仅包含文本信息交互，还包括图像、视频、声音以及调用其他命令的按钮等内容。机器人的对话受消息平台所支持的功能的限制，微软的Bot框架中集成了必需的开发组件，可以最大化利用消息平台支持的功能。
1.3.3 语音唤醒的智能助理
另一个使对话智能迅速兴起的原因是语音唤醒设备的快速发展。虚拟语音助理Siri于2011年由Apple推出，现在早已家喻户晓，它由Dragon NaturallySpeaking这一最著名的桌面语音识别系统支持。该系统由Nuance开发，以帮助Siri实现“语音-文本”转换。
Siri是第一个进入市场的语音助理，并推动了其他科技巨头的参与热情。微软在2014年发布了语音助理Cortana（微软小娜）；同年，亚马逊推出Amazon Echo。Cortana最初仅在Windows Phone和Windows系统上发行，后来移动端甚至Xbox也都可用；亚马逊的Echo采用Alexa语音助理，是第一款成功商业化的语音硬件设备，亚马逊由此主导了早期语音助理的市场。在随后几年，Facebook和Google分别推出了M（已经于2018年初关闭）和Google Assistant。Google同时推出了Google Home并加入到语音设备市场的争夺战中。Harman Kardon发布了由Microsoft Cortana支持的语音设备Invoke。还有更多的公司正在持续地进入语音设备的市场，进一步推动技术创新。
语音助理市场之所以活跃是因为人工智能、语音识别、自然语言处理、自然语言理解技术发展迅速。这些技术为在消息平台上创建自定义功能提供了标准、框架和工具。我们会在后文中看到，这些自定义功能均可以在机器人中实现。
1.4 创建聊天机器人的动机
我们为什么要编写机器人，并且使用消息应用程序作为对话平台？我们明明可以编写一个移动应用程序，然后发布到应用程序商店，这样不可以么？因为用户的行为中存在各种倾向，所以这种方法不可行。
对于一些广为使用的事务，下载相应的应用程序自然是最快捷的方式。比如，想使用Facebook可以直接下载该应用程序；想查阅邮件可以直接下载邮件应用程序。但是，对于一些轻量级的事务，比如用户想了解附近花店的一些信息，此时根本不需要一个专门的应用程序来做这件事，为每个单一的事务下载一个应用程序对用户而言是不可接受的。显然，只需要向花店致电或者发送短信就足够了。
很多公司的业务中包含了B2C。以Facebook为例，一家当地花店可以注册一个Facebook主页，并在主页上发布消息，业务员可以对某一客户的查询请求做出回复；无独有偶，Twitter则对外提供了全新的Direct Message API，它为Twitter带来了巨大的商业价值。这种不需要下载应用的方式让业务更简单、快捷，机器人就是这种免下载免安装模式，消息平台在这个过程中负责用户识别、身份验证、整体应用稳定性等。
机器人同样改变了其他用例场景，比如效率工具Slack。Slack是一个出色的工作协作平台，能够让大家在不同的聊天主题中交流和协作。机器人可以让Slack更加高效，图1-7展示了Slack平台上一些排名靠前的机器人，这类机器人专注于工作中的任务，比如待办事项、站会（站立式会议）、任务分配等。显然，如果工作团队完全使用Slack来沟通协作，那么将普通的工作任务交给机器人去做可能比创建专门的网站去做更加高效。
虽然Slack的列表中包含一个名为Bots的特定类别，但事实上所有这些应用程序都是机器人。其中一些可能更擅长对话，而另一些则可能给人以更多的命令行感觉；就我们而言，机器人只是在听取消息并对其采取行动。针对比较擅长对话的聊天机器人，自然语言理解的内容以及与理解人类语言有关的学科，对用户体验来说至关重要。因此，我们将第2章和第3章专门用于探讨这项内容。
1.5 机器人的组成
我们将机器人的开发分解成独立的部分。在下面的介绍中，本书采用在开发时最常使用的概念进行描述，并重点介绍在微软Bot框架中开发机器人的方式。具体包括以下内容：
- 机器人运行库
- 自然语言理解引擎
- 对话引擎
- 通道集成
1.5.1 机器人运行库
最基本的，聊天机器人是一个响应用户请求的Web服务。尽管集成的消息平台有所差异、实现细节有所不同，但核心思路是相同的：都是消息平台通过HTTP端点来调用机器人，并在消息中包含用户的输入。机器人处理收到的消息，并做出响应，响应消息中包含了附件内容和与消息平台相关的数据。图1-8描述了一种通用的处理方法。依据消息平台的特点，用户可能会收到对应的异常，异常里包含HTTP状态代码或其他异常代码。机器人处理消息时，通过调用通道（channel）的HTTP端点来响应。然后，该通道将响应消息传递给用户。
图1-8中所示方法的缺点在于它将机器人局限于一个特定的消息发布通道。实际上，我们希望开发的机器人具有与通道无关的特性，以便最大限度地重复使用机器人中的逻辑。Bot框架通过在消息平台和机器人之间提供一个通道连接器（channel connector）服务来弥补该缺点，因此实际应用中的交互过程更像如图1-9所示的过程。可以看到，通道连接器掌管了机器人与消息平台的连接、通信，并将消息转换成机器人可以识别的通用数据格式。我们将在1.5.4节对通道进行更为详细的介绍。
由于机器人运行库本质上就是一个监听HTTP端点请求的程序，因此开发者可以使用任何允许我们接收HTTP消息的技术来开发机器人，比如.NET、Node.js、Python和PHP。尽管连接器为开发者提供了开发便利和优势，并且开发者可以自由地选择实现HTTP端点的方法，但是我们可以继续使用Bot框架的另一个组件Bot Builder SDK，以使开发更便捷。我们将在1.5.3节介绍Bot Builder SDK。
1.5.2 自然语言理解引擎
由于人类的语言是非结构化的输入数据，语言内容非常灵活并且没有一致的规则，因此编写一个能理解人类说话内容的机器人是一项非常具有挑战性的工作。机器人要具备可用性就必须能接收人类的语言输入并理解语言内容。自然语言理解（Natural Language Understanding，NLU）引擎可以帮助开发者解决理解自然语言过程中的两大问题：意图分类（intent classification）和实体抽取（entity extraction）。
下面通过一个例子来说明意图和实体是什么。假设我们要开发一个恒温控制机器人，并且设定四个动作：开关打开、开关关闭、设置模式（制冷或加热）、设定温度。用户语言中描述的这四个动作类型就是意图；而其所处的模式（冷、热）和温度值就是实体。自然语言理解引擎支持开发者自定义一系列与机器人应用相关的意图和实体。表1-1列举了一些典型的“语言-意图-实体”映射的例子。
显然，我们的代码更容易处理基于意图和实体实现的逻辑关系，而不是直接基于原始的用户语言。
机器人开发者可以通过多种服务实现自然语言理解功能。目前，许多云端API都提供了自然语言理解功能，如LUIS、Wit.ai和Dialog f?low等，其中LUIS是我们认为提供功能最为丰富、性能表现最好的，第3章将深入探讨自然语言理解的主题。
1.5.3 对话引擎
在构建机器人时，我们通常会设计一个工作流程来实现我们想要机器人完成的任务。比如，接着上面恒温控制机器人的例子，它的架构和逻辑如图1-10所示。
机器人的工作流程总是从监听用户的自然语言输入开始，用户说出的话语将被解析成表1-1中的意图：如果意图是“开关打开”或者“开关关闭”，那么机器人就能正确地执行逻辑，并且响应一个确认信息；如果意图是“设定温度”，那么机器人会验证温度实体是否存在，如果不存在则会请求一个温度值（即实体），在用户用语言输入温度值之后，机器人同样会正确地执行逻辑，并且响应一个确认信息。“设置模式”和“设定温度”的逻辑相似，因为它同样会验证实体的存在性，并且在不存在的时候向用户请求实体。
在聊天机器人中，对话就是机器人对用户的输入做出响应；对输入、输出和转换的类型进行设计的过程称为对话体验设计（conversational experience design），我们将在第4章深入介绍该部分内容。
对话引擎负责监听输入消息、处理消息，以及执行两个对话节点之间的转换。对话引擎独立处理每个用户的消息输入，并且存储用户的对话状态，在用户下一次发起对话时可直接查询到用户的对话状态。微软Bot框架在Bot Builder SDK组件中提供了性能优秀的对话引擎。
旁白：意图、实体、行动、老虎机，哦，我的天！
机器人的开发方法可以总结为两类：机器人引擎和机器人对话即服务（bot conversation as a service）。机器人引擎方法在前文已讲述过：我们将机器人作为Web服务运行，根据需要调用NLU平台，并使用对话引擎将消息传递给对话框。下面讲述机器人对话即服务的方法，该方法得到了Dialogf?low之类的广泛推广。机器人对话即服务方法将NLU解析、对话映射（conversation mapping）等流程全部集成在云端Dialogf?low的基础设施上，然后，Dialogf?low调用机器人来修改响应或与其他系统集成。
用户的语言映射到意图和一系列定义的实体上的过程称为动作（action），一个动作包含一个意图和一系列动作参数。再次回到恒温器机器人的例子中，我们可以定义一个“SetTemperatureAction”的动作，该动作包含一个“SetTemperature”意图和一个“Temperature”实体。当Dialogf?low解析一个动作时，它可以调用机器人来执行动作。在第二种方法中，对话引擎的功能被外包给NLU服务，机器人在这种方法中更加关注NLU服务的执行逻辑。
机器人对话即服务的机器人开发方法的一个关键内容是插槽填充（slot f?illing）。插槽填充是一个过程：一个服务会检测到动作（意图和动作参数）仅被用户输入填充了一部分，并自动地要求用户填充未被填充的剩余部分—动作参数。表1-2和表1-3展现了两个动作示例。
图1-11描述了用户、消息平台、连接器、NLU服务以及机器人这一完整的端到端流程，机器人在该对话中为服务模型。
机器人对话即服务的开发方法运行更快，但灵活性稍差，使用Bot框架可以让我们掌控机器人引擎，从而解决这些问题。
1.5.4 通道集成
构建机器人时要考虑与多种消息平台进行集成。举个例子，你的老板让你负责编写一个Facebook Messenger机器人，你完成并发布了它，老板为你的工作喝彩，但接着又提出了新需求：“能否把这个机器人作为网络聊天机器人嵌入到公司的FAQ页面上？”Facebook Messenger机器人的代码是与Messenger Webhooks和Send API相关联的，怎么实现第二个任务呢？我们可以将一些与Messenger通信的逻辑独立出来，创建同一接口的第二个实现—通过Web套接字与聊天机器人通信，此时我们便实现了机器人和消息平台之间的接口抽象。
通过上面的例子，可以看出我们希望让机器人尽可能地与消息平台独立。这样，如果开发者不是机器人框架底层的基础设施开发人员，不负责构建不同消息平台下的连接器，那他们就不需要关注如何从通道接收消息以及发送响应等细节。本书面向的对象是机器人开发工程师，而不是基础设施开发者。幸运的是，市场上不同的机器人框架都帮我们实现了与消息平台独立这一需求，如图1-12所示。这些框架都允许我们编写与通道无关的机器人，然后通过一些简单的操作连接到这些通道。这种与通道无关的功能通常称作通道集成。
因为消息平台版本功能太新或者消息平台过于特定，所以无论哪种机器人框架都做不到面面俱到—都有无法支持某些功能或某个消息平台的短板，这种短板与许多通用框架的情况类似。此时，机器人框架应该支持开发者以原生格式与平台进行通信。微软机器人框架（Microsoft Bot Framework）就提供了这样的机制。
此外，机器人框架应该非常柔性灵活，以支持开发者创建自定义通道的连接器。举两个例子，如果开发者想创建一个提供聊天机器人界面的移动应用，那么机器人框架应该支持该功能；如果企业使用的即时消息通道不被内建的连接器支持，那么机器人框架应该支持让开发者自己创建一个对应该消息平台的连接器。微软机器人框架通过Direct Line API支持这种级别的集成。
我们将在第9章和第10章深入介绍有关通道和自定义通道集成的内容。
1.6 结束语
在本章中，我们快速浏览了用于构建机器人的几个组件。在我个人的实际工作中，使用对话即服务方法的微软Bot框架明显胜过其他的机器人框架，它的灵活性能满足诸多企业场景的需求；Bot框架同时提供了更好、更丰富的抽象概念，以及更深层次的通道集成和非常开放、活跃、多元的技术社区。微软的Bot框架团队为开发者创造了一个功能十分强大的开发套件，它可以作为任何聊天机器人的底层开发框架。我和我的团队使用微软Bot框架已经超过了2年，Bot框架的对话引擎和连接器特性已经被证明可以适用于我们所采用的任何用例。
考虑到上述原因，本书使用微软Bot框架作为首选框架进行介绍。微软Bot框架支持C#/.NET和Node.js，在本书中我们使用Node.js；另外，不需要使用像TypeScript或CoffeeScript之类的其他工具，我们只需使用简单的JavaScript即可展示使用Node.js版的微软Bot框架SDK（即Bot Builder）时，编写机器人是多么简单和直接。
无论是否存在技术炒作，与机器人相关的开发技术确实发展迅猛，令人惊叹。本书不仅涵盖了机器人开发的基础知识，还带领读者了解了一些背后的基础技术和方法。当然，本书不会深入研究背后的底层技术，只保证让读者大致了解如何实现聊天机器人中的智能，以便更轻松地探索更复杂的使用场景。另外，对于涉及的重点内容，本书将提供参考链接和文献作为补充性阅读材料，以方便读者理解。我虽然不是数据科学家，但我在本书中尽力引入了相关的机器学习概念。
我们即将开始技术之旅：对话设计、自然语言理解、与机器人相关的机器学习……在我们介绍这些内容以及构建机器人时，请记住这些技术不仅适用于聊天机器人，同样适用于语音助理。随着自然语言交互和语音交互在家庭和工作场所变得越来越普遍，我保证本书中的技术既会应用于当前的工程项目也会在未来应用到与自然语言相关的应用程序中。让我们开始吧！
