工业级推荐系统架构设计与工程实践

1. 推荐系统架构全景解析

现代推荐系统早已超越了简单的"用户喜欢什么就推什么"的初级阶段。一个成熟的工业级推荐系统通常采用分层处理架构，就像工厂的流水线一样，每个环节各司其职又紧密配合。这种设计不仅能处理海量数据，还能在效果和性能之间取得平衡。

我参与过多个日活千万级产品的推荐系统搭建，发现分层架构最大的优势在于：当某个环节需要优化时，可以单独调整而不影响整体流程。比如想改进排序模型时，只需在排序层做AB测试，候选生成和过滤层可以保持不变。这种模块化设计让系统迭代变得高效可控。

2. 候选生成：从亿级物品池中快速筛选

2.1 召回策略组合拳

候选生成层（Recall）的核心任务是从亿级物品池中快速筛选出千级别的潜在候选。这里常用的方法有：

  • 协同过滤：基于用户历史行为计算相似度
  • 内容匹配：利用物品标签/特征进行匹配
  • 热点补充：适当加入实时热门内容
  • 地理位置：结合LBS的本地化推荐

实际工程中，我们通常会采用多路召回策略。比如在短视频推荐场景，我们会同时部署：

  1. 基于用户最近观看的视频类型召回相似内容
  2. 根据用户关注列表召回创作者新作品
  3. 从同城用户喜欢的视频中召回
  4. 补充平台当前热门视频

经验：召回阶段不宜使用太复杂的模型，重点要保证计算效率。我们一般用近似最近邻(ANN)算法替代精确计算，能在毫秒级完成亿级物品的筛选。

2.2 实时召回实践

传统召回依赖离线计算，现在越来越多的系统开始引入实时召回。我们团队的做法是：

  • 用户每次互动行为（点击/播放/收藏）实时写入消息队列
  • Flink消费消息后更新用户短期兴趣向量
  • 在线服务用更新后的向量实时召回内容

实测表明，引入实时召回后，用户次日留存提升了3.2%。特别是在新闻资讯类产品中，实时召回能显著提升时效性内容的曝光率。

3. 过滤层：业务规则与质量把控

3.1 硬过滤规则

候选生成的结果需要经过严格过滤，主要包括：

  • 去重：去除用户已读/已购/已屏蔽的内容
  • 时效性：过滤过期商品/下架内容
  • 合规性：剔除违规或敏感内容
  • 冷启动：对新用户适当放宽过滤条件

我们在电商项目中曾遇到一个典型问题：某商品因库存不足被过滤，但用户搜索时仍能看到。后来增加了"库存预扣减"机制，只有当实际库存>0时才进入推荐流。

3.2 软过滤策略

除了硬规则，我们还会应用一些柔性策略：

  • 频控：限制单个内容的最大曝光次数
  • 疲劳度：降低连续推荐同类内容的权重
  • 多样性：确保不同类别内容都有代表

避坑指南：过滤规则要定期review。我们曾因过滤规则过于严格，导致新上架商品得不到曝光，后来调整为"新商品前3天适当放宽过滤"。

4. 排序模型：从粗排到精排的层层递进

4.1 粗排模型设计

粗排（Pre-ranking）要对千级候选进行初步排序，模型特点：

  • 特征维度：100-500个核心特征
  • 模型结构：简单DNN或浅层GBDT
  • 耗时要求：<10ms/请求

我们常用改进版的DIN（Deep Interest Network）模型，在用户历史行为序列上加入Attention机制，能更好捕捉用户的动态兴趣。

4.2 精排模型优化

精排（Ranking）处理百级候选，模型更为复杂：

  • 特征工程：加入交叉特征、统计特征
  • 模型架构：DeepFM、MMoE等多任务模型
  • 目标函数：综合点击率、停留时长、转化率

在视频推荐场景，我们使用多塔模型：

  • 用户塔：处理用户画像、行为序列
  • 视频塔：处理内容特征、创作者信息
  • 上下文塔：处理时间、位置等场景信息

实验表明，这种结构比单塔模型AUC提升0.015。

5. 多样性控制：推荐系统的调味艺术

5.1 类别多样性

我们采用以下方法保证类别覆盖：

  • 在召回阶段设置类别配额
  • 排序模型中加入多样性特征
  • 后处理阶段使用MMR（Maximal Marginal Relevance）算法

5.2 新颖性探索

解决信息茧房的关键是：

  • E&E策略：ε-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：模型区分度
  • Recall@K：召回能力
  • NDCG：排序质量

7.2 在线AB测试

除了常规的CTR、CVR，我们还关注：

  • 用户停留时长
  • 次日/7日留存率
  • 多样性指数（基尼系数）

在最近一次优化中，我们通过改进多样性策略，虽然CTR微降0.3%，但用户日均使用时长增加了12分钟。

8. 实战经验与避坑指南

  1. 数据质量优先：曾因用户行为日志丢失时间戳，导致时序模型效果大幅下降。现在我们会做数据完整性检查，确保关键字段不为空。

  2. 模型可解释性：当排序结果出现偏差时，通过SHAP值分析发现是某个特征权重异常，及时进行了修正。

  3. 缓存策略优化：热门内容的结果可以适当缓存，但要注意设置合理的过期时间（我们一般设置5-10分钟）。

  4. 资源隔离：排序模型消耗大量CPU资源，我们通过K8s的ResourceQuota避免影响其他服务。

  5. 监控告警：除了系统监控，我们还设置了业务指标告警，当CTR波动超过2个标准差时自动触发排查。