背景目标
背景
了解项目的背景,在公司的生态位中作用,能产生的业务价值,影响的业务范围。
价值有多大,影响多大。坑多不多。
历史迭代
了解曾经有哪些方向迭代过,哪些成功or失败的经历。很多公司有钱,一个业务有很多个团队都迭代过,也有很多经验,需要进行了解。
如果业务是产品等提过来的,则可以找对方了解这些信息,或者让对方去获取这些信息,这是产品的工作。
业务生态
可以有哪些渠道去获取业务数据,拓展内容数量等。
算法是依赖数据的,数据能够为算法提供哪些子弹。
很多时候是生态有变化,技术有发展,才会把一个业务更新迭代,也才能有效果。
目标
基本确定上面几项,才能更深刻的了解业务目标,才好进行整体工作。
数据分析
数据确认校验
数据口径要对齐,业务方看哪些指标,指标如何计算的,要了解这些信息:
- 数据来源
- 数据维护情况
- 分析看板
宏观数据
了解宏观数据情况,是否符合业务描述。
基线分析
目前业务现状如何,用到哪些数据,存在哪些问题,需要输入分析报告
可行性分析
根据现状,分析模型设计优化的可行性。算法模型不是上了就有效果。包含但不限于如下情况:
- 新的探索:以前没做的,现在来深入做了,就会有机会
- 技术代差:从人工规则到算法,从普通线性模型到机器学习模型,深度学习模型;有技术代差才有效果提升
- 数据源:更高质量的数据引入
- 实时性:实时的特征,计算也是提升效果的一个维度
- 明显缺陷:之前业务设计有明显没考虑到的角度,明显的数据缺陷,则是提升的空间
- 业务价值大:如果业务很赚钱,则深入做是很有机会的,小的优化就能带来大的提升,但因为只做一个小模块,需要事先想好如何评估,否则做了不被认可,比如做召回,但精排又管不了
如果以上都没有,需要看下业务能否做出价值
KPI定制
根据业务目标,数据情况,定制KPI指标,以此作为训练分析的指标。
- 目标正相关:一般业务目标都是促活,增收,降本等,但算法模型本身不能定这种目标
- 能快速迭代:在尽量短的周期内能评估得到效果的最好,1小时,1天最好;比如目标是半年内付费比例,那就基本就坑死自己。
建模
特征分析
特征的分布,异常值,缺失值。
相关性分析。
生态分析,比如推荐的内容是否完备等。
特征工程
特征工程在做什么
以下内容抄自这个链接(如果侵权立删):
- 样本处理
-
- 异常样本清洗
-
- 采样,样本不均衡处理
-
- 样本权重
- 单个特征
-
- 归一化
-
- 离散化
-
- 编码
-
- 缺失值,异常值处理
-
- 数据变换:log,指数,时间衰减,box-cox变换(连续性变量不满足正态分布则可以做这个变换)
- 多个特征
-
- 降维:PCA,LDA
- 特征选择
-
- filter:自变量和目标关系选择,相关系数,卡方检验,信息增益,互信息
-
- wrapper:目标函数评估是否加入新特征,迭代产生特征子集,然后评价,可考虑完全搜索,启发式搜索,随机搜索等
-
- embedding:机器学习自动选择。L1NORM,决策树的熵、信息增益,深度学习
-
- 衍生变量:特征交叉,除法,减法等处理,可以根据特征重要性变化来评估处理是否有用
模型设计
如果前期设置的好,模型反而工作更纯粹了:
- 模型选型
- 模型设计
- 调参:网格搜索,超参数寻优等
- 优化设计:根据模型效果反推优化模型,必要时把模型拆成多个模块分别对不同场景优化
- badcase分析:做模型的人最怕看到badcase,但其实能帮助发现模型的缺陷,需要注意评估量级。badcase挖掘方法本来也可以做成一套流程,还可以根据
效果评估
- KPI指标评估
- 周边指标评估:最好拉通分析同学,设计完整的分析指标,而不是盯着auc之类的单一指标调来调去
- badcase分析:需要注意评估量级
仿真模拟
有时kpi指标不是模型直接输出的,需要模拟真实环境计算,则需要搭建仿真模拟流程。
我曾经也觉得搭建仿真模拟流程非常费时,性价比不好。
但模型要多轮迭代测试,其实最终仿真模拟性价比还比较高。
开发
架构设计
技术选型,包括数据和算法部署的方案。关注原则:
- 性能达标
- 方便部署,回滚
- 模型扩展
一般不会只有组模型,会有在各个模块完善。 - 方便监控
- abtest支持
- 技术先进性
研发流程
算法涉及到前后端开发等多个角色,算法也会多次迭代部署上线。需要事先定制好流程
- 上线前测试流程
模型上线前,都要进行模型测试,因为一般测试都不会测模型,所以算法要自己准备一套测试流程。 - 数据开发上线流程
数据上线也是同理。 - 后端上线流程
后端一般有标准的上线流程,也就还好。 - 灰度流程
一般需要设计灰度流程,业务先跑一段时间ok了再慢慢切换。
数据开发
数据开发和一般的开发不同,一般开发输入问题不大,输出只要测试通过都ok。但数据不一样,数据源经常会有各种问题,计算错误延迟等,或者没人维护
- 数据源稳定性
- 数据源监控:量级,重复性,缺失值等监控
- 特征监控:特征是最终输出给模型用的,所以需要监控结果
- 模型输出监控
- 异常告警
模型部署
模型部署,需要严格按照流程执行。
监控
效果监控不用说,而且是持续的完善。
也需要关注特征,模型的结果监控,异常监控功能,这是算法的一部分。
运营
效果监控
除了基础分析外,运营中也会因为业务问题而需要深入分析:
- 脱离具体算法:一般尽量让效果监控脱离具体的算法,从更宏观角度来监控
- 下钻分析:宏观效果ok,不代表细化ok,经常需要深挖。需要搭建配套监控。
- badcase挖掘:一般来说badcase挖掘方法比较复杂,也比较多样,需要定制复杂的流程挖掘,以及修复后可以持续监控。
运营效率提升
业务一般有配套的业务,比如推荐有推荐内容生态的建设等,有相应运营团队来做内容,则为了让推荐效果更好,也会拓展运营效率的任务。
用户价值,潜客挖掘会对应销售团队,则需要销售系统完善,提供参考的指标,能提升整体效率。
项目管理
以上整个流程,会花掉很多时间,如果都做则整个流程会比较漫长。
但作为技术负责人,需要把握住关键点:
- 保质保量:保障每个模块都保质保量完成,不能因为业务压力就缩减工作,未来给自己项目埋下坑。需要顶住业务压力,保证各个模块按照标准流程进行,才不会埋坑。
- 详细工作安排:详细的业务工作量给业务列出来,并且每个人按照要求定期输出工作内容,业务也会觉得比较专业,也会认可投入。同时也更好评估工作量
- 定期沟通:我会倾向于把详细算法过程和业务产品解释,是否听得懂再看,核心是让对方任何整个结果,也辅助看有没问题。
- 业务也会感兴趣:业务虽然说听不懂算法只想要结果,或者巴不得需求提出来后30min就想业务上线,但其实算法也牵扯到业务个人利益,嘴上说不想了解细节,其实还是很想知道细节,毕竟万一有坑对自己kpi影响很大,大家是有共同目标的。
- 避免业务强势:算法要保证专业性,也要避免业务介入过多,一般整个项目计算流程不会绝对完美(时间不允许),有些参数,有些场景是不会
- 避免人员缺位:产品经理,项目经理,业务方,上游数据提供方,业务方后台,运维。一旦有人缺位(不投入or人员撤走)就要很大精力填补,一定要保障人员到位,不然其他人就会很累。
不存在是某个角度就这么一点点工作,每个专业方向的工作量都不少,特别是要技术负责人来填补这项工作量,就更跨界了。最后还会因为不专业而影响整个项目。 - 技术先进性:永远保持技术先进性,多看论文,有机会就多尝试,即使当前项目不必须用到,未来也会回报给自己的。拿到项目,先去调研下最新的技术和论文。