导读：迄今为止，对于搜寻将来状态的摸索从未进行。2021 年，尝试搜寻流式体验新形态时，咱们发现，在热点场景下提供更多视频、热议、资讯等富媒体内容，会带来更高的搜寻散发。然而因为以后搜寻架构贴着搜寻搭建，留给富媒体内容混排的工夫和空间十分无限，强制插入混排队列对以后搜寻零碎侵入性太强。因而，咱们提出了全新的搜寻浏览态通用架构，通过近线获取更多系统资源数据，从而实现近线粗排、在线精排。新零碎的设计防止了对原有零碎的侵入，在解决搜寻零碎混排条数空间无限的问题同时，也留出了更多工夫反对更简单的排序模型。2021 年，搜寻浏览态通用架构上线，反对新闻热点场景，提供搜寻流式满足，给用户提供了更加活泼的沉迷式搜寻体验。

全文 4700 字，预计浏览工夫 12 分钟

一、浏览态：一种新的搜寻状态

搜寻的指标是满足用户需要，Feed 的指标是激发浏览。如何在搜寻根本满足的根底上激发用户浏览趣味，这始终以来是搜寻新形态的指标。这个方向从 2016 年开始就继续摸索，但始终没有找到很好的执行门路。2021 年，咱们找到一种新的搜寻状态——搜寻浏览态，能够在用户主需要满足的状况下，提供更多视频、资讯、热议内容，并给用户打造了一滑到底的沉迷式浏览体验，散发晋升。

在产品款式方面，浏览态产品由结构化头卡和内容流后果两局部组成，结构化头卡负责在头部满足用户主需要，内容流后果则用于激发用户的浏览诉求。咱们将资讯、热议、视频的组卡拆开成单条，混排在内容流中，同时反对视频自动播放，热议后果开展，大大晋升了后果页间接满足的成果，给用户打造了沉迷式浏览的体验。

产品款式劣势是：突破阿拉丁低效生产、晋升百家号和视频占比、视频自动播放、内容丰盛度大幅晋升。产品成果上搜寻散发大涨，对用户留存也有正向成果。

二、基于通用搜寻架构的浏览态实现问题

咱们尝试在金融、体育、新闻热点等垂直畛域下应用新的浏览满足状态和更加丰盛鲜活的策略成果，基于通用搜寻架构，通过疾速尝试资源混排，晋升视频、热议内容占比，发现搜寻散发有显著晋升。然而，通搜架构留给资源混排的工夫无限，也限度了用于混排的资源条数，具体如下：

无奈主动回退：在搜寻零碎上间接批改搜寻后果，对系统侵入重大，一旦发现批改后后果品质不达标，无奈反对回退到原后果；

工夫少：搜寻架构高扇出，每个子系统的速度间接决定了搜寻后果响应工夫，子系统外部排序的工夫长，留给混排的工夫被压缩；

空间少：以后架构在混排模块能拿到多个子系统的后果，但因为混排工夫无限，各个子系统提供的后果条数受到数据包大小限度，且提供的特色信号无限，无奈反对更深度的排序。

针对以上基于通搜架构浏览态实现的三大问题，咱们提出了全新的搜寻浏览态零碎，将子系统更多后果通过流式计算聚合到新的零碎中排序，联合内容丰盛度、时效性、用户行为进行深度排序，晋升搜寻内容丰盛度。在控制系统整体耗时不减少的同时，将更简单的特色和模型利用于排序。

上面我将介绍搜寻浏览态零碎。

三、搜寻浏览态设计方案

3.1 设计思路

在介绍搜寻浏览态零碎设计思路之前，先介绍相干概念如下：

