Chapter 12: 案例研究与迭代实战（Case Studies & Iteration）

12.1 开篇段落

欢迎来到实战篇。如果说 Benchmark 是“体检报告”，那么训练数据集和策略调整就是“治疗方案”。在这一章，我们将跳出单纯的指标数字，进入“评测驱动开发”（Evaluation-Driven Development）的闭环。

很多开发者会遇到这样的困境：“我的模型在 LLaVA 架构下跑通了，但 OCRBench 分数只有 200 分（满分 1000），怎么提升？” 或者 “MathVista 总是回答错误，加了数学书数据也没用。”

本章将通过四个经典场景（OCR、数学推理、Grounding、视频），手把手教你如何：

  1. 诊断（Diagnose）：通过观察 Bad Case 定位是视觉层（Vision Encoder）的问题还是语言层（LLM）的问题。
  2. 处方（Prescribe）：制定针对性的数据混合（Data Mixture）策略。
  3. 治疗（Treat）：应用特定的训练技巧（分辨率调整、Token 策略）。
  4. 复查（Monitor）：防止灾难性遗忘。

12.2 案例一：攻克 OCRBench v2 与细粒度视觉

12.2.1 临床表现（Symptoms）

你的模型在 OCRBench v2、TextVQA 或 DocVQA 上表现不佳。

  • 典型 Bad Case：
  • 指鹿为马：把 "Starbucks" 读成 "Starbacks"。
  • 视而不见：完全忽略了角落里的小字或页脚的页码。
  • 排序混乱：在多栏排版的 PDF 中，把左栏第一行直接连到了右栏第一行。

12.2.2 深度诊断（Diagnosis）

OCR 问题通常有 70% 归咎于视觉分辨率，30% 归咎于数据对齐。

| 检查项 | 诊断标准 | 改进方向 |

检查项 诊断标准 改进方向
分辨率 输入图像是否被 resize 到了 224x224 或 336x336？ 对于 A4 文档，336px 意味着每个字符只有 2-3 个像素，不仅模糊且特征丢失。需要 High-Res 策略。
长宽比 这里的长条形文本行（如横幅）是否被强制压扁成正方形？ 宽高比失真会破坏字符结构。需要 Aspect-Ratio Preservation。
先验知识 模型是否见过这种字体？ 需要合成数据增强。

12.2.3 治疗方案：AnyRes 与 数据合成

1. 架构调整：引入 AnyRes (Dynamic High Resolution)

不要直接缩放图片。采用类似 LLaVA-NeXT / UReader 的切片策略：

  • Grid Crop：将一张 的大图切成 4 张 的小图，外加一张 的缩略图（提供全局上下文）。
  • Encoding：分别编码后拼接 Tokens。
  • 效果：等效分辨率提升到 672x672 或更高，小字清晰可见。

2. 数据配方（The OCR Recipe）

单纯加 OCR 语料是不够的，需要分阶段：

  • Stage 1: 纯 OCR 预训练 (Pre-alignment)
  • 数据：IIT-CDIP (文档), LAION-OCR (场景文本)。
  • 任务：给定图，输出所有文字（Json 格式或纯文本）。

  • 目的：让 Visual Encoder 学会关注文字笔画。

  • Stage 2: 问答微调 (SFT)

  • 混合比例建议：
  • DocVQA / ChartQA: 40% (高难度文档理解)
  • SynthText: 20% (合成的弯曲、艺术字、异形字)
  • TextVQA: 20% (自然场景问答)
  • General Caption: 20% (防止模型变成复读机)

Rule of Thumb (OCR) 想要 OCR 好，分辨率是王道。如果计算资源受限无法做切片（AnyRes），尝试在数据预处理时针对包含文字的区域进行 Random Crop 训练，强迫模型在局部高分率下学习特征。

12.3 案例二：提升 MMMU / MathVista 的推理智商

