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

编辑整理：吴雪松

出品社区：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. 背景

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