• 通用搜寻架构：通用搜寻架构是综合性搜寻零碎，须要兼容多垂类后端和组卡满足，因而，通用搜寻架构的上游扇出非常复杂，须要在通用排序模块获取多垂类后果，并进行混排和点调。
• 近线服务：近线服务是介于在线服务和离线服务之间，采纳数据音讯队列进行数据准实时处理，实现秒级别数据处理。相比于离线，它的处理速度更快，稳定性更强；相比于在线，它不会严格受到架构和网络耗时要求限度，能够更灵便的接入各路数据，解决申请的工夫能够更长。
• Streaming Framework：百度流式计算对立技术栈，反对提早低至亚秒、秒级的高时效性场景。曾经反对了广告、风控、反作弊等业务。流式计算可作为浏览态零碎实时数据处理服务。
• UNDB：这是百度自研的基于 SSD 的 KV 数据库，相比于 redis KV 数据库基于内存，应用 SSD 作为存储介质机器资源更节俭。UNDB 可用于近线零碎索引库。
• GDP：是百度自研的基于 Go 语言的 Web 框架，其并发能力强，业务框架清晰，作为在线业务层更适合，有更好的微服务特型。
• SEDA：是 GDP 图引擎，反对策略算子化，可作为在线服务反对摘要飘红计算和数据打包解决。
• 举荐在线架构：是一套反对召回、排序的残缺在线微服务架构，其欠缺的配套设施和工具链能够很好的反对排序策略研发，可作为在线服务反对排序功能。

基于以上百度服务基建，咱们设计并实现了搜寻浏览态零碎。该零碎以 Streaming 流式计算框架为近线数据处理服务，以 UNDB 数据库为索引存储，以举荐在线架构为在线框架设计排序服务，以 GDP 和 SEDA 图引擎为在线正排和摘要服务，设计并实现了从数据流式解决入库到在线需要辨认、粗排、精排、摘要飘红计算、展示组包的全流程搜寻零碎。

3.2 总体设计

基于以上思路，咱们实现了搜寻浏览态零碎设计。该零碎由四局部组成，数据触发层、数据处理层、在线混排层、正排摘要层：

数据触发层：基于以后通用搜寻架构搭建。通用搜寻架构提供了需要剖析、根底后果召回、根底特色计算、数据 dump 等性能。通过需要剖析失去触发信号，将触发信号透传给各个垂类子系统，垂类子系统通过根底检索排序，将最优质的 top N 条后果计算出来，再将数据公布到 big-pipe 流式零碎中。

数据处理层：基于 Dstream 流式计算搭建的近线数据流。用于实时获取来自 big-pipe 订阅的 top N 后果数据，设计标准的 protobuf 数据协定，依照协定对数据字段进行实时裁剪，将裁剪对齐后的数据灌入索引库中。

混合排序层：基于举荐架构搭建的在线混排服务。该服务从索引库中获取各垂类 top N 条后果，基于相关性、互动信号、正排信号进行混排，重点晋升内容丰盛度和时效性。同时，实现了干涉、屏蔽、去重性能。举荐架构提供了配置管理、词典治理、debug\trace、工具链，能够很好的反对配置、词典疾速失效，反对线上问题追究和线下 debug，其欠缺的研发和测试工具链能够保障研发效率和系统维护效率。

展示摘要层：基于 GDP + SEDA 框架搭建的在线展示摘要服务。该模块反对在线获取正排特色，将排好序的 top 10 条后果通过策略引擎解决其题目、飘红、摘要和出图，并将结构化的展示数据拼接成展示包返回给上游。正排摘要层通过读取正排库获取题目和注释数据，申请了搜寻千亿级正排库，再调用飘红摘要服务接口获取飘红和摘要，最初实现展示数据组包。

3.3 流程设计

整个零碎分为 触发阶段、近线解决、在线召回 3 个阶段。

触发阶段：

咱们复用搜寻需要辨认性能，依据用户的 query 判断该需要是否属于浏览态需要。若判断为浏览态需要，则将触发上游子系统将排序好的搜寻后果公布到 bigpipe 上。该阶段相比于之后四个阶段绝对独立，其性能更依赖通用搜寻零碎，也会受到零碎自身 cache 等限度。

