2018/08/16 15:28

只要三步！教你做一款人工智能应用“会议伴侣”

编者按：会议伴侣是一款能在大型会议中优化用户问答环节体验的人工智能应用，通过会议伴侣，听众能够随时提问，演讲者则可以一目了然地在台上查看、搜索、筛选听众的问题。本文以会议伴侣为例，讲解了AI应用架构和开发流程。本文编译自微软机器学习博客文章"3 Steps to Build Your First Intelligent App – Conference Buddy"。

想象这样一个场景：在一场精彩的开发者大会上，台上的演讲者正侃侃而谈，讲解最新的前沿技术，而台下的听众也在一边全神贯注地听着演讲，一边思考着跟演讲相关的一些问题，渴望从演讲者口中得到答案。但是通常，这些问题很少有机会得到演讲者的回答，也许是因为提问者认为时机不合适，也许是因为听众不好意思当众提问，也有可能提问者做好了准备，却没有得到提问的机会。

在数字化转型席卷各行各业的今天，人工智能能否推动演讲者和听众之间的互动，带来更好的大会问答环节的体验呢？

优化这一环节的关键在于优化演讲者和听众之间的对话方式，可以在两方面进行优化：一是借助聊天机器人等对话式AI工具，让人与系统之间的对话更加自然；二是借助微软认知服务等预置AI工具，让系统拥有可与真人媲美的认知能力。

作为一个端到端的智能应用，会议伴侣（Conference Buddy）将对话式AI机器人和预置AI工具都融入了其中，能够在大型会议等演示场景中为用户提供更好的问答体验，听众能够随时提问，演讲者则可以一目了然地在台上查看、搜索、筛选听众的问题。

对于想踏上AI之旅的开发者来说，会议伴侣应用的开发是一个理想的参考案例，因为整个开发过程非常简单，只需要三个步骤。

应用架构

问答环节可以被细分为以下几个需求：让听众进行提问的用户界面；方便演讲者查看提问数据的展示界面；还有能够提高互动效率的智能核心。

会议伴侣使用了融合智能核心、用户界面、数据洞见(data insights)所需的不同组件的AI导向型应用架构，这一架构遵循微服务模式（microservices pattern），组件之间松散地组合，每个组件都承担独立任务，并且完全自主运行。这种设计模式使每个组件都可以独立构建、部署和扩展。

我们分三步构建会议伴侣，如图1所示：

图1 会议伴侣应用架构

第一步：构建应用的智能大脑——Bot Brain

我们从应用的智能大脑“Bot Brain”开始。Bot Brain是整个应用的核心，可以被任何经过身份验证的其它组件调用。

Bot Brain包含两部分：Bot Task(处理任务)的集合以数据协定（Data Contract）。

Bot Task负责收集听众提问，自动生成相关答案，并将问题存储到数据存储器中。每项Bot Task都是独立的逻辑函数，它可以部署到同一服务或一组不同服务中，并且互不影响。这种微服务的架构能够简化调试和修复bug的工作。

在会议伴侣中，每个Bot Task都作为一项Azure功能来部署，以下是三个Bot Task示例：

“查询身份”任务：如果听众想了解演讲者的更多信息，该任务利用Azure认知服务的QnA Maker功能，为听众提供回答。
“了解更多”任务：该任务利用Azure认知服务的视频索引器和必应Web搜索功能，自动在网上搜索与听众问题有关的答案。
“回答问题”任务：该任务利用Azure认知服务的文本分析功能，从听众的问题中提取信息，并将结果存储到Azure搜索服务中。

开发者可以在以下链接中尝试这些Azure功能。

https://docs.microsoft.com/en-us/azure/azure-functions/

为了更好地发挥微服务架构的优势，应用的各个组件之间不能组合得太紧密，不同组件需要的只是一个标准化的请求和响应——数据协定（Data Contract）。它是Bot Brain与其调用组件之间的协议，对需要交换的数据进行了抽象的描述。

第二步：构建听众提问页面

接下来，我们要建立一个让听众随时提出问题的用户界面。这一任务由会议聊天机器人Conference Bot完成，Conference Bot使用Azure机器人服务构建，它允许听众在多种渠道以及设备上，以自然语言的方式提出问题。Conference Bot使用LUIS（微软语言理解智能服务）理解听众的问题，然后通过数据协定发出请求，调用Bot Brain，从各种渠道搜索相关答案，最后将答案以合适的方式反馈给听众。