装饰设计网站模板程序员培训

笔者鼓励致力于从事数据行业的去参加一些人工智能，机器学习的培训，然后有人说：其实很多企业不喜欢培训出来的人，认为培训不贴近实际，纸上谈兵。

我倒不这么看，其实即使在企业内干数据挖掘的人，很多也出不了活，这个不仅仅涉及业务和技术，更是管理上的问题。

任正非说，华为最后能留下来的财富只有两样：一是管理框架、流程与组织支撑的管理体系；二是对人的管理和激励机制，什么是流程化组织，简单的说，就是基于流程来分配权力、资源以及责任的组织。

为什么这么说？

笔者的粗糙理解就是：好的做事的方法，靠人的口口相传是没有用的，写成书也是没人看的，只有把这些东西固化到企业的生产流程中去。

你要干活就必须遵循这个流程，才能让这些方法成为企业的基因，无时不刻发挥出其应有的价值，阻止突破底线事情的发生，流程让新人做事一开始就站在巨人的肩膀上。

创新型的公司往往是传统流程和机制的破坏者，但当初公司在建立这些流程和机制的时候，其实符合当时的大多利益，而且这些机制和流程确保了企业最基本的利益，所以后来要被颠覆，只是因为跟不上变化了而已，绝不是说机制和流程本身就是个问题。

可惜的是，对于数据挖掘这么复杂的、不确定性的工作，我们竟然很少去制定符合其特点的相关的流程和规范，有些数据挖掘美其名曰立项建设，大多采用放飞的方式进行，失败是大多数的，投资浪费是很多的，偶偶的亮点不能说明问题。

数据挖掘工作定义的六个阶段，业务理解、数据理解、数据准备、模型构建、模型评估、模型部署，被大家简单的理解为纯粹的技术步骤，从来没想过这些阶段跟管理有什么关系。

但正是管理的缺位，导致大量的数据挖掘工作事倍功半，新人来到一个团队，历经千辛万苦作出的东西，往往一文不值，这到底是新人的问题还是团队的问题？

数据挖掘工作其实根本不可能靠闭关三日来给出什么惊喜，这是为实践所证明的。

如果你是一支数据团队的管理者，改变不了整个企业的环境，比如数据驱动业务的思想，公司的政策等等，但应该在你的职权范围内，在有限的资源条件下，用更好的管理手段让数据挖掘工作变得更有效。

最近，我跟团队正在思考拟定数据挖掘的管理流程和规范，共5个关键节点，希望新人做的数据挖掘工作，能够按照规定的流程走，从一开始就能站在一个较高的起点上，并一直处在一个较为正确的方向上，直到成功或者快速的失败。

 

一 需求分析

团队大了，工作多了，每个人的自由权就相对大了，这个时候团队就要明确一些做事的原则，什么样的数据挖掘可以做，什么样的数据挖掘不要做，这个不能靠拍脑袋，以下给出了4个原则，如果不满足就要退回：

1、公司或部门重点工作（比如OKR）、领导安排的重点需求、日常运营分析和一线反馈的重点需求，杜绝不计原则的去接收挖掘需求，数据挖掘不是买菜，要耗费企业最珍贵的数据分析或挖掘资源，少而精是原则。

2、判断是否已有相关模型或标签满足需求，有则推荐现有模型和标签，如果有相关模型或标签但无法满足现有需求，则需优化原模型和标签，这其实也是数据治理的要求，很多挖掘其实是原来做的不好或者未有效推广，不能重复造轮子。

3、双方明确数据挖掘目标，初步评估技术可行性及大致所需工期，包括度量成功的指标（精确率、召回率）、定义成功的基准（小样本验证、AB测试等），业务侧可能的主观评估标准（覆盖用户数、纳入业务生产流程）等等。

4、联系业务方明确验证方案，如果对方无法承诺验证环境，比如政策和外呼资源等等，则要特别谨慎，根据经验，由于配合不到位导致的模型延期上线或者失败的案例比比皆是，究其原因，还是因为业务方不够重视或者级别不够，调动不了相关资源去推进这个事情。

除了以上原则，我们还制定了升级领导的原则，包括与业务方无法在目标上达成一致，实施周期超过XX人天等等，这些都是为了制止盲目的开启一个数据挖掘课题。

 

二 方案设计

这一过程看似简单，有些人甚至只是脑子转了下就仓促跳过，但很多建模失败就栽在这个阶段。

在方案设计阶段要善于换位思考，承认自己的认知有限性，始终想着如何才能获得最强的“业务大脑”和“数据大脑”来帮助你更好的理解业务和对应的数据，包括三个方面的工作：

