分享嘉宾:刘亮 美团 资深算法工程师

编辑整理:吴雪松

出品社区:DataFunTalk

导读: 在过去的20年中,搜索过程中处理查询的方式以及向用户显示结果的方式已完全改变。该过程已经从仅基于文本匹配的检索发展到现阶段——尝试基于对查询的真实语义理解以及上下文,位置,时间,用户的先前短期和长期浏览活动来获得搜索结果。本文主要介绍美团搜索场景下,查询理解系统的一些建设和相关的工作。主要围绕以下几点展开:

  • Query理解简介
  • 实体识别&实体链接
  • 查询改写
  • 意图识别

▌Query理解简介

1. 美团搜索

在介绍查询 ( Query ) 理解之前,我们先了解下美团搜索,左图是美团APP首页的截图,中间是美团承接的业务,可以看出美团的业务非常多,包括了像外卖、美食、酒店住宿等大家比较熟悉的业务,也有像婚纱摄影、机票预定等相对低频业务。顶部的搜索框,是美团搜索的主入口,美团的搜索就是通过这个搜索框来获取用户的查询Query,在理解查询Query后,对接到所服务的各种各样的业务品类,最后返回给用户想要的结果。

美团搜索是典型的O2O搜索,右图显示了对比传统的网页搜索以及电商搜索的一些差异。

首先是搜索目标,美团搜索的核心是提供服务,包括团单、套餐等本地生活服务。另外也会对一些信息和商品提供查询服务,像天气或者医美百科等;另外还有商品,相对于传统电商,美团主要是本地的一些商品,包括周边的便利店,周边的商场中的商超类的产品,以及周边能配送的商品的搜索。

另外一个重要的特点是基于位置的相关性比较高,因为O2O主要是基于本地生活的服务形态。供给约束方面,网页搜索基本不用考虑;电商搜索的供给是全国的商家,购买后全国配送;O2O场景下,从蜂窝到城市到全国这些维度都有涵盖,蜂窝是类似外卖这种业务,它的配送范围是很有限的,大概可能3~5公里的范围;像美食到餐团购类,是到店里消费,基本是一个城市维度的;另外像酒店旅游这种业务,它可能是全国性质的供给,所以说它涵盖的范围会比较广。

以上就是美团搜索的大概介绍。

2. QU

下面介绍下查询理解系统。QU ( Query Understanding ),主要利用基础NLP能力,对我们的用户输入的Query进行分析,产生一系列的基础信号,然后这些信号会应用到整个搜索链路的召回、排序等各个阶段。

举个例子来说的话,用户输入:杭州东附近的7天酒店,可以通过查询的变换,纠错和扩展,把杭州东扩展成杭州东站,扩大召回。

在往下是成分识别,这个后面也会重点介绍,包括了实体识别、实体链接,它可以把Query再进行一个成分粒度的识别,把杭州东识别成车站类的地理位置,7天识别成一个商家品牌,通过实体链接可以将杭州东对应的经纬度返回,7天链接到具体的品牌ID等。在最后是一些业务应用,包括查询意图的识别方面,我们还需要把它识别出它具体是本地意图,还是异地意图。

右图是我们目前线上应用的搜索结果,可以看到首先它识别出杭州东这个主点,并链接到了杭州东站这个实体。在意图方面,由于是在北京的搜索,但是我们需要找杭州东附近的酒店,所以会有异地的提示,最终的结果是在杭州东站坐标点一定距离半径内召回7天品牌酒店。

3. DQU

上图是查询理解DQU项目的架构。

公司有非常多的业务,很多业务也有自己的垂搜系统,在业务快速迭代的阶段是独立运行的,随着业务的不断发展,如何避免低水平重复建设,更好的积累技术、经验,平台就成了很有价值的工作。目前DQU的项目已经支持了公司内大部分的搜索场景,包括美团点评大搜,还有度假、住宿等业务频道内搜索。

整个框架分三个部分,最底层是基础信号层,主要是NLP相关基础信号模块,可以提供通用和业务个性化的信号输出。中间是业务逻辑层,适配不同的垂搜业务逻辑。最上层是适配层,对于不同的业务搜索可能有不同的接口,需要接口适配再返回最终结果。

接下来重点介绍下几个核心的查询理解模块。

▌实体识别&实体链接

1. 实体识别

① 简介

首先是实体识别,对比于通用网页搜索,电商和O2O搜索更多的是结构化的召回。举个例子,上图中间的“如家上地”,需要把它的商家和地址身份进行识别,然后对应到我们的Doc端,通过不同的字段进行召回。

