论文分享 - 记忆网络之Key-Value Memory Networks

今天要介绍的这篇文章是Facebook在2016年6月发表的一篇文章,相比之前的两篇可以说是更加完美的将Memory Networks应用的了QA任务上。End-To-End那篇文章相比第一篇解决的强监督的问题,从而提出一种端到端的记忆网络,但仍然没有运用到QA的数据集上(虽然专栏的第三篇文章介绍了两篇使用该模型进行QA数据集训练的方法,但是模型的实际效果并不是很好,而且这种针对数据集的修改没有对模型本身进行创新,所以效果提升不明显),而本文在end-to-end的基础上对模型结构进行修改,使其可以更好的存储QA所需要的先验知识(KB或者wiki文章等)。

在这之前先看一下前面两篇文章提出模型的架构示意图来回忆一下:


此外本篇文章还提出了一个全新的数据集movieQA,同时提供了基于知识库和wiki文章还有IE数据库三种先验知识支撑,以便大家对不同知识源的效果进行比较。首先比较一下基于知识库KB和wiki文章的问答系统的区别和各自的优缺点:

  • 基于KB的QA,优点是KB具有高度的结构化组织并且有人工构建,所以便于机器处理。缺点是知识的覆盖面不全,会有遗漏和缺失,也就是有些问题在KB中本身就找不到答案,也就是其稀疏性,此外三元组中的实体可能会有变种表示,但KB中也为包含等各种问题。
  • 基于wiki 文章的QA,优点是覆盖面广,基本上所有的问题都能从中找到答案。缺点是非结构化、不直接、有歧义、可能需要多个文档经过复杂的推理才能找出答案等,也就是直接从文档中检索出问题的答案是一个很困难的问题。

基于这些,作者提出了一个新的数据集MovieQA,因为他觉得要想弥补wiki文章和KB系统之间的差距,应该先从一个简单领域(电影)开始,如果二者的gap被填上之后在推广到开放域即可。本数据集包含十万+的QA对覆盖了电影领域的,而且同时可以以KB、wiki文章、IE三种知识源为背景进行问答。接下来我们看一下论文提出的Key-Value MemNN模型,其结构如下图所示:

从上图可以看出来key embedding和value embedding两个模块跟end-to-end模型里面input memory和Output memory两个模块是相同的,不过这里记忆是使用key和value进行表示,而且每个hop之间有R矩阵对输入进行线性映射的操作。此外,求每个问题会进行一个key hashing的预处理操作,从knowledge source里面选择出与之相关的记忆,然后在进行模型的训练。在这里,所有的记忆都被存储在Key-Value memory中,key负责寻址lookup,也就是对memory与Question的相关程度进行评分,而value则负责reading,也就是对记忆的值进行加权求和得到输出。二者各自负责自己的功能,相互配合,使得QA过程的记忆和推理各司其职。接下来从细节的角度上描述一下模型:

  1. key hashing:首先根据输入的问题从知识源中检索出与问题相关的facts,检索的方法可以是至少包含一个相同的实体等多种方法。也就是上图中下面的绿色部分,相当于一个记忆的子集。这部分工作可以在与处理数据的时候进行。然后将其作为模型输入的一部分训练的时候输入模型即可。
  2. key addressing:寻址,也就是对memory进行相关性评分。用key memory与输入的Question相乘之后做softmax得到一个概率分布。概率大小就表明了相关程度。Qx与Qk都是embedding模型,对输入问题和key进行编码得到其向量表示。
  3. Value Reading:有了相关性评分,接下来就对value memory进行加权求和即可,得到一个输出向量。

这样就完成了一个hop的操作,接下来将输出向量o与输入问题的向量表示q相加,经过Ri矩阵进行映射,在作为下一层的输入,重复循环这个过程即可。每一层都会离答案更进一步,这里可以类比CNN模型进行理解,CNN处理图片时,第一层可以得到一些边缘特征,第二层得到车轮、车门等特征,最后一层得到车,同样,这里第一层可能得到与问题相关的一些答案,第二层得到具体的答案(可以参考end-to-end那篇文章,最后说了一下bAbI任务中,每个hop得到的结果分别是什么进行理解)。最后,我们在使用一个答案的预测层即可。

yi可以理解为所有的KB中的实体或者候选的答案句子(使用wiki文章时)。并且使用交叉熵作为损失函数即可,然后就可以端到端的对模型进行反向传播训练。整个过程看下来其实跟end-to-end模型很相似,那么最关键的地方加在于Key-Value的memory如何进行表示,这也是本模型的创新所在,接下来我们就看一下:

