顺着AppEngine指导教程一步步搞，发现AppEngine很先进的感觉。第一点它是一个云上的，网页上的开发平台，不需要配置复杂的开发环境。第二点就是数据的存储的功能继承在平台里了，功能非常简洁明了。第三点就是前端页面可以拖拽布局，组件还支持MVVM，有着很好的低代码开发体验。总之就是一句话，AppEngine平台的上手真的很简单。开发页面的文件夹起名和MVC模型视图控制思想感觉也很相似，Logic对应着控制，Model就是模型了，Page就是视图，开发页面一上来就有一种亲切感。

对于一款设计者已经明确其功能需求的轻量级应用，一个月的开发时间加上延期的时间本应是绰绰有余。但团队的两位成员限于知识水平与项目开发经验，真正着手时还是遇到了不少“意料之中”却“难以解决”的困难。比如在页面模型绑定时，绑定何种模型，怎么与脚本关联，脚本变量怎么设置等，我们或许明明知道原理是什么，明明知道应该怎么做，冥冥之中好像也看到了效果，但是——钻了一个月的牛角尖似乎还是没钻出来。加之椅子周围总也扫不干净的头发，两个人都忍不住焦虑起来。队友第N次说要放弃时我都一笑了之，但凡我们之中还有一个在钻牛角尖，另一个总不会甩手不管的。我们也只能珍惜每一次线上答疑的机会小心翼翼地问出自认为很愚蠢的问题，在专家详尽的解答中懵懵懂懂地记录自己也看不懂的笔记。不过有人点拨总比自己瞎摸好一些。比如系统开发之初专家就为我们在对象定义上明确了方向。起初我们将物品根据“丢失物”与“拾获物”区分为两个实体，后来根据指导老师的意见将其统一为一个实体，以属性区分，同时略去了失物招领流程中“人”的实体，将用户个人信息附着于物品属性中，于是最终系统只存在一个“物品”对象，在绑定各类模型以及敲定代码中的变量时减少了不少麻烦。不过真正走上开发之路，还是任虽不重道却险阻啊。目前应用的开发成果未达到预期，但我们在解决诸多问题的过程中也积累了不少经验，也在一次次抓狂中磨练了心性，不论系统最终开发成果如何，本次参赛都是非常难得的经历呢。

通过这次华为云的比赛，我了解到了许多关于APP CUBE 这个平台的使用方法。对于这个全新的平台，我的感受是非常的容易上手。在一次具体的案例实践中，就能够大概了解完成一个项目的全部过程。让我从中收获了许多经验，学到了很多东西。

爽!从来没有进行过,这么so easy的开发.在App Engine,已经实现了,人人都能成为产品经理的愿景.一个App或者网页的开发,一般需要10W,周期一般为1月.而且,从无到有开发能力弱,开发低效,开发资源不足.而且还要管理数据库.这些种种让我对App以及网页开发,望而止步!学习完一门语言,比如说HTML5,CSS,JS需要1个月,在学习几个框架,2个月可以学完,但是学完就能做完整的开发了吗.就是一个大项目,自己完整的做下来.假设项目出来了,要改变功能,或者出了Bug谁去维护,维护需不需要资金呢.一个软件的开发,前端+后端+维护+更新,这一套下来,欲哭无泪了.例如说,一个厂家E2E独立交付,逐个项目做定制典型案例:XX在IOC场景中，逐个项目定制,苦不堪言传统的软件开发是神圣的,对普通人,农民,高中生,创客,是高高在上的.而App Engine把它拉下了神坛.在App Engine中,组件库和AI辅助让前端开发更为高效,流程编排引擎加速了应用的构建.支持云上云下协同快速开发部署,在线测试,在线发布,在线升级.一个账户就可以快速开发,平台+资质可规模复制,效率大规模提升.

 因为是第一次接触AppEngine这个平台，所以刚开始使用的时候，就比较生疏，看着主赛题攻略去做也会遇到各种各样的问题。遇到问题的时候我先自己研究研究，然后实在不行就发到了群里，询问大佬，然后自己在思考。慢慢地也就熟悉了这个平台，然后自己也在平台的学习模块，深入了解了一下标准页面的功能，利用平台的教学，完成了我的对数据处理视图的创新，让使用者看数据更加直观。        知道最后结果的时候，其实我是真的很开心，并且也学到了App开发的很多东西，也较为深入地了解了华为AppEngine这个平台，并且我也会一直学习这个平台，然后将来去实现我的想法。通过这个竞赛也告诉我，不要觉得自己不行，不敢尝试，而要大胆地尝试，在竞赛中学习，不断完善自己的能力。当然这个竞赛也让我发现了自身代码能力不足的问题，需要我继续努力学习代码。   对于大一的我来说，有了这样一次做App的竞赛体验是很珍贵的，也鼓励我继续深入学习，以后也会多多参加这样的竞赛，在竞赛中不断学习。这次竞赛也让我结识了很多优秀的同学，我们竞赛结束之后也仍然保持的联系，一起讨论一些问题，一起解决问题和学习。    祝愿AppEngine平台越做越好，我也会更深入的了解平台，也希望华为越来越好！

通过这比赛我不仅仅收获了知识，还结识了许多跟我一样对未来充满梦想的朋友，在未来的开发和学习当中，互相也可以多交流。这次是我第一次真正的接触到平台开发，也切身的体会到了平台开发的开发周期之短，开发效率之高，让我对软件开发模式的未来发展方式有了更加深刻的认知。我也希望能有更多的开发者能体验到平台开发的优势与乐趣。最后，我真心期待AppEngine能在未来的发展与革新中，带给我更多的惊喜。我也将成为AppEngine的忠实粉丝和用户。

