首页 > 其他分享 >文本匹配(语义相似度)综述

文本匹配(语义相似度)综述

时间:2023-07-25 20:01:16浏览次数:30  
标签:场景 匹配 综述 模型 语义 打卡 文本 数据

目录

打卡的baseline模型

打卡的任务场景和数据集

一、相似度计算&复述识别(textual similarity¶phrase identification)

二、问答匹配(answer selection)

三、对话匹配(response selection)

四、自然语言推理/文本蕴含识别(Natural Language Inference/Textual Entailment)

五、信息检索中的匹配

六、机器阅读理解问题

打卡的Siamese结构(基于表示)

打卡的花式attention结构(基于交互)

打卡的学习方法

打卡的开源工具


文本匹配是一个很宽泛的概念,只要目的是研究两段文本之间的关系,基本都可以把这个问题看作是文本匹配问题。由于在不同的场景下对”匹配“的定义可能非常不同,因此文本匹配并不是一个完整独立的研究方向。不过有相当多的NLP任务可以建模成文本匹配问题,当它们建模成文本匹配问题时,当然会发现模型结构、训练方法等是高度高度相似的,却又有着微妙的不同。所以这个问题虽然跑个baseline简单,但是把具体的匹配问题中做好却并不容易(尤其是在有BERT之前)。
下面就来具体说说可以打卡的内容。
PS:关注「夕小瑶的卖萌屋」订阅号后台回复「文本匹配」可领取小夕打包好的论文大礼包噢~(包括正文中的papers)

打卡的baseline模型

无论具体的匹配问题是什么,有一些很好实现的baseline是可以不管三七二十一的直接跑一下的。

我自己最喜欢用的baseline是SiameseCNN这种结构的模型,毕竟从头手撸一遍非常快的,跑的又很快,效果又不错,训练又比较稳定,受超参数的影响相对较小。

文本匹配(语义相似度)综述_建模

 

模型大体结构如图所示,这里一般没必要实现的太花哨,一般就用一层CNN来分别encoding一下需要匹配的textA和textB,然后max pooling一下或再concat一个mean pooling得到两个文本的向量表示vecA和vecB(上图中的u和v)。

这之后可以直接套用一些公式如cosine距离、L1距离、欧式距离等得到两个文本的相似度,不过我们做文本匹配并不一定是希望判断这两个文本是否相似,除了相似关系外,还可以有问答关系、对话回复关系、文本蕴含关系等,因此更通用的做法是基于u和v构建用于建模两者匹配关系的特征向量,然后用额外的模型(比如MLP)来学习通用的文本关系函数映射。

这个特征向量可以像上图一样包括vec1, vec, |vec1-vec2|, vec1*vec2,也可以包括一些更加fancy的features,比如小夕常加的max(vec1, vec2)^2等,在一些匹配场景下有奇效。当然啦,更加靠谱的还是根据实际匹配场景的(bad)case来精心构造features。

如果对LSTM有执念,完全可以用lstm替代cnn来当sentence encoder,也就是使用SiameseLSTM结构,同样这里的encoder可以搭配各种预训练模型强化一下文本的向量表示。

燃鹅,其实有了BERT之后,我就更喜欢拿BERT来当baseline了╮( ̄▽ ̄"")╭,毕竟连代码都不用写了,更方便(经常baseline跑了一下发现问题解决了)。

打卡的任务场景和数据集

一、相似度计算&复述识别(textual similarity¶phrase identification)

这个可以说是文本匹配最典型最经典的场景了,也就是判断两段文本是不是表达了同样的语义,即是否构成复述(paraphrase)关系。有的数据集是给出相似度等级,等级越高越相似(这种更合理一些),有的是直接给出0/1匹配标签。这一类场景一般建模成分类问题。

代表性数据集:

  • _SemEval STS Task:_从2012年开始每年都举办的经典NLP比赛。这个评测将两段文本的相似度程度表示为0.0~5.0,越靠近0.0表示这两段文本越不相关,越靠近5.0表示越相似。使用皮尔逊相关系数(Pearson Correlation)来作为评测指标。链接[2]
  • _Quora Question Pairs (QQP):_这个数据集是Quora发布的。相比STS,这个数据集规模明显大,包含400K个question-question pairs,标签为0/1,代表两个问句的意思是否相同。既然建模成了分类任务,自然可以使用准确率acc和f1这种常用的分类评价指标啦。(知乎什么时候release一个HuQP数据集( ̄∇ ̄))链接[3]
  • _MSRP/MRPC:_这是一个更标准的复述识别数据集。在QQP数据集中文本都是来自用户提问的问题,而MRPC里的句子则是来源于新闻语料。不过MRPC规模则要小得多,只有5800个样本(毕竟是2005年release的数据集,而且人工标注,所以可以理解╮( ̄▽ ̄"")╭)。跟QQP一样,MRPC一般也用acc或f1这种分类指标评估。链接[4]
  • _PPDB:_这个paraphrase数据集是通过一种ranking方法来远程监督[]做出来的,所以规模比较大。文本粒度包含lexical level(单词对)、phrase level(短语对)和syntactic level(带句法分析标签)。而且不仅包含英文语料,还有法语、德语、西班牙语等15种语言(为什么没有中文!)。语料库规模从S号、M号一直到XXXL号让用户选择性下载也是很搞笑了,其中短语级就有7000多万,句子级则有2亿多。由于语料规模太大,标注质量还可以,因此甚至可以拿来训练词向量[5]。链接[6]

