前一段时间一直在优化部署模型。这几天终于来了需求，又要开始重操训练一些新模型了。趁着这次机会总结了下之前的一些训练模型的笔记，可能比较杂，抛砖引玉！当然这是不完全统计的经验，除了训练部分，还有很多部署的坑没有写。
训练模型阶段
1.算法工程师50%的时间是和数据打交道，有时候拷贝数据（分别从多个文件夹拷贝到某一文件夹）；有时候筛选数据（过滤掉一些质量不好的数据）；有时候把数据换个名字、加个前缀（为了后续训练的时候区分数据的特性，比如多尺度、多种图像增强策略）等等，这些工作可能一个月要重复n多次，因此最好总结起来；可以用Python或者Shell脚本来处理，或者用jupyteR notebook存自己常用的文件处理代码。
2.如果你不清楚拿到数据的来源和可靠度，可以先用find ./ -size -1k -exec RM {} 等命令简单过滤一下，刚才这个命令是扫描1k（或者其他值）以下的损坏图像并删除掉，当然也可以设置其他的参数。很多时候给你的图不一定都是正常的图，最好提前筛一遍，要不然后续处理很麻烦。
3.并不所有的数据都已经有标注信息，如果收集了一批数据要拿去标注，正好公司也有标注人力，可以尝试将这批数据打上预标框让他们再去调整或者补充标框，这样效率更高些。至于预标框怎么打，可以先让模型训练一小批数据，训练个召回率高的小模型，然后预测打框就可以，也可以用一些老模型打框；不过有一个现象比较神奇，标注人员在标注的时候，对于有预标框的数据，标注的质量反而变差了，虽然速度上来了，这是因为大部分标注人员不想调整，这时候需要你好好监督一下，要不然后续模型精度上不去大概率就是数据的问题。
4.有时候模型的指标不仅仅看准招，当模型给别人提供服务的时候，要看PM那边怎么看待这个模型输出结果在实际场景中的使用效果；对于检测模型最终的输出分数，最终给到使用方的框一般是根据你取得分数阈值来设，设的低一点，那么框就多一点（召回率高），设的高一点，那么框就少一点（准确度高）；不同方式不同场景设置不同的阈值有不同的效果，说白了模型效果好坏很大一部分依赖于场景；这个情况在实际项目中其实挺常见的，说白了loSS也好, accuRacy也好，都是很片面且脆弱的评估指标。与模型结构以及评测的数据分布都有很大关系，具体如何选择模型应该与应用场景强相关。
5.当模型遇到badcase的时候，简单粗暴地增加模型的容量效果可能并不好；因为这个badcase大概率和场景强相关，这种情况下最好就是收集badcase，可能会有使用你模型的人给你提供badcase，但这种效率比较低，看提供者的心情oR紧急程度；你可以直接捞一大批模型使用场景的queRy然后使用当前模型做检测，收集相应类别置信度比较低的case，然后挑选出来；
6.测试集很重要，测试集一般不是从训练集中切分出来的，从训练集中切分出来的是验证集；验证集一般用于判断这个模型有没有过拟合、有没有训练走火入魔啦，如果想用验证集来判断模型好坏的话，往往并不能代表模型实际的水平；最好是有测试集，而且测试集是和模型采集批次不同训练模型的时候比较接近实际水平的评价标准；如果没有测试集也可以看训练集的loSS大概确定一下，一般来说只要不是DEMO级别的场景，模型不会轻易过拟合，我们的训练集往往有很重的图像增强策略，每一个epoch可能图像分布都不一样，这时候其实也可以选取模型 Model_last。
7.再强调下，loSS和准确率不是完全正比的关系，loSS波动很正常，loSS低了不一定代表模型的MAP高；相反如果loSS变高，模型的精度也不一定差，有可能是loSS设的不够好导致部分上升占主导，掩盖了另一部分正常的下降也很正常；
8.计算检测模型的MAP，实际中在计算的时候是不考虑目标框分数阈值的，也就是说我们会将所有分数大于0的检测框送去计算MAP；但这里要注意，计算MAP是有Max_nuM也就是最大检测出目标个数，根据任务需求可能是100、可能是500也可能是5000等等，当有这个限制的时候，此时框就需要根据分数来排序，取前100、前500或者前5000的框去计算；最后，如果我们需要可视化结果在图上画框的话，这时候是可以卡阈值的，比如大于0.2分数阈值的要，要不然最终画出来的图会有很多碎框；最后的最后，别忘了NMS！
9.测试转换后的模型是否正确，一定要保证输入图像的一致；这里的一致指的是输入图像的数值必须一模一样，dif为0才行；一般来说我们输入的模型的图像范围是0-1，通道数一般是彩色也就是RGB，不过需要注意这个彩色是否是假彩色（有时候为了传输节省资源会传灰度图再实际推理的时候变成彩色图，对于某种场景来说，假彩色和真彩色的精度相差不大），输入尺寸也要保持一致，是否需要padding（padding成0或者127或者255，这几种padding方式队对结果影响很大）、需要补成32的倍数、或者需要最大边最小边限制，一定要保持一致；对于类别，这样测试模型才能够保证准确性。
10.对于模型来说，如果之后考虑上线。上线的方式很多种：可以pyTorch+flask直接dockeR上线，也可以尝试libTorch上线，也可以TensoRRT上线，当然也可以通过自研框架上线&hellIP;等等等等。如果这个模型追求精度，而且是线下某一时间段跑，并不是实时，可以尝试flask+dockeR的服务；如果这个模型的实时性很高，在设计模型的时候就要考虑之后的上线，那就需要考虑模型优化以及对应的服务器推理框架了可以尝试TensoRRT+tRITon seRveR；
部署方面
1.再次强调一下训练集、验证集和测试集在训练模型中实际的角色：训练集相当于老师布置的作业，验证集相当于模拟试卷，测试集相当于考试试卷，做完家庭作业直接上考卷估计大概率考不好，但是做完作业之后，再做一做模拟卷就知道大体考哪些、重点在哪里，然后调整一下参数啥的，最后真正考试的时候就能考好；训练集中拆分出一部分可以做验证集、但是测试集千万不要再取自训练集，因为我们要保证测试集的&Rdquo;未知“性；验证集虽然不会直接参与训练，但我们依然会根据验证集的表现情况去调整模型的一些超参数，其实这里也算是&Rdquo;学习了“验证集的知识；千万不要把测试集搞成和验证集一样，&Rdquo;以各种形式“参与训练，要不然就是信息泄露。我们使用测试集作为泛化误差的近似，所以不到最后是不能将测试集的信息泄露出去的。
2.数据好坏直接影响模型好坏；在数据量初步阶段的情况下，模型精度一开始可以通过改模型结构来提升，加点注意力、加点DCN、增强点backbone、或者用点其他巧妙的结构可以增加最终的精度。但是在后期想要提升模型泛化能力就需要增加训练数据了，为什么呢？因为此时你的badcase大部分训练集中是没有的，模型没有见过badcase肯定学不会的，此时需要针对性地补充badcase；那假如badcase不好补充呢？此时图像生成就很重要了，如何生成badcase场景的训练集图，生成数据的质量好坏直接影响到模型的最终效果；另外图像增强也非常非常重要，我们要做的就是尽可能让数据在图像增强后的分布接近测试集的分布，说白了就是通过图像生成和图像增强两大技术模拟实际中的场景。
3.当有两个数据集A和B，A有类别a和b，但只有a的GT框；B也有类别a和b，但只有b的GT框，显然这个数据集不能直接拿来用（没有GT框的a和b在训练时会被当成背景），而你的模型要训练成一个可以同时检测a和b框，怎么办？四种方式：1、训练分别检测a和检测b的模型，然后分别在对方数据集上进行预测帮忙打标签，控制好分数阈值，制作好新的数据集后训练模型；2、使用蒸馏的方式，同样训练分别检测a和检测b的模型，然后利用这两个模型的soft-label去训练新模型；3、修改一下loSS，一般来说，我们的loSS函数也会对负样本（也就是背景）进行反向传播，也是有损失回传的，这里我们修改为，如果当前图片没有类别a的GT框，我们关于a的损失直接置为0，让这个类别通道不进行反向传播，这样就可以对没有a框的图片进行训练，模型不会将a当成背景，因为模型“看都不看a一眼，也不知道a是什么东东&Rdquo;，大家可以想一下最终训练后的模型是什么样的呢？4、在模型的最后部分将head头分开，一个负责检测a一个负责检测b，此时模型的backbone就变成了特征提取器。
4.工作中，有很多场景，你需要通过旧模型去给需要训练的新模型筛选数据，比如通过已经训练好的检测模型A去挑选有类别a的图给新模型去训练，这时就需要搭建一个小服务去实现这个过程；当然你也可以打开你之前的旧模型Python库代码，然后回忆一番去找之前的DEMO.py和对应的一些参数；显然这样是比较麻烦的，最好是将之前模型总结起来随时搭个小服务供内部使用，因为别人也可能需要使用你的模型去挑数据，小服务怎么搭建呢？直接使用flask+PyTorch就行，不过这个qps请求大的时候会假死，不过毕竟只是筛选数据么，可以适当降低一些qps，离线请求一晚上搞定。
5.目前比较好使的目标检测框架，无非还是那些经典的、用的人多的、资源多的、部署方便的。毕竟咱们训练模型最终的目的还是上线嘛；单阶段有SSD、yolOV2-V5系列、FCOS、CenteRNet系列，CoRneRnet等等单阶段系列，双阶段的FAsteR-Rcnn已经被实现了好多次了，还有Mask-Rcnn，也被很多人实现过了；以及最新的DETR使用tRansfoRMeR结构的检测框架，上述这些都可以使用TensoRRT部署；其实用什么无非也就是看速度和精度怎么样，是否支持动态尺寸；不过跑分最好的不一定在你的数据上好，千万千万要根据数据集特点选模型，
