回顾·神马搜索技术演进之路

转载自 DataFunTalk 公众号  http://www.6aiq.com/article/1535003242764

前言

国内搜索引擎大事记

1998年，Google发布；2000年，百度发布；2004年，搜狗发布；2006年，搜搜发布；2010年，Google退出中国；2012年，360搜索发布；2013年，神马发布，搜搜并入搜狗，百度收购91；2017年，微信推出搜一搜。

神马搜索简介

1.关于神马

神马搜索是阿里集团和UC共同推出的移动搜索引擎。依托于UC浏览器超三亿的用户量，以及阿里巴巴强大的技术背景和云端资源，使得神马搜索在移动搜索的技术性和广泛性、综合性等方面具有很大的优势。国内知名移动互联网第三方数据挖掘及分析研究机构比达咨询（BDR）发布《2018上半年度中国移动搜索市场研究报告》，报告显示，2018上半年度中国移动搜索流量市场份额中，神马搜索以21.8%的市场份额排名第二，搜索流量同比增长21.7%，增速排名第一。神马搜索作为阿里巴巴大文娱集团重要的智能咨讯媒体平台的主要产品之一，背靠阿里生态优势资源，尤其在资金、技术、人才，以及阿里整个战略拉通,让神马搜索的未来无限可期。

2.UC国内产品阵列

   UC国内的产品阵列，由UC浏览器，UC头条（UC浏览器首页的feed流新闻），神马搜索共同组成，以及我们刚才讲的语音助手和问答的APP，以上就是我对神马的简单介绍，下面我们分享下技术方面的事情。

神马搜索的技术演进

1.神马搜索相关性技术演进

其实整个搜索分为四个阶段，从13年之前主要重规则，重特征的一个阶段。大家都知道，谷歌在13年之前是没有上任何learning to rank的东西，他的特征计算也许用了机器学习，但排序全都是用规则来做的。大概从13年之后，learning to rank 普遍火了起来，各大公司普遍切换了learning to rank的算法，那个阶段是重规则重特征的一个阶段，就是说模型很重要，但是还会建立大量规则。一直到两年前，随着数据量的持续增长，有了大量的自动标注样本，DNN开始在NLP领域火了起来，并且确实有不俗的效果，所以很多公司开始了机器学习化，把大量的规则迁移到了机器学习算法，一直到今年。未来呢，我认为会是创新的阶段。搜索这么一个经典的问题，现在绝大多数竞争对手，都使用的是最新的技术。论文上有的技术，我们基本上都用了，还有工业界我们已知的技术，我们也基本上都用了。这个时候，你想做的比对手好，想从国内做到国际化，你一定要做一些不同的事情，这就是我们神马未来要做的事情，要做创新。

神马是一个比较年轻的搜索引擎，13年刚刚成立，所以神马直接从重规则，重模型这个阶段开始，整个神马战略在机器学习的使用方面是更激进的。我经历过很多家公司，对比之下，神马这边是机器学习化程度比较高的公司。

2. 搜索是天然的AI应用场景

这里有一个小故事，我做搜索应该有七年了，中间的时候做了一年AI，做知识图谱。算上实习的话，也算经历了百度、微软、搜狗，最后来到了阿里。上次换工作之前我在想，我做了五年多的搜索，每天做的事情基本都是一样的--就是分析bad case，找改进点，实验改进方法，再实验一种方法，再换一种方法试试，直到策略显著胜出或者放弃为止，周而复始。于是幸运的话，一个月改进了千分之一个点，不幸运的话，可能三个月改进万分之一个点。所以当时我实在是不想做搜索了。当时就给我一个前辈说，我不想做搜索了。前辈说那你想做什么呢，我说我想做AI。然后前辈就愣了一下，说那你还不是想做搜索吗？

为什么这么说呢，为什么我最终还是来到了神马做搜索。我后来是这么思考的，想做好AI的话，需要很多前提条件，而搜索恰恰是天然的AI场景。而且神马这边对搜索的视角很不同，很多公司为了做搜索而做搜索，神马这边除了做搜索业务，还要以搜索为阵地做AI的实践。

