[Question] 关于有条件和无条件的数据疑惑

[jxz7110]

Required prerequisites

• I have read the documentation https://align-anything.readthedocs.io.
• I have searched the Issue Tracker and Discussions that this hasn't already been reported. (+1 or comment there if it has.)
• Consider asking first in a Discussion.

Questions

代码似乎有错误，如果是我的问题，希望理解

在训练过程中发现将与条件数据放在前一半 无条件数据放在后一半 但是后续logits是奇偶放置的

[Gaiejj]

非常抱歉带来困惑，请问是否有更详细的解释？比如您运行的是哪个算法的训练，以及对logits进行奇偶打印的动机。感谢您的补充！

[jxz7110]

Align_Anything_Janus/janus/models/modeling_vlm.py 文件中的问题 发现代码写错了 不知道是我理解的问题还是确实是错误的

[htlou]

您好，请问您所提供的图1中的logit是在哪个位置print得到的呢？

[yujinhanml]

这里似乎有bug，前面的token的位置是better - worse - better padding -worse padding，计算CFG的时候，使用的却是better - better padding 和 worse -worse padding的加权计算，如果理解错了请纠正

[htlou]

这里似乎有bug，前面的token的位置是better - worse - better padding -worse padding，计算CFG的时候，使用的却是better - better padding 和 worse -worse padding的加权计算，如果理解错了请纠正

从您的表述看似乎是DPO对的实现逻辑有问题，Janus的DPO分为两种逻辑，但是在处理数据时padding的策略都是一致的（参考align-anything/datasets/janus/preference.py中的PreferenceCollator，统一是执行(better + better_padding) + (worse + worse_padding)的逻辑，对(better, worse)先padding成(better + better_padding, worse + worse_padding)后再squeeze得到。

如果我的理解有误或者您有后续的问题，欢迎在本issue中进一步提出！

[yujinhanml]

这里似乎有bug，前面的token的位置是better - worse - better padding -worse padding，计算CFG的时候，使用的却是better - better padding 和 worse -worse padding的加权计算，如果理解错了请纠正

从您的表述看似乎是DPO对的实现逻辑有问题，Janus的DPO分为两种逻辑，但是在处理数据时padding的策略都是一致的（参考align-anything/datasets/janus/preference.py中的PreferenceCollator，统一是执行(better + better_padding) + (worse + worse_padding)的逻辑，对(better, worse)先padding成(better + better_padding, worse + worse_padding)后再squeeze得到。

如果我的理解有误或者您有后续的问题，欢迎在本issue中进一步提出！

感谢回复，我的问题是tokens (batch size=1)后是不是按照better - worse - better padding -worse padding排列，使用现在的CFG代码是否会造成better - better padding 和 worse -worse padding的加权计算？是不是应该是better - worse 和 better padding -worse padding的加权计算。也就是一开始截图里的问题 “在训练过程中发现将与条件数据放在前一半 无条件数据放在后一半 但是后续logits是奇偶放置的”。感谢您的解释。

[htlou]

感谢回复，我的问题是tokens (batch size=1)后是不是按照better - worse - better padding -worse padding排列，使用现在的CFG代码是否会造成better - better padding 和 worse -worse padding的加权计算？是不是应该是better - worse 和 better padding -worse padding的加权计算。也就是一开始截图里的问题 “在训练过程中发现将与条件数据放在前一半 无条件数据放在后一半 但是后续logits是奇偶放置的”。感谢您的解释。

在Janus目前的训练实现中，有两部分可能与您的问题有关：

• 在preference数据的data loading阶段会出现better和worse的组合，在这个阶段进行的padding可以参考align-anything/datasets/janus/preference.py中的PreferenceCollator，统一是执行(better + better_padding) + (worse + worse_padding)的逻辑
• 在image generation training的forward阶段会出现cfg的计算，此时也会先在image的预计token位置生成padding作为图像生成的占位符，但是在这一部分中不会与数据中的better和worse产生关联，batch中的每条数据是被单独处理的

在上一个回答中我的解释可能造成了一些误解，麻烦您看一下您的问题是与模型训练的哪一部分有关呢？

[yujinhanml]

感谢回复，我的问题是tokens (batch size=1)后是不是按照better - worse - better padding -worse padding排列，使用现在的CFG代码是否会造成better - better padding 和 worse -worse padding的加权计算？是不是应该是better - worse 和 better padding -worse padding的加权计算。也就是一开始截图里的问题 “在训练过程中发现将与条件数据放在前一半 无条件数据放在后一半 但是后续logits是奇偶放置的”。感谢您的解释。

在Janus目前的训练实现中，有两部分可能与您的问题有关：

• 在preference数据的data loading阶段会出现better和worse的组合，在这个阶段进行的padding可以参考align-anything/datasets/janus/preference.py中的PreferenceCollator，统一是执行(better + better_padding) + (worse + worse_padding)的逻辑
• 在image generation training的forward阶段会出现cfg的计算，此时也会先在image的预计token位置生成padding作为图像生成的占位符，但是在这一部分中不会与数据中的better和worse产生关联，batch中的每条数据是被单独处理的

在上一个回答中我的解释可能造成了一些误解，麻烦您看一下您的问题是与模型训练的哪一部分有关呢？

嗨感谢您的进一步回复，我的问题和第2点，image generation training的forward阶段会出现cfg的计算计算相关，我想确认一下这一部分比如在batch_size等于1的时候，modeling_vllm.py那个文件中的tokens是不是按照better - worse - better padding -worse padding排列的呀（我试着打印这些ids发现似乎是这样排列的），所以后续奇偶的顺序 logits_cond = logits[0::2, :] logits_uncond = logits[1::2, :]似乎cfg就变成(better + better_padding) + (worse + worse_padding)。感谢解答！