因为在我们的场景下,Doc端的数据包含了很多结构化的字段,不同字段之间的语义差距会非常大,如果我们进行全字段检索,经常会出现一些语义漂移的问题。比如,搜“肯德基”,可能召回一个理发店,因为它的地址字段有“在肯德基对面”。所以我们需要结构化召回来保证更高的精度。其中NER是指导召回的关键信号。

② 整体架构

实体识别的整体框架,主要分两个部分:下面的离线端和上面的在线部分。

线上的识别来源主要分两部分,一部分是词典的实体匹配,一部分是模型预测,然后再往上是消歧策略,实体词典匹配,主要解决一些热门和词库里能够匹配的词,对一些长尾和泛化的词识别,还是依赖于模型。但是这两个部分中间的结果可能会有一些冲突,所以需要一个消歧策略,包括多粒度、多结果选择。我们主要通过一些模板规则,进行优先级的消歧,最终输出一个多路的结果,因为某些query会有粒度和类别的歧义。

离线部分主要是两个大的部分:一部分是实体挖掘,这个主要是为线上的实体匹配提供基础的实体库,模型方面主要是一些基础的模型训练、优化相关的工作。

③ 模型迭代

接下来讲一下NER模型迭代相关的一些工作。初期线上的模型主要是CRF,在19年引入了BERT模型。这里面主要是两个方面的改进,一方面是训练过程,引入了美团UGC的一些数据,用这些评论相关的数据进行预训练,补充O2O场景下的一些语义信息。再就是fine-tune阶段,我们除了人工标注语料的数据集,还有基于用户行为统计的半自动化生成的一些语料,来扩充训练数据。使模型训练效果,能够更好的拟合线上的应用。

④ 自动标注训练数据

这里简单介绍下,根据词典扩充训练数据的工作。

对于大规模的模型训练,语料是非常重要的一个部分,但是对于NLP任务,一般来说还是比较难以去自动化的获取这些训练语料,我们的一个核心思路是如何利用已有的标注数据、词典来指导内容半自动化的生成训练语料。首先用原始的人工标注语料,训练一个Model A,然后针对线上已有的实体库去预测打分,对打分有差异的部分,进行校正,然后把校正后的结果合并原始数据,再训练一个Model B,最终应用到线上。其中的核心就是校正的过程。

它的前提假设是,实体库和模型的质量,都是比较高的,但是其中模型预测和词典它中间还是有差异的部分,就是我们的模型预测相对于它可以提供更细的粒度。比如下面这个例子:“兄弟烧烤个性diy”,它其实是一个商家的名称,因为有比较全的美团商家库的信息,所以能够通过词典来挖掘出我们的商家信息。

但是模型预测的话,由于兄弟这个词,有影视类的电影,可能是电影名,模型也可能会识别错误,所以需要根据词典的信息进行修正。修正的方法是对模型预测的序列,进行轮巡替换,找出替换概率最高的一个,然后作为替换类型,最终生成一条校正后的训练数据,和原始数据进行联合训练。

⑤ 数据挖掘

另外一个部分就是离线词库的挖掘。

除了已有的商家库和一些结构化数据以外,线上的用户行为,也是非常重要的,怎么通过海量的用户行为数据,泛化我们的实体库,是我们的核心工作。这部分工作主要利用我们线上的用户点击日志,结合召回命中信息,来识别出Query的边界和类型,把用户Query中识别出的实体成分进行落库,同步到实体库中。

Query中的实体边界的切分,主要参考该Query召回的多个Doc结果的命中信息。由于我们是结构化召回,所以可能存在多个字段同时命中,通过统计所有Doc的命中分布情况,来考虑它的切分方式,最终转化成一个整数线性规划的问题,来寻求一个切分概率最大的方式,具体可以参考文章《美团搜索中NER技术的探索与实践》。有了这个切分边界后,再对它的每一个成分进行二分类模型识别,把识别概率比较高的目标成分,进行人工抽检,将符合要求的实体补充到实体库中。最终,通过这样的循环来扩充我们的实体库。

2. 实体链接

① 背景

下面再介绍一下实体链接的一些相关工作,美团搜索场景下的LBS属性,决定了很多用户都有地址类搜索的习惯,所以地址识别也是我们的一个重点。实体识别把地址成分识别出来之后,后面很重要的工作是把它的经纬度坐标找到,通过半径距离召回,满足用户搜索某个地址周边结果的诉求。这就需要实体链接把用户Query中的文本链接到具体的实体,并返回实体的属性。另外实体链接模块,本身还可以修正NER的结果。