近线解决阶段：

• 数据处理：是连贯通用搜寻和浏览态近线零碎的桥梁，将触发阶段公布的数据依照定义好的格局进行筛选，灌入数据库中。同时，减少数据过滤策略，反对基于站点的过滤，过滤局部低质资源。
• 特色读取：这是数据处理后进行的操作，次要为获取资讯、视频、热议的正排特色。获取到 url 数据，秒级别申请正排库，获取正排数据。该操作实现了对索引库数据的二次加工，实现了更多正排特色灌入。

在线召回阶段：

• 精排计算：用户申请被在线辨认为浏览态需要后，触发查问索引库，召回 URL 和特色，进行在线排序。通过精排失去的 top 10 后果会参加通用搜寻混排，依据后果品质决策是否出浏览态后果。
• 摘要计算：排好程序的 top N 条后果返回给展示摘要层，进行摘要、飘红、出图、题目计算，并打包展示数据包。这个阶段会拜访通用搜寻正排库，热议正排正排库，视频物料库，并拜访飘红摘要通用接口。

四、浏览态零碎劣势

零碎解耦：

实现了网页搜寻召回和浏览态后果召回解耦，不仅保障了网页搜寻后果失常召回，也保障了浏览态后果能够和网页搜寻后果进行 pk，从零碎层面保障了返回后果的品质。

混排下移：

垂类资源的后果混排从上游的排序模块下移到浏览态模块中，能够接入更大模型进行计算，计算工夫增大 6 倍，混排条数增大 10 倍，策略能够进行晋升的空间变大。

内容丰盛：

浏览态架构实现了视频、短文本热议、长文资讯、UGC 知乎笔记等内容的充沛混排，其大大晋升了浏览态后果的内容丰盛度，给用户提供了沉迷式浏览的体验。

接入老本：

新架构采纳网页、视频、资讯、热议根底资源做兜底，资源引入老本简直为 0，策略只须要专一于排序，架构只须要专一于特色通路，产品研发只须要专一于展示成果降级，新垂类接入老本从 Q 级别升高为双周级别。

五、浏览态垂类利用范例：新闻热点浏览态

新闻热点浏览态是咱们在新架构下尝试的第一个垂类，咱们将视频、资讯、热点阿拉丁后果拆条混排，将时效性更强的视频、短文本资源排在后面，更好的满足了用户内容丰盛度。从图中能够看出，老款式下，新闻热点后果由结构化区域 + 阿拉丁满足组成，在新款式下，新闻热点后果改成由结构化区域 + 内容流满足。

新闻热点浏览态残缺过程范例：

• 当用户第一次搜寻『冬奥会』的时候，需要辨认阶段将 query 辨认为热点浏览态 query，触发了浏览态信号，资讯搜寻、视频搜寻、热议搜寻子系统拿到浏览态信号，在根底排序模块中将排好序的 N 条后果写入 big-pipe 中，并将第一次搜寻后果返回给用户，这个时候用户看到的后果非浏览态后果。

• 其次，big-pipe 中有新数据后，数据处理阶段开始生产新数据，首先依照约定的 protobuf 格局进行数据校准，通过校准的数据进行数据过滤，依照站点白名单和黑名单过滤数据；

• 再次，将解决好的数据间接写入 UNDB 数据库中，这时候数据库中能够查到『冬奥会』对应后果，后续搜寻的时候也会触发后果更新，将根底检索的新数据更新到数据库中。

• 当用户二次发动雷同『冬奥会』的搜寻时，就会拿到浏览态后果，这个后果进行在线精排计算，失去最好的 10 条后果，并将这部分后果推送给展示摘要模块。

• 展示摘要模块查问资讯摘要库、热议摘要库和视频物料库计算出飘红、摘要、出图和题目，再将展示后果打包，返回给通搜零碎进行混排。

