做搜推一体这个方向最早是因为受不了两套系统互相打架。用户在搜索框里敲了一个词搜出来的结果和首页推荐流推的东西完全对不上这边刚搜完“无线耳机”回首页还在推手机壳。业务方天天来问为什么不能把搜索和推荐打通技术那边一听就头大说这是两套链路数据、模型、接口全是独立的打通等于重构。但重构这件事又绕不过去因为用户的行为信号已经明摆着在说搜和逛本来就是同一件事。这篇内容就是来聊清楚搜推一体到底怎么做四层架构怎么搭四阶段怎么落地适合正在搞搜索或者推荐系统、想往一体化方向演进的技术团队参考。1. 搜推一体到底在解决什么问题先别急着聊架构得先把痛点说透。搜索和推荐分开建设在业务规模小的时候没什么问题但一旦量级上来各种割裂感会越来越明显。1.1 两套系统各自为战的典型症状先从用户视角看。一个用户进入App他的行为路径通常是先逛逛首页推荐流看到感兴趣的点进去然后可能产生一个具体的需求去搜索框里输入关键词。这个过程中用户的兴趣是连续的但系统给的反应是断裂的。推荐流不知道用户刚才搜过什么搜索也不知道用户平时喜欢什么于是出现上面说的那种“搜完无线耳机还推手机壳”的尴尬。再从技术视角看割裂体现在三个层面。数据层面推荐系统有一套用户行为日志、物料标签体系搜索系统有另一套倒排索引、相关性特征两边各存各的口径都对不上。模型层面推荐用协同过滤、双塔搜索用LTR排序模型特征工程的做法也不一样同一个用户在这个系统里是一个ID体系在另一个系统里可能又是另一套ID。服务层面更麻烦搜索有Query理解、召回、精排链路推荐有召回、粗排、精排链路接口协议不同运维部署也是两套算力资源也没法共享。这些割裂带来的直接后果是开发效率低、资源浪费、用户体验差、业务指标上不去。更麻烦的是当业务方提出“能不能在搜索结果里也做个性化”“能不能在推荐流里也插入搜索热点”这类需求时两套团队互相扯皮最后经常不了了之。1.2 搜推融合的本质用户意图的连续建模搜推一体不是把两套系统简单合并成一套而是要上升到用户意图的连续建模层面。用户的行为是一个从“泛兴趣”到“具体需求”的连续光谱推荐擅长捕捉泛兴趣搜索擅长满足具体需求两者本来就应该互为补充。我见过一个比较直观的类比推荐像是逛街用户漫无目的地看系统引导他发现兴趣搜索像是带着购物清单去店里用户目标明确系统要高效匹配。传统架构下这两个场景是两拨人在服务用户在这两个场景之间来回切换时系统完全感知不到。搜推一体要做的就是让同一套用户理解贯穿两个场景让逛的时候积累的兴趣信号能辅助搜索让搜的时候表达的意图信号也能反馈到推荐。这个本质想清楚之后架构上的很多选择就顺理成章了。比如为什么需要统一用户画像、为什么需要共享特征体系、为什么召回层要做成多路融合这些都是为了支持连续建模这个核心目标。2. 四层架构拆解从数据到服务的完整链路搜推一体的架构设计我通常把它分成四层来看数据层、召回层、排序层、服务层。这四层不是简单画个分层图就完事每一层都要回答“搜索和推荐怎么在这里融合”这个关键问题。2.1 数据层统一物料、行为与画像口径数据层是整个搜推一体的地基也是前期投入最大、最容易踩坑的一层。很多人以为搜推一体最难的是模型实际落地时才发现最难的是数据对齐。数据层要解决三个统一。第一个是物料统一商品、文章、视频这些内容数据要有统一的ID体系和属性规范。传统架构下搜索这边有一套类目体系推荐那边是另一套标签体系同一样东西在两个系统里的表示完全不一样。统一之后一份物料数据同时供搜索和推荐使用属性、标签、时效性信息全在一个地方维护。第二个是行为统一。用户点击、曝光、收藏、购买、搜索点击这些行为事件要用一套统一的埋点规范和事件定义来采集。搜索结果的点击是一种正反馈信号推荐流的曝光和点击也是正反馈信号这些信号在传统架构下是分开存储的在搜推一体架构下必须进入同一个行为数仓。我在项目里见过最典型的问题就是推荐侧的样本只用了推荐场景的行为搜索侧的样本只用了搜索场景的行为导致同一个用户的兴趣画像在两套模型里完全是两种样子。第三个是画像统一。用户画像、长期兴趣、短期兴趣标签这些要在同一个画像服务里生成和维护。搜索侧需要的用户背景信息推荐侧需要的用户历史行为序列都从同一个画像服务取保证用户理解的一致性。数据层实操上要特别注意ID映射的问题。我有一个经历过几次项目的经验不要在应用层做ID映射而是要在数据接入层就统一。有些团队觉得临时做个映射表就行结果后期每次数据对不上都要回来查映射非常痛苦。2.2 召回层搜索召回与推荐召回的统一框架召回层是搜推一体架构里技术含量最高的部分也是最考验设计功力的地方。搜索的召回和推荐的召回原本是两套完全不同的思路要统一起来并不容易。搜索召回的核心是Query理解加倒排索引。用户输入一个query先做分词、纠错、改写、意图识别然后拿处理后的term去倒排索引里找候选文档。推荐召回的核心是用户兴趣匹配通常用双塔、向量召回、协同过滤这类方案从海量物料里找出用户可能感兴趣的候选集。搜推一体的召回层要做的是把这两套召回能力放进同一个框架里让它们可以灵活组合、统一调度。我在架构设计上用的方法是构建一个召回中心把各种召回源都做成可插拔的组件比如搜索倒排召回基于query分词结果的BM25召回这是搜索场景的基础链路保留但不能丢语义向量召回把query和doc都向量化在向量空间里做近邻检索这是搜索和推荐都可以共享的能力用户兴趣向量召回基于用户行为序列生成的兴趣向量从向量库召回与兴趣相似的候选这是推荐的经典玩法协同过滤召回基于用户行为相似性找邻居再找邻居喜欢的物料适合推荐场景热点召回基于实时热点和流行度做召回两个场景都适用召回中心的统一调度逻辑是这样的搜索场景下以倒排召回为主向量召回为辅再叠加个性化召回推荐场景下以兴趣向量召回和协同过滤召回为主叠加热点召回。两种场景共享同一个召回中心框架只是路由配置不同。这里有一个关键的技术点向量召回在搜推一体里怎么统一。传统做法是给query和doc各自训练一个编码器映射到同一个向量空间。搜推一体可以更进一步直接用统一的语义向量模型同时服务搜索和推荐两个场景。这个模型不但要理解词义还要理解用户兴趣和物料之间的语义关系。实操上负样本的选取直接影响向量模型效果搜索场景负样本可以全库随机采样推荐场景负样本应该更侧重曝光未点击两套采样逻辑在统一模型里要怎么协调这个细节很值得打磨。2.3 排序层多目标排序模型与搜索推荐共享排序层是决定最终效果的关键环节也是搜推一体能出效果、能提升业务指标的核心抓手。传统架构下搜索精排模型优化的是相关性、点击率推荐精排模型优化的是点击率、时长、转化率两边各训各的。搜推一体的排序层要做的不是让两个模型变成一个而是让两个模型共享底层的特征和网络结构各自保留场景特有的输出头。我用的是一个多任务学习框架底层共享一个特征工程模块和Embedding层中间共享几层全连接网络上层分场景出多个输出头。具体来说搜索场景的输出头重点优化相关性评分、点击率、搜索转化率推荐场景的输出头重点优化点击率、停留时长、转化率同时还有一个共享的输出头来建模用户满意度。这个设计的好处是明显的。搜索场景的训练数据里有大量用户主动表达的意图信号这些信号能帮助模型更好地理解用户对内容类型的偏好推荐场景的训练数据里有效果信号比如看完、收藏、购买这些信号也能辅助搜索排序。通过共享底层表达两个场景互相借力这是我见过的最有效的搜推融合方式。排序特征方面也要讲一下。搜推一体架构下的特征体系要统一建设我通常会维护一个特征中心把用户侧特征、物品侧特征、上下文特征、交叉特征都集中在里面。搜索场景特有的特征比如query和doc的相关性特征、点击位置特征推荐场景没有推荐场景特有的特征比如用户历史行为序列的丰富度、兴趣多样性搜索场景可能用不上。特征中心要做的是把所有特征统一管理场景按需取用而不是各搞各的特征服务。排序层有一个实操上的坑想特别提醒搜索排序不能因为引入个性化就把相关性做没了。有的团队在做搜推一体的时候为了让用户点击率看起来更好看把个性化权重调得很高结果用户搜“苹果手机”出来一堆用户之前浏览过的其他手机品牌相关性崩了用户很快就流失了。搜索的底线是相关性个性化是在相关性基础上的增强这个优先级不能颠倒。2.4 服务层场景路由与结果融合策略服务层是用户直接感知的一层也是搜推一体最终落到产品形态上的地方。服务层要解决的核心问题是一个请求进来怎么判断该走搜索链路还是推荐链路怎么融合两路的结果怎么保证响应延迟在可接受范围内。场景路由是服务层的第一步。用户从首页推荐流进来这明显是推荐场景用户在搜索框输入query这是搜索场景但搜推一体要处理的远不止这两种。搜索无结果或者结果很少的时候要不要触发推荐兜底搜索结束之后要不要在结果页底部给一个“猜你想找”的推荐流这些都在服务层的路由逻辑里。结果融合是另一个关键设计。我见过两种主流策略一种叫做结果拼接就是搜索的结果按照相关性排序推荐的结果作为补充放在后面或者穿插其中另一种叫做重排融合就是搜索召回的所有候选进入同一个重排模型用排序分融合相关性和个性化得分统一排序输出。第一种实现简单但融合感生硬第二种效果好但工程复杂度高而且对排序模型的融合能力要求很高。实际项目里我通常建议先做结果拼接把框架跑通再渐进式地升级到重排融合。服务层还有一个容易出现性能瓶颈的点搜索和推荐共用特征服务之后推荐场景的高并发请求会不会把特征服务打爆进而影响搜索的延迟这个我在项目里遇到过。解决办法是做多级缓存把用户画像、物料属性这些热点数据放到本地缓存特征服务扛不住的流量在缓存层就消化掉了真正打到存储层的请求量会小很多。3. 四阶段落地路径从现状盘点到底层打通架构设计得再漂亮落地还是得一步一步来。搜推一体这种体量的工程改造不可能直接一步到位推翻原有系统重构那样风险太大业务也不会答应。我比较推荐四阶段渐进式落地的路径每一阶段都有明确的目标和交付物业务也能在每个阶段看到实际收益。3.1 第一阶段盘点现状统一数据口径和ID体系落地搜推一体先别急着动架构先做盘点把家底摸清楚。这个阶段的目标是搞清楚现有搜索和推荐系统各自有哪些数据、哪些接口、哪些模型数据口径有什么差异为后续统一做好准备。盘点内容分成几块来看。数据资产方面搜索这边维护了哪些物料数据推荐这边维护了哪些两边对同一类内容的属性定义是否一致。行为数据方面两边的埋点体系分别是怎样的同一个用户行为在两套系统里分别怎么记录。ID体系方面用户的设备ID、登录ID、匿名ID在各系统里怎么关联物料的ID怎么映射。盘点之后要做的事情是统一ID和统一数据口径。用户的跨场景身份统一是这里的关键动作只有在同一个用户ID下才能把搜索行为和推荐行为串联起来后续的画像统一、模型共享才有基础。这个阶段不一定需要上线新功能完全是基础工程建设但对后续所有阶段都非常关键。我见过有些团队跳过了这个阶段结果做到排序层就开始数据对不上又回过头来补课反而浪费了更多时间。这个阶段的交付物主要是三份文档数据资产清单、ID映射规范、行为事件定义规范。不要小看这些文档它们决定了后面所有工程动作能不能顺畅推进。3.2 第二阶段共享基础设施统一召回和特征服务第一阶段把数据基础打好之后第二阶段开始动真格的把两个系统的基础设施层打通。这个阶段的目标是搜索和推荐共用一套召回框架和特征服务但模型和排序逻辑暂时还是各跑各的。召回层在这个阶段要做的就是上面说过的那种召回中心改造。倒排索引保留在搜索侧向量召回做成统一服务用户兴趣召回抽出来作为独立模块。搜索场景继续用自己的倒排召回为主推荐场景继续用兴趣召回为主但底层的召回框架是同一个后续调整召回组合就非常方便。特征服务统一也是这个阶段的重头戏。把散落在搜索和推荐两边的特征工程代码集中到一个特征中心统一管理特征的计算、存储、上线。特征中心上线之后搜索和推荐两个模型开始从同一个特征中心取特征这会带来一个显著的变化两边的特征口径完全一致了之前那种同一个用户在两套系统里看起来完全是两个人的问题从根上就消失了。这个阶段还要注意模型评估口径的打通。搜索模型的离线评估和推荐模型的离线评估原本是各评各的指标定义都不一样。第二阶段应该把评估体系也统一起来公共的指标用同一套定义后续做融合改进的时候才比较得心应手。3.3 第三阶段排序模型融合多任务学习落地基础设施打通之后第三阶段开始动模型。这个阶段的目标是搜索和推荐的排序模型从各自独立训练演进为共享底层表达的多任务学习架构。第三阶段的落地路径我一般分三步走。第一步是特征共享把第二阶段建好的特征中心真正用起来搜索模型和推荐模型的输入特征都从特征中心获取去掉各自独立的特征工程逻辑。第二步是Embedding共享用户和物料的Embedding在模型底座里共享两个场景用同一套表示学习这一步是模型层融合的关键需要把两边的训练数据都喂给同一个底座模型。第三步是输出头分场景底座共享上层保留场景特有的输出头和多目标优化。这个阶段要特别关注样本处理。搜索样本和推荐样本的分布差异很大搜索样本通常包含比较强的相关性信号推荐样本更侧重兴趣信号。多任务模型要同时在这两类样本上训练就需要在样本采样和Loss权重上做一些平衡。我当时是怎么做的呢给每个场景的Loss函数设置可调节的权重初期权重偏向搜索场景保证相关性能力不退化等模型稳定之后再逐步根据业务目标调整权重。这个阶段最容易出现的问题是模型离线指标看起来不错但线上AB测效果反而下降了。这种情况多半是因为离线评估和线上评估的口径不一致第三阶段一定要把线上AB实验平台的能力建设好搜索和推荐共用一套实验平台实验可以灵活配置场景维度灰度发布也要支持按场景逐步放量。3.4 第四阶段业务联动与场景闭环前三个阶段做的是技术与架构层面的打通第四阶段要解决的是业务层面的联动。这个阶段的目标是搜索和推荐在业务玩法上互相渗透形成完整的用户场景闭环。业务联动的形式其实挺丰富的。一个常见玩法是搜索引导推荐用户在搜索框搜索之后把搜索意图沉淀到用户的短期兴趣画像中推荐流在接下来一段时间里重点推荐与搜索意图相关的内容。这个玩法可以直接复用第一阶段的用户统一画像和第三阶段的共享模型能力实现成本不算高但效果通常很显著。还有一种玩法是推荐带搜索推荐流里有一些内容用户感兴趣但展示不完整这时候在推荐卡片上做一个搜索入口用户点击之后直接带着这个内容相关的query进入搜索结果页。这个交互看着简单但它把“逛”和“搜”两件事自然衔接起来了用户行为路径变顺了整体转化率一般都会有提升。搜索结果页的个性化补充也值得做。在确保相关性不受影响的前提下搜索结果底部穿插推荐内容根据用户的长期兴趣和实时搜索意图做个性化。这个玩法需要结果融合策略的支持这也是第四阶段可以重点打磨的。我有一次比较成功的实践是把搜索和推荐放在同一个复盘体系里去迭代。原来搜索团队和推荐团队各看各的指标现在统一看用户全链路转化搜索场景的指标变化和推荐场景的指标变化放到一张报表里对比这样两边团队才会真正往同一个方向努力。从组织协作的角度来说搜推一体不光是技术架构的融合也要求团队协作方式跟着调整这个软性的问题如果解决不好技术融合的效果也会大打折扣。4. 实战中的常见问题与排查技巧实录搜推一体做到现在踩过的坑不少这里整理几个典型问题都是实际项目里几乎一定会遇到的给做这块的朋友做个参考。4.1 数据一致性导致的两边用户理解分裂问题表现搜索场景的个性化推荐效果一直提不上去排查发现推荐场景认为用户喜欢A品类搜索场景认为用户偏好B品类两边对用户的判断完全对不上。排查思路这种问题九成以上出在数据层。先检查两个场景的行为数据是不是进到了同一个数仓是不是用了同一套事件定义。再检查用户ID是不是同一个体系不要在应用层做映射要在数据接入层就统一。最后检查特征服务的输入是不是一致如果特征计算逻辑在两边各有一份一定要统一到特征中心去。这个问题我在项目里遇到过好几次最典型的案例是搜索侧记录的是“搜索点击数”推荐侧记录的是“曝光点击数”两边都叫点击但事件定义完全不同。数据基础设施排查不到位就上线模型结果可想而知。我的建议是数据层改造宁可慢一点也要把口径问题彻底解决掉。4.2 相关性被个性化带偏导致搜索体验崩坏问题表现搜推一体改造之后搜索场景的点击率上升了但用户的搜索满意度反而下降了具体表现是搜出来的内容“看着相关但并不精准”用户越来越倾向于改query重新搜。排查思路这是一体化改造最容易出现的方向性错误根源在于排序模型把个性化权重调得太高了。排查方法很简单看搜索结果里相关性分低的候选是不是经常排到前面看搜索无点击率是不是在上升搜索改query率是不是也在上升。解决办法是给排序模型加相关性约束。我的做法是在多任务模型里加一个相关性置信度门槛相关性分低于一定阈值的候选不能进入最终排序结果个性化只能在相关性合格的范围内发挥作用。搜索场景的底线一定要守住宁可牺牲一部分点击率也要保证相关性体验。4.3 向量召回在搜索场景中语义漂移问题表现统一向量模型上线之后推荐场景的效果有提升但搜索场景的召回质量没升反降召回进来一些“语义相似但完全不相关”的内容比如搜“苹果手机”返回了苹果最新发布的耳机。排查思路向量模型是用统一的语义训练目标训练的但搜索场景对精确匹配的要求要远高于推荐场景。推荐场景中“差不多相关”就够了搜索场景中差一点都不行。问题出在向量模型没有针对搜索场景做专门优化。解决办法是在向量模型的训练目标里加入搜索场景特有的语义匹配约束比如增加query-doc的字面匹配特征、引入相关性标注数据作为训练信号。实操上建议把场景特定样本抽一部分出来单独做微调让统一的语义向量模型在保持推荐语义能力的同时也能满足搜索精确匹配的需求。4.4 AB实验互相打架指标无法准确评估问题表现搜索团队和推荐团队同时在各自场景上了新模型两边单独看指标都有提升但整体业务指标没有变化团队之间开始互相质疑。排查思路这个问题的根源在于实验的隔离机制不够。搜推一体之后搜索和推荐共用底层特征和模型底座一个场景的模型改动可能通过共享底座影响另一个场景的效果。如果两边各开各的实验互相干扰指标当然说不清楚。解决办法是把实验平台升级成支持分层实验和联动实验的模式。底层模型和特征属于公共层公共层实验要统一评审不能随便上场景层可以独立实验但要通过实验平台设置好隔离策略。我在项目里推行的原则是公共层动一个字都要全局评估场景层随便玩但要在统一框架内看效果。这个机制建立起来之后团队之间的扯皮少了很多。4.5 性能瓶颈融合后的服务链路延迟超标问题表现搜推一体改造过程中搜索场景是核心场景性能要求高但接入共享特征服务之后延迟明显增加从原来的50毫秒涨到了150毫秒。排查思路延迟增加大概率是特征服务的依赖链路变长了。搜索原本从本地特征库取特征改造后要从远端特征中心取网络消耗和序列化消耗都会增加。解决办法是建立分级的特征存取策略。用户长期画像这类变化缓慢的特征放到本地缓存并定时更新实时行为特征走远端但要做批量获取物料属性特征可以随索引一起打包下发不用单独远程取。顺便提醒一下不要在服务链路上做同步调用能批量的功能尽量批量能异步的功能尽量异步这些细节会直接影响体验。5. 搜推一体架构设计的核心心得技术细节聊了很多最后分享几个我实际做项目的总体体会比较零散但都很重要。第一搜推一体的价值判断要回归业务场景。不是所有业务都需要搜推一体如果你的搜索流量和推荐流量都很小用户行为也没那么复杂分开维护两套系统成本其实更低。搜推一体适合的是用户体量大、搜索和推荐都是核心场景、用户行为链路长的产品形态。做之前先想清楚价值在哪里别为了技术先进而上。第二数据基础比模型算法重要得多。搜推一体的实施顺序里数据层是最先要投入的也是后续所有阶段的地基。我看过太多团队一上来就搞多任务模型结果被数据口径不一致反复折磨模型上线之后效果也不理想。先把数据搞干净后面会顺很多。第三工程架构比单点算法更能决定成败。向量召回、多任务模型、重排融合这些单点技术都有人能做好但搜推一体的难点在于把这些能力组合成一个统一的、可维护的、高性能的系统。一个合理的分层架构、一个灵活的召回框架、一个稳定的特征中心这些工程能力才是项目能够持续推进的保障。第四场景之间的优先关系要理清楚。搜推一体不等于搜索推荐对等融合每个产品都有自己的核心场景。有的产品搜索是核心推荐是辅助那就要以搜索为主推荐服务于搜索场景的延伸有的产品推荐是核心搜索是补充那就要反过来。场景优先级决定了你资源配置的方向这个定了架构选择就顺了。第五组织协作方式要跟技术架构同步调整。搜推一体如果只是技术团队在做业务团队和算法团队还是按搜索、推荐分开的模式在运作那就很难形成真正的闭环。尽可能让团队围绕用户全链路来组织指标考核也瞄着全链路来定这样技术架构的融合才能发挥出它应有的效果。搜推一体这条路每一步都不轻松但走通了系统效果和团队效率都会有质的提升。希望这些经验能帮正在这条路上的朋友少踩几个坑。
做搜推一体这个方向最早是因为受不了两套系统互相打架。用户在搜索框里敲了一个词搜出来的结果和首页推荐流推的东西完全对不上这边刚搜完“无线耳机”回首页还在推手机壳。业务方天天来问为什么不能把搜索和推荐打通技术那边一听就头大说这是两套链路数据、模型、接口全是独立的打通等于重构。但重构这件事又绕不过去因为用户的行为信号已经明摆着在说搜和逛本来就是同一件事。这篇内容就是来聊清楚搜推一体到底怎么做四层架构怎么搭四阶段怎么落地适合正在搞搜索或者推荐系统、想往一体化方向演进的技术团队参考。1. 搜推一体到底在解决什么问题先别急着聊架构得先把痛点说透。搜索和推荐分开建设在业务规模小的时候没什么问题但一旦量级上来各种割裂感会越来越明显。1.1 两套系统各自为战的典型症状先从用户视角看。一个用户进入App他的行为路径通常是先逛逛首页推荐流看到感兴趣的点进去然后可能产生一个具体的需求去搜索框里输入关键词。这个过程中用户的兴趣是连续的但系统给的反应是断裂的。推荐流不知道用户刚才搜过什么搜索也不知道用户平时喜欢什么于是出现上面说的那种“搜完无线耳机还推手机壳”的尴尬。再从技术视角看割裂体现在三个层面。数据层面推荐系统有一套用户行为日志、物料标签体系搜索系统有另一套倒排索引、相关性特征两边各存各的口径都对不上。模型层面推荐用协同过滤、双塔搜索用LTR排序模型特征工程的做法也不一样同一个用户在这个系统里是一个ID体系在另一个系统里可能又是另一套ID。服务层面更麻烦搜索有Query理解、召回、精排链路推荐有召回、粗排、精排链路接口协议不同运维部署也是两套算力资源也没法共享。这些割裂带来的直接后果是开发效率低、资源浪费、用户体验差、业务指标上不去。更麻烦的是当业务方提出“能不能在搜索结果里也做个性化”“能不能在推荐流里也插入搜索热点”这类需求时两套团队互相扯皮最后经常不了了之。1.2 搜推融合的本质用户意图的连续建模搜推一体不是把两套系统简单合并成一套而是要上升到用户意图的连续建模层面。用户的行为是一个从“泛兴趣”到“具体需求”的连续光谱推荐擅长捕捉泛兴趣搜索擅长满足具体需求两者本来就应该互为补充。我见过一个比较直观的类比推荐像是逛街用户漫无目的地看系统引导他发现兴趣搜索像是带着购物清单去店里用户目标明确系统要高效匹配。传统架构下这两个场景是两拨人在服务用户在这两个场景之间来回切换时系统完全感知不到。搜推一体要做的就是让同一套用户理解贯穿两个场景让逛的时候积累的兴趣信号能辅助搜索让搜的时候表达的意图信号也能反馈到推荐。这个本质想清楚之后架构上的很多选择就顺理成章了。比如为什么需要统一用户画像、为什么需要共享特征体系、为什么召回层要做成多路融合这些都是为了支持连续建模这个核心目标。2. 四层架构拆解从数据到服务的完整链路搜推一体的架构设计我通常把它分成四层来看数据层、召回层、排序层、服务层。这四层不是简单画个分层图就完事每一层都要回答“搜索和推荐怎么在这里融合”这个关键问题。2.1 数据层统一物料、行为与画像口径数据层是整个搜推一体的地基也是前期投入最大、最容易踩坑的一层。很多人以为搜推一体最难的是模型实际落地时才发现最难的是数据对齐。数据层要解决三个统一。第一个是物料统一商品、文章、视频这些内容数据要有统一的ID体系和属性规范。传统架构下搜索这边有一套类目体系推荐那边是另一套标签体系同一样东西在两个系统里的表示完全不一样。统一之后一份物料数据同时供搜索和推荐使用属性、标签、时效性信息全在一个地方维护。第二个是行为统一。用户点击、曝光、收藏、购买、搜索点击这些行为事件要用一套统一的埋点规范和事件定义来采集。搜索结果的点击是一种正反馈信号推荐流的曝光和点击也是正反馈信号这些信号在传统架构下是分开存储的在搜推一体架构下必须进入同一个行为数仓。我在项目里见过最典型的问题就是推荐侧的样本只用了推荐场景的行为搜索侧的样本只用了搜索场景的行为导致同一个用户的兴趣画像在两套模型里完全是两种样子。第三个是画像统一。用户画像、长期兴趣、短期兴趣标签这些要在同一个画像服务里生成和维护。搜索侧需要的用户背景信息推荐侧需要的用户历史行为序列都从同一个画像服务取保证用户理解的一致性。数据层实操上要特别注意ID映射的问题。我有一个经历过几次项目的经验不要在应用层做ID映射而是要在数据接入层就统一。有些团队觉得临时做个映射表就行结果后期每次数据对不上都要回来查映射非常痛苦。2.2 召回层搜索召回与推荐召回的统一框架召回层是搜推一体架构里技术含量最高的部分也是最考验设计功力的地方。搜索的召回和推荐的召回原本是两套完全不同的思路要统一起来并不容易。搜索召回的核心是Query理解加倒排索引。用户输入一个query先做分词、纠错、改写、意图识别然后拿处理后的term去倒排索引里找候选文档。推荐召回的核心是用户兴趣匹配通常用双塔、向量召回、协同过滤这类方案从海量物料里找出用户可能感兴趣的候选集。搜推一体的召回层要做的是把这两套召回能力放进同一个框架里让它们可以灵活组合、统一调度。我在架构设计上用的方法是构建一个召回中心把各种召回源都做成可插拔的组件比如搜索倒排召回基于query分词结果的BM25召回这是搜索场景的基础链路保留但不能丢语义向量召回把query和doc都向量化在向量空间里做近邻检索这是搜索和推荐都可以共享的能力用户兴趣向量召回基于用户行为序列生成的兴趣向量从向量库召回与兴趣相似的候选这是推荐的经典玩法协同过滤召回基于用户行为相似性找邻居再找邻居喜欢的物料适合推荐场景热点召回基于实时热点和流行度做召回两个场景都适用召回中心的统一调度逻辑是这样的搜索场景下以倒排召回为主向量召回为辅再叠加个性化召回推荐场景下以兴趣向量召回和协同过滤召回为主叠加热点召回。两种场景共享同一个召回中心框架只是路由配置不同。这里有一个关键的技术点向量召回在搜推一体里怎么统一。传统做法是给query和doc各自训练一个编码器映射到同一个向量空间。搜推一体可以更进一步直接用统一的语义向量模型同时服务搜索和推荐两个场景。这个模型不但要理解词义还要理解用户兴趣和物料之间的语义关系。实操上负样本的选取直接影响向量模型效果搜索场景负样本可以全库随机采样推荐场景负样本应该更侧重曝光未点击两套采样逻辑在统一模型里要怎么协调这个细节很值得打磨。2.3 排序层多目标排序模型与搜索推荐共享排序层是决定最终效果的关键环节也是搜推一体能出效果、能提升业务指标的核心抓手。传统架构下搜索精排模型优化的是相关性、点击率推荐精排模型优化的是点击率、时长、转化率两边各训各的。搜推一体的排序层要做的不是让两个模型变成一个而是让两个模型共享底层的特征和网络结构各自保留场景特有的输出头。我用的是一个多任务学习框架底层共享一个特征工程模块和Embedding层中间共享几层全连接网络上层分场景出多个输出头。具体来说搜索场景的输出头重点优化相关性评分、点击率、搜索转化率推荐场景的输出头重点优化点击率、停留时长、转化率同时还有一个共享的输出头来建模用户满意度。这个设计的好处是明显的。搜索场景的训练数据里有大量用户主动表达的意图信号这些信号能帮助模型更好地理解用户对内容类型的偏好推荐场景的训练数据里有效果信号比如看完、收藏、购买这些信号也能辅助搜索排序。通过共享底层表达两个场景互相借力这是我见过的最有效的搜推融合方式。排序特征方面也要讲一下。搜推一体架构下的特征体系要统一建设我通常会维护一个特征中心把用户侧特征、物品侧特征、上下文特征、交叉特征都集中在里面。搜索场景特有的特征比如query和doc的相关性特征、点击位置特征推荐场景没有推荐场景特有的特征比如用户历史行为序列的丰富度、兴趣多样性搜索场景可能用不上。特征中心要做的是把所有特征统一管理场景按需取用而不是各搞各的特征服务。排序层有一个实操上的坑想特别提醒搜索排序不能因为引入个性化就把相关性做没了。有的团队在做搜推一体的时候为了让用户点击率看起来更好看把个性化权重调得很高结果用户搜“苹果手机”出来一堆用户之前浏览过的其他手机品牌相关性崩了用户很快就流失了。搜索的底线是相关性个性化是在相关性基础上的增强这个优先级不能颠倒。2.4 服务层场景路由与结果融合策略服务层是用户直接感知的一层也是搜推一体最终落到产品形态上的地方。服务层要解决的核心问题是一个请求进来怎么判断该走搜索链路还是推荐链路怎么融合两路的结果怎么保证响应延迟在可接受范围内。场景路由是服务层的第一步。用户从首页推荐流进来这明显是推荐场景用户在搜索框输入query这是搜索场景但搜推一体要处理的远不止这两种。搜索无结果或者结果很少的时候要不要触发推荐兜底搜索结束之后要不要在结果页底部给一个“猜你想找”的推荐流这些都在服务层的路由逻辑里。结果融合是另一个关键设计。我见过两种主流策略一种叫做结果拼接就是搜索的结果按照相关性排序推荐的结果作为补充放在后面或者穿插其中另一种叫做重排融合就是搜索召回的所有候选进入同一个重排模型用排序分融合相关性和个性化得分统一排序输出。第一种实现简单但融合感生硬第二种效果好但工程复杂度高而且对排序模型的融合能力要求很高。实际项目里我通常建议先做结果拼接把框架跑通再渐进式地升级到重排融合。服务层还有一个容易出现性能瓶颈的点搜索和推荐共用特征服务之后推荐场景的高并发请求会不会把特征服务打爆进而影响搜索的延迟这个我在项目里遇到过。解决办法是做多级缓存把用户画像、物料属性这些热点数据放到本地缓存特征服务扛不住的流量在缓存层就消化掉了真正打到存储层的请求量会小很多。3. 四阶段落地路径从现状盘点到底层打通架构设计得再漂亮落地还是得一步一步来。搜推一体这种体量的工程改造不可能直接一步到位推翻原有系统重构那样风险太大业务也不会答应。我比较推荐四阶段渐进式落地的路径每一阶段都有明确的目标和交付物业务也能在每个阶段看到实际收益。3.1 第一阶段盘点现状统一数据口径和ID体系落地搜推一体先别急着动架构先做盘点把家底摸清楚。这个阶段的目标是搞清楚现有搜索和推荐系统各自有哪些数据、哪些接口、哪些模型数据口径有什么差异为后续统一做好准备。盘点内容分成几块来看。数据资产方面搜索这边维护了哪些物料数据推荐这边维护了哪些两边对同一类内容的属性定义是否一致。行为数据方面两边的埋点体系分别是怎样的同一个用户行为在两套系统里分别怎么记录。ID体系方面用户的设备ID、登录ID、匿名ID在各系统里怎么关联物料的ID怎么映射。盘点之后要做的事情是统一ID和统一数据口径。用户的跨场景身份统一是这里的关键动作只有在同一个用户ID下才能把搜索行为和推荐行为串联起来后续的画像统一、模型共享才有基础。这个阶段不一定需要上线新功能完全是基础工程建设但对后续所有阶段都非常关键。我见过有些团队跳过了这个阶段结果做到排序层就开始数据对不上又回过头来补课反而浪费了更多时间。这个阶段的交付物主要是三份文档数据资产清单、ID映射规范、行为事件定义规范。不要小看这些文档它们决定了后面所有工程动作能不能顺畅推进。3.2 第二阶段共享基础设施统一召回和特征服务第一阶段把数据基础打好之后第二阶段开始动真格的把两个系统的基础设施层打通。这个阶段的目标是搜索和推荐共用一套召回框架和特征服务但模型和排序逻辑暂时还是各跑各的。召回层在这个阶段要做的就是上面说过的那种召回中心改造。倒排索引保留在搜索侧向量召回做成统一服务用户兴趣召回抽出来作为独立模块。搜索场景继续用自己的倒排召回为主推荐场景继续用兴趣召回为主但底层的召回框架是同一个后续调整召回组合就非常方便。特征服务统一也是这个阶段的重头戏。把散落在搜索和推荐两边的特征工程代码集中到一个特征中心统一管理特征的计算、存储、上线。特征中心上线之后搜索和推荐两个模型开始从同一个特征中心取特征这会带来一个显著的变化两边的特征口径完全一致了之前那种同一个用户在两套系统里看起来完全是两个人的问题从根上就消失了。这个阶段还要注意模型评估口径的打通。搜索模型的离线评估和推荐模型的离线评估原本是各评各的指标定义都不一样。第二阶段应该把评估体系也统一起来公共的指标用同一套定义后续做融合改进的时候才比较得心应手。3.3 第三阶段排序模型融合多任务学习落地基础设施打通之后第三阶段开始动模型。这个阶段的目标是搜索和推荐的排序模型从各自独立训练演进为共享底层表达的多任务学习架构。第三阶段的落地路径我一般分三步走。第一步是特征共享把第二阶段建好的特征中心真正用起来搜索模型和推荐模型的输入特征都从特征中心获取去掉各自独立的特征工程逻辑。第二步是Embedding共享用户和物料的Embedding在模型底座里共享两个场景用同一套表示学习这一步是模型层融合的关键需要把两边的训练数据都喂给同一个底座模型。第三步是输出头分场景底座共享上层保留场景特有的输出头和多目标优化。这个阶段要特别关注样本处理。搜索样本和推荐样本的分布差异很大搜索样本通常包含比较强的相关性信号推荐样本更侧重兴趣信号。多任务模型要同时在这两类样本上训练就需要在样本采样和Loss权重上做一些平衡。我当时是怎么做的呢给每个场景的Loss函数设置可调节的权重初期权重偏向搜索场景保证相关性能力不退化等模型稳定之后再逐步根据业务目标调整权重。这个阶段最容易出现的问题是模型离线指标看起来不错但线上AB测效果反而下降了。这种情况多半是因为离线评估和线上评估的口径不一致第三阶段一定要把线上AB实验平台的能力建设好搜索和推荐共用一套实验平台实验可以灵活配置场景维度灰度发布也要支持按场景逐步放量。3.4 第四阶段业务联动与场景闭环前三个阶段做的是技术与架构层面的打通第四阶段要解决的是业务层面的联动。这个阶段的目标是搜索和推荐在业务玩法上互相渗透形成完整的用户场景闭环。业务联动的形式其实挺丰富的。一个常见玩法是搜索引导推荐用户在搜索框搜索之后把搜索意图沉淀到用户的短期兴趣画像中推荐流在接下来一段时间里重点推荐与搜索意图相关的内容。这个玩法可以直接复用第一阶段的用户统一画像和第三阶段的共享模型能力实现成本不算高但效果通常很显著。还有一种玩法是推荐带搜索推荐流里有一些内容用户感兴趣但展示不完整这时候在推荐卡片上做一个搜索入口用户点击之后直接带着这个内容相关的query进入搜索结果页。这个交互看着简单但它把“逛”和“搜”两件事自然衔接起来了用户行为路径变顺了整体转化率一般都会有提升。搜索结果页的个性化补充也值得做。在确保相关性不受影响的前提下搜索结果底部穿插推荐内容根据用户的长期兴趣和实时搜索意图做个性化。这个玩法需要结果融合策略的支持这也是第四阶段可以重点打磨的。我有一次比较成功的实践是把搜索和推荐放在同一个复盘体系里去迭代。原来搜索团队和推荐团队各看各的指标现在统一看用户全链路转化搜索场景的指标变化和推荐场景的指标变化放到一张报表里对比这样两边团队才会真正往同一个方向努力。从组织协作的角度来说搜推一体不光是技术架构的融合也要求团队协作方式跟着调整这个软性的问题如果解决不好技术融合的效果也会大打折扣。4. 实战中的常见问题与排查技巧实录搜推一体做到现在踩过的坑不少这里整理几个典型问题都是实际项目里几乎一定会遇到的给做这块的朋友做个参考。4.1 数据一致性导致的两边用户理解分裂问题表现搜索场景的个性化推荐效果一直提不上去排查发现推荐场景认为用户喜欢A品类搜索场景认为用户偏好B品类两边对用户的判断完全对不上。排查思路这种问题九成以上出在数据层。先检查两个场景的行为数据是不是进到了同一个数仓是不是用了同一套事件定义。再检查用户ID是不是同一个体系不要在应用层做映射要在数据接入层就统一。最后检查特征服务的输入是不是一致如果特征计算逻辑在两边各有一份一定要统一到特征中心去。这个问题我在项目里遇到过好几次最典型的案例是搜索侧记录的是“搜索点击数”推荐侧记录的是“曝光点击数”两边都叫点击但事件定义完全不同。数据基础设施排查不到位就上线模型结果可想而知。我的建议是数据层改造宁可慢一点也要把口径问题彻底解决掉。4.2 相关性被个性化带偏导致搜索体验崩坏问题表现搜推一体改造之后搜索场景的点击率上升了但用户的搜索满意度反而下降了具体表现是搜出来的内容“看着相关但并不精准”用户越来越倾向于改query重新搜。排查思路这是一体化改造最容易出现的方向性错误根源在于排序模型把个性化权重调得太高了。排查方法很简单看搜索结果里相关性分低的候选是不是经常排到前面看搜索无点击率是不是在上升搜索改query率是不是也在上升。解决办法是给排序模型加相关性约束。我的做法是在多任务模型里加一个相关性置信度门槛相关性分低于一定阈值的候选不能进入最终排序结果个性化只能在相关性合格的范围内发挥作用。搜索场景的底线一定要守住宁可牺牲一部分点击率也要保证相关性体验。4.3 向量召回在搜索场景中语义漂移问题表现统一向量模型上线之后推荐场景的效果有提升但搜索场景的召回质量没升反降召回进来一些“语义相似但完全不相关”的内容比如搜“苹果手机”返回了苹果最新发布的耳机。排查思路向量模型是用统一的语义训练目标训练的但搜索场景对精确匹配的要求要远高于推荐场景。推荐场景中“差不多相关”就够了搜索场景中差一点都不行。问题出在向量模型没有针对搜索场景做专门优化。解决办法是在向量模型的训练目标里加入搜索场景特有的语义匹配约束比如增加query-doc的字面匹配特征、引入相关性标注数据作为训练信号。实操上建议把场景特定样本抽一部分出来单独做微调让统一的语义向量模型在保持推荐语义能力的同时也能满足搜索精确匹配的需求。4.4 AB实验互相打架指标无法准确评估问题表现搜索团队和推荐团队同时在各自场景上了新模型两边单独看指标都有提升但整体业务指标没有变化团队之间开始互相质疑。排查思路这个问题的根源在于实验的隔离机制不够。搜推一体之后搜索和推荐共用底层特征和模型底座一个场景的模型改动可能通过共享底座影响另一个场景的效果。如果两边各开各的实验互相干扰指标当然说不清楚。解决办法是把实验平台升级成支持分层实验和联动实验的模式。底层模型和特征属于公共层公共层实验要统一评审不能随便上场景层可以独立实验但要通过实验平台设置好隔离策略。我在项目里推行的原则是公共层动一个字都要全局评估场景层随便玩但要在统一框架内看效果。这个机制建立起来之后团队之间的扯皮少了很多。4.5 性能瓶颈融合后的服务链路延迟超标问题表现搜推一体改造过程中搜索场景是核心场景性能要求高但接入共享特征服务之后延迟明显增加从原来的50毫秒涨到了150毫秒。排查思路延迟增加大概率是特征服务的依赖链路变长了。搜索原本从本地特征库取特征改造后要从远端特征中心取网络消耗和序列化消耗都会增加。解决办法是建立分级的特征存取策略。用户长期画像这类变化缓慢的特征放到本地缓存并定时更新实时行为特征走远端但要做批量获取物料属性特征可以随索引一起打包下发不用单独远程取。顺便提醒一下不要在服务链路上做同步调用能批量的功能尽量批量能异步的功能尽量异步这些细节会直接影响体验。5. 搜推一体架构设计的核心心得技术细节聊了很多最后分享几个我实际做项目的总体体会比较零散但都很重要。第一搜推一体的价值判断要回归业务场景。不是所有业务都需要搜推一体如果你的搜索流量和推荐流量都很小用户行为也没那么复杂分开维护两套系统成本其实更低。搜推一体适合的是用户体量大、搜索和推荐都是核心场景、用户行为链路长的产品形态。做之前先想清楚价值在哪里别为了技术先进而上。第二数据基础比模型算法重要得多。搜推一体的实施顺序里数据层是最先要投入的也是后续所有阶段的地基。我看过太多团队一上来就搞多任务模型结果被数据口径不一致反复折磨模型上线之后效果也不理想。先把数据搞干净后面会顺很多。第三工程架构比单点算法更能决定成败。向量召回、多任务模型、重排融合这些单点技术都有人能做好但搜推一体的难点在于把这些能力组合成一个统一的、可维护的、高性能的系统。一个合理的分层架构、一个灵活的召回框架、一个稳定的特征中心这些工程能力才是项目能够持续推进的保障。第四场景之间的优先关系要理清楚。搜推一体不等于搜索推荐对等融合每个产品都有自己的核心场景。有的产品搜索是核心推荐是辅助那就要以搜索为主推荐服务于搜索场景的延伸有的产品推荐是核心搜索是补充那就要反过来。场景优先级决定了你资源配置的方向这个定了架构选择就顺了。第五组织协作方式要跟技术架构同步调整。搜推一体如果只是技术团队在做业务团队和算法团队还是按搜索、推荐分开的模式在运作那就很难形成真正的闭环。尽可能让团队围绕用户全链路来组织指标考核也瞄着全链路来定这样技术架构的融合才能发挥出它应有的效果。搜推一体这条路每一步都不轻松但走通了系统效果和团队效率都会有质的提升。希望这些经验能帮正在这条路上的朋友少踩几个坑。
