视觉指令微调的损失函数：掩码算错时，loss 曲线看起来是正常的

这篇拆解视觉指令微调（Visual Instruction Tuning）的具体机制，并重点探讨在混合图像与文本 Token 时，我们究竟是如何构建损失函数（Loss Function）的。

核心概念：多模态自回归下一个 Token 预测

在标准的 LLM 中，我们基于所有前面的 Token 来预测下一个 Token。在如 LLaVA 或 Qwen-VL 等 MLLM 中，我们将连续的视觉特征（通过如 CLIP 这样的视觉编码器映射后）直接注入到 LLM 的嵌入空间（Embedding Space）中。对 LLM 而言，图像仅仅是一段特殊的 Token 序列。

数学推导：多模态自回归损失函数

给定一张图像 $\mathbf{X}_v$ 以及一段文本指令与回复序列 $\mathbf{X}_t$，我们将图像转换为 Token 序列 $\mathbf{H}_v$，将文本转换为 Token 序列 $\mathbf{H}_t$。拼接后的序列为 $\mathbf{H} = [\mathbf{H}_v, \mathbf{H}_t]$。

标准的自回归语言建模目标是在给定指令 $\mathbf{X}_{instruct}$ 和图像 $\mathbf{X}_v$ 的前提下，最大化生成目标回复 $\mathbf{X}_{response}$ 的概率。损失函数 $L$ 是负对数似然（Negative Log-Likelihood）：