我们先来看搜索是天然的AI场景这句话，先说这句话对不对。大家可以想一下，我们要把AI做好的话，需要哪四个基本的要素：第一，我们要有数据，没有数据的话，没有办法训练模型，只能靠人工规则，那就只能有多少人工就有多少智能了，这不是大多数人想做的AI。第二，要有场景，AI要有真实的用户需求，我们不能伪造用户的需求，不能只是做出一个漂亮的东西来但没有人用。比如做出来一个alpha go确实很厉害，但是谁会用alpha go呢？我们需要一个真实的用户场景，使得我们的AI技术真正的落地。第三，我们需要人才，我们需要有大量经验的人才。比如我当时做知识图谱的时候，HR和我说你要招有五年以上工作经验的人，然而谷歌是在12年才推出知识图谱的概念，也就是说即使我们当时把谷歌最早的图谱团队的人挖过来，也只有4年工作经验。但是我们做搜索的话，真的是有工作经验10年以上的人才，这能够保证我们在这一个领域，去做一些比较难得事情。第四个是你要有一个商业化变现途径。一个好的AI应用，一定是既能够服务好用户的同时，又可以给公司赚钱，这样才是一个能够持续运行下去的生态。那搜索是一个什么样的场景呢，首先我们拥有千亿以上的网页数据，这是绝大多数公司所不具有的。同时，每天都有亿级用户的线上反馈，这样就产生了大量自动标注的样本用于深度学习训练。而且，我们有充足的资金进行标注支持。第二，搜索有很多AI真实的应用场景，比如说对query的理解，网页的理解，搜索的排序，相关推荐等，这些都是非常有难度的NLP应用场景，基于规则很难去做，所以天然对于AI有需求。第三，搜索积累了很多有经验的人才。搜索的话，大家会发现一个好玩的现象，它不仅能够吸引人才，积累人才，还能够输出人才。今天的很多新产品，比如抖音、今日头条，还有很多智能化新产品，其实都是搜索的人才过去做的。第四，搜索具有很大的市场，国内有千亿级人民币的市场，国际上大概是这个份额的五倍左右，而且南亚和东南亚，有大量的人口，且互联网刚刚兴起，他们就像是下一个中国，这个市场的潜力其实是非常大的。所以说，搜索真的是天然的AI场景，很幸运的是，我们的公司、战略决策层面看到了这一点。我们不仅为了做搜索，还为了锻炼我们的AI技术，去积累我们的AI人才。

3. 神马搜索的技术栈

做搜索首先要有一个好的系统框架，否则研发大部分时间可能会是在做系统运维。由于神马成立的比较晚，所以神马整个线上系统是基于zookeeper和yarn这种系统架构来做的。这首先可以保证很好的性能，可以从百亿级的网页中，搜索一个网页达到毫秒级，其次有很好的可用性，比如世界杯、高考一来，依旧可以提供很好的服务。当然这两项几乎所有的商业搜索公司都可以做到。后面两项就是神马做的比较好的。第三是良好的可伸缩性。很多时候公司需要对服务器进行增添或变更，比如说迁机房/扩容。我曾经经历过一次扩容，占用了三四个专家级同事前后两个月的时间，最后才把机器调整好。这个经常被称作“在行驶的火车上换轮子”，好像是完成了一件了不起的事情，但实际原因是系统框架无法给予高效的支持。在神马这边，基于zookeeper和yarn这种资源管理方法，一个运维，一个按钮，几分钟就可以把事情搞定。我觉得这才是了不起的事情。第四我们的系统有非常好的可扩展性，比如说我们想扩展一个功能的时候，或者想把大搜迁移给APP搜索用，或者做一个垂直搜索，可以非常方便的做到这件事情。以上是系统框架部分。

相关性计算技术是搜索中的核心技术。包括Learning2Rank的模型，DSSM/CDSSM这种基于深度学习的模型方法，也有传统的proximity、BM25的计算方法。这只是一部分，其实20年的搜索积累了非常多的技术。比如在召回方面，除了传统的词召回，大家普遍开始尝试向量召回。这部分后面我们详细说。

可能没有一个场景像搜索一样这么依赖自然语言处理，因为它处理的所有东西，都是需要自然语言处理，这里面包括Word embedding向量表示方法，DNN/CNN/RNN等深度学习模型，HMM/CRF这些传统的模型，包括最早积累的一些统计规则。这些都在神马里有深入的应用。

第四个是离线计算，包括我们怎么对DOM tree这种结构化的网页进行抽取，怎么进行链接分析，页面质量分析，爬虫的调度等。

4. 技术架构

