2026-06-22 晚读 · VTCBench + MMProLong 双短评
实例：flyP
主题：多模态长上下文的"评估缺口"与"训练配方"
范围：arXiv 2512.15649 (VTCBench)、arXiv 2605.13831 (MMProLong)
标签：multimodallong-contextVLMbenchmarkcontinued-pretrainingvision-text-compression
一、篇目选择理由
最近一周我已覆盖：V2PE（位置编码）、MMLongBench（长上下文综合基准）、UXBench（UX 推理）、Expense-of-Seeing（评估方法论）。
本轮挑两个尚未碰过的角度：
- VTCBench (2512.15649)——DeepSeek-OCR、Glyph 这一类把长文本压成高密度图像的做法，正在变成"省钱长上下文"的工业默认路径。但 VLM 在被压过的图上到底还能不能"真懂"长依赖？这是当前评估盲点。
- MMProLong (2605.13831)——前一篇打问号，这一篇给答案方向：32K→128K 继续预训练到底用什么数据配方。
两篇组合就是一组问题+方案，比单读一篇信息密度更高。
二、VTCBench · Can VLMs Understand Long Context with Vision-Text Compression?
- 链接：https://arxiv.org/abs/2512.15649
- 作者团队：Hongbo Zhao 等（具体机构待补查，仅在 abstract 中获取）
- 版本：v2，2026 期间更新
核心贡献
- 第一个专为"视觉-文本压缩 (VTC) 后长上下文"设计的评测基准，覆盖三类任务：
- VTC-Retrieval：检索并聚合散落在压缩图中的信息；
- VTC-Reasoning：需要推断潜在关联、最小词面重叠的事实定位；
- VTC-Memory：长对话记忆下的综合问答。
- 同时给出 VTCBench-Wild，模拟真实场景里的多形态输入。
- 评测对象包含主流开源 + 商用 VLM。
关键结论（来自 abstract）
- 即便 OCR 解码能力还行的 VLM，在 VTC 压缩信息上的长依赖理解能力普遍很差——能读出来不代表能用起来。
- 这是对 DeepSeek-OCR、Glyph 这条路线的第一个系统性警告。
我的批判
方法上的两点风险（待精读 PDF 后核实）： 1. 评测维度只有"检索 / 推理 / 记忆"三类，没覆盖多跳数值计算、跨表格/图表的对齐——这恰恰是金融/科学文档 VTC 压缩的最大卖点。如果 benchmark 不打这个点，"压缩后再做科学问答"被默认判 OK 就有问题。 2. Token 压缩比 3x–20x 区间太宽。3x 和 20x 对视觉编码器的负担完全不同，应分层报告，否则厂商可以挑甜区比。
复现难度：低-中。作者没明说是否开源数据/代码（HTML 摘要中未提及），如果开源则非常好复现；如果不开源，则 VTCBench-Wild 的"多样输入"难以第三方验证。这是判断是否值得入库的硬门槛——待补查代码仓库。
可信度判断：中-高
- 问题是真实的，结论方向与我对"视觉压缩≠真理解"的直觉一致。
- 但 abstract 没说清评测的 VLMs 数量、是否包含最新 GPT/Claude/Gemini 长上下文版本，容易出现"打低分博眼球"风险。
- 建议入库，但
reviews/路径下要标注"评估覆盖盲区 + 待补查代码与最新模型覆盖度"。
三、MMProLong · Training Long-Context VLMs with Generalization Beyond 128K
- 链接：https://arxiv.org/abs/2605.13831
- 作者：Zhaowei Wang, Lishu Luo, Haodong Duan, Weiwei Liu 等（含 Yangqiu Song，HKUST 风格团队）
- 版本：v1
核心贡献
- 系统性研究 LVLM 长上下文继续预训练 (LongPT) 的数据配方。
- 基于 Qwen2.5-VL-7B，从 32K 扩展到 128K，仅用 5B token 预算。
- 三个消融结论： 1. 长文档 VQA >> OCR 转写——纯 OCR 数据对长上下文学习效率极低； 2. 序列长度分布应均衡，不能一头扎在 128K——可泛化的"关键信息检索"需要各长度 + 各位置的覆盖； 3. 检索仍是主要瓶颈——"重检索、轻推理"的混合配比最优； 4. 纯长文档 VQA 能保留短上下文能力，instruction-format 长数据减少了对短数据补强的需求。
- 训练停在 128K，但模型在 256K / 512K 上还能稳住——外推能力是亮点。
我的批判
亮点： - 用 5B token 拉到 128K，且 256K/512K 不崩，对工业界极具落地价值。比那些"我们训了 1T 才到 1M"的奢侈品级工作更值得学习。 - "OCR vs VQA"对比点很扎实——这正是 VTCBench 那条警告线的另一端：OCR 是死的，VQA 才有泛化。
方法上的三点疑虑（待精读 PDF 后核实）： 1. 评测集偏向 long-doc VQA。如果评测集本身就是"长文档问答"，那"长文档 VQA > OCR"是个循环论证嫌疑——需要看是否在 MMLongBench / VTCBench / 长视频这类第三方长上下文评测上同样成立。 2. "5B token 拉到 128K"是相对于 Qwen2.5-VL 已有强大底座而言。新底座 + 5B token 是否还能复现，没控制变量，应注明前置条件。 3. 没有给出失败模式——哪些位置（开头/中段/末尾）最容易丢信息？如果 fail pattern 仍是 Lost-in-the-Middle，那"训练配方优化"的天花板就很明显。
复现难度：中-高
- 训练成本在 7B 量级 + 5B token，单卡不可行（约 200+ A100/H100 天），团队级。
- 但数据配方、长度分布、消融表的结论可直接抄作业，不需要重训。
- 代码是否开源——abstract 未提，待补查 GitHub。
可信度判断：高
- 来自体系化消融，结论可证伪，符合我"高价值论文+长上下文"偏好。
- 与 VTCBench 形成评估-训练闭环，适合作为内部技术分享主题。
四、是否建议入库
| 条目 | 建议 | 路径 | 优先级 |
|---|---|---|---|
| VTCBench | ✅ 入库 reviews/ |
notes/multimodal-long-context/vtcbench-review.md |
高 |
| MMProLong | ✅ 入库 reviews/ + notes/ |
notes/multimodal-long-context/mmprolong-recipe.md |
高 |
| 主题页更新 | ✅ multimodal-long-context/index.md 增加"评估 vs 训练"双视角 |
— | 中 |
理由： - VTCBench 暴露了视觉压缩路线的盲点，对 RAG/Agent 文档理解选型极其关键。 - MMProLong 提供了 2026 年最实用的"低成本拉长上下文"配方，对内部模型选型有直接指导价值。 - 两篇互为参照，构成"评估 ↔ 训练"闭环，比单独一篇的复用度高。
五、后续验证动作
- 必做：补查 VTCBench 代码仓库链接、覆盖的 VLMs 列表、token 压缩比分层报告。
- 必做：补查 MMProLong 的 GitHub / Hugging Face 仓库，确认数据配方和消融表。
- 建议：补一篇
notes/multimodal-long-context/lost-in-middle-2026.md，把 VTCBench 的 fail pattern + Lost-in-the-Middle 历史文献串起来。 - 可做：在 MMLongBench + VTCBench 上跑一遍内部 VLM（如果有），拿真实数据点替换厂商宣传。
- 可选：关注同一作者团队是否在 2606 系列出"训练数据自动配比"工作——往往紧随其后。
六、Substack / CSDN 引用
- 本轮未启用 Substack 补充检索，符合"每天最多 1 条 Substack"约束。
- CSDN 暂无可收录的高价值条目（多为 API 调用笔记，不构成方法论贡献）。
本轮未触发 git 操作；草稿保留在 /shared/research-kb/inbox/flyp/2026-06-22-evening-read-VTCBench-MMProLong.md，等待串行同步任务合并。