二、问答匹配(answer selection)

问答匹配问题虽然可以跟复述识别一样强行建模成分类问题,但是实际场景往往是从若干候选中找出正确答案,而且相关的数据集也往往通过一个匹配正例+若干负例的方式构建,因此往往建模成ranking问题。
在学习方法上,不仅可以使用分类的方法来做(在ranking问题中叫pointwise learning),还可以使用其他learning-to-rank的学习方法,如pairwise learning(”同question的一对正负样本”作为一个训练样本)和listwise learning(”同question的全部样本排好序“作为一个训练样本) 。因此,相应的评价指标也多使用MAPMRR这种ranking相关的指标。

注意:这并不代表pointwise matching这种分类做法就一定表现更弱,详情见相关papers

代表性数据集如:

  • _TrecQA:_包含56k的问答对(但是只有1K多的问题,负样本超级多),不过原始的数据集略dirty,包含一些无答案样本和只有正样本以及只有负样本的样本(什么鬼句子),所以做research的话注意一下,有些paper是用的clean版本(滤掉上述三类样本),有的是原始版本,一个数据集强行变成了两个track。链接[7]
  • _WikiQA:_这也是个小数据集,是微软从bing搜索query和wiki中构建的。包含10K的问答对(1K多的问题),样本正负比总算正常了些。链接[8],paper[9]
  • _QNLI:_总算有大规模数据集了,这个是从SQuAD数据集改造出来的,把context中包含answer span的句子作为匹配正例,其他作为匹配负例,于是就有了接近600K的问答对(包含接近100K的问题)。链接[10]

三、对话匹配(response selection)

对话匹配可以看作进阶版的问答匹配,主要有两方面升级。
一方面,对话匹配在问答匹配的基础上引入了历史轮对话,在历史轮的限制下,一些本来可以作为回复的候选会因此变得不合理。比如,历史轮提到过你18岁了,那么对于query”你今天在家做什么呢“,你就不能回复“我在家带孙子”了。

ps:一个价值五毛钱的例子(¬_¬)

另一方面,对于一个query,对话回复空间要远比问题答案空间大得多,对于问答类query,正确答案往往非常有限,甚至只有一个,但是对话类query却往往有一大串合理的回复,甚至有一大堆的万能回复比如“哦”,“好吧”,“哈哈哈”。很多时候的回复跟query在lexical level上基本没有交集,因此对话匹配模型更难训一些,数据质量稍差就难以收敛。因此做够了问答匹配,来做做对话匹配还是比较意思滴。
该问题一般使用Recall_n@k(在n个候选中,合理回复出现在前k个位置就算召回成功)作为评价指标,有时也会像问答匹配一样使用MAP、MRR等指标。

代表性数据集:

  • _UDC:_Ubuntu Dialogue Corpus是对话匹配任务最最经典的数据集,包含1000K的多轮对话(对话session),每个session平均有8轮对话,不仅规模大而且质量很高,所以近些年的对话匹配工作基本都在这上面玩。链接[11],paper[12]
  • _Douban Conversation Corpus:_硬要给UDC挑毛病的话,就是UDC是在ubuntu技术论坛这种限定域上做出来的数据集,所以对话topic是非常专的。所以@吴俣 大佬release了这个开放域对话匹配的数据集,而且由于是中文的,所以case study的过程非常享受。链接[13],paper[14]

四、自然语言推理/文本蕴含识别(Natural Language Inference/Textual Entailment)

NLI,或者说RTE任务的目的就是判断文本A与文本B是否构成语义上的推理/蕴含关系:即,给定一个描述「前提」的句子A和一个描述「假设」的句子B,若句子A描述的前提下,若句子B为真,那么就说文本A蕴含了B,或者说A可以推理出B;若B为假,就说文本A与B互相矛盾;若无法根据A得出B是真还是假,则说A与B互相独立。
显然该任务可以看作是一个3-way classification的任务,自然可以使用分类任务的训练方法和相关评价指标。当然也有一些早期的数据集只判断文本蕴含与否,这里就不贴这些数据集了。

