文字较多，都是干货，大家慢慢看哈。
- 算法工程师50%的时间是和数据打交道，有时候拷贝数据（分别从多个文件夹拷贝到某一文件夹）；有时候筛选数据（过滤掉一些质量不好的数据）；有时候把数据换个名字、加个前缀（为了后续训练的时候区分数据的特性，比如多尺度、多种图像增强策略）等等，这些工作可能一个月要重复n多次，因此最好总结起来；可以用Python或者shell脚本来处理，或者用jupyter notebook存自己常用的文件处理代码。
- 如果你不清楚拿到数据的来源和可靠度，可以先用
find ./ -size -1k -exec rm {}等命令简单过滤一下，刚才这个命令是扫描1k（或者其他值）以下的损坏图像并删除掉，当然也可以设置其他的参数。很多时候给你的图不一定都是正常的图，最好提前筛一遍，要不然后续处理很麻烦。 - 并不所有的数据都已经有标注信息，如果收集了一批数据要拿去标注，正好公司也有标注人力，可以尝试将这批数据打上预标框让他们再去调整或者补充标框，这样效率更高些。至于预标框怎么打，可以先让模型训练一小批数据，训练个召回率高的小模型，然后预测打框就可以，也可以用一些老模型打框；不过有一个现象比较神奇，标注人员在标注的时候，对于有预标框的数据，标注的质量反而变差了，虽然速度上来了，这是因为大部分标注人员不想调整，这时候需要你好好监督一下，要不然后续模型精度上不去大概率就是数据的问题。
- 有时候模型的指标不仅仅看准招，当模型给别人提供服务的时候，要看PM那边怎么看待这个模型输出结果在实际场景中的使用效果；对于检测模型最终的输出分数，最终给到使用方的框一般是根据你取得分数阈值来设，设的低一点，那么框就多一点（召回率高），设的高一点，那么框就少一点（准确度高）；不同方式不同场景设置不同的阈值有不同的效果，说白了模型效果好坏很大一部分依赖于场景；这个情况在实际项目中其实挺常见的，说白了loss也好, accuracy也好，都是很片面且脆弱的评估指标。与模型结构以及评测的数据分布都有很大关系，具体如何选择模型应该与应用场景强相关。
- 当模型遇到badcase的时候，简单粗暴地增加模型的容量效果可能并不好；因为这个badcase大概率和场景强相关，这种情况下最好就是收集badcase，可能会有使用你模型的人给你提供badcase，但这种效率比较低，看提供者的心情or紧急程度；你可以直接捞一大批模型使用场景的query然后使用当前模型做检测，收集相应类别置信度比较低的case，然后挑选出来；
- 测试集很重要，测试集一般不是从训练集中切分出来的，从训练集中切分出来的是验证集；验证集一般用于判断这个模型有没有过拟合、有没有训练走火入魔啦，如果想用验证集来判断模型好坏的话，往往并不能代表模型实际的水平；最好是有测试集，而且测试集是和模型采集批次不同训练模型的时候比较接近实际水平的评价标准；如果没有测试集也可以看训练集的loss大概确定一下，一般来说只要不是demo级别的场景，模型不会轻易过拟合，我们的训练集往往有很重的图像增强策略，每一个epoch可能图像分布都不一样，这时候其实也可以选取模型
model_last。 - 再强调下，loss和准确率不是完全正比的关系，loss波动很正常，loss低了不一定代表模型的mAP高；相反如果loss变高，模型的精度也不一定差，有可能是loss设的不够好导致部分上升占主导，掩盖了另一部分正常的下降也很正常； 相关讨论：https://github.com/thegregyang/LossUpAccUp 和 https://www.zhihu.com/question/318399418
- 计算检测模型的mAP，实际中在计算的时候是不考虑目标框分数阈值的，也就是说我们会将所有分数大于0的检测框送去计算mAP；但这里要注意，计算mAP是有max_num也就是最大检测出目标个数，根据任务需求可能是100、可能是500也可能是5000等等，当有这个限制的时候，此时框就需要根据分数来排序，取前100、前500或者前5000的框去计算；最后，如果我们需要可视化结果在图上画框的话，这时候是可以卡阈值的，比如大于0.2分数阈值的要，要不然最终画出来的图会有很多碎框；最后的最后，别忘了NMS！
- 测试转换后的模型是否正确，一定要保证输入图像的一致；这里的一致指的是输入图像的数值必须一模一样，dif为0才行；一般来说我们输入的模型的图像范围是0-1，通道数一般是彩色也就是RGB，不过需要注意这个彩色是否是假彩色（有时候为了传输节省资源会传灰度图再实际推理的时候变成彩色图，对于某种场景来说，假彩色和真彩色的精度相差不大），输入尺寸也要保持一致，是否需要padding（padding成0或者127或者255，这几种padding方式队对结果影响很大）、需要补成32的倍数、或者需要最大边最小边限制，一定要保持一致；对于类别，这样测试模型才能够保证准确性。
- 对于模型来说，如果之后考虑上线。上线的方式很多种：可以pytorch flask直接docker上线，也可以尝试libtorch上线，也可以TensorRT上线，当然也可以通过自研框架上线…等等等等。如果这个模型追求精度，而且是线下某一时间段跑，并不是实时，可以尝试flask docker的服务；如果这个模型的实时性很高，在设计模型的时候就要考虑之后的上线，那就需要考虑模型优化以及对应的服务器推理框架了可以尝试TensorRT triton server；
继续老潘的含泪经验，紧接着AI算法工程师的一些含泪经验（一），除了训练模型阶段的注意点，这次更多的是一些部署方面的经验，希望能够对大家有帮助。依然是抛砖引玉，持不同意见的小伙伴欢迎留言！
- 再次强调一下训练集、验证集和测试集在训练模型中实际的角色：训练集相当于老师布置的作业，验证集相当于模拟试卷，测试集相当于考试试卷，做完家庭作业直接上考卷估计大概率考不好，但是做完作业之后，再做一做模拟卷就知道大体考哪些、重点在哪里，然后调整一下参数啥的，最后真正考试的时候就能考好；训练集中拆分出一部分可以做验证集、但是测试集千万不要再取自训练集，因为我们要保证测试集的”未知“性；验证集虽然不会直接参与训练，但我们依然会根据验证集的表现情况去调整模型的一些超参数，其实这里也算是”学习了“验证集的知识；千万不要把测试集搞成和验证集一样，”以各种形式“参与训练，要不然就是信息泄露。我们使用测试集作为泛化误差的近似，所以不到最后是不能将测试集的信息泄露出去的。
- 数据好坏直接影响模型好坏；在数据量初步阶段的情况下，模型精度一开始可以通过改模型结构来提升，加点注意力、加点DCN、增强点backbone、或者用点其他巧妙的结构可以增加最终的精度。但是在后期想要提升模型泛化能力就需要增加训练数据了，为什么呢？因为此时你的badcase大部分训练集中是没有的，模型没有见过badcase肯定学不会的，此时需要针对性地补充badcase；那假如badcase不好补充呢？此时图像生成就很重要了，如何生成badcase场景的训练集图，生成数据的质量好坏直接影响到模型的最终效果；另外图像增强也非常非常重要，我们要做的就是尽可能让数据在图像增强后的分布接近测试集的分布，说白了就是通过图像生成和图像增强两大技术模拟实际中的场景。
- 当有两个数据集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是什么东东”，大家可以想一下最终训练后的模型是什么样的呢？4、在模型的最后部分将head头分开，一个负责检测a一个负责检测b，此时模型的backbone就变成了特征提取器。
- 工作中，有很多场景，你需要通过旧模型去给需要训练的新模型筛选数据，比如通过已经训练好的检测模型A去挑选有类别a的图给新模型去训练，这时就需要搭建一个小服务去实现这个过程；当然你也可以打开你之前的旧模型python库代码，然后回忆一番去找之前的demo.py和对应的一些参数；显然这样是比较麻烦的，最好是将之前模型总结起来随时搭个小服务供内部使用，因为别人也可能需要使用你的模型去挑数据，小服务怎么搭建呢？直接使用flask Pytorch就行，不过这个qps请求大的时候会假死，不过毕竟只是筛选数据么，可以适当降低一些qps，离线请求一晚上搞定。
- 目前比较好使的目标检测框架，无非还是那些经典的、用的人多的、资源多的、部署方便的。毕竟咱们训练模型最终的目的还是上线嘛；单阶段有SSD、yolov2-v5系列、FCOS、CenterNet系列，Cornernet等等单阶段系列，双阶段的faster-rcnn已经被实现了好多次了，还有mask-rcnn，也被很多人实现过了；以及最新的DETR使用transformer结构的检测框架，上述这些都可以使用TensorRT部署；其实用什么无非也就是看速度和精度怎么样，是否支持动态尺寸；不过跑分最好的不一定在你的数据上好，千万千万要根据数据集特点选模型，对于自己的数据集可能效果又不一样，这个需要自己拉下来跑一下； 相关模型TensorRT部署资源： https://github.com/grimoire/mmdetection-to-tensorrt https://github.com/wang-xinyu/tensorrtx
- 再扯一句，其实很多模型最终想要部署，首要难点在于这个模型是否已经有人搞过；如果有人已经搞过并且开源，那直接复制粘贴修改一下就可以，有坑别人已经帮你踩了；如果没有开源代码可借鉴，那么就需要自个儿来了！首先看这个模型的backbone是否有特殊的op（比如dcn、比如senet，当然这两个已经支持了），结构是否特殊（不仅仅是普通的卷积组合，有各种reshape、roll、window-shift等特殊操作）、后处理是否复杂？我转换过最复杂的模型，backbone有自定义op，需要自己实现、另外，这个模型有相当多的后处理，后处理还有一部分会参与训练，也就是有学习到的参数，但是这个后处理有些操作是无法转换为trt或者其他框架的（部分操作不支持），因此只能把这个模型拆成两部分，一部分用TensorRT实现另一部分使用libtorc实现；其实大部分的模型都可以部署，只不过难度不一样，只要肯多想，法子总是有的。
- 转换后的模型，不论是从Pytorch->onnx还是onnx->TensorRT还是tensorflow->TFLITE，转换前和转换后的模型，虽然参数一样结构一样，但同样的输入，输出不可能是完全一样的。当然如果你输出精度卡到小数点后4位那应该是一样的，但是小数点后5、6、7位那是不可能完全一模一样的，转换本身不可能是无损的；举个例子，一个检测模型A使用Pytorch训练，然后还有一个转换为TensorRT的模型A`，这俩是同一个模型，而且转换后的TensorRT也是FP32精度，你可以输入一个随机数，发现这两个模型的输出对比，绝对误差和相对误差在1e-4的基准下为0，但是你拿这两个模型去检测的时候，保持所有的一致（输入、后处理等），最终产生的检测框，分数高的完全一致，分数低的（比如小于0.1或者0.2）会有一些不一样的地方，而且处于边缘的hardcase也会不一致；当然这种情况一般来说影响不大，但也需要留一个心眼。
- 模型的理论flops和实际模型执行的速度关系不大，要看具体执行的平台，不要一味的以为flops低的模型速度就快。很多开源的检测库都是直接在Pytorch上运行进行比较，虽然都是GPU，但这个其实是没有任何优化的，因为Pytorch是动态图；一般的模型部署都会涉及到大大小小的优化，比如算子融合和计算图优化，最简单的例子就是CONV BN的优化，很多基于Pytorch的模型速度比较是忽略这一点的，我们比较两个模型的速度，最好还是在实际要部署的框架和平台去比较；不过如果这个模型参数比较多的话，那模型大概率快不了，理由很简单，大部分的参数一般都是卷积核参数、全连接参数，这些参数多了自然代表这些op操作多，自然会慢。
- 同一个TensorRT模型（或者Pytorch、或者其他利用GPU跑的模型）在同一个型号卡上跑，可能会因为cuda、cudnn、驱动等版本不同、或者显卡的硬件功耗墙设置（P0、P1、P2）不同、或者所处系统版本/内核版本不同而导致速度方面有差异，这种差异有大有小，我见过最大的，有70%的速度差异，所以不知道为什么模型速度不一致的情况下，不妨考虑考虑这些原因。
- 转换好要部署的模型后，一般需要测试这个模型的速度以及吞吐量；速度可以直接for循环推理跑取平均值，不过实际的吞吐量的话要模拟数据传输、模型执行以及排队的时间；一般来说模型的吞吐量可以简单地通过1000/xx计算，xx为模型执行的毫秒，不过有些任务假如输入图像特别大，那么这样算是不行的，我们需要考虑实际图像传输的时间，是否本机、是否跨网段等等。
