推荐系统为何总推相似内容
刷短视频时，连续跳出三个一模一样的猫跳舞视频；购物网站上，同款拖鞋换了个颜色又被推到首页。这种“似曾相识”的体验，其实是推荐系统没处理好去重逻辑。运维人员在调优推荐模块时，得把“避免重复”当成基础任务来抓。
从数据源头掐掉重复项
很多重复问题出在数据输入阶段。比如商品库中同一款手机因渠道不同被录成三条记录，用户行为日志里点击事件被重复上报。这类情况需要在数据清洗环节加规则过滤。
DELETE FROM user_click_log
WHERE (user_id, item_id, click_time) IN (
SELECT user_id, item_id, MIN(click_time)
FROM user_click_log
GROUP BY user_id, item_id
HAVING COUNT(*) > 1
);上面这条SQL能清除同用户对同一物品的多余点击记录。类似地，在特征工程阶段可以用MD5对文本标题做哈希，相同哈希值的商品大概率是重复条目。
实时去重缓存机制
线上服务通常用Redis保存用户近期浏览过的ID列表。每次生成推荐前，先查缓存剔除已曝光项。例如一个用户刚看完某部电影，接下来半小时内就不该再推相同内容。
user_history = redis_client.lrange("rec_history:user_123", 0, -1)
filtered_candidates = [item for item in candidate_list if item.id not in user_history]这个机制简单但有效，关键是要控制缓存周期。太久不清理会导致可推荐池子越来越小，太短又起不到去重作用。一般设为6小时到24小时比较合理。
多样性打散算法介入
完全靠过滤会损失推荐效率，这时候需要引入打散策略。比如按类别轮询展示：科技、生活、娱乐类内容交替出现。或者限制同类商品连续推荐不超过两个。
某电商首页信息流采用滑动窗口法，在每8个推荐位中最多允许2个来自同一品牌。这种规则写进排序服务的后处理模块，不影响上游模型输出。
用户反馈闭环调节
有些人看到重复内容会点“不感兴趣”，这个信号要快速回流到系统。运维侧需监控“重复投诉率”指标，一旦某类内容被多人标记重复，就临时降低其权重。
比如短视频平台发现某个热门BGM的视频被频繁跳过，系统自动对该音频下的所有视频降权48小时。这种动态调整比固定规则更贴合真实体验。
跨场景协同防重复
用户可能在APP首页、消息推送、邮件营销多个渠道接收推荐。如果各系统独立运行，很容易出现“三端齐推一条新闻”的尴尬。建议建立统一的内容曝光中心服务，所有推荐请求先向中心报备，避免多头出击。
实际部署时可用轻量级API记录每次曝光，查询延迟控制在10ms以内。虽然增加了一次网络调用，但换来的是整体体验的清爽度提升。