12.3.1 临床表现

  • 典型 Bad Case：
  • 幻觉计算：图上明明是 "x=5"，模型看成了 "x=3"，算出一堆错误结果。
  • 逻辑跳跃：读对了数字，公式也列对了，但最后一步加减法算错。
  • 多图困惑：题目包含三张子图（Fig A, Fig B, Fig C），模型混淆了它们的内容。

12.3.2 深度诊断

这是“视觉感知”与“逻辑推理”的双重挑战。

  • Perception Failure：视觉编码器没对齐数学符号（如积分号、几何角标）。
  • Reasoning Failure：LLM 基座的逻辑能力不足，或者未被激活。

12.3.3 治疗方案：CoT 与 Interleaved Data

1. 数据增强：思维链（CoT）蒸馏

不要只训练 Question -> Answer (Option A)。在 MMMU 这种高难基准上，必须让模型“学会思考”。

  • 利用 GPT-4V/Gemini Pro：将现有训练集（如 ScienceQA）的答案重写。
  • Prompt："请一步步解析这张图，先提取图中的变量，再列出物理公式，最后代入计算。"
  • 训练目标：Image + Question -> Rationale (思考过程) -> Final Answer。

2. 格式调整：交错图文（Interleaved）

数学和科学推理往往依赖上下文。

  • 构建方法：从 arXiv 论文或教科书中提取数据。
  • 格式：Text_1 <image_1> Text_2 <image_2> Text_3 ...
  • 作用：让模型学会图像与文本的共指关系（Co-reference）（例如 "如图 1 所示"）。

3. 推荐数据源（Open Source）

  • MathV360
  • Geo170K (几何专项)
  • ScienceQA (含详细讲义)

Rule of Thumb (Reasoning) 提升数学能力的代价通常是对话能力的下降。建议使用 Weighted Loss：在训练数学数据时，保持 1.0 的 Loss 权重；同时混入 10-20% 的通用对话数据（LLaVA-Instruct 等），甚至可以降低这部分权重的 Loss，仅作为 Regularization（正则化）手段。

12.4 案例三：RefCOCO 与 Grounding（指哪打哪）

12.4.1 临床表现

  • 漂移：框的位置大体正确，但边缘不贴合物体（IoU < 0.5）。
  • 语义混淆：指令是“左边的红衣男子”，框住了“右边的红衣男子”或“左边的蓝衣男子”。

12.4.2 深度诊断

Grounding 任务本质是分类问题还是回归问题？

  • 早期的模型直接回归连续坐标 （MSE Loss），但在 LLM 时代，效果往往不如离散化分类。

12.4.3 治疗方案：坐标离散化与双向增强

1. 坐标 Token 化 (Bin Quantization)

不要让 LLM 输出 "0.153, 0.442"。

  • 做法：将图片长宽划分为 1000 个桶（Bins）。
  • 词表扩充：新增 1000 个特殊 Token <bin_0> ... <bin_999>。
  • 转换：。
  • 优势：LLM 擅长预测下一个 Token，这把回归变成了 1000 分类的分类问题，更容易收敛。

2. 负样本挖掘 (Negative Mining)

Grounding 训练很容易过拟合“只要有物体就框”的倾向。

  • 构造负样本：
  • 图：一张只有猫的图。
  • 问："请框出图中的狗。"

  • 答："图中没有狗。"（或者输出特定的 <no_obj> token）。

  • 这能大幅降低幻觉率（Hallucination Rate）。

Rule of Thumb (Grounding) 数据质量 > 数据数量。RefCOCO 的原始标注比较稀疏。推荐使用经过清洗的 Visual Genome Region Descriptions 或 GQA 进行大规模预训练，最后用 RefCOCO 的训练集做几十个 Epoch 的 Fine-tuning。

12.5 案例四：MVBench / LongVideoBench 与时序理解

