Reddit、YouTube、Facebook点赞处理及推荐算法运行逻辑技术问询

1. 点赞、推荐功能的通用实现逻辑 #

• 点赞功能前端层面是状态触发组件，点击后先做本地状态回显（比如按钮变亮、计数临时增减），同时异步调用后端interaction/like类接口，后端会做用户身份校验、内容合法性校验，完成后将交互记录写入用户行为库、内容统计库，再返回最终状态给前端同步更新。
• 推荐功能是多层级架构：底层是召回层，会基于用户基础画像、历史行为、内容标签从千万级内容池里捞出千条左右候选内容；中层是排序层，用LR、深度神经网络等模型给每条内容打分，分值维度包括匹配度、热度、用户偏好契合度；上层是重排层，会做内容多样性调整、合规过滤、广告插入，最终输出几十条内容到用户端。

2. 点赞行为影响推荐结果的高层级流程 #

用户点赞数据会先进入用户行为数据管道，按以下步骤处理：

• 特征提取：把这次点赞对应的内容标签（比如内容分类、作者、关键词、时长）、交互场景（首页推荐、搜索结果、好友动态）、交互时长（点击点赞按钮前停留在内容页的时间）都提取成结构化特征，写入用户偏好画像库。
• 模型更新：离线训练的推荐模型会每天全量用最新的用户行为数据迭代参数，实时流模型会分钟级把新的交互特征喂入短期偏好模型，调整用户的短期偏好权重。
• 推荐调整：下次用户刷新推荐流的时候，召回层会优先捞取和用户新偏好匹配的内容，排序层也会给对应标签的内容加权重分，最终呈现的推荐结果就会向用户点赞的内容方向倾斜。

3. 点赞/点踩操作是否会立即更新推荐列表 #

不会直接立即更新当前展示的推荐列表：

• 点击按钮的瞬间会立即调用后端接口上报交互数据，也会即时更新用户的偏好特征库，但已经加载到用户本地的推荐列表不会做实时替换，避免内容频繁跳动影响体验。
• 只有当用户手动下拉刷新、或者滚动到当前列表底部加载下一页内容的时候，新的偏好特征才会作用到新的推荐结果里。部分平台会做少量实时插入，但也只会在用户刷新的时候生效，不会修改已经加载出来的内容。

4. 误触延时机制和反复点赞 spam 操作的处理逻辑 #

• 大部分平台都设置了300ms到1s不等的前端延时上报逻辑：用户点击点赞按钮后如果短时间内又点击取消，就不会上报后端，避免误触产生无效数据。
• 针对同一内容反复点赞取消的spam操作：首先前端会做频率限制，10s内反复操作超过5次的话会临时禁用点赞按钮10s；后端层面会把短时间内对同一内容的多次互斥操作判定为无效交互，不会计入用户行为特征，也不会修改内容的点赞计数；如果单用户短期内出现大量这类操作，会被判定为行为异常，触发风控校验，严重的会临时限制交互功能24小时。

内容的提问来源于stack exchange，提问作者Eric Gumba