Key-Value memory的好处在于可以方便的对先验知识进行编码,这样就可以让每个领域的人都方便的将本领域内的一些背景知识编码进记忆中,从而训练自己的QA系统,相比于end-to-end模型将相同的输入经过不同的矩阵分别编码到Input memory和Output memory,Key-Value则选择对输入首先进行一个(key, value)形式的表示,然后再分别编码进入key和value两个memory模块,这样就有了更多的变化和灵活性。我们可以按照自己的理解对数据进行key索引和value记忆,而不需要完全依赖于模型的embedding矩阵,这样也可以使模型更方便的找到相关的记亿并产生与答案最相近的输出。然后论文根据不同形式的输入(KB或者wiki文章),提出了几种不同的编码方式:

  1. KB Triple:由于知识库是以三元组的形式构成,所以很方便的就可以表示为(key, value)的形式。这里首先将KB进行double,也就是将主谓宾反过来变成宾谓主,这样使得有些问题可以很方便的被回答。然后将每个三元组的主+谓作为key,宾作为value即可(可以想象,一般的问题都是主语干了什么事之类的,所以主+谓作为key可以更好的跟Question进行匹配,而宾语往往是答案,那么根据key找到相应的答案也就与想要的结果更相似,所以这样的组合很完美==)
  2. Sentence Level:以句子为单位进行存储的时候,与end-to-end模型一样,都直接将句子的BOW表示存入memory即可,也就是key和value一样。每个memory slot存储一个句子。
  3. Window Level:以窗口长度W对原始wiki文章进行切分(只取以实体作为窗口中心的样本),然后将整个窗口的BoW表示作为key,该实体作为value。因为整个窗口的模式与问题模式更像,所以用它来对问题相关性评分可以找到最相关的memory,而答案往往就是实体,所以将窗口中心的实体作为value对生成答案更方便。
  4. Window + Center Encoding:将字典double,使用第二个字典对窗口中心进行编码,这样能更精确的找到中心词。也会跟答案最相关。
  5. Window + Title:仍然使用窗口的BoW表示作为key,但是使用wiki文章的标题title作为value,因为对于电影信息而言,文章标题往往就意味这电影名称,所以更贴近问题的答案。这里还会同时保持Center Encoding的方式同时作为value进行训练。

至此,我们就介绍完了Key-Value memory networks的模型细节。今天先写到这,等下一篇在介绍模型的实现环节。


转载:https://blog.csdn.net/liuchonge/article/details/78143756

G
M
T
Detect languageAfrikaansAlbanianArabicArmenianAzerbaijaniBasqueBelarusianBengaliBosnianBulgarianCatalanCebuanoChichewaChinese (Simplified)Chinese (Traditional)CroatianCzechDanishDutchEnglishEsperantoEstonianFilipinoFinnishFrenchGalicianGeorgianGermanGreekGujaratiHaitian CreoleHausaHebrewHindiHmongHungarianIcelandicIgboIndonesianIrishItalianJapaneseJavaneseKannadaKazakhKhmerKoreanLaoLatinLatvianLithuanianMacedonianMalagasyMalayMalayalamMalteseMaoriMarathiMongolianMyanmar (Burmese)NepaliNorwegianPersianPolishPortuguesePunjabiRomanianRussianSerbianSesothoSinhalaSlovakSlovenianSomaliSpanishSundaneseSwahiliSwedishTajikTamilTeluguThaiTurkishUkrainianUrduUzbekVietnameseWelshYiddishYorubaZulu
AfrikaansAlbanianArabicArmenianAzerbaijaniBasqueBelarusianBengaliBosnianBulgarianCatalanCebuanoChichewaChinese (Simplified)Chinese (Traditional)CroatianCzechDanishDutchEnglishEsperantoEstonianFilipinoFinnishFrenchGalicianGeorgianGermanGreekGujaratiHaitian CreoleHausaHebrewHindiHmongHungarianIcelandicIgboIndonesianIrishItalianJapaneseJavaneseKannadaKazakhKhmerKoreanLaoLatinLatvianLithuanianMacedonianMalagasyMalayMalayalamMalteseMaoriMarathiMongolianMyanmar (Burmese)NepaliNorwegianPersianPolishPortuguesePunjabiRomanianRussianSerbianSesothoSinhalaSlovakSlovenianSomaliSpanishSundaneseSwahiliSwedishTajikTamilTeluguThaiTurkishUkrainianUrduUzbekVietnameseWelshYiddishYorubaZulu
Text-to-speech function is limited to 200 characters

猜你喜欢

转载自blog.csdn.net/jdbc/article/details/80657507
今日推荐