今天早上来看结果,还是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,后面就全让匈牙利匹配搞
不知道这样会不会好