摘要：搜推一体架构的关键不是合并两个系统，而是把数据层、召回层共用到底座上，只在排序与策略层分场景分离；落地顺序为统一事件流 → 共用向量召回 → 分场景排序 → 策略联动。
搜索与推荐各建一套索引、各记一份日志，是大多数企业的现状：搜索由技术团队按查询相关性维护，推荐由算法团队按用户偏好维护。结果是同一个用户在同一站点上的行为被切成两半——搜过"连衣裙"的用户，推荐位仍在推他三年前买过的品类；推荐位点击率高的商品，搜索结果里却排在第五页。
本篇边界：本文是架构与实施篇，只回答"两套系统怎么在技术上融合"——四层架构职责、四阶段落地与工程侧度量。搜索与推荐为什么要协同、业务价值怎么算、组织怎么配，见姊妹篇《搜索推荐一体化：为什么 1+1>2？》，两篇合起来才是完整答案。
关键要点
- 融合的第一原则是底座共用、策略分离：数据、召回共用，排序目标与干预规则分开。
- 融合的第一件事不是改算法，而是把两套系统的用户行为日志合并为一份事件流，并统一实体 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）的口径见姊妹篇《搜索推荐一体化：为什么 1+1>2？》，两层的指标不要混在一张表上算。
建议盯四组工程指标：
| 指标 | 含义 | 阶段验收参考 |
|---|---|---|
| 跨系统 ID 映射覆盖率 | 同一商品在搜索索引与推荐候选池中是同一个 ID 的比例 | 阶段一 ≥ 95% |
| 召回复用率 | 向量 / 倒排通道被两侧同时调用的比例 | 阶段二较改造前提升，索引由两套降为一套 |
| 向量更新延迟 | 新品 / 新内容从入库到可被向量召回的时间 | 阶段二控制在分钟级 |
| 两侧核心指标基线 | 搜索转化率、推荐点击率不低于改造前 | 阶段三逐场景回归，不降为准 |
前三项决定"底座是否真的共用起来了"，第四项是安全线——架构改造不应以牺牲单侧指标为代价。
六、架构落地的四个技术坑
- 双写不一致：商品主数据同时写搜索索引与推荐候选池，任一侧失败就会出现"搜索有、推荐没有"的幽灵商品。应改为单一事实源 + 两侧订阅，而不是两次独立写入。
- 向量漂移：向量模型升级后，旧向量与新向量不在同一空间，混检会让相似度失真。升级必须全量重建并灰度切换，禁止新旧向量同库混合召回。
- 延迟预算被吃掉：向量召回叠加在关键词召回之上，首字延迟会上升。多路召回要设并发与超时，超时的通道直接降级为不参与，而不是让整体等待。
- 排序层被误共用：把搜索的相关性模型直接拿去排推荐位，相关性高但千篇一律，推荐点击率反而下降。排序层必须分场景设定目标权重。
这四个坑都属于工程实现范畴，与姊妹篇讲的"业务侧误区"（共用一套评估指标、一次性全量切换等）不在同一层，落地时两边都要过一遍。
常见问题
问：搜索和推荐应该合并成一个系统吗？
答：不建议完全合并。两者优化目标不同：搜索必须保障"查什么出什么"的相关性下限，推荐则需要多样性与探索空间。正确做法是底座共用（索引、向量、用户事件流、特征工程），策略层分离（排序目标、干预规则、评估指标各自独立）。
问：协同改造先做哪一步性价比最高？
答：先统一用户行为事件流与实体 ID。这一步投入最小、不涉及算法改造，但决定了后续所有模型的样本质量。日志没打通就做联合排序，模型拿到的仍是残缺样本，效果上限被数据卡住。
问：向量检索为什么适合作为共用通道？
答：因为同一份向量索引天然服务两种召回：搜索侧用语向量做语义召回，解决"词不匹配但意图匹配"（搜保暖外套出羽绒服）；推荐侧用物品向量做相似召回，解决"看了又看"。一次构建、两处复用，是协同成本最低的切入点。
问：搜索结果页里放推荐位会不会伤害体验？
答：取决于是否做意图判断。用户查询词明确（如具体型号、品类词）时应以相关性结果为主，推荐位收窄为同类补充或不展示；查询词宽泛（如"送女友"、"夏天穿"）或零结果时，推荐位才有明显增益。不做区分地混排会破坏搜索的可信度。
问：协同之后怎么判断带来的到底是增量还是流量搬家？
答：看跨入口转化率。统计"从搜索进入、最终在推荐位成交"与"从推荐位进入、最终在搜索成交"的占比与绝对值。跨入口转化上升说明两个入口在互相导流；总转化上升但跨入口转化不变，多数只是流量在两个入口之间重新分配，不是新增量。
问：小团队没有算法工程师，能做一体化吗？
答：可以从规则层做起。先做三件事：统一行为日志、用现成的向量检索能力（如开源向量库）构建一路语义召回、在搜索无结果或弱结果时降级到推荐位补位。这三项都不需要自研模型，但能覆盖协同收益中的大部分。
数据来源
- Netflix TechBlog《System Architectures for Personalization and Recommendation》：推荐系统的计算划分为离线、近线、在线三层，在线响应实时但受复杂度限制、离线能力强但易陈旧，关键难点在于如何把三种模式无缝结合管理。
- Elasticsearch 官方指南《Search your data》：检索流程由构造查询、召回候选与打分排序构成，是搜索侧召回与排序分离的权威说明。
- Elasticsearch《What is vector search?》：向量检索把文本、图像等非结构化数据映射为稠密向量并按相似度召回，用于语义匹配与相似物品检索。
- FAISS（Meta AI Research）官方仓库：提供大规模稠密向量的聚类与近似最近邻检索算法库，是向量召回通道的常见工程底座。