12.5.1 临床表现

  • 静态化：模型能识别出“有人”、“有球”，但分不清是“踢球”还是“接球”。
  • 失忆：对于 10 分钟以上的视频，问开头发生的事，模型开始瞎编。

12.5.2 治疗方案：时空池化与帧数预算

1. 视觉编码策略

  • 短视频 (MVBench)：均匀采样 8-16 帧。使用 2D Pooling 将 的特征压缩为 。
  • 长视频 (LongVideoBench)：
  • 关键帧策略：先用 CLIP 算每一帧与 Text Query 的相似度，只把 Top-K 相似帧喂给 VLM。
  • Token Merging：在时序维度合并相似的 Token。

2. 训练数据构造

视频数据稀缺，需要从图像数据“伪造”或者使用专门的视频数据集。

  • VideoChat-Instruct：包含大量时序推理问答。
  • ShareGPT4Video：包含高质量的密集视频描述（Dense Caption）。
  • 技巧：在 Prompt 中显式加入时间戳信息（e.g., "At 00:15, a man enters..."），训练模型对时间的敏感度。

12.6 数据配方实战（Recipe Dashboard）

这是一个通用的微调数据配方模板，用于构建一个平衡的“六边形战士”模型。

pie
    title 推荐的 SFT 数据混合比例 (Total: 1M - 5M samples)
    "通用对话 (LLaVA/ShareGPT4V)" : 30
    "OCR & 文档 (DocVQA/Synth)" : 20
    "数学 & 推理 (Math/Science)" : 15
    "图表 (ChartQA)" : 10
    "Grounding (RefCOCO)" : 10
    "纯文本指令 (Alpaca/ShareGPT)" : 15
  • 纯文本数据的作用：保持 LLM 的指令遵循能力和逻辑思考能力，防止被视觉 Token 的分布带偏。

12.7 本章小结

  1. 诊断优先：利用 Benchmark 的细分维度（Sub-categories）定位短板，不要只看总分。
  2. OCR 靠分辨率：AnyRes 切图策略是提升 OCRBench 的首选。
  3. 推理靠 CoT：数学题必须训练模型输出“解题步骤”，而不仅是答案。
  4. 定位靠离散化：将坐标转换为 <bin> token 比回归浮点数更有效。
  5. 平衡靠配方：任何专项能力的提升都可能导致通用能力下降，务必保留 20-30% 的通用数据作为 Replay Buffer。

12.8 练习题

每道题目旨在模拟真实的研发决策场景。

  1. [架构设计] 你的团队想复现 LLaVA-NeXT 的效果。在处理一张 的海报时，模型将其 Resize 到 导致文字无法识别。请简述如果要实施 "AnyRes" 策略，数据预处理流水线（Pipeline）应该怎么改？
查看提示与答案

提示：涉及 Crop 和 Resize 的组合。 答案：

  1. 动态切片：判断原图尺寸，将其切分为 (举例) 个 的局部 Patch。
  2. 全局缩放：同时生成一张 resize 到 的全局图。
  3. 拼接：将 9 个局部 Patch 的 Token 和 1 个全局图的 Token 按照空间位置拼接输入给 LLM。
  4. 特殊符：通常需要在换行处插入 <newline> 或分隔符 token 以告知模型空间结构。
  1. [数据策略] 你在训练 MathVista 专项模型，发现模型经常无法识别图中的几何符号（如 ）。你应该增加哪种类型的预训练数据？
查看提示与答案

提示：这是视觉编码器（Vision Encoder）的对齐问题。 答案：应增加图文对齐的预训练数据，特别是包含 LaTeX 公式和对应渲染图的数据。例如，生成大量“几何图形 + 对应的 LaTeX 源码”数据对，让 Visual Encoder 学会几何特征与文本符号的对应关系。

  1. [Debug] 模型在 RefCOCO 上训练后，生成的 bbox 总是 [0, 0, 0, 0] 或者超出 [1000, 1000] 的范围。除了 Tokenizer 问题外，还有什么常见的代码实现错误？
