MiniCPM-V多图微调训练中的数据处理问题分析

问题背景

在MiniCPM-V项目的多图微调训练过程中，开发者遇到了"data fetch error"的错误提示。经过深入排查，发现问题出在finetune/dataset.py文件中的conversation_to_ids函数实现上。该函数负责将对话数据转换为模型可处理的token ID序列，但在处理不同类型语言模型时存在不一致性。

核心问题剖析

数据类型不一致问题

conversation_to_ids函数根据llm_type参数的不同，会分别调用三个子函数：

• conversation_to_ids_llama3
• conversation_to_ids_qwen2
• conversation_to_ids_minicpm

前两个函数返回的input_ids是numpy数组对象，而conversation_to_ids_minicpm函数直接返回Python列表。然而在conversation_to_ids函数的第146行，代码尝试通过.shape属性获取input_ids的维度信息，这在Python列表上会引发错误。

图像token处理问题

另一个潜在问题出现在tokenizer的处理逻辑中：

1. 在dataset.py的第215行，message_ids = tokenizer.encode(message)[1:]这行代码截断了编码结果的第一个元素
2. 这个被截断的元素可能是图像起始token(image_start_token)
3. 导致后续第178行的判断if len(image_start_tokens) != len(image_end_tokens)可能失败，因为image_start_tokens的数量比预期少了一个

解决方案探讨

临时解决方案

开发者提出的临时解决方案是在返回input_ids前，添加一行代码将其转换为numpy数组：

input_ids = np.hstack(input_ids)

这种方法确实可以解决.shape属性访问的问题，但需要注意可能引入的其他副作用。

潜在风险

有开发者反馈，在应用上述修改后，可能会遇到新的错误：

RuntimeError: Function torch::autograd::CopySlices returned an invalid gradient at index 1 - got [64, 2304] but expected shape compatible with [192, 2304]

这表明修改可能影响了梯度计算过程中的张量形状一致性，特别是在处理图像数据时。

最佳实践建议

1. 统一数据类型：确保所有分支函数返回相同类型的数据结构，要么统一返回numpy数组，要么统一返回列表并在外层统一转换

2. 谨慎处理token截断：对于图像相关的特殊token，应该确保它们的完整性，避免无意中的截断操作

3. 形状一致性检查：在处理多模态数据时，应该增加张量形状的验证逻辑，确保各阶段的维度匹配

4. 全面的错误处理：为数据处理流程添加更详细的错误日志，便于快速定位问题

总结

MiniCPM-V项目中的多图微调训练涉及复杂的多模态数据处理流程，需要特别注意数据类型的统一性和特殊token的完整性处理。开发者在修改相关代码时，不仅要解决眼前的问题，还需要考虑修改对整个训练流程的潜在影响，特别是涉及梯度计算和反向传播的部分。建议通过更系统性的重构来彻底解决这类问题，而不仅仅是应用临时性的修复方案。