项目三：LLaVA 多模态指令数据工厂¶

本章概览¶

P03 聚焦把图像、区域标注、OCR 信息和多图关系加工成可训练、可质检、可封装的多模态监督数据资产。章节重点不在单张图片问答，而在多模态资产到训练样本的工程化转化过程。

本章可以按四条主线理解：

多模态资产组织：管理原始图像、派生文档、图表结构与任务标签。
指令合成与区域对齐：处理 OCR、bounding box、对象级 grounding 与多图关系。
质量审核与失败样本回查：通过可视化抽检和错误样本归因控制监督质量。
训练封装与结果验证：形成统一的训练接口、切分结果与检查报告。

如果按工程顺序阅读，本章对应的是一条完整链路：

原始图像资产 -> 派生文档/图表资产 -> 指令合成 -> 区域对齐 -> 多图交错 -> 质检抽检 -> 训练封装 -> 报告与验证

这一结构对应的核心目标，是构建一条能够支撑 LLaVA 类模型训练的多模态数据流水线。

1. 项目背景：多模态指令数据工厂的必要性¶

通用语言模型在纯文本问答上已经有较强能力，但进入视觉场景后，数据问题会立刻暴露出来。

最常见的失真同样可以分成三类。

第一类是视觉事实失真。模型明明看到的是两只狗，却生成三只；图里是餐桌，却说成办公桌；框选的是左上角物体，回答却描述了整张图。这类错误一旦进入训练集，会让模型把“幻觉”当成知识。

第二类是任务失真。很多团队只做 caption 或通用 VQA，于是模型只会对整图做粗描述，却不会处理对象级 grounding、文档区域阅读、图表数值比较或多图联动推理。问题不是样本太少，而是任务谱系不完整。

第三类是接口失真。多模态数据的字段更多、依赖更强：图像路径、图像类型、任务标签、OCR 文本、bbox、conversation 模板、训练切分、可视化抽检结果，都必须能被下游训练和评估共同消费。只要 schema 失控，数据工厂就会退化成一堆临时脚本。

因此，P03 的目标不是简单“生成一些 LLaVA 格式 JSON”，而是搭建一个LLaVA 多模态指令数据工厂，把图像资产管理、任务构造、对象级对齐、质量审核和训练交付组织成一条可复用的工程生产线。

这条生产线服务的不是一次性演示，而是一种方法论：

当团队未来需要从 COCO 图像扩展到真实文档、票据、图表、网页截图、多页 PDF 乃至视频关键帧时，真正能迁移的不是某个 prompt，而是这套“从多模态资产到训练监督”的数据工程方法。

2. 项目目标与边界¶

2.1 项目目标¶

本项目聚焦以下四个目标。

目标一：建立多模态资产到监督样本的转化链路。
即把原始图像、标注框和派生视觉资产，转成可直接用于视觉指令微调的结构化样本。

目标二：建立面向 LLaVA 风格训练的任务体系。
本项目不把所有样本都统一成“图片 + 问答”，而是拆分为描述、计数、OCR 摘要、文档问答、图表阅读、区域定位与多图比较等不同任务类型。

目标三：建立可审核、可回退、可版本化的 QA 机制。
多模态样本如果只有生成没有抽检，错误会以很高隐蔽性进入训练集。因此项目同时建设质量规则、人工抽检、可视化反查和低质量样本标记。

目标四：形成训练侧可直接消费的数据资产。
最终输出不仅包括中间处理文件，还包括训练集、验证集、smoke test、manifest、评估报告和项目检查结果，确保项目能从“实验脚本”转为“正式交付物”。

2.2 项目边界¶

为了保证项目具备足够的可复现性，本项目显式设置了若干边界。

1）数据来源边界¶

当前数据主要基于本地 COCO 子集及其标注，并进一步派生出文档式与图表式图像。它适合做方法演示、流程讲解和小型工厂验证，但并不宣称覆盖开放世界真实业务图像全貌。

2）任务边界¶

本项目当前重点覆盖以下几类任务：

图像描述（image description）
计数与视觉问答（counting / visual QA）
OCR 摘要与文档问答（OCR summary / document QA）
图表阅读与比较（chart reading / chart comparison）
区域定位（region grounding）
多图交错比较（multi-image comparison）

这些任务已经足以覆盖“整图理解—局部定位—图文联合—跨图推理”的主干路径，但尚未完整扩展到多页长文档、表格结构化抽取、网页级导航、时序视频问答等更复杂任务。

3）监督方式边界¶

本项目以模板化生成 + 规则补充 + 启发式审查 + 人工抽检为主，而不是依赖大规模纯人工逐条撰写。它更像一个小型数据工厂雏形，而非大规模商业标注生产线。

4）上线能力边界¶

当前样本规模较小，质量通过率较高，很大程度上来自受控数据环境。它适合用于展示多模态数据工厂如何被设计，而不应被夸大为已足够支撑复杂开放场景生产上线。

2.3 边界说明的作用¶

在实践类工程案例里，通常只有两种常见写法：

一种是把项目写得“什么都能做”；
另一种是把项目写成“在什么前提下能稳定做好什么”。