这场比赛给我最大的感触就是认识到学习软件方面的时候自己应该如何做，这里想起了一位老师的话：“不耻下问，勇于上问”。说实在一点，一定要厚脸皮，厚着脸皮的去问，不要害羞。是的，初次接触平台，真的好多不会，和看天书没什么区别，对着开发指导一步一步的抠，但就是那样还是经常卡住，一开始觉得不好意思，觉得都有开发指导了，再去问别人，岂不是太菜了。但是不问吧，自己是真不知道怎么做，一个按键找了接近一个小时，后来忍不住了，去问了一下，没想到很快就有老师和其他选手给我很详细的解答，哪有什么自己那多余的担心，逐渐的，我问的越来越多越来越多以至于自己都感觉有些不好意思。但是大家还是很耐心的为我解答，我也逐渐融进了这种氛围，接下来有人问问题的时候我也积极的为他人进行解答。再到后来通过解答的方式我自己也差不多把赛题又重新理解了一遍，也感觉到主赛题到附加题到选择题这样的设计逻辑是很有心的，像我这样的小白一开始真的需要主赛题那样一步一步的指导，接着到了附加题的时候，没有详细指导，就要联想并体会主赛题的流程，先做什么后做什么，这一步如果出现出错，那么问题出在了哪个部分，脚本还是界面，真的是只有真正理解了，才能达到条件反射似的看到出错就知道错在哪的地步。再到后来的选做题，是留下上升空间给我们自主探索，而选做题只是这空间的一小部分，更大的空间是给我们自己去发现的。先摹，后临，最后自己创造，突然有那么点顿悟的感觉。

这是我第一次接触平台开发，感觉自己做的其实还不错，希望有更多人可以参与到AppEngine平台的开发制作中，和我一起体验平台开发的乐趣。感谢华为的AppEngine平台提供了这次比赛的机会,学习了软件开发知识，如对象的呈现，脚本的构建，页面的构建，报表的呈现等相关知识，结交了好多朋友。通过这次比赛，发现自己存在着太多的不足，一次次失败后的尝试也正是慢慢收获知识的过程，在以后的学习中，我也会像这次比赛一样尽心尽力，强化自己的专业知识，认真地对待生活中遇到的问题。特别期待华为云下次举办的比赛还可以让我像现在一样收获满满！

言关于本次比赛，我只参加了初赛，复赛因为团队原因没有参加，有点遗憾。不过不影响我此次的分享。0x00虽然没参加复赛，但是我体验并使用了AppCube开发应用，我在平台提供的指导书的基础上写了一个摊位管理系统，和啤酒配送系统（正在完善）。通过这些项目我初步体验到了AppCube的魅力，它把前端和后端融合在了一起，写项目更加流畅。脚本使用Typescript，也让我顺便学习到了TS的语法，而不仅仅局限于JS。对node的学习让我对后端有了初步的印象，通过AppCube的体验，让我对后端开发有了进一步的认识。不过平台应该省去了许多后端繁琐的部分，我感觉真正的后端开发可能没这么简单。0x01创建项目后，会有五个目录，主要用到就是前三个，Logic，Model，Page。其中Logic存放后端脚本，Model存放数据对象，Page存放前端页面。具体细节可以参考平台教程：应用魔方 AppCube > 用户指南0x02开发后端脚本的时候，一些修饰符，好像并不是ts的内置语法，应该是对编译器的提示信息在脚本中，@符号代表修饰符，如：@action.object({ type: "param" })@useObject(["beerMgtInfo__CST"])我使用过的就这两个，第一个是定义入参出参的时候使用，第二个是连接数据对象的时候使用。0x03前端页面绑定数据这些都很方便，和vue挺像的。最主要的是，不用自己写CSS！不满意的地方也可以自己重写样式，太省事了！0x04其他的没啥说的了，还有一些细节值得注意：给数据对象（数据模型），添加自定义字段时不要打错字，不然调试代码的时候，难以定位错误。数据对象（数据模型）的名字首字母要大写，这只是一种命名习惯。指导书上的代码，也会有一丢丢的错误，不过可以自己修改，无伤大雅。respect！

