推荐系统冷启动隐式反馈去噪：从信号过滤到置信度加权实践

推荐系统里最隐蔽的坑冷启动期的隐式反馈一半是噪声做推荐系统的朋友应该都有这种感觉老用户的行为数据很“厚”怎么折腾都行可一遇到新用户、新商品整个模型就像是掉进了一个装满伪信号的泥潭。点击率看着不低转化却惨不忍睹收藏不少复购基本为零。这时候最让人头疼的往往不是模型结构不够强而是冷启动推荐阶段吃进去的隐式反馈本身就有大量噪声。我去年接手了一个面向新用户和新品类的推荐项目核心指标一直上不去。最后把问题定位到数据层面才发现我们在冷启动阶段用来训练的隐式反馈有相当一部分是误触、无意义滑动、甚至爬虫产生的垃圾信号。模型学得越努力推荐结果反而越跑偏。这篇文章就把我在这段时间里用到的去噪思路完整讲一遍包括信号过滤、行为置信度加权和一个用于冷启动场景的伪标签迭代流程。适合正在做推荐系统冷启动、或者刚接触隐式反馈建模想搞清楚“为什么数据这么脏、怎么洗才有效”的朋友。1. 冷启动和隐式反馈碰在一起为什么噪声特别多先明确一下语境冷启动推荐一般分三种用户冷启动新注册用户、物品冷启动新上架商品、新发布内容和系统冷启动新平台没数据。无论哪种共同特点是历史交互极少模型只能在很稀疏的数据上做推断。而隐式反馈指用户没有主动给出评价但系统能观测到的行为信号比如点击、滑动、停留、播放时长、页面切换。这类信号量大、收集成本低但代价是行为本身有歧义。冷启动阶段的歧义会被无限放大。举个例子一个新用户在首页看到一个封面图很亮眼的商品顺手点了进去但发现根本不是自己要的东西立刻返回。这个点击行为在传统隐式反馈模型里会记为正样本。如果这个商品恰好也是新品两者都没有太多历史曝光一个错误正样本可能直接让模型对“该商品→该用户”的关联建立起虚假的置信度。一两个这样的样本无所谓问题是冷启动场景里这样的样本是批量产生的。1.1 用户侧噪声犯错成本极低行为连续性差新用户没有形成稳定的浏览习惯。他们在界面上停留时间短、点头绪乱、频繁返回清单页再重新进入。这种状态下产生的点击很多是“试探性点击”或“局部误触”并不是真实兴趣表达。更麻烦的是新用户的反馈稀疏到无法用历史行为做交叉验证比如老用户可能收藏了A类商品但没有收藏B类出现这种“来源不明的点击”还能用偏好一致性去降权新用户做不到。1.2 物品侧噪声新品曝光分布极端样本高度同质化新品在冷启动期往往集中在少数推荐位上曝光集中在同一批用户。这批用户的点击行为高度同质化一旦某个展位本身处于页面边缘或加载异常就会产生大量无差别点击。这些点击从单条看和正常点击完全一样从聚合统计看却呈现出“爆款”假象。做去噪时物品侧最优先处理的是这类位置偏差与曝光虚高导致的系统性噪声。1.3 平台侧噪声自动化行为和接口异常这可能是最容易被忽视的一块。冷启动阶段为了快速收集数据很多平台会把新品推进信息流、瀑布流、甚至外部投放渠道。这种场景下自动化脚本和爬虫的流量占比明显高于正常搜索场景。它们的行为特征是请求间隔均匀、浏览链路单一、停留时长极短但点击量巨大。如果不提前过滤这些“虚拟用户”的交互数据会直接参与新品的CTR和转化率预估造成指标虚高。我把这三类噪声的特征和影响整理成了一个表方便对照排查噪声来源典型行为特征对冷启动推荐的影响优先处理策略用户侧高频返回、短停留、无连续浏览深度正样本错误关联兴趣建模偏离行为序列置信度过滤物品侧集中曝光位点击、同质化交互新品CTR虚高误判为潜在爆款聚类聚合特征修正平台侧请求间隔均匀、无真实页面浏览轨迹污染训练分布评估指标失真服务端日志交叉验证2. 先分类什么样的隐式反馈算干净信号什么样的必须排除去噪不是简单地对所有低置信度样本一刀切。核心原则是保留“具有行为完整性的信号”排除“孤立且无连续行为的点击”。一条干净的隐式反馈至少应当能回答三个问题用户看到了什么、用户在页面上做了什么、用户下一步去了哪里。围绕这三点我在项目中设计了三个层面的置信度判断。2.1 行为完整性判断一段能自洽的“浏览链”看一条行为日志时我会关注它是否属于一个完整浏览链用户在列表页/推荐流看到商品卡片并触发曝光事件点击后进入详情页页面停留达到预设阈值用户在详情页发生了至少一次有效交互滑动、图片切换、参数查看只有同时满足这三步这条点击才具备“行为自洽性”。我见过不少只记录“点击进入详情页”的埋点方案这远远不够。比如用户点进详情页后1秒内直接返回这类点击大概率是误触或点错了。2.2 内容相关性判断行为背后有没有“意图锚点”行为完整性只是第一步还需要判断点击是否和用户兴趣存在一致性。方法很朴素将点击商品与用户近期的正向反馈商品做类目和标签层面的相似度计算。如果某用户看了大量运动鞋却突然点了一个家电清洁剂并且行为链还是完整的那不能直接定性成噪声但置信度确实要打折。相反如果点击来源是搜索结果意图就相对明确因为搜索词本身就是一个强意图锚点。2.3 行为复现性判断一次是偶然两次是倾向三次是信号冷启动阶段单次交互不可信但同类交互复现后置信度会指数上升。我在项目里设置了一个简单窗口机制同一个用户在短时间窗口一般24小时内连续对同一类目下不同商品产生了3次以上完整的浏览行为这些交互的置信度统一调高一级如果只有1次按低置信度样本处理先不进下一轮模型训练的主训练集。3. 方法实践我如何对隐式反馈做去噪与置信度加权3.1 方案一基于行为序列的置信度打分模型与其给每条隐式反馈打一个“是/不是噪声”的标签不如给每条样本算一个置信度分数。这里我采用的是行为序列embedding加二分类器打分。先把用户在一次会话里的连续行为切成序列格式类似曝光商品A - 点击商品A - 停留20秒 - 滑动到详情2屏 - 返回列表 - 曝光商品B - 点击商品B - 停留3秒 - 退出将两类样本送入序列模型一类是人工规则筛选出来的确定正样本比如点击后产生了收藏、加购、下单的高完整性行为链一类是确定噪声样本比如机器刷量、1秒内退出、点击未超过页面10%高度的行为。模型输出0到1的置信度。实际使用时置信度大于0.7的样本直接作为强正样本参与训练介于0.4到0.7的样本作为弱正样本低于0.4的样本丢弃。这里有一个关键细节序列模型的训练样本不能用全量自动日志必须先用一套强规则产生“确定噪声样本”规则宁可苛刻也不能宽松。否则模型会把正常的长尾行为误判为噪声。我踩过这个坑刚开始为了快速出效果规则放得比较宽结果去噪后的样本量只剩原来的三分之一模型覆盖度明显不够。3.2 方案二曝光次数与交互率交叉验证针对物品侧噪声核心是用曝光数据做交叉验证。一条点击是否可信可以在物品维度上对比曝光数和点击数如果某商品曝光1000次点击率达到一个明显异常的高水平比如12%以上而同类目平均只有3%这种情况就要警惕是不是刷量或展示位异常。与此同时再对比点击到转化的漏斗转化率如果CTR极高而CVR极低那这批点击几乎可以肯定是低质量流量。我在冷启动推荐项目中会对所有新商品建立一个“冷启动探测期”一般是上线前7天。这期间系统只做曝光采样不直接进入全局排序。只有当某个商品的点击率和转化率的比值落在一个正常区间内根据同类目历史统计得到时才开始逐步增加流量分配。这种方式本质上是对噪声最猛烈的一段时间做主动规避而不是被动洗数据。3.3 方案三服务端日志与客户端埋点交叉验证这是过滤平台侧噪声最实用的一招。很多点击数据来自客户端上报但客户端上报的事件可以被篡改也可能因为网络问题重复上报。我在项目里要求所有参与训练的点击行为必须能在服务端访问日志中匹配到对应的接口请求。匹配不上的一律丢弃。这个方案看似简单实施起来却有几个坑客户端埋点事件和服务端请求日志的时间戳存在秒级偏差直接以毫秒匹配会导致大量正常样本被误杀。我最后是把时间窗口放宽到上下3秒再结合设备ID和商品ID做多字段关联。服务端日志需要保留完整的请求参数路径。有些服务为了性能只记录了部分参数导致无法还原完整的关联信息。浏览器端和App端的行为链路差异很大两端不能共用同一套校验规则。App端点击后拉起详情页往往有一层本地缓存渲染服务端日志不一定有请求这类情况需要额外保留一个“本地渲染上报”信号。4. 完整落地流程从原始日志到可用训练集的六步管线上面说的都是方法论真正落地的过程中我梳理了一条清晰的管线每一步都做了一轮人工抽样验证。这里把这套流程完整分享出来。4.1 第一步原始日志清理与会话分割这一阶段处理的是最基础的脏数据。去掉明显超时任务产生的空数据、去掉测试账号产生的日志、按设备ID加时间间隔切分会话。会话间隔我一般设置为30分钟超过30分钟没有行为就认为是一个新的会话。这个参数不是拍脑袋定的是根据项目统计的用户行为间隔分布得到的取的是分布曲线的拐点。4.2 第二步曝光去重与去重后归因同一个用户在同一个会话内反复刷到同一个商品只保留第一次曝光产生的行为记录。重复曝光会产生非常严重的正样本偏差。我在复盘中观察到一个商品在信息流里重复出现12次之后用户的点击概率会明显下降但模型会把这些点击都当作偏好信号导致后期出现“越推越窄”的收敛问题。4.3 第三步服务端日志交叉过滤这一步就是上面说的方案三。客户端点击事件对应的商品详情请求必须在服务端日志中存在。同时处理一个重要细节点击事件如果发生在商品详情接口请求之后超过5秒基本可以判定为异常上报直接丢弃。4.4 第四步生成行为序列并做置信度打分清洗后的数据进入序列模型打分。这一阶段输出的不是零一标签而是0到1之间的分数。我会把所有序列模型判定的结果、规则过滤结果、人工抽样复核结果都记录下来形成一份完整的去噪报告。这份报告对后续每次调整算法都很重要。4.5 第五步负反馈与低置信度样本的管理去噪后的低置信度样本并不是完全没有价值。对于置信度在0.2到0.4之间的样本我一般不直接丢弃而是打上“弱负样本”标签。具体来说如果商品曝光且完全无点击这是确定负样本如果点击退出了但用户明确没有有效停留这是弱负样本。弱负样本在训练中的权重按0.1计入。4.6 第六步人工抽样复核与动态更新每条收编进训练集的样本类型变化都会触发一轮人工抽检。抽检比例不需要高千分之一就够了重点看三类内容异常高置信度但可能误判的样本、被丢弃的低置信度样本中是否存在真实偏好、以及新商品上线的冷启动首日数据是否出现新的异常模式。每完成一轮抽检把结论反馈给规则引擎和序列模型完成一次闭环迭代。5. 实战复盘某新品频道的冷启动项目去噪过程与效果这套方案真正打到业务上是在一个新品频道推荐项目中。当时的情况是频道上线两周曝光量很大点击率做到了5%以上日均点击量过万但成交流水惨淡几乎可以忽略。运营那边已经开始怀疑是商品本身不行我坚持先查数据。5.1 问题定位从数据分层对比找到噪声源当时做了一场数据下钻分析把点击样本按用户分层拆开用户分层点击量占比平均详情停留时长24小时内二次点击率下单率新注册3天内61%7.2秒12%0.3%注册7天以上21%38.5秒43%2.1%异常账号疑似脚本18%1.1秒1%0%数据很直观新用户层级贡献了六成点击但平均停留只有7秒二次点击率也低实际上很多都是一次性误触。异常账号虽然只占18%的点击量却占用了大量曝光资源还直接污染了训练集。5.2 执行去噪后的指标变化按上面六步流程跑完第一轮去噪后重新统计训练集样本和线上效果训练集有效正样本量减少了约37%但样本置信度明显提升模型排序的离线指标AUC提升了4.5%左右线上曝光点击率下降0.8个百分点但详情页停留时长提升了120%下单转化率从0.3%提升到1.1%这里有一个很明显的反直觉现象去噪后点击率反而降了但在线真实转化提升了。因为之前模型学到的是噪声带来的虚假偏好推荐给用户的东西看起来点击很多实际匹配很差。去噪后模型真正开始学习强意向信号点击量下降但点击质量上涨用户找到目标商品的速度更快。5.3 从数据效果反推后端的联动变化去噪还有一个容易被忽略的价值它间接修正了推荐候选生成阶段的召回分布。之前基于脏数据的协同过滤会把热门但低质的商品反复召回形成马太效应。去噪之后召回层的候选池分布变得更加分散长尾新品获得了更多曝光机会。这个变化直接反映在频道整体的人均浏览商品数上从单次会话8.3个提升到13.1个。6. 效果评估与长期维护去噪模型本身也需要持续迭代去噪流程上线一段时间后会出现一个新问题噪声的形态也在进化。爬虫会模拟更真实的行为序列用户在冷启动期的行为会随着产品改版而变化原先设计的规则和置信度模型会慢慢失效。6.1 设计一套“噪声哨兵”监控机制我用三个核心指标做持续监控。第一是正样本置信度分数分布的变化如果分布整体向右移动或者出现双峰说明候选样本结构发生了改变。第二是曝光到交互的转化漏斗如果某些路径的漏斗出现突然收窄或放宽多半是链路出现异常。第三是训练集AUC与线上实时效果发生背离的频率这个偏离一旦频繁出现就说明训练分布和真实分布已经不匹配了。6.2 定期重建规则库与样本回流策略每个月做一次规则覆盖复盘把上一轮人工抽检中发现的新噪声形态沉淀成新的规则。比如有一段时间App版本升级后页面里新增了一个AR试戴入口导致大量用户点击后立即返回这个入口产生的点击在原有置信度模型中得分很高却明显是无效反馈。我们后来为AR入口单独配置了停留时长阈值才算把这类噪声清理掉。另一个经验是去噪后的样本如果你直接丢弃不做任何记录后面想追溯问题会非常痛苦。我的做法是为每个丢弃样本保留一份完整的“丢弃理由链”包含被哪条规则或哪个模型分数丢弃、关联的行为序列特征、以及后续抽样回访的结论。这样即使算法调整也能对比新旧方案差异。6.3 动态窗口下的冷启动探索策略最后补充一个和去噪配套的策略思路。当过滤规则已经稳定之后不要让新内容自动进入全量推荐继续保持一个低流量探索窗。这个窗口的作用不是获取更多训练样本而是压低噪声爆炸的风险。如果某新品在探索期内表现异常比如点击率偏高但停留为0这类异常样本会被拦截在训练集之外不会对下一轮模型更新造成冲击。冷启动场景下的去噪本质是一个“持续免疫”的过程要靠规则、模型、人工抽检、监控指标联动才能长期维持效果。