推荐系统里最隐蔽的坑：冷启动期的隐式反馈，一半是噪声

做推荐系统的朋友应该都有这种感觉：老用户的行为数据很“厚”，怎么折腾都行；可一遇到新用户、新商品，整个模型就像是掉进了一个装满伪信号的泥潭。点击率看着不低，转化却惨不忍睹；收藏不少，复购基本为零。这时候最让人头疼的，往往不是模型结构不够强，而是冷启动推荐阶段吃进去的隐式反馈，本身就有大量噪声。

我去年接手了一个面向新用户和新品类的推荐项目，核心指标一直上不去。最后把问题定位到数据层面才发现，我们在冷启动阶段用来训练的隐式反馈，有相当一部分是误触、无意义滑动、甚至爬虫产生的垃圾信号。模型学得越努力，推荐结果反而越跑偏。这篇文章就把我在这段时间里用到的去噪思路完整讲一遍，包括信号过滤、行为置信度加权和一个用于冷启动场景的伪标签迭代流程。适合正在做推荐系统冷启动、或者刚接触隐式反馈建模，想搞清楚“为什么数据这么脏、怎么洗才有效”的朋友。

1. 冷启动和隐式反馈碰在一起，为什么噪声特别多

先明确一下语境：冷启动推荐一般分三种，用户冷启动（新注册用户）、物品冷启动（新上架商品、新发布内容）和系统冷启动（新平台没数据）。无论哪种，共同特点是历史交互极少，模型只能在很稀疏的数据上做推断。而隐式反馈，指用户没有主动给出评价，但系统能观测到的行为信号，比如点击、滑动、停留、播放时长、页面切换。这类信号量大、收集成本低，但代价是行为本身有歧义。

冷启动阶段的歧义会被无限放大。举个例子，一个新用户在首页看到一个封面图很亮眼的商品，顺手点了进去，但发现根本不是自己要的东西，立刻返回。这个点击行为在传统隐式反馈模型里会记为正样本。如果这个商品恰好也是新品，两者都没有太多历史曝光，一个错误正样本可能直接让模型对“该商品→该用户”的关联建立起虚假的置信度。一两个这样的样本无所谓，问题是冷启动场景里这样的样本是批量产生的。

1.1 用户侧噪声：犯错成本极低，行为连续性差

新用户没有形成稳定的浏览习惯。他们在界面上停留时间短、点头绪乱、频繁返回清单页再重新进入。这种状态下产生的点击，很多是“试探性点击”或“局部误触”，并不是真实兴趣表达。更麻烦的是，新用户的反馈稀疏到无法用历史行为做交叉验证，比如老用户可能收藏了A类商品但没有收藏B类，出现这种“来源不明的点击”还能用偏好一致性去降权，新用户做不到。

1.2 物品侧噪声：新品曝光分布极端，样本高度同质化

新品在冷启动期往往集中在少数推荐位上，曝光集中在同一批用户。这批用户的点击行为高度同质化，一旦某个展位本身处于页面边缘或加载异常，就会产生大量无差别点击。这些点击从单条看和正常点击完全一样，从聚合统计看却呈现出“爆款”假象。做去噪时，物品侧最优先处理的是这类位置偏差与曝光虚高导致的系统性噪声。

1.3 平台侧噪声：自动化行为和接口异常

这可能是最容易被忽视的一块。冷启动阶段为了快速收集数据，很多平台会把新品推进信息流、瀑布流、甚至外部投放渠道。这种场景下自动化脚本和爬虫的流量占比明显高于正常搜索场景。它们的行为特征是：请求间隔均匀、浏览链路单一、停留时长极短但点击量巨大。如果不提前过滤，这些“虚拟用户”的交互数据会直接参与新品的CTR和转化率预估，造成指标虚高。

我把这三类噪声的特征和影响整理成了一个表，方便对照排查：

2. 先分类：什么样的隐式反馈算干净信号，什么样的必须排除

去噪不是简单地对所有低置信度样本一刀切。核心原则是保留“具有行为完整性的信号”，排除“孤立且无连续行为的点击”。一条干净的隐式反馈，至少应当能回答三个问题：用户看到了什么、用户在页面上做了什么、用户下一步去了哪里。

围绕这三点，我在项目中设计了三个层面的置信度判断。

2.1 行为完整性判断：一段能自洽的“浏览链”

看一条行为日志时，我会关注它是否属于一个完整浏览链：

1. 用户在列表页/推荐流看到商品卡片并触发曝光事件
2. 点击后进入详情页，页面停留达到预设阈值
3. 用户在详情页发生了至少一次有效交互（滑动、图片切换、参数查看）

只有同时满足这三步，这条点击才具备“行为自洽性”。我见过不少只记录“点击进入详情页”的埋点方案，这远远不够。比如用户点进详情页后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 问题定位：从数据分层对比找到噪声源

当时做了一场数据下钻分析，把点击样本按用户分层拆开：

数据很直观：新用户层级贡献了六成点击，但平均停留只有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，这类异常样本会被拦截在训练集之外，不会对下一轮模型更新造成冲击。冷启动场景下的去噪，本质是一个“持续免疫”的过程，要靠规则、模型、人工抽检、监控指标联动才能长期维持效果。