微信智言夺冠全球对话系统挑战赛,冠军解决方案全解析

本文涉及的产品
云解析 DNS,旗舰版 1个月
全局流量管理 GTM,标准版 1个月
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
简介: 如何利用端到端的对话系统基于 Fact 和对话历史生成靠谱的回答,微信智言团队有话说。

前不久,微信智言团队夺得第七届对话系统技术挑战赛(DSTC7)Track 2 赛道的冠军。


DSTC7 挑战赛由来自微软研究院、卡耐基梅隆大学(CMU)的科学家于 2013 年发起,旨在带动学术与工业界在对话技术上的提升,是对话领域的权威学术比赛。本届挑战赛分为三个方向,微信模式识别中心参加了其中一个方向:基于 Fact(如百科文章、Blog 评论)与对话上下文信息自动生成回答。共有 7 支队伍、26 个系统参加该竞赛。


据了解,微信智言团队的主要参赛成员是微信模式识别中心的暑期实习生 Jiachen Ding,目前在上海交通大学读研;另一名成员 Yik-Cheung (Wilson) Tam 博士毕业于 CMU,现任职于微信模式识别中心,对这一参赛项目提供了指导。近日,Wilson 接受了机器之心的采访,就任务详情、模型结构、训练细节等进行了介绍。


DSTC7 Track 2 任务简介


DSTC7 Track 2「Sentence Generation」任务要求基于 Fact 和对话历史自动生成回答。该任务与传统对话系统不同的一点是,它要求利用端到端的对话系统自动读取 Fact。这就像使对话系统具备阅读理解的能力,能够基于 Fact 产生正确的答案。


竞赛提供的 Fact 可能是维基百科文章、新闻等。如下图所示,DSTC7 Track 2 提供的数据集包括来自 reddit 社区的 300 万对话问答,以及从 reddit 网页上相关的网页中提取的 2 亿个句子。


88E9AC97-29E4-4465-8BA8-3096DD4B94CB.png

DSTC7 Track 2 竞赛的数据集构成示例。


Wilson 告诉机器之心,这个任务的难点在于:对话系统生成的答案需要与 Fact 相关,而 Fact 是非结构化数据,相对来讲比较难处理。

 

传统的聊天机器人没有「阅读」Fact 的机制,所以聊天回答可能会有偏差,例如:这家火锅店好不好吃?机器人回答有时会说「这家店的菜很好吃」,有时也会说「这家店的菜很差」,没有办法给出与真实点评一致的回答。


而结合了 Fact 和对话上下文信息的对话系统所生成的回答能够基于 Fact 中的真实信息作答,确保回答是有用、有信息的。


模型架构


微信模式识别中心提出一种基于注意力机制来「阅读」Fact 与对话上下文信息的方法,并利用原创动态聚类解码器,产生与 Fact 和上下文相关并且有趣的回答,在自动和人工评测都取得最佳成绩。


A10319AC-DCFC-4548-9EDC-C799A6FADC5B.png


上图展示了该系统的整体架构,包括数据预处理、对对话历史和 Fact 执行端到端的编码器-解码器注意力建模、改进版解码策略。


下面我们来看一下每个模块的具体细节。


首先是数据预处理。这一步直接决定了系统的性能,Wilson 认为在所有模块中数据预处理是模型训练中最重要的模块之一。该竞赛提供的数据集中很多网页存在大量无关信息(如广告),模型训练时需要先进行数据预处理工作。


在数据清洗过程中,微信智言团队去除了对话历史数据中 reddit 网页上的无用信息(如广告、导航栏、页脚),并简化 Fact 文章内容:从相关 Fact 文章中提取与对话历史关联度高的信息,将平均 4000 单词的文章压缩至至多 500 个 word token。


若我们将 Fact 与对话历史编码为隐藏向量,再借助解码器就能将这些信息解码为对应的回答。其中如上所示编码器比较简单,直接用 BiLSTM 就行了。而如果需要得到优质回答,虚框内的解码过程就必须精炼候选回答,这也是该对话系统解决的核心问题。


为了解码为优质回答,微信团队主要利用了注意力机制、k 均值聚类和语言模型等方法,它们一方面保证集成对话历史和 Fact 信息,另一方面也最大限度地保障回答的多样性和有趣。


其中 k 均值聚类主要对  Beam search的候选回答进行聚类,这样就能识别重复或类似的回答。然而由于该模型解码器中使用了注意力机制,因此对话历史和 Fact 中的 token 可能被重复关注,从而生成重复的 N-grams。因此微信团队随后会移除重复的 N-grams,减少垃圾回答。


在经过了两次筛选之后,最终得到的 top n 个回答中仍可能包含安全却无用的回答。微信智言团队选择构建一个语言模型(LM),过滤掉无用的回答。最后,只需要选择概率最高的作为最终回答就可以了。


解码过程