• 通搜零碎拿到天然搜寻后果、垂类零碎后果、浏览态混排后果，再依据后果品质决策应用哪一路数据作为最终反馈给用户的数据。

六、以后零碎面临的问题和解决方案

搜寻浏览态零碎解决了对原有零碎侵入过大，混排空间不够的问题，但同时也带来了一些新问题：

1、触发问题

问题形容：浏览态上线初期面临召回笼罩有余的问题，起因有：

1）触发机会太晚：以后浏览态近线零碎是用户被动搜寻触发，造成用户第一次搜寻非浏览态，体验有损失；

2）泛化笼罩有余：19% 需要来自子系统泛化笼罩，因为以后搜寻零碎限度这部分需要无奈实时拿到触发信号。

解决方案：

– 建设触发成果监控，制订指标，建设分钟级内容流触发成果回归监控，并建设触发剖析漏斗，剖析各个策略阶段影响内容流触发的问题；

– 搭建触发近线层，在触发词典失效的时候，异步发动根底数据灌库操作，被动触发数据 dump，解决了被动期待用户触发的操作；

– 买通通用泛化能力，在线实时触发泛化信号，反对泛化需要触发浏览态数据读写；

2、内容量有余：

问题形容：浏览态产品设计初期对资讯、热议、视频每一页的展示条数都有最低要求，同时也会依据图片品质、互动信号、视频清晰度等决策是否要出，通过层层筛选后，后果条数可能有余导致不召回或者页数有余。

解决方案：针对这个问题，咱们首先建设条数剖析漏斗，明确每个垂类在不同 query 下的相干资源数，以及在各个阶段可参加排序的资源条数。通过条数剖析漏斗，发现并优化了 5 个内容有余的问题，均匀可翻页数失去晋升。

3、排序计算依赖新特色：

问题形容：以后浏览态后果的特色都是来自建库数据，特色丰盛度有余。同时须要引入一些用户行为信号，比方互动信号等，搭建一套特色获取和近线计算零碎能力更好的反对排序。

解决方案：首先无效的梳理要减少的新特色，针对梳理好的特色信号，将特色分成两局部：第一部分为在线零碎计算出来的统计特色，第二局部从正排库中获取。第一局部特色能够通过在线特色实时获取到；第二局部特色通过在线读取正排服务获取，这里波及到正排服务降级，互动信号引入等工作。

七、总结与瞻望

搜寻浏览态零碎是随着搜寻浏览态产品应运而生的零碎，其对以后通用搜寻零碎侵入性很小的，同时解决了混排问题，其定位是疾速、高效的反对垂类尝试搜寻浏览态新形态。2022 年，咱们将会联合通用浏览态业务场景，对搜寻零碎进行深度革新，建设更加通用的搜寻浏览态架构。

作者介绍：

– 林同学 百度资深研发工程师 负责网页搜寻展示体验优化和搜寻浏览态架构零碎

– 高同学 百度资深研发工程师师 负责搜寻浏览态架构零碎

– 陈同学 百度资深研发工程师 负责网页搜寻展示架构和接入架构零碎

– 楚同学 李同学 李同学 举荐技术架构部 负责搜寻场景下举荐架构零碎

– 康同学 百度资深研发工程师 负责搜寻场景下举荐算法优化

– 柴同学 百度资深研发工程师 负责搜寻场景下举荐算法优化

举荐浏览：

百度 APP 视频播放中的解码优化

百度爱番番实时 CDP 建设实际

当技术重构遇上 DDD，如何实现业务、技术双赢？

接口文档主动更改？百度程序员开发效率 MAX 的秘诀

技术揭秘！百度搜寻中台低代码的摸索与实际

百度智能云实战——动态文件 CDN 减速

化繁为简 – 百度智能小程序主数据架构实战总结

———- END ———-

百度 Geek 说

百度官网技术公众号上线啦！

技术干货 · 行业资讯 · 线上沙龙 · 行业大会

招聘信息 · 内推信息 · 技术书籍 · 百度周边