一、概述
写此文的出发点，一部分如README所述。
另一部分，随着数据规模的增大和计算能力的大幅提升，深度学习的爆发带动了机器学习这个领域的大踏步发展，再加上Google、Fackebook等众多公司的“争先恐后”的花式开源动作，大大降低了机器学习这个领域的门槛，使像我一样的毫无相关背景的人，也能很快入门，并在自己的业务领域内,快速完成了特定任务的模型训练与项目交付工作。
工程落地我们需要面对的问题
学习新知识的过程，基本上都是：“以为懂了 --> 知道不懂了 --> 开始懂了 --> 还是很多不懂” 这样一个我们称之为“螺旋上升”的过程。对于深度学习这个“边缘”技术领域，尤其是在项目落地的过程中，随着理解的加深，越来越觉得这种交叉领域的技术转移到“软件应用”层面时，对每个参与个体、团队的综合要求是非常高的，表现在：
难以解释性
深度学习的不可解释性，如何向“普通人”“通俗易懂”的解释算法不准确、以及为什么会导致不准确问题，是一件比较困难的工作（比如图像分类的修改像素后的分类错误）。因为其内在机理的不透明性，很难用“别人听得懂”的语言给出令人信服的解释，在一定程度上会带来一些沟通的困惑与障碍。
概率问题
传统软件层面的算法，输出对输入的结果始终一致，所以可以放心将算法嵌入“业务流程”，作为业务流程的一部分，甚至是关键业务流程的判断依据。而机器学习的结果是一种“预测概率”，这种情况下，如何和业务流程结合，同时又能“规避”错误导致的问题，即使只有0.1%的错误率，在关键业务环节应用，也是高风险的。
怎么落地、在哪落地
现阶段用户对于机器学习可以解决什么问题，以及对于机器学习有哪些“明确”的“应用需求”，这件事还是不明确或者说不乐观的；而“炼丹师”、产品经理也非用户业务领域的专家，对于如何才能用最合理、安全、准确的方式将机器学习引入用户业务流程这样的问题，更是很难给出准确的方案，这中间的“认知鸿沟”目前看还是不小的，这应该是“落地难”的一个重要原因。
期望落差
阿尔法狗围棋大胜、图像识别领域的准确率超越人类表现水平、AI玩游戏也大胜等等，诸如此类的新闻稿、标题党，通过各种APP推送到每个人的手机，大幅度的提高了“用户”对于机器学习的“认知期望”。当特定任务的算法落地使用后，对于“炼丹师”来说，出现错误在所难免，业内对于“错误”是有容忍度的。
但是对于无限拔高了期望的用户来说，你都超越人类表现水平了，我一眼都能看出来这不对，你这就是“人工智障”。更不幸的是，媒体怎么会错过这种博眼球的新闻？
过拟合问题
针对特定的数据集，在训练过程中，已经有了非常多的“技巧”去平衡方差和偏差的问题，最终在测试集取得“State-Of-The-Art”的效果。不论我们的training set，test set数量多巨大，也符合我们直觉上的正态分布，但是，有一点是不可忽视的：相对于现实世界的各种场景，我们的training set始终都是一个子集，理论上是难以覆盖所有现实世界场景的。
换句话说，在理论层面没有巨大突破的情况下，我们的训练过程实际上相对现实世界的多样性，是Overfitting了training set+ test set的，那么自然会出现模型在现实世界使用的时候大概率的会出现“高方差”的问题。
工程/项目经验
PMBOK(Project Management Body Of Knowledge，项目管理知识体系),是世界项目管理领域公认的关于涉及项目管理的知识要点的系统性集成，提供了完善的项目知识体系，再结合企业/团队在项目实践中总结出的方法论去执行，结果是可预期的。
对于不成熟的软件产品项目，失败或者延期的风险是相当大的，有一本对我思维方法有非常重要的影响书，推荐给大家读一下：死亡之旅。在“传统”软件行业，有一句话人人皆知：“三分软件，七分实施”，没听过这句话的，可以自行琢磨下含义。当我们在ML项目交付过程中，又新引入了“ML模型”这个“X因素”，可想而知，这样的项目实施交付难度必然会更高的。
难在哪里呢？拿应用最广的人脸识别项目举两个例子。
例1：不是像高铁站的“人脸闸机”一样，约束检测目标主动对着摄像机直到识别完成，才会开闸放你通过，而项目需要在高点架设监控摄像机（比方说写字楼大厅、车站码头机场接站口），然后在视频流里做人脸识别。做“人脸”的同学们，应该会想到几个问题吧：大倾角、遮挡、可能的逆光、还要考虑去重等。
例2:宁波行人闯红灯的“人工智障”新闻估计大家都看过吧，不知道的可以Google下，或者看看下面这张图。
把公交车的车身广告的“董小姐”识别为了闯红灯行人，然后现场还有大屏展示，于是，这个错误就“火了”。那么，这种“误报”的“锅”该甩给谁呢？
算法团队：产品没有提“活体”检测的需求，这是“非约束”场景，视频流有人脸，我检测到了，锅不是我的；
产品团队：用户需求是检测行人闯红灯，我哪里知道还有车身广告这档子事，你们算法团队就不能检测下这个人脸是不是“活体”的人脸么，要不加个目标检测，协同过滤下公交车这种情况呢？
项目交付团队：产品说的对。
领导：对什么对？你们在现场测试的时候，为什么没有发现这个问题，你们的测试用例完备么，你们的边界条件定义合理么？测试的，不要在旁边笑，也有你们的份。
大领导：说了半天，有解决方案么，是让你们做“产品”，不是做“玩具”，给你们三天时间搞定。
希望你能会心一笑，这个例子，后面还会继续说，暂时到此为止。
上面这六个问题，正如上面的这个例子一样，项目团队的每个人都可以找到合情合理的理由，把自己“摘”出来，但是，我们的目标如果是“推进AI项目的工程落地，并实现客户预期的目标”，那么这些问题就不是某个个体的，而是整个团队需要思考解决与应对的。个体遇到困难，干不下去了，可以辞职，可以请假；团队呢？公司呢？所以，有些事情，我们选择去做了，就要当做没有退路的去做。
当然，我们需要面对的问题显然不止上述几个，下决心写此文的目的就是想把个人对这些内容的一些思考分享给ML社区。
内容概述
在构思本文大框架的过程中，有过不少挣扎，但比较明确的两点是：
1 - 这不会是一个深度学习框架、训练、调参等技巧的最佳实践介绍文章；
2 - 这不会是一个深度学习所涉及的理论、论文、数学知识等方向的解读、介绍文章。
为什么这两点是明确的？原因是令人沮丧的：我并不认为我具有这样的知识储备，可以在整体层面介绍深度学习的方方面面。
所以，我只能从我擅长的方向着手。
对于想学习这两个方向内容的阅读者，第一个问题可以去看看Andrew Ng的：Machine Learning Yearning，短小精悍的一本书，所有内容都是“炼丹”干货。第二个问题，建议去找找各种 MOOC 资源，免费的太多太多了，不怕没得学，就怕时间不够。另外，对于英语不好的同学还有个温馨提示，如果 MOOC 资源没有中文字幕，可以看看视频资源是否存储在 YouTube上。Google 的语音转文字和机器翻译水平已经是State-Of-The-Art了，而且此类视频资源估计是提了权重，我看过的，到目前为止还没有发现没有完成字幕机翻的。
所以，我的初始目标或者说努力的目标就是，能够尽量覆盖深度学习项目/产品在 to B/G 领域，工程化落地过程中的除了上述 2 条的方方面面。比如：项目的生命周期，团队成员之间的分工与协作，产品经理需要考虑的事情，数据准备，部署的一些建议及项目交付的项目管理等等。
具体参见下面的章节介绍。
章节介绍
除本节概述外，初步的想法是通过十个章节的内容，能够较全面覆盖深度学习项目落地的方方面面，但不排除在过程中突发奇想的调整。
您正在看的就是这一章。
本章会重点关注引入了机器学习这个“X因子”之后的项目，与传统的软件项目存在的差异，以及我们如何去定义自己的项目过程是比较合理的。
本章会对团队中的角色，分工以及如何合理的协作，做一些说明。由于协作这个过程应该是事件驱动的，所以在后续章节，对于需要协作的部分还会给出建议。
产品经理是一个非常难做的工作岗位，好的产品经理对于综合能力的要求近乎于是无上限的，不是千里挑一也是大几百里挑一。因为一本书，好多同学进了选了个方向，做的大多都是“原型绘制经理”的工作，独立思考和思辨能力不足，只能去像素级抄友商或者听领导“指示”，然后熟练的用“原型工具”画出来原型图提交讨论，所以是“原型绘制经理”。
当在引入“X因子”后，对于产品经理新增的挑战又有哪些呢？这是本章会重点探讨的问题。
“售前”与“解决方案”这是to B/G 软件领域内的通识用语，很有可能有些同学没有听过这两个词，所以先简单解释下。
“售前”全称应该是“售前咨询”或“售前顾问”，要说来源，我的理解是从“管理咨询”这个领域延伸过来的。
那么“售前”要做什么事情呢？当销售了解到客户有采用某软件或者某方案的需求，而这种软件或者需求恰好你所在的公司现有产品可以基本覆盖，或者绝大多数覆盖。那么销售会先和客户接触，了解更具体明确的软件需求或者方案要求，当然还有预算、项目周期等等，这些和技术体系关系不大，就不展开说了。
了解到需求后，销售会和产品经理或者售前咨询顾问（不一定每个公司都有这个岗位，但不管具体岗位什么名字，只要销售找到你了，基本售前这件事就要找你解决了。）去说明客户的需求，并会共同讨论：公司产品的契合度，以及缺什么，然后讨论确定一个初步的针对客户的售前阶段的售前咨询方案。老销售或者由顾问转到销售的，由于经验丰富，对公司产品也熟悉，可能就会直接说结果，提要求了。
之后，接了这个任务的同学，会根据商量的结果，先做PPT，然后销售会安排去给客户做售前介绍，如果产品成熟度高，还会同步做产品演示。依据客户的不同喜好及销售的水平和关系建立的情况，这个过程可能会多次，也有可能只有一次。
所以，去介绍的时候，一定要嘴巴，脑袋，耳朵，记性，一样不少的都带上。
然后会按照“售前咨询”阶段方案介绍收集到的信息，出一个Word版本的文档，这个文档就是针对客户需求的“解决方案”。如果一切顺利，那么下面就是投标、中标、签合同，然后项目就要正式启动了。
好的开始是成功的一半。本篇预估篇幅较大，能想到的方方面面的问题，都会给出一些行动建议。在项目启动阶段，最重要的几件事情是：
1 - 厘清项目需求，梳理出来最关键的：功能需求、性能需求和ML需求，以及ML需求和功能需求的关系（是否强关联，耦合度很高）；
2 - 确定基准。对于ML需求，如果有可参考的“State-of-the-art”则最好，如果没有，则找类似任务的当前最优，了解关键指标；
4 - 了解部署要求，现在一般B/G企业早都完成了私有云或者信息中心建设，部署都是在人家分配给你的机器上进行，裸机还是虚机，允许Docker部署不，CPU还是GPU，CPU什么型号，能给你推理用的最多核数等；
5 - 已经了解的关键ML指标，判断用户提出的性能需求，是否可以满足，如果不能，差多少，团队头脑风暴下是否有解决希望；
6 - 部署的要求一定要问清楚！！！千万不要乐观的认为弄了个ResNet-152满足准确性指标，就万事大吉。推理服务器GPU给你就那么多（或许只有CPU），内存也不多，准是准了，但是慢了好多，怎么办？
7 - 数据集收集之前一定要派有经验的人去看看，部署上线后的实际场景（尤其是 CV 项目）什么样，千万不要在起跑线就摔一跤；
8 - 我们都知道为了平衡准确度和召回，一般都用“F1 score”评价算法整体表现。但是，千万不要教条主义，理解清楚真实需求的精度指标是：“查准优先”还是“查全优先”。
9 - 最最最重要的是：先弄明白一件事“如果算法出错了，后果是什么”、“如果算法出错了，后果是什么”、“如果算法出错了，后果是什么”，这个必须强调三遍。
如果，结合这个事情，能想明白为什么会扎堆的用“人脸”创业，为什么现阶段落地最好的也是“人脸”相关的应用。那么，恭喜你，起码你已经明白了如何去规避项目风险，以及技术成功和商业成功的基本关系。
对于ML，有一个概念比较基本但很重要，也容易被忽视，那就是：“训练数据，权重，超参”实际上是一体的。
所以，我们不但要关注训练数据采集的正态分布和与生产环境的一致性，还要做好数据版本管理，以及后续训练的权重、超参的一体化版本管理。只有这样，当我们在生产环境做测试后，发现整体性能指标还不如test set的话，那就要把错误数据拿回去好好分析了，分析什么、怎么分析不知道的话，罚抄Machine Learning Yearning三遍！
我是不会告诉你我就遇到过test指标看起来最好的，放在生产环境测试让人意外，然后丢了一个test第三好的model 到生产环境测试，结果比test第一的准确率还高这种事。
八、训练与调试
接上一章，建议是要做好训练数据，权重，超参一体化的版本管理工作，多轮“炼丹”之后，可以放在一起横向比较。另外就是，如果迫不得已必须人工合成数据，给数据集扩容，千万要保护好原始数据。硬盘真的不贵，哪怕就是放云上OSS也不贵，raw数据集脏了，真的哭都来不及了。
另外，如果训练数据收集的数量比较大，刚开始主要是做大方向验证，不要一下子上全量数据开始训练，小数据集来一轮浪费的时间少，小数据集能优化的不错了，偏差接近甚至超越基准了，全量数据上去，这个时候才是看计算资源的时候，资源多就能多尝试超参组合。
至于这个阶段的DL框架选择，如果熟悉Keras，那就Keras+TensorFlow；如果人手紧张，每个人任务都很重，还要赶进度，还是建议Keras+TensorFlow 。
如果对PyTorch熟悉，那就fastai+PyTorch，个人感觉，现阶段在“快速炼丹”，或者搞点突发奇想、稀奇古怪的东西去尝试，这套组合是最方便、也是代码量最少的，TF2.0还没用过，但愿正式版发布后，能比现在开发友好大进一步。
考虑到部署与生产环境的支持，至少在现阶段还是要选TensorFlow，在生产环境完备性上，PyTorch还有一段距离要追赶，不是很理解的同学可以看看TensorFlow Extended (TFX) 这一整套的轮子用起来起嘛不会踩坑太多。
九、模型部署与测试
由于 ONNX Runtime 的出现，使得Model Serving这件事有了更多选项，此外，CPU推理的话，Intel 也提供了预编译的TensorFlow等多种部署模式选择，真是一个丰俭由己的好时代啊！
另外，如果不是用分布式的GPU推理的，个人不太建议选择TensorFlow Serving这个方案，略重了。
生产环境的测试，如果可能用户也愿意把数据给你，那在开发环境下能做连续测试，是最理想的情况，在去交付客户前，以及对系统整体表现有了基本判断。如果必须要在现场做部署后的验证测试，那么就给自己留足缓冲时间，不要憋到最后都憋出内伤了，才去现场部署，部署后发现ML效果不尽如人意，项目经理哭都来不及啊！
十、机器学习的DevOps
前面章节已经说了，我们需要考虑训练数据，权重，超参一体化的问题，那么是需要考虑一个针对机器学习领域功能完备的版本管理的方案与平台。
另外还要考虑的事情就是，如果我们的业务应用已经实现了DevOps 的全套自动化的 Pipeline ，那么我们的 Model Serving 如何能实现与之匹配的Pipeline？ 毕竟，没有哪个运维人员能接受业务全自动，推理全手动的更新迭代。
十一、项目交付
在前面的问题中已经说了“三分软件，七分实施”这个问题，所以，本章会详细介绍一下项目管理的相关知识与交付的一些通用策略（套路）。
对于项目交付，我过去在不同场合做项目管理培训的时候，说的最多的一句话是：“项目管理，就是一个先找怎么死，才能有机会比较舒服活着的过程”。
“找怎么死”：就是把项目的所有风险点尽可能早的“识别”出来，千万别忘了“干系人”也是一种风险哦，然后做好“风险管理”，逐步释放风险、解决风险和有技巧的规避风险，最差的情况下，也要能做到：给关键风险陆陆续续的降级。思考一下：
在项目早期，发现之前有一个“不当”的“非关键承诺”，在理论层面都很难实现，做为项目经理，你准备怎么办，怎么应对这个风险？
我会在本章节的正文中来解释具体的处理思路。
“项目管理”单独就是一个很大的题目，PMBOK V6 700多页，十个知识领域，五个过程组，共49个项目管理过程。这么多的内容，写出来一个篇幅规模不小于本文的文章也不是什么难事。所以，项目交付这一篇，也会着墨较多，目前考虑会在PMBOK中选一些我认为最重要的东西拿出来解释下，另外就是结合个人的项目经验，说一些你在“正统”项目管理书籍中很难看到的“技巧”。
如果恰好你对项目管理感兴趣，看目前进度规划，等到写完这章估计就是一个半月以后的事情了，怎么办？没关系，给你推荐两篇2007年我在一个论坛的连载文章，论坛不声不响的下线了，用了“网络时光机”找回来放在了知乎上。
进度安排
当我把目录列出来之后，把自己也吓了一大跳。
原估计就是一到两周，写个三章就能完成的事情，现在看来，这件事变成一件大工程，但是既然决定开始了，我还是会尽全力去完成的。
初步计划是：花一到一个半月的时间，完成Draft版本，然后再花一到两个月的时间去修改、润色、调整以及改错别字。
所以暂定每4天左右更新一章，如果有关注的同学，可以按这个节奏过来刷新看看。
PS：目前已经严重延期，具体原因就不提了，争取尽快完成。
Last updated
