【研0日记】24.01.03

今天早上来看结果，还是0.249要差一点，而且看过程也收敛慢一点还不如普通的匈牙利匹配，然后我又看了一下匈牙利匹配的缺点（dn-detr），感觉我之前那个方法还是没有解决匈牙利匹配的问题

匈牙利匹配问题就是随机性，每个epoch下kernel对应的gt都可能不一样，特别是前面几个epoch，所以是应该想办法让kernel在每个epoch都固定他对应的gt，比如说在epoch_1，k_1对应的是gt_1，那么在之后的epoch也应该让k_1尽量对应gt_1，重点是不同epoch下，kernel要对应相同的gt；之前侧重点在于一个epoch下，让某些kernel对应他的gt，但是其实哪个kernel对应哪个gt根本不重要（一个epoch里面），只要能让这个kernel从头到尾都对应同样的gt，他就能收敛，匈牙利依靠cost去找匹配，只是想要找一个cost小一点的、尽可能收敛快一点的对应关系而已，但是恰巧是这个方法让他有了随机性

所以还是要改一改，想一想，有什么匹配方法比较能解决这个问题。毕竟我们现在是已经有了伪标注，实现起来肯定比dn-detr要容易一点

---

然后早上还改了一下clip做辅助分类的代码，改了好久，各种各样的问题，有些也确实是我想简单了，最基础的from import都搞了挺久。终于开始跑了，看了两眼emmmm感觉有点难评，总loss倒是挺小，但是clip grad norm有点高，但是这个也不好说，还是要看正式训练怎么样

---

跑到现在，感觉结果都差不多，但是还是感觉差一点，而且我总感觉clip分类器没啥作用，可能还是要换点方法

---

又想了一个，类似最初的那样，cost=cost1 * θ + cost2 * (1-θ)，cost1是原本的匈牙利匹配计算的cost，然后用这个cost匹配，当初是一直设置θ为0.3，意思是说让cost2全程监督，但是感觉其实不用，匈牙利匹配主要还是前几个epoch会出错，只要在前几个epoch让cost2多监督就行，后面正常匈牙利匹配，所以设置成θ线性从0~1，在第八个epoch变成1，后面就全让匈牙利匹配搞

不知道这样会不会好