推荐系统的技术债实验平台和特征管道比模型本身更难维护一、模型不是最难的部分——推荐系统的真实瓶颈藏在基础设施里业界聊推荐系统80% 的精力花在聊模型——双塔、DIN、DeepFM、多目标优化各种前沿论文层出不穷。但在生产环境里跑了两年推荐系统之后一个事实会越来越清晰模型迭代的成本远低于基础设施维护的成本。一个 CTR 预估模型从训练到上线流程是可控的——样本构造、特征工程、模型训练、离线评估、AB 测试、全量上线。模型没效果换一组特征或者换一种网络结构一个迭代周期 1-2 周。模型发版出错回滚上一版 Serving 目录几秒内恢复。但实验平台和特征管道不是这样。它们是有机体——一旦建好就不再是一个独立系统而是和业务逻辑、数据流、组织形态深度耦合的生态。实验平台的设计决定了能不能高效验证新策略特征管道的架构决定了特征迭代的成本是加一行 SQL还是重构整个数据管道。这两种基础设施之所以变成技术债不是因为一开始建得不好而是因为推荐系统的业务需求在持续膨胀。一年前只需要 20 个特征现在需要 200 个一年前只有一个推荐场景首页 Feed现在有 5 个搜索结果页、猜你喜欢、购物车推荐、Push 推送、直播间推荐。特征管道和实验平台需要频繁扩展来跟上业务速度而这种扩展的摩擦成本就是技术债的利息。二、实验平台的技术债正交性、指标口径和灰度耦合实验平台的第一笔技术债是实验正交性冲突。当一个推荐系统同时跑 10 个 AB 实验时各实验之间的流量分层是否正交、实验组是否互相干扰是一个极度复杂的验证问题。一个经典的事故实验 A优化召回排序和实验 B优化精排特征在正交层上同时影响同一个用户结果是实验 A 的点击率 5%、实验 B 的 -3%合并后 2%。但这 2% 不是因为两个实验都有效而是 A 提的点数覆盖了 B 丢的点数——实际上 B 是负向策略。如果不是事后做交叉分析这个错误的结论会被当作两个实验都正向记入文档。实验平台的第二笔技术债是指标口径不一致。产品经理想的点击率是 UV CTR算法工程师说的是 PV CTR数据开发同学做报表时又是 Session CTR。三套口径在每一次实验报告里对不上团队之间反复对齐口径的时间比真正分析实验结论的时间还长。这不是技术问题是组织协作问题附着在技术系统上的表现。第三笔是灰度发布和新模型上线的耦合。推荐系统很少是一键全量的上线模式——通常先灰度 1% 流量观测 2 小时再扩到 10% 观测 1 天最后全量。灰度发布系统本身是独立的但当灰度策略和实验平台的分流规则打架时——灰度 10% 的流量和实验平台的 20% 对照组流量重叠——上线效果的数据就混入了噪音。谁先扩、谁后扩、哪些组应该排除这些事情没有自动化全靠人力口头对齐对齐成本随实验数量增长而非线性增长。三、特征管道的技术债血缘、一致性和回填特征管道在推荐系统里处于被所有上游依赖影响所有下游的位置但得到的关注度远不如模型。日积月累管道的技术债变成三座大山。第一座山特征血缘不清。一个推荐系统运行一年后可能积累 200 个在线特征和 500 个离线特征。有些特征被 3 个模型使用有些特征早已被废弃但仍在每天跑 Spark 任务——因为它还出现在某个几乎无人维护的报表 SQL 里。想清理一个旧特征先花两天时间追溯所有依赖方发 5 封邮件确认这个特征你们还在用吗。这种维护成本随着特征数量的增长指数级上升。第二座山Online-Offline 特征不一致。离线训练时 Spark 计算的特征分布和在线推理时 Flink 实时计算的特征分布因为数据源、时间窗口和聚合逻辑的细微差异产生了系统性的偏差。某推荐系统发现离线 AUC 0.78在线 CTR 比预期低 12%——排查了两周才发现是离线特征用了 30 天窗口的历史数据在线特征只有 2 小时的内存数据。特征管道的在线-离线一致性检查应该是一个自动化流程但大多数团队靠人眼核对效果和可持续性都堪忧。第三座山特征回填困难。新模型上线需要过去 30 天的历史特征数据做训练样本。如果特征是过去一个月才新建的怎么办只能回填——用历史原始日志重新计算新特征。这件事的工程链路极长从 HDFS 拉取 30 天的原始日志 → Spark 重跑特征 → 落样本表 → 启动训练。快一点 2 天慢一点 5 天。如果需要回填的特征数量多10Spark 集群资源被回填任务打满正常的天级特征计算和模型训练全部排队等待。特征管道的维护难题本质上是一个数据工程问题但推荐团队往往是算法主导、工程接棒、数据缺失三角色之间没有统一的特征治理 Owner。特征管道的技术债就是这种组织架构缺陷在代码层面的投影。四、还债策略不是推倒重来是渐进式治理推荐系统的技术债不能靠推倒重来解决——重构一个实验平台需要 2-3 个月重做一套特征管道需要 3-6 个月业务迭代不会等你这么久。务实的做法是渐进式治理——在当前架构上做局部改进逐步提升可维护性。实验平台的治理重点有三件事强制正交性检查——每次新建实验时系统自动检查实验层是否和已有实验冲突不通过就不让上线。这块在 Google 的 Overlapping Experiment Infrastructure 论文里有成熟的层域管理模型可以参考。指标口径统一——所有实验报表从一个权威的指标计算服务出不允许各团队自己算自己报口径打架的问题从流程上封死。灰度-实验耦合治理——灰度流量自动从实验流量池中排除通过配置中心管理互斥规则减少人工对齐。特征管道的治理重点是特征血缘自动化。在特征注册表中维护每个特征的生产方式、消费方、更新频率。当 Spark 任务运行时自动检测如果某个特征在最近 30 天没有被任何模型或报表消费自动标记为候选下线。这比人工排查高效得多。Online-Offline 一致性检查也应该自动化——每天凌晨的 Spark 任务完成后自动对比在线和离线特征分布的关键统计量均值、方差、分位数漂移超过阈值自动告警。治理的另一个重要维度是特征编码规范。特征命名必须遵守统一格式如{domain}_{entity}_{stat_type}_{window}user_click_ctr_7d特征的加工逻辑要有单元测试Spark 任务的单元测试虽然难写但特征计算逻辑相对独立适合单独测试。编码规范和测试覆盖虽小却是防止特征管道熵增最有效的手段。五、总结推荐系统的核心竞争力不在模型本身而在支撑模型高效迭代的基础设施。实验平台决定了能不能快速验证想法特征管道决定了能不能低成本添加新信号。这两套基础设施的技术债如果不在前期预留治理空间会在一年内膨胀到吞噬团队一半以上工程精力的程度。还债的关键不是停下来重构而是在日常迭代中嵌入治理动作。实验平台的强制正交检查、指标口径统一、灰度互斥管理特征管道的血缘追踪、一致性检查、编码规范——把这些动作做成自动化流程让治理成为日常开发的一部分而非一个独立的还债项目。最终衡量标准很简单一个新特征从提出到上线需要几天一个新 AB 实验从配置到出报告需要几小时这两个数字越小说明基础设施的健康度越高。如果新特征要两周、新实验要三天那模型迭代再快也没用——漏斗卡在上游所有下游都在空转。