查看提示与答案

提示：检查 Normalization 逻辑。 答案：常见的错误是归一化与反归一化不匹配。

  1. 训练数据制作时，是否正确地将 x_pixel / image_width 转换到了 0-1000？
  2. Padding 区域是否被错误地计入了 image_width？（应当只计算有效图片区域）。
  1. [进阶思考] 为什么在微调 VLM 时，通常建议冻结 Visual Encoder（Vision Tower），只训练 Projector 和 LLM？什么情况下应该解冻 Vision Tower？
查看提示与答案

提示：权衡数据量与特征破坏。 答案：

  • 冻结原因：Visual Encoder（如 CLIP-ViT）是在海量数据上训练的，特征非常鲁棒。微调数据量少时，解冻会导致“灾难性遗忘”，破坏已有的视觉特征空间。
  • 解冻时机：当你拥有千万级（10M+）的高质量多模态数据，且涵盖了特定领域（如医疗切片、中文文档）这些 CLIP 没见过的图像分布时，才建议解冻 Vision Tower 进行全量微调。
  1. [视频模型] 使用“平均池化（Mean Pooling）”来压缩视频的时序 Token 有什么致命缺点？在 MVBench 的哪个子任务上会体现最明显？
查看提示与答案

提示：平均意味着顺序信息的丢失。 答案：致命缺点是丢失时序顺序信息。在 MVBench 的 Action Sequence（动作顺序） 任务上体现最明显。例如“人先坐下再站起来”和“先站着再坐下”，平均池化后的特征可能几乎一样，导致模型无法分辨动作先后。

  1. [Data Leakage] 你发现你的模型在 MMMU 上的验证集准确率高达 80%，但在测试集上只有 40%。经过检查，并没有直接把测试图片放入训练集。请问可能发生了哪种隐性的“数据泄漏”？
查看提示与答案

提示：LLM 强大的记忆力。 答案：可能是文本侧泄漏。MMMU 的许多题目来源于教材或网络题库。如果你的 LLM 基座（Base Model）在预训练时通过 CommonCrawl 见过这些题目的文本描述和答案，它可能直接凭“文本记忆”做题，而忽略了图像。这就是为什么即使不做视觉训练，纯 LLM 在某些多模态基准上也能得分的原因。

12.9 常见陷阱与错误 (Gotchas)

  1. Prompt 格式不统一： * 错误：训练时混用了多种 Prompt 模板（有的加 User:, 有的加 Human:），且没有添加 EOS Token。 * 后果：模型推理时不知道何时停止，疯狂输出重复内容。 * 对策：严格统一对话模板（Chat Template），并在 Data Collator 中强制 mask 掉 User 的指令部分的 Loss，只计算 Assistant 回答部分的 Loss。

  2. 忽略图像宽高比（Aspect Ratio）： * 错误：直接暴力 resize 所有图片到正方形。 * 后果：ChartQA 中的柱状图高矮比例失真，OCRBench 中的文字变形。 * 对策：在 Preprocessing 阶段实现 padding 逻辑，保持原始长宽比，用灰色或黑色填充边缘。

  3. 过拟合特定 Benchmark： * 错误：为了刷榜，只训练该 Benchmark 的训练集。 * 后果：这叫“刷题”。虽然分数高，但稍微换个问法（Prompt Perturbation）模型就挂了。 * 对策：鲁棒性测试。在验证阶段，尝试对 Prompt 进行同义词替换，观察输出是否稳定。

  4. 评测时的生成参数（Generation Config）： * 陷阱：Benchmark 评测时开启了 do_sample=True 和高 temperature。 * 后果：结果不可复现，且对于数学/OCR 这种确定性任务，采样会导致准确率大幅波动。 * 对策：评测 Benchmark 时，务必设置 temperature=0 (Greedy Search)。