最近 Tasytt 发布了 Obie 。Obie 是一个 Slack 平台上用于了解企业知识的聊天机器人。团队可向 Obie 提出“何事(What)”、“什么方法(How)”以及“何处(Where)”等问题,例如,“我们的计算机策略是什么?”。Obie 可能会查找企业的相关文档并发现答案,也可能会请求用户向它提供一个答案,这样下次有人问它类似的问题时,它就可以直接地给出答案。
Obie 已经集成了一些现有的服务,包括 Google Docs、Confluence、Google sites、Evernote 和 Dropbox 等。这意味着企业不必从头开始训练 Obie。对已有知识的访问确保了 Obie 具有很短的训练时间。
针对 Obie 的一些问题,InfoQ 采访了 CEO 和创始人 Chris Buttenham。
InfoQ:我们在 Slack 平台上初步试用了一下 Obie,感觉它并未对我们前期的会话进行分析。未来是否会考虑添加该特性?
你也能想到,之前也有一些用户提出了这一问题!虽然看上去 Obie 完全可以用 Slack 平台中已经存在的内容作为开端,但事实上,我们感到其中大部分会话是完全无结构化的,因此从某种程度上不能用于团队知识的组织。我们的确在考虑如何将已存在于 Slack 平台中的内容添加为 Obie 可参考的知识,但是在企业中散布着来自多来源的丰富内容,这在我们看来是更唾手可得的内容。
InfoQ:当前 Obie 只能读取你们自己构建的知识库。你们是否有计划添加一些额外的智能,例如 Alea 和 Siri 等所具有的?
我们关注的基本上是“内部”知识这一概念。虽然无法知道它的发展方向,但是我们希望 Obie 能成为一种从内部学习一切的最智能解决方案。这意味着,我们远不是仅仅对企业知识感兴趣,也可以是对任何团队、家庭或个人。当你想要不公开地与他人分享你所知道的事情时,我们希望做到让这些人只需要请教你的个人 Obie 即可。
InfoQ:人们可以用很多种不同的方式去反复地提问同一问题。Obie 是如何识别这些问题的意图所在的?
为了理解聊天内容、上下文、关键字和其它由 Obie 采集的元数据。我们使用了一些第三方技术,以及我们自身的尚未公开的 NLP(自然语言处理)技术。为此,我们还对各种服务使用了一些后备机制。
InfoQ:当前自然语言处理是一个热门话题。您能简要介绍一下 Obie 的底层机制,并向我们透露一下其中所使用的技术吗?
为确保能返回最适合的结果,Obie 组合使用了一系列的技术。其中涉及一个处理打分的流水线,它根据知识实体的属性和元数据的数量,为每个知识实体的给定了一个分数。为了增加准确性,Obie 会根据用户的行为以及结果持续进行学习。实体分类技术用于在更抽象的层级上对文档进行分类,而组合了词向量的关键字抽取技术确保了 Obie 能提供一些其它的可选结果。此外,Obie 还采用了类似于 Lucene 的打分机制对结果做预处理,并使用更大规模的知识库,实现了更优越的性能。
InfoQ:我们发现 Obie 可以与 Dropbox、Onedrive 和 Atlassians Confluence 等现有的“知识库”集成。作为一家企业,如果我们在这些服务中保存了非常重要的私有敏感信息,是否依然适合使用 Obie 分析数据?
当然可以,我们也接触了不少类似的场景。我们非常注重安全和隐私问题,并部署了严格的访问控制策略,确保了只有经认证的服务器才可以访问企业的信息。我们的服务器不会保存任何来自于集成方的信息,我们还给出了可选项,可以选择加密所有控制面板和 CMS 中的内容。同时,我们也对加密的密钥做了安全处理,并经常性地在安全架构中旋转密钥。
InfoQ:有很多团队依然尚未使用 Slack 平台,而是依赖于 HipChat,甚至是更古老的电子邮件方式。你们是否已经考虑会将 Obie 用于其它的聊天客户端?
在 Slack 平台之外,无疑存在着市场,我们不能好高骛远(Boil the Ocean),Slack 为 Obie 提供了一个很好的起始平台,对我们而言,它具有高度增长的理想客户细分样本。此外,我们已经与 message.io 和 Microsoft 建立了伙伴关系,近期将会将 Obie 引入 Microsoft 团队中,提供易于和 HipChar、Skype、Cisco Spark 等接口的功能。我们一直在构建 Obie,以使其有朝一日可以在任何活跃的对话中访问,甚至是用于短信中!
InfoQ:你们是怎么想到要去构建这样的一个聊天机器人的?
这完全是误打误撞!我和我的联合创始人曾在前期工作的企业中首次碰上了这个问题,我们决定构建一个应用以解决问题。我们很快地认识到,团队并不需要更多的工具!聊天机器人的热潮及对话接口让我们灵光闪现(Lightbulb Moment),于是就将产品转化为 Obie 这样的一个聊天机器人。
InfoQ:您曾指出其它的聊天机器人正对已有的工作流过程产生干扰。您是否能就此给出一个实例?为什么 Obie 做得更好?
如果我理解问题正确的话,那么对聊天机器人普遍地存有一个误解,即聊天机器人是一个包罗万象的解决方案。我们在自身的技术、用户体验和品牌上要优于我们的竞争者,但是还存在着大量不构成竞争关系的机器人产品。例如,Growbot(growbot.io)是一种帮助团队获取成功的机器人,促进了团队内“支持”或“荣誉”态度的分享。在我们看来,聊天机器人在成为单点解决方案上存在着充足的发展空间,因此我们可聚焦于如何非常好地解决一个问题。我们可以看到,从早期的“App”时期到聊天机器人空间涌现间的齐头并进。
InfoQ:设想另有开发人员也想要启动一个 Slack 集成服务。在此之前有哪些应了解的事情?
需要指出的是,如果想实现一个复杂的聊天机器人,要让这种前无古人的做法在业界分一杯羹,你将会经历一些成长上的痛苦。Web 和移动应用已是良好确立的,因此已经存在着一套标准了。相对而言,Obie 等聊天机器人初来乍到,提供了一种与软件交互的全新方式。你不太可能第一次就做到完全正确,因此确保你立于新 API 特性的潮头地位,通过发博文等方式介绍业界涌现的趋势和开发工具。
聊天机器人看上去很简单,但是不要被此所蒙蔽,它就像是一个除了输入以外空无一物的网页。而大量的用户输入最难以处理的,用户不会总是按照你所期待的方式做事。例如,如果你不想让一个按钮被用户点击,你仅仅禁用该按钮即可。但是一个聊天机器人必须具备处理所有的输入的能力,并且为了确保良好的用户体验,还应该给出很得体的处理实现。
查看英文原文: Q&A With the Developers of Obie: A Chatbot for Company Knowledge
评论