代表性数据集:

  • _SNLI:_Stanford Natural Language Inference__数据集是NLP深度学习时代的标志性数据集之一,2015年的时候发布的,57万样本纯手写和手工标注,可以说业界良心了,成为了当时NLP领域非常稀有的深度学习方法试验场。链接[15],paper[16]
  • _MNLI:_Multi-Genre Natural Language Inference__数据集跟SNLI类似,可以看做SNLI的升级版,包含了不同风格的文本(口语和书面语),包含433k的句子对,链接[17]
  • _XNLI:_全称是__Cross-lingual Natural Language Inference。__看名字也能猜到这个是个多语言的数据集,XNLI是在MNLI的基础上将一些样本翻译成了另外14种语言(包括中文)。链接[18]

五、信息检索中的匹配

除上述4个场景之外,还有query-title匹配、query-document匹配等信息检索场景下的文本匹配问题。不过,信息检索场景下,一般先通过检索方法召回相关项,再对相关项进行rerank。对这类问题来说,更重要的是ranking,而不是非黑即白或单纯的selection。ranking问题就不能仅仅依赖文本这一个维度的feature了,而且相对来说判断两个文本的语义匹配的有多深以及关系有多微妙就没那么重要了。
从纯文本维度上来说,q-a、q-r匹配和NLI相关的方法在理论上当然可以套用在query-title问题上;而query-doc问题则更多的是一个检索问题了,传统的检索模型如TFIDF、BM25等虽然是词项(term)level的文本匹配,但是配合下查询扩展,大部分case下已经可以取得看起来不错的效果了。如果非要考虑语义层次的匹配,也可以使用LSA、LDA等主题模型的传统方法。当然啦,强行上深度学习方法也是没问题的,例如做一下query理解,甚至直接进行query-doc的匹配(只要你舍得砸资源部署),相关工作如

DSSM:CIKM2013 | Learning Deep Structured Semantic Models for Web Search using Clickthrough Data

CDSSM:WWW2014  | Learning Semantic Representations Using Convolutional Neural Networks for Web Search

HCAN:EMNLP2019 | Bridging the Gap between Relevance Matching and Semantic Matching for Short Text Similarity Modeling

六、机器阅读理解问题

同时,还有一些不那么直观的文本匹配任务,例如机器阅读理解(MRC)。这是一个在文本段中找答案片段的问题,换个角度来说就可以建模成带上下文的问答匹配问题(虽然候选有点多╮( ̄▽ ̄"")╭)。代表性数据集如SQuAD系列、MS MARCO、CoQA、NewsQA,分别cover了很多典型的NLP问题:MRC任务建模问题、多文档问题、多轮交互问题、推理问题。因此做匹配的话,相关的代表性工作如BiDAF、DrQA等最好打卡一下的。

BiDAF:ICLR2017 | Bidirectional Attention Flow for Machine Comprehension

DrQA:ACL2017 | Reading Wikipedia to Answer Open-Domain Questions

PS:

上述各个场景的模型其实差不太多,甚至一些方法直接在多个匹配场景上进行实验,近两年的paper也大多claim自己是一个非常general的匹配框架/模型。因此下面介绍打卡paper的时候就不区分场景啦,而是分成基于表示和基于交互来介绍打卡点。
注意:虽然基于表示的文本匹配方法(一般为Siamese网络结构)与基于交互的匹配方法(一般使用花式的attention完成交互)纷争数年,不过最终文本匹配问题还是被BERT及其后辈们终结了。因此下面两节请带着缅怀历史的心情来打卡,不必纠结paper的细节,大体知道剧情就好。

打卡的Siamese结构(基于表示)

这种结构就是本文开头提到的,首先对两段文本分别进行encoding进而得到各自的向量表示,然后通过相似度计算函数或相关结构来得到最终的匹配关系。
在baseline阶段提到的SiameseCNN和SiameseLSTM的基础上,这个方向往下做无非就是两个方向:
1. 加强encoder,得到更好的文本表示2. 加强相似度计算的函数建模
对于第一个方向,无非就是使用更深更强大的Encoder,代表性打卡工作如

InferSent:EMNLP2017 | Supervised Learning of Universal Sentence Representations from Natural Language Inference Data

ps:虽然这篇paper的真正目的是迁移学习

SSE:EMNLP2017 | Shortcut-Stacked Sentence Encoders for Multi-Domain Inference

