搜推一体：搜索与推荐融合的四层架构及落地实践

搜推一体这个提法这几年在搜广推圈子里热度一直很高。我自己做了几年搜索和推荐系统最大的感受是搜索和推荐虽然在产品形态上一个叫“搜”、一个叫“推”但底层要解决的问题高度重叠——用户理解、内容理解、匹配排序。过去很多公司把这两个场景当成两套独立系统来建设Query理解一套、用户画像一套、特征管道一套、排序模型又一套结果就是投入翻倍、迭代效率减半用户在搜索结果页和推荐Feed里看到的体验还经常互相矛盾。这篇文章就把搜推一体的核心思路掰开揉碎讲一遍为什么要融合、四层架构怎么划分、四阶段落地怎么推进以及我自己在推进过程中踩过的坑。如果你正在设计或者重构搜索、推荐系统无论团队大小这篇文章都能给你一张能直接照着走的路线图。1. 搜推一体搜索和推荐凭什么能融合又为什么非融不可1.1 本质差异一个是“找”一个是“逛”搜索的核心是“意图明确”。用户输入一个Query比如“男士运动鞋”他心里已经有一个大概的边界品类、性别、使用场景。这时候系统要解决的核心问题是“相关性”——把和Query语义匹配的内容找出来再按质量、时效、个性化做排序。搜索的评估标准也相对清晰用户点没点、搜完满不满意、有没有二次搜索。推荐的核心是“意图模糊”。用户打开App没有输入任何词系统要从用户的历史行为、当前上下文里猜他此刻可能喜欢什么。这时候重点不是相关性而是“探索性”“多样性”“惊喜感”评估指标也更多元点击率、停留时长、完播率、交易转化率。这个差异决定了融合不是简单地把两套代码塞进一个服务里而是要在统一的框架下允许不同场景有不同目标权重和打散策略。搜索场景需要高精度推荐场景需要高召回两者在同一个架构里是可以共存的但前提是你要在一开始就想清楚“哪些层必须统一、哪些层必须保留差异”。1.2 分开建设为什么跑不动了很多团队不是一开始就想分开而是搜索和推荐往往是不同时期、不同团队建的慢慢变成了两套并行系统。分开建设带来四个非常现实的痛点重复建设严重。数据和特征管道是最明显的。搜索要建一份内容库的解析、清洗、索引管道推荐又要建一份几乎一样的内容标签管道搜索建了一套用户点击日志的采集和特征计算推荐又来一遍。如果是多模态内容图文特征抽取、视频特征抽取全部重复。数据和标签割裂。用户在搜索里表现出的强意图没有同步给推荐当成信号用户在推荐流里的兴趣探索也没有反馈到搜索的个性化排序里。结果就是搜索不知道用户兴趣全貌推荐也捕捉不到用户的明确需求。架构和资源浪费。两套检索服务、两套GPU推理集群、两套缓存和存储。搜索的倒排索引集群和推荐的向量索引集群各自维护故障还得分别处理。产品体验割裂。同一个内容在搜索里被强相关约束在推荐里被个性化约束两套策略口径不一致用户会觉得“这个App的逻辑是分裂的”。1.3 融合之后的收益可以先算一笔账融合初期最先见效的是资源成本。数据管道合并能砍掉30%以上的重复计算任务检索服务合并能降低近一半的冗余机器资源。接着是体验层面。搜索和推荐共用用户向量、内容向量、兴趣标签以后用户在搜索里没搜到的东西可以由推荐结果作为“补充探索”推荐里产生的深度兴趣也能用于搜索的个性化重排。再往后是模型能力增强。搜索有大量Query-Doc相关性标注数据推荐有大量用户行为序列数据统一训练能让模型同时学到两者的知识这对推荐冷启动和搜索个性化都有正向帮助。所以要记住一句话融合不是要消除搜索和推荐的区别而是要底层“合并同类项”场景层“保留差异化”。只有底层统一才能避免双份成本只有场景保留差异化用户体感才不会乱。2. 四层架构搜推一体的骨架怎么搭搜推一体要落地必须有一个清晰的架构分层。我这里用的是实践中验证过的四层结构统一数据与特征层、统一召回层、统一排序层、重排与服务层。每一层都有自己要解决的问题层与层之间通过标准化协议衔接不会互相越界。2.1 第一层统一数据与特征层这是搜推一体的地基。所有场景都建立在“内容”和“用户”两条主线上这两条主线必须统一建模。内容侧要建立统一的内容仓储。不管内容来自图文、视频、商品还是问答都统一成一套内容Schema。核心字段大概是这样{ content_id: c_1024, content_type: video, title: 10分钟搞定红烧肉, category_id: 5, tag_list: [美食, 家常菜, 红烧肉], text_embedding: [0.102, 0.334, ...], image_embedding: [0.201, ...], quality_score: 0.87, status: online }统一以后搜索做倒排索引、推荐做向量召回都从同一个Content Service拿数据。不要在搜索库里存一份内容字段、推荐库里再存一份两份一定会在某一天不一致。用户侧要统一用户ID体系打通搜索、推荐、浏览、交易的全行为序列。我建议把行为日志设计成一张跨域行为表每一条行为带上场景来源字段比如search_query、recommend_feed、detail_page、order_pay。这样模型能知道用户在某次会话里是先搜了一个词、然后点了某个推荐位、最后下单的整个行为链路是连续的。特征层要搭建统一特征平台同时服务离线和在线。特征平台要解决三个问题特征口径一致、实时特征与离线特征对齐、特征上线可复用。实操上我建议先把所有特征按照“实体-特征名-特征值”的规范注册比如用户侧特征前缀user_内容侧特征前缀item_场景侧特征前缀ctx_。然后统一通过特征服务API在线读取新场景接入时不需要重新开发特征管道。这一层最容易踩的坑就是“同一特征线上和线下算出来不一样”。比如“用户最近30天点击品类分布”这个特征离线用的是T-1的历史日志全量计算线上用的是Flink实时窗口累计两边口径稍微差一点模型离线在线效果就会撕裂。我的做法是离线训练和在线推理时都记录特征快照上线前用快照做线上回溯验证确保差异在可控范围。2.2 第二层统一召回层传统搜索召回靠倒排索引用BM25这类文本匹配算法从千万级文档里快速找到包含Query词项的候选集。传统推荐召回靠协同过滤、双塔向量、热门召回等多路通道。两者技术路线完全不一样这也是很多人觉得搜推一体很难落地的原因。搜推一体要做的是“召回框架统一”而不是把倒排索引砍掉。具体做法是抽象出一个通用检索服务内部集成两种引擎文本稀疏索引倒排和向量稠密索引Faiss或HNSW。再抽象出一个统一的打分框架召回阶段不再天然区分“搜索走倒排、推荐走向量”而是配置化的多路召回。我常用的打分函数长这样def recall_score(item, queryNone, userNone): text_score bm25(item, query) if query is not None else 0 vector_score dot(user.embedding, item.embedding) attr_score match_tags(user.interests, item.tags) # 不同场景可以在配置中心里调节权重 return params.alpha * text_score params.beta * vector_score params.gamma * attr_score搜索场景里alpha会调大保证文本相关性不漂移推荐场景里beta、gamma权重更高让个性化信号主导。权重本身放配置中心不用改代码就能调。这一层融合的价值非常大。搜索可以复用推荐的内容质量分和标签推荐可以复用搜索的倒排索引做“关键词兜底”比如用户刚搜过“露营装备”推荐流里就可以把露营类内容通过倒排通道捞回来。另外向量召回让搜索的语义泛化能力明显增强——用户搜“腿粗显瘦的裤子”即使标题里没有这些词也能通过语义向量召回款式相近的商品。2.3 第三层统一排序层排序层是搜推一体最核心、也最容易被保守派反对的地方。过去搜索精排模型专门研究Query-Doc相关性推荐精排模型专门研究用户兴趣序列。想让一个模型同时干两件事最怕的是“相关性被点击偏好带跑偏”。我的实际经验是不要试图训练一个完全共用的精排模型而是采用“共享底层 分场景塔”的多任务架构。底层共享用户行为序列编码、内容特征Embedding、上下文特征上层分裂出多个目标塔比如相关性分、点击率分、停留时长分、转化分。场景特征is_search作为一个重要特征输入模型。这样搜索线得到的是“相关性优先 点击偏好辅助”的分数推荐线得到的是“兴趣优先 相关性约束”的分数两个场景既能共享底层学习到的表示又不会完全同质化。粗排环节也一样。粗排模型传统上是独立的轻量模型这里可以统一成一套“双塔向量 简单交叉特征”的粗排框架。粗排候选量搜索一般是Top 200推荐一般是Top 500。关键是把粗排推理拆成向量内积形式用GPU批量算否则延迟扛不住。我见过很多失败的融合案例都是粗排环节算力没跟上链路超时导致整体AB掉点。排序层融合还要重构样本协议。搜索样本天然带有Query推荐样本没有Query两边标签也不一致。要统一训练样本格式每条样本包含场景标识、用户特征、内容特征、Query特征推荐场景可以为空、标签列表点击、时长、转化、相关性人工标注。统一样本协议之后多目标模型才能真正跨场景训练否则样本拼接都拼不了。2.4 第四层重排与服务层排序之后的重排搜索和推荐各有很强的场景约束。搜索需要结果相关性不漂移、同类结果不扎堆推荐需要多样性不能太差、不要连续给同质内容。这一层我不建议强行融合成一套逻辑更好的做法是提供一个统一的“重排策略引擎”里面内置通用算子MMR去重、DPP多样性、规则打散、置顶、兜底替换。搜索和推荐各自通过配置选择算子顺序和参数。服务层要统一出口。我习惯建设一个统一的Gateway对外接收两类请求带Query的搜索请求、不带Query的推荐请求。Gateway先统一做用户识别和上下文解析再分流到意图理解模块搜索的词权重、同义词、纠错和候选池服务最后统一走“召回→粗排→精排→重排”流程。这一步还要建设统一的实验平台。搜索和推荐的AB实验尽量使用同一个分流层可以用ExperimentContext统一管理。比如一个用户在一次访问里既参与搜索实验又参与推荐实验两个实验ID互不干扰。没有统一实验平台融合系统的版本管理会非常混乱上一个新模型都提心吊胆。重排和服务层的监控指标建议重点关注单链路延迟P99、无结果率、策略命中率、打散后多样性指数。这些指标能直观反映融合服务是否健康。这四层架构的整体逻辑是数据层是最底层的资产底座召回、排序是共用引擎能力最上面是统一网关和策略层。搜索和推荐各自的场景特点主要在网关之后的策略配置里体现。3. 四阶段落地从现状到搜推一体的演进路线架构是理想态落地才是真本事。我建议把搜推一体分成四个阶段逐步推进每一阶段都有明确的产出和验收标准不要想着一口气全做完。3.1 阶段一盘点与目标对齐融合不是一上来就动代码而是先做业务和系统的对齐。要回答几个问题搜索和推荐现在的北极星指标分别是什么哪些数据管道和特征完全重复哪些能力是某场景独有的、必须保留团队人力结构算法和工程是否齐全管理层对融合的期望排序是降本、提效还是体验增长。这个阶段产出的一份搜推一体规划文档至少要包含现状架构图、融合目标、里程碑节点、验收标准。我特别强调一定要拉上业务产品一起参与目标对齐否则融合做完变成纯技术自嗨产品根本不认可。另外要把“如果某个阶段指标负向立即叫停”的决策机制写清楚这会给团队安全感。3.2 阶段二基础设施与数据层融合这个阶段建议控制在3到6周先动数据不动排序风险最小、收益最明确。具体工作包括统一内容仓储接口让搜索和推荐从同一个Content Service读内容打通用户跨域行为序列把两边特征计算任务收口到统一特征平台把向量索引服务做成公共组件同时服务两个场景。完成标志是搜索和推荐同时从统一内容服务和特征平台读取数据线上AB效果不退步。只要这个阶段顺利完成整个融合项目的组织信心就建立起来了。我自己推进时这个阶段也是最容易出成绩的阶段因为成本账算得清楚领导看得见。3.3 阶段三召回与排序模型融合这一步进入核心算法建议分两个子阶段先融合召回再融合排序。召回融合的做法是先让两边的候选来源都包含对方的典型通道。搜索的候选加入向量召回通道推荐候选加入倒排关键词通道然后统一召回打分框架观察线上指标。这一步相对平滑因为候选集变多一般不会伤体验但要注意延迟和算力。排序融合要谨慎。先离线训练多目标模型统一Sample协议然后做离线评测分别看搜索场景和推荐场景的指标再用shadow模式跑几天线上真实流量对比线上模型和shadow模型的分位数分布最后小流量AB逐步放量。排序融合最容易翻车我建议在实验平台里保留旧模型一旦线上指标显著负向立刻切回。如果某个场景负向严重不要硬融。可以先保持该场景用独立模型分析清楚原因可能是特征冲突、样本权重问题、或是模型容量不够做消融实验后再重新尝试。3.4 阶段四服务治理与持续迭代融合不是一次性交付而是长期演进。这个阶段主要做三件事统一网关的流量治理和降级兜底建立完整的监控大盘数据质量、延迟、召回覆盖率、AB实验指标建立搜推联动的迭代机制。比如搜索侧发现高频Query无结果可以把这些Query作为信号推给推荐侧推荐侧补足相关供给这就是搜推联动的直接价值。还要做组织层面的沉淀更新统一特征字典、模型家族命名规范、架构文档。让后来的同事新写一个特征或模型时知道该接到哪里而不是再起一套新的。按一个中等规模团队10人左右来估算从阶段一到阶段四核心融合大概需要三个月。4. 实操中的关键问题与避坑指南搜推一体的坑不在概念而在细节。我把实操中最容易翻车的几个问题整理成表格方便大家直接对照。典型问题表现排查思路建议方案特征口径不一致离线AUC高、线上掉点检查离线在线特征分布差异统一特征平台 特征快照 shadow验证搜索相关性被点击率带偏搜索结果看着“不相关但点击高”看相关性人工标注指标多任务分离塔 相关性监督项单独加权统一服务延迟增大链路P99升高超时率上升分阶段打点找耗时瓶颈多路召回并发、粗排限制候选量、特征本地缓存AB实验互相污染搜索结果受推荐实验影响检查是否同一套分流逻辑统一实验平台ExperimentContext隔离推荐多样性下降推荐流连续同质内容查看多样性指标重排层DPP/MMR打散配置独立于排序模型4.1 特征口径不一致最隐蔽的离线在线撕裂这是我遇到最多的问题。现象很简单离线训练指标涨了线上AB反而跌了。查到最后往往不是模型问题而是“用户近30天点击类目分布”这类特征离线用的是T-1全量日志在线用的是近30天实时累积两边窗口和计算逻辑稍有不同特征值就漂了。解决方案有三步一是特征统一在Feature Store登记口径不允许各场景自己算二是离线训练时保留特征快照线上推理时也记录实际使用的特征值定期对比分布三是新特征上线前必须走shadow验证对比线上模型分的分位数。4.2 搜索相关性被推荐点击率带偏统一多目标模型最怕这个。用户点得多不代表相关搜索场景里用户可能是误点、可能是标题党吸引。如果模型过度拟合点击率搜索结果会慢慢偏向“吸引眼球但和Query无关”的内容。我的解决办法是在损失函数里给搜索相关性单独加一个监督项用人工标注的Query-Doc相关性样本训练一个相关性塔。推荐场景的样本不参与这个塔的更新但可以共享底层特征表示。相关性塔的输出在搜索最终排序里占较高权重点击率塔只做辅助。4.3 统一服务延迟和容量问题搜推一体之后网关承接的请求量是搜索加推荐的总和链路也更长。常见瓶颈有三个召回多路并发吃CPU、粗排候选量太大导致精排算力不够、特征重复读取拖慢延迟。我踩过坑之后总结的经验召回阶段多路并发不要串行粗排候选量设硬上限比如500高频特征做本地LRU缓存不要每次查远程特征服务向量检索分片部署冷热数据分离。还有一个不起眼但很重要的优化网关不要做太重的业务逻辑只做路由和协议转换业务逻辑下沉到下游服务。4.4 实验评估体系不统一搜索团队习惯看NDCG、MRR、Query无结果率推荐团队习惯看Recall、GAUC、人均时长。融合系统不能用单一指标评估否则会掩盖另一场景的退化。我建议建立统一评估面板分层展示离线层、在线实时监控层、AB实验指标层。同时用“场景化AB”模式——同一个实验流量按搜索请求和推荐请求分别切分统计。评估标准先定好预期比如“搜索NDCG不低于基线、推荐GAUC提升目标3%”双方达成共识后再放量。5. 搜推一体实践的进阶心得5.1 小团队怎么低成本启动如果团队只有两三个人别急着做排序模型融合。先做数据层和召回层融合成本低、收益稳。具体做法搜索和推荐共用内容服务、向量索引、特征平台召回打分改成配置化排序模型先在两边共享Embedding层各自上层塔独立。只要底层复用起来机器成本和人天成本都能省一大截而且架构上也已经迈出了搜推一体的第一步。记得在方案评审时告诉老板融合不是一次革命而是一次一次小的收敛。优先做低风险高收益的再逐步啃硬骨头。5.2 搜推一体和LLM/AIGC的结合现在大语言模型给搜推一体带来了新的变量。语义检索可以用LLM生成Query向量和内容向量替代或补充传统双塔生成式推荐可以直接生成内容摘要、标题改写统一内容理解能力LLM重排可以让大模型对候选结果做相关性判断和摘要生成但要注意延迟问题。搜推一体的四层架构天然适合承接这些能力因为统一内容仓储和特征平台已经存在LLM只需要接入一层就能同时服务搜索和推荐两个场景。如果你现在正在设计新系统我建议给LLM留好接口比如在内容仓储里预留“语义摘要”“向量版本号”字段在重排引擎里预留一个LLM打分算子位。写到最后分享一点个人体会。搜推一体这件事难点从来不在技术而在组织协同。搜索团队和推荐团队各有各的KPI你说要统一首先得让两边的负责人都觉得“融合后我的目标不会变差”。我做过几个项目最顺利的都不是因为技术方案多惊艳而是先花时间把目标对齐了把基础设施共享了让大家先尝到甜头后面自然有人愿意往里推。另外一个很实用的小技巧是在融合初期保留一个“场景差异开关”让每个场景都可以通过配置调整自己的召回权重和重排参数。这样技术上融合了业务上也没有被绑死项目推起来会顺畅很多。