尧图网络 高端网站定制 · 原创设计
免费咨询热线
400-888-6620
免费获取方案
从召回、排序到重排:X平台For You推荐算法全链路解析
聊算法的人很难不注意到X平台那套“For You”信息流。它是目前社交平台里少有的把推荐系统全链路公开讨论过的案例从候选生成、排序到重排都值得拆一拆。不管你是做推荐系统的新人还是已经在信息流业务里摸爬滚打多年把这条链路的每个环节弄清楚再回头看自己手头的推荐项目很多问题会豁然开朗。这篇文章我会从一个做推荐的实际视角把For You推荐算法从头到尾拆开讲。不堆公式不贴论文重点说清楚每个环节解决什么问题、为什么这么设计、线上跑的时候容易踩什么坑。想直接拿来当理解推荐系统的“骨架”也非常合适。1. 整体设计为什么For You是一个漏斗系统1.1 先想清楚一个推荐请求要处理多少内容X平台的信息流和电商、短视频一样本质是在一个巨大的内容池里给每个用户挑出几十条内容。区别在于X上的内容非常碎片化、实时性强一条推文从发布到被看到可能只在几分钟内就有价值。全站每天能产生的新内容量级我做推荐这么多年最直接的体会就是任何模型都不能在对所有候选内容逐一打分后再排序。原因是单次请求的耗时有硬上限用户不会等你把全站几亿条内容全算一遍才看到结果。即使离线预处理一部分在线可用的候选依然远远超出单次推理能承载的范围。所以For You算法采用的策略非常典型把它当成一个漏斗每一层都在“减少候选数量、增加计算精度”。漏斗式的结构不是X独创却是这类超大规模信息流系统最务实的选择。你要真拿一个深度模型对全量候选在线跑机器扛不住延迟也过不了关。1.2 漏斗的四个阶段与各自使命For You推荐的漏斗大致可以分成四段候选生成召回从内容池里快速筛出几千到上万条“可能有点意思”的内容。粗排用轻量级模型把上万条压到几百条。精排用复杂模型对几百条做精细打分按分数输出。重排与混排根据多样性、去重、负反馈、商业化等规则调整最终顺序。每个阶段的使命完全不同。召回追求“不能漏”粗排追求“快速且不掉太多”精排追求“准”重排追求“整个列表合理”。很多团队在做推荐时有个通病一上来就死磕精排模型召回随便写几个规则结果模型再强天花板也被召回卡死了。我见过不止一个项目陷入这样的局面花大力气提升了精排的离线指标线上数据却纹丝不动。后来复盘才发现真正的瓶颈是召回阶段丢掉了大量潜在正反馈样本。所以聊For You算法必须先把这个漏斗逻辑立住后面每一步才有意义。2. 候选生成怎么从全站内容里先圈出一批有潜力的2.1 多路召回每一路都是一个独立世界观For You的候选生成不是单一路径而是“多路召回”并行。每一路从一个角度回答同一个问题“用户可能对什么感兴趣”把这些路拼起来才是一个相对完整的用户兴趣图谱。日常做召回常见的一路是基于社交关系的召回。这个在X上尤其重要因为平台的核心是关注关系。你关注的人发了什么天然是强候选。但这路不能只取你直接关注的人还得往下一层扩展你关注的人中有人点赞了某条内容那条内容对你来说就可能是有价值的。还有一路是基于兴趣的向量召回。平台把用户和内容都映射成向量用户的历史行为点赞、回复、转推、观看时长构成用户向量内容本身的文本、图片、话题构成内容向量两者算相似度取Top N。这一路的目标是捕捉“你不一定关注了相关作者但你就是喜欢这类内容”的情况。比如一个用户关注的全是篮球资讯但他经常刷到科技新闻还会点赞这时候向量召回就能把科技新闻捞出来。图算法召回也是不可少的一路。用户与用户的关注关系、用户与内容的互动关系本质上是一张巨大的异构图。通过图上的传播逻辑能发现“和你兴趣相似的人正在看什么”这比单纯依靠用户自身历史行为更有时效性也更容易发现新内容。我特别想强调一点召回的各路之间逻辑应该是互补的而不是重叠的。如果三路召回出来的内容都是同一类那多路就没有意义。业内经常用“召回来源覆盖率”和“各路独立贡献比”来衡量召回体系好不好。我的经验是隔一段时间就统计一下各路的产出占比和最终转化占比会发现部分路早已名存实亡。2.2 召回路上的工程细节去重、截断、插入实时内容候选生成阶段看起来“只是查出候选”实际工程细节非常多。第一步是截断。每路召回都有数量上限不可能让一路把所有名额都占掉。常见的做法是给每路分配固定配额比如社交关系召回500条、兴趣向量召回500条、图召回300条、热门补充200条。配额分配比例需要根据业务特点调比如一个以转发扩散为主的平台图召回占比可以高一些一个以用户个体观看时长为主的平台向量召回占比可以高一些。第二步是合并去重。多路召回的结果合并后需要按内容ID去重。这里有个容易被忽略的规则去重时不能简单地“谁先到谁留下”而是要按优先级保留比如精排预估更高的路优先保留或者互动信号更强的路优先保留否则可能会出现一条实际质量不高的内容占住位置反而把高质量候选取掉了。第三步是插入实时内容。For You很强调实时性很多内容从发布到展示不应该超过几分钟。所以召回链路里通常会有一条“实时通道”专门用来把新发布的内容快速推入候选池。这个通道和常规召回不同它没有太多个性化逻辑更多是依赖作者关系、话题热度、事件突发度做初步过滤。这条通道必须足够轻、足够快一旦走常规召回路径新内容往往要等几十秒甚至几分钟才能出现在用户的候选里对资讯类平台来说这就是致命的延迟。3. 排序模型候选内容如何被精细打分3.1 特征体系模型看到的信息长什么样候选池经过召回之后剩下来的内容还有几百到上千条这时候轮到排序模型工作。排序模型的质量一半取决于模型结构一半取决于特征工程。For You这套体系里的特征大致可以分成四类。用户特征用户的历史互动统计、活跃时段、关注列表的规模、长期兴趣分布。这部分的特征是“你是谁”。内容特征内容的文本主题、话题标签、附带图片或视频的类别、作者的历史互动质量、作者被用户关注的关系。这些特征是“这条内容是什么”。上下文特征当前时间、星期几、用户所在地区、设备类型、当前网络环境。这类特征经常被新手忽略但实际上非常有用。周末和工作日用户刷内容的偏好明显不同凌晨和傍晚热门内容类型也不同网络差的时候视频内容的权重就应该降低。交叉特征用户与该内容作者的互动历史是否经常点赞该作者、用户在过去N天内是否看过同类话题等。交叉特征把“谁”和“什么”连在一起往往比单侧特征效果更明显。我在实际项目里的体会是交叉特征是最容易出效果也最容易出问题的部分。做得好的时候模型能精准识别“这位用户虽然爱看篮球但从不喜欢某个特定篮球评论员”做得不好的时候交叉特征直接变成记忆导致模型只会复制历史行为新内容一点机会都没有。3.2 模型与训练目标一次预测多个互动信号For You这类平台训练排序模型很早就从单一目标转向了多目标学习。原因是用户的“喜欢”不是一个单一动作点赞、回复、转推、点开详情、观看时长每一个动作都代表了不同程度的兴趣。多目标学习里常用Shared-Bottom结构多个任务共享底层特征表示上层各自输出自己的预估。这样做既省资源又能在一定程度上缓解某个任务样本太少的问题。更进阶的做法是加入动态权重让模型根据当前用户场景自动调整不同目标的权重。比如一个资讯敏感型用户转推目标的权重会更高一个纯娱乐型用户点赞和观看时长的权重会更高。每个目标还要解决“怎么定义正样本”的问题。拿简单了不行拿复杂了也不行。比如拿“曝光并且有互动”做正样本那没曝光的内容就永远没有机会学习模型会偏向探索少的热门内容对低互动的新内容极不友好。所以X这类平台会在样本里加入一定比例的“未互动但曝光过的内容”作为负样本甚至加入少量随机采样负样本来避免模型只学到“曝光多正样本”这种偏置。3.3 线上推理排序模型不能超过时间预算排序模型做得再准线上推理超时就是废模型。For You的单次请求要同时处理几百条候选每条内容都要出分数整个排序阶段不能耗时过多。工程上有几个被我反复验证有效的优化点第一特征预计算。能离线算好的特征绝不在线重新算。用户历史统计特征、内容的历史互动率、作者质量分这些都是可以离线算好的线上只查表。在线只计算真正依赖实时数据的特征比如“用户最近5分钟是否看过这条内容的作者”。第二模型量化与剪枝。深度模型在离线用浮点训练线上可以转成低精度推理在不太掉点的前提下把速度提上去。如果你用的模型本身规模不大剪枝的收益可能比量化更明显。第三批处理抽取。排序模型的推理往往是逐条进行但其实几百条候选里很多可以批量计算。用Batch模式一次Forward传入多条候选GPU或CPU的资源利用率会高很多。这一步做得好整体耗时能降一半以上。4. 重排与多样性为什么排序分数第一的内容不能都放前面4.1 列表级目标多样性、作者打散与已读过滤精排模型给每条候选内容打了分理论上按分数从高到低排下来就是最终结果。但真实产品不会这么做因为用户看的不是单条内容而是一个连续的信息流列表。如果完全按精排分数排序列表会被少数几个作者的内容占满。用户刚刷完A作者的推文下一条还是A作者再下一条还是A作者体验很糟糕。所以重排阶段要做作者打散约束同一个作者在相邻位置出现的次数一般控制在连续两条以内。除了作者打散还要做话题多样性。精排模型很容易把同一个话题下的内容集中排到前面比如体育类内容整体高分。用户刷十条里面八条是体育新闻就算单条都很准列表体验也不好。重排可以通过MMR最大边际相关或DPP行列式点过程这类方法在“保持高分”和“拉开内容距离”之间找平衡点。这类算法不算复杂但在多样性控制上确实有效。已读过滤也是重排的重要工作。用户看过的内容必须及时从候选里移除否则一条内容在一个会话里出现三次用户会直接怀疑平台是不是有问题。已读过滤要分两级短期会话级过滤和长期历史级过滤。短期过滤是必须的长期过滤要克制因为用户可能确实对某个内容有兴趣隔一段时间再看一遍也有价值。4.2 实时负反馈用户划过一条内容之后发生了什么For You信息流里用户并不只有“点赞”“转推”这种正反馈还有大量“划过”“不感兴趣”“屏蔽”这类负反馈。负反馈对推荐的影响比重反馈更大。用户在列表里快速划过某条内容没有做任何互动这个信号会传给重排模块让该内容在本次会话里被降权。但这里有个细节划过不一定是“不喜欢”可能是用户已经有了足够的信息或者单纯是不想点开。过度解读划过信号会让模型变得敏感反而损失正常的自然曝光。“不感兴趣”和“屏蔽作者”这类明显负反馈则要强硬处理。用户主动点击“不感兴趣”按钮说明他对这条内容的主题或形式产生了反感。这类信号要进模型训练样本同时也要在重排阶段直接过滤甚至是短期的“硬过滤”。我在自己做的系统里对负反馈的处理策略是“分级压制”屏蔽作者是最强压制基本等于永久过滤“不感兴趣”是中等压制对该话题降权一段时间“划过”是弱压制只影响当前会话内的排序。分级压制的好处是既能响应用户情绪又不会因为一条模糊信号就把内容彻底打死。5. 实验评估与数据闭环5.1 从曝光到回流的完整链路很多人以为推荐系统的工作在“排好序、给出结果”就结束了实际上真正的活是从用户看到结果之后开始的。For You算法能有持续效果靠的是数据闭环曝光、互动、回流、再训练。链路有四个关键节点曝光日志记录用户看到了什么内容、出现在第几位、停留了多久。互动日志记录点赞、回复、转推、点开详情、关注作者、屏蔽、举报等动作。负反馈日志记录划过、不感兴趣、减少此类推荐等信号。负反馈日志经常单独放因为它和正反馈需要不同的加权方式。模型回流日志经过清洗后生成训练样本更新特征、更新模型最后重新回到线上服务整个推荐系统。这个闭环看起来简单真正做起来每一步都有坑。我印象最深的一个坑是曝光日志和互动日志的时间对不上。用户在凌晨刷到一条内容觉得有意思但等到第二天早上才点赞。如果只按日志到达时间关联系统会误以为用户是“隔了很久才回应一条内容”特征和标签的关系就扭曲了。正确做法是曝光日志保留一个“展示时间戳”互动日志也带上“互动发生的时间”两者按用户维度和时间窗口关联建模才能准确反映内容对用户的影响。5.2 离线指标与在线实验的取舍推荐系统的实验离线要做在线也要做但两者的关系不是简单的“离线好就线上好”。离线评估的核心是看模型的排序能力常用AUC、GAUC这类指标但它只能说明模型在训练样本上的区分度。线上实验则复杂得多。哪怕只改了一个排序权重也要通过A/B实验观察多个指标互动率、点赞率、转推率、负反馈率、次留、长期留存。不同指标之间经常互相制约。比如把个性化权重调高互动率短期可能上升但用户看到的内容越来越窄一周后留存反而下降。这里我想说一个项目管理层面的建议不要把线上实验的目标定成单一的“互动率提升”或“时长提升”要同时锁死约束指标比如负反馈率不能上升超过多少、作者发文积极性不能下降。约束指标一旦爆掉哪怕主指标翻倍也不能上线。很多验证有效的优化其实靠的是“降低坏体验”而不是“提高好体验”。比如把负反馈率的权重加大之后互动率没有明显变化但屏蔽和“不感兴趣”次数大幅下降用户的长期留存是提升的。这种方向只看短期主指标很容易被误判为无效改动。所以做信息流推荐在线实验最好同时看短期行为指标和长期留存指标短期指标有变化长期指标往往延迟几天才能体现出来。6. 常见问题与排查技巧实录6.1 模型离线涨分、线上无效果这个问题我在好几个推荐项目里都遇到过也是新手最容易困惑的地方。离线指标提升线上却不涨通常有三个原因一是离线在线特征不一致。离线训练时用的特征是在历史日志里算好的线上推理时特征值统计窗口不同或来源不同模型看到的向量和训练时有偏差。这个要做特征一致性校验线上服务里单独记录特征快照与离线重算的特征对比找出偏差来源。二是样本选择偏差。正样本只来自曝光过的内容模型学到的是“在曝光过且被排序靠前的内容里哪些能获得互动”而不是“全站所有内容里哪些值得推荐”。如果样本里没有加随机采样的负样本模型的表达能力再强召回池里真正优秀的新内容也无法被浮出水面。三是流量分配差异。离线指标是按历史流量加权计算的而线上试验的流量偏向了特定用户小流量实验里的用户群体本身就和全站用户分布不一致。解决方法是实验分组时充分随机尽量让实验组和对照组的用户画像一致。6.2 推荐越做越窄同质化严重这是一个比较隐蔽的问题。当你把排序调得越来越“精准”时用户看到的内容会逐渐收敛到极少数的几个话题上。原因是反馈闭环强化用户只看到一类内容只和一类内容互动模型再拿这些互动当标签去学习系统就再也跳不出这个圈。缓解同质化的手段业内基本就是两条路增加探索流量和强化多样性约束。探索流量的意思是在整体流量里专门留出很小一个比例比如2%用来给用户推荐他历史行为中没有出现过的内容。这部分流量不追求互动率目标是让用户发现新兴趣。虽然短期指标会掉一点但长期看能明显扩展用户的内容视野拉长留存。多样性约束则是在重排阶段加显式限制比如列表里至少保证一定比例的内容来自不同话题、不同作者池。不要小看这个简单规则它往往比模型结构改动更直接有效。6.3 实时热点追不上的问题信息流平台如果没有实时性用户的体感会非常差。比如一场重要比赛刚结束用户打开信息流刷了很久都看不到相关讨论这就会让用户觉得平台“没有在看我关心的事”。热点追不上通常不是排序模型的锅而是实时候选通道没打通。新内容从发布到进入候选池如果走的是小时级的离线任务那热点出来至少慢半小时。解决办法是在召回阶段加一条低延迟发布通道新内容发布后立即进入候选池并且用热度信号短时间内被转发、回复的数量给它临时加权保证它有机会被排到前面。另一个容易被忽略的问题是热点事件往往在短时间内产生大量相似内容这些内容一起冲进候选池会导致列表全是同一条新闻的不同搬运版本。这时重排阶段的多样性约束反而更重要同一个话题的内容在一个列表里控制出现比例。这件事我踩过一次很深的坑只追实时性不加多样性结果用户反馈“信息流全是重复内容”还不如不追。6.4 负反馈处理不好引发连锁问题负反馈是比较容易处理过头或处理不足的信号。处理过头的情况是用户一时手滑点了“不感兴趣”系统就把整类内容都过滤掉结果用户反而发现想看的东西少了。处理不足的情况是用户已经屏蔽了某个作者系统还在用“相似作者”的向量召回相关内容换一个马甲号继续出现在信息流里。我的经验是给负反馈分两个维度处理一个是强度一个是持续时间。屏蔽作者的强度最高可以持续30天甚至永久不感兴趣的中等持续3到7天划过属于弱负反馈只影响当前会话。而且负反馈处理完之后一定要有“松绑”机制比如一段时间后自动降级或取消过滤给用户重新看到新内容的机会。否则模型会越来越保守用户的信息流会丧失新鲜感。写在最后的一点个人经验做过几套信息流推荐之后我最大的感触是推荐系统的复杂点从来不只在算法本身。For You这种量级的信息流比拼的是数据链路的完整度、特征体系的扎实程度、工程链路的稳定性最后才是模型结构。你去看很多所谓“效果奇好”的推荐方案大部分本质上是把数据这层做得比别人到位样本干净、特征一致、负反馈处理精细、实时链路通畅模型反而只是加分项。如果你现在正打算优化自己的信息流推荐我建议你先别急着换模型。花一周时间把曝光、互动、负反馈这条日志链路梳理清楚把离线特征和在线特征做一次对齐校验把召回各路各自的贡献比算出来。做完这三件事可能不用改模型结构很多问题已经自己浮出水面了。做推荐系统尤其是信息流推荐表面上是算法问题实际上是个数据工程和产品判断的综合题。把底层理顺上面的模型随便换结构都不至于出大问题。
RELATED