后者明显更可信，也更容易复用。多模态项目尤其如此，因为视觉任务一旦脱离边界，就很容易把受控实验结果误说成通用能力。

3. 项目定位：P03 的能力链位置¶

如果把全书视作一条大模型数据工程能力链，那么 P03 位于“多模态监督数据工程”这一段的核心位置。

前面的章节已经讨论过文本数据清洗、SFT 数据设计、偏好数据与训练封装等方法论。本章的价值，在于把这些方法延伸到一个更复杂的对象：图像及其派生监督信号。

也就是说，本章不是重新讲一遍 LLaVA 论文原理，而是展示：

图像型监督数据为什么不能照搬文本工厂的思路；
为什么多模态任务设计必须按图像类型与监督粒度拆层；
为什么视觉样本的质量控制离不开可视化回查；
为什么对象级坐标对齐与多图关系构造是工程要点；
如何在项目初期就把训练接口、检查脚本和版本演进一起考虑进去。

从这个意义上说，本章最重要的不是“模型能看图”，而是回答一个更大的问题：

多模态监督数据，究竟应该如何被设计成一套持续生产能力，而不是一次性的样本拼装脚本？

4. 整体架构：从多模态资产到训练资产的数据流水线¶

从工程视角看，本项目可以拆成三层。

4.1 第一层：资产处理层¶

这一层解决的是“有没有干净、可控、结构明确的多模态输入资产”。主要包括：

原始图像收集
图像类别均衡
派生文档图像构造
派生图表图像构造
资产 manifest 记录

这一步的目标不是直接生成训练样本，而是把分散的视觉素材转成可追踪、可分层采样的资产池。

4.2 第二层：监督构造层¶

这一层解决的是“如何把不同类型的视觉资产转成不同类型的监督样本”。主要包括：

图像描述与重描述
OCR 摘要与文档问答
图表阅读与比较
bbox 对齐与 grounding
多图交错样本生成
conversation 模板统一

这一步是整个项目的核心，因为它决定模型学到的是“粗糙 caption 化能力”，还是“有任务分层的多模态理解能力”。

4.3 第三层：质检与交付层¶

这一层解决的是“这些样本是否真的能进入训练”。主要包括：

规则审查
人工抽检
bbox 可视化核验
低质量样本标记
train/val/smoke 切分
manifest 生成
报告与项目检查

到这一步，项目才真正从“生成样本实验”变成“可复用的数据工厂”。

5. 工程前置：多模态数据工厂的关键面¶

在最小实验里，资产准备、样本生成、质量检查和训练封装往往可以由同一个人串起来完成；但当项目准备进入团队复用或后续扩展阶段时，更稳的做法不是强调“谁来做”，而是先把哪些职责面必须被覆盖写清楚。

多模态数据工厂里，至少有四类职责面需要被显式定义。

5.1 资产规划与采样策略¶

这一层负责界定图片从哪里来、分成哪几类、覆盖到什么范围、哪些样本应该进入第一轮资产池。它关注的重点不是单条样本，而是整体分布是否均衡、是否已经覆盖通用图像、文档图像和图表图像三个层面。

5.2 数据处理与接口维护¶

这一层负责图像处理、标注对齐、schema 设计、中间产物落盘、训练切分和检查脚本。它的核心目标是保证数据接口稳定、字段一致、版本可追踪，而不是把流程停留在一组临时脚本上。

5.3 任务生成与模板编排¶

这一层负责 caption 重写、OCR 样本构造、图表任务编排、多图比较模板、API 调用与后处理。它连接“视觉资产输入”和“监督样本输出”，决定项目最终形成的是单一 caption 数据集，还是具备任务谱系的多模态监督集。

5.4 质检、回退与版本控制¶

这一层负责错误类型归因、抽检规则、可视化复核、拒收条件、低质量样本沉淀与返工闭环。在多模态场景里，这部分尤其关键，因为很多问题只有回到图片、框标注和多图顺序本身才能被真正发现。

5.5 关键职责面的作用¶

因为很多团队第一次做多模态 SFT 时，真正的问题往往不是“模型不会生成”，而是关键控制点没有被显式设计，导致：

资产来源缺少边界；
任务覆盖缺少规划；
坐标与图像版本缺少校验；
失败样本缺少沉淀；
版本演进缺少稳定接口。

因此，把这些职责面写清楚，本质上是在说明：多模态 SFT 更像一条带视觉质检能力的工程流水线，而不是若干临时样本拼装步骤。

6. 资产层设计：多模态资产池的构建¶

通用文本 SFT 里，很多团队直接从已有文本库切片开始；但多模态项目不适合一上来就“对着图片生成问答”。原因在于，图像不是天然结构化的知识单元。

因此，本项目先建设一层相对稳定的多模态资产池，并把它拆成三类：

通用图像资产（general image）
文档图像资产（document image）
图表图像资产（chart image）

这一设计的价值，不只是为了凑不同样本，而是为了给后续任务分发提供明确的“输入语义边界”。

6.1 为什么要做三类资产拆分¶

因为不同图像天然支持的任务不同。

