首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >微信智言夺冠全球对话系统挑战赛,冠军解决方案全解析

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

作者头像
机器之心
发布于 2019-03-21 09:36:26
发布于 2019-03-21 09:36:26
1.1K0
举报
文章被收录于专栏:机器之心机器之心

如何利用端到端的对话系统基于 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 亿个句子。

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

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

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

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

模型架构

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

上图展示了该系统的整体架构,包括数据预处理、对对话历史和 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,然后对二者执行注意力机制,即解码器在每个时间步中通过注意力机制关注编码器输入的不同部分。然后利用模式预测和输出词概率估计来计算最终的单词概率分布。

解码步流程。微信团队使用 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 层进行模式预测。

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

Beam search 解码策略

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

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

模型训练 trick

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

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

  • 实现地址:https://github.com/abisee/pointer-generator

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

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

关于微信智言

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

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

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

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

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

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2019-03-20,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 机器之心 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
MYSQL-数据引擎(InnoDB)
作者介绍:简历上没有一个精通的运维工程师,下面的思维导图也是预计更新的内容和当前进度(不定时更新)。
运维小路
2025/09/30
1620
MYSQL-数据引擎(InnoDB)
MySQL-8.0 | 数据字典最强解读
数据字典(Data Dictionary)中存储了诸多数据库的元数据信息如图1所示,包括基本Database, table, index, column, function, trigger, procedure,privilege等;以及与存储引擎相关的元数据,如InnoDB的tablespace, table_id, index_id等。MySQL-8.0在数据字典上进行了诸多优化,本文将对其进行逐一介绍。
数据和云
2019/05/13
4.3K0
数据字典
我个人是比较讨厌数据字典这个功能的,前期十分抵触这个功能,但是京东项目强制要求使用数据字典。于是整理一下数据字典这个功能与概念。
收心
2023/02/22
1.1K0
MySQL 8.0 数据字典表
MySQL 8.0 对数据字典进行了重构,用户表、数据字典表、MySQL 其它系统表的元数据都统一保存到 mysql 库的数据字典表中了。
csch
2022/12/20
2.1K0
MySQL 8.0 数据字典表
MySQL数据字典提示1146不存在的问题解决
最近某套MySQL因为磁盘挂载问题,异常宕机,拉起后,数据库能正常访问了,但是在error.log一直提示这个错误,
bisal
2021/09/18
1.3K0
MySQL数据字典提示1146不存在的问题解决
MySQL8.0​ 字典表增强的意义
MySQL中数据字典是数据库重要的组成部分之一,INFORMATION_SCHEMA首次引入于MySQL 5.0,作为一种从正在运行的MySQL服务器检索元数据的标准兼容方式。用于存储数据元数据、统计信息、以及有关MySQL server的访问信息(例如:数据库名或表名,字段的数据类型和访问权限等)。
MySQL轻松学
2020/06/23
9580
MySQL 8.0新特性 — 事务性数据字典与原子DDL
事务性数据字典与原子DDL,是MySQL 8.0推出的两个非常重要的新特性,之所以将这两个新特性放在一起,是因为两者密切相关,事务性数据字典是前提,原子DDL是一个重要应用场景。
brightdeng@DBA
2020/08/17
2K0
MySQL 8.0新特性 — 事务性数据字典与原子DDL
[MYSQL] frm2sdi (2) sdi内容讲解
除了在数据字典中有元数据信息外, mysql还在ibd里面存储了该数据文件对应的表的元数据信息.这部分信息就叫做 Serialized Dictionary Information (SDI). 数据格式是我们常见的json格式.
大大刺猬
2025/01/20
4620
RocksDB和Innodb引擎性能PK胜负难料?
迫于线上环境存储空间的问题,最近针对Rocksdb引擎做了一些预研测试,本文主要对比MyRocks引擎和Innodb引擎以及压缩模式下的Innodb引擎的在性能方面的一些差异对比,分别从读写,只读,只写等场景下压测的结果对比;关于rocksdb引擎的介绍,本文不做详细介绍;废话不多说了,我们先看一下如何来安装rocksdb引擎;
SEian.G
2021/04/15
4.8K0
RocksDB和Innodb引擎性能PK胜负难料?
MYSQL INNODB ibd文件详解 (3) FIL_PAGE_SDI
虽然上一章已经提取了DDL, 但是存储DDL的sdi页还没有讲.... 现在补上呗..
大大刺猬
2023/04/25
1.1K2
MYSQL INNODB ibd文件详解 (3) FIL_PAGE_SDI
MySQL 8.0数据字典有什么变化
从MySQL 8.0开始,采用独立表空间模式的每个InnoDB表只有一个 .ibd 表空间文件,而不再有 .frm 文件了。为了实现DDL的原子性,InnoDB直接把元数据存储在表空间文件中,需要的话,可是使用 ibd2sdi 工具从中读取,例如:
老叶茶馆
2022/12/02
1.1K0
MySQL InnoDB引擎
表空间是InnoDB存储引擎逻辑结构的最高层, 如果用户启用了参数 innodb_file_per_table(在8.0版本中默认开启) ,则每张表都会有一个表空间(xxx.ibd),一个mysql实例可以对应多个表空间,用于存储记录、索引等数据。
用户9615083
2022/12/25
1.8K0
MySQL InnoDB引擎
深度解读 MySQL 8.0 数据字典重构:源码解析与实践
今天我要给大家分享一些自己日常学习到的一些知识点,并以文字的形式跟大家一起交流,互相学习,一个人虽可以走的更快,但一群人可以走的更远。
喵手
2024/10/29
3330
深度解读 MySQL 8.0 数据字典重构:源码解析与实践
MySQL8.0之数据字典
MySQL 8.0 将数据库元信息都存放于InnoDB存储引擎表中,在之前版本的MySQL中,数据字典不仅仅存放于特定的存储引擎表中,还存放于元数据文件、非事务性存储引擎表中。本文将会介绍MySQL 8.0对数据字典的改进,以及改进带来的好处、影响以及局限性。
沃趣科技
2018/05/15
3.5K1
MySQL8.0之数据字典
MySQL 5.7 General Tablespace学习(r11笔记第34天)
MySQL里面的文件蛮有意思,之前大体有两个参数来做基本的控制。一个是innodb_data_file_path就是一个共享表空间,数据都往这一个文件里放,也就是ibdata1,这个文件其实角色是有重复的,undo,数据都会放在一起。ibdata1会持续增长,无法收缩。另外一个参数是innodb_file_per_table,这样一来,就成了独立表空间,通俗一些就是每一个表都有独立的文件.frm和.ibd,而且实际中使用独立表空间还是比较普遍的,对于delete的操作影响MySQL和Oracle就大大不同。
jeanron100
2018/03/21
1.4K0
MySQL 5.7 General Tablespace学习(r11笔记第34天)
MySQL 8.0初体验
从决定安装MySQL 8.0到开始行动,也就不到一个小时的时间,一个小时的时间能干些啥呢,来简单体验下8.0,官网上能看到这个丰富的表情包。
jeanron100
2018/07/26
8710
MySQL 8.0初体验
mysql 寻找SDI PAGE
对于原本就是8.0环境的ibd文件, 第4页就是SDI PAGE, 之前的ibd2sql也是直接解析第四页得到的.
大大刺猬
2023/10/13
3940
MySQL 8.0 information_schema.tables表和之前版本的差异
在做自动化运维开发过程中,需要从information_schema.tables获取MySQL表相关的元信息,发现MySQL8.0和5.7存在的差异还是比较大的;在MySQL8.0以前,通常会通过infomation_schema的表来获取一些元数据,例如从tables表中获取表的下一个auto_increment值,从indexes表获取索引的相关信息等。
SEian.G
2021/12/13
2K0
详解MySQL-8.0数据字典
提示:公众号展示代码会自动折行,建议横屏阅读 ---- 1. 引言 ---- 数据字典(Data Dictionary)中存储了诸多数据库的元数据信息如图1所示,包括基本Database, table, index, column, function, trigger, procedure,privilege等;以及与存储引擎相关的元数据,如InnoDB的tablespace, table_id, index_id等。MySQL-8.0在数据字典上进行了诸多优化,本文将对其进行逐一介绍。 图1 2.
腾讯数据库技术
2019/05/16
7.1K0
详解MySQL-8.0数据字典
MySQL 8.0新特性之原子DDL
MySQL 8.0 开始支持原⼦ DDL(atomic DDL),数据字典的更新,存储引擎操作,写⼆进制日志结合成了一个事务。在没有原⼦DDL之前,DROP TABLE test1,test2;如遇到server crash,可能会有test1被drop了,test2没有被drop掉。下面来看下在MySQL 8.0之前和MySQL 8.0 数据字典的区别。
星哥玩云
2022/08/17
5490
MySQL 8.0新特性之原子DDL
相关推荐
MYSQL-数据引擎(InnoDB)
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档
首页
学习
活动
专区
圈层
工具
MCP广场
首页
学习
活动
专区
圈层
工具
MCP广场