神马搜索如何提升搜索的时效性？

　　小叽导读 ：什么是搜索的时效性？有哪些特征？如何优化？本文分享 神马搜索 在搜索排序时效性问题 上的实践和探索，从基础特征优化开始，通过标注数据进行排序和召回模型优化，以及时效性排序的召回体系和收录体系。较长，同学们可收藏后再看。
　　一 问题定义
　　如何理解时效性呢？古语云：＂四方上下曰宇，往古来今曰宙＂。时间贯穿了一切，时间感知的唯一标准是变化。个人理解相对变化越难时间越慢，接近光速的时候时间变慢就是因为要改变它很困难。
　　从内容侧理解时效性
　　在信息场景下定义时效性的标准也同样是变化。
　　信息的价值会随时间的延续而变化，一般通常情况下信息的价值是会衰减，会失效的。这个和物理里面的放射性很像，借用物理里面的观点我们对信息定义一个时效性半衰期的概念：信息相对价值衰减一半所需要的时间。对于一篇文章定义一个时间，假设文章刚发表的时候信息量是100，那么信息量衰减到50的时候需要的时间，就是这篇文章的半衰期。
　　从需求侧理解时效性
　　在搜索场景下定义时效性的标准也是变化。
　　搜索的最佳答案会随着时间的延续而变化。对于不同的query，变化快慢也不一样。对于需求最佳答案变化的频率，我们定义一个时间敏感度的概念，用户对时间的敏感度越高，那么越希望得到新的内容，内容的时效性和整体的满意度的相关程度越高。
　　泛时效性
　　时效性从需求出现的时间分布上大概可分成3大类：突发时效性，周期时效性和泛时效性。
　　具体的分类可以参考下图，本文核心介绍和解决的是泛时效性。
　　不同于突发和周期时效性，泛时效性query和普通搜索query时间分布上基本一致，从时间序列分析上基本属于平稳序列。
　　比如，杭州西湖限行，阿里市值，从萧山机场怎么去阿里西溪园区方便，今年最流程什么款式的女装，杭州有哪些店比较好吃，灵隐寺附件民宿推荐等。
　　上面介绍到内容侧和需求侧的时效性相关的两个量化指标：时效性半衰期和时间敏感度。为了方便，我们将这两个指标的强度分类5档：
　　二 评估标准
　　对于任何问题进行优化的前提是必须知道衡量标准，时效性问题也不例外，在进行优化之前先要制定一套合理的评估方案，一是可以用来对现状摸底，进行Case分类和比例分析进行针对性的优化，二是优化完之后通过前后对比得出优化对于整体指标的提升。
　　在做时效性优化评估之前，搜索本身是有综合满意度评估打分的，但是综合满意度打分对于时效性并没有很强的体现，只是在时效性明显不满足需求的情况下进行扣分，相对较弱。为了更好的暴露出时效性的问题，我们单独构建了时效性满意度的打分标准，评测时按照两个标准进行同时打分。
　　和神马搜索满意度类似采用满分3分，对Top3的结果进行评测，按照结果不满足需求进行扣分的方式进行时效性满意度打分。
　　扣分标准
　　命中以下规则时进行扣分：
　　时间失效，8年以上，例如：＂怎么知道别人开过我电脑没，09年的消息。
　　信息失效，网页内容已经过期，如果页面是新闻或者招聘、下载等页面时间敏感较强的页面，时间上要严格一些，保证1-2年内。
　　时间过旧，根据query时间敏感度和结果的更新频率进行综合判断，一般以超过5年结果进行时间是否过旧划分。
　　时间内容和展示不一致。
　　结果非最新进展。
　　打分流程
　　进行query和结果敏感度衡量。
　　先判断时间失效， 然后判断信息失效，时间过旧，内外时间不一致，事件最新；每条扣1分。
　　死链单独扣分。
　　单纯小说query暂时不评，下载需求按照正常评。
　　注意
　　时间敏感的query根据其敏感程度判定，如＂优惠卷使用超出使用日期＂，＂新问答电脑故障解决-回答是XP系统的方法＂信息失效。
　　关于视频资源播放和下载问题：有时间显示，有简介，无论能否播放依照时间打分；无时间显示，对应简介，无法播放算信息失效或者低质，还是按照时效性最新算，不扣分。
　　三 整体打法
　　在做泛时效性项目之前我们做了突发时效性，经历了从规则优化->迁移模型->抽象特征->模型迭代这四个阶段。发现一个现象，在做一个项目的时候当我们把整个项目的优化方案定好，然后按照从底层特征到上层模型，这样稳步迭代推进的方案，虽然前期特征设计和优化难有收益，但是后期效果提升反而非常显著，而且速度很快，层次清晰很有条理，问题定位和优化都很容易。
　　因为有了上面的经验总结，我们觉得就先从基础特征优化开始，然后通过标注数据进行排序和召回模型优化。
　　泛时效性框架
　　时效性服务框架图
　　四 基础特征优化
　　网页时效性特征
　　时间抽取
　　时间抽取是时效性排序的最为基础的特征，在抽取时间的时候首先要对网页时间进行定义，网页时间主要分为以下几个类别：网页内容时间、网页更新时间、网页发布时间和网页发现时间。
　　网页内容时间：就是网页中所描述的内容的时间，比如一个网页描述的是1945年二战快要结束的时候的事情，那么这个网页的内容时间就是1945年，如果介绍的是2018年北京奥运会开幕式，就是2018年8月8日，目前的网页内容时间是从网页内容的所有时间中挑选出一个最能代表内容的时间，是一个基于标注数据的Ranking模型来实现的。
　　网页发布时间：一般是指网页的生成的时间，一般情况下是指网页的Link创建的时间，对于一些内容页，比如新闻，二手交易等，网页发布时间一般在网页上会明确给出。
　　网页更新时间：一般是指网页主体内容发生最近一次变化的时间，对于一般的新闻和普通的文章页，一般生成后不会再进行更新，所以最后一次更新时间一般情况下都是网页的发布时间。
　　网页发现时间：一般是指网页链接被搜索引擎爬虫发现的时间，由于爬虫Flowlink需要一定的时间窗口还有内容孤岛等现象，网页发现时间有可能严重滞后于网页发布时间。
　　网页首次进入索引时间：因为网页被爬虫发现后，网页并不一定能够及时的被抓取和解析到，可能首次进入索引的时间会严重滞后于网页发现时间。
　　网页时间：就是最能代表一个网页价值的时间，一般情况下是从这5个时间进行选择，目前我们使用的是一个规则的方法进行时间挑选。
　　规则的方法主要是：
　　对于新闻等内容页面，如果网页发布时间可以通过模版和规则明确抽取出来，就选择该时间作为网页时间。
　　当多个时间存在严重不一致的情况下会优先选择置信度高的时间，比如网页发现时间或者网页首次进入索引时间。
　　时间敏感度(时效性半衰期)
　　网页的时间敏感度，也就是网页信息衰减的一个速率，我们用一个时效性半衰期来衡量网页的时间衰减的速率，也就是假设从当前时间开始网页信息衰减为当前信息量一半所需要的时间。
　　半衰期作为一个明确的时间其实很难定量标注，为了简单起见，我们将半衰期进行定性的离散化，通过标注数据来学习网页的半衰期。
　　标注数据的GuideLine：
　　1）时间敏感度标注
　　在时间敏感度标注的时候，为了让标注的同学能够尽可能的有内容的时效性感知，我们没有定义很明确的详细细则，只是有一些例子补充，核心还是希望能够让标注的同学去感知内容的时间敏感度，能够去进行有效的思考，而不是去逼近学习标注细则，从而获取到更为优质的数据。
　　这种粗GuideLine的标注虽然带来的数据质量上的提升，但是也存在一些问题：
　　标注同学的培训成本很高，需要消耗大量的时间去培训标注的成员，同时进行case解释，这个陆续地持续了大概1个月的时间。
　　标注的拟合率较低，在项目初期5人的跨档（也就是5个人中有3个以上的人标注的是比邻的档位）拟合率不到50%，即使到了项目的最后阶段，5人的单档拟合率（也就是5个人中3个以上的人标注的是相同的档位）也在60%左右，跨档拟合率在70%～80%之间波动。
　　2）时间敏感度的模型
　　目前我们的模型使用的是Pairwise和PointWise两个模型。
　　Pairwise模型输出的连续值，分辨率更高，更适合上层排序的基础特征。
　　PointWise模型输出的主要是0，1，2及以上，主要是用来进行索引挑选以及上层排序的伪反馈标记特征，通过统计召回结果时间敏感的网页的分布来反推Query的时间敏感度，这个后面会详细介绍一下。
　　页面信息失效
　　虽然定义了网页的时间敏感度，对于一些时间敏感的网页过了一段时间自然价值会变低，这种网页定义信息失效比较困难，但是对于一些有明确时间边界的页面来说信息失效是可以明确定义的。
　　比如一些信息发布页面，类似二手交易、组织活动、房产信息等都具有明确的时间边界，当交易发生，商品下架，或者活动时间过期等都是可以明确定义的，我们把这种信息称为信息失效页面，这种页面可以认为时效性价值为0，是需要做一些恶劣Case打压的，这个在后续的排序模块中也会介绍。
　　对于这种页面的识别，目前是通过一些规则的方式，对于不同站点和类型的网页进行识别的。
　　需求时效性特征
　　需求的时间敏感度
　　Query的时间敏感度和网页的时间敏感度是同样的概念。
　　Query的时间敏感度: Query需要的网页的时间敏感度，可以通过召回结果中网页的时间敏感度来反推时效性的敏感度。
　　Query的时间敏感度的特征因为涉及到时效性结果的召回和时效性粗排，所以线上无法通过召回结果的分析来进行反推，需要直接通过Query端的分析就获取到Query的时间敏感度。
　　Query时间敏感度的模型主要是经历了3个版本的迭代，这里面简单介绍一下：
　　1）第一版：基于时间敏感词的Attention机制的ABCNN的模型
　　通过一些时间敏感的Patten做Attention来确定Query是否可以和某些时间敏感的词进行搭配，如果Query和这些时间敏感词的搭配比较合理在搜索语料中也比较常见，那么这个Query是时间敏感的Query的概率自然也会比较高，这些常用的搭配的词主要是：最新，最近，今年，年份，今天等。
　　2）第二版：基于伪反馈的蒸馏技术
　　刚才上面提到了其实我们已经有一个网页端的时间敏感度的模型，因为网页本身的信息量大，网页结构特征多，更容易做的准确。当我们有一个比较准确的网页时间敏感度的模型的时候，可以通过召回结果的分布分析，生成大量的伪标注的样本。通过这些伪标注的样本可以训练一个大样本的CNN的模型，效果对比第一版提升也比较明显。
　　3）第三版：基于主动学习的样本标注的迭代技术
　　时效性的上层排序的时候需要一个TriggerModel，TriggerModel的作用是用来判断Query是否需要时效性的调整，以及时效性调整的力度。
　　这个TriggerModel是基于人工标注数据的Model，这个Model使用的特征更为丰富，包括相关搜索的时间敏感词（因为用户有的时候会修改Query，给Query加上时间限词来进行结果筛选），网页的时间敏感度的分布，Query的时间敏感度的分布，用户的点击行为等特征，同时通过ActiveLearing进行临界样本标注，增加模型的分辨率。
　　当我们获取到了一个分辨率和准确率都比较高的Query的时间敏感度的TriggerModel，用这个Model来生成大量的高分辨率的样本，同时结合强大的Bert语言模型，可以训练得到一个比较好的时间敏感度的模型。
　　同时因为TriggerModel使用了第二版的Query的时间敏感度的特征，当Query敏感度效果提升的时候TriggerModel可以重训提升效果，同时新的TriggerModel又可以指导Query的时间敏感度的模型的训练，这样迭代训练同时提升。
　　时效性需求强度
　　时效性需求强度是和时间敏感度并列，主要判断是用户是否显示的表达出对结果的时间维度上的需求（比如最新***,2020年***）。
　　这个模型相对来说较为简单，早期是一个基于规则的模型，来识别Query是否具有显著的时效性Pattern。后期同样是通过召回结果和用户行为（比如用户的显式的query修改的二次查询，当用户搜索＂杭州限行规则＂的时候，如果结果不好用户会修改query为＂2020杭州限行规则＂，＂最新杭州限行规则＂等）来生成伪标注样本进行模型的训练。方法类似于时效性敏感度模型的第二版。
　　五 数据标注
　　目前神马搜索的上层的排序的模型核心是基于标注样本的LTR Model，所以时效性优化的比较合理的方案是：通过标注样本的方式，重训LTR的模型来进行时效性的优化。
　　要训练LTR Model需要标注时效性的学习的目标，在迭代的过程中主要经历的2个阶段，第一个阶段是尝试讲时效性的目标融入到AC的5档标注里面（Prefect, Excelent, Good, Fair, Bad)，后续由于标注的难度的问题，采用二阶段的单独标注的方法。
　　时效性满意度融入AC标注
　　目前神马搜索的AC标注分为5档（Prefect, Good, Excelent, Fair, Bad= 4,3,2,1,0），为了把时效性的目体现在AC中，我们增加了3档，分别是2.5,1.5和0.5。
　　具体的打分的原则主要是：
　　对于时效性特别不好的结果，如果影响到了满意度，那么则直接降低1档或者2档。
　　对于时效性不是特别理想的结果，但是不影响满意度，适当降低0.5档，对于时效性特别好的结果适当提升0.5档。
　　由于从原来的5档提升到了8档，而且AC的标注是7人拟合导致标注难度大大增加，同时神马搜索AC的标注标准和标注人员都长期稳定，标注人员形成了一定的任务感知。让标注人员重新学习新的的标注标注，导致标注人员的拟合率降低比较严重，低于60%，多次培训之后仍然没有显著提升，所以后来放弃了把时效性的标注融合神马搜索AC的标注体系中，启用了新的单独的标注原则。
　　单独时效性满意度
　　单独时效性的标注原则是，对于神马搜索已经标注过AC的样本进行第二个辅助Label的标注。从神马搜索已经标注的AC样本中，挑时间敏感的Query，对于该Query的非0档的Q-U的结果进行时效性满意度的标注。
　　时效性满意度标注的GuideLine：每个query会对应多个url，我们评测人员需要理解query含义——判断页面是否满足用户需求——判断页面时效性的满足程度。
　　理解query含义，推断用户的需求。  从用户需求出发，判断结果的时效性能多大程度的满足用户。  根据后边提到的标准，给出合理打分。
　　分档标准2/1/0分档均在结果相关的情况下判断。
　　只要有时间属性页面，均以2、1、0打分，与敏感度的区别是，不抛弃变化页面（按照主体内容的时效性判断）。
　　2——页面结果的时效性满足很好，为最新/价值高结果。
　　1——页面结果的时效性的满足一般，不为最新/价值结果，但是有一定参考价值。
　　0——页面结果的时效性满足很差，为很旧的结果，或者已经无参考价值。
　　不相关——页面内容与query完全不相关。
　　死链/spam——页面作弊/内容失效/空白页。低质。
　　无时效性需求——query明显无时效性需求（例， 论语全文）。
　　无法判断——页面内容不包含时效性因素，无法按照时效性满足打分（例，百科、长视频页面、网站首页）。
　　单独时效性满意度的标准和时间敏感度的标注一样，我们没有设定特别细的GuideLine，核心还是要让标注的同学进行主要的思考，让标注的同学去感知时效性的损失对用户的满意的影响。前期标注的拟合率也较低，低于60%，后期经过长时间的培训和case讲解，最终拟合的准确率大概在75%～85%之间。
　　六 排序模型
　　时效性排序的Model主要分为四层。
　　时效性粗排
　　对于时间敏感的query，在索引召回的层尽可能的将一些时间比较新的结果召回上来。时效性粗排项目进行的比较早，当时还没有标注数据，主要的方式使用的是特征增强的方法，来提升新的结果排序靠前的概率。
　　神马搜索排序Model加入时效性特征
　　AC的部分标准里面其实是考虑到了时效性的因素的。
　　第一类：比如一些新闻，因为很多新闻事件，虽然人物、地点等没有变化但是核心的事情已经变化了，这个就会影响基础的满意度，这种在AC标准中有体现。
　　第二类：另外的一种是信息失效，信息失效在AC标准里面是有明确定义的，属于无价值内容的，这个是可以直接作用于满意度的。一般来说信息失效的概率和时间敏感度和网页离现在的时间成正比，一定量的信息失效的目标可以学习到部分时效性的目标。
　　其他类型：还有很多其他的类型的比如用户显示的说明了年份的，比如＂最新的阅兵式＂，＂51放假安排＂等。
　　因为时效性敏感的Query的标注的结果是和标注的时间有关系的，所以我们必须要记录AC样本标注的时间，这样才能准确地计算时间特征，同时在Dump特征的时候必须把样本的时间还原到标注时间。为此我们对神马搜索的特征Dump的流程进行了改动，增加了时间还原功能，保证时效性特征的准确性。
　　时效性独立双Label排序模型
　　因为时效性的标注数据是有2个Label的，我们必须开发一套独立的多Label的排序框架，为此我们进行了一些的算法改动，升级了原来的LightGBM的工具支持多Lable的训练。
　　主要的思想就是LambdaMart在计算交换Doc的PairwiseLoss的时候考虑到2个Label：
　　第一版的方法：当第一个Label的相同的时候，增加辅助Label的作用，计算辅助Label的Loss，后来在应用中发现这种方法存在一定的问题，就是这种情况下辅助Label只能在Label相同的样本上起作用，Label不同的样本无法产生Loss。
　　第二版的方法：为了弥补第一种方法的不足，我们通过Label放大的方法，将原来的Label进行缩放，将AC的标准变成 8，6，4，2，0，然后将时效性的目标3，2，1，0，变成（1，0，-1，-2）。通过这种方式，将时效性的Label增加到AC的Label上，形成了新的Label目标，同时将LightGBM的交换Loss的2^Label 变成2*Label（这里参考了神马搜索的做法），这个主要是因为放大了Lable之后，2^Label会使得头部的Loss特别的大，导致和线上真实的交换损失不一致。
　　第三版的算法：后来我们在观察样本的时候发现，时效性的作用其实和样本本身的Label有一定的关系，当样本本身的Label是1的时候，其实用户不太关心时效性，当Label本身是3的时候时效性起的作用又很小，基本上用户也不太关心。时效性主要起作用的是标注样本的2档这部分，我们通过降低3档和1档的时效性作用，增加2档的时效性作用，来提升时效性特征目标的区分度。
　　时效性独立Model对神马搜索的Model进行动态矫正
　　时效性单独的模型计算出的排序的分数是无法直接对结果进行时效性排序的，因为要考虑到时间敏感度和时效性需求强度比如：
　　当时间敏感度较低的时候时效性起的作用要弱。
　　当整体相关性水平都不高的时候，其实排序的核心还是相关性。
　　时效性标注的样本量要远小于神马搜索的AC样本，学习能力要弱于神马搜索的AC Model。
　　通过结合这3个方面的考虑，我们设计了一套动态平滑的方法，将时效性模型的分数平滑到神马搜索的排序分数中：
　　RankScore = RankScoreAC*Lamda + RackScoreTimeliness*(1-Lambda)
　　核心是Lambda的计算，Lambda的计算我们进行了3个维度的探索和尝试：
　　早期的第一版：TriggerModel结合人工规则的方式，TriggerModel会计算时间敏感度强弱的特征（TriggerModel在上面Query信号的地方简单介绍了一下），然后根据TriggerModel反馈到时间敏感度的分档信号上，然后人工指定Lambda的值。
　　中期的第二版：在第一种方法的基础上，将TriggerModel的阈值和Lamba权重之间的关系，进行平滑，设计了一个简单的调和平均的方法，将Trigger的预测值和Lamda的值进行了关联，使得调整的维度更为平滑。
　　正在尝试的版本：这个是目前排序里面正在尝试的多目标融合的算法，通过纯Pair的标注样本，将多个多目标模型（每个多目标模型都学习了AC的目标和一个单独的子维度）进行模型融合，通过一些全局的统计特征等来学习不同的多目标模型的权重。
　　基于IRGAN的泛时效性排序的探索
　　由于时效性标注样本的成本比较高，当时业界有一些通过IRGAN的方法进行模型迭代的，同时同组的突发时效性的团队通过IRGAN的方法在突发时效性的场景下拿到了收益。我们也希望能够通过IRGAN的方式来获得时效性的收益，这个进行了一些探索和尝试。
　　红色是已标注的相关文档，深蓝是召回的文档中未标注的相关文档，浅蓝是召回的文档中未标注的不相关的文档。G的训练就是先给未标注的文档打分，把得分较高的文档送给D进行判断，D对一个pair 进行判断，判断其是G挑选的（认为为假）还是真实已标注的（认为为真），并将其打分返回给G进行修正，如此G最终便能挑选出那些与真实已标注的样本比较接近的文档。
　　G和D现在的网络结构和预训练过程都是一样的，在进行对抗之前是几乎一模一样的模型（除了预训练之前的随机初始化值不同） 。但对抗训练G的时候，D认为 已标注的doc 一直是比G挑出来的Doc要好的，即使G 已经挑到实际上比较好的文档（ G预训练之后和D能力一样，一开始挑的可能已经是非常好的了）这时G反而会越学越差。因此可以考虑D和G采样不一样的网络结构，D要做的只是pair的正逆序判断，可以简单点，G要混淆D，可以采用更复杂的网络。
　　七 召回
　　时效性排序的召回体系主要是从通用召回的Query端处理，以及时间限定查询和独立时效性索引召回这3个维度进行的。
　　Query端的处理
　　我们发现时效性Query下，用户经常会搜类似这样的Query：今年***，3月份***，最新***，最近***。类似这种Term在原来神马搜索的召回体系中的Weight一般都比较大，纯字面召回很多时候是只考虑了Term的匹配，而忽略的Term和网页时间上的不一致。由于没有考虑到时间上的限制，经常会召回一些Term匹配特别好，但是时间上却特别老的结果。为了处理这种Case我们对神马搜索的Query分析的模块进行了单独的处理，增加了TimelinessTermWeightReadjust和TimelinessQueryRewrite的功能，主要是从TermWeight和Query改写的角度进行召回链路上的优化。
　　TimelinessTermWeightReadjust
　　目前神马搜索的核心引擎倒排索引，query分析后会指定AND词，就是倒排索引拉链归并的时候使用的必须要要包含的命中词。对于时效性场景下，我们其实不太希望今年，最近，最新等这种词命中，因为这次词的命都是相对时间，相对于网页发布的时候可能是最新的结果，但是随着时间推移，如果网页内容不变的话，这些信息的价值会大打折扣。
　　索引查询的AND逻辑的核心特征是TermWeight，只要Term的Weighting降低，那么这个词大概率就会被Rank掉，不参与拉链的归并。为此我们挖掘了一批时效性限定词语，在时效性场景下将这些词的Weight调低，提升召回的效果。
　　TimelinessQueryRewrite
　　对于今年***，3月份***，用户隐含的意思就是2020年***，2020年3月份***。通过Query改写，增加一路指定绝对时间的独立查询逻辑，通过限制时效性的时间强制匹配来保证召回结果的时间维度的满足。
　　时间限定查询
　　时间限定查询这个理解起来比较简单，就是通过query的时间敏感度的半衰期来对召回结果进行时间上的限制，上面的Query的时间敏感度的特征的说明的时候也提到了，时间敏感度的特征主要是作用在这个阶段。
　　当我们发现这个query是时间敏感的时候，会单独的发起一次查询，该查询会通过Filter语法的方式来限定召回结果的时间，这个时间就是上面提到的网页时间。
　　如果时间敏感度是3，也就是半衰期是1周，那么我们在查询引擎的是需要通过Filter语法制定只召回最近一周的结果，同理其他的敏感度的召回按照对应的半衰期来进行查询的时间限定，保证召回结果的时效性足够的好。
　　时效性索引召回
　　时效性索引召回，这个主要是为了解决一些业务逻辑的痛点，同时为了做性能和效果的balance，我们把一些足够新的内容放在一个单的索引中，查询的时候单独查询时效性索引增加召回。
　　上面的时间限定查询和TimelinessQueryRewrite都会单独的发起一次查询，这个查询如果用通用库的话，按照现在泛时效性Query的触发的标准，那么索引的查询量将增加50%，这对索引来说是极具的性能消耗，但是带来的提升却并不一定有这么的大。
　　独立索引之后，时效性的数据挑选和生效逻辑可以更加的灵活，摆脱神马搜索索引的各种限制。
　　新闻和强泛时效性下，需要天级别，小时级别，甚至是分钟级别的数据收录，在神马搜索场景下是无法实现的，需要单独的时效性业务索引来承载这块。
　　八 收录
　　时效性的收录体系，收录其实是排序的最基础的核心部分，如果链接没有收录再好的排序的算法也没有用武之地，目前搜索的收录体系主要分为突发和强泛时效性时效性的定向收录体系和神马搜索的通用的分层收录体系。
　　定向收录体系
　　基于种子页面的新闻场景收录
　　强时效性特别是新闻场景下，收录往往是通过新闻的种子列表页进行定向Flowlink进行连接发现的，举个简单的例子，新浪首页，新浪NBA首页，新浪财经首页，知乎热门话题页面，微博热门话题页面等。
　　通过定期的检查这种种子页面上是否有新的链接来发现新的内容，这种种子页面一般情况下只Flowlink一层。这个里面其实涉及到的内容很多，涉及到种子页面的发现标注，种子页面抓取的调度算法，种子页面的定期淘汰机制等，这里面就不在展开了。
　　基于时效性需求的定向收录
　　目前互联网的发现的的现状和未来的趋势还是封闭，各个网站和APP内的数据很难在网上Flowlink到，同时由于自媒体时代的到来，人人都是可能的种子页面，原来的通过种子调度的算法不可能这么庞大的内容进行调度，即使能调度的起来时效性和收益也很难保证。
　　这种情况下一般都是通过需求定向收录来做的，简单来讲就是各个网站和App都有自己的搜索接口，我们通过构造时效性需求的查询请求来抓取这些网站和App的数据来做需求的定向收录。
　　通用收录体系
　　基于时间敏感度的索引分层收录
　　上面收录的地方介绍过，其实时效性的索引分层是解决时效性业务需求和性能平衡点的最佳解决方案。
　　作者:大饼
　　来源:微信公众号:阿里开发者
　　出处:https://mp.weixin.qq.com/s/wYpLxEFmgvSgDAENIrbQbA