我从来没有拷打过任何人，除了今天拷打自己。面试准备期跟重做没区别……
后天就要面试了。检查项目的时候，我注意到这个实验设计不合理。
我做的对比实验，测出来延迟是这样的：
| 模型 | 准确率 | 参数量 | 延迟 | FPS |
|---|---|---|---|---|
| MobileNetV3-Large | 85.96% | 4.21M | 108.59ms | 9.2 |
| ResNet50 | 84.81% | 23.52M | 95.81ms | 10.4 |
| EfficientNet-B0 | 86.62% | 4.01M | 47.60ms | 21.0 |
| ShuffleNetV2 | 85.47% | 1.26M | 48.61ms | 20.6 |
嗯？我当时模型选择的主要依据是什么来着？(之前做实验的自己习惯差得可以啊，你是一点不沉淀）
往下一看竟然是“轻量化”。我瞬间无语凝噎了，
怎么没有对比同参数量的模型就直接来对比这些主流选手了？
怎么选的是MobileNetV3-Large（你咋不选Small？）
还有啥经典基线ResNet50都来了，你看看你这23.52M的参数量……
于是我紧急补课，顺着最终部署的ShuffleNetV2，先了解了同系列的区别，再去找一样轻量化的模型……
一味追求 FLOPs 的降低，但是内存访问成本变高、网络碎片化等问题没解决，实际运行时间反而会变长。
看到这里我脑中灵光一闪，突然悟了。
我认为，如果想改进一个关于耗时的算法，我们可以尝试的观察方向是：
- 了解整个流程，每一个模块是如何工作的，它的原理是什么；
- 了解每个步骤之后，把它还原到操作系统、硬件上是如何执行的，每一步的耗时都找出来；
- 这个时候我们可以注意到哪个环节出现问题，并返回到算法层面，思考解决方法。
更笼统地说，找创新点其实就是去找问题和局限。
所以可解释性很重要。有了可解释性，我们就能更好地理解并尝试如何修改模型。这个思路在准确率上也可以沿用。
找出难解释的算法，增强其可解释性，也是一个不错的方向（我个人觉得）。这里我们引入数学学科。
果然操作系统也应该好好学（毕竟是计算机的基础）。
看到这里大家会不会觉得，其实研究也没那么神秘呢？这篇随笔我是以 2018 年 ECCV 的 ShuffleNetV2 为例，得到的启发。
只需要观察文章的一句话，就可以倒推作者是如何发现问题、以怎样的思维设计、最终如何解决的。看到数据后，又可以观察改进效果能支撑这个结论到哪一步。
3年学习效率不如面试前一天，
我前几年果然是使用了大脑消失术吧。
希望最后不要变成《重新检查项目结果找到了100个设计不合理的地方》。