转载

微软发布了云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的支持下，也可以支持持续部署。

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

图片来源：（截图）

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

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

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