【项目跟进】如何跟进一个算法项目

背景目标

背景

了解项目的背景，在公司的生态位中作用，能产生的业务价值，影响的业务范围。
价值有多大，影响多大。坑多不多。

历史迭代

了解曾经有哪些方向迭代过，哪些成功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人员撤走）就要很大精力填补，一定要保障人员到位，不然其他人就会很累。
  不存在是某个角度就这么一点点工作，每个专业方向的工作量都不少，特别是要技术负责人来填补这项工作量，就更跨界了。最后还会因为不专业而影响整个项目。
• 技术先进性：永远保持技术先进性，多看论文，有机会就多尝试，即使当前项目不必须用到，未来也会回报给自己的。拿到项目，先去调研下最新的技术和论文。