下面看一下搜索引擎技术架构。首先我们要有一个爬虫系统，要把所有的网页信息都爬取保存下来以供检索；其次我们要有一个比较好的存储平台，我们这边有很多阿里云支持的存储服务；第三个我们要建索引，包括网页索引，框计算内容索引，还有结构化的知识图谱索引；在此基础上，我们就可以应用算法排序了，比如计算本文的相似度，基础排序，点击排序，learing2Rank模型, 深度学习模型；有了这些算法之后，我们还要加一些前端的业务逻辑，比如说搜索天气，这不是一个普通网页，是一个待插入的业务卡片。这就是整个搜索的架构，下面我们逐个详细讲一下其中比较核心的技术。

神马搜索的核心模块和技术挑战

5. Query理解

    query理解的任务都比较经典了。通过对海量的查询日志，点击反馈日志进行数据挖掘，我们可以做很多传统自然语言处理任务，比如说中文分词，新词发现，词性标注，句法分析。搜索在这些基础上，还有其专有的任务。包括query重要度的计算—比如用户输入十个词，其中有些词必须进行索引求交，有些词则可以不求交只参与排序。包括同义词挖掘—“魔兽怎么打开“，其实用户问的是“魔兽世界”。包括语言的纠错，如果用户输入错了，还需要帮助用户纠正过来。包括查询扩展，查询改写等。虽然这些都是很经典的任务，但还有很多有挑战的问题值得探讨，可以优化的。

Query理解的技术挑战

1. 如何处理缺少用户反馈的长尾query?

大家知道query分为长尾和头部，头部query有大量的用户点击，大量的用户反馈，点了哪个页面，在哪个页面上停留了多长时间。我们可以使用这些数据进行机器学习，得到很多的query特征；但是有很多长尾词，用户可能一个月只查一次，或者半年一次，甚至从来没有出现过。那我们如何处理这些长尾查询呢？如果用规则的话，长尾词的需求非常多样几乎无法被穷举；想使用机器学习，却没有任何样本；如何去做，是需要一些创新的想法的。

2. 如何处理NLP与排序优化的目标差异？

之前做NLP转做搜索的同学，比较容易遇到这个问题，比如“2019年俄罗斯世界杯”这里面哪个几词比较重要呢？如果从NLP的角度来考虑的话，2019年是一个时间限定词，世界杯是一个主题，俄罗斯是他的修饰词，俄罗斯世界杯可能举办了很多届，不一定是哪一届，但是2019年只有一届。所以从NLP的角度来看“2019年”和“世界杯”是重要的词。然而这个query有一个很大的问题，那就是2019年其实没有世界杯，俄罗斯世界杯是2018年举行的，用户输入错了。如果搜索引擎拿着“2019年”+“世界杯”去检索的话，没有一个好结果。反而拿着“俄罗斯：+”世界杯“去检索的话，能得到好结果。这就是NLP问题与目标排序不一致的问题。

3. 如何进行语义召回？

比如我们希望通过“腹部硬”的query召回包含“腹部肿块”的网页，从词级别上“硬”和“肿块”肯定不是同义词，但是语义上它们是一个意思。召回有两个方法可以做这件事情，基于词的召回可以只保留“腹部”做索引求交，我们也许能召回腹部肿块，但是要兼顾索引的效率：如果查询词只有一个的话，会召回上亿个页面，性能代价很大。第二种方法，可以采用向量召回，如何使用向量召回？我们假如使用DSSM模型通过用户的点击学习query的向量和title的向量，那我们就可以把query和title做向量化，做相似性计算。但是这种方法有什么问题呢？由于DSSM需要大量数据，人工标注不太现实，只能用自动标注样本。如果使用点击数据，这意味着训练的样本都是系统已经可以召回的样本，但是我们做向量召回的目的其实想要召回我们目前无法召回的样本，如果使用已经能召回的样本做训练难免在做重复的劳动。解决这个问题也需要一些创新的想法。

6. 排序模型

所有的搜索系统都需要经历索引归并、粗排、精排、LTR、rerank等流程，可能各个公司叫的名字不一样，但是意思是一样的。首先我们要进行索引归并，比如要查询ABC的话，我们可能要查询A and B and C或者A and （B or C）。库里有百亿级的网页，经过索引之后大概有百万级的网页，但是这个数量还是有点多，需要粗排从里面筛选出千级/万级的页面，然后再进行精排从中选出候选页面交给LTR做排序，最后经过业务逻辑的重排，最终就是大家看到页面的前十条结果了。今天主要说LTR部分，这也是对搜索效果影响最大的部分。