通用图像更适合描述、计数、目标识别和局部定位；
文档图像更适合 OCR 摘要、文档问答和局部阅读；
图表图像更适合趋势总结、数值比较和结构解读。

如果不先拆开，就会在同一个 prompt 池里混入大量不适配样本：例如对普通猫狗图片要求 OCR 摘要，对票据截图要求自然场景比较。这种混乱会直接降低有效样本比例。

6.2 资产均衡的工程意义¶

项目最终形成了 87 条资产，其中三类资产各 29 条，说明资产层不是随手收集，而是刻意做了均衡设计。这样做的好处是：

后续任务分发更容易控制分布；
结果分析时更容易判断哪类任务表现不足；
小规模项目里也能避免单一图像类型主导训练集。

6.3 为什么派生文档图像和图表图像很重要¶

许多团队会误以为“多模态 = 自然图片”。但在真实业务里，文档截图、报表、票据、仪表盘、图表和网页截图往往更重要。它们的难点不在物体识别，而在图文混合与局部结构理解。

因此，本项目没有停留在 COCO 自然图像，而是进一步派生出文档式和图表式资产，用一个小规模项目把多模态任务谱系拉开。

表 1：资产类型与任务映射表

资产类型	典型来源	适配任务	主要风险
`general_image`	COCO 自然图像、通用场景图片	图像描述、计数、视觉问答、局部定位	幻觉描述、对象遗漏、类别混淆
`document_image`	文档截图、票据、制度页面、扫描件	OCR 摘要、文档问答、局部阅读	文字漏读、版式误判、局部区域错位
`chart_image`	柱状图、折线图、报表截图、仪表盘	图表阅读、趋势概括、数值比较	趋势反读、类别关系误判、数值遗漏
`interleaved_pair`	多图配对、跨页样本、对照截图	多图比较、共同点总结、差异归纳	顺序混淆、跨图串扰、配对失衡

7. 数据 schema：多模态种子的结构化方式¶

完成资产收集之后，项目并不会直接把图片送去生成模型，而是先把资产、标注和任务字段统一进 schema。

7.1 schema 在多模态场景中的重要性¶

文本数据里，很多时候 instruction 和 output 两列就能跑通一个基础实验；但多模态场景不同，至少还要额外处理：

图片文件路径
图片类型
原始宽高
标注框
OCR 文本
派生任务类型
对话模板
样本来源与版本

如果 schema 不统一，后面每扩一类任务就要重写一遍逻辑，项目很快会变成多套临时格式并存。

7.2 一个更稳的最小 schema 应该包含什么¶

本项目的种子和训练样本，至少应包含以下字段：

id：样本唯一标识
image：图片路径或图片列表
asset_type：general_image / document_image / chart_image / interleaved_pair
task_type：任务类型标签
source_id：来源资产标识
bbox：区域定位任务的坐标
ocr_text：OCR 或可读文本摘要
conversations：LLaVA 对话格式主体
split：train / val / smoke
meta：版本、生成方式、审核状态等元信息

7.3 schema 的工程价值¶

schema 的意义不只是字段清单，而是让三个环节都能对齐：

生成环节知道该写什么；
QA 环节知道该查什么；
训练环节知道该读什么。

这使项目不再是“一份 JSON 就结束”，而是一个可以长期演进的接口层。

8. 图像采样与重描述：监督重写的必要性¶

很多现成图像数据集都带有 caption，但多模态 SFT 不能简单直接拿来训练，原因有三点。

第一，原始 caption 往往偏短、偏描述性，覆盖不了问答、计数、解释和比较等任务。
第二，原始 caption 的风格不统一，不一定符合 LLaVA 对话式数据格式。
第三，原始 caption 多半只描述整图，无法覆盖对象级或图文混合型能力。

因此，本项目对图像先做“重描述”，再将其转换为任务化监督。

8.1 重描述在这里解决什么问题¶

重描述并不只是把一句 caption 改得更长，而是把图像中可能用于训练的显性信息组织出来，例如：

场景主体是什么；
存在哪些显著对象；
是否有可读文本；
是否适合做计数；
是否适合做比较或定位。

重描述是从“图像素材”到“任务种子”的过渡层。

8.2 模板化生成的作用¶

完全开放式生成当然更灵活，但在小型工厂里也更容易失控。尤其是多模态场景，模型很容易：

把图里不存在的东西写进去；
把不确定信息说得过满；
对同类图片生成风格不一致的回答。

因此，本项目更强调模板化的 prompt 和受控生成，让样本先具备统一性，再在后续阶段逐步增加复杂度。

8.3 任务化重写的思路¶

同一张图，重写后可以派生出多种训练样本，例如：

描述类：请概括这张图的主要场景；
计数类：图中大约有几个显著主体；
识别类：左侧最明显的物体是什么；
推断类：这更像室内还是室外场景，为什么；
OCR 类：请读出并总结图中的文字；
比较类：两张图的主要共同点和差异是什么。

这也是多模态数据工厂和“单一 caption 数据集”的根本差别：前者构造的是任务分布，后者只有素材描述。

9. 文档图像与 OCR 任务：文档理解链路¶

