pixmo-docs

背景：多模态模型的「偏食」困境

当你用 GPT-4V 或 Claude 读一张复杂的科学图表时，它往往能给出精准的解读——但你可能不知道的是，这些模型的"视觉能力"其实相当挑食。它们擅长处理自然照片，却经常在文字密集型图像上栽跟头：图表里的数据趋势读不出来，LaTeX 公式渲染成乱码，电路图看不懂走向。

问题出在数据上。多模态模型的"视觉"能力，取决于训练时喂给它什么样的图像。真实世界中的文本密集图像（如图表、文档、电路图）稀缺、标注成本高、且涉及版权问题。这成了 AI 领域的一个公认瓶颈。

Allen Institute for AI（Ai2） 的一支研究团队决定用一种看似"笨"但实际上极其聪明的办法解决这个问题：让 AI 自己生成自己的训练数据。他们在 2025 年 ACL 论文中开源了 PixMo-Docs，一个包含 25 条生成管线的合成数据生产系统，专门用于批量生产高质量的文本密集型图像。

核心原理：用代码生成替代人工标注

PixMo-Docs 的设计哲学可以概括为一句话：让 LLM 写代码，用代码渲染图像，再让 LLM 标注图像。整个流程形成了一个优雅的三方循环：

第一步：LLM 生成主题和数据。 给定一个图表类型（如"折线图"）和一个领域（如"全球碳排放"），GPT-4o 负责构思数据的具体数值和元数据。这一步确保了数据的多样性和真实性——LLM 可以自由发挥，创造出人类可能想不到的组合。

第二步：代码渲染图像。 系统内嵌了 25 条不同的渲染管线，每条管线对应一种特定的图像生成工具。MatplotlibChartPipeline 用 Matplotlib 画图表，PlotlyChartPipeline 用 Plotly，LaTeXChartPipeline 用 TikZ 写 LaTeX 代码来渲染……每种工具都有自己擅长的领域，组合起来覆盖了科学文献中几乎所有类型的图文内容。

第三步：LLM 自我标注。 渲染出的图像交给同一个 GPT-4o（或 Claude Sonnet）进行问答对（QA pair）生成。这一步非常关键：标注者拥有完整的原始数据（第一步生成的数据），因此可以生成高度准确的问题和答案，形成天然的数据标签。

25 条管线：覆盖科学文献的每一寸版图

PixMo-Docs 的 25 条管线按功能分为 8 大类别，每一条都对应一种真实世界中文档密集型图像的类型：

图表类（5 条）：Matplotlib、Plotly、Vega-Lite、LaTeX TikZ、HTML+CSS。其中 Matplotlib 和 Plotly 可以覆盖科学文献中常见的折线图、散点图、热力图、极坐标图等。

表格类（4 条）：LaTeX、Matplotlib、Plotly、HTML 分别渲染。LaTeX 表格管线擅长复杂结构（如跨列跨行的多级表头），而 HTML 管线则适合简单单层表。

文档类（3 条）：LaTeX、HTML、DOCX。LaTeX 管线可以生成学术论文风格的文档，HTML 管线支持复杂 CSS 样式，DOCX 管线则直接输出 Word 兼容文件。

图表类（3 条）：Graphviz、Mermaid、LaTeX TikZ。Graphviz 适合生成树状图、有向图；Mermaid 适合流程图、时序图；LaTeX TikZ 适合精确的几何示意图。

电路类（2 条）：SchemDraw 和 LaTeX circuit 库，用于生成电路原理图。

专业图形（6 条）：DALL-E 生成图像、RDKit 化学结构图、LaTeX 数学公式、LilyPond 乐谱、SVG 矢量图、Asymptote 数学图形。这一部分展示了系统极强的扩展性。

屏幕截图类（1 条）：HTML Screen Pipeline，使用 Playwright + Chrome 将 HTML 渲染为网页截图，模拟真实浏览器界面。

指向类（1 条）：HTML Document Point Pipeline，生成带结构化指针标注的 HTML 文档。

所有管线统一基于 DataDreamer 框架编排，DataDreamer 是一个用于构建 LLM 流水线的 Python 库，提供了 prompt 管理、输出解析和日志记录等基础设施。

为什么不用现成的开源数据？

你可能会问：网上那么多公开的图表数据集，为什么还要自己生成？

答案在于配对性（pairedness）。要让多模态模型学会解读图表，不仅需要图像本身，还需要知道"这个图表的正确解读是什么"。真实数据集要么缺少标注，要么标注质量参差不齐，要么格式不统一。更重要的是，不同图表工具渲染同一数据的方式完全不同——Matplotlib 和 LaTeX 画出来的图表风格截然不同，但背后的数据是相同的。如果模型只在某一种工具生成的数据上训练，就会在另一种工具上泛化失败。