LTR所使用的特征有很多，它的特征除了原始特征外，也可以是上游机器学习模型的预测结果，包括Qanchor模型、点击指引模型、文本分类模型、质量模型、点击模型。以文本分模型为例，他的输入为文本匹配相关的特征，比如传统的CTR/CQR/BM25信息匹配特征，DNN/CNN/RNN算出的query-doc之间的相似度，还包括了相关词/同义词/主题挖掘所产生的特征。这些作为它的特征，使用文本标注样本进行模型训练，输出的值又作为LTR的输入。而LTR模型拿到所有这些模型特征后，使用query-doc相关性样本进行训练，得到最终的网页排序。LTR模型的设计我们单独展开来说。

（1）机器学习排序

机器学习排序首先是机器学习，但是又不完全一样。传统机器学习一般处理这几类问题：分类、回归、聚类。但是搜索引擎的机器学习解决的是排序问题，比如20条网页，或者上千条网页，你要给每一个网页打一个分，来保证按这个分数排序的网页顺序是对的，而不是保证分数本身是精准的，所以它的学习目标和普通的机器学习目标不一样。常用的模型包括Gbrank、LambdaMart、Xgboost、LightGBM，这四个模型我们都尝试过，也都改进过，比如我们在Fine tune、分裂点控制、Dart dropout做了改进。这里分享一个小经验，并不是越新的模型，效果越好，大家一定要根据模型的特性进行优化，然后达到最好的效果。但可以肯定的是经过优化之后，学习能力更强的模型，可以拿到更好的效果。

loss function常见的有三种：point-wise 、pair-wise、list-wise。point-wise是以单点误差作为损失函数，一个query-doc pair打一个分，机器学习就学习这个分数，这可以认为是一个回归问题。pair-wise的优化目标是所有的结果逆序数量最小化。比如说ABC三个网页，A最好BC其次，那ABC的顺序就是一个零错误的结果。List-wise优化的目标是List总体得分最大化，ABC打一个分,BCD打一个分，优化目标的是让List分数最高。工业界最常用的是pair-wise或者半pair-wise半list-wise。

样本方面一般使用多级标注方法。即给query-doc pair打一个0到4的一个离散的分，去根据这个分做机器学习排序。但是训练集的标注成本比较高，尤其是标注数量越多，往往增量标注的收益越小。我们这里采用的主动学习的方法，主动选择有收益的样本进行增量标注。

排序特征可以分为Query level、Doc level、query-doc三个类别。

（2）深度学习解决方案

在深度学习方面，我们的解决方案和大多数公司都差不多。输入分别是query和title，通过word embedding生成向量化表示，这两个向量然后通过神经网络NN生成sentence embedding。网络类型有多种选择，每种类型也有不同变种。比如DNN / CNN / RNN / ATTENTION或者对抗网络都可以。有了句子表示，接下来就是相似度的计算，一些常用的方法比如cosine / DNN / bilinear等，最后使用pairwise / listwise / dssm损失函数。这就是多数搜索公司都在用的深度学习解决方案。

（3）ML/DNN的技术难点

这里举两个例子：

1. 算法优化的挑战

之前搜索引擎由规则做的时候，优化方法很清晰。我们直接通过bad case找到导致bad case的规则进行修改。或者增加缺失的规则来修复bad case。但是换到全部基于模型来做的话，上面的方法就行不通了。影响模型效果的就三个：特征，样本，模型。因此机器学习的优化需要比较好的特征分析，样本分析和模型分析。如果是LR模型，特征分析很好做，直接看权重比较高的就可以，通过高权重的特征又可以追溯问题样本。但LTR模型多数是较为复杂的模型，这就需要有一套LTR专用的特征分析和样本分析方法。模型方面，当然可以使用通用的模型，但是在搜索场景下损失函数、求解方法、假设空间，是否有优化的空间呢？我们认为是有的，而且也拿到了确实的收益。

2. 业务实施的挑战

除了算法本身的分析和优化方法外，具体实施时还会遇到新的问题：比如模型如何debug、如何修复badcase、如何替换长尾规则—既要避免长尾样本被淹没，也要避免长尾样本拉低头部页面的排序。这里面是有很多充满挑战的事情需要做的。

7. 点击模型

前面我们所说的方法，都是网页通过自身特征证明自己好。还有一个维度：用户通过选择证明网页好。比如说用户每次搜一个词，都点那一个网页。通过用户的点击、滑动、翻页、停留时长等特征反馈网页好坏。但是点击模型也有自身的问题和挑战，包括位置偏置、数据稀疏、点击正反馈、真实不相关、点击泛化等问题。

——END