当前位置：首页 > news >正文

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

news 2026/7/23 8:35:38

推荐系统的 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 个，就将后面的同质商品移到窗口之后的位置。