人力分为模型迭代的人力和模型维护的人力。模型迭代的人力首先是在于模型是否具有通用性和普遍性,模型的设计是否可以模块化分开迭代,这样最大限度的避免了耦合上的人力内耗。模型维护的人力主要在于模型数量和模型稳定服务的人力投入。两种人力问题的二合一例子就是多场景在通用维护以及特异性迭代上的矛盾。今天很多团队一开始迭代一个场景对应生产一个模型,随着平台的发展逐渐迭代多个场景多个模型,如果人力不够会尝试发展多场景归纳到一个模型从而节约人力,但是其中一个场景的数据分布发生剧烈变化或者业务优化目标发生变化,又会干扰到其他场景,为了屏蔽对应风险又要进行拆分,从而出现节约模型迭代人力、增加维护稳定人力的矛盾。因此在对应问题上需要看各自业务的发展需求,如果业务目标大家认为simple is more,很长一段时间不会追求差异化,那么可以考虑多场景建模,但是如果平台发展的瓶颈期需要精细化去挖掘剩余价值,可以思考进行迭代生产链路的流水线升级,对应新增场景的生产和维护只需配置即可上线服务,这样也会节约人力。综上想说明的就是在设计模型的时候一定要考虑未来的人力投入,如果花一个月上线的提效,以后每周都要花一天时间维护稳定,那不如多花点设计一个轻维护的模型省心。
(4)可迭代性
由于不同团队的迭代和系统架构有所不同,上图我就不再展开,例如部分团队的样本来自于在线请求打分的直接落盘,而我们团队从迭代性考虑在样本生产上还是主要采用feature join的逻辑。整体迭代体系可以形象成下图的组织结构:"RTP计算平台 & 样本、模型、特征三兄弟 & 训练引擎XDL"。