文｜见鹿@知乎
本文已获作者授权，禁止二次转载

搜索引擎是个极其复杂的系统工程，搜索引擎上并不会大力出奇迹，需要一点点打磨。在搜索引擎上，q-u相关性计算是基础，但仍需要考虑其他很多因素，其中非常重要的两点就是权威性和时效性。

不同的query下，一直都会有新的资源产生，但不是说所有query下都需要将新资源排序、展示出来。有一类query，在这些query下用户期待看到最新的新闻事件搜索结果。搜索引擎需要将这部分突发需求识别出来，并且将其相关的新资源尽可能排上来。

例如：在科比去世（2020-01-27 R.I.P）的背景下，此时当用户在搜索引擎上搜索"科比"时展示的结果，可能跟几分钟前的展示结果差异很大。

或是“武汉爆发新型肺炎”这类query,可能平时没出现过，属于低频冷门词，但用户想看的就是最近的结果。

诸如此类的需求变化识别，搜索引擎在自动化识别的过程中，遇到哪些challenge？

注：有一部分query需求也是一直要求"实时新"，如天气，汇率等需求，这部分query形态比较稳定，并且对这部分query而言“唯一不变的就是变化”，这部分需求识别先不放在本次讨论中，我们讨论的是这种明确有事件性质的识别，可能结果形态和平时不同的case。

召回问题：这类query的占比低，因为如果没有识别召回，则基本上通篇检索结果，都不会满足。假如：科比去世背景下，“科比”如果没有被识别出来，则通篇不会有其飞机失事的新闻结果。

准确率问题： 由于其有特殊的地位权重，就要求对识别的准确要求也很高。

识别速度： 准召高就好了么？并非如此，因为新闻事件通常生命周期很短，若是事情已经过去1天了才识别出来，热度的高点都过去了。识别速度也非常关键。通常我们是要做到分钟级识别。

一个新闻事件的发生，会激发出好多周边需求，而这些需求分布很泛很散。

从很多统计信号上，根本不好区分。白百何出轨事件下，“失恋三十三天”频次pv增加50w...

快速识别出来不是目的，将真正的优质新结果展现到合理的位置才是。

需要上游分钟级别的抓取、建库、流式数据建设，又需要下游的召回、排序、pk机制效果保障。

每天数十亿的pv请求，每次pv又要去数千亿的网页库中查找召回，再做上层排序，每次开销是很大的，势必需要上层对于中高频的query做cache缓存。

而cache缓存和新结果的识别又是天然矛盾。缓存存在的意义就是不下发查找，而识别依赖查找，总要有一定的机制去指导去做主动更新。

通常一个事件，发生事件只在几天只能，对齐评估标注，需要考虑当时的情景。而且特别是事件刚刚爆发下，需要在分钟级内对其进行现场录制比较。

这个评估非常非常的耗费人力物力，超乎一般的想象。

对于刚刚发生的事件而言是分钟级别影响，可能5min之后就是完全另一个效果展示了。因为突发识别的有无、强弱影响很大。“九寨沟地震”背景下，可能就在短短几分钟之内搜索“九寨沟”的展示就差别很大。

若是有问题，需要及时抓取记录，否则无法事后进行分析。

资源、频次等都是瞬息万变的，所以即便做了模型、策略优化。

也很难回归之前的历史问题case,需要将很多很多的信号全都dump下来，才有可能去回归效果。这需要架构方面的大力支持。

有的事件虽然有识别，搜索引擎也知道它是新闻事件，但若它有最新的进展，则本质上在这个时间点后面的检索需求又发生了改变。如何识别出这个时间点，已经将这个时间点后面的资源做优质的boost，仍是一个比较大的挑战。

例如：“欧冠决赛”，假如比赛刚刚结束了，新的结果已经产出，此时的搜索就需要将最新的比方结果给出，而不是上半场的播报，或是半天前的赛前分析了。“无锡高架桥死伤”，若官方出了最新通报，这之前的死伤结果就不是所需要的了。

这部分case真实占比还不算低。

在抓取建库时需要做页面分析，需要对流量作弊做分钟级别的控制。但处于实际效率，对于高时效部分的pv在反作弊上的工作有所折衷。anti-spam的一些漏网之鱼会给整体识别带来不小的麻烦。

尤其是一些商品，加盟等有高危影响的方面。

同一个事件，在这么大量级的用户群体中，会出现成百上千个不同的描述。

如何找到同一事件后相同query间的关系，并利用这个关系，是一个很大的挑战。

大的新闻站点，也并不是那么可信。包括熟知的一些非常大的新闻站点。

这超乎了很多的想象。

不信你可以统计你资讯app上推送的内容，以及新闻站点/app上随机看，看看到底有多少是真正的新闻的比例。或许你就懂了。

一些地方性、领域性的事件，甚至对于你而言非常小，但对他而言，有确实是一个新闻事件按需求，我们每个人都会有这样的需求。

例如某个县的副县长xxx被开除党籍、xxx小区着火，甚至“西二旗路面大坑”，这种很小的、频次很低需求（不过上面这些case，我们还确实解决了:）

我相信所有的搜索引擎公司的网页库，都是漏斗形结构。

这样的话，同一个query在不同库种下搜索的结果存在天然的分布不合理。特别中高频短query。如何解决这个问题，同时又要兼顾真有突发事件的需求不被误干掉，挑战同样存在。

加入卖萌屋NLP/IR/Rec与求职讨论群

后台回复关键词【顶会】