$$L(\theta) = – \sum_{i=1}^{L} \log p_\theta(x_i | \mathbf{X}_v, x_{

关键细节：Mask 掩码矩阵
我们不会计算图像 Token 上的损失，也不会计算用户指令部分的损失。我们只对模型生成的回复部分计算损失。因此，我们引入一个布尔掩码 $\mathbf{M}$，其中如果第 $i$ 个 Token 属于目标回复，则 $m_i = 1$；如果它属于图像或用户指令，则 $m_i = 0$。

修改后的损失函数变为：

$$L(\theta) = – \frac{1}{\sum_{i=1}^{L} m_i} \sum_{i=1}^{L} m_i \log p_\theta(x_i | \mathbf{X}_v, x_{

数据流：从 JSON 到 Masked Labels

数据实际上是如何从磁盘流入损失函数的呢？以下是其心智模型：

graph TD
    A[多模态 JSON 数据集] -->|提取| B(图像路径 & 对话上下文)
    B --> C{Tokenizer & 处理器}
    C -->|图像| D[Vision Encoder -> 图像 Tokens]
    C -->|文本| E[LLM Tokenizer -> 文本 Tokens]
    D --> F[序列拼接]
    E --> F
    F --> G[生成 Label 掩码]
    G -->|图像与指令 Tokens| H[Label = -100 被忽略]
    G -->|回复 Tokens| I[Label = 对应 Token ID]
    H --> J[PyTorch 交叉熵损失 CrossEntropyLoss]
    I --> J

PyTorch 实现：Label 的掩码操作

在实现 DataLoader 时，设置正确的 Label 是最容易出现 Bug 的步骤。在 PyTorch 的 CrossEntropyLoss 中，Label 设为 -100 的部分会在损失计算时被忽略。我们必须将图像 Token 和提示词（Prompt）Token 遮蔽（Mask）掉。

import torch
from torch.utils.data import Dataset

IGNORE_INDEX = -100
IMAGE_TOKEN_ID = 32000 # 示例：<image> 的 Token ID

class MultimodalDataset(Dataset):
    def __init__(self, data, tokenizer):
        self.data = data
        self.tokenizer = tokenizer
        
    def __getitem__(self, idx):
        item = self.data[idx]
        # 示例格式： "<image>\nUser: 这是什么？\nAssistant: 一只猫。"
        text = item['conversations'] 
        
        # 1. 对整个序列进行 Tokenize
        input_ids = self.tokenizer(text, return_tensors="pt").input_ids[0]
        
        # 2. 克隆 input_ids 以创建 labels
        labels = input_ids.clone()
        
        # 3. 将图像 Token 的 Label 设为忽略
        labels[labels == IMAGE_TOKEN_ID] = IGNORE_INDEX
        
        # 4. 遮蔽用户的指令（此为演示的简化逻辑）
        # 找到 Assistant 开始回复的分隔符
        assistant_token_id = self.tokenizer.convert_tokens_to_ids("Assistant:")
        try:
            assistant_idx = (input_ids == assistant_token_id).nonzero(as_tuple=True)[0][0]
            # 遮蔽 Assistant 回复之前的所有内容（包括 Prompt）
            labels[:assistant_idx + 1] = IGNORE_INDEX
        except IndexError:
            pass # 处理边界情况
            
        return {
            "input_ids": input_ids,
            "labels": labels,
            "image_path": item['image']
        }

为什么要分两阶段训练，以及冻结谁

掩码决定了「哪些位置产生梯度」，但还有一个同样重要的问题：这些梯度允许流进哪些参数。视觉指令微调通常分两个阶段，两阶段的冻结策略完全不同，弄反了训练会很不稳定。

第一阶段只训投影层，视觉编码器和 LLM 全部冻结。此时投影层是随机初始化的，它输出的视觉 token 在 LLM 看来是一堆噪声。如果这时候放开 LLM，梯度会把 LLM 往”适应噪声”的方向拉——而那个噪声下一步就会变，于是 LLM 学到的是一个正在移动的目标，表现为 loss 下降缓慢且伴随原有语言能力退化。

先把 LLM 冻住，等于给投影层一个固定的目标空间去对齐。这一阶段用大量图文对（caption 数据）就够了，不需要指令数据。

第二阶段解冻 LLM，用真正的指令数据微调。此时投影层已经能输出”像样”的视觉 token，LLM 面对的是一个基本稳定的输入分布，微调才有意义。

视觉编码器通常全程冻结。它的表示是在海量图像上预训练出来的，指令数据集的规模远不足以改进它，解冻只会让它过拟合到指令数据的图像分布上——症状是在训练集风格的图片上很好，换一类图片就崩。

# 阶段一：只有投影层可训练
for p in vision_encoder.parameters(): p.requires_grad = False
for p in llm.parameters():            p.requires_grad = False
for p in projector.parameters():      p.requires_grad = True

# 阶段二：解冻 LLM，视觉编码器仍然冻结
for p in llm.parameters():            p.requires_grad = True

一个容易漏的检查：设完 requires_grad 之后要确认优化器只收到了可训练参数。如果构造优化器时传的是 model.parameters()，被冻结的参数虽然没有梯度，但带 weight decay 的优化器仍然会更新它们——冻结形同虚设，而且不会有任何报错。

opt = torch.optim.AdamW(
    [p for p in model.parameters() if p.requires_grad],  # 必须过滤
    lr=2e-5, weight_decay=0.0)

掩码算错时，loss 曲线看起来是正常的

这类实现最麻烦的地方在于：掩码错了，训练照样跑，loss 照样下降。没有异常、没有报错，只是模型学到的东西不对。

最常见的两种错法各有特征，值得分别记住。

忘记掩掉视觉 token 的位置。如果视觉 token 对应的 label 没有设成忽略值，模型会被要求”预测下一个视觉 token”。视觉 token 是连续的投影输出，不属于词表，这个预测任务毫无意义。表现是 loss 起点异常高（因为有一大批无法完成的预测），而且下降到某个值之后就卡住不动——那个平台就是无意义部分贡献的固定损失。

忘记掩掉指令部分。如果用户的提问也参与了 loss，模型会同时学习”生成用户会问什么”和”回答问题”。表现更隐蔽：loss 曲线完全正常，但推理时模型倾向于自问自答——生成完答案之后接着编出下一个问题。

所以验收不能只看 loss 曲线。可靠的做法是直接检查一个样本的 label 张量：

ignored = (labels == -100).sum().item()
total   = labels.numel()
print(f"被忽略 {ignored}/{total}")
# 解码出真正参与 loss 的那部分，肉眼确认它只包含答案
kept = input_ids[labels != -100]
print(tokenizer.decode(kept))

把最后一行打印出来看一眼，应该只有助手的回答，不含系统提示、不含用户问题、不含任何图像占位符。这个检查花不到一分钟，能挡掉这一整类问题——而靠 loss 曲线判断，往往要等到模型训完、推理时行为古怪才发现。

生产环境避坑指南 (Production Pitfalls)

1. 灾难性遗忘 (Catastrophic Forgetting)

在对 MLLM 进行微调时，如果学习率过高，或者数据集严重偏向简短的视觉描述，底层的 LLM 很快就会丧失其通用的推理或对话能力——这一现象被称为灾难性遗忘。为了缓解这个问题，工程师们通常会将纯文本的指令微调数据（如 Alpaca 或 ShareGPT 数据集）与视觉数据混合，以锚定并保留大语言模型的基础能力。

2. 为什么我们要冻结视觉编码器 (Freeze Vision Encoder)

在大多数视觉指令微调阶段（如 LLaVA 的第二阶段），我们会完全冻结视觉编码器（例如 CLIP ViT），只训练映射层（Projection Layer）和 LLM 主干网络。为什么？

• 表征的稳定性： CLIP 已经使用数十亿的图文对进行了训练。它拥有非常优秀且对齐的视觉概念流形（Manifold）。在一个小规模的指令数据集（比如 15 万条）上解冻它，会导致编码器过拟合，从而破坏其泛化视觉表征。
• 计算效率： ViT 非常消耗内存。冻结视觉编码器可以节省显存（VRAM），以便用于训练庞大的 LLM 主干（例如 7B 或 13B 参数），并允许使用更大的 Batch Size 或进行梯度累加（Gradient Accumulation）。

核心总结： 视觉指令微调的目的并不是教模型如何“看”——因为 Vision Encoder 已经能看到了。微调的真正目的是教 LLM 如何去关注和推理那些被注入到上下文窗口中的连续视觉特征，并严格确保仅仅在生成的文本回复上计算损失（Loss）。