vl_benchmark_tutorial

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)。