实时推荐系统实战：端到端延迟分段与工程化落地

做推荐系统的人大概都经历过这种尴尬老板问“实时推荐做得怎么样了”你说“已经上线了”结果拉了一下监控从用户点击到模型真正反应过来中间隔了一个多小时。这一个多小时不是某一个环节慢而是数据、特征、训练、发布、推理五段链路各自慢了几分钟叠在一起就成了“伪实时”。TencentRec这个开源推荐框架之所以值得花时间拆解正是因为它把“实时推荐”从一句口号变成了可落地的工程结构召回、排序、样本、训练各司其职每条链路都有自己的时效性目标。这篇文章不打算复述论文里的公式而是想聊聊作为一个推荐系统从业者我从这个项目中看到的真正有价值的东西——哪些设计可以直接借鉴哪些坑它提前帮我们踩过了。1. 让推荐系统“实时起来”之前先想清楚延迟都丢在哪了1.1 离线、近线与在线推荐系统里被混淆的三个“实时”很多团队说自己做的是实时推荐但细问一下其实是每天凌晨跑一次全量更新或者每小时触发一次增量训练。这不能说错但严格来说只能算“离线更新”或“近线更新”。真正的实时推荐指的是从用户产生行为、行为被系统感知、特征被更新、模型参数被调整、到下一条推荐结果返回用户整个过程被压缩到一个可接受的短时间窗口内。TencentRec的项目设计里一个很有意思的地方是把系统明确拆成了三层来处理时间敏感度不同的问题。离线层负责处理海量历史数据做全量预计算比如物品的向量表示、用户的长周期兴趣画像这类结果对时效要求低可以用批处理框架慢慢跑近线层处理分钟级到小时级的数据比如用户最近半小时的点击序列汇总、物品热度衰减、图结构的增量更新在线层处理秒级请求比如当前请求上下文、实时特征拼接、模型推理打分。这个三层拆分本身并不是什么新鲜概念但真正执行到位的项目很少。大多数系统的问题是离线层和在线层之间缺少一个明确的“近线缓冲带”导致所有时效性需求都被压到在线服务里硬扛。结果就是在线服务越来越重延迟越来越高最终只能通过缓存妥协而缓存一过期推荐结果又明显变差。1.2 端到端延迟是算出来的不是感觉出来的我见过不少团队优化实时推荐上来就盯着推理接口的P99延迟把服务端QPS压得很高但用户侧体验并没有变好。原因很简单用户感受到的实时性从来不是单次推理有多快而是“我刚刚点击的那个商品什么时候开始影响我后续看到的内容”。这个端到端延迟由四段组成数据接入延迟、特征生产延迟、模型训练与发布延迟、召回索引更新延迟。假设每段都优化到“看起来还可以”的程度数据接入3秒、特征窗口1分钟、增量训练5分钟、索引重建10分钟叠加起来就是16分钟。用户在前一分钟点击了某件商品十六分钟后系统才反应过来本质上已经属于“历史兴趣”了。TencentRec相关的公开设计里很重要的一条思路是把每段延迟分别设定独立的SLO而不是笼统地说“实时”。数据接入要做到秒级可见特征计算做到分钟级可用模型增量更新做到近实时发布召回索引更新要跟模型版本对齐。每段都有独立的监控指标哪一段超时立刻能定位。这个“延迟分段的思路”是我认为比任何模型结构都值得先抄下来的东西。链路阶段推荐时效目标常用技术手段主要监控指标数据接入秒级消息队列、流式消费数据可见延迟、丢失率特征生产分钟级实时特征聚合、特征存储特征新鲜度、覆盖率模型训练近实时增量训练、在线学习训练到发布耗时索引更新与模型对齐向量索引重建、热加载索引版本与模型版本偏差2. TencentRec的架构主线四条链路各司其职2.1 从用户行为到模型更新一次点击经历的四个阶段阅读TencentRec相关材料时我印象最深的是它把整个推荐链路抽象成了四条并行管道样本管道、特征管道、模型管道、服务管道。这四条管道各有自己的生命周期又通过版本号和数据血缘关系耦合在一起。样本管道的职责是把用户行为日志清洗成训练样本包括正样本、负样本采样、特征拼接、标签对齐。这步看起来简单但实际工程里最容易出问题。比如用户点击了一个商品但商品已经被下架特征表里查不到再比如用户行为发生的时间和样本落库的时间差了十几分钟导致样本里拼接的“当前特征”其实已经过期。TencentRec式的设计会强调样本必须携带事件发生时间的快照而不是落库时间否则后面所有实时模型都在学习一套错误的时间关系。特征管道负责把原始行为聚合成特征。这里要区分静态特征和实时特征。静态特征可以每天全量更新变化很慢实时特征要求随着用户行为滚动变化比如“用户最近5分钟点击的品牌列表”“用户最近一次搜索后经过的时间”。特征管道通常用流式计算引擎做窗口聚合把结果写入特征存储在线推理和离线训练都从同一份特征存储读取。模型管道负责训练、评估、发布。全量模型可能每天或每周重训一次增量模型每隔几分钟到几十分钟用新样本做一次微更新。发布时要保证新旧版本平滑切换不能出现线上模型还在用旧特征、新特征已经落库导致的错位。服务管道负责接收请求、召回候选、排序打分、返回结果。它依赖特征管道提供实时特征依赖模型管道提供最新模型依赖召回索引提供最新候选集。四条管道中任何一条延迟都会直接反映到端到端实时性上。2.2 从请求视角看一遍实时推荐系统如何处理当下这一次曝光用一次真实请求来串一遍会更清楚。用户点开App服务端收到请求后先拿到用户ID、上下文信息然后从特征存储里取出用户实时特征——这部分是从最近几分钟的行为里算出来的。接着做召回从向量索引里找与用户兴趣最接近的几百个物品。召回后进入排序模型排序模型同时接收用户特征、物品特征、上下文特征打出分数经过业务规则重排后返回给前端。这里最微妙的地方在于如果用户刚刚点击了一个商品那么这次请求能否被“立刻感知”答案是依赖两条路径。一条是实时特征路径用户的点击行为在几秒内进入特征管道聚合成“最近点击序列”特征供下一次请求直接使用另一条是模型路径点击行为作为训练样本进入增量训练让模型参数发生变化。特征路径快基本是秒级到分钟级模型路径慢再快也需要几分钟。所以短期兴趣靠实时特征去捕捉长期偏好靠模型去拟合两者不能互相替代。这个阶段如果设计不当会出现一个经典问题实时特征已经很强了用户刚点的商品立刻被推荐了相关内容但模型本身并没有更新导致推荐结果只在“特征层面”表现实时在“模型层面”依然落后。短期看问题不大长期看模型的泛化能力会跟不上兴趣演化速度。2.3 批量、微批量与流式数据处理节奏决定了系统的时间粒度TencentRec架构里另一个值得注意的细节是它没有把所有数据都做成纯流式而是按数据特征选择了不同的处理节奏。纯流式适合高价值、低延迟要求高的信号比如用户实时点击序列微批量适合需要窗口聚合的信号比如最近十分钟的行为统计批量适合全量重算的信号比如物品全量向量。我见过不少团队一提到实时推荐就要求所有链路都走流式这是很大的误解。流式处理会带来额外的复杂度包括状态管理、乱序处理、精确一次语义等问题。如果某个特征本身一小时变化不到几个百分点完全没必要做成流式。合理的做法是给特征打上“时效等级”标签等级高的走流式等级低的走离线批处理两种路径的结果在特征存储里汇合。这里有一个实践技巧无论走哪条路径每条特征都要记录它对应的“数据版本”或“事件时间窗口”。这样在线推理时能知道这条特征的时效离线训练时能对齐同一时间点的特征快照避免用未来的特征去预测过去的行为。3. 召回层的两个关键解法双塔向量召回与图神经网络3.1 双塔模型把召回变成“向量检索”是性价比最高的实时化TencentRec相关的实现里双塔模型是最基础也最实用的召回结构。它把用户特征和物品特征分别编码成向量线上用近邻检索代替全量打分。这个设计的妙处在于用户塔和物品塔可以被分开更新。物品侧的向量可以由离线批量计算用户侧的向量可以在在线请求时实时推理或者反过来用户向量保持相对稳定物品向量频繁更新。这种解耦在工程上带来非常大的便利。想象一个拥有千万级物品的推荐系统全量打分在在线环节是不可能完成的但向量检索可以在毫秒级返回相似项。双塔模型把“召回”问题转成了“近邻搜索”问题系统复杂度一下子降了一个量级。不过双塔也有明显的天花板。它把用户和物品各自压成一个固定维度的向量交互信息被压缩得很严重。比如用户在某个特定场景下只喜欢特定品类的物品这种条件关系很难在双塔的点积里充分表达。所以双塔适合做初筛不适合做精细排序更不适合直接替代排序模型。在实际复用这段设计时我建议把双塔召回定位成“候选集的过滤网”而不是“唯一答案”。它的目标是保证实时性、覆盖率和基础相关性把Top几百的候选交给排序模型去做精细打分。这样双塔的模型容量不足反而成了一个优点——计算足够快可以频繁更新保证召回侧始终能反映最新行为。3.2 图神经网络召回利用行为关系图解决长尾与冷启动如果说双塔模型是在做“基于内容表达的语义匹配”那么图神经网络召回就是在做“基于关系的结构扩展”。TencentRec相关方案里一个显著的技术选型是引入图神经网络来处理物品与物品、用户与物品之间的复杂交互关系。图神经网络的直觉很好理解物品不是孤立存在的用户行为序列天然构成了一张图。A用户点击了物品X又点击了物品Y那么X和Y之间就有了关联很多用户都在相似序列中同时点击了X和Y这种关系就会被强化。传统协同过滤能捕捉的是一阶或二阶共现而图神经网络通过多层邻居聚合可以传播更远的关系信号。图神经网络召回对冷启动和长尾物品尤其有价值。新物品刚上线时没有太多用户行为但如果它能通过图结构连接到一批已经有行为的“邻居物品”模型就能借助邻居信息生成一个还不错的初始向量。这个邻居聚合的过程相当于把“相似物品的向量”作为先验信息注入到新物品的表示里。落地的时候要注意一个工程陷阱图神经网络的训练和在线推理是两套逻辑。离线训练时可以对整张图做聚合但在线推理时一个请求只知道目标节点和它的局部邻居没法做全域聚合。因此通常做法是在离线阶段为每个物品预计算出最终向量在线阶段直接查表或者只对“当前请求涉及到的少量节点”做局部推理。3.3 召回索引的新鲜度向量再新索引不更新也白搭召回侧最容易出现“模型实时、索引不实时”的问题。模型增量训练结束物品向量已经更新但如果向量索引还在用旧版本的向量做检索线上看到的召回结果依然是旧的。这个问题在TencentRec的公开讨论里被反复强调向量模型的更新频率必须和索引重建频率对齐。这里有一个很实用的经验不要每次训练完都把全量索引重建一遍成本太高。更好的做法是维护一个“增量向量队列”训练产出的新向量先写入队列索引系统定期批量合并增量向量同时保留全量重建的兜底机制防止增量合并累积太多误差。索引新鲜度还涉及版本一致性。线上推荐服务同时存在多个模型版本、多个特征版本、多个索引版本排查问题时如果不知道当前请求到底用了哪个版本的组合会非常痛苦。建议在请求日志里记录版本号线上出问题时能精确回放“当时那个请求用的是哪一套组合”。4. 排序层的实时特征与一致性别让模型“看到的”和用户“经历的”脱节4.1 排序模型想吃到“热乎”的特征特征平台才是主角实时推荐最终的体验出口在排序层。用户看到的Top item列表是排序模型打分后的结果所以排序模型能否感知到用户的新行为直接决定了推荐结果的实时感。但排序模型本身不产特征它依赖的是特征平台能不能在请求发生前把最新特征准备好。一个成熟的实时特征平台至少包含三部分。第一部分是实时聚合计算把行为流按时间窗口聚合成特征第二部分是特征存储要求读写延迟足够低能支撑在线请求的高并发读取第三部分是特征血缘管理记录每条特征从哪个数据源来、经过哪些计算、当前是什么版本。前两部分很多团队都有第三部分经常被忽略但恰恰是排查问题时最关键的。实时特征还有一个隐藏问题特征延迟造成的偏差。A特征已经实时到秒级了B特征还是小时级更新的排序模型把A和B拼接在一起模型会误以为B特征也代表当前状态。这种偏差在离线训练时往往看不出来因为离线用的是同一份特征表线上却会因为特征新鲜度不一致导致模型在训练和推理时看到的数据分布不同。4.2 训练与推理的特征一致性特征穿越是怎么发生的说到训练和推理的一致性必须先解释一个概念特征穿越。假设离线训练样本里记录了用户点击时刻的特征但特征向量实际是从点击之后才计算出来的那么模型就“偷看”了未来信息离线评估指标会虚高。上线后线上推理没有未来信息可用效果立刻回落到正常水平这就是离线在线不一致的典型表现。避免特征穿越的核心手段是打时间戳。每条样本必须记录事件时间而不是处理时间每条特征必须记录特征时间拼接时只能使用事件时间之前已经存在的特征。TencentRec相关的工程实践里对这一点非常强调因为实时系统里数据乱序、迟到、重复是常态稍不注意就会把未来信息混进去。这里给一个可操作的建议在样本生成时不仅保存特征值还要保存特征的时间标记。训练前的数据校验环节增加一个检查规则——“特征时间必须早于事件时间”一旦发现违反规则的样本就单独拎出来告警而不是默默丢弃。这个检查在刚开始可能每天都会触发但随着系统理顺触发量会越来越少这也是系统健康度提升的一种直观体现。4.3 把上下文特征按时间窗口组织提升排序实时性的低成本手段排序模型的实时性不一定非要靠频繁更新模型来实现更好的做法是把时间窗口组织成特征。比如“距离用户上一次点击经过的秒数”“用户最近3分钟的点击品类分布”“当前时间是否在用户活跃时段”。这些特征更新得足够快模型只要学一次就能持续受益。TencentRec式的特征组织方式值得参考把连续型时间特征经过离散化或归一化后直接进模型把序列型特征通过序列编码层压缩成向量。上下文特征虽然简单但对实时推荐的影响非常直接。同样是“推荐相似物品”的策略用户在刚点完一件商品后的十秒内看到相关推荐和十分钟后才看到体验上是天壤之别。另外上下文特征还能帮助模型处理“会话内兴趣转移”。用户可能上一秒在浏览电子产品下一秒切到服饰类目如果模型只依赖长期兴趣会给出与当前会话完全无关的推荐。实时上下文特征能让模型感知到这个切换这是纯离线模型很难做到的。5. 模型更新增量训练与在线学习怎么跟上用户兴趣漂移5.1 全量重训、增量训练、在线学习三种节奏怎么选模型更新的节奏直接决定了推荐系统对兴趣漂移的响应速度。全量重训最稳定覆盖所有历史数据但计算量大通常以天为单位增量训练用新样本在前一版模型基础上做有限步更新成本低可以做到小时级或分钟级在线学习更进一步用实时样本流不断更新模型参数但稳定性风险最高。TencentRec相关方案里比较克制的一点是它并不是盲目追求在线学习而是把三种更新方式按需组合。底层大模型按天做全量重训保证基础能力不退化增量模型每隔一段时间吸收一批新样本快速贴近近期兴趣少量的在线学习只作用于模型顶层或部分参数捕捉分钟级的兴趣变化。这个组合的合理性在于不同层级的参数对时间敏感度完全不同。底层的特征Embedding变化很慢没必要频繁更新顶层的排序权重对近期行为更敏感适合做快速增量。把高频更新限制在少数参数上能显著降低不稳定风险。5.2 在线学习的稳定性别让一个坏样本把模型带偏提到在线学习很多人第一反应是“实时性好”但真正实施时最大的问题往往是稳定性。一条异常日志、一个错误标注的样本都可能在在线更新时把模型参数推向错误方向。全量训练中这类噪声会被大量正常样本稀释在线学习的每个样本权重都更高危害会被放大。工程上常用的缓解手段有几个。第一种是缩小学习率让每次更新的步长变小即使遇到异常样本也不会产生剧烈震荡第二种是设置梯度裁剪限制单次更新的最大梯度范数第三种是维护一个“样本回放池”把最近一段时间的正常样本混入在线更新抑制单一样本的过拟合。还有两个容易被忽略的细节。一是样本延迟处理一条行为在事件发生后迟迟才进入训练管道可能已经和当前状态不匹配了需要设置最大可接受延迟阈值二是样本去重同一个行为被重复计入训练样本会导致样本加权失衡。这两点不处理好在线学习的收益会被噪声完全抵消。6. 抛开论文看落地TencentRec里真正值得抄的设计6.1 值得复用的设计清单从数据血缘到灰度回滚从TencentRec相关公开资料里我整理了一份可以直接对照落地的设计清单核心不在于模型多高级而在于工程底座是否抗造。第一数据血缘是排查问题的生命线。每个特征、每个样本、每个模型版本都要能追溯到来源。实时推荐系统链条长任何一个环节出错都要能快速定位血缘管理做的好的系统排查问题的时间能缩短一个数量级。第二所有环节都要有版本对齐机制。请求日志记录特征版本、模型版本、索引版本出问题时能精确复现“那个请求看到的组合”。这个设计初期觉得麻烦后期排查问题时会发现它是救命稻草。第三灰度发布和快速回滚是标配。实时推荐系统的更新频率高灰度手段不能只覆盖服务代码还要覆盖模型和特征。线上流量按比例切到新模型观察到指标回退就立即回滚这些流程越顺畅团队才越敢高频迭代。6.2 中小团队的最小落地路径先实时化哪条链路收益最大很多中小团队看到实时推荐系统这么复杂可能会觉得无从下手。我的建议是不要一开始就追求全链路实时而是先想清楚当前系统里“哪个滞后对体验伤害最大”。如果用户行为到特征更新的链路太慢那就先实时化特征管道把“用户近几分钟行为”变成可用特征这一步改造量相对小收益却立竿见影如果召回索引更新太慢导致新物品迟迟无法被推荐那就先优化索引增量更新让召回池保持新鲜如果排序模型一个月才更新一次那再考虑增量训练。我曾在模拟项目X里实践过这个思路一开始只做了实时特征管道推荐相关性就明显提升后来又加了增量训练整体指标又涨了一截最后才逐步补齐图神经网络召回和在线学习每一步都有明确的收益反馈而不是一次性推倒重来。6.3 个人实践中的一点体会拆完TencentRec这套设计我最深的感受是实时推荐的难点不在于某个单点技术有多难而在于把“实时性”当成一个贯穿全链路的系统指标去设计。模型结构可以照搬特征公式可以借鉴但真正决定实时推荐能不能落地的是数据节奏、版本管理、一致性校验这些“笨功夫”。如果只能从这篇文章带走一个概念我希望是“端到端延迟分段”这个思想。不要笼统地说“我们要做实时推荐”而是把这句话拆成数据接入秒级、特征生产分钟级、模型更新近实时、索引与模型对齐四个具体目标。每一条都设成可监控的SLO逐一击破实时推荐才会从一个口号变成一个真正能不断提升用户体验的工程系统。