心法利器
本栏目主要和大家一起讨论近期自己学习的心得和体会，与大家一起成长。具体介绍：仓颉专项：飞机大炮我都会，利器心法我还有。
近期，我再次总结了我的历史文章，累积起来有50w字，百余篇文章了，有兴趣可以拿来看看，获取方式：七夕清流，百余篇累计50w字文章合集发布。
往期回顾
背景
语义相似度问题已经不是很新颖的问题，甚至都已经开始往无监督、自监督之类的方向卷了，但是到了实际落地的时候，却很难说能解决的很好，其中一个很典型的问题，就是和句子长度相关的问题了，无论是长-长、长-短还是短短，其实都会有大量解决不好的情况，尤其在搜索、对话等场景，用户的大部分问题非常灵活，有比较喜欢精简直接的短句，也有力求清晰而把问题描述仔细的长句，我们会发现，这种情况的出现往往伴随语义相似度的骤降，从而导致出现了miss的情况，本期给大家介绍一下，并给大家介绍我遇到的比较好的解决方案吧。
原因和机理分析
通过对很多case的分析和调研，我发现导致长短句匹配没有符合我们的预期，其实主要是这几个问题：
开放域问题和业务的区别问题。
信息冗余和弥散问题——针对长句，包括长-长和长-短。
信息的缺失——针对短-短的情况。
然后我来一个一个讲。
开放域和业务的差距
语义相似度已经是一个打榜非常成熟的任务了，而这些任务大部分其实都是开放域的居多（当然也有类似BQ_corpus之类的特定领域的），此时我们是有一个共同也相对明确的，但是到了我们实际应用的时候，其实所谓的“语义相似”的概念其实就非常模糊了。
以电商一个空调相关问题场景来举个例子吧。假设A1和A2是两个空调的型号，来看这两个pair：
A1多少钱，A2多少钱。
A1无理由退货，A2无理由退货。
在业务的定义下，第一个pair答案是不同的，需要给出不同的价钱，所以我们其实并不希望他们能分在一块认为是1，但是第二个pair由于业务的定义，都归类于无理由退货的问题，此时却认为他们相似，这点和开放域的定义是完全不同的，这两个pair在开放域里面，因为实体的不同其实我们不会认为他们是相似的，但在业务里面，运营人员的角度趋势更倾向于认为后者相似，毕竟是一类典型问题。
当然这不是长短句，那就来一个长短句的例子，极端一点：
我上周买的空调，前天修好了，昨天还能用，但是今天却无法开机了，怎么回事？现在好热啊，希望能快点回复，感谢感谢。
空调无法开机。
同样的，开放域里会认为信息量上就存在巨大差距，意思差距太大，是可以认为是负类的，但是在业务角度，用户本质就是在阐述一个空调无法开机的问题，所以应该认为相似，至少在众多答案中这个应该是排在前面的。
从这几个例子可以看到，业务的定义会让我们对语义相似的概念产生偏移，这点偏移让很多我们常用开放域的语义相似度定义和思路来分析并不完全可取。
信息冗余和弥散问题
继续取这个例子：
我上周买的空调，前天修好了，昨天还能用，但是今天却开不了机了，怎么回事？现在好热啊，希望能快点回复，感谢感谢。
空调无法开机。
我们聊到，第一句和第二句不相似的根本原因就是第一句信息太多，而相比之下第二句没有这种信息，这就导致模型也好，人也好，很难直接认为他俩就是相似的，我们可以从两个角度来看这个问题，一个是信息冗余，一个是信息弥散。
首先是信息冗余，这个很好理解，对于语义相似度本身，其实第一句话只有“空调”、“开不了机”这两个信息是有用的，其他的其实都是冗余信息，冗余信息势必会影响到我们对句子的理解和判断，直观的，我们要看完句子然后分析，这个分析成本理应更高，难度也就更大，这里要求模型也是如此，要找到最关键的信息然后进行匹配。
进一步是信息弥散，从浓度而言，或者大家所谓的“干货”，其实就是讲的关键信息的含量，都是一滴墨水，滴在一勺水和滴在大海里是完全不同的效果，而在模型或者统计规则的角度来看，整体的语义比对大都是要经过把“每个词”或“对应信息”的特征加权求和或者池化等统筹的过程，说白了要把全局信息进行综合考虑得到，此时，过多的信息就会稀释句中原有的关键信息，重要性下降，从而导致匹配难度加大很多。
这个问题，其实无论在长-长还是长-短句，大部分都是这个问题。
信息的缺失
针对短-短句的信息缺失问题，之前的文章有提过一个点，要让模型学好，首先需要确认我们提供给模型的信息是否足够（心法利器[45] | 模型需要的信息提供够了吗），造成短句miss的大部分问题，往往就是这个导致。来一个例子：
Java-渣瓦-1。
叉烧-叉烧包-0。
根据业务定义，是会存在这些情况，哪怕让模型学，其实难度也很大，因为“模型没见过”，人对没见过的事物大都是按照历史经验来判断，模型也是如此，他会根据自己所学习的样本来进行分析，而这里从人来看最简单的信息就是字面信息，毕竟样本里多少也有体现出这个现象——文字层面相同的相似的可能性更好，而字面大部分不同的就很难相似了，因此对上面两个case，模型很难不分错。
解决方案
短短句
首先先来聊短短句的问题，毕竟这个会比较简单一些。
简单的说，其实这块问题本质就是一个同义词问题，所以最好的解决方式就是用词典来处理，当然复杂的，将句子进行规范化改写后在进行匹配也是可以的，但这里的关键其实就在于对同义词的挖掘，这点真的是需要具体业务去查找和挖掘，设置是在一些物料里面挖掘，都是非常有必要的。因为这个是一个强信息依赖的问题，找不到、告诉不了模型，那模型就是不会，这个绕不过去的。
长句问题
无论长-长还是长-短，其实没什么太大差别，本质还是要解决长句信息冗余的问题。这里介绍几个关键思路吧。
首先，最直接的做法就是改长句为短句。通过关键词抽取、切句抽句、丢词甚至是摘要等手段，将长句转化为短句，尤其是能代表句子关键信息的短句，这样就解决了长句的问题。
其次，针对长-短这种情况，考虑使用单向句子相似度的方案，之前我提到的ctr-cqr（心法利器[18] | cqr&ctr：文本匹配的破城长矛）其实就是单向的相似度，短句对应的相似度偏高的一般都是可以认为相似的，例如这个例子：
Query：我上周买的空调，前天修好了，昨天还能用，但是今天无法开机了，怎么回事？现在好热啊，希望能快点回复，感谢感谢。
Title：空调无法开机。
这里的ctr应该不会太低，所以这种方式是有效解决长短句问题的。
第三，模型层面的控制。长句的匹配核心需要考虑的是两句的关键信息是否相同，所以attention是非常关键的措施，这也是为什么attention机制为什么会受到关注的原因，尤其是交互式，能充分提取两个句子两者视角下的关键信息从而进行匹配，能更契合这种问题，早期abcnn之类的方案其实都有体现出这个思想出来。但值得强调的是，我们是可以通过这个机制构造模型来进行解决，可是如何定义attention，什么叫做重要，这是需要我们在数据层面给模型解释清楚的，让模型知道什么是值得attention的，什么不是，只有这样，attention才能够生效。
第四，根据信息弥散情况对容忍度进行控制。在前面的分析汇总我们其实可以发现，句子越长，其实相似度会更倾向于下降，这个无可厚非，但既然如此，我们是可以设计一个机制，对语义相似度的阈值进行控制，随着句子长度的增加降低认为是相似的阈值，这种方式也能有一定收益。
第五，就是把多种和长度相关的因素构造成特征，用类似wide&deep的模式将语义信息和长度信息，甚至是单向句子相似度信息进行整合，构造出一个合体模型来处理，当然这样的构造方式，其实就已经是将语义相似度任务在向精排模型之类的方向过渡了。
思路启示
看完之后大家其实多少有些发现，语义相似度这类型的问题对业务有非常高的依赖度，本质其实是通用和业务的矛盾，从自己做过开源数据的角度来看，开放域对语义相似度的概念往往更加严格，但对边界更加明确，而业务则会有非常强的所谓的严格定义，这和开放域不同，但又在边界上很模糊，而相似度这个问题，在中学相信大家也有些感受，全等三角形的判别定理和规则十分清楚明确，内容并不是很多，但是相比之下相似三角形却花了大量时间来学习讨论甚至论证，其实就是因为相似这个相对模糊的定义。回过头来，语义相似度在工业界落地背后的一大难点就是业务对他的定义是困难的、复杂的，甚至是可变的，我们在设计、分析和讨论过程中，也确实要考虑到这些因素。
1649
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
