导读：在过去的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. 背景目前我们意图模块的核心是识别用户的业务需求，因为我们涵盖的业务品类非常多，不同的业务，展示模板和展示样式也都不同，比如酒店的查询，可能会有用户的入离时间展示模板。
所以需要把不同的业务需求识别出来，进行多形态的召回。
上面是我们意图的划分，包括左边的业务意图，例如美食、酒店、旅游等等，会直接访问业务相关索引进行召回。
中间是阿拉丁（开放平台），主要获取一些活动、第三方结果。
最右边还会有一些基于知识内容的信息类召回，比如根据评论内容召回结果。
最下面是对应的一些场景，比如时间、空间、人和事件的场景。
2. 整体框架意图识别的整体框架，主要分为两个部分：意图召回。
这块是转换为了分类任务，只判断某个查询是否包含某种意图。
线上采用词典匹配+规则+模型的方式进行识别，词典主要包含业务和领域相关数据，词典和Pattern规则，能比较好的解决热门识别，针对长尾部分，主要靠Bert模型来解决泛化识别问题。
意图分布。
意图召回完了以后，我们还要知道当前搜索的各个意图的强弱，尤其是找到主意图，就是图上面部分的意图分布，我们将其转化成排序问题。
由于线上展示的每条POI结果，后台都有明确的业务归属，所以我们就可以依据这个业务归属信息和用户点击行为，获得有标注的训练语料，来训练排序模型。
模型特征主要分为两部分，一是统计类的特征，包括一些CTR、CVR及相关的用户行为的特征。
二是Embedding类特征，来进行语义的表达。
▌总结和展望最后总结下，本文主要介绍了美团查询理解系统中的主要模块，包括实体识别、查询改写、意图识别。
查询理解是搜索引擎与NLP结合的产物，用来解决搜索相关的一些文本理解任务。
除了文本本身，后续我们还会考虑引入更多包括时空、用户，场景的信息来做到更深入的理解搜索场景下的用户查询意图。
今天的分享就到这里，谢谢大家。
分享嘉宾：刘亮美团 | 资深算法工程师刘亮，美团资深算法工程师。
9年搜索和NLP相关工作经验，目前是美团搜索查询理解方向架构师。
分享嘉宾：刘亮 美团 资深算法工程师编辑整理：吴雪松出品社区：DataFunTalk