全文共2146字，预计学习时长7分钟
来源：Pexels
2016年11月3日晚上11:35，我坐在多伦多市中心贝街的会议室里，盯着街边空荡荡的办公室。房间的灯变暗了，电话亮了。我收到了三条提醒。
· 10小时后的执行方案陈述。
· 打电话给杰西。在12小时内发送最终的婚礼安排细节。
· 去机场。在18小时后飞往香港举行婚礼。
“该死，该死，该死！”
我轻敲键盘；笔记本电脑打开了；弹出一个数字。还是不行。我该如何解释预期转化率下降了35%的原因？
我拿起电话，打给西蒙，一位会在汇报时支持我的同事：“来计划一下损失的控制方案。”
“嘿，你在想我们的婚礼吗？“我可爱的妻子杰西问道。
我一下子回过神，今天是2019年11月5日，我要结婚了，但我因为机器学习项目的事的确忘了结婚这件事……但我永远不会忘记这一天。
该死的，塞巴斯蒂安
我喜欢关于机器学习的成功故事。
但是，残酷的事实是：大多数机器学习项目都失败了。
来源：Pexels
许多项目失败是因为人们试图用机器学习解决错误的问题；有些失败是因为人们没有对最后一公里问题、工程和组织问题给予足够的关注。还有一些失败是因为人们觉得数据科学很无聊，因而对此不再关心。
剩下的失败，就像我承认的，是因为项目管理不善。
如果要从这次经历中吸取一个教训，那就是：不要太过于敏捷。
这一切都是从塞巴斯蒂安·特龙的图表开始的。
这是我最喜欢的机器学习工作流程图，部分原因是塞巴斯蒂是用电脑书写板书写流程图中最好的那一个。
但是，有一个重要的细微差别一直被我忽视。
塞巴斯蒂安·特龙，Udacity——数据科学导论，最好的在线课程！
我的无知，细微差别，以及所发生的一切
首先，我必须承认自己的无知。我是敏捷方法的天真倡导者，因为瀑布模型是如此老派、不合时宜。
和我一样，许多人可能听说过敏捷：迭代允许人们进行快速学习、测试和失败。（而且，人们通过节省纸张编写技术规范来减少树木的砍伐量，而这些技术规范没有人读，并且在早期项目中可能是错误的）。
细微差别。不应该有箭头指向问题和评估（绿色和红色文本）阶段。敏捷的迭代原则不适用于定义核心问题和评价指标的阶段。
核心问题必须尽早明确表述。然后，必须立即考虑子问题（见假说驱动问题解决方法）。它们有利于：
1）识别好的特性想法并推动探索性分析；
2）规划时间线；
3）决定每个敏捷迭代应该关注什么，必须根据核心问题仔细选择评价指标；
这次，由于无法认识到自己的无知和机器学习工作流中的细微差别，导致了3个致命错误。
错误1：由于对核心业务问题的错误定义，目标变量被中途更改。这导致了数据泄露，破坏了模型性能，不得不重新对约35%的代码库编码，并花费约2周时间重新尝试不同的数据转换和模型架构。那是一场噩梦。
错误2：优先考虑了低影响的特性，因为子问题没有考虑清楚。好吧，其中一些功能是创新的，但回想起来却没有用。这浪费了宝贵的开发时间，而这些时间在时间有限的咨询环境中非常重要。
错误3：更改了评估指标。必须重新设计模型架构，并重新运行超参数优化。这需要新的测试用例，不得不手动运行许多回归测试。
所有这些错误在客户体验、团队士气和时间安排上都产生了很糟糕的影响。最终，导致了我婚礼前夕异常紧张。
来源：Pexels
变得更聪明
这样吧，公平一点。我确实断章取义地接受了塞巴斯蒂安的建议。他是机器学习最好的老师（对不起，吴恩达）。
塞巴斯蒂安的工作流主要是为实验性的机器学习项目（例如商业智能或洞察）而设计的。对于像以工程（engineering）为中心的机器学习项目（例如，全栈机器学习系统），工作流应该根据软件工程和产品管理的最佳实践进行优化。
以下是我对敏捷与否的看法。对于限时咨询或内部原型项目来说，这一点尤为重要。凡事都没有完美的方法，所以不要做过了头，要明智地应用。
敏捷
•开发数据功能
•模型架构开发
•设计和开发面向用户的用户界面（如仪表板、Web界面等）
•设计和开发持续集成和持续交付(CICD)测试用例
不敏捷
•如果最终消费者是人，则为用户体验；如果最终消费者是系统，则为集成模式和协议
•核心问题、子问题的定义，以及顶级特色创意列表
•目标变量的定义（不惜一切代价避免变更。但如果业务需求发生变化，锁定CICD管道对捕获数据或软件错误非常有帮助。）
•评估指标
•管道：数据到模型以及使用DVC的CICD
•基础设施：集成模式、服务层、关键数据库和硬件平台
到目前为止效果很好。
回到文章开头，能够清晰地表达核心问题并导出分析、特征思想、模型选择对项目的成功至关重要。好东西不一定适用于各个场景，矛盾辩证法中“具体问题具体分析”的思想还需时刻牢记。
这样才能大大减少“翻车率”。
留言 点赞 关注
我们一起分享AI学习与发展的干货
欢迎关注全平台AI垂类自媒体 “读芯术”
（添加小编微信：dxsxbb，加入读者圈，一起讨论最新鲜的人工智能科技哦～）