欢迎参加上海理工大学首届智慧校园应用开发设计大赛的童鞋，在论坛中发帖进行互动分享，我们将在所有参与发帖的选手中，进行抽奖~并评选出优秀分享内容获得优秀分享奖~>>大赛链接 根据最终分享内容提交情况，评选出的获奖名单情况如下：(领奖请加QQ群 151534240）1、优秀分享奖，3名，每人200元京东卡获奖者：Sq800、地球人、lyy112、在所有参与发帖分享的同学中抽取5名，每人50元京东卡获奖者：lilycai、Sunforge、h0ss、wyz2019、da1357发帖注意：1、      分享内容：1）参赛心得 2）作品展示 3）讲解视频分享 （可任选或全选进行分享）2、      发帖位置：请在华为云大赛技术圈发布论坛分享，>>华为云大赛技术圈，主题分类选择：参赛经验分享3、      发帖命名：上海理工大应用开发设计大赛—你的参赛心得标题4、   回帖抽奖：请将内容分享帖链接+华为云账号回复在本帖下方，抽奖将在回复的帖子中抽取哦~

大赛链接>>华为云DevCloud啤酒供需数字化管理系统开发赛分享者昵称：hwChenZh 一、初见        我很高兴再次来到华为云DevCloud软件平台，进行一次系统化开发的实践，几个月之前完成了口罩预约管理系统的开发，这次完成了啤酒供需数字化管理系统的开发。对于系统开发非常感兴趣，能够学习到总体框架知识，所以，我看到了这次比赛，决定继续学习App Engine开发平台的开发，掌握更加深刻的知识。        华为云提供的这次大赛给了我一次很好的实战机会，有老师专业的指导和QQ群里面大家的热情帮助，大赛竞争也比较激烈，大家也非常积极。我觉得在这个比赛过程中，平台提供的开发资源和相互学习交流，这些收获是最大的。下面我分享的是赛道二啤酒供需数字化管理系统开发的整个过程和思路。     二、开发        开发周期短，获得的效果好。这得益于App Engine平台的友好界面和丰富的系统教程，这也是平台很大的优点。        1、主赛题                因为有详细的指导手册，我在较短时间内完成了主赛题的完整开发，这部分我进行比较顺利，让我有更多时间测试系统找出不足之处。其中，第一个Bug是在期望到达时间的Date类型，从预约上面没有错误，在出库时候发现变为了Datetime类型，经过一段时间的观察和修改，解决了这个问题。第二个，接关单按钮不起作用，这个排错需要从模型绑定开始，开始我从自定义JS代码入手，但是没有起效果，后来仔细研究了一番，发现是模型绑定错误，服务模型是takeAndclose而不是editMgtInfo。第三个，接关单对于订单状态没有验证，测试系统过程尝试了不同订单状态的接关单，都可以通过，导致了数据错误问题，后来修改了自定义JS代码，传入订单状态的参数进行判断，符合当前操作才能接关单。这是我开发的系统界面，包括手机端和电脑端        2、附加题        这部分完成了DMAX大屏界面的开发，关键步骤在于与主赛题开发的系统各个接口 进行交互，从接口获取订单数据信息，呈现于大屏的各个统计图上面。    三、总结这次在App Engine平台实践开发确实收获许多，啤酒供需数字化管理系统的开发是一个相对完整的系统开发过程。平台提供了很方便的图形化交互，很大的减少了编写代码的繁琐。另外，在啤酒管理系统的开发中，App Engine将项目合理地呈现处理，包括前端页面设计、模型数据的绑定，后端脚本的逻辑处理，以及各接口的调用。这些对于系统开发都是很重要的因素。我对此赛题的见解，在主赛题有详细的教程，题目更侧重于熟悉平台的各项功能，其中也有需要自己根据前面学习之后，运用到系统开发中，比如接关单功能的数据模型，附加题也是学习之后的一种应用，考验开发者细心和app实现的细节，向优秀学习！最后，贴上我的系统开发二维码。

比赛页面：https://competition.huaweicloud.com/information/1000029328/introduction?track=111作者：slaine本人代号slaine，有幸在此次华为网络人工智能黑客松大赛的硬盘异常检测赛题中收获第一名的成绩，在这里简单跟大家分享下比赛方案。一、赛题背景硬盘生命周期通常为3-5年，在2-3年后故障率明显升高，导致换盘量陡增。在华为数据中心服务器硬件故障中，硬盘故障占比达到48%+。因此通过机器学习构建硬盘故障预测模型，对数据中心典型硬件进行预测，可以提前感知硬件故障，降低运维成本，显著提升业务体验。此次比赛，非常荣幸能够免费接触和体验到的华为先进的NAIE训练平台。我花了大概一到两天的时间，就能够熟练使用该平台开发模型。二、任务理解本次比赛为典型的二分类问题，根据硬盘当天运行数据及之前的历史记录，判断硬盘未来是否会损坏。此前有不少人误解这个标签指的是硬盘当天损坏与否，但实际上所有的标签都是官方根据硬盘最终是否损坏与否来标注的，标注为0的就是硬盘最终没有坏，标注为1的是该盘最终坏掉了。评分标准官方定义如下：在业务上评价硬盘故障预测算法有两个指标：误报率FAR（False Alarm Rate）和检出率FDR（Fault Detect Rate）。业务目标是在误报率FAR<=0.1%的情况下尽量提高FDR。因此本任务的评价指标为：Score = max(FDR) s.t. FAR≤0.1%，其中，FDR = TP/(TP+FN)，FAR = FP/(TN+FP).实质上从数据分析的角度来看，就是在保证准确率的情况下，尽量提高召回率。三、数据理解由于时间有限，本次比赛我没有在可视化分析上花太多时间，所以这里就不作详细地数据分析，重点给大家介绍一下数据里的破题点。此次比赛提供的训练集一共有55w+行数据，特征维度为52，标签值为0或者1，0代表好盘，1代表坏盘，每一条记录对应着一个硬盘某一天的状态信息，原始数据如下：1. 数据组织因为赛题目的是为了根据硬盘当天和历史数据来预测硬盘未来发生损坏的概率，那么数据组织就有至少两种方式:一是对每一个硬盘每一天的数据进行建模，模型输出每个硬盘每天的预测概率，最后对每个硬盘每天的预测概率取平均或者取最大值，作为当前硬盘在未来一段时间内损坏概率的最终预测值；二是对硬盘ID进行聚合分组，对每一个特征按硬盘ID分组计算统计特征，由此建模得到的预测概率就是在未来一段时间内该硬盘的损坏概率。我在这里优先选择了第二种数据组织方式，该方式可以有效回避个别数据异常值的影响，也更便于发现数据里的潜在规律。2. 数据筛选官方将测试集每条硬盘的数据记录数统一截取为20条。如果在构造训练集时不针对性地做出调整，很容易训练出过拟合的模型。所以我在构造训练集时首先删除了数据记录小于20条的硬盘，随后对于记录数大于20条的硬盘，按日期从小到大进行排列，并取最后20条记录来做聚合，从而保证和测试集的一致性，具体操作如下：四、特征工程这里重点讲一下特征处理的一些操作。原始特征训练集中原始的52个特征都是对硬盘当前性能的描述，在度娘上可以很容易找到对应特征的解释，比如所有raw特征均代表着从硬盘上采集到的数据的原始值，而normalized特征是对相应raw特征进行归一化操作的结果，另外各个特征数字代表的含义如下：上图中特征9，241，242等都与硬盘启用时间有强相关，一般而言硬盘工作时间越长，出故障的概率越高，这些与工作时间相关的特征应该具有很强的建模价值，所以我的baseline思路就是对所有的原始特征进行简单的均值、最值统计，具体如下：这样的操作在验证的时候（验证数据日期与训练集数据日期在同一个区间时）很有效，能轻松达到0.97+，但是当在测试集（2019年的数据）上提交时，线上得分却只有0.1不到，这意味着2019年的数据与2018年的数据有严重的不同。2. 特征构造此次比赛还有一个难点就是测试集的特征我们拿不到，这样导致我们不能像往常一样逐特征分析对比训练集和特征集的差异，包括kaggle上一些专门针对特征筛选的trick（比如对抗性验证等等）都无法使用，这时只有通过反复实验来求证（充分体现了数据科学中科学的一面）。尝试一：为了解决过拟合问题，首先想到的是剔除在训练集中表现强劲的特征，也就是我在上面讲到的与硬盘工作时间强相关的特征（9，241，242等等），但是删除这些特征后线上成绩依然没有得到明显提升。尝试二：期间我也尝试过解决训练集和测试集的一致性问题，因为测试集是统一在2019年1月头20天的数据，我便考虑构造训练集在2018年头20天或者最后20天的数据，但是训练集2018年头20天的数据标签全为1，最后20天的标签全为0，显然无法构造二分类。尝试三：前面提到过所有raw特征均代表着从硬盘上采集到的数据的原始值，而normalized特征是对相应raw特征进行归一化操作的结果。如果测试集和训练集硬盘是同一个批次且同一个时期开启使用的，那么由于测试集的时间在训练集之后，测试集硬盘的raw特征取值应该普遍大于训练集，所以我删除了所有raw特征，仅使用normalized特征建模。本来信心满满，结果依然GG。尝试四！！本来已经感觉快山穷水尽时，我做了最后一个灵光一闪的关键尝试，考虑到normalized特征是对raw特征的某种归一化操作的结果，那么两者之间应该有潜在关系可以挖掘，我条件反射地将两者拿来做除法，结果bingo！！此题的magic就这样发现了。通过将原始所有数字特征的normalized特征和raw特征分别做除法操作，线上成绩终于突破了0.1，而随后的上分操作就是一马平川。通过去除时间强相关特征，并加入一些有意义的统计特征，线上单模可以轻松突破0.4，具体操作如下：3. 特征筛选通过上述方法构造出来的特征共100多维，为进一步增强泛化能力，我采用了wrapper（封装式）特征筛选法，以lgb模型作为筛选模型，通过递归特征消除的方式最终筛选得到了最优的特征子集，这样可以有效减小特征维度并增强模型泛化能力。具体来说就是原始特征数为N，每次删除K个特征并检验当前N-K个特征下的模型得分，如果当前得分有所提高，则取当前N-K个特征为最优特征子集，继续下一次循环，再删除k个特征，以此类推，可以求得最优特征子集。五、模型模型方面我采用了简单的lgb和xgb的bagging融合，粗暴的bagging融合就是对lgb和xgb预测值之和取平均，而我稍微做了一些调整，通过遍历两个模型权重来选择最优的融合比例，操作如下：另外lgb和xgb均用了3个不同种子的5折融合，相当于最后一共融合了30个模型的预测结果，这样的操作使最终线上得分突破了0.5。本来我还打算尝试stacking融合，加入NN和逻辑回归增强泛化能力，还好各位大佬手下留情，没有逼我放大招哈哈，开玩笑。六、总结华为的服务还是很到位的，前期熟悉平台遇到的问题都能及时解答或者协助解决，甚至远程视频，诚意满满。NAIE平台本身也不错，JupyterLab特征工程有交互式编码体验，SDK调用代码一键生成，也支持在Jupyter里敲自定义代码，同时还有有强大的图表分析能力，WebIDE提供了强大的云端编码和debug能力。方案写得不怎么样，主要是跟大家分享一下心路历程和踩过的坑，因为是一边加班一边偷偷打比赛，所以过程相当艰辛，还有很多地方可以优化都没有尝试。今年据说华为还有不少比赛，如果工作时间允许还会继续支持参加，要是奖金再高一点就更好了哈哈。原文链接：https://zhuanlan.zhihu.com/p/131272835来源：网络人工智能园地

比赛页面：https://competition.huaweicloud.com/information/1000029328/introduction?track=111作者：原子弹从入门到精通HDC2020网络人工智能黑客松大赛告一段落，来自深圳福田莲花街道的原子弹从入门到精通同学（也就是我）最终果然没能逆袭成功，线上得分0.4488，排名第二，本文将给出我的赛题解析和方案介绍。一、赛题介绍赛题背景：华为数据中心服务器硬件故障中，硬盘故障占比高达48%。因此构建硬盘故障预测模型，提前感知硬件故障，对于降低数据中心的运维成本，提升业务体验均有着重要意义。赛题数据：比赛提供2017，2018年硬盘最后一次检测前一个月的检测数据进行训练，对未来的硬盘检测数据进行线上预测，评估硬盘未来是否会损坏。模型的开发需要在NAIE服务器中完成。其中训练数据集不可以从云端下载到本地，测试数据无法查看，模型建立完成后需将预测代码打包生成推理服务进行线上测试。评价指标：本次比赛的评价指标如下：FDR = TP/(TP+FN)FAR = FP/(TN+FP)SCORE = max(FDR)  s.t. FAR≤0.1%二、指标分析仔细观察评价指标可以发现，评价指标中的FAR，FDR其实就是AUC曲线中的FPR和TPR。那么把指标翻译成人话就是：在误报率≤千分之一的分数阈值下，坏硬盘的召回率。虽然score与AUC息息相关，但是直接使用AUC作为建模阶段的评价指标会存在一些问题。图1的两个模型从AUC的角度来说显然是model2显著优于model1，然而本题的score是在FPR<0.1%下的max(TPR)，也就是图中红色框框这个范围，因此虽然model2的AUC大很多，但是model2的score仅有0.21，而model1的score却有0.42。基于以上分析，在建模的过程中需要针对本题建立一个专属的评价指标，我使用的是LightGBM，建立评价函数my_score_，在调用模型的时候将my_score_传给lgb.train的参数f即可。三、目标分析由于本题线上仅需对每块硬盘的最后一条记录进行预测，因此我的分析也会以最后一条记录为主。首先看一下每个月坏硬盘的分布情况。从图3中我们可以很清楚的看到坏硬盘的数目随着时间的推进呈现震荡下降的趋势。原因可能是华为数据中心在不断优化或坏硬盘的损坏类型在发生变化，这我们不得而知。我们能拿到的是2017年和2018年的坏样本，而线上需要预测的是2019年的坏样本。既然坏样本的分布随着时间逐渐变化，在无法对2019年数据进行分析的情形下，基于图3的趋势，我倾向于相信2019年坏样本的分布与2018年下半年最为接近。因此在建模的时候我选择直接舍弃早期坏样本，把目光集中在2018年下半年，尤其是2018年8月后，因为这段时间的曲线最为平稳。四、数据分析与建模由于训练集中仅有每块样本前30天的记录，而样本变为坏样本后便不再有记录，因此，数据中好样本都集中在2018年12月而坏样本大多在2018年11月之前，如果把时间作为入模变量进行建模，就能在训练集完美区分好坏样本——12月没了记录的就是坏样本，但这显然是过拟合。由于没有2018年11月前的好样本数据，因此这个比赛存在超级难点，即如何判断模型是在识别好坏样本而不是在识别时间的远近。更雪上加霜的是硬盘自身的相关属性本身就会随着时间的增长而改变，如smart9累计通电时间（图4），smart241写入总数/写入剩余寿命（图5），等等。训练集中某变量的有效范围[a,b]在测试集中可能已经偏移到[a+c,b+c]，而c是多少，我们并不知道。图6是硬盘的写入总数smart_241_raw在好坏样本上的分布，从图6的好坏样本密度图中我们可以看到在训练集中smart_241_raw这个变量有着非常强的区分能力，写入总数越少的样本坏的比率越高，或者说剩余寿命越长的样本坏的比率越高。但是从业务的角度来说显然剩余寿命越长损坏的几率越小，然而由于数据分布的原因，好样本记录的时间节点比坏样本多了那么一两年，导致分析的结果恰恰相反，得出了剩余寿命越长损坏的几率越大这种结论。这其实是一种不公平比较，好坏样本没能也无法在同一时间切片上进行比较，将这种数据直接扔进模型进行训练，就会造成严重的过拟合，很多同学线上分数无法突破0.1主要就是这个原因。为了解决这个问题，我尝试了很多方法：与时间相关的变量除以通电时间进行标准化处理：尝试将时间相关的变量除以通电时间，即将变量标准化为平均每单位时间，这种操作确实能使得分布看起来比较平滑，但这个操作不仅消除了时间的影响，也消除了大量有效信息，未能带来有效的提升。对所有数据进行归一化处理，但每个数据集仅使用该数据集本身的统计指标进行归一化，比如训练集中变量A的最大值是56而测试集中变量A的最大值是321，那么在训练集中将56设置为1，而在测试集中将321设置为1：理论上树模型仅基于数据的rank，无需做数据的标准化处理，但是在当前赛题下，2018年变量的范围是[a,b]，而2019年变量的范围却是[a+c,b+c]，两个数据集的取值并不是等价关系，而我希望2019年的b+c等同于2018年的b，因此我想到对2018年和2019年的数据分别做标准化处理，考虑到2019年的标准化可能涉及数据穿越的问题，即20190101的标准化是[20190101，20190120]的数据做出来的，对20190101数据进行标准化的过程中使用到了未来的数据，因此我又考虑每日标准化，即20190101的标准化仅使用当天数据，20190102的标准化也仅使用那一天的数据，以此类推，但一通操作后我发现推理服务中的预测是将测试集数据切分成73份的，所以该想法并不能很好的实现，不过做了这个与所想不符的操作也没有掉分，属实比较奇怪。虽然该操作在NAIE上没能实现，但是我觉得这个操作很骚且疑似很强，不知道隔壁阿里赛道有没有同学使用类似的方法；尽量使用滑窗统计，差分等相对平稳的变量：由于推理服务中有10分钟的限制，并且我在推理服务的predict中使用并行总是无响应，为了避免超时，我最终上线的代码仅开了3，7，15天的窗口。此处仅举例均值滑窗统计及差分的代码，其他统计指标如std，skew，kurt等可直接替换修改：使用无监督模型；经测试，在这道题中使用无监督异常检测算法iForest有着良好的效果，无监督单模型线上分数接近0.4，已经到达奖牌区，无监督的入模变量我选择了对2018年四个季度的坏样本都有效的变量，即使用LightGBM分别对四个季度的坏样本进行训练，取四个集合中都有效的变量作为无监督模型的入模变量。做完以上分析与操作后，把建模样本限制在2018年下半年，线上分数0.3，调整模型参数后线上分数0.3x，进入奖牌区；将样本范围限制在2018年8月及以后，同时将坏样本的倒数第二条记录也作为坏样本加入训练集（一边降低坏样本数，一边增大坏样本数），线上分数提升至0.41，持续一周TOP1后被超越，模型融合后线上分数0.43，短暂TOP1，最终TOP2;直接使用无监督的结果，线上分数接近0.4，无监督单模进入奖牌区，逼近奖金区；无监督做规则模型，结合有监督最强单模，线上分数0.4488，最终TOP2;五、总结这次比赛让我思考了很多以前没有考虑过的问题，对我日常的工作学习还是很有帮助的，但过程中仍有很多不足的地方：我平时经常把无监督的输出作为有监督的入模变量使用，在这题一开始我也是这样操作，但是没有显著的效果，直到最后一天晚上黔驴技穷了才开始尝试无监督直接作为输出结果使用，没想到效果这么好，导致我既没做相关调优，也没做阈值调整，感觉无监督这一块还有很大的开发空间；直到最后我也没能很好的处理变量时间泄露和变量真实效果之间的问题，可能TOP1大佬raw变量除normalized变量的骚操作才是关键吧，不过我觉得大佬上分的核心应该是基于这个衍生变量的统计变量，而不是这个变量本身。六、吐槽1. 本题中训练集的date_g是str格式，而线上测试数据是datetime格式，导致同样的代码在predict的时候总是出错，刚上手NAIE的我debug到脑壳疼；七、鸣谢非常感谢小爱姐，希旭哥，诸葛亮等各位老板在参赛过程中给予的帮助与解答，尤其是希旭哥和小爱姐，总是能够及时地答疑解惑。最后祝华为及NAIE越来越好，向下扎到根，向上捅破天！来源：网络人工智能园地链接：https://zhuanlan.zhihu.com/p/131275558

首先感谢华为公司举办的比赛，感谢提供给我们一个提升自己的机会。我们是来自南开大学的Excavator团队（挖机联盟），本次比赛非常有幸能进入前10。一、赛题任务本次KPI异常检测比赛提供了某运营商的部分网元的KPI真实数据，根据历史一个月的异常标签数据，训练机器学习模型，智能预测后续一周内KPI中的异常。评价函数为二分类中常用的F1-score：二、数据初探训练集数据仅有5列，分别是：Ø  kpi_id：表示某个KPI名称，本次共分为20个KPI_ID。Ø  start time、end time：采样间隔为1小时，用于指示当前KPI值的开始时间和结束时间。Ø  value：KPI值，本次KPI检测的关键数据，核心特征。Ø  label：标签值，指示kpi值是否异常。0为正常，1为异常。除去ID列和标签列，仅有时间特征和kpi特征。其中最为关键的就是KPI值，通过KPI值的时序变化，来判别异常点。根据上述分析，将本赛题归纳出几个关键字：时序类数据、原始特征较少、二分类问题。接下来我们进一步分析，发现两个问题：1.通过绘制value值分布图发现，不同kpi_id的 value值分布截然不同：有的较为平稳，有的波动很大，且取值区间也相差很大。2.通过对label列的value_counts()函数统计发现，0值较多，1值极少。0与1取值分布如下图所示，比值约为98.5:1.5，训练集数据极为不平衡。      第一时间想到的解决方案是：分ID训练不同模型，根据1/0比值划分阈值。三、特征工程时序类数据和时间强相关，上下联系紧密，首先想到的就是窗口特征和差分特征。1.窗口特征：向上向下取一定数量的值（称为窗口），进行统计分析。可以使用Dataframe中rolling函数。2.差分特征：时间移位作差，目的是观察时序变化。可以使用diff函数。3.卡方分箱：将value值放缩并进行一个映射，便于模型理解。四、解决方案：常见的时序类模型会想到lstm等神经网络，但是其训练速度较慢，所以本次并未采用。本次采用数据挖掘比赛常用的Lightgbm模型，并结合数据规则进行综合评判。分ID思路如下：1.稳定ID一部分ID具有较稳定的value值，异常点即离群点。针对这个现象，我们根据折线图和散点图，找出这些稳定ID，设置一个KPI正常区间。区间之外的点为异常点，置为1。2.不稳定IDl  直接按照模型概率划分0，1对于一部分不稳定ID，我们直接采用LGB模型预测，得到每个点是异常点的概率，再通过计算Train中0，1比例，得到概率划分基准点，再进行微调。划分阈值这里我们的方案如下：五折交叉验证后得到的训练集异常概率，遍历0.001到0.5之间阈值，计算训练集F1_score，得到最优的阈值listl  经常会出现两个连续1的ID有一部分ID的异常点经常是连续出现的（2个）,根据这种情况，我们采用的方案是：1）确定必然是异常的点（异常概率大，超过0.5）。2）在异常点的上下寻找概率较大的点，也将其记作异常点。l  模型概率加阈值划分最后一类问题是我们最头疼的一类问题，某些谷底的值，因为下降过程非常平滑，模型有时不能判断其是否是异常，这种我们通过模型概率先找出异常点，再划分阈值来判断异常。最终评分0.9403，线上排名第10，复核排名第9五、总结1.        首先分ID训练优化模型，对于较少ID的比赛（比如本次比赛）还可以，对于ID多的恐怕会相当复杂，所以还是很期待前排“1”佬们的方案。2.        我们提供的方案主要还是单模，难免在最后阶段进入瓶颈期。后面还要更多考虑模型融合，发掘不同模型之间的优势，取长补短。3.        特征挖掘思路较为常规，还需要进行更深入的挖掘，毕竟“特征为王”，挖到几个强特可能直接分数暴增。4.        对于华为NAIE平台，刚开始使用的时候还是挺困难的，但是一天的摸索后，就一句话：NAIE真香。----------------------------------------------------分割线---------------------------------------------------------5.        对于赛制：没有B榜可能是唯一的槽点吧，全都朝着A棒拟合，模型泛化能力检测不够吧。有点慈善赛的味道（不是为了买代码）。6.        希望下次还能有机会参加华为的比赛，和各路高手比拼。和GREAT再战300回合！

作者：刘迎飞作者简介：刘迎飞，硕士在读，导师为孙显研究员。2018年由天津大学保送至中国科学院大学，研究方向为遥感图像目标检测。曾获2020海华AI挑战赛·垃圾分类技术组第三名。2020年7月18日，由深圳市南山区人民政府主办，华为技术有限公司承办的“华为云杯”2020深圳开放数据应用创新大赛落下帷幕。赛博智能团队疫情期间，在科研环境有限、线下沟通不畅的情况下，发扬“艰苦奋斗、自强不息”的科研精神，利用华为云NAIE 等训练平台，积极投身科研和学科竞赛中。由刘迎飞、时爱君、郭荣鑫、许全福和林仁灯等研究生组成的江流儿赛队，在全国912支参赛队伍、4388名参赛者中脱颖而出，夺得生活垃圾图片分类检测赛道的冠军。在参加比赛的过程中，非常感谢华为NAIE平台给我们提供的计算资源支持。平台代码调试非常方便，此外为每个用户提供5张V100显卡使用。这些使我们有了更多参数调试的机会，大大提高了我们模型迭代的速度。图源 https://competition.huaweicloud.com获奖证书一、赛题描述生活垃圾的分类和处理是目前整个社会都在关注的热点，如何对生活垃圾进行简洁高效的分类与检测对智慧城市建设至关重要。为了对算法的实用性进行评估，比赛测评选用的是VOC形式的mAP，使用华为云ModelArts系统进行自动评分。选手需要将网络模型部署到ModelArts系统中，在CPU机器上对近三千张图像进行测试，要求测试时间不大于三小时，禁止使用TTA和模型融合。这对于算法的精度和实时性都有非常高的要求。二、模型介绍团队在本次比赛中使用MMdetection检测框架，以Res2Net152+gcb作为backbone，单阶段的ATSS检测算法作为baseline。训练过程中结合常见的平移、缩放、旋转、颜色变换，多尺度训练、GridMask数据增强，类别平衡采样方法、余弦学习率衰减、随机权值平均（SWA）等。1、Baseline选取双阶段算法一直是横扫各大比赛的主流算法。但是受到比赛规则的限制，双阶段算法在CPU环境下的部署要比单阶段算法慢得多。有很多的队伍都使用Cascade RCNN，但是只能对较小的输入尺寸进行测试，限制了算法的上限。网络结构图 图源|FCOS[2]如上图所示，ATSS的网络结构沿用了FCOS的形式，相比于双阶段网络，由于没有ROI head，在CPU上的运行速度大大提升，因此选用ATSS作为比赛的baseline。2、Backbone选取Res2Net模块图源|Res2Net[3]如上图所示，Res2Net在单个残差块内构造分层的残差类连接，增加每个网络层的感受野范围，提升特征提取能力。相比于ResNet，Res2Net能用相近的计算复杂度达到更高的精度，因此比赛选用Res2Net系列作为backbone，从最开始的Res2Net50逐步升级到Res2Net152.三、提升技巧很多技巧的参数在比赛的过程中是不断反复调整的，因此很难拿一个具体的数值来定量描述，这里只给出一个大致的提升效果。最初的baseline我们选用的是Res2Net50 + ATSS，保留本地验证集的情况下在初赛A榜mAP=67.48%，使用全部训练数据大约69.5%-70%。1、Albumentations数据增强库Albumentations包含了各种数据增强算法。选用平移缩放旋转和随机旋转90度进行增强。这两项结合在A榜有3%左右的提升。dict(type='RandomRotate90', p=0.5),dict(type='ShiftScaleRotate',shift_limit=0.0625,scale_limit=0.5,rotate_limit=30,interpolation=1,p=0.5)2、多尺度训练为了充分利用测试时间，选用608x640的测试尺寸。在训练过程中，固定长边不变，短边从384浮动到640进行多尺度训练. 多尺度训练的提升在1%~1.5%左右。img_scale=[(640, 384), (640, 640)]3、GridMaskGridMask示意图 图源|GridMask[5]如上图所示，GridMask 通过生成一个和原图相同分辨率的mask，然后将该mask与原图相乘得到一个图像。上图中灰色区域的值为1，黑色区域的值为0。GridMask可以理解为一种正则化方法，将GridMask使用比率设为0.8，结合其他数据增强训练50个epoch。GridMask在初赛A榜有大约2%左右的提升。dict(type='Grid', use_h=True, use_w=True, rotate = 1, offset=0, ratio = 0.5, mode=1, prob = 0.8),4、Cosine学习率衰减余弦学习率衰减指的是学习率衰减像余弦函数一样变化，在训练初期和训练末期均保持一个较为平稳的学习率，在训练中期学习率快速下降。相比于step阶梯式的学习率下降策略，在初赛A榜提升在0.5%左右。lr_config = dict(policy='CosineAnealing', min_lr_ratio=0.01, by_epoch=False,warmup='linear', warmup_iters=500, warmup_ratio=1.0 / 3,)5、类别平衡采样数据的平衡对于以mAP为测评指标的算法非常重要，初赛设置上采样率为0.02，出现频率低于0.02的类别将会采用过采样的方式达到这一比率。决赛设置上采样率为0.018. 在初赛A榜提升有0.5%左右。train=dict(type='ClassBalancedDataset',oversample_thr=0.018,…6、更大的backboneBackone的选取对模型精度提升很关键，在初赛A榜将Res2Net50替换为Res2Net101可以将mAP从70.65% 提升至72.32%， 后期使用Res2Net152将mAP从75.43% 提升至76.08%。Global Context Block 图源|GCNet[4]在决赛期间，由于不允许模型融合，继续增加网络的复杂度是很有必要的。 对Res2Net152添加Global Context Block（GCB），决赛可以从77.14%提升到77.63%。backbone=dict(type='Res2Net',depth=152,scale=4,baseWidth=26,num_stages=4,out_indices=(0, 1, 2, 3),frozen_stages=1,='pytorch',gcb=dict(ratio=1. / 4. ),stage_with_gcb=(False, True, True, True)),7、随机权值平均SWA随机权值平均可以增强模型的泛化性能，降低过拟合的风险。在50 epoch的训练过程中，每5个epoch保存一次模型，使用随机权值平均得到十个模型的平均值。这使得初赛、决赛的最后均有0.8%左右的提升。https://github.com/open-mmlab/mmdetection/issues/20018、类别细化在多类别的检测中，一组参数可能无法对所有的类别达到最优的效果。类别细化就是对不同的类别设置不同的参数，以期达到更优的效果。FCOS和ATSS都具有center-ness分支，在本地验证集的统计发现一些类别的分类得分不乘center-ness高，一些乘以center-ness高。在测试过程中对这些类别加以区分，一些乘center-ness，一些不乘。在初赛提升了0.06%，决赛提升了0.07%。从决赛最终的成绩来看，这个细节发挥了最关键的作用。三、总结展望此次比赛过程，初赛一帆风顺，决赛一波三折。从决赛的过程来看，任何时候都不能松懈，很多实验的细节可能成为决定胜败的关键。此外，受限于比赛时间和硬件条件，本方案仍存在一定的提升和改进的空间：1、Generalized Focal Loss在缺少预训练模型的情况下，GFocal Loss在比赛数据集上效果比ATSS略差，后续可以考虑加上GFocal Loss在COCO上预训练。2、GCB模块GCB模块在本方案中当做一个即插即用的模块使用，如果使用COCO的预训练模型可能取得更好的效果。3、训练尺寸测试尺寸在决赛期间做了较大修改，由于时间关系训练尺寸未做较多的调整，精细化的调整可能会带来一些提升。四、参考文献Zhang, Shifeng, et al. “Bridging the Gap Between Anchor-Based and Anchor-Free Detection via Adaptive Training Sample Selection.” CVPR 2020: Computer Vision and Pattern Recognition, 2020, pp. 9759–9768.Tian, Zhi, et al. “FCOS: Fully Convolutional One-Stage Object Detection.” 2019 IEEE/CVF International Conference on Computer Vision (ICCV), 2019, pp. 9626–9635.Gao, Shanghua, et al. “Res2Net: A New Multi-Scale Backbone Architecture.” IEEE Transactions on Pattern Analysis and Machine Intelligence, 2019, pp. 1–1.Cao, Yue, et al. “GCNet: Non-Local Networks Meet Squeeze-Excitation Networks and Beyond.” 2019 IEEE/CVF International Conference on Computer Vision Workshop (ICCVW), 2019, pp. 1971–1980.Chen, Pengguang, et al. “GridMask Data Augmentation.” ArXiv Preprint ArXiv:2001.04086, 2020.Zhang, Zhi, et al. “Bag of Freebies for Training Object Detection Neural Networks.” ArXiv Preprint ArXiv:1902.04103, 2019.Izmailov, Pavel, et al. “Averaging Weights Leads to Wider Optima and Better Generalization.” UAI 2018: The Conference on Uncertainty in Artificial Intelligence (UAI), 2018, pp. 876–885.