近年来,聊天机器人和人工智能(AI)已经成为科技领域和公众想象中的热门话题。聊天机器人,即可以使用自然语言交流的计算机程序,正在做从订购比萨饼到购买衣服到节省停车罚单的钱到它们之间的谈判的一切事情。最初,开发一个聊天机器人相当于开发一个与消息平台的集成。没有简单的方法用代码表示对话流。当微软创建 Bot 框架和 Bot Builder SDK 时,这种情况发生了变化。微软创造了一个丰富的环境,在这个环境中,开发人员从与单个频道集成的顾虑中解放出来,可以专注于编写代码来执行聊天机器人需要完成的对话任务。Bot Builder SDK 提供了一种开发对话体验的通用方法。微软的 Bot 连接器实现了将通用格式转换为特定于通道的消息的逻辑。
结果是聊天机器人的开发对于数百万开发者来说变得更加容易。工程师们不再需要学习如何与脸书的 Messenger APIs 或 Slack 的 Web API 集成。相反,开发人员专注于核心机器人逻辑和对话体验。微软担心剩下的。
Bot Builder SDK 可用于。NET 和 Node.js,并在 GitHub 上作为 MIT 授权的开源项目运行。团队在开发和应对开发团队遇到的各种问题方面都很活跃。而且球队很友好的开机!
2017 年 12 月,微软同时推出了 Bot 框架和语言理解智能服务(LUIS)。LUIS 是微软的自然语言服务,它将帮助我们为机器人添加对话智能。Bot 框架现在也被称为 Azure Bot 服务;这两者指的是同一个东西。顾名思义,Azure Bot 服务现在是微软 Azure 云产品的成熟部分。微软也提供了免费的服务层,所以我们可以尽情地玩这个框架。书中所有的样本和技术都可以免费实验!
在过去的几年里,所有大型科技公司,如微软、脸书和谷歌,以及许多较小的公司,都在尝试创建最好、最易用的聊天机器人开发框架。这个领域非常活跃。框架来来去去。事情似乎每天都在变化。尽管空间是动态的,微软的机器人框架仍然是开发强大、快速和灵活的聊天机器人的最佳平台。我很高兴用这个工具带你踏上聊天机器人开发之旅。
两年多来,我与客户交谈的大部分时间都花在讨论聊天机器人的功能,它们是什么,更重要的是,它们不是什么。我们的文化在很大程度上混淆了聊天机器人的能力和人工智能,很容易看出为什么。一些聊天机器人使用丰富的自然语言能力,让我们想象它们有更多的功能。同样,基于语音的数字助理,如 Cortana、Alexa 和 Google Assistant,生活在我们的家中,可以像真人一样说话。为什么聊天机器人不会显示出更高的智能?
这种文化还渗透着对 IBM 的沃森(Watson)在《危险边缘》(Jeopardy)上的引用、 4 《纽约时报》在谷歌大脑团队 5 上的特写,以及他们在语言翻译方面使用深度学习、无人驾驶汽车的壮举,以及 AlphaZero 在学习如何下棋仅四个小时后就摧毁了世界上最高评级的下棋引擎。 6
这些和其他许多故事凸显了对这些技术的投资和兴趣,预示着我们正在走向的人工智能驱动的设备交互。人工智能领域的发展改变了我们与技术互动的方式,以及我们对技术的期望。为我们的设备赋予人类属性和能力正变得越来越普遍。认知和科幻领域的思想家长期以来一直在努力解决这种可能性,阿西莫夫的机器人三定律(Three Laws of Robotics)推广了这种可能性,这是一套机器人必须遵守的规则,以确保机器人不会追逐人类。现在现实世界中已经有了一些清晰而具体的人工智能例子,这种现实似乎更加接近了。
然而,现实与人工智能在一些非常具体的问题领域的成功所设定的期望并不匹配。虽然我们在自然语言处理、计算机视觉、情感检测等方面取得了巨大的飞跃,但将所有这些组成一个类似人类的智能,通常被称为人工通用智能 AGI,还不在我们的掌握之中,也不是聊天机器人的现实目标。对于每一篇庆祝人工智能领域巨大成就的文章,都有一篇匹配的文章淡化了围绕同一技术的炒作,并展示了为什么这种类型的人工智能仍然远非完美的例子(想想那些展示计算机视觉算法仍然无法正确分类的所有图像的文章)。正如任何被媒体大肆宣传的技术一样,我们必须合理对待我们对它的期望。
我们的机器人会成为具有人类智能的代理人,与我们的用户进行对话吗?不。考虑到我们希望机器人完成的技术和任务,我们能让机器人很好地完成这些任务吗?绝对的。这本书旨在让读者掌握构建引人注目、引人入胜且有用的聊天机器人的必要技能。在这段旅程中,你想融入多少最新的人工智能技术,这取决于工程师。当然,对于一个优秀的聊天机器人来说,这些技术并不是必需的。
在最基本的层面上,聊天机器人,在本书中也被简称为机器人,是一个计算机程序,它可以接受用户以自然语言输入的信息,并向用户返回文本或富媒体。用户通过 Facebook Messenger、Skype、Slack 等消息应用,或者通过亚马逊 Echo、谷歌 Home 或微软 Cortana 支持的 Harmon Kardon's Invoke 等语音激活设备,与聊天机器人进行交流。
图 1-1 展示了我们第一个使用微软 bot 框架构建的 Bot。这个 bot 只是向用户返回相同的消息,并以字符串“echo:”作为前缀。在 Bot 框架上运行这种体验的逻辑非常简单。
图 1-1
一个简单的回声机器人
var bot = new builder.UniversalBot(connector, [
function (session) {
// for every message, send back the text prepended by echo:
session.send('echo: ' + session.message.text);
}
]);这是一个聊天机器人。基本的,不是很有用,对吧?我们可以轻松地创建一个 YouTube 机器人,给定用户文本输入,搜索该主题的视频,并将这些视频的链接发送给用户(图 1-2 和 1-3 )。
图 1-2
猫也可以
这是另一个基本的机器人,只做一件事,而且做得很好。它与 YouTube API 集成,使用您的输入作为搜索参数,并返回在 Bot 框架中被称为 cards 的内容,我们将在本书的后面进行探讨。这些图像带来了更丰富、更引人入胜的体验——更有趣,但仍相当基础。
图 1-3
狗更好!
接下来显示了这个程序的代码。我们向 YouTube 发出请求,并将响应从 YouTube 格式翻译成 Bot 框架卡。
const bot = new builder.UniversalBot(connector, [
session => {
const url = vsprintf(urlTemplate, [session.message.text]);
request.get(url, (err, response, body) => {
if (err) {
console.log('error while fetching video:\n' + err);
session.endConversation('error while fetching video. please try again later.');
return;
}
const result = JSON.parse(body);
// we have at most 5 results
let cards = [];
result.items.forEach(item => {
const card = new builder.HeroCard(session)
.title(item.snippet.title)
.text(item.snippet.description)
.images([
builder.CardImage.create(session, item.snippet.thumbnails.medium.url)
])
.buttons([
builder.CardAction.openUrl(session, 'https://www.youtube.com/watch?v=' + item.id.videoId, 'Watch Video')
]);
cards.push(card);
});
const reply = new builder.Message(session)
.text('Here are some results for you')
.attachmentLayout(builder.AttachmentLayout.carousel)
.attachments(cards);
session.send(reply);
});
}
]);好吧,这个怎么样?我们可以有一个机器人,给定一个陈述,它可以判断这是一个中性的、积极的还是消极的陈述,并返回一个适当的响应(图 1-4 )。我们没有展示它,但是这个例子的代码和前面的例子一样简单:我们从一个简单的情感 REST API 中获取一个情感分数,并使用它来呈现一个答案。
图 1-4
利用人工智能推动对话的一个简单例子
这是一个简单的例子,表明如果我们走这条路,我们的代码可以多么容易地与人工智能集成。机器人不必总是遵循问答模式。机器人可以主动接触用户。例如,我们可以有一个欺诈警报机器人(图 1-5 )。
图 1-5
主动用户信息
机器人可以更加任务驱动。例如,想象一个日历机器人,它可以创建约会,检查可用性,编辑或删除约会,并给你一个日历摘要(图 1-6 )。
图 1-6
一个简单的日历机器人集成了谷歌日历
现在事情开始变得有点有趣了。我们开始采用自然语言并付诸行动。
为什么机器人变得如此重要?当然,它们以各种形式存在于像 IRC 7 和 AOL Instant Messenger 这样的老派应用中。 8 这些都不是小实验。IRC 机器人已经存在很长时间了。我记得通过 IRC 与相当多的机器人互动过。当谈到技术的时候,我还很年轻,很天真,最初我以为真的有人在回应我的信息。我很快意识到,某个地方有一台机器在回应我写的东西。我与 IRC 机器人互动得越多,我就越把它们当成命令行。然而,这在当时是非常小众的技术。公众不是每天都与机器人互动,所以没有必要迎合自然语言的互动。
今天,我们与周围技术互动的方式完全不同,这是由三种力量驱动的:人工智能的进步,消息应用作为对话智能平台的想法,以及语音激活的对话界面。
在整个 20 世纪,计算机科学家、生物学家、语言学家和经济学家在认知、人工智能、人工生命、机器学习和深度学习领域取得了巨大进步。执行指令的计算机程序的概念,通用图灵机 9 和可以数字存储代码并执行代码的计算机架构的想法,接受输入并产生输出,以及冯诺依曼架构, 10 在人类历史标准中是最近的,但却是我们在计算机上的工作所基于的基本概念。1943 年,麦卡洛克和皮茨在他们的论文《神经活动中内在思想的逻辑演算》中首次发表了关于神经网络的想法111950 年,阿西莫夫在其著作《机器人三定律 I、 机器人中收录了机器人三定律。 12 同年,第一篇描述计算机如何下棋的论文——克劳德·香农(Claude Shannon)的《为下棋编写计算机程序》发表。他继续从本质上发明了信息论领域。从 20 世纪 60 年代开始,这个领域的研究数量和增长速度令人震惊;我们每天都能在媒体对最新人工智能应用的报道中看到这方面的证据。
可以说,自 20 世纪 60 年代以来,机器学习和使用各种算法构建我们自己的模型的过程已经变得更好执行和更容易获得。像 scikit-learn for Python 和 Google 的 Tensor Flow 等库都有很好的记录,并得到了社区的大力支持。大型科技公司也在他们的计算能力和能力上投入了足够的资金,以便能够在合理的时间框架内完成一些计算量最大的任务。微软、亚马逊、谷歌、IBM 和其他公司现在都以这样或那样的方式涉足云平台。下一步是按需提供一些机器学习算法。如果我们简单地以微软的认知服务为例,我们会发现在撰写本文时有 30 个 API。这些包括计算机视觉工具,如面部和情感检测、内容审核和 OCR 功能。它还包括语言工具,如自然语言处理、语言和文本分析以及自然语言理解。它甚至包括搜索和知识工具,如推荐引擎和语义搜索。任何开发人员都可以在任何时间以合理的成本接入这些强大功能的服务的可用性是智能系统在我们生活中变得如此普遍的重要原因,也是我们的机器人可以利用的基础设施之一。我们将在第 10 章中探讨微软的认知服务。
近年来,移动通讯应用风靡一时。Snapchat、Slack、Telegram、iMessage、FB Messenger、WhatsApp 和微信是移动用户手机上最常用的一些应用。事实上,它们的使用率已经超过了脸书等社交网络。据 Business Insider 报道,在 2015 年第一季度的某个时候,即时通讯应用开始比社交网络更受欢迎,这一趋势一直持续到现在。虽然这本书不会详细介绍美国和全球市场的所有相关参与者,但关键是,微信和 LINE 等亚洲通讯应用已经找到了通过聊天应用增加使用量的最佳方式,以及如何利用这种使用来赚钱。货币化趋势尚未完全赶上美国市场,但苹果、Twitter 和脸书等公司已经领先,允许开发者创建简单的聊天机器人,甚至支付集成。我并不是说讨论仅限于上述玩家;开放消息平台的趋势是普遍的。
在现有的信息平台中托管这些机器人的能力为更多的客户打开了品牌。用户体验停留在消息应用中。机器人开发者不需要像移动应用开发者那样关心动画和内存管理;主要关注的是与用户的对话。我们将在整本书中遇到的一个有趣的概念是,机器人不仅仅是文本。它们可以包括图像、视频、音频以及调用其他命令的按钮。在现有消息应用的范围内创建对话体验是在应用中编写应用的练习;我们的 bot 受到消息传递平台支持的本机特性的限制。Bot 框架有必要的设施来最大限度地利用所有这些功能。
另一个显著加速对话智能技术发展的因素是支持语音的硬件设备的发展。苹果公司在 2011 年推出了更重要的现代虚拟助手之一 Siri。Siri 现在是一个家喻户晓的名字,它是由最著名的桌面语音识别系统之一 Nuance 的语音到文本产品 Dragon NaturallySpeaking 背后的一些技术驱动的。
Siri 是第一个上市的,似乎鼓励了许多其他公司跳入语音助手的游戏。微软在 2014 年发布了 Cortana 助手,同年发布了第一款亚马逊 Echo 设备。Cortana 最初仅限于 Windows Phone 和 Windows 桌面操作系统,但后来在移动操作系统甚至 Xbox 上也可以使用。亚马逊的 Echo 采用了 Alexa 语音助手,是第一款商业上成功的独立硬件设备,并让亚马逊在早期主导了语音助手市场。在随后的几年里,脸书和谷歌分别推出了 2018 年初关闭)和谷歌助手。谷歌正通过 Google Home 进入语音设备领域。哈曼卡顿将一款名为 Invoke 的产品推向市场,这是一款基于微软 Cortana 的扬声器。许多其他参与者正在向该市场扩张,这进一步鼓励了该领域的创新。
人工智能和语音识别、自然语言处理和自然语言理解技术的进步加速了这种增加的活动和竞争。这些技术的显著发展增加了在标准、框架和工具方面为这些平台创建定制功能的活动。正如我们将很快看到的,这些自定义功能或技能可以由聊天机器人来支持。
为什么我们要编写机器人,并使用消息应用作为平台?我们可以轻松地编写移动应用,发布到应用商店,然后一劳永逸,不是吗?不完全是。用户行为的各种趋势使得这种方法不太可行。
对于一些较大的品牌来说,下载他们的应用是一项简单的任务。我想用脸书?好吧,我去拿应用。我想查看我的电子邮件;我会使用应用。但是,我想和我当地的花店谈谈?我不需要一个应用。我不希望有这样的应用。为什么我要为我接触的每一家企业下载应用?理想情况下,我可以给他们打电话或者发短信,对吗?
公司在市场上采取的行动允许用户直接与企业对话。让我们以脸书为例。当地的花店可以有一个脸书页面,并在该页面上启用消息传递。企业员工可以在一个地方回答客户的询问。Twitter 在其新的直接消息 API 中也有类似的功能。这为企业提供了很多价值。应用下载摩擦的消除使得用户开始与企业对话变得更加容易。当然,下一步是自动化一些通信。这就是机器人的用武之地。消息传递平台负责许多问题,例如用户身份、身份验证、应用的整体稳定性等等。
这也转化为其他用例。让我们以 Slack 这样的生产力工具为例。Slack 是一个很棒的工作协作平台,它使人们能够跨多个主题进行聊天和协作。Slack 平台上的聊天机器人通常更注重生产力。例如,你可能很难让人们在 Slack 上使用约会机器人,而不是在脸书这样的社交网络上。图 1-7 显示了排名靠前的 Slack 机器人列表。这些类型的机器人更多地与工作任务相关联,如待办事项列表、站立、任务分配等。很明显,如果一个团队完全投入并沉浸在懈怠中,创建一个机器人来执行共同的任务可能比创建一个完全独立的网站更有效。
图 1-7
Slack bot 列表
尽管 Slack 的列表中包含一个名为机器人的特定类别,但事实是所有这些应用都是机器人。其中一些可能更具有对话性,而另一些可能更具有命令行的感觉;就我们而言,机器人只是简单地监听消息并根据消息采取行动。对于大量对话型聊天机器人来说,自然语言理解的主题,即理解人类语言的学科,对于良好的用户体验至关重要。因此,我们将章节 2 和 3 献给这个主题。
当我们深入 Bot 框架时,有必要将聊天机器人的开发分解成单独的组件。一般来说,每个组件都有几种方法。在下面的讨论中,我试图描述一般概念,然后强调微软在 Bot 框架中解决问题的方式。
-
机器人运行时
-
自然语言理解引擎
-
对话引擎
-
通道整合
在最基本的层面上,聊天机器人是一种响应用户请求的网络服务。根据我们集成的消息传递平台的不同,细节会有所不同,但想法是相同的:消息传递平台通过 HTTP 端点用包含用户输入的消息调用 bot。我们的聊天机器人的角色是处理消息,并向平台发送消息,包括机器人的响应以及任何附件或特定于平台的数据。图 1-8 展示了一种通用方法。根据平台的不同,我们可能能够返回带有 HTTP 状态代码或其他格式的异常情况。当我们的 bot 处理消息时,它通过调用通道的 HTTP 端点进行响应。然后,通道将消息传递给用户。
图 1-8
用户、消息平台和通用机器人之间的消息交换
这种方法有一些问题,主要是我们将机器人绑定到特定的消息传递通道,而我们的机器人应该是通道不可知的,这样我们就可以尽可能多地重用逻辑。bot 框架通过提供位于消息传递平台和 Bot 之间的连接器服务来解决这个问题。实际上,交互看起来更像图 1-9 。请注意,通道连接器拥有与消息传递平台的连接和通信,并将消息转换为我们的 bot 可以识别的通用格式。我们将在本章后面的“通道集成”部分更详细地介绍通道。
图 1-9
使用 bot 框架在用户、消息传递平台、连接器服务和 Bot 之间进行消息交换
由于 bot 运行时只是一个监听 HTTP 端点的计算机程序,我们可以使用任何允许我们接收 HTTP 消息的技术来开发 bot。我们可以利用。NET、Node.js、Python 和 PHP。事实上,我们可以简单地使用 Bot 框架来获得连接器的优势,并使用我们喜欢的任何方法实现 HTTP 端点。然而,如果我们这样做了,我们将失去 Bot Builder SDK。我们将在本章后面的“对话引擎”部分介绍它的好处和使用它的理由。
编写一个能够阅读和理解用户话语的聊天机器人是一项挑战。人类语言是具有灵活和不一致规则的非结构化输入。然而,我们的机器人需要能够接受这些输入,并找出用户在谈论什么。在高层次上,自然语言理解引擎为机器人开发者解决了两个问题:意图分类和实体提取。
我们将通过例子来说明什么是意图和实体。比方说,我们正在开发一个恒温器控制机器人。最初,我们希望支持四个动作:打开、关闭、设置模式为制冷或制热,以及设置温度。用户可以用自然语言表达的动作类别(意味着开/关、设置模式或设置温度)被称为意图。模式本身(冷或热)和温度值是实体。NLU 引擎允许机器人开发者定义一组与应用相关的自定义意图和实体。表 1-1 列出了一些示例映射。
表 1-1
由 NLU 系统解析的用户输入到意图的示例映射
|说话
|
目的
|
实体
| | --- | --- | --- | | "打开" | 接通开启 | 没有人 | | “关闭电源” | 岔道 | 没有人 | | “设置为 68 度” | 设定温度 | “68 度”类型:温度 | | “将模式设置为冷” | 设置模式 | “酷”类型:模式 |
显然,我们的代码基于意图和实体值执行逻辑要比基于原始的用户话语更容易。
bot 开发人员可以利用几种服务来获得这种 NLU 功能。在当前的技术环境下,有大量基于云的 API 可用,如 LUIS、Wit.ai 和 Dialog flow 等。LUIS 是这一组中最富有和表现最好的,他是第 3 章中 NLU 深入探讨的主题。
在构建机器人时,我们通常会开发一个工作流来实现我们的机器人想要完成的任务。按照基本的恒温器示例,我们可以设想如图 1-10 所示的机器人架构。
图 1-10
示例 bot 对话设计图
工作流总是从机器人监听用户话语开始。用户说出的话语将被解析为表 1-1 中的意图。如果意图是打开或关闭,机器人可以执行正确的逻辑,并用确认消息进行响应。如果我们收到一个设置温度的意图,我们的机器人可以验证温度实体存在。如果没有,我们向用户询问。一旦我们收到它,我们就可以执行正确的逻辑并发送确认响应。SetMode 的工作方式类似于 SetTemperature,因为我们将确认实体的存在,如果它不存在,就引出它。
这种基于用户输入的对机器人行为的描述是一种对话。设计输入、输出和转换类型的活动被称为对话体验设计。我们将在第 4 章中深入讨论这个话题。
对话引擎是跟踪传入消息、处理它们并在对话图 Node(也称为对话)之间执行状态转换的引擎。它为每个用户分别执行此操作。对话的状态被存储起来,这样当下一条用户消息进入机器人时,机器人就知道用户的当前状态。Bot 框架在通过 Bot Builder SDK 提供对话引擎方面做得很好。
开发机器人有多种方法,但它们可以总结为两种方法:机器人引擎和我所说的机器人对话即服务。前面描述了 bot 引擎:我们将 bot 作为 web 服务运行,根据需要调用 NLU 平台,并使用对话引擎将消息路由到对话。像 Dialogflow 这样的公司推广了“机器人对话即服务”的方法。该方法意味着 NLU 解析、对话映射、状态和转换发生在 Dialogflow 基础设施上的云中。然后,Dialogflow 调用您的 bot 来修改响应或与其他系统集成。
当用户的话语映射到一个意图和一组定义的实体时,它被称为一个动作。一个动作有一个意图和一组参数。基于我们的恒温器机器人,我们可以定义一个名为 SetTemperatureAction 的动作。此操作是使用温度参数设置温度的目的。温度参数的类型是温度实体。当 Dialogflow 解析一个动作时,它可以调用您的 bot 来完成该动作。在该模型中,bot 逻辑关注于基于 NLU 服务的解析逻辑的逻辑执行;对话引擎外包给 NLU 服务。
这种 bot 开发方法的一个高级主题是槽填充。这是一个过程,通过这个过程,服务注意到一个动作只有部分被用户输入填充,并自动要求用户填充剩余的槽,也就是我们所说的动作参数。表格 1-2 和 1-3 展示了两个示例动作。
表 1-3
基于机票预订机器人的更复杂的动作
|行动
|
名字
|
类型
|
必需的?
|
提示
| | --- | --- | --- | --- | --- | | 订机票 | 从 | 城市 | 是 | 出发城市 | | 到 | 城市 | 是 | 目的地城市 | | 日期 | 日期时间 | 是 | 你什么时候旅行? |
表 1-2
在我们的恒温器机器人中设置温度的动作定义
|行动
|
名字
|
类型
|
必需的?
|
提示
| | --- | --- | --- | --- | --- | | 设定温度 | 温度 | 温度 | 是 | 你想要设置什么温度? |
图 1-11 展示了在这个对话即服务模型中,用户、消息传递平台、连接器、NLU 服务和机器人之间的整个端到端流程。
图 1-11
典型的 bot 对话即服务流
对话即服务方法善于在短时间内启动并运行某些东西。不幸的是,这样会失去一些控制和灵活性。使用 bot 框架可以让我们完全控制 Bot 引擎,从而避开这些问题。
构建机器人意味着处理多个消息平台。你的老板让你写一个 Facebook 信使机器人。你发布它,你的老板祝贺你的伟大工作。然后他问你,“我们能把这个作为网络聊天添加到我们的 FAQ 页面吗?”您的 bot 代码绑定到 Messenger Webhooks 和 Send API。您四处游荡,认为您可以在传输接口后面隔离一些与 Messenger 通信的逻辑。您创建了同一个接口的第二个实现,它通过 web 套接字与您的聊天机器人对话。现在,您已经创建了自己的机器人和消息传递平台之间接口的抽象。
我们希望我们的机器人逻辑尽可能地从单个消息传递平台中抽象出来。如何从通道接收消息和发送响应的细节是我们不想过多关注的细节,除非我们是构建各种平台连接器的专业人员。我不认为你会读这本书,如果你是。你想开发一个机器人,而不是基础设施。幸运的是,市场上不同的 bot 框架通常会为我们完成所有这些工作,如图 1-12 所示。这些框架允许我们以一种与通道无关的方式编写一个机器人,然后通过几次点击和输入一些数据来连接到这些通道。这些功能通常被称为频道或频道集成。
与许多通用框架一样,也有一些框架不支持的边缘情况,因为平台特性要么太新,要么特定于平台。在这种情况下,框架应该允许我们以其本地格式与平台进行通信。Bot 框架为此提供了一种机制。
此外,我们的框架应该足够灵活,允许我们创建定制的通道连接器。例如,如果我们希望构建一个提供聊天机器人界面的移动应用,框架应该允许我们这样做。如果我们的企业正在使用一个不受微软连接器支持的即时消息通道,我们应该能够创建一个。微软的 Bot 框架通过我最喜欢的特性之一:Directline API 实现了这种程度的集成。
图 1-12
你的机器人不应该关心与哪个通道对话。应该为你抽象出来。
在这一章中,我们快速浏览了可用于构建机器人的不同组件的表面。在我的工作中,Bot 框架明显战胜了使用对话作为服务方法的竞争对手。Bot 框架提供的灵活性和控制是许多企业场景的需求。Bot 框架还提供了更好、更丰富的抽象,更深层次的连接器集成,以及开放和多样化的社区。机器人框架团队已经创建了一个非常强大的套件,可以作为任何对话机器人的基础。我和我的团队使用 Bot 框架已经快两年了,没有找到放弃这个平台的理由。事实上,该框架的对话引擎方法和连接器架构已经被证明对我们抛出的任何用例都具有弹性。
由于这些和许多其他原因,这本书围绕使用微软的 Bot 框架作为框架的选择。该框架适用于 C#/。NET 和 Node.js 开发平台。出于本书的目的,我们将使用 Node.js 版本。我们不会利用任何额外的工具,如 TypeScript 或 CoffeeScript。我们简单地使用普通的 JavaScript 来展示使用 Bot Framework SDK for Node.js(又名 Bot Builder)开始编写 Bot 是多么容易和简单。
不管宣传与否,用于构建机器人的技术和技巧确实令人惊叹。作为这次冒险的一部分,我想确保我们不仅涵盖了构建机器人的基础知识,还学习了更多关于一些底层技术和方法的知识。我们不会非常深入地研究这些主题,但我会涵盖足够多的内容,让读者对如何实现机器人中的智能有一个初步的了解,以便探索更复杂的场景。为了书籍的整体重点,当我涉及这些主题时,我会提供额外阅读材料的链接和信息来补充内容。我不是数据科学家,但我已经尽我所能介绍了相关的机器学习(ML)概念。
我们即将踏上一段激动人心的旅程,穿越对话设计、自然语言理解和应用于聊天机器人的机器学习的世界。当我们讨论这些主题和构建机器人时,请记住,这些技术适用于从聊天机器人到语音助手技能的所有东西。随着自然语言和语音界面在家庭和工作场所变得越来越流行,我保证你会在当前的项目和未来的自然语言应用中应用这些概念。我们走吧!
Footnotes [1](#Fn1_source)机器人律师为违规停车罚单辩护: http://www.npr.org/2017/01/16/510096767/robot-lawyer-makes-the-case-against-parking-tickets
成交还是不成交?训练 AI 机器人谈判: https://code.facebook.com/posts/1686672014972296/deal-or-no-deal-training-ai-bots-to-negotiate/
GitHub 上的微软 Bot Builder SDK:https://github.com/Microsoft/BotBuilder
IBM Watson:赢得 Jeopardy 的超级计算机如何诞生的内幕,以及它下一步想做什么: http://www.techrepublic.com/article/ibm-watson-the-inside-story-of-how-the-jeopardy-winning-supercomputer-was-born-and-what-it-wants-to-do-next/
伟大的人工智能觉醒: https://www.nytimes.com/2016/12/14/magazine/the-great-ai-awakening.html
Google 的 AlphaZero 在百场比赛中消灭 stock fish:https://www.chess.com/news/view/google-s-alphazero-destroys-stockfish-in-100-game-match
IRC 机器人: https://en.wikipedia.org/wiki/IRC_bot
SmarterChild: https://en.wikipedia.org/wiki/SmarterChild
万能图灵机: https://en.wikipedia.org/wiki/Universal_Turing_machine
冯·诺依曼建筑: https://en.wikipedia.org/wiki/Von_Neumann_architecture
一种内在于神经活动的逻辑思维: http://www.cs.cmu.edu/~epxing/Class/10715/reading/McCulloch.and.Pitts.pdf
机器人三定律: https://en.wikipedia.org/wiki/Three_Laws_of_Robotics











