导读: 当你坚持学习到这一步，并且之前的内容都有跟着操作。那么恭喜你，你已经在脑力层面消化了最难的知识，接下来就是需要你行动的时候了。换句话说，接下来就是体力活了，因为路径上要踩的坑你已经趟过一遍了。不要小看这个"体力活"，因为很多人就倒在了执行力不够，导致即使知道方法，也不愿意去动手。因此，这一章节可以理解为衔接"学习研究方法"和"学习论文写作"的桥梁。
- 遇到所谓的“失败”怎么办？心理建设：不可能事事一帆风顺，出现没有效果的情况太多了。
- 我尝试的方法没有效果怎么办？
- 做实验到什么地步就可以开始构思论文了？
经过前面的学习，想必大家已经找到了自己的方向，也有了相关领域的实验经验，根据找创新点的教程，想必也做了很多的实验。但是不是每一次实验都能成功，因此找到实验不work的原因，才能有效地改进当前的方法。分析原因，最重要的步骤就是分析实验结果。不分析实验结果的后果：Project做得很慢，很可能不成功，或者被scoop，导致之前投入的时间白费。
如何找到当前实验不work的原因。
-
搜集当前实验的failure cases（效果不好的实验结果、表面的实验现象）。
-
搜集当前实验的good cases（效果好的实验结果），或者找到一个能work的实验版本。
-
如何找到能work的实验版本，有两种做法：
- 把任务变得简单：实验数据的复杂度（比如：大场景 → 小场景，复杂光照 → 简单光照，复杂材质 → 简单材质）、task setting（比如：泛化 → 拟合，稀疏视角 → 稠密视角，RGB监督 → RGB-D监督，降低数据量）
-
- 逐个去掉自己加的算法改进
-
分析“work的实验版本”和“不work的实验版本”之间存在performance gap的技术原因。（分析good cases和failure cases之间存在performance gap的技术原因）
如果是“work的实验版本”和“不work的实验版本”，要怎么做
-
在work的实验上逐步加东西，直到变得不work，从而定位导致实验不work的表面原因。
-
具体做法，有两种做法：
- 把任务变得复杂。
-
-
加算法改进。
一次只加一个因素，找到导致不work的因素（该因素越单一越好）。高水平科研工作者的经验：As you do experiments, only change one thing at a time, so you know what the outcome of the experiment means.
-
找到单一的导致不work的因素以后，分析技术原因。**列出尽量多的可能性。**把这些可能性排个序。
-
具体做法
-
可能是代码有bug。
-
如何检查代码的bug，在之前的课程中也已经讲了。
可以逐行检查代码的输出，验证输出的结果和自己的预期是否一样。可以检查数据的shape，还有可视化代码输出的结果来验证。这个bug可能是个人对算法的理解不到位，此时需要去看论文或者原理性的东西去理解透彻了再回去检查代码。
-
-
可能是算法确实有问题。算法有问题的四种可能：（1）超参没设置对。（2）算法缺了几个tricks。（3）数据不合适。（4）算法本身确实不行。
-
如何寻找算法的问题
一个有效的方法是看相关的论文为什么可以work，看他们使用了什么tricks。
相关论文指的是使用了相近的方法模块/insight、或者解决相近的technical challenge的论文。
💡 有些很牛逼的算法，单独自己的时候不work，需要加一些tricks才work。（比如NeRF + positional encoding）
-
-
-
如果是“good cases”和“failure cases”，要怎么做
-
找到good cases和failure cases对应的数据，分析它们的数据特点。是数据上的哪一方面的差异导致了performance gap？
-
分析数据差异背后的技术原因是什么。**列出尽量多的可能性。**把这些可能性排个序。
- 具体做法：1.可能是代码有bug。2.可能是算法确实有问题。算法有问题的四种可能：（1）超参没设置对。（2）算法缺了几个tricks，导致在这个数据上不work。（3）算法本身确实不行，导致在这个数据上不work。（4）数据太难了，可以换个简单的数据。
-
-
实验验证上一步中提出的技术原因。一切的猜测最终都要由实验验证。针对导致failure cases的技术原因，提出解法。
我觉得最为重要的一点是，要快速迭代。我们做科研，其实并不是每个想法都正确，我们的 Idea 总会出错，而且大多数人的大多数 Idea 都是不 Work 的。我之前有个规律，就是把我的所有结果都写到Google Spreadsheet 里面，然后就发现每当写四五百行或者1000行，就会有一个 Positive 的结果。所以这就意味着，产出结果的速度，取决于你迭代的速度，你要迭代的足够快，才有可能快速地出结果。所以我觉得这是一个很重要的经验。请注意，**快速迭代建立在有效实验的基础上。**盲目的做实验可能让事情变得更糟。要经常性地确认自己在正确的方向上：当前的算法思路真的对吗。要避免陷入local minima。建议经常找同学交流讨论。当我们验证的某个大的创新点在大部分情况下已经有效时，就可以考虑开始构思和撰写论文了。