AI 项目落地应用指南 --2. 机器学习项目过程(下)

阅读数:110 2019 年 12 月 17 日 13:51

AI 项目落地应用指南--2.机器学习项目过程(下)

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 的解释下吧。
  • 要有出众的语言组织能力。机器学习怎么能用“大白话”解释给客户;推理出了错,怎么和客户沟通才能让对方理解“这不是人工智障”;为了项目推进,需要想客户提要求的时候,怎么说才比较委婉、合情合理?
  • 风险意识和风险管理能力。

三分软件,七分实施绝对不是说着玩的,项目有一个好的项目经理带队,基本就已经成功一半了。所以,考虑到深度学习的技术难度和理解难度,建议在项目经理选派这件事上,真不要随意,更不要为了控成本,从这个方向开始下手。

项目经理代表公司在客户现场做交付,项目做的好,用户满意,就是“活广告”;做不好,客户不会认为是项目经理能力不行,而会说“这个公司不行”,这里面的机会成本,各位决策者衡量衡量。

有关项目经理和项目交付的更多内容,在第十一章会做进一步详细介绍。

本文转载自知乎专栏:不如无书

原文链接:

https://zhuanlan.zhihu.com/p/76744225

评论

发布