摘要搜推一体架构的关键不是合并两个系统而是把数据层、召回层共用到底座上只在排序与策略层分场景分离落地顺序为统一事件流 → 共用向量召回 → 分场景排序 → 策略联动。搜索与推荐各建一套索引、各记一份日志是大多数企业的现状搜索由技术团队按查询相关性维护推荐由算法团队按用户偏好维护。结果是同一个用户在同一站点上的行为被切成两半——搜过连衣裙的用户推荐位仍在推他三年前买过的品类推荐位点击率高的商品搜索结果里却排在第五页。本篇边界本文是架构与实施篇只回答两套系统怎么在技术上融合——四层架构职责、四阶段落地与工程侧度量。搜索与推荐为什么要协同、业务价值怎么算、组织怎么配见姊妹篇《搜索推荐一体化为什么 112》两篇合起来才是完整答案。关键要点融合的第一原则是底座共用、策略分离数据、召回共用排序目标与干预规则分开。融合的第一件事不是改算法而是把两套系统的用户行为日志合并为一份事件流并统一实体 ID。向量检索是搜索与推荐共用的天然通道同一份向量索引既服务语义召回也服务相似推荐。四层架构职责清晰数据层保一份事实源、召回层多通道并行、排序层分场景加权、反馈层闭环回流。工程侧度量看索引一致性、召回复用率与向量更新延迟业务侧增量看跨入口转化见姊妹篇。落地建议分四阶段推进日志统一 → 召回共用 → 排序协同 → 策略联动每阶段独立验收。一、先划边界融合不等于合并架构设计的第一个决定是划清共用什么与分离什么。必须共用的实体 ID 与商品 / 内容索引、用户行为事件流、向量通道、画像与特征工程。这些是两侧都要读的同一份事实各建一遍等于把基础设施成本付两次。信号割裂的代价也来自这里——用户搜索轻薄羽绒服没下单这条强意图只落在搜索日志里推荐读不到。必须分离的排序目标与干预规则。搜索必须保障查什么出什么的相关性下限这是信任基础推荐的目标则是转化与多样性需要探索空间。两侧优化目标不同共用一套排序模型会互相拖累。Netflix 在技术博客中把推荐系统的计算划分为离线offline、近线nearline与在线online三层并指出关键难点在于如何把三种计算模式无缝结合管理——搜索系统同样面临这三层结构但三层之上的目标函数必须各写各的。一句话概括底座共用、策略分离。后文的四层设计都遵循这条线。二、协同的技术底座统一索引与共用召回协同落地的第一层是数据与索引。这一层做扎实后面的排序协同才有基础。2.1 统一用户事件流把搜索与推荐的行为日志合并为一份事件流至少包含事件类型搜索 / 点击 / 加购 / 收藏 / 下单 / 停留、主体 ID用户、商品、内容、上下文时间、终端、入口位置、查询词仅搜索事件有。合并的价值在于构造完整的兴趣序列一个用户搜索 A → 点击 A1 → 未购买 → 三天后从推荐位点击 B → 下单 B的完整链路只有在事件流统一后才能被看见。这条链路既是推荐模型的训练样本也是搜索排序里该用户偏好的实时信号。2.2 统一索引与向量通道第二层是把商品 / 内容索引收敛为一份并同时构建倒排索引与向量索引。Elasticsearch 官方文档将检索流程划分为查询构造、召回与打分三个阶段向量检索则把文本、图像等映射为稠密向量后按相似度召回——同一份向量索引既可以做搜索词语义召回也可以做相似商品推荐这正是两者共用的天然通道。工程上稠密向量的相似度检索通常由专门的库承担。Meta 开源的 FAISS 提供了大规模向量的聚类与近似最近邻检索能力是这类通道的常见底座选择。能力搜索侧用途推荐侧用途是否共用倒排索引关键词精确召回类目 / 属性过滤✅ 共用向量索引语义召回搜保暖外套出羽绒服相似物品召回看了又看✅ 共用用户画像个性化排序权重召回候选源✅ 共用行为事件流查询词分析与纠错兴趣序列建模✅ 共用排序模型相关性优先多样性 转化优先❌ 分场景干预规则必出 / 屏蔽词运营置顶 / 打散❌ 分场景三、一体化架构的四层设计底座统一之后一体化架构可以拆成四层数据层、召回层、排序层、反馈层。每层的职责与协同点如下。3.1 数据层一份事实源数据层负责把商品主数据、内容元数据、用户行为事件、上下文信号汇入同一处并对外提供一致的读取接口。关键约束是实体 ID 全局唯一——同一件商品在搜索索引与推荐候选池里必须是同一个 ID否则跨系统的行为无法归并。3.2 召回层多通道并行召回层同时开放多路通道倒排关键词召回、向量语义召回、协同过滤召回、热销 / 新品等规则召回。协同发生在通道复用上——搜索场景调用关键词 向量两路推荐场景调用协同过滤 向量两路向量通道由两者共用。3.3 排序层分场景加权排序层是必须分开的一层。搜索排序的首要目标是相关性用户输错了词就不能给出无关结果推荐排序的目标是转化率与多样性允许适度探索。可行的做法是共用底层模型、分场景调整目标权重搜索场景给相关性特征更高权重推荐场景给协同信号与多样性特征更高权重。这样既复用特征工程与模型训练基础设施又不牺牲各自的目标。3.4 反馈层闭环回流反馈层把曝光、点击、加购、下单等结果回流到数据层同时驱动两类动作一是刷新用户画像与物品画像二是调整召回通道的配额。Netflix 提到在线计算响应实时但受限于复杂度、离线计算能力强但容易陈旧反馈层的设计要点正是区分哪些信号必须实时回流如曝光去重、哪些可以批量更新如长期兴趣。四、实施路径从并行到融合的四个阶段协同不必一步到位。按以下四阶段推进每阶段独立验收风险与投入都可控。阶段一日志与 ID 统一2–4 周。打通搜索与推荐的行为事件流统一商品与内容 ID 映射。验收标准能按用户 ID 还原跨系统的完整行为序列跨系统 ID 映射覆盖率达到 95% 以上。阶段二索引与向量通道共用4–8 周。构建统一索引引入向量召回并同时接入两侧。验收标准搜索侧语义召回覆盖率提升推荐侧相似召回复用同一份向量索引维护成本由两套降为一套。阶段三排序协同6–10 周。共用特征与底层模型分场景设定目标权重搜索侧引入个性化重排推荐侧引入搜索意图信号。验收标准两侧核心指标搜索转化率、推荐点击率均不低于改造前基线。阶段四策略联动持续。按用户当前意图动态分配搜索结果与推荐位的流量配比明确意图时以搜索为主、推荐位收窄为同类补充弱意图时以推荐探索为主。验收标准整体转化率与人均浏览深度同步提升。五、架构落地怎么度量这一层只回答工程改造成不成立业务增量跨入口转化、人均 GMV的口径见姊妹篇《搜索推荐一体化为什么 112》两层的指标不要混在一张表上算。建议盯四组工程指标指标含义阶段验收参考跨系统 ID 映射覆盖率同一商品在搜索索引与推荐候选池中是同一个 ID 的比例阶段一 ≥ 95%召回复用率向量 / 倒排通道被两侧同时调用的比例阶段二较改造前提升索引由两套降为一套向量更新延迟新品 / 新内容从入库到可被向量召回的时间阶段二控制在分钟级两侧核心指标基线搜索转化率、推荐点击率不低于改造前阶段三逐场景回归不降为准前三项决定底座是否真的共用起来了第四项是安全线——架构改造不应以牺牲单侧指标为代价。六、架构落地的四个技术坑双写不一致商品主数据同时写搜索索引与推荐候选池任一侧失败就会出现搜索有、推荐没有的幽灵商品。应改为单一事实源 两侧订阅而不是两次独立写入。向量漂移向量模型升级后旧向量与新向量不在同一空间混检会让相似度失真。升级必须全量重建并灰度切换禁止新旧向量同库混合召回。延迟预算被吃掉向量召回叠加在关键词召回之上首字延迟会上升。多路召回要设并发与超时超时的通道直接降级为不参与而不是让整体等待。排序层被误共用把搜索的相关性模型直接拿去排推荐位相关性高但千篇一律推荐点击率反而下降。排序层必须分场景设定目标权重。这四个坑都属于工程实现范畴与姊妹篇讲的业务侧误区共用一套评估指标、一次性全量切换等不在同一层落地时两边都要过一遍。常见问题问搜索和推荐应该合并成一个系统吗答不建议完全合并。两者优化目标不同搜索必须保障查什么出什么的相关性下限推荐则需要多样性与探索空间。正确做法是底座共用索引、向量、用户事件流、特征工程策略层分离排序目标、干预规则、评估指标各自独立。问协同改造先做哪一步性价比最高答先统一用户行为事件流与实体 ID。这一步投入最小、不涉及算法改造但决定了后续所有模型的样本质量。日志没打通就做联合排序模型拿到的仍是残缺样本效果上限被数据卡住。问向量检索为什么适合作为共用通道答因为同一份向量索引天然服务两种召回搜索侧用语向量做语义召回解决词不匹配但意图匹配搜保暖外套出羽绒服推荐侧用物品向量做相似召回解决看了又看。一次构建、两处复用是协同成本最低的切入点。问搜索结果页里放推荐位会不会伤害体验答取决于是否做意图判断。用户查询词明确如具体型号、品类词时应以相关性结果为主推荐位收窄为同类补充或不展示查询词宽泛如送女友、夏天穿或零结果时推荐位才有明显增益。不做区分地混排会破坏搜索的可信度。问协同之后怎么判断带来的到底是增量还是流量搬家答看跨入口转化率。统计从搜索进入、最终在推荐位成交与从推荐位进入、最终在搜索成交的占比与绝对值。跨入口转化上升说明两个入口在互相导流总转化上升但跨入口转化不变多数只是流量在两个入口之间重新分配不是新增量。问小团队没有算法工程师能做一体化吗答可以从规则层做起。先做三件事统一行为日志、用现成的向量检索能力如开源向量库构建一路语义召回、在搜索无结果或弱结果时降级到推荐位补位。这三项都不需要自研模型但能覆盖协同收益中的大部分。
