搜推链路这四个字听起来像是两个系统的拼接实际上它就在你我每天打开App的每一次搜索、每一次下拉刷新背后。我做了几年的搜索和推荐后台经常有刚转过来的同事问我同一个问题搜索和推荐到底各自在干什么中间这一大段链路是怎么流转的这篇文章我就把这两套体系放在一起用最不绕弯的方式拆开讲讲。不管你是做产品、做后端、做数据还是刚入门算法只要你想搞明白“搜推链路”到底是什么这篇都能给你搭起一个完整骨架。1. 搜推一体的大背景与基础框架1.1 为什么“搜”和“推”现在总被放在一起聊几年前搜索团队和推荐团队往往是两个独立部门各搭各的架构各用各的数据连技术栈都不统一。后来大家逐渐发现一个尴尬的事实用户根本不区分你到底是搜索还是推荐。他今天搜了“跑步鞋”明天打开首页就希望看到运动装备的推荐他今天刷信息流看到一条美食视频周末就可能去搜索框里搜那道菜的做法。业务上的用户心智本来就是连续的技术侧却割裂成两套这本身就是一种浪费。于是“搜推一体”就成了很多公司的自然选择。搜索引擎的查询理解能力可以帮推荐系统理解用户当下的实时意图推荐系统的用户画像和向量召回能力反过来也能帮搜索做个性化排序。两个方向共享同一套特征平台、同一个向量检索库、同一套模型服务团队的维护成本能降不少。我见过最极端的案例某内容社区把搜索和推荐的后端合并成一个团队维护接口层统一暴露在线联调效率直接翻了一倍。所以现在聊搜推链路不再是两个孤立系统而是同一套基础设施上的两条业务表达。1.2 链路的骨架输入、处理、输出不管搜索还是推荐整个链路都可以压成三层来理解输入层、处理层、输出层。输入层是链路启动的触发条件。对搜索来说输入就是用户在搜索框里敲下的一串字符对推荐来说输入就是用户当前的身份、历史行为序列、以及当前所处的场景比如首页还是视频流还是详情页底部。这里有个容易忽略的点推荐系统的输入不是一个明确的“问题”而是一堆杂乱的信号系统要从这些信号里自己猜出用户想要什么这比搜索的输入更模糊也是两条链路最本质的差异。处理层是链路的发动机舱。这一层可以继续拆成召回、粗排、精排、重排这几个标准动作。召回是从海量内容里快速捞出一批候选粗排是用轻量模型把候选压缩到一个更小的集合精排用复杂模型把最终的结果排出一个精确顺序重排再基于商业规则和用户体验做一些干预。搜索和推荐在这一层的技术动作几乎一样区别只在于每一环面对的数据量级和使用的特征不同。输出层是用户能感知到的结果。搜索输出的是搜索结果页推荐输出的是信息流或者“猜你喜欢”模块。输出层还有一个容易被忽略的职责它要把结果包装成前端可用的数据结构附带曝光、埋点、追踪所需的各种辅助信息。这三层骨架说起来简单但每一条链路在每一层里面都有很多值得抠的细节。下面分别把搜索链路和推荐链路各拆开揉碎讲一遍。2. 搜索链路的核心环节拆解2.1 查询理解先把人话翻译成系统能懂的话搜索链路的第一站是对用户输入的原始query做处理。这个环节我通常叫它“查询理解”它决定了整条链路的天花板。原因很简单如果系统在一开始就误解了用户想找什么后面做再多精细的排序都是白搭。查询理解一般包含几件事。分词是最基础的中文不像英文按空格天然切分“北京烤鸭”可以被切分为“北京”加“烤鸭”也可能被切成别的组合分词错了召回结果就会跑偏。拼写纠错处理用户打错字的情况用户输入“德芙巧克力”打成“德夫巧克力”系统要先识别出来是误写自动纠正再去检索。查询改写负责同义词和近义词的转换“笔记本电脑”和“笔记本”在用户意图里可能指向同一个东西但字面完全不同。意图识别则走向更高一层用户搜“天气”和搜“天气之子”一个是想要即时天气信息一个是想找一部动画电影系统必须在语义层面做出区分才能召回正确的结果。这一环节的实操难点在于资源投入的性价比。做一个基础版本早上线比什么都重要。可以先只做分词和基础纠错改写真不需要一开始就上意图识别可以先用规则词典覆盖高频场景。我见过团队一上来就想搞全套深度学习语义模型结果光数据标注就做了三个月业务等不起最后还是先上了规则版本顶住。搜索是一个不断迭代的活查询理解的深水区可以后面慢慢趟。2.2 检索召回倒排索引到底解决了什么问题查询理解做完系统知道了用户想找什么下一步就是从海量的候选文档里快速捞出一批备选。这个动作叫召回搜索引擎召回领域最核心的数据结构是倒排索引。倒排索引这个东西理解起来其实特别简单。想象一下正排索引就是一份份文档都带着自己的标签列表比如“文档1包含词A和词B”“文档2包含词B和词C”。用户搜索“词B”的时候系统需要把全库所有文档扫一遍看哪个包含词B。这种全表扫描的方式在数据量小的时候无所谓但当一个搜索库里有几千万甚至上亿篇文档时一次查询要扫全表响应时间就是灾难级的。倒排索引的做法是反过来建表把“词”作为主键一个词对应一串包含它的文档ID列表比如“词B - [文档1, 文档2, 文档5]”。用户在搜索框里敲入“词B”系统直接用哈希或者字典树查到这个词对应的文档列表几百万个文档瞬间就定位到了。这就是倒排索引“空间换时间”的精髓在索引构建时多花一些存储空间换来查询时几乎恒定的检索速度。用生活里的话类比倒排索引就是书最后的索引页你想查某个概念在哪几页出现直接翻索引比从第一页逐页看书快得多。召回阶段还有一个常见的补充动作叫做向量召回。传统的倒排索引依赖词面的精确匹配用户搜“可以听歌的软件”文档里可能写的是“音乐播放器”字面不匹配就召不回来。向量召回把文本映射成高维向量通过计算语义相似度来匹配能覆盖这种“表达不同但意思相同”的场景。现在搜索架构里普遍是关键词召回和向量召回并行最后做一次融合取并集进入后续排序环节。2.3 相关性排序让最像用户想要的结果浮上来召回阶段通常能捞回几百到几千个候选结果但用户只会在第一屏看到十条左右。怎么把最相关的那十条推到最前面这就是排序要做的事。相关性排序里最经典也最常用的算法之一是BM25。它的核心思想不复杂一句话概括一个词在文档里出现的词频越高说明这篇文档和这个词的关系越紧密但同时如果这个词在所有文档里都特别常见那它对区分文档相关性的价值就变低了。所以BM25在计算词和文档的相关性分数时一方面看重词频另一方面又对超高频词做抑制还考虑文档长度进行归一化短文档里出现一次关键词比长文档里出现一次关键词的权重更高。这套算法到今天仍然在很多实时性要求高的场景里发挥着作用因为它快、稳定、可解释。模型排序可以在BM25这个强基线之上继续做优化比如引入点击反馈信号统计“用户搜这个词之后点击了哪些文档”把点击行为作为特征喂给排序模型。搜索排序的演进路线基本就是从词法匹配到统计相关性再到模型打分每一步都在前一步的基础上增加信号维度。实操中的建议是先做好BM25再把点击反馈加进去这两步做完普通场景的搜索相关性就已经能打了。不要一上来就上大规模排序模型数据和特征跟不上模型再高级也白搭。2.4 业务规则在排序中的影响力排序模型给出的分数不是最终展示顺序的唯一决定因素。搜索结果页是产品的一部分产品就要考虑商业目标和用户体验这就轮到业务规则层出场。最常见的业务规则干预是时效性。新闻搜索场景里一篇一周前的旧报道就算相关性打分再高也不能排在一篇10分钟前刚发布的新报道前面。地域约束也很典型用户搜“附近修手机”结果里出现另一个城市的店铺就没意义必须按地理位置强约束。去重规则同样重要同一个商品图片在不同商家店铺里各有一个详情页按相关性模型算它们都排得很靠前但让用户连续看到五个一模一样的商品图体验就很差这时候就要做去重同一商品只保留最优的一个结果。这一层还有一个敏感但必须做的环节就是商业结果和自然结果的混排。商业结果要按付费和预估点击率综合打分自然结果要保证不因为商业位的插入而明显降级。具体怎么平衡没有绝对标准只能靠AB实验调。我的经验是商业位占比和位置要设置上限比如一页最多出现几个商业位避免用户产生“全是广告”的感受。3. 推荐链路的完整路径3.1 从用户画像到候选内容推荐靠什么做判断推荐系统的输入远比搜索模糊它没有一search框让用户说清楚想要什么只能通过用户留下的各类行为数据去推断偏好。这套推断的基础是建设两张画像用户画像和内容画像。用户画像的核心构成不只是年龄、性别、地域这些静态属性更重要更有效的是用户的实时行为序列。最近一个星期点击了哪些内容、收藏了哪些商品、搜索了哪些关键词、在哪些页面上停留的时间长这些行为串起来就是用户在某个时间段内的兴趣快照。做推荐系统的人常说行为数据比人口属性数据值钱十倍。新用户刚注册没有行为数据这时候画像只能退而求其次用注册时选择兴趣标签、或者进入场景时的上下文信号来判断冷启动期给他推什么。内容画像用来刻画被推荐的物品本身。一个视频、一篇文章、一件商品都要被描述清楚“它是什么”。类目和标签是最基本的更精细的做法是给内容生成一个向量表示也就是embedding。通过向量系统可以直接计算两篇内容之间的相似度这个相似度是后续向量召回的基础。类比来说用户画像是“你想了解我”内容画像是“你想让我了解它”两者在一个空间里对齐了才能做匹配。3.2 多路召回不同策略各捞一网推荐系统的第一层处理同样叫召回但思路比搜索召回要复杂得多。推荐场景里的召回分多路进行每一路干不同的事最后把各路的候选结果合并到一起。为什么要多路召回因为单一的召回策略一定有盲区。只推和用户历史点击相似的内容用户就永远只看到同一类东西只推热门内容又会丢失个性化。多路召回就是对冲这个矛盾。常见的召回路有I2I召回Item-to-Item基于用户最近点击过的物品去召回和这些物品最相似的其他物品适合推测用户的短期兴趣迁移U2I召回User-to-Item直接计算用户向量和内容向量的相似度适合从整体上理解用户长期偏好热门召回把全站热度最高的内容捞进来作为兜底保证新用户和冷门需求不会空手而归还有基于类目偏好的召回用户历史点击主要集中在美食类就加大美食类内容的召回规模。各路召回得到的集合最终会有重叠系统在合并时做一次去重再以一定的比例混合。这个比例通常不是拍脑袋定的而是基于每日的分析和AB实验调整。我见过一个常见失误团队花大力气优化了某一路模型召回但线上混合比例里这路召回的流量占比太小优化效果完全体现不出来。调整融合比例和应用侧优化这两件事需要联动。3.3 粗排与精排两级排序漏斗多路召回之后候选集往往还有几百到上千条精排模型在这个规模上跑不现实计算开销太大。工业界的标准做法是在中间加一层粗排用轻量级模型快速把候选规模从千级压缩到百级甚至几十级然后再交给精排。粗排模型追求的是快而糙。常见的实现方式有双塔模型用户侧和内容侧分别编码成向量最后只算一个内积分数还有简单的LR模型配上少量核心特征。粗排的排序质量不需要太高因为它的任务只是筛掉明显不合适的候选把有希望进精排的保留下来。这个环节要特别注意别把好结果误杀了粗排的保守性可以设计得高一些。精排是排序链路里技术含量最高的部分。精排模型使用极其丰富的特征包括用户特征、内容特征、上下文特征还有搜索/推荐场景里各种交叉特征。模型会把所有候选内容算出一个预估分数通常是预估用户点击率、点赞率、收藏率或下单率再把这些预估指标加权合并成一个综合分。精排模型输出的顺序基本就是用户最终看到的内容顺序。需要强调的是精排阶段的模型迭代是最频繁的特征加工和训练数据质量优化都能带来直接的线上指标提升但每一项优化都必须在AB实验中验证了才能上线。3.4 重排体验、商业和内容生态的最后平衡精排把内容排好序但直接把精排结果原封不动地抛给用户往往会产生体验问题。因为精排模型站在“单点预估最优”的角度做排序缺乏全局视野。重排阶段的职责就是弥补精排的“近视”。最典型的操作是打散。内容推荐里如果精排结果的前五条全部来自同一个大品类比如全是美食视频用户刷起来就会觉得单调信息熵太低。重排策略会强制把这些同品类的结果隔开让不同类别的内容交错出现。去重也是重排在处理的事相似度过高的两条内容不能同时出现在用户视野里。还有强插逻辑运营想推某个活动、某个新品或者商业广告需要插在某些位置都要在重排阶段以规则的方式实现。重排的难处在于它是一个多方博弈的环节打散会让单条内容的预估效果下降但整体体验会好商业强插会挤压自然内容的曝光但能带来真金白银。我的建议是给重排层的每一项规则都配上可量化的观测口径比如打散后整体的曝光点击率变化、单条强插带来的收入贡献让每一条规则都有据可循不至于变成拍脑袋决策。4. 搜索链路与推荐链路的对比与共性4.1 一张表看懂两条链路的根本差异很多人分不清搜索和推荐有些产品同学甚至觉得“都是给用户看一堆东西差不多”。其实两条链路在出发点上差异明显我用一张表格理一下关键维度。维度搜索链路推荐链路触发方式用户主动发起输入query系统被动猜测场景自动触发用户意图明确具体目的性强模糊宽泛靠兴趣驱动实时性要求高用户等不及晚几秒的结果相对宽容信息流刷新有异步空间评估指标相关性、无结果率、点击数、转化曝光点击率、停留时长、多样性结果确定性强用户对结果有预期弱用户没有明确预期这张表最值得琢磨的是“意图明确度”这一行。搜索用户对结果有预期系统做得不好用户很容易感知到推荐用户没有明确预期系统推荐效果如何用户感知相对模糊大不了划走不看了。这个差异决定了我们在优化两条链路时的方法论完全不同搜索优化要紧密围绕相关性这个核心推荐优化则要围绕体验和留存做文章。4.2 两条链路共用的底层组件两条链路从流程上各有不同但落到基础组件层面复用度其实很高。现在做搜推一体的架构通常都是把共用的部分抽取成中台服务。特征平台是最典型的共用组件。搜索排序要用到query侧特征和文档侧特征推荐精排要用到用户侧特征和内容侧特征虽然特征的具体含义不一样但特征的存储、访问、实时更新机制完全一样。向量检索引擎也可以共用搜索侧用来做语义召回推荐侧用来做向量召回底层都是同一个向量数据库。模型服务端也能共用一套精排模型虽然因场景而异但模型的上线、分发、打分接口是标准化的。AB实验平台是另一个绝对要共用的基础设施。搜索和推荐每天都有大量的策略调整要上线验证如果没有一个完备的实验平台支撑两个团队各搞各的流量划分和结果评估都会成一团乱麻。5. 链路背后容易被忽视的隐形环节5.1 数据一切链路的起点很多刚接触搜推系统的同学会把注意力集中在召回和排序模型上忽略了整个链路最前端的数据环节。但事实上没有数据后面的一切都是空谈。搜索要记录用户的搜索行为日志推荐要记录用户的曝光、点击、停留时长这些数据经过清洗加工之后一部分实时进入链路成为特征一部分进入离线训练集成为模型的养料。埋点的规范程度决定了数据的可用性。我踩过最痛的坑是某产品上线了推荐功能但事件埋点的字段在不同版本之间发生过命名变更导致训练特征和线上特征出现了不一致模型离线评估指标虚高一上线就崩。从那以后我把数据一致性校验作为每个项目的必选项线上实时特征和离线训练特征的分布要定期比对差异超过阈值立刻排查。5.2 评测与AB实验每次策略升级的安全带搜推链路里的任何策略改动都伴随着风险所以评测体系的建设必须和业务功能同步。评测分两层离线评测用历史数据验证模型效果主要看模型的准确率、召回率、排序指标NGSK等在线评测通过AB实验把新旧策略分别分给不同用户流量比较真实业务指标。离线评测和在线结果不一致是家常便饭。原因在于离线评测用的是历史数据环境是静态的而线上环境是动态的模型上线之后会改变用户的后续行为导致后续数据分布跟着变。所以在搜推项目里我始终记得一条判断标准离线指标是参考在线AB实验才是最终裁决。5.3 监控告警链路是否健康不能靠感觉链路故障的排查效率取决于监控体系的完备程度。搜推链路需要盯的指标有几个核心方向一是性能指标比如接口的耗时百分位数这个直接关系到用户体感二是业务健康度比如搜索的无结果率、推荐的无曝光率三是策略执行度比如各策略的流量分配是否正常。有个经典的排查案例某天搜索无结果率突然上涨第一反应去查分词词典发现最近一次词典更新引入了一个错误配置把部分高频词的切分路径全部打乱了召回环节直接导致大量搜索没有任何结果。如果没有无结果率的监控这个问题可能要到用户大量投诉之后才被发现。搜推系统不是“实现完功能就结束”的工程长期稳定运行完全依赖监控的基础建设。6. 常见问题与排查思路实录6.1 搜索无结果按什么顺序排查搜出空结果页是搜索场景最大的体验事故排查的时候我习惯按链路的顺序推进。第一步看查询理解环节把用户输入的query在后台日志里捞出来确认分词结果是否符合预期如果分词切错了什么结果都没有很正常。第二步看召回环节确认倒排索引里到底有没有包含关键词的文档排除索引未更新或者数据源为空的问题。第三步看过滤条件检查排序之后有没有强过滤的规则把结果全滤掉了比如地域限制或类目限制设得太严格。第四步才看排序排除重排层把结果打没的情况。按照这个顺序走大多数无结果问题都能在三十分钟内定位。6.2 推荐总是推同一类问题出在哪推荐多样性不足用户会明显觉得乏味。排查首先看召回路是否给得够宽多路召回里如果没有触达新领域的通路排序做得再好也是在旧世界里打转。其次看重排层确认打散规则是否真正生效打散阈值是不是查得太严。最后回到精排模型的训练数据如果模型训练数据里热门内容占比太高预估分数的分布就会高度集中导致热门内容永远霸榜。解法一般是给训练数据做降采样同时引入探索机制让一部分流量专门尝试非热门候选。6.3 链路变慢怎么找到瓶颈搜推链路变慢最常见的原因不是算法模型本身而是在线服务链路里的某个环节出了问题。定位瓶颈需要逐层采集耗时分布从接入层开始记录到查询理解、召回、排序、重排每一跳的耗时都打点统计。拿搜索来说通常最耗时的是召回的IO压力和精排的计算量。召回环节如果向量检索库和倒排索引库分两次访问可以尝试并行发起请求精排模型如果模型体量太大可以做量化压缩或者把粗排和精排的阈值调得更狠让进入精排的候选数量更少。6.4 新用户冷启动到底靠什么顶住冷启动问题做搜推都会遇到新用户没有历史行为画像空荡荡。我常用的应对手段从三个层面展开召回层保证热门内容的一定占比让新用户不至于刷不出东西重排层可以按用户的注册来源或当下场景做一些类目偏好的猜测比如从某个运动社区导入的新用户初始权重就可以往运动品类倾斜模型层给这类用户的行为特征填充兜底值避免因为缺特征导致打分异常。结尾做搜推系统这几年我越来越觉得链路的复杂度和工程上的“简单”并不矛盾。很多团队容易把精力花在模型迭代上但真正决定系统稳定下限的往往是最基础的数据是否干净、打点是否规范、监控是否完整、链路各环节的职责是否清晰。搜推这条链路从一次用户输入到最终的内容展示中间要流过数据、特征、召回、排序、策略干预这么多关卡任何一道关卡出了问题最终都会由用户来买单。所以我个人在实际操作中的体会是先把一条端到端的简单链路跑通再谈局部的深度优化把每一步的日志、指标、监控线都对齐了往后再加复杂度才不会把自己绕晕。希望这篇解析能帮你把搜推链路这个大框架装进脑子里至少下次系统出错时你能知道该往链路的哪一段去追。