微软发布了云 Bot-as-a-Service 平台

在去年十一月，微软发布了号称“业界首款云Bot-as-a-Service”平台。Bot 和更多专用的对话应用是近期非常受欢迎的主题。亚马逊和谷歌最近也发布了深度学习公告。

Azure Bot 服务由微软Bot 框架提供支持，并且拥有建立在 Azure 功能之上的无服务器计算后台。采用 Bot 服务可以允许开发者创建对话应用程序，并且将它嵌入许多流行的聊天应用程序之中，包括 Slack、Facebook Messenger、Skype、Microsoft Teams、Kik 和 Office 365 等等。它还支持文本和 SMS 消息服务，并且可以嵌入客户自己的网站。

Lili Cheng 是一位在微软人工智能和研究小组工作的杰出的工程师。她解释了为什么微软决定创建这项服务：

对于软件开发人员来说，创建一个对话服务需要我们转变设计和构建软件的方式。事实证明，要做好这一点是相当困难的。对于对话来说，它自身的特点决定了不固定和突然转换主题都是常态。

当大家喜欢在移动平台上开发完成任务式的应用程序时，还有那么一些人，包括 Amino 的市场营销主管 Carine Carmy，却在呼吁移动应用程序不要再开发消息机器人相关的东西了。这种公开式的反对很大程度上与寻找合适的移动应用程序过程中引发的摩擦不愉快有关：

移动应用程序很适合一直使用现有的，但不适合换新的。

Lars Liden 是在微软工作的首席软件工程师，他描述了在构建传统移动应用程序的时候，开发人员所面临的一些挑战：

应用程序的问题在于用户必须把它们安装在他们的手机里。现实中，人们只会频繁使用他们手机上的五个或六个应用程序。作为开发人员来说，开发跨平台应用软件是非常痛苦的。这个任务的工作量很大。Bot 的伟大之处在于你一旦创建了它，它就无处不在。它使你的生活变得更简单。当大多数人拿着手机时，他们会把大部分时间花在聊天类应用程序上。所以，当人们在使用他们的聊天应用程序的时候，他们就可以从 Bot 服务请求信息了。

当开发人员改去开发对话应用程序时，他们可能会落入一些陷阱。当开发人员构建 Bot 时，他们通常会把时间花在两个方面，一方面是实现 Bot 的逻辑或者说是智能，另一方面是把你的 Bot 集成到不同的服务中，以便它可以展示给用户。Liden 建议说：

当开发人员实际上想把时间花在开发真正的对话机器人时，大多数开发人员 80% 的时间却陷入了泥潭中，他们在试图将自己的对话机器人连接到各种服务上。

微软的 Bot-as-a-Service 平台旨在简化开发人员的体验。为了加快开发进程，微软也提供了示例代码、Visual Studio 和 Visual Code 支持、模板和一个集成的聊天窗口，可以在你向 Azure 发布 Bot 之前, 先进行本地测试。一旦你的 Bot 已经发布到 Azure 了，它就可以通过 Azure 提供的功能按需扩展规模。在 Git 和 Visual Studio Online 的支持下，也可以支持持续部署。

图片来源：（截图）

微软支持集成到第三方渠道，以及微软的认知服务等其它API。通过结合认知服务，开发人员可以利用微软在自然语言处理方面的积累来进行关键短语检测、情感分析、语言检测或主题检测。开发人员还可以创建语言理解智能服务（Language Understanding Intelligent Service，LUIS）模型。此模型支持上下文感知，以及在Bot 内部的自学习式对话。

这里有一个关于语言理解的例子。微软已经谈过了这个例子，就是关于一个可以检索股票行情的聊天应用程序。虽然是根据固定的股票报价编码返回一个结果，构建一个这样的应用程序并不是非常具有挑战性，但是如果在用户一边的是一个自由输入的文本框，那么这件事情就不一样了。使用LUIS（语言理解智能服务模型），开发人员可以训练机器学习算法，让它理解询问股票价格的问句的各种不同表达方式。这通过在LUIS 控制台里定义的意图和实体来完成。然后开发者就可以在把他们自己的模型提供给一个Bot 应用程序使用之前，先训练和测试它们。

图片来源：（截图）

当开发者使用Azure Bot-as-a-Service 提供的服务时，他们只需支付应用程序所消耗的资源的费用。这包括与Azure 功能相关的计算，还有通过Bot 做出的对任何认知服务的API 调用。可以在这里找到更多有关定价的信息。

查看英文原文： Microsoft Launches Cloud Bot-as-a-Service Platform