MiniCPM-V微调过程中数据集预处理问题分析与解决

问题背景

在使用MiniCPM-V进行微调训练时，开发者可能会遇到一个典型的数据集预处理问题。具体表现为在dataset.py文件中处理对话数据时，由于移除了BOS(开始符号)导致部分短文本内容被截断为空，进而引发后续处理阶段的类型转换错误。

问题现象分析

当运行微调脚本时，系统会抛出类型转换错误：

TypeError: Cannot cast array data from dtype('float64') to dtype('int32') according to the rule 'same_kind'

通过调试代码发现，预处理阶段对对话内容进行了BOS移除操作：

prefix_ids = tokenizer.encode(prefix)[1:]  # remove bos
message_ids = tokenizer.encode(message)[1:]

这种处理方式会导致以下问题：

1. 对于短文本(如"Yes")，移除BOS后内容为空
2. 前缀处理不完整(如"<用户>"变为"用户>")
3. 消息内容丢失(如"Yes."变为".")
4. 最终导致空数组无法进行类型转换

技术原理

在自回归语言模型中，通常需要构建训练目标(target)：

1. 模型通过前一个token预测下一个token
2. 第一个token由BOS开始
3. 目标序列通常比输入序列短一个token

原始代码的设计意图是：

target = torch.full_like(ids, -100, dtype=torch.int32)
for i in range(1, len(ids)):
    if context[i] == 0:
        target[i - 1] = ids[i]
    if context[i] == 1 and context[i - 1] == 0:
        target[i - 1] = tokenizer.eot_id if hasattr(tokenizer, "eot_id") else tokenizer.eos_id

这种设计假设所有输入都包含BOS，移除后从第二个token开始预测第一个token。但对于短文本，这种处理会导致内容丢失。

解决方案

1. 保留BOS处理：对于完整的对话上下文，保留BOS有助于模型理解对话开始
2. 特殊短文本处理：对于极短回复(如"Yes")，不应移除BOS
3. 错误处理机制：添加对空内容的检查，避免后续处理失败
4. 前缀完整保留：确保角色标识符(如"<用户>")完整保留

建议修改预处理逻辑，仅在确定有足够长度时才移除BOS，或采用更智能的截断策略。

最佳实践建议

1. 预处理阶段添加长度检查
2. 对极短文本保留BOS
3. 添加调试日志验证预处理结果
4. 使用try-catch处理可能的异常
5. 确保数据集中的对话样本都符合最小长度要求

通过以上改进，可以确保MiniCPM-V微调过程中的数据预处理更加健壮，避免因短文本导致的训练中断问题。