2. 数据收集
事实上，现阶段的深度学习还是在比拼数据集规模的阶段。这一点，AI 创业公司是能够理解的，但是对于转做深度学习的软件公司来说，可能有一个误区：“下一个开源数据集不就好了么？干嘛还要自己去准备数据集，费时、费力还费钱”。
一方面，对于政企领域的特定任务来说，大概率是没有特定的开源数据集的，恰好有，那也非常小，可以拿来搞搞研究玩玩，但是想做到“生产就绪”，数据量是远远不够的。举个例子，给你一个中文语音到文字的 NLP 任务，去找找中文语料库看看够用不。
另一方面，恰好有比较大的开源数据集，比方说“人脸”这么热闹，数据集不少，还有 FaceNet、DeepFace、DeepID，是不是找两个程序员就可以做出来和“独角兽们”一样的“人脸”了？嗯，我也尝试过（匿了，匿了，说出来好丢人）。但是，“独角兽们”不会告诉你，他们用的数据集，比开源数据集，高一个数量级起步。再比如，人脸特征点，Dlib 好啊，68 点看起来不错把，唬唬行外人妥妥没问题，也有个小哥做了一个 81 点的放出来，你以为这就是 State-of-the-art 了？现在人脸特征点是 96 点起步，做到 128 点出门才好意思跟人打招呼，196 点才能算是现阶段“比较领先的水平”。嗯，196 点是有个 Helen dataset，training + test 一共 2330 个数据，研究可以，商用想都别想。
开源一代，自用一代，研究一代，这句话真的没有错。在这里建议从各个领域拥抱 AI 转向 DL 项目的的兄弟们，一定要给 Boos 说清楚数据集这件事。
2.1 指标验证
为什么还没有数据集，就要先验证？实际上，这个工作，在我们在评估基线和定义项目指标的时候，就应该同步开始去做了。毕竟项目不是莫名其妙从天上掉下来，在项目前期准备过程中，对于这个特定任务显然已经明确，也会准备一些数据做可行性验证与演示用的 Demo。
这个阶段做的验证工作，真正要解决的问题是：
用小数据集，利用经验去评估指标实现的可能性和代价；
通过误差分析（再建议一遍，不知道误差分析怎么做的，去看 Andrew Ng 的 Machine Learning Yearning）明确数据采集的策略和要求；
基于误差分析，“炼丹师”仔细评估数据集，看看有没有可能在数据质量，标注上做点工作；
基于小数据表现、经验、任务难度以及数据集采集难度，估算数据集规模；
2.2 数据策略
上一步已经基于指标验证工作，对数据集的规模、采集要求、标注有了初步结论。那么就需要对所有的数据可能性，给出足够范例，然后项目经理明确对外包团队的数据要求、标准。当然，好多 AI 公司现在都有自己的数据标注团队了，这个事情做起来会相对靠谱的多。
另外还有一点需要注意的就是，对于 CV 类的图片数据采集，一定要和生产环境使用的场景基本一致，不要为了凑数据数量而忽视了质量。
2.3 数据采集
这个暂时不多说，按照给出的范例去采集就好。
2.4 数据标注
这就是个体力活，主要就是做好培训，然后就是早期多检查“Turk”的工作，确保标注准确性和符合要求。
2.5 数据管理
此外，还有一个重要的事情是做好数据集的管理工作。一方面是保证数据安全，不能丢，更不能莫名其妙就泄漏出去。另一方面要有一个比较好的数据集管理策略，raw 数据怎么管，标注后的怎么管，怎么做数据增强，数据集和训练数据怎么关联，毕竟“炼丹”遇到大麻烦，还是要回来看看数据集的。
有关数据收集更多的内容会在第七章做更详细的解释。
3. 训练与调试
训练与调试，这是做深度学习的基本功，这些做不好还谈什么项目落地，本文的定位是介绍项目落地相关的工作，这部分内容按理来说可以不关注。但是考虑到作为一个项目整体的一部分，训练与调试的目标是项目交付，而不是搞科研、发 Paper，过程中关注的侧重点与思考方向会有所差异。
3.1 模型的 MVP
MVP(Minimum Viable Product) 是产品经理非常熟悉的一个概念，为什么在已经做了指标验证的情况下，还要提出用 Simplest model 去做 model 的 MVP 呢？
如果项目的任务是我们非常熟悉的领域，对于数据集、model 选择、超参的经验值等这些都非常熟悉，那么可以忽略这一步工作，但是如果是一个从未做过的全新任务，那么“强烈建议”从这一步开始做起。选一个较小的数据集开始验证想法，一般把这种数据集叫做“Eyeball 开发集”，起步用一个“AlexNet like”的模型就可以，主要的任务就是能方便我们验证想法、思路，并做好误差分析，最终目标是确定一个可以 Work 的思路。
3.2 验证模型
在上一步，我们通过 Eyeball 开发集，完成了误差分析，也确定了 model 的方向，从我们的 training set 中取一部分数据出来，用小一点的数据集做模型验证工作。具体这个数量是多少，因该按照具体任务确定，如果是简单的 CV 任务，我们要做的是 fine-tuning 工作，一个分类有 100～200 个样本应该就够了。这个阶段在关注精度的同时，也要同时考虑部署后的推理性能问题，避免解决了精度的指标而导致推理指标大幅超过目标值。
用较小数据集做验证还有一个好处，可以用较短的时间完成一轮训练，那么就可以晚上让机器干活，白天我们根据结果进行调整，既不耽误时间也不会过多抢占 GPU 算力。
验证阶段，解决了偏差问题，那么可以用全量 training set 开始训练了。
3.3 模型训练
在之前提到过，对于 model 来说，是训练数据，权重，超参一体化的，为了更好的调参、优化，在训练阶段我们需要有适当的工具做好相关内容的管理与记录。
3.4 模型优化
在优化方向的选择上，一方面我们要做好误差分析工作，另一方面要对误差的优化难度和优先级做好评估工作，其实就是一句话：在误差占比高的方向选择“成本、难度、时间”综合最经济的，先做优化。
另外，对于模型精度的选择。查准和查全，不同的任务，不同的应用场景实际上要求是有区别的，不能用固化的思维去看待这个问题，只看 F1 score 来确定模型是否使用。还是拿“人脸”举个例子。
假设我们训练完成后，排前两名的 model 在 F1 score 上相差不多，但是恰好 A 查准精度高，B 查全精度高，如何选择呢？安全的选择肯定是 F1 score 那个高用那个，用理论支撑的工具做的选择，出了问题没责任。但这不一定是最优但选择，切记，一定要看场景但业务需求。如果是做“人证合一”的验证，业务的核心需求是“准确验证”，那么选择 A 是比较合适的；如果是做“人脸布控”，那么查全就非常重要了，所以选择 B 更合理，误报没关系，但是漏报就麻烦了。同理，大家可以思考下，在“张学友的演唱会”要做人脸布控追逃的话，又该怎么选？
3.5 软件集成
到这个阶段，业务相关的软件开发工作也基本完成了，是时候将 ML 与软件进行开发集成了测试了，Postman 虽能解决集成测试问题，但是早投入模拟生产的集成测试，总是没有坏处的。
有关训练与调试的更多内容，在第八章会做更多的说明。
有关机器学习开发过程中，与软件开发 DevOps 的配合，以及一些专用工具或者软件平台的简单介绍，在第十章。
4. 部署
如果一切顺利，按照项目计划，到部署的时间节点就该去做生产试点部署了。当然了，就算有点不顺利，到了时间还是要去部署。而且，正常情况下，试点部署的时间只会比计划提前，很少会有推后的。你想啊，你小时候过年买了新衣服，是不是也想在年三十之前就穿啊？
4.1 开发环境测试
“谋定而后动，知止而有得”，所以我们要制订完备的项目计划，做好风险管理，知进退才能有期望中的收获。
“不打无准备之仗，不打无把握之仗”，所以，在正式去客户现场部署之前，我们要在内部尽量去模仿一个最终部署形态的“env”环境。有条件、不缺钱计算资源多的公司，建议在开始关注政企市场的项目机会后，在“研发环境”、“测试环境”、“生产环境”之外，从基础设施平台中再独立出一个“交付部署测试环境”。
有人可能会想，在开发过程中，已经做了软件集成及相关测试，为什么要增加工作量，不做这一步可以不？答案是：可以。为什么可以呢？因为只有吃过足够的苦头之后，就会长记性了，就知道这一步的重要性了。
技术从业者是一个奇特的“物种”，讲起理论、概念、方法都可以做到滔滔不绝，各种新颖名词脱口而出，你要想全听懂，要么是专家，要么是全才，要么随时准备好 Google。但是，干起活来，各种意想不到的 Bug，奇葩的错误，诡异的意外，技术储备的欠缺等等情况，都有可能出现，你脑洞再大，也有出你意料之外的“惊喜”：
内网部署，无互联网，依赖拉不下来，没法部署下去；
家里测试没问题，到了现场跑不起来，各路高手轮番上阵排错，最后发现是有个对自家“基础环境”的小依赖忘了部署；
Nginx 负载均衡玩的溜的很，结果用户有硬件负载均衡，还分链路和服务，要求不用 Nginx 用他们硬件实现 LB，前期没问清楚，不会配置，傻眼了；
客户指着地上放的纸箱子说“这是给你们准备的全新服务器，你们自己上架，自己做系统吧……”。什么是 bond，什么是虚拟化，什么是 SAN 网络，我在哪？我要干什么？
在家千日好，出门半朝难。充分演练，充分准备，没有任何坏处。
4.2 生产试点
先试点，再扩大，最后全面推广，这基本是标准规则。所有要动生产环境的事情，就是：小心，小心，再小心。
4.3 测试
最理想的情况是，客户恰好有生产测试环境，那么在生产测试环境做试点部署和测试，是最稳妥的，也是客户肯定会要求的。但是，如果没有生产测试环境呢？那么就一定要做好测试的准备工作，从用例到回滚到风险应对等的全套方案。而且，极其不建议在生产试点阶段的测试做回滚操作，这是增加风险的动作。最好的方式是，先单独测试 ML 部分，不和业务数据联动，ML 部分验证没问题后，再做对接业务的测试，但对数据库是非 CUD 数据测试。
4.4 正式部署
项目走到这个阶段，大家都可以松一口气了。恭喜，恭喜。
4.5 监控
虽然可以松一个口起了，但是项目刚上线，还没有验收，千万不可大意，做好监控工作，定好 Oncall 的排班计划。谁都不希望出事，但是哪里有那么多心想事成但好事啊，做好预案，有了问题能快速解决更重要。
有关部署的内容，在第九章会进一步说明一些注意事项和风险预防与规避策略。
一般而言，对于政企项目，在部署环节开始后，就进入了正式的“交付实施过程”，项目经理在这个阶段压力是非常大的。当然，也有部分 to G 的项目，要求合同签订项目正式启动后，就要项目组进场，“驻场”开发，这种项目对项目经理的能力要求是指数级上升的。
由于国内软件行业传统的认识和人员的选用安排，项目经理、项目交付人员，无论从待遇上还是能力要求上，还是在内部的话语权上，都是相对同级别程序员较低的。事实上，大多公司都存在类似这样的认识：“实施，不就是去现场装个系统，教会客户使用么，有什么难的，干嘛要用那么“贵”的人？”。
但是，实际情况是这样么？我们来看看 ML 的项目经理应该具备哪些能力：
- 情商高。会和人打交道，而且还要具有快速和陌生人建立信任关系的能力；
- 头脑灵活反应快，会说话，敢说话。给领导汇报，能三言两语说清楚；和项目相关方沟通，知道怎么说，能“听懂话”；
- 快速判断能力。很多时候就是要在分钟级的时间单位内对一件事的难度、风险，是否答应，该不该答应等做出综合判断，并给出回复，而且还要不怕承担风险；否则用户就会觉得这个项目经理“不行”，什么事情都磨磨唧唧，什么事情都定不下来，失去信任感。项目经理一旦让客户失去信任感，基本这个项目做“砸”就是高概率了；
- 快速学习能力。面对新进入的陌生领域，要能快速学习客户方业务知识，在需求沟通过程中才会收放自如；
- 硬件、网络等 IT 综合知识。项目经理要在现场协调、沟通方方面面的工作内容，即使这些工作都有专业工程师配合完成，但是项目经理要都懂才能做好沟通、协调工作；
- 对于 CV 类的项目，还要懂视频相关知识，以及工程施工的相关知识，否则人家摄像头给你配个 H.265，你可能取流就要傻眼，摄像头怎么安装位置选择要清楚，POE 是什么总要明白吧……；
- 要有架构、写代码的能力。在客户现场，讨论需求、沟通变更或者和第三方集成，做技术沟通，没有这些基本功，怎么沟通，怎么初步判断工作量的量级？能不能判断出来别人是帮你还是害你？
- 对于 ML 项目来说，还要有基本的深度学习技术相关知识。否则，客户问，速度这么慢，为什么你们不给我们上 GPU？GPU 不是能成倍的加速么。项目经理起码要知道训练和推理的计算量的区别吧，要知道反向传播吧，这样才能 balabala 的解释下吧。
- 要有出众的语言组织能力。机器学习怎么能用“大白话”解释给客户；推理出了错，怎么和客户沟通才能让对方理解“这不是人工智障”；为了项目推进，需要想客户提要求的时候，怎么说才比较委婉、合情合理？
- 风险意识和风险管理能力。
三分软件，七分实施绝对不是说着玩的，项目有一个好的项目经理带队，基本就已经成功一半了。所以，考虑到深度学习的技术难度和理解难度，建议在项目经理选派这件事上，真不要随意，更不要为了控成本，从这个方向开始下手。
项目经理代表公司在客户现场做交付，项目做的好，用户满意，就是“活广告”；做不好，客户不会认为是项目经理能力不行，而会说“这个公司不行”，这里面的机会成本，各位决策者衡量衡量。
有关项目经理和项目交付的更多内容，在第十一章会做进一步详细介绍。
本文转载自知乎专栏：不如无书
原文链接：
评论