PixMo-Docs 生成的每个样本天然包含了：原始数据、渲染代码、图像、QA 对。这四元组使得模型可以学到从数据→可视化→解读的完整链条，而不只是表面的图像模式。

数据规模与下游效果

PixMo-Docs 催生了 Ai2 的 Molmo 系列多模态模型。论文报告显示，在纯 PixMo-Docs 数据上训练的 Molmo，在文字密集型图像理解基准上达到了与 GPT-4V 和 Claude Sonnet 相当甚至更优的水平，而模型参数规模远小于这些商业闭源模型。

随后发布的 CoSyn-400K 数据集则将这一思路进一步扩展，使用改进后的管线生成了 40 万样本，涵盖更多文档类型和更复杂的数据结构。

技术架构：Datadreamer 驱动的流水线编排

从代码结构来看，系统采用 Datadreamer 框架统一管理所有管线的执行。main.py 作为入口脚本，接受命令行参数来选择管线类型、数量、LLM 模型等。pipeline/all_pipelines.py 定义了 DataDreamer session 并加载各管线实例。每个管线子目录（如 matplotlib_chart_pipeline/）包含：

• pipeline.py：管线主类，定义数据生成→渲染→QA 的完整流程
• generate_data.py：用 LLM 生成主题和原始数据
• generate_graphic.py：用对应工具（Matplotlib/Plotly/LaTeX 等）渲染图像
• generate_qa.py：用 LLM 生成问答对

主技术栈为 Python 3.10 + Datadreamer + OpenAI SDK + Anthropic SDK，渲染层则混合了 Matplotlib、Plotly、Vega-Lite、LaTeX、Graphviz、Mermaid、RDKit、LilyPond、SchemDraw 等十余种可视化库。

部署难度：不低，但有章可循

PixMo-Docs 并非开箱即用的工具，而是一套可配置的研究级数据生成系统。它的部署复杂度主要来自两个方面：

第一，依赖链极长。 整个系统需要同时安装 Python 科学计算栈（NumPy、Pandas、Matplotlib）、PDF 渲染工具（WeasyPrint、ReportLab）、化学结构工具（RDKit）、音乐工具（LilyPond）、图形工具（cairosvg）、浏览器自动化工具（Playwright + Chrome）。README 中明确列出了 5 类外部依赖，每一类在 Linux/macOS/Windows 上的安装方式各不相同。

第二，API Key 是硬性要求。 整个数据生成流程依赖 GPT-4o 和 Claude Sonnet 来生成数据和标注，必须提供有效的 OpenAI API Key 和 Anthropic API Key，且会产生相应的 API 调用费用。

第三，无容器化。 项目没有提供 Dockerfile 或 docker-compose.yml，无法通过容器快速复现环境。这对于研究团队内部使用问题不大，但对于想要复现的研究者来说门槛较高。

优点是：整个系统完全开源（Apache-2.0），代码结构清晰，每条管线独立可运行，不需要的管线可以注释掉。

局限与思考

PixMo-Docs 也存在一些值得注意的局限：

合成数据的分布偏移问题。 合成图像虽然质量高，但与真实世界的文档图像仍有细微差异（如字体渲染、纸张质感）。论文中提到需要将合成数据与少量真实数据混合训练才能达到最优效果。

LaTeX 环境是跨平台噩梦。 在非 Linux 系统上安装完整的 LaTeX 环境（Tex Live 完整版超过 5GB）是一个痛点。

API 成本不可忽视。 生成数十万高质量标注样本需要消耗大量 GPT-4o 和 Claude 的 API 配额，不是小型实验室能轻易承受的。

管线质量参差不齐。 部分管线（如 Mermaid、LilyPond）生成的图像类型较为小众，通用性有限。

行业意义：重新定义多模态数据

PixMo-Docs 的出现代表了一个趋势：用 AI 生成 AI 训练数据（Synthetic Data Generation）。在真实数据标注成本越来越高、隐私问题越来越敏感的背景下，这条路线正在成为扩展多模态模型能力的关键手段。Ai2 的实践证明了：通过精心设计的代码生成管线，可以在不依赖人工标注的情况下，生产出规模庞大、格式统一、标注准确的多模态训练数据。

对于想要复现或扩展这一工作的开发者，建议先从 MatplotlibChartPipeline 或 PlotlyChartPipeline 入手——这两条管线依赖最少（只需 Python 科学栈），生成速度最快，最适合练手。等熟悉了数据生成流程后，再逐步引入 LaTeX、Playwright 等重型依赖。