相关推荐

视频回放轴VideoLineForJS:监控回放时间轴组件实战指南

视频回放轴VideoLineForJS:监控回放时间轴组件实战指南

简介:VideoLineForJS 是一款针对海康威视视频回放场景的 JavaScript 时间轴组件,视频轴也称回放轴,常作为录像时间选择的交互核心,面向需要快速实现 Web 端历史视频回放界面的开发者。组件在页面中生成可点击/拖动的视频轴&#x…

📅 2026/10/18 8:47:26
视频回放轴设计与实现:时间轴组件、像素映射与播放器联动实践

视频回放轴设计与实现:时间轴组件、像素映射与播放器联动实践

简介:VideoLineForJS是一份基于JavaScript实现的视频回放轴组件,专为海康威视等安防监控平台的录像回放场景设计。它将录像片段映射为可视化的时间轴区间,支持点击或拖动定位时间节点,并通过回调输出格式化时间,方便与…

📅 2026/10/18 8:47:26
DotNET Reactor混淆实战:CI/CD集成与WPF/MAUI兼容性避坑指南

DotNET Reactor混淆实战:CI/CD集成与WPF/MAUI兼容性避坑指南

简介:本资源为DotNET Reactor最新破解版工具包,面向.NET开发者与逆向分析学习者,用于C#、VB.NET等托管代码的混淆、加密与反调试保护,解决商业软件作者对源码泄露与非法篡改的核心防护需求。压缩包共105个文件,含18个可…