文档图像是多模态场景中最容易被低估的一类资产。很多模型看上去能读字，但一旦进入文档问答或长段摘要，就会暴露出明显短板。

9.1 OCR 任务在本项目中的定位¶

本项目把文档图像任务拆成两层：

OCR summary：读出图中文字并做压缩概括；
document QA：基于图中文字回答明确问题。

这两者并不等价。前者更像“读到什么”，后者更像“读懂了什么并能回答什么”。

9.2 为什么不能把 OCR 结果原样塞进训练集¶

因为 OCR 本身也会有噪声，尤其在复杂版式、局部模糊、小字体或图文混排情况下。如果把 OCR 输出原样当真值，很容易把视觉识别错误包装成监督信号。

因此，本项目更合理的做法是：

先把图中文字提取为中间层信息；
再用模板控制摘要和问答任务；
最后通过人工抽检和低质量标记把明显错误挡住。

9.3 文档图像为什么是通往真实业务的关键一步¶

因为真实世界多模态任务里，很多输入不是自然照片，而是截图、扫描件、报表、工单、票据和制度文档。只做自然图像训练，很难支撑这些场景。

所以，文档图像任务在本项目里的意义，不只是扩充样本，而是把工厂从“看图说话”推进到“图文联合理解”。

10. 图表图像任务：图表阅读任务层¶

图表图像和自然图片最大的区别在于：它不是“看见什么”，而是“结构上表达了什么”。

10.1 图表任务为什么要单独建类¶

图表阅读的难点在于，它同时涉及：

标题和图例识别
轴标签理解
数值关系概括
趋势判断与比较

如果把图表图像只当作普通图片做 caption，模型学到的大概率只是“这是一张柱状图”或“图中有几条线”，却学不会真正有用的图表理解。

10.2 本项目中的图表任务拆分¶

项目至少应支持以下两类：

chart reading：描述图表结构、主要趋势和显著信息；
chart comparison：比较不同类别、区间或曲线之间的差异。

这使训练集不再只是视觉识别，而是开始接近多模态分析能力。

10.3 为什么图表样本适合做失败归因¶

因为图表任务的错误通常更容易归类：

读错轴标签
忽略单位
把相对变化说成绝对变化
比较关系反了
把不存在的趋势编出来

这些错误很适合进入失败样本库，并反过来指导 prompt 调整与 QA 规则设计。

11. 区域定位与坐标对齐：grounding 的几何约束¶

在多模态训练里，grounding 是最容易被“看起来差不多”误导的一类任务。

因为边框一旦有偏差，文本可能仍然很流畅，但模型学到的监督已经错了。特别是在对象级任务里，坐标偏 1% 看似很小，投射到实际图像上可能已经换了物体。

11.1 输入坐标和训练坐标为什么不一致¶

原始 COCO 标注采用像素绝对坐标 [x, y, w, h]。而很多 LLaVA 风格或下游对齐实现，更偏向归一化后的 [ymin, xmin, ymax, xmax] 表达，并将坐标映射到 [0, 1000] 范围。

这就意味着项目必须做两层转换：

格式转换：从左上角宽高制，改为上下左右边界制；
尺度归一化：从像素值映射到标准区间。

11.2 为什么还要做 clamp¶

即使理论公式没问题，浮点到整数转换时依然可能出现边界溢出。例如图像最右侧、最下侧的框，在舍入后可能出现 1001 或 -1。如果不做 clamp，训练脚本很可能直接报错，或者在解析中 silently fail。

因此，本项目把安全截断写进对齐函数，本质上是在把数学逻辑补全成工程逻辑。

11.3 为什么 grounding 样本不应该无限生成¶

一个常见误区是：既然有很多 bbox，就给每张图尽量生成很多问答对。这样虽然样本数会增加，但也会带来分布失衡：某些图片会因为物体特别多而被过度重复利用。

因此，项目采用类似 selected_anns = anns[:3] 的受控策略，只选取部分对象构造问答与定位样本。这种做法的重点不是节省算力，而是避免训练集被高密度目标图像主导。

11.4 坐标对齐实现¶

# 核心代码摘自 alignment.py
# 输入为 COCO 风格 bbox: [x, y, w, h]
def convert_bbox(bbox, width, height):
    x, y, w, h = bbox

    xmin = int((x / width) * 1000)
    ymin = int((y / height) * 1000)
    xmax = int(((x + w) / width) * 1000)
    ymax = int(((y + h) / height) * 1000)

    return [
        max(0, min(1000, ymin)),
        max(0, min(1000, xmin)),
        max(0, min(1000, ymax)),
        max(0, min(1000, xmax)),
    ]

11.5 这一步真正的工程意义¶

bbox 对齐的重要性并不只在于“会写一个转换函数”，而在于它体现了一个关键原则：

多模态数据工程里，任何“看起来只是格式改一下”的步骤，背后都可能决定监督真值是否仍然成立。

12. 多图交错样本：比较任务的构造¶

单图监督能教会模型看图说话，但很多真实多模态任务并不止于此。用户经常会要求：

比较两张图的差异；
判断哪张图更符合某种条件；
综合多张图提取共同点；
在多页输入中完成对照理解。