微信智言团队使用双向 LSTM 分别编码对话历史和 Fact,然后对二者执行注意力机制,即解码器在每个时间步中通过注意力机制关注编码器输入的不同部分。然后利用模式预测和输出词概率估计来计算最终的单词概率分布。


79511AA8-3F90-495F-9C55-4ED3718EBDC0.png

解码步流程。微信团队使用 pointer generator 模型,允许复制对话历史(H)和事实(F)。在每个解码时间步中,计算三个动作概率,即从 h 中复制一个 token,从 f 中复制一个 token,生成一个 token。最终的单词概率分布是这三个概率分布的线性插值。


传统的 seq-to-seq 模型易遇到 OOV 问题。为此,智言团队选择使用斯坦福大学 Abigail See 等人提出的 pointer-generator 方法(原用于文本摘要任务)。他们将该模型从支持两种模式(生成 token 和复制 token)扩展为支持三种模式:生成 token;从对话历史中复制 token;从 Fact 中复制 token。然后模型在每个解码步将所有可用特征级联起来,包括使用注意力机制后得到的对话历史向量和 Fact 向量、解码器隐藏状态、最后一个输入词嵌入。再使用前馈网络和 Softmax 层进行模式预测。


86C768D2-4274-4EA9-8FC2-8A07D27BEAEC.png


最后,模型对上述三种模式的词汇分布执行线性插值,从而计算出最终的单词概率分布,其中 m 对应于复制机制中的模式索引:


3949FEA9-9E65-4798-A1E2-283B5BDAF8EA.png


Beam search 解码策略


传统的束搜索方法主要目的是找到概率最大的假设,但对话系统中往往出现很多安全却无用的回答,很可能概率最大的句子并非是最合适、最有趣的回答。因此微信智言团队在束搜索中继承了 K 均值聚类方法,将语义类似的假设分组并进行修剪,以提高回答的多样性。


如下所示为带 k 均值聚类的束搜索,首先模型会和常见的束搜索一样确定多个候选回答,在对这些候选回答做聚类后,每一个集群都会是类似的回答。如果我们对每一个集群包含的候选回答做一个排序,那么就能抽取到更合理的候选回答,这样也会因为集群而增加回答的多样性。最后,使用语言模型对聚类得到的所有候选答案进行评分,符合自然语言表达的假设就能输出为最终的回答。


748087A6-D0C0-4094-926D-775B4B4AA64C.jpeg


模型训练 trick


除了介绍模型之外,Wilson 还向机器之心介绍了模型训练过程中的具体技巧。


该模型基于 TensorFlow 框架构建,直接使用 pointer generator 模型的源代码,改进以适应该竞赛任务,从而在有限时间内完成比赛任务。



该模型训练过程中,微信智言团队最初使用了单机版 GPU,训练时间为 5 天。


Wilson 表示训练过程中遇到的最大困难是数据预处理,同时他也认为数据预处理是模型训练中最重要的模块之一。其次是束搜索,他们在束搜索中结合了 K 均值聚类,从而有效地过滤掉无用的回答,提高回答的多样性。


关于微信智言


微信智言是继微信智聆之后,微信团队推出的又一 AI 技术品牌。微信智言专注于智能对话和自然语言处理等技术的研究与应用,致力于打造「对话即服务」的理念。目前已经支持家居硬件、PaaS、行业云和 AI Bot 等四大领域,满足个人、企业乃至行业的智能对话需求。


在家居硬件方面,目前腾讯小微已经与多家厂商有合作,如哈曼•卡顿音箱、JBL 耳机和亲见智能屏等智能设备。


此外,腾讯小微定制了很多预置服务(如听歌、查天气、查股票等),但由于不同领域的需求不同,为提高可扩展性,微信智言团队为第三方开放 PaaS 平台,让任何一个开发人员甚至产品经理都可以基于自己领域的业务逻辑、业务需求在 PaaS 平台上搭建自己的应用和服务。


行业云提供面向企业客户的完整的解决方案,为企业快速搭建智能客服平台和行业任务智能对话系统。以客服系统为例子,很多公众号希望搭建对话机制,自动回答用户的问题。开发人员只需将数据上传到微信智言的平台,微信智言团队即可提供 QA 系统。此外,微信智言还提供定制服务,比如 NLP 方面的基础服务,包括分词、命名实体识别、文本摘要等,用服务的方式为客户提供技术。


据了解,微信智言已经通过智能对话技术服务于国内外数百万的用户。微信智言在 AI 技术研究上还将不断探索和提升,为各行业伙伴和终端用户提供一流的智能对话技术和平台服务——真正实现团队「对话即服务」的理念。DF290D4F-5ECF-4116-929C-7A978CAC6888.png



本文为机器之心原创,转载请联系本公众号获得授权