📅 2026/10/18 8:47:26
MORE NEWS

更多资讯

📰

Redis 已正式接入 AI !用 MCP 把缓存层改到 TaoToken 的完整配置

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

📰

3D高斯泼溅实战指南:从COLMAP位姿到实时渲染点云资产

简介:基于3D高斯泼溅(3DGS)的完整三维重建代码包,面向计算机视觉、深度学习方向的研究者与三维重建开发者,解决从手机实拍图像到可交互3D场景的完整流程问题。包内集成预处理、数据集转换、模型训练与实时可视化模块&a…

📰

Spring AI + RAG 实战:Java 后端构建知识库问答系统的调优指南

身边不少做后端的朋友最近都在琢磨同一件事:怎么把大模型接到自己的业务系统里,而不是停留在“调 API 玩 demo”的阶段。我上个月刚好把一个企业内部知识库问答项目从零搭到了线上,核心方案就是标题里这几个关键词的组合——Spring AI、RAG&a…

📰

花1000得1600是真是假?拆解消费增值的算法与避坑判断法

这两年我数不清有多少次刷到“花1000得1600”这类文案了。充值1000到账1600,消费满1000返600积分,购物满1000送600礼金……形式五花八门,话术全绕着一个“赚”字。第一次看到这类“消费增值”活动时,我也心动过,谁跟钱…

📰

终端保密检查工具实操:翻出U盘痕迹与文件残留,实现自动化巡检

简介:终端保密检查工具.zip 是一套面向 Windows 环境的信息保密检查工具,主要服务于政企单位保密专员、IT 运维及终端安全管理员。该工具可完成敏感关键字扫描、违规文件排查、USB 外接设备使用审计等检查工作,能够帮助定位终端上的信息泄露隐…

📰

36个可调试前端源码:HTML语义化与CSS布局实战切片

简介:这是一份面向前端初学者与进阶开发者的实战型网站布局学习资源,聚焦HTML结构、CSS响应式布局及基础JavaScript交互实现,帮助开发者快速掌握单页、多栏、瀑布流、网格等主流网站形态的源码级实现逻辑。压缩包共2000个文件,主体…

TODAY

今日更新

THIS WEEK

本周精选

THIS MONTH

本月热门

读完文章,想聊聊您的网站?

告诉我们您的行业与需求,资深顾问一对一梳理方案与报价,全程免费。

📞 💬