因此，本项目专门建设多图交错样本。

12.1 多图任务在本项目中的价值¶

多图样本的关键，不只是把两张图拼到同一个 prompt 里，而是训练模型学习：

顺序意识：知道第一张与第二张分别是什么；
对照意识：能找共同点和差异点；
聚合意识：能基于多图形成更高层概括。

这使模型从“单图描述器”向“跨图理解器”迈出关键一步。

12.2 Payload 构建为什么是工程痛点¶

在多图对话生成中，本地图片通常需要先编码，再按照目标 API 的要求组织成消息列表。这里常见问题包括：

图片顺序混乱；
Base64 数据格式不一致；
单图接口逻辑无法直接复用到多图；
请求体太大导致调用失败。

因此，interleaved.py 中的 Base64 编码与 image_url 列表构造，虽然看起来像技术细节，实际上决定了多图样本能否稳定生成。

12.3 多图交错实现¶

import base64

def encode_image(path):
    with open(path, "rb") as f:
        return base64.b64encode(f.read()).decode("utf-8")

def generate_comparison(img1_path, img2_path):
    prompt = "Here are two images. Please compare their similarities and differences."

    messages = [
        {
            "role": "user",
            "content": [
                {"type": "text", "text": prompt},
                {"type": "image_url", "image_url": {"url": f"data:image/jpeg;base64,{encode_image(img1_path)}"}},
                {"type": "image_url", "image_url": {"url": f"data:image/jpeg;base64,{encode_image(img2_path)}"}},
            ],
        }
    ]
    return messages

12.4 为什么交错样本数量通常不会太多¶

多图样本生成成本更高、检查难度更大，而且错误影响也更复杂。因此在小规模工厂里，更合理的策略不是一开始追求海量，而是先做少量高价值样本，验证 schema、模板、调用链路和 QA 机制是否成立。

13. LLaVA 对话模板：训练接口格式¶

很多入门项目会把多模态样本理解成“图像路径 + 一段文本”。但对于 LLaVA 风格训练，真正重要的是：

图像如何被引用；
用户与助手轮次如何组织；
任务标签如何与模板配合；
是否兼容下游训练代码。

13.1 conversation 模板解决什么问题¶

conversation 模板的价值在于，它把不同任务统一进同一种训练接口。例如：

用户提出描述请求；
助手给出描述；
用户提出局部定位请求；
助手返回坐标与解释。

这使不同任务类型虽然语义不同，但仍能共享同一种训练消费方式。

13.2 为什么要控制模板数量¶

模板越多，表面上看样本更丰富；但在小规模项目里，模板一旦过多，反而容易造成：

语气漂移
输出风格不一致
QA 难度上升
某些模板与图像类型不匹配

因此，更合理的做法是：先建立少量稳定模板，再逐步做风格扩充。

13.3 LLaVA 格式示例¶

{
  "id": "p03_000128",
  "image": "images/sample_128.jpg",
  "task_type": "region_grounding",
  "conversations": [
    {"from": "human", "value": "<image> 请指出图中左侧那只狗的大致位置。"},
    {"from": "gpt", "value": "它大致位于 [214, 103, 588, 472]。"}
  ]
}

这类格式的重点不是字段形式本身，而是训练与检查脚本都能稳定消费。

14. 质量控制：多模态 QA 的结构¶

如果一个文本样本写得很流畅，很多时候它大概率至少是“语言上正常的”；但多模态样本不同，文本正常并不代表视觉事实正常。

因此，多模态 QA 至少要做三类检查。

14.1 第一类：结构一致性检查¶

主要检查：

图片路径是否存在；
conversations 是否完整；
bbox 格式是否正确；
多图样本是否真的包含多张图；
训练切分是否存在冲突。

这一层更偏工程完整性。

14.2 第二类：语义质量检查¶

主要检查：

回答是否与图像内容一致；
描述是否出现明显幻觉；
OCR 摘要是否遗漏核心文本；
图表问答是否读错趋势；
比较任务是否把两张图混淆。

这一层更偏内容真实性。

14.3 第三类：可视化反查¶

对于 grounding 任务，文本检查远远不够，必须把坐标重新画回图像上。如果在图片上画出来的框不对，那无论文本多通顺，样本都应该被拒收。

这就是为什么项目专门生成 bbox 可视化文件并做人工抽检。因为视觉对齐问题只有回到图像上才能被真正发现。

14.4 为什么要维护低质量样本库¶

很多团队只保留“通过”的样本，而不系统记录“失败”的样本。这样做虽然省事，但会失去非常宝贵的工程信号。

多模态项目中，低质量样本库至少有三个价值：

反向指导 prompt 调整；
帮助归纳常见错误类型；
为后续训练安全过滤提供经验基础。

15. 可视化核验：bbox 反向渲染¶

在本项目中，visualize_bbox.py 的意义非常典型。它证明了多模态数据工厂不能只在 JSON 层检查，而必须具备“反向渲染”能力。

15.1 反向渲染在这里解决什么问题¶

它解决的是一个非常朴素但关键的问题：

模型训练时看到的坐标，是否真的对应我们以为的那个对象？