相关文章
|
2月前
|
存储 缓存 关系型数据库
社交软件红包技术解密(六):微信红包系统的存储层架构演进实践
微信红包本质是小额资金在用户帐户流转,有发、抢、拆三大步骤。在这个过程中对事务有高要求,所以订单最终要基于传统的RDBMS,这方面是它的强项,最终订单的存储使用互联网行业最通用的MySQL数据库。支持事务、成熟稳定,我们的团队在MySQL上有长期技术积累。但是传统数据库的扩展性有局限,需要通过架构解决。
78 18
|
2月前
|
JSON 小程序 UED
微信小程序 app.json 配置文件解析与应用
本文介绍了微信小程序中 `app.json` 配置文件的详细
210 12
|
2月前
|
Serverless 对象存储 人工智能
智能文件解析:体验阿里云多模态信息提取解决方案
在当今数据驱动的时代,信息的获取和处理效率直接影响着企业决策的速度和质量。然而,面对日益多样化的文件格式(文本、图像、音频、视频),传统的处理方法显然已经无法满足需求。
111 4
智能文件解析:体验阿里云多模态信息提取解决方案
|
2月前
|
文字识别 开发者 数据处理
多模态数据信息提取解决方案评测报告!
阿里云推出的《多模态数据信息提取》解决方案,利用AI技术从文本、图像、音频和视频中提取关键信息,支持多种应用场景,大幅提升数据处理效率。评测涵盖部署体验、文档清晰度、模板简化、示例验证及需求适配性等方面。方案表现出色,部署简单直观,功能强大,适合多种业务场景。建议增加交互提示、多语言支持及优化OCR和音频转写功能...
122 3
多模态数据信息提取解决方案评测报告!
|
2月前
|
存储 缓存 监控
社交软件红包技术解密(四):微信红包系统是如何应对高并发的
本文将为读者介绍微信百亿级别红包背后的高并发设计实践,内容包括微信红包系统的技术难点、解决高并发问题通常使用的方案,以及微信红包系统的所采用高并发解决方案。
91 13
|
2月前
|
存储 分布式计算 Hadoop
基于Java的Hadoop文件处理系统:高效分布式数据解析与存储
本文介绍了如何借鉴Hadoop的设计思想,使用Java实现其核心功能MapReduce,解决海量数据处理问题。通过类比图书馆管理系统,详细解释了Hadoop的两大组件:HDFS(分布式文件系统)和MapReduce(分布式计算模型)。具体实现了单词统计任务,并扩展支持CSV和JSON格式的数据解析。为了提升性能,引入了Combiner减少中间数据传输,以及自定义Partitioner解决数据倾斜问题。最后总结了Hadoop在大数据处理中的重要性,鼓励Java开发者学习Hadoop以拓展技术边界。
66 7
|
2月前
|
存储 监控 容灾
社交软件红包技术解密(五):微信红包系统是如何实现高可用性的
本次分享介绍了微信红包后台系统的高可用实践经验,主要包括后台的 set 化设计、异步化设计、订单异地存储设计、存储层容灾设计与平行扩缩容等。听众可以了解到微信红包后台架构的设计细节,共同探讨高可用设计实践上遇到的问题与解决方案。
63 5
|
3月前
|
存储 监控 算法
企业内网监控系统中基于哈希表的 C# 算法解析
在企业内网监控系统中,哈希表作为一种高效的数据结构,能够快速处理大量网络连接和用户操作记录,确保网络安全与效率。通过C#代码示例展示了如何使用哈希表存储和管理用户的登录时间、访问IP及操作行为等信息,实现快速的查找、插入和删除操作。哈希表的应用显著提升了系统的实时性和准确性,尽管存在哈希冲突等问题,但通过合理设计哈希函数和冲突解决策略,可以确保系统稳定运行,为企业提供有力的安全保障。
|
3月前
|
安全 前端开发 Android开发
探索移动应用与系统:从开发到操作系统的深度解析
在数字化时代的浪潮中,移动应用和操作系统成为了我们日常生活的重要组成部分。本文将深入探讨移动应用的开发流程、关键技术和最佳实践,同时分析移动操作系统的核心功能、架构和安全性。通过实际案例和代码示例,我们将揭示如何构建高效、安全且用户友好的移动应用,并理解不同操作系统之间的差异及其对应用开发的影响。无论你是开发者还是对移动技术感兴趣的读者,这篇文章都将为你提供宝贵的见解和知识。
|
3月前
|
Android开发 开发者 Python
通过标签清理微信好友:Python自动化脚本解析
微信已成为日常生活中的重要社交工具,但随着使用时间增长,好友列表可能变得臃肿。本文介绍了一个基于 Python 的自动化脚本,利用 `uiautomator2` 库,通过模拟用户操作实现根据标签批量清理微信好友的功能。脚本包括环境准备、类定义、方法实现等部分,详细解析了如何通过标签筛选并删除好友,适合需要批量管理微信好友的用户。
134 7

热门文章

最新文章

推荐镜像

更多