推荐系统的 AI 化改造——从规则推荐到深度学习的架构迁移方案

一、规则推荐的困境：场景爆炸导致规则失控

电商平台的推荐系统早期是用规则引擎驱动的。运营同学配置几百条规则，比如"买了口红的推荐卸妆水""库存大于 100 且利润率大于 30% 的置顶""新用户前三天只推爆款"。这些规则在 SKU 量级在 10 万以内、推荐场景在 5 个以内时说得过去——运营可以逐条维护，效果看得见。

当 SKU 增长到 200 万、推荐场景扩展到首页、商品详情页、购物车、支付成功页、Push 推送等 15 个场景时，规则系统就陷入了维护困境。不同场景的规则互相冲突，新增商品的规则覆盖需要 3 天时间，推荐结果千人一面，CTR（点击率）长期在 3% 左右。但完全推倒重来不行——平台每天有 300 万 GMV 依赖推荐系统驱动，大幅度波动是不可接受的。

二、渐进式迁移架构：规则平滑退出，模型逐步介入

渐进式迁移的核心是流量切分和结果融合。全部流量通过推荐路由层按 userId 哈希做实验分流，前 10% 流量走深度学习模型推荐，90% 流量走原有规则引擎。观察一周后，如果模型推荐的核心指标（CTR、转化率、人均浏览商品数）均不低于规则引擎的 95%，则将实验流量扩大到 30%；再观察两周，如果指标稳定或优于规则，扩大到 60% 并准备全量切换。

召回层的多路设计是模型效果的基石。协同过滤召回覆盖了用户与商品的交互行为；向量召回通过 Item2Vec 捕获商品间的语义相似关系；热门召回作为冷启动和新用户的兜底策略。三路召回各自返回 Top 200，合并后由粗排模型（双塔结构）筛选到 Top 100，再送入精排模型（DeepFM）做最终排序。精排模型融合了用户特征（历史购买品类、价格偏好、活跃时段）、商品特征（类目、价格、销量、评分）和上下文特征（当前时间、所在页面、前一个浏览商品）。

三、特征工程与模型的 Java 服务化

深度学习模型的训练是在 Python 生态（TensorFlow）中完成的，但推理上线要走 Java 服务。我们采用 TF Serving 的方式：模型训练好后导出为 SavedModel 格式，部署在独立的 TF Serving 容器中，Java 后端通过 gRPC 调用推理接口。

@Service public class DeepRankService { private final ManagedChannel tfServingChannel; private final PredictionServiceGrpc.PredictionServiceBlockingStub stub; public DeepRankService(@Value("${tfserving.host}") String host, @Value("${tfserving.port}") int port) { this.tfServingChannel = ManagedChannelBuilder .forAddress(host, port) .usePlaintext() .maxInboundMessageSize(16 * 1024 * 1024) // 16MB 上限 .build(); this.stub = PredictionServiceGrpc.newBlockingStub(tfServingChannel); } /** * 批量推理精排分数 * @param userId 用户 ID * @param itemIds 候选商品 ID 列表（粗排后的 Top 100） * @return 每个商品对应的精排分数 */ public Map<String, Float> rank(String userId, List<String> itemIds, String page, String deviceType) { // 构建推理请求：组装用户特征、商品特征和上下文特征 PredictRequest request = buildRequest(userId, itemIds, page, deviceType); try { PredictResponse response = stub .withDeadlineAfter(150, TimeUnit.MILLISECONDS) // 150ms 超时 .predict(request); return parseScores(response, itemIds); } catch (StatusRuntimeException e) { // TF Serving 异常时降级到粗排分数 return fallbackScores(itemIds); } } private Map<String, Float> fallbackScores(List<String> itemIds) { // 降级策略：按粗排顺序给分，保持原有的排序 Map<String, Float> scores = new LinkedHashMap<>(); float baseScore = 1.0f; for (String itemId : itemIds) { scores.put(itemId, baseScore); baseScore -= 0.01f; // 逐步递减 } return scores; } }

TF Serving 的推理超时设置为 150ms。推荐系统的 P99 延迟要求是 200ms，需要为召回、粗排、精排、重排每个阶段做超时预算控制。精排完成后，重排层要做多样性打散——避免同一个品牌、同一类目的商品连续出现在推荐列表中。我们实现了一个简易的打散算法：滑动窗口内如果同一类目的商品超过 2 个，就将后面的同质商品移到窗口之后的位置。

四、效果验证与模型迭代

模型推荐上线后，CTR 从规则推荐的 3.1% 提升到 5.4%，转化率从 2.0% 提升到 3.2%，人均浏览深度从 12 个商品增加到 18 个。更关键的是推荐的长尾覆盖：模型推荐中非头部 20% 的商品占比从 8% 提升到 23%，缓解了规则推荐的"马太效应"。

模型的迭代周期是每周一次，训练数据是过去 30 天的用户行为日志。每次模型更新后先在 10% 实验流量上验证 24 小时，核心指标无劣化后才推广到全量。每个模型版本都记录在模型管理系统中，包含训练时间、训练数据范围、评估指标和流量分配比例，支持快速回滚。

冷启动问题也做了针对性处理。新用户和新商品的 embedding 可以通过属性特征（类目、价格、品牌）的均值向量来做近似估计。对于没有任何行为数据的全新用户，则完全退回到热门召回通路。

五、总结

推荐系统从规则到深度学习的迁移，关键是控风险和保旧路。渐进式流量切换保证业务稳定性，多路召回保证结果多样性，TF Serving 的 Java gRPC 调用保证推理延迟可控，降级策略保证服务可用性。模型上线不是终点——特征更新、模型迭代、效果监控和 A/B 实验是持续的工作。