1. 推荐系统架构全景解析现代推荐系统早已超越了简单的用户喜欢什么就推什么的初级阶段。一个成熟的工业级推荐系统通常采用分层处理架构就像工厂的流水线一样每个环节各司其职又紧密配合。这种设计不仅能处理海量数据还能在效果和性能之间取得平衡。我参与过多个日活千万级产品的推荐系统搭建发现分层架构最大的优势在于当某个环节需要优化时可以单独调整而不影响整体流程。比如想改进排序模型时只需在排序层做AB测试候选生成和过滤层可以保持不变。这种模块化设计让系统迭代变得高效可控。2. 候选生成从亿级物品池中快速筛选2.1 召回策略组合拳候选生成层Recall的核心任务是从亿级物品池中快速筛选出千级别的潜在候选。这里常用的方法有协同过滤基于用户历史行为计算相似度内容匹配利用物品标签/特征进行匹配热点补充适当加入实时热门内容地理位置结合LBS的本地化推荐实际工程中我们通常会采用多路召回策略。比如在短视频推荐场景我们会同时部署基于用户最近观看的视频类型召回相似内容根据用户关注列表召回创作者新作品从同城用户喜欢的视频中召回补充平台当前热门视频经验召回阶段不宜使用太复杂的模型重点要保证计算效率。我们一般用近似最近邻(ANN)算法替代精确计算能在毫秒级完成亿级物品的筛选。2.2 实时召回实践传统召回依赖离线计算现在越来越多的系统开始引入实时召回。我们团队的做法是用户每次互动行为点击/播放/收藏实时写入消息队列Flink消费消息后更新用户短期兴趣向量在线服务用更新后的向量实时召回内容实测表明引入实时召回后用户次日留存提升了3.2%。特别是在新闻资讯类产品中实时召回能显著提升时效性内容的曝光率。3. 过滤层业务规则与质量把控3.1 硬过滤规则候选生成的结果需要经过严格过滤主要包括去重去除用户已读/已购/已屏蔽的内容时效性过滤过期商品/下架内容合规性剔除违规或敏感内容冷启动对新用户适当放宽过滤条件我们在电商项目中曾遇到一个典型问题某商品因库存不足被过滤但用户搜索时仍能看到。后来增加了库存预扣减机制只有当实际库存0时才进入推荐流。3.2 软过滤策略除了硬规则我们还会应用一些柔性策略频控限制单个内容的最大曝光次数疲劳度降低连续推荐同类内容的权重多样性确保不同类别内容都有代表避坑指南过滤规则要定期review。我们曾因过滤规则过于严格导致新上架商品得不到曝光后来调整为新商品前3天适当放宽过滤。4. 排序模型从粗排到精排的层层递进4.1 粗排模型设计粗排Pre-ranking要对千级候选进行初步排序模型特点特征维度100-500个核心特征模型结构简单DNN或浅层GBDT耗时要求10ms/请求我们常用改进版的DINDeep Interest Network模型在用户历史行为序列上加入Attention机制能更好捕捉用户的动态兴趣。4.2 精排模型优化精排Ranking处理百级候选模型更为复杂特征工程加入交叉特征、统计特征模型架构DeepFM、MMoE等多任务模型目标函数综合点击率、停留时长、转化率在视频推荐场景我们使用多塔模型用户塔处理用户画像、行为序列视频塔处理内容特征、创作者信息上下文塔处理时间、位置等场景信息实验表明这种结构比单塔模型AUC提升0.015。5. 多样性控制推荐系统的调味艺术5.1 类别多样性我们采用以下方法保证类别覆盖在召回阶段设置类别配额排序模型中加入多样性特征后处理阶段使用MMRMaximal Marginal Relevance算法5.2 新颖性探索解决信息茧房的关键是EE策略ε-greedy、Thompson采样Bandit算法LinUCB、NeuralBandit新内容冷启动给予初始流量测试在资讯推荐中我们保留5%-10%的流量专门用于探索性推荐虽然短期指标可能下降但长期来看用户活跃度提升了8%。6. 工程实现关键点6.1 特征平台建设推荐系统依赖高质量特征我们构建了统一特征平台离线特征Hive表按天分区实时特征Flink计算写入Redis特征监控统计覆盖率、异常值6.2 模型服务化模型上线要考虑服务隔离排序模型独立部署流量控制AB测试分流机制降级方案当复杂模型超时自动切换简单模型我们使用TF Serving部署模型配合自定义的batching策略QPS提升3倍的同时保持延迟50ms。7. 效果评估体系7.1 离线评估指标AUC、GAUC模型区分度RecallK召回能力NDCG排序质量7.2 在线AB测试除了常规的CTR、CVR我们还关注用户停留时长次日/7日留存率多样性指数基尼系数在最近一次优化中我们通过改进多样性策略虽然CTR微降0.3%但用户日均使用时长增加了12分钟。8. 实战经验与避坑指南数据质量优先曾因用户行为日志丢失时间戳导致时序模型效果大幅下降。现在我们会做数据完整性检查确保关键字段不为空。模型可解释性当排序结果出现偏差时通过SHAP值分析发现是某个特征权重异常及时进行了修正。缓存策略优化热门内容的结果可以适当缓存但要注意设置合理的过期时间我们一般设置5-10分钟。资源隔离排序模型消耗大量CPU资源我们通过K8s的ResourceQuota避免影响其他服务。监控告警除了系统监控我们还设置了业务指标告警当CTR波动超过2个标准差时自动触发排查。
1. 推荐系统架构全景解析现代推荐系统早已超越了简单的用户喜欢什么就推什么的初级阶段。一个成熟的工业级推荐系统通常采用分层处理架构就像工厂的流水线一样每个环节各司其职又紧密配合。这种设计不仅能处理海量数据还能在效果和性能之间取得平衡。我参与过多个日活千万级产品的推荐系统搭建发现分层架构最大的优势在于当某个环节需要优化时可以单独调整而不影响整体流程。比如想改进排序模型时只需在排序层做AB测试候选生成和过滤层可以保持不变。这种模块化设计让系统迭代变得高效可控。2. 候选生成从亿级物品池中快速筛选2.1 召回策略组合拳候选生成层Recall的核心任务是从亿级物品池中快速筛选出千级别的潜在候选。这里常用的方法有协同过滤基于用户历史行为计算相似度内容匹配利用物品标签/特征进行匹配热点补充适当加入实时热门内容地理位置结合LBS的本地化推荐实际工程中我们通常会采用多路召回策略。比如在短视频推荐场景我们会同时部署基于用户最近观看的视频类型召回相似内容根据用户关注列表召回创作者新作品从同城用户喜欢的视频中召回补充平台当前热门视频经验召回阶段不宜使用太复杂的模型重点要保证计算效率。我们一般用近似最近邻(ANN)算法替代精确计算能在毫秒级完成亿级物品的筛选。2.2 实时召回实践传统召回依赖离线计算现在越来越多的系统开始引入实时召回。我们团队的做法是用户每次互动行为点击/播放/收藏实时写入消息队列Flink消费消息后更新用户短期兴趣向量在线服务用更新后的向量实时召回内容实测表明引入实时召回后用户次日留存提升了3.2%。特别是在新闻资讯类产品中实时召回能显著提升时效性内容的曝光率。3. 过滤层业务规则与质量把控3.1 硬过滤规则候选生成的结果需要经过严格过滤主要包括去重去除用户已读/已购/已屏蔽的内容时效性过滤过期商品/下架内容合规性剔除违规或敏感内容冷启动对新用户适当放宽过滤条件我们在电商项目中曾遇到一个典型问题某商品因库存不足被过滤但用户搜索时仍能看到。后来增加了库存预扣减机制只有当实际库存0时才进入推荐流。3.2 软过滤策略除了硬规则我们还会应用一些柔性策略频控限制单个内容的最大曝光次数疲劳度降低连续推荐同类内容的权重多样性确保不同类别内容都有代表避坑指南过滤规则要定期review。我们曾因过滤规则过于严格导致新上架商品得不到曝光后来调整为新商品前3天适当放宽过滤。4. 排序模型从粗排到精排的层层递进4.1 粗排模型设计粗排Pre-ranking要对千级候选进行初步排序模型特点特征维度100-500个核心特征模型结构简单DNN或浅层GBDT耗时要求10ms/请求我们常用改进版的DINDeep Interest Network模型在用户历史行为序列上加入Attention机制能更好捕捉用户的动态兴趣。4.2 精排模型优化精排Ranking处理百级候选模型更为复杂特征工程加入交叉特征、统计特征模型架构DeepFM、MMoE等多任务模型目标函数综合点击率、停留时长、转化率在视频推荐场景我们使用多塔模型用户塔处理用户画像、行为序列视频塔处理内容特征、创作者信息上下文塔处理时间、位置等场景信息实验表明这种结构比单塔模型AUC提升0.015。5. 多样性控制推荐系统的调味艺术5.1 类别多样性我们采用以下方法保证类别覆盖在召回阶段设置类别配额排序模型中加入多样性特征后处理阶段使用MMRMaximal Marginal Relevance算法5.2 新颖性探索解决信息茧房的关键是EE策略ε-greedy、Thompson采样Bandit算法LinUCB、NeuralBandit新内容冷启动给予初始流量测试在资讯推荐中我们保留5%-10%的流量专门用于探索性推荐虽然短期指标可能下降但长期来看用户活跃度提升了8%。6. 工程实现关键点6.1 特征平台建设推荐系统依赖高质量特征我们构建了统一特征平台离线特征Hive表按天分区实时特征Flink计算写入Redis特征监控统计覆盖率、异常值6.2 模型服务化模型上线要考虑服务隔离排序模型独立部署流量控制AB测试分流机制降级方案当复杂模型超时自动切换简单模型我们使用TF Serving部署模型配合自定义的batching策略QPS提升3倍的同时保持延迟50ms。7. 效果评估体系7.1 离线评估指标AUC、GAUC模型区分度RecallK召回能力NDCG排序质量7.2 在线AB测试除了常规的CTR、CVR我们还关注用户停留时长次日/7日留存率多样性指数基尼系数在最近一次优化中我们通过改进多样性策略虽然CTR微降0.3%但用户日均使用时长增加了12分钟。8. 实战经验与避坑指南数据质量优先曾因用户行为日志丢失时间戳导致时序模型效果大幅下降。现在我们会做数据完整性检查确保关键字段不为空。模型可解释性当排序结果出现偏差时通过SHAP值分析发现是某个特征权重异常及时进行了修正。缓存策略优化热门内容的结果可以适当缓存但要注意设置合理的过期时间我们一般设置5-10分钟。资源隔离排序模型消耗大量CPU资源我们通过K8s的ResourceQuota避免影响其他服务。监控告警除了系统监控我们还设置了业务指标告警当CTR波动超过2个标准差时自动触发排查。
