关于对比学习中的一些疑问

Hongqiong12 commented 6 months ago

作者您好！有幸了解到您的工作，对比论文和代码产生的一些疑惑： 1）cal_cl_loss部分

    论文中有transformation functions， 但是实际上logit_scale对应exp(𝜏)，那么g_i^(1)和g_i^(2)对应什么呢？
    此处我的理解是：
    在定义encode_text的时候，有一行是x = x @ self.text_projection，这里的text_projection对应的是text的transformation
    functions么？但是为什么graph_text没有呢？
    2）对齐的疑问
    graph encoder的空间是一个128维的空间，encode_text确实一个512的空间，通过text_projection投影的128的空间。那么最终对齐的含义是什么？是说让graph encoder的空间和text encoder的一个投影空间对齐么？

感谢您抽空回答，谢谢！

AriKing11 commented 6 months ago

g1 g2可以理解为两个编码器，其实他这个方法你可以参考一下CLIP这篇工作的对比学习，原理是一样的。

对齐我更多理解的是语义上的对齐，就跟clip他是把图片的语义和自然语言的语义对其一样，这里是节点的语义和节点包含的文本的语义对齐

Hongqiong12 commented 6 months ago

感谢AriKing11的回答。但是这块我还是有一些疑问，感谢再次解惑。这块的原理可能我了解的不是很透彻，我的困惑点是：此处的对齐，貌似是graph encoder的128维的空间和text encoder的512的空间，通过g2编码器到128维空间的对齐。这种对齐的，是不是可以理解只是在该空间的对齐，不同空间的语义信息是可以迁移的么？这样对齐后，通过“轻量级对齐投影策略” 后，还能保持和Vicuna的4096维度的语义空间还对齐么？

tjb-tech commented 6 months ago

感谢AriKing11的回答。但是这块我还是有一些疑问，感谢再次解惑。这块的原理可能我了解的不是很透彻，我的困惑点是：此处的对齐，貌似是graph encoder的128维的空间和text encoder的512的空间，通过g2编码器到128维空间的对齐。这种对齐的，是不是可以理解只是在该空间的对齐，不同空间的语义信息是可以迁移的么？这样对齐后，通过“轻量级对齐投影策略” 后，还能保持和Vicuna的4096维度的语义空间还对齐么？

您好，经过Text-Graph grounding后，pre trained GNN可以将Graph与对应的语义信息对齐，作为轻量级对齐投影阶段的graph encoder。后续两个阶段的对齐中graph encoder的参数是不更新的，与Vicuna的4096维度的语义空间对齐的任务是projector的。希望我的解答对您有所帮助！🥰

Hongqiong12 commented 6 months ago

您好，经过Text-Graph grounding后，pre trained GNN可以将Graph与对应的语义信息对齐，作为轻量级对齐投影阶段的graph encoder。后续两个阶段的对齐中graph encoder的参数是不更新的，与Vicuna的4096维度的语义空间对齐的任务是projector的。希望我的解答对您有所帮助！🥰

感谢Jiabin的解答然后我还有个关于我们在实际业务中使用的问题，关于node的text的定义。因为cora数据集中node 对应的text是标题和摘要，互相引用或者同类别的node间是否本身文本上就比较相似？对于实际落地的业务场景中，是否也需要在构造相应的node info时，也考虑节点间的关联信息呢？若关联信息考虑进去的话，描述的内容会变得非常长。这块您有什么比较好的建议么？感谢百忙之中抽空解惑，感谢感谢

tjb-tech commented 6 months ago

您好，经过Text-Graph grounding后，pre trained GNN可以将Graph与对应的语义信息对齐，作为轻量级对齐投影阶段的graph encoder。后续两个阶段的对齐中graph encoder的参数是不更新的，与Vicuna的4096维度的语义空间对齐的任务是projector的。希望我的解答对您有所帮助！🥰

感谢Jiabin的解答然后我还有个关于我们在实际业务中使用的问题，关于node的text的定义。因为cora数据集中node 对应的text是标题和摘要，互相引用或者同类别的node间是否本身文本上就比较相似？对于实际落地的业务场景中，是否也需要在构造相应的node info时，也考虑节点间的关联信息呢？若关联信息考虑进去的话，描述的内容会变得非常长。这块您有什么比较好的建议么？感谢百忙之中抽空解惑，感谢感谢

我们原先数据中node 的text信息只有各自单个结点的text信息，即标题和摘要，没有融入关联信息。您的加入关联信息的方法是个不错的想法，对于描述的内容会变得非常长的问题，我觉得可以通过采样部分关联信息的方法，即不加入所有邻居信息，只采样部分邻居信息。

Hongqiong12 commented 6 months ago

再次感谢Jiabin的解答这里采样的想法和我们不谋而合。关于加入邻居信息，还有两个问题： 1、关于node text的设计： 1）参考SimKGCIB的方法，若节点a采样的邻居为n_1,...,n_s，则节点a的text信息变成： a的描述、n_1的描述....n_s的描述。 2）这算是我们自己的一个想法，若a和邻居n_s的关系为r_s，则节点a的text信息变成：a的描述、r_1,...,r_s。即用相对简单的关系描述替代节点本身的长文本描述。感谢Jiabin百忙之中抽空解惑，感谢感谢。

tjb-tech commented 6 months ago

再次感谢Jiabin的解答这里采样的想法和我们不谋而合。关于加入邻居信息，还有两个问题： 1、关于node text的设计： 1）参考SimKGCIB的方法，若节点a采样的邻居为n_1,...,n_s，则节点a的text信息变成： a的描述、n_1的描述....n_s的描述。 2）这算是我们自己的一个想法，若a和邻居n_s的关系为r_s，则节点a的text信息变成：a的描述、r_1,...,r_s。即用相对简单的关系描述替代节点本身的长文本描述。感谢Jiabin百忙之中抽空解惑，感谢感谢。

这两种都是可行的方法，第一种对邻居信息可能更全面，第二种对于关系的描述可能更详细，选取哪种也可以根据性能决定🥰

Hongqiong12 commented 6 months ago

好滴，感谢，我们实验看下效果🥰

HKUDS / GraphGPT

关于对比学习中的一些疑问 #35