对于第二个方向,则是使用更花哨的相似度计算函数或更花哨的用于学习相似度函数的网络结构,可打卡的工作如

**SiamCNN:**ASRU2015 | Applying deep learning to answer selection: A study and an open task

**SiamLSTM:**AAAI2016 | Siamese Recurrent Architectures for Learning Sentence Similarity

**Multi-view:**2016 EMNLP | Multi-view Response Selection for Human-Computer Conversation

显而易见,这个方向可玩性不强(虽然容易work但是paper写出来不够炫酷),所以不要问为什么只更新到了2017年,因为2016年attention就遍地开花了,自然大家基本都跑去赶潮做花式交互结构了。

打卡的花式attention结构(基于交互)

顾名思义,这种思路就是首先通过attention为代表的结构来对两段文本进行不同粒度的交互(词级、短语级等),然后将各个粒度的匹配结果通过一种结构来聚合起来,作为一个超级特征向量进而得到最终的匹配关系。
显然这种思路下,除了让文本对的交互更花哨以外,就是考虑让模型变得更深(从而建模更高level的匹配关系)。
不过个人经验来说,这种思路下虽然可以玩的花样很多,一些论文argue的点也看似有一些道理,不过实际很多模型都是在廖廖一两个数据集上疯(暴)狂(力)改(搜)进(索)各种structure才把分数刷上去的,导致这种structure看似在某个场景甚至仅仅是某些数据集上work,实际上这个structure可能仅仅迎合了特定数据分布或特定场景的一些特性,导致很多工作放到一个新场景下就效果翻车了,甚至努力调参都调不动太多。
因此在BERT之前这类论文提出的模型虽然看起来高大上,不过可能换个数据集后还不如稍微调调参拍拍脑袋的SiameseCNN好用。所以在刷这类论文时,千万不要被蜜汁花哨的模型结构迷惑了双眼噢~相关工作很多,从中挑选了几篇比较有代表性或比较有信息量或容易阅读的。
MatchCNN:AAAI2016 | Text Matching as Image RecognitionDecAtt:EMNLP2016 | A Decomposable Attention Model for Natural Language InferenceCompAgg:ICLR2017 | A COMPARE-AGGREGATE MODEL FOR MATCHING TEXT SEQUENCESESIM:ACL2017 | Enhanced LSTM for Natural Language Inference2018 COLING | Neural Network Models for Paraphrase Identification, Semantic Textual Similarity, Natural Language Inference, and Question Answering

ps:这篇paper其实可以看做是对前面各模型的实验和分析大总结

DAM:ACL2018 | Multi-Turn Response Selection for Chatbots with Deep Attention Matching Network**HCAN:**EMNLP2019 |Bridging the Gap between Relevance Matching and Semantic Matching for Short Text Similarity Modeling
此外,这里尤其要注意一下模型对称性的问题,像文本相似度计算/q-q匹配/title-title匹配这类场景下的匹配是对称的,即match(a,b)=match(b,a),但是模型不对称后,就会让模型自己额外的学习这个先验知识,除非数据集很大,或者已经预训练过了,否则效果很容易翻车。当然了,也有一些tricks可以强行使用不对称模型,即在这类场景下对每个样本都跑一遍match(a,b)和match(b,a)然后取平均,不过相比天然对称的模型效果如何就要看各位炼丹师的水平啦

打卡的学习方法

pointwise/pairwise/listwise learning这三种方法已经资料满天飞了,这里就不赘述了。这里给还不熟悉的小伙伴们推荐一篇文章[19]

打卡的pretrain models

虽然经过若干年的炼丹,靠model structure已经可以在非常多的文本匹配任务场景取得不错的效果了,但是实验证明,还是没法跟海量语料上pretrain的模型比的,先上一张图,问答数据集TrecQA上的实验结果:

文本匹配(语义相似度)综述_数据集_02

其中HCAN是EMNLP2019新提出的模型,虽然已经吊打了ESIM、DecAtt等老一代花哨模型,但是可以看到还是被BERT吊打了,更不必说跟XLNet、ERNIE2.0和RoBERTa等近期模型去对比了。所以真正大一统文本匹配任务的话,目前来看还是离不开大型预训练模型的。
当然啦,非要用传统的匹配模型的话,至少还有ELMo可以拿来强行续命【手动狗头】

打卡的开源工具

虽然文本匹配baseline容易构造,不过要在具体场景搭建一个完整的系统还是工作量比较大的,借助一些好用的开源工具可以大大提升开发效率。

