导读：迄今为止，关于搜索未来形态的探索从未停止。2021年，尝试搜索流式体验新形态时，我们发现，在热点场景下提供更多视频、热议、资讯等富媒体内容，会带来更高的搜索分发。但是由于当前搜索架构贴着搜索搭建，留给富媒体内容混排的时间和空间非常有限，强制插入混排队列对当前搜索系统侵入性太强。因此，我们提出了全新的搜索浏览态通用架构，通过近线获取更多系统资源数据，从而实现近线粗排、在线精排。新系统的设计避免了对原有系统的侵入，在解决搜索系统混排条数空间有限的问题同时，也留出了更多时间支持更复杂的排序模型。2021年，搜索浏览态通用架构上线，支持新闻热点场景，提供搜索流式满足，给用户提供了更加生动的沉浸式搜索体验。一、浏览态：一种新的搜索形态 搜索的目标是满足用户需求，Feed的目标是激发浏览。如何在搜索基本满足的基础上激发用户浏览兴趣，这一直以来是搜索新形态的目标。这个方向从2016年开始就持续探索，但一直没有找到很好的执行路径。2021年，我们找到一种新的搜索形态——搜索浏览态，可以在用户主需求满足的情况下，提供更多视频、资讯、热议内容，并给用户打造了一滑到底的沉浸式浏览体验，分发提升。
全文4700字，预计阅读时间12分钟
文章图片
在产品样式方面，浏览态产品由结构化头卡和内容流结果两部分组成，结构化头卡负责在头部满足用户主需求，内容流结果则用于激发用户的浏览诉求。我们将资讯、热议、视频的组卡拆开成单条，混排在内容流中，同时支持视频自动播放，热议结果展开，大大提升了结果页直接满足的效果，给用户打造了沉浸式浏览的体验。
产品样式优势是：打破阿拉丁低效消费、提升百家号和视频占比、视频自动播放、内容丰富度大幅提升。产品效果上搜索分发大涨，对用户留存也有正向效果。
二、基于通用搜索架构的浏览态实现问题 我们尝试在金融、体育、新闻热点等垂直领域下使用新的浏览满足形态和更加丰富鲜活的策略效果，基于通用搜索架构，通过快速尝试资源混排，提升视频、热议内容占比，发现搜索分发有明显提升。然而，通搜架构留给资源混排的时间有限，也限制了用于混排的资源条数，具体如下：
无法自动回退：在搜索系统上直接修改搜索结果，对系统侵入严重，一旦发现修改后结果质量不达标，无法支持回退到原结果；
时间少：搜索架构高扇出，每个子系统的速度直接决定了搜索结果响应时间，子系统内部排序的时间长，留给混排的时间被压缩；
空间少：当前架构在混排模块能拿到多个子系统的结果，但由于混排时间有限，各个子系统提供的结果条数受到数据包大小限制，且提供的特征信号有限，无法支持更深度的排序。
文章图片
针对以上基于通搜架构浏览态实现的三大问题，我们提出了全新的搜索浏览态系统，将子系统更多结果通过流式计算聚合到新的系统中排序，结合内容丰富度、时效性、用户行为进行深度排序，提升搜索内容丰富度。在控制系统整体耗时不增加的同时，将更复杂的特征和模型应用于排序。
下面我将介绍搜索浏览态系统。
三、搜索浏览态设计方案 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 说
百度官方技术公众号上线啦！
技术干货 · 行业资讯 · 线上沙龙 · 行业大会
【百度搜索流式体验新形态探索之路】招聘信息 · 内推信息 · 技术书籍 · 百度周边