只有把归一化后的坐标还原回原始像素空间，再把框画在图上，我们才能真正确定标注是否仍然成立。

15.2 典型错误包括什么¶

ymin/xmin 顺序写反；
宽高转换边界出错；
多个框里抽错对象；
图像尺寸读错；
不同预处理阶段的图片不是同一版本。

这些错误在表层 JSON 上往往很难看出来，但一可视化就会立刻暴露。

15.3 这一步的工程价值¶

这里最值得强调的是：

多模态 QA 不是额外附加项，而是数据真值的一部分。

如果没有可视化核验，bbox 样本是否正确其实并不可信。

16. 训练封装：训练接口的最终整理¶

很多项目做完样本生成后，就把一个训练文件交给下游，这在工程上其实是不完整的。因为训练前还有至少三件事必须明确：

数据如何切分；
是否支持快速 smoke test；
是否有 manifest 能说明产物状态。

16.1 train / val / smoke 三层交付¶

本项目最终应输出：

train.jsonl：正式训练集
val.jsonl：验证集
smoke_test.jsonl：快速连通性检查集
training_manifest.json：训练接口元信息

其中 smoke_test.jsonl 非常关键。它不追求代表性，而追求能快速暴露字段缺失、图像路径错误、模板异常等问题。

16.2 为什么 manifest 很重要¶

manifest 的意义在于让数据集从“若干 JSONL 文件”变成“一个可被系统读取和检查的正式产物”。

它至少应该记录：

样本总数
各 split 数量
各 task type 数量
各 asset type 数量
文件路径
生成版本
overlap 检查结果

这会让后续训练、评估和版本更新都更稳。

16.3 训练封装本质上是在做什么¶

它本质上是在回答：

这些样本不仅能被人看懂，而且能被系统稳定消费吗？

只有当答案是肯定的，项目才能被称为数据工厂，而不是数据拼装。

17. 项目指标：当前产出指标的含义¶

当前结果显示，P03 有几组非常关键的指标：

资产总数：87
三类资产：各 29 条
基础指令：174
对齐样本：79
交错样本：14
最终训练记录：267 条
QA 可视化样本：29 条
质量通过率：100%
项目检查：11 / 11 PASS

17.1 为什么“87 条资产 -> 267 条训练记录”有意义¶

因为这说明项目不是线性复制原始图片，而是通过任务派生把同一资产转成多种监督样本。也就是说，真正被建设的是“任务分发能力”，而不是简单素材堆叠。

17.2 资产类型分布说明了什么¶

报告显示，最终训练集的资产类型分布不是简单的三等分，而是：

general_image = 137
document_image = 58
chart_image = 58
interleaved_pair = 14

这说明：

通用图像承担了更多基础描述与定位任务；
文档和图表图像更多承担 specialized 任务；
多图样本被刻意控制在较小规模，符合其高成本、高复杂度特点。

表 2：样本类型与覆盖度表

任务类型	主要输入	主要输出	覆盖能力	工程价值
`image_description`	通用图像	场景描述	整图理解	建立视觉主语与场景表达能力
`counting_visual_qa`	通用图像	计数或问答	对象识别	建立显著主体识别与数量判断
`ocr_summary`	文档图像	文本摘要	图文联合	建立“看见字”到“读懂字”的过渡能力
`document_qa`	文档图像	问题回答	局部阅读	建立区域理解与条件提取能力
`chart_reading`	图表图像	趋势概括	结构阅读	建立数值关系与结构化解释能力
`region_grounding`	图像 + bbox	坐标答案	对象对齐	建立区域级监督与定位能力
`multi_image_comparison`	多图输入	对照总结	跨图推理	建立顺序意识、差异归纳与信息聚合能力

17.3 为什么 100% 通过率不能被过度解读¶

这组数字看起来很好，但更合理的解释是：项目在受控环境下做了小规模、高约束的数据工厂验证，因此质量更容易被压住。

这不是坏事，恰恰说明：在小范围里把方法跑通，才是后续扩大的前提。

但它也意味着，不能直接把这一结果外推到开放世界图像场景。

17.4 为什么 11/11 PASS 很重要¶

项目检查通过，意味着代码、产物、报告和训练接口之间建立了基本一致性。这类信息比“模型看起来效果不错”更有说服力，因为它直接体现了工程闭环。

18. 成本分析：吞吐与审查的平衡¶

当前结果显示了两项很有代表性的成本信息：

外部 caption 成本估算约 1.3 美元
人工复核成本约 267 元

这组数字不大，但已经能反映小型工厂的成本结构。

表 3：成本、耗时与人工投入表

项目	当前结果	说明
资产总数	87	三类资产均衡，各 29 条
训练记录	267	多任务派生后的最终训练总量
QA 可视化样本	29	支持 bbox 反向回查
质量通过率	100%	受控环境下的小规模结果
外部 caption 成本	$1.3	小型批量生成的模型成本
人工复核成本	267 元	说明多模态 QA 不是免费步骤
项目检查	11 / 11 PASS	代码、数据与报告闭环成立

18.1 为什么人工复核成本需要单独看¶