MatchZoo[20]:一个通用文本匹配工具包,囊括了非常多代表性的数据集、匹配模型和场景,接口友好,非常适合拿来跑baseline。

AnyQ[21]:一个面向FAQ集和的问答系统框架,插件和配置机制做的很赞,集成了一堆代表性的匹配模型和一些检索模型,完整涵盖了Question Analysis、Retrieval、Matching和Re-Rank这4个做问答系统的全部必备环节。

DGU[22]:一个bert-based通用对话理解工具,提供了一套simple but effective的对话任务解决方案,一键刷爆各个对话任务(包括多轮对话匹配)的SOTA也是一个神奇的体验了。


标签:场景,匹配,综述,模型,语义,打卡,文本,数据
From: https://blog.51cto.com/xixiaoyao/6848917

相关文章

  • 使用jQuery在文本框中按Enter键
    使用jQuery在文本框中按Enter键jQuery是一个流行的JavaScript库,它简化了HTML文档遍历、事件处理、动画和Ajax等操作。在网页开发过程中,经常需要对用户的输入进行处理,并对用户的操作做出相应的响应。在这篇文章中,我们将介绍如何使用jQuery来检测用户在文本框中按下Enter键的操作,并......
  • 最好的PDF文本编辑开发库
     PDF文件是一种常见的文档格式,它具有跨平台、保持原样、安全性高等特点。但是,PDF文件也有一个缺点,就是不可编辑。如果我们想要修改PDF文件中的内容,比如文字、图片、表格等,就会很麻烦,需要转档为Word等其他可编辑的文档进行编辑后再转为PDF文件。为了解决这个问题,使我们工作中能够......
  • 【补充】富文本编辑器WangEditor
    【补充】富文本编辑器WangEditor使用Textarea·wangEditor用户文档【一】前端页面文本域<p>内容</p><br><div><textareaname="content"cols="40"rows="10"class="vLargeTextField"required=""id="......
  • R语言文本挖掘tf-idf,主题建模,情感分析,n-gram建模研究|附代码数据
    原文链接:http://tecdat.cn/?p=6864我们围绕文本挖掘技术进行一些咨询,帮助客户解决独特的业务问题。我们对20个Usenet公告板的20,000条消息进行分析 ( 点击文末“阅读原文”获取完整代码数据******** )。此数据集中的Usenet公告板包括新汽车,体育和密码学等主题。预处理我们首......
  • php - 支持word上传的富文本编辑器
    ​ 在之前在工作中遇到在富文本编辑器中粘贴图片不能展示的问题,于是各种网上扒拉,终于找到解决方案,在这里感谢一下知乎中众大神以及TheViper。通过知乎提供的思路找到粘贴的原理,通过TheViper找到粘贴图片的方法。其原理为一下步骤:监听粘贴事件;【用于插入图片】获取光标位置;【......
  • asp - 支持word上传的富文本编辑器
    ​ 如何做到ueditor批量上传word图片?1、前端引用代码<!DOCTYPE html PUBLIC "-//W3C//DTDXHTML1.0Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head>......
  • asp.net - 支持word上传的富文本编辑器
    ​  自动导入Word图片,或者粘贴Word内容时自动上传所有的图片,并且最终保留Word样式,这应该是Web编辑器里面最基本的一个需求功能了。一般情况下我们将Word内容粘贴到Web编辑器(富文本编辑器)中时,编辑器都无法自动上传图片。需要用户手动一张张上传Word图片。如果只有一张图片还能......
  • 二进制和文本文件的区别
    1.磁盘文件概述磁盘文件在物理上都是二进制存储从用户或者操作系统的角度(逻辑上),把文件分为文本文件和二进制文件1.1文本文件基于字符编码的文件(即不管是数值还是字符串,一个符号对应一个字节)。常见的编码有ASCII、UNICODE等。一般可以使用文本编辑器直接打开。1.2二进制......
  • 文本指纹算法 Java工具
    文本指纹算法Java工具1.什么是文本指纹算法文本指纹算法(TextFingerprintingAlgorithm)是一种用于比较和识别文本相似度的算法。它的原理是将文本转换为一串短的二进制序列,即文本指纹,通过比较文本指纹的相似度来判断文本的相似程度。文本指纹算法在文本比较、文本搜索、版权保......
  • 为什么文件后缀改了.java显示还是文本文件
    为什么文件后缀改了.java显示还是文本文件在计算机中,文件后缀用于标识文件的类型。根据文件后缀,操作系统会使用相应的程序来打开、编辑或执行文件。例如,文件后缀为".txt"的文件会被认为是文本文件,并使用文本编辑器打开。而文件后缀为".java"的文件则会被认为是Java源代码文件,并使......