② 整体框架

上图是实体链接的整体框架,它主要分为两个部分:

离线的部分,其核心是对所有物理实体mention的挖掘,其实就是实体的一个别名,用来扩大实体链接召回。

线上部分,首先通过别名进行实体召回,然后对召回的实体进行消歧排序。消歧主要结合Query文本序列的特征、基于地理位置的特征(比如城市和GeoHash),还有上下文的一些文本信息进行消歧排序,返回给用户最相关的Top实体。

③ 核心算法

核心算法如上图。离线部分,刚才也提到了主要是Mention的挖掘,目前基础数据,主要是商家库的数据、搜索日志、UGC评论、知识图谱等。Mention挖掘目前主要有三种方式:

  • 抽取式:对已有的核心实体库进行核心词的一个识别,然后再通过核心词的组合,来泛化出标准实体的一些别名
  • 挖掘式:主要是通过用户评论和搜索的点击session日志,通过用户行为挖掘用户对于实体的一些别名输入
  • 生成式:主要是通过Seq2Seq的一些模型,自动化的去生产一些泛化实体的别名

右下角是一些例子,比如说标准的别名,凯德茂望京,能够挖掘出它的一些相关的子成分(凯德mall)。

在线消歧部分,主要是一些相关性的计算和消歧排序,不再展开了。

▌查询改写

1. 背景

为什么需要查询改写?主要因为自然语言表达的多样性,首先是Query和Doc之间表达的差异,用户的Query会相对随意,而Doc端相对正规,商家和运营录入的商家介绍等相关字段,会标准化一些。另外一个问题就是一义多词,通常一个含义的表达会有非常多种输入的方式。

右图是线上真实的搜索日志,是“理发”相关的搜索词。可以看到有非常多的变换形式。还有一词多义的问题,比如:结婚照,它可能包含两类的含义,一类是要找婚纱照,另外还有可能是去拍结婚证需要的证件照,如果我们不进行Query查询的改写,直接通过原词文本匹配,很可能会漏召回。

2. 技术演进

查询改写这块,技术演进主要分4个阶段,最初是基于词典规则,它的优点是精度高,但是召回率非常低。后面加入了基于用户行为统计挖掘的相关扩召回的方式,但由于是基于整串的匹配,召回虽然有一定提升,还是没法满足线上用户很多长尾Query的搜索。

为了解决长尾问题,引入了基于翻译模型的统计翻译改写,主要是通过用户行为日志,训练翻译模型和语言模型,从子串片段级别来解决覆盖问题,极大的提升了改写的召回。但它的问题是会比较容易产生语义的漂移,因为它主要是基于文本对齐和文本替换的统计概率,并未考虑语义信息。所以我们又引入了基于Bert的语义规范化,进行过滤,很大程度的缓解了语义漂移的问题。

3. 为什么选择SMT

接下来重点介绍一下我们线上的翻译改写模型。

为什么要选择这样一个翻译模型呢?首先翻译所需的平行语料,在搜索场景下,比较容易通过搜索日志的Session来构造,甚至还可以用Query-Doc的点击数据来补充,通过这样的平行语料,就能够自动化的获取海量的标注数据,覆盖足够多的语言现象,解决表达多样的问题。

另外翻译模型很重要一个特点,是它能够支持子串级别的替换,并充分考虑上下文。所以说它能够很好的进行召回泛化。

4. SMT改写过程

这是SMT改写的一个大致的过程。它主要分为三个部分:

最上面是句对挖掘,通过海量的用户行为,包括Session、Query-Title、Query-Doc-Query数据,对这些数据进行特征抽取,然后再结合句对的判别模型,生成片段级别的对齐语料。

第二部分翻译模型训练,它的输入是上一步生成的对齐语料,然后生成N-gram的片段,再结合语义计算和统计规则,去生产翻译模型和语言模型。它主要是通过N-Gram这种方式进行子串级别的泛化。

第三部分是线上的解码和终判,主要考虑性能问题。因为线上替换时,子串候选解码如果不加限制,会产生组合爆炸的问题。所以结合了BeamSearch以及业务相关的过滤器,例如利用NER和实体链接的信息,对商家实体词限制改写,通过这样的一些业务特征来保证精度。通过路径裁减,返回概率最高的Top-K的结果,进行改写路径的生成。

▌意图识别

1. 背景

目前我们意图模块的核心是识别用户的业务需求,因为我们涵盖的业务品类非常多,不同的业务,展示模板和展示样式也都不同,比如酒店的查询,可能会有