Yanhui Peng

实体数量太多了，调整 test_batch_size，设置小一点。 这是在测试过程中的显存溢出。测试 ranking 时会计算所有实体的 score，计算量为 test_batch_size * num_ents，由于实体数量太多，计算量太大，一次不能测试太多的 triple。由于 num_ents 不可变，所以你把 test_batch_size 调小试试。如果还不行，就只能改代码，把 num_ents 也切分，分批计算，算完再合起来 ranking。

> > 由于很多时候，调整batch_size，设置小一点。 这是在测试过程中显存的量。 ，一次测试所以需要三倍。由于 num_ents 不存在，你把 test_batch_size 调小不能做。如果还起来，就只能改代码，把 num_ents 也切分，分批计算，算再合排名。 > > 谢谢您的回复，该问题已解决，我发现您的代码中有对关系链接模式进行评估---------- Evaluating on Symmetry Dataset ---------- 2022-03-31 20:00:54,760 | INFO: Evaluating the model... (0/136) 2022-03-31 20:01:10,378 |...

> 您好？在论文中打分函数是用w_r^{1}* h +br - w_r^{2}* t ，但在代码中是用w_r^{1}* h +r - w_r^{2}* t 而不是br？哪个是对的？ 不好意思，因为前段时间回家休息了，所以没上线。 因为我们上中学的时候教科书上都用 b 表示截距的吧，所以论文里用了 br。写代码的时候为了方便，也不影响可读性，就简单地用了 r，都一样的，只是个符号而已，不影响的运行的。

代码我找不到了，由于代码比较简单，当时就直接在一台服务器上写了，跑完也没备份。 不过你这个是正常的。是由WN数据集的实体类型单一（只有一种）所致，实体数量庞大，每个实体涉及的关系很多，每个关系又涉及很多实体，优化时不同关系的直线之间会“抢夺”相关联的“点”，所以优化到完美是很难的。 但是直线的斜率和截距又比较符合预期，那“散乱的点”是如何优化出“良好的直线”呢？ 其实，点看似非常散乱，实际上大部分点（我记得应该有90%左右）是分布在直线附近的，远离直线的点其实是非常少的，只是由于基数太大，这些少数的点画到图上也使图看起来散乱。你的第二张图中这种现象就比较明显，直线附近点比较密集。 为了把直线比较清晰地展现出来，我是选取了分布比较好的维度，并隐去了那些少数的散乱点。其实你也可以发现，涉及实体越多的关系，画出来的图越散，就是基数太大，以至于“少数”也成了“大量”。

呃！效果好很多要感谢大神 Zhiqing Sun 在 RotatE paper （本项目readme中有引用） 中提出的自对抗负采样方法，显著提升了 Distance-based KGE models 的性能。有三点：（1）损失函数的改进 (margin-based-->logsigmoid); （2）向量维度更高了，有一定提升；（3）就是负采样方法。像诸如 TransE、RotatE 和本文的 LineaRE 都是 Distance-based KGE models，以上三点都可以提升这类模型的效果；像 DistMult 和 ComplEx 这类 Bilinear（或者叫 semantic matching）模型的提升点主要在 (2)，负采样方法作用不大，且这类方法不稳定，调参极难，学习率和正则化系数以及训练 epoch...

注释掉的部分是 self adversarial negative sampling 原文的，下面的是我尝试的小trick，结果证明没有什么差别，你用注释掉的部分吧，把下面的部分注释掉。或者你去new code文件夹里看新代码，是经过精心整理重构的，比较老代码清晰很多。

> 非常感谢！还有一个疑问请教一下您，在new-code/lineare.py 62 和64 行 `score = wh * self.ent_embd.weight + (r - wt * t)` 这块测试的时候是用所有实体 self.ent_embd.weight，不应该是h吗，期待你的回复 测试的时候是要把所有实体的 score 都计算的，计算好之后再进行排序。论文 IV.B 节有详细的说明。

我记得是在 train 中。