Token sampler代码与论文的差异

[jfma-USTC]

根据论文中的Alg.1的说法，max_similarity = CMX(token, other_tokens)，这里的相似性应该是计算当前vision token和除了自身之外的其他所有token的相似度，并且取得这些相似度中最高的值，作为当前token和其他token重叠度的判断。
但是在代码实现中，是这么做的：monkey_model/text_monkeymerge.py#L19

scores = a @ b.transpose(-1, -2) # a_lxb_l
b,_,_ = scores.shape
scores_diag = torch.tril(torch.ones(t,t))*2
scores_diag = scores_diag.expand(b, -1, -1).to(metric.device)
scores = scores-scores_diag

这里的scores_diag形成了下三角矩阵，形成了类似掩码的效果（除了最后一个token之外，因为倒数第一行所有元素都被减了2，在计算max的时候没有影响），这里可以看到其实只计算了Score_i,j（j>i）的部分，而不是算法Alg1.中提及的other_tokens。请问这种做法是有什么考虑吗？我直观感觉是为了避免重复计算相似的pair， 由于相似度矩阵的对称性，如果有相似度高的两个token会被同时计算为需要被排除的token，而不是保留其中的一个。但是这样的话最后一个token由于相对于其他的所有元素的相似度都被减了2，所以一定会被保留，这样是否是符合算法初衷的呢？

[MelosY]

论文中CMX的算法中other tokens抱歉产生了误解，这里有一个从前往后遍历的trick，会是和自己之后的其他token做计算。并且，如果不用矩阵mask，很多相似token是直接丢失的，这样后面的resampler的merge也就无从说起了。另外至于最后一个token存在的问题，其实只是一个选择的问题，如果存在和它很相似的token，我们选择了保留偏后的token，而非靠前的token。

[jfma-USTC]

论文中CMX的算法中other tokens抱歉产生了误解，这里有一个从前往后遍历的trick，会是和自己之后的其他token做计算。并且，如果不用矩阵mask，很多相似token是直接丢失的，这样后面的resampler的merge也就无从说起了。另外至于最后一个token存在的问题，其实只是一个选择的问题，如果存在和它很相似的token，我们选择了保留偏后的token，而非靠前的token。

感谢解答，这样确实是更加合理的做法，采用下三角mask的做法能够正好实现这一点👍