1、明确所需数据及必要的特征：对于较为复杂且重点课题，一般都要组织相关利益方开展头脑风暴，集思广益进行特征的有效选择，大量的数据挖掘工作失败在于建模者仅凭自己有限的业务知识和有限的调研（包括有限的通识理解，特别是不谙世事的新人）就仓促选定变量，然后直接跳到自己以为擅长的数据建模阶段在调参上耗尽心血，最后事倍功半，代价不可谓不大。

2、明确所需模型及技术实现步骤：一般跟着经验走就可以了，关于技术实现步骤相信每个企业都有自己的经验做法，比如我们就发现随机森林在很多情况下好用，新人不清楚就问导师，这一步其实是比较简单的。

3、进行方案设计的汇报：要向利益相关者及你的领导汇报方案，领导可能技术上不如你，但人生经验比你足，业务视野比你开阔，拥有的资源比你多。

因此，要努力争取到他的看法，领导支持你去做这个事情不代表他就支持你的设计，不要试图跨过领导等有了建模结果后再向他汇报，因为一旦结果不好，领导的团队成本已经花出去了，他不看好你的设计方案可以直接说NO，你要给他这个机会。

 

三 建模开发

这个阶段大致可以分为三个子过程：

1、宽表开发及数据预处理：谁都知道这个步骤，大家都喜欢建立自己的宽表为自己的数据挖掘服务，但如果你对企业的数据资产局理解不够全面的化，就会在宽表处理上重复造轮子，效率很低。

因此，对于数据资产的全局掌握进行定期的培训和考试是有必要的，很多人做了好长时间数据挖掘却对于融合模型不清楚，这是管理上出现了问题。

2、模型基线开发及训练评估：参数调优、交叉验证、效果评估都是需要反复进行的过程，但如果发现难以达到满意的结果就不要一路走到死，召集相关人员进行一次技术讨论是非常有必要的。

4、模型和标签上线发布：模型和标签上线要遵循严格的标准，包括是否满足当初设定的技术指标要求，是否满足数据治理要求，是否满足运维性能的要求等等。

 

四 试点验证

1、效果验证：跟功能开发不同，模型上线不代表就结束了，因为实际的生产环境跟你的训练环境会有很大的差别，你需要协调业务方按照当初的承诺尽快的进行效果验证，这个时候你要承担起连接者的角色，推进各方尽快反馈生产的效果，如果无法达到当初的设定目标，就要考虑重新优化模型，试点推进不利很多时候是业务方的原因，比如外呼排期延后等等，这个时候就要推动领导协调。

2、试点汇报：一旦达到要求，就要组织业务方和自己方的领导进行汇报，明确模型是否具备全面推广或纳入生产的条件，这个涉及到业务方相关政策和资源的配合，不是简单的模型的问题。组织这种会议其实是向各方领导表明，我已经完成了任务，但要让这个模型产生价值，接下来你们得给我资源配合完成剩余的非功能性工作，好的模型最后不了了之往往是沟通出了问题，业务方的领导跟你的领导很多时候信息是极度不对称的，你要干成事情就得多做协调的事情。

很多试点的结果并不理想，汇报的另一个目的就是及时止损，一方面是由于市场变化很快，总有意外的情况发生，另一方面是现有的模型的确达不到业务要求，你不能被一个看似无前途的事情拖死，你需要领导帮你做决策，继续干还是放弃。

 

五 总结汇报

1、你要跟踪模型的生产运行效果，及时发布运营报告，让你的领导和业务的领导知道你干成了这个事情，很多时候，试点的效果很好，但一旦纳入生产情况并不理想，因此要持续的跟踪一段时间。

2、如果模型的效果保持稳定，则可以将其移交给统一运营团队（如果有的话），代表你交给公司的是一个可用的模型，从而进入常态化运营阶段，这个时候自己才可以全身而退。后续如果运营团队发现模型有问题，可以向你提交优化需求，由此迭代。

数据挖掘最怕的就是只管杀不管埋，比如训练结果很好，但其实试点情况很差，试点情况还好，但生产情况很差，开始生产的时候还行，但持续一段时间就不行了。

模型师一定要记住，模型的上线绝对不是你工作的终点，而仅仅是起点，只有模型进入稳定的生产阶段以后你才算完成了工作，大量的外包数据挖掘工作所以失败，就是因为他们把数据挖掘工作当成了简单的功能开发。

你会发现，笔者从需求分析讲到总结汇报，都不在谈技术，而是在谈管理，我在谈进入每个阶段时要采用的质量控制的手段，其实每个阶段的周期也要控制，一般来讲，如果某个阶段超过了二个礼拜（可以根据企业实际调整），就要反思和对外暴露问题。

根据以上的内容很容易就画出数据挖掘的管理流程，可以贴在墙上成为军规。当然每个企业的情况不同，流程可能不一样，但一定要沉淀出这种流程，它们保证了基本的做事的效率，不会由于人员的变动而导致效率的下降，这就是任总所说的流程化组织要干的事情吧。

这是我最近的一点思考，大家一起加油吧。