因为在多模态场景里，人工 QA 不是可有可无的最后一步，而是整个项目可信度的关键来源。尤其是 grounding、OCR 和图表类任务，完全不做人工抽检，风险会明显增大。

18.2 为什么 caption 成本不等于总成本¶

很多团队在做多模态数据预算时，只算模型 API 成本，而忽略：

派生资产准备成本
失败重试成本
可视化检查成本
人工审核成本
回退修改成本

这会导致预算判断严重偏乐观。P03 的意义之一，就是说明：多模态数据工厂的瓶颈，很多时候不在生成本身，而在审查与回路。

18.3 成本优化应优先优化什么¶

在这个阶段，更值得优化的往往不是每次调用少几分钱，而是：

哪些样本值得做人工复核；
哪些任务可以先用规则挡掉明显错误；
哪些复杂任务应控制数量、提高单条价值；
哪些中间产物要保留，避免重复生成。

19. 失败样本与局限：当前工厂的风险点¶

多模态项目尤其需要把限制与失败模式单独拆开，因为小规模演示阶段的顺利运行并不等于工程稳定。

19.1 当前最明显的局限¶

第一，资产规模仍小。87 条资产足够讲清方法，但不足以支撑广泛泛化结论。
第二，文档与图表仍以派生资产为主，离真实业务文档、票据、复杂仪表盘还有差距。
第三，多图样本规模较小，更像功能验证，而不是充分训练。
第四，质量通过率来自受控环境，不能被误写成“开放场景天然稳定”。

19.2 典型失败样本可以如何归类¶

这类失败样本至少可以归纳为以下几类：

视觉幻觉：图中不存在的对象被描述出来；
OCR 漏读：关键文字没提到；
图表误判：趋势或类别关系读错；
grounding 偏框：坐标偏到相邻目标；
多图混淆：把第一张和第二张图的信息串起来。

表 4：失败样本类型表

失败类型	典型表现	最可能来源	优先修复方向
视觉幻觉	回答写出图中不存在的对象或关系	开放式生成过度发散、重描述过满	收紧 prompt、增加显著对象约束
OCR 漏读	文档摘要遗漏关键字段或条件	OCR 中间层噪声、局部区域不清晰	加强中间层校验、提高抽检密度
图表误判	趋势、类别、数值关系读反	图表任务模板不稳定、结构理解不足	收紧图表模板、增加结构型示例
grounding 偏框	坐标落在相邻目标或框体越界	bbox 转换、归一化或图片版本不一致	反向画框核验、检查尺寸与 clamp
多图混淆	两张图的信息被串写到同一结论中	顺序控制不足、payload 组织不稳	加强顺序标识、控制多图样本复杂度

把这类失败样本汇总成“失败归因表”后，就能直接支撑下一轮模板收缩、QA 改写和抽检策略调整。

19.3 为什么失败归因需要细化到错误类型¶

因为“有噪声”太泛，无法指导下一轮迭代。只有写成错误类型，才能真正支持：

prompt 调整
模板收缩
QA 规则改进
任务边界重划

20. 项目检查：一致性验证闭环¶

P03 当前共有 11 项检查，并全部通过。

20.1 为什么要做项目检查¶

如果一个多模态数据项目只有图片和 JSON 文件，没有检查机制，那么它是否正确其实并不清楚。因为错误可能来自很多地方：

文件存在但字段不对；
多图样本格式正确但只含一张图；
bbox 有值但不在合法范围；
train/val 切分泄漏；
报告数字和训练文件数量不一致。

20.2 本项目检查覆盖了什么¶

当前检查覆盖了：

命令级检查：py_compile、evaluate_factory
数据/产物级检查：必需文件存在、资产类型覆盖、对齐样本含 bbox、多图样本确为多图、train/val 无 overlap、smoke 覆盖多个任务等

20.3 为什么这一步是工程完整性的体现¶

因为它意味着项目不是“肉眼觉得差不多”，而是在代码、数据、训练接口和报告之间形成了一个一致性闭环。

从工程复用角度看，这类闭环信息往往比单个示例更有迁移价值。

21. 与项目二的呼应：跨项目一致的方法骨架¶

虽然 P02 是法律文本工厂，P03 是多模态工厂，但两者在数据工程方法上有很强呼应关系。

21.1 一致点一：都强调“种子层”¶

P02 先建法规种子文本，P03 先建多模态资产池。本质上都不是直接生成监督，而是先构建可靠输入层。

21.2 一致点二：都强调任务拆分¶

P02 把法律任务拆成 legal QA、法条解释和案情分析；P03 则把多模态任务拆成描述、OCR、图表、grounding 和多图比较。两者都说明：

好的数据工厂，核心不是多做样本，而是把不同能力拆开生产。

21.3 一致点三：都强调 QA 前置¶

P02 的重点是审核协议与风险拒答，P03 的重点是可视化反查与失败样本库。虽然具体形式不同，但都在强调：质量控制必须进入生产线，而不是留到训练后。

21.4 一致点四：都强调训练交付层¶

两章最后都不是停在“样本生成完了”，而是继续下探到训练切分、manifest、报告、检查脚本与交付物。

从整体结构看，P03 与 P02 保持了相似的工程展开顺序：

先讲为什么；
再讲边界；
再讲分层架构；
再讲 step-by-step；
最后讲结果、成本、局限与迁移。

22. 后续扩展：走向更真实的多模态 Agent 场景¶

P03 的价值，不在于它已经把多模态数据做到了很大，而在于它搭出了一个可扩展的最小工厂。

下一步如果继续扩展，可以优先沿以下几个方向推进。

22.1 从单图走向多页文档¶

把文档图像从单页截图扩展到多页 PDF、长截图、表单与票据组合，才能进一步测试长上下文图文理解能力。

22.2 从静态图表走向复杂结构图¶

把当前图表任务扩展到真实 BI 面板、混合图表、仪表盘和多图联动，会更接近企业分析场景。

22.3 从多图比较走向任务型 Agent 输入¶

例如把网页截图、表格截图、说明文档和操作界面放到同一个样本中，让模型学习“读图—比对—执行建议”这类更贴近 Agent 的能力。

22.4 从受控 QA 走向半自动评审面板¶

随着样本规模扩大，纯人工抽检会很快成为瓶颈。下一步更合理的方向，是建设更系统的多模态质检面板、错误标签体系和分层抽样策略。

23. 主要交付物清单¶

23.1 中间数据产物¶

data/processed/asset_manifest.jsonl
data/processed/asset_collection_summary.json
data/processed/llava_instruct.jsonl
data/processed/llava_alignment.jsonl
data/processed/llava_interleaved.jsonl
data/processed/quality_audit.jsonl
data/processed/low_quality_flags.jsonl
data/processed/manual_review_samples.jsonl
data/processed/qa_visual_audit.jsonl

23.2 训练数据产物¶

data/training/final_llava_dataset.jsonl
data/training/train.jsonl
data/training/val.jsonl
data/training/smoke_test.jsonl
data/training/training_manifest.json

23.3 报告与检查产物¶

data/reports/p3_metrics.json
data/reports/p3_report.md
data/reports/p3_test_results.json
data/reports/p3_test_report.md

表 5：交付物清单表

类别	代表文件	作用
资产与中间层	`asset_manifest.jsonl`、`llava_alignment.jsonl`、`llava_interleaved.jsonl`	记录资产来源、任务派生与中间样本状态
质检与审核层	`quality_audit.jsonl`、`low_quality_flags.jsonl`、`qa_visual_audit.jsonl`	沉淀规则检查、低质量样本与可视化复核结果
训练交付层	`final_llava_dataset.jsonl`、`train.jsonl`、`val.jsonl`、`smoke_test.jsonl`、`training_manifest.json`	提供训练、验证与连通性检查入口
报告与验证层	`p3_metrics.json`、`p3_report.md`、`p3_test_results.json`、`p3_test_report.md`	记录指标、结论与项目级检查结果

24. 结语¶

对于多模态训练来说，真正难做的往往不是“让模型看到图片”，而是让图片、文字、区域和任务关系一起变成可信的监督数据。

P03 这个案例的价值，不在于样本规模已经很大，而在于它把多模态数据工程中最关键的几个问题浓缩进了一条可以复现的小型流水线：

先建设资产层，而不是直接生成；
再按任务谱系拆分监督，而不是只有 caption；
对 grounding 做严格对齐，而不是坐标随便转；
对样本做可视化抽检，而不是只看文本通顺；
最后交付训练切分、manifest、报告与检查闭环，而不是只留下一份 JSON 文件。

这个案例最重要的启发是：

多模态数据工厂，不是图片越多越好，而是要把“资产、任务、质量、交付”四层一起设计出来。

只有当这些层被一起设计并串成闭环时，多模态项目才真正从演示样例变成了可扩展的工程系统。

专题：多模态标注的抽检与错误回放¶

LLaVA 类数据工厂还有一个非常重要、但经常被轻描淡写的部分，就是抽检与错误回放。因为多模态样本的错误往往并不体现在一句文本里，而是体现在图像、框、文本和任务关系的错位上。如果没有稳定的抽检和 replay 机制，团队很容易在样本量增加的同时失去对质量的直觉。

一、抽检要优先看“关系对不对”¶

与纯文本数据不同，多模态样本最值得优先检查的不是句子是否通顺，而是关系是否成立。例如：

框选区域是否真的对应描述对象；
问答是否真的依赖该图像，而不是纯常识就能答；
多图比较任务是否真的比较了不同图片中的信息；
interleaved 样本里的图文顺序是否支持当前任务。

这些关系一旦错位，哪怕文本本身写得很顺，样本仍然会变成低价值监督信号。

二、错误回放应成为数据工厂的固定资产¶

P03 这类项目特别适合把高频错误沉淀为 replay 集。比如：

框坐标映射正确但语义对象错了；
图表读到了标题，却没有读到关键趋势；
多图样本里模型被相似背景误导；
文档截图里的正文、批注和表格关系被打散。

把这些问题固定为 replay 样本后，团队就能在每次迭代时快速验证“这类错有没有真正变少”。对多模态数据工厂来说，replay 集往往比一次性大规模抽检更能支撑长期质量改进。