你是否尝试过编辑扫描文档或源文件已丢失的 PDF？这通常是一种令人沮丧的体验。你可能想移动一个段落、更改标题级别或更新表格数值。在文字处理软件中，这易如反掌。但在文档图像中，这些元素仅仅是像素而已。

生成式 AI 的最新进展，尤其是扩散模型，彻底改变了图像创作。然而，它们在 文档编辑 方面却举步维艰。如果你要求标准的图像生成器“更改页眉中的日期”，它可能会把文字弄得模糊不清，产生虚构的字母 (出现幻觉) ，或者破坏表格的对齐。文档不仅仅是像素的集合；它们是结构化的信息——包含文本、布局、样式和层级结构。

在这篇文章中，我们将深入探讨 DocEdit-v2 , 这是一篇提出复杂框架来解决这一确切问题的研究论文。通过利用大型多模态模型 (LMMs) 和一种新颖的定位 (grounding) 架构，研究人员创建了一个能够理解用户意图、找到文档中确切位置并执行精确结构化编辑的系统。

核心挑战: 为什么文档编辑很难？

要理解为什么 DocEdit-v2 是必要的，我们首先需要了解这项任务的难度。语言引导的文档编辑涉及三个主要障碍:

  1. 多模态定位 (Multimodal Grounding) : 模型必须理解用户指的是图像中的 哪里。如果用户说“更改第二个要点”，模型需要在视觉上从众多要点中定位到那一个特定的要点。
  2. 消歧 (Disambiguation) : 用户的请求通常很含糊。“让它看起来更好”或“移动 Logo”需要模型解读出需要更改的具体属性 (位置、样式、内容) 。
  3. 结构保真度 (Structural Fidelity) : 编辑后的效果必须看起来专业。文本必须清晰可读，字体必须匹配，布局不能乱。像素级的生成通常会在此失败。

DocEdit-v2 的作者假设，解决方案不是直接生成新的像素，而是操纵文档底层的 HTML 和 CSS 表示。

DocEdit-v2 框架

DocEdit-v2 框架是一个端到端的流程，旨在弥合用户自然语言请求与结构完美的文档编辑之间的差距。

图 1: DocEdit-v2 框架概览。

如上图 1 所示，该过程流经三个不同的阶段:

  1. Doc2Command: 视觉定位和编辑命令生成。
  2. 命令重构 (Command Reformulation) : 将技术命令翻译为 LMM 的指令。
  3. 文档编辑 (Document Editing) : 使用 LMM (如 GPT-4V 或 Gemini) 生成最终的 HTML 结构。

让我们分解每个组件。

1. Doc2Command: 整个操作的“大脑”

第一步是弄清楚要做什么以及在哪里做。研究人员引入了一个名为 Doc2Command 的新颖组件。这是一个多任务模型，负责 多模态定位 (找到感兴趣区域，即 RoI) 和 命令生成 (将请求转换为结构化动作) 。

架构

Doc2Command 的架构非常迷人，因为它将用户的请求视为一个视觉元素。

图 2: Doc2Command 架构。

如图 2 所示，该过程如下运作:

  1. 视觉渲染: 用户的文本请求实际上被渲染 到 文档图像本身上 (视觉上放置在顶部) 。
  2. 图像编码器: 这个组合的视觉输入被送入一个视觉 Transformer (ViT) 编码器。这使得模型能够在同一个视觉空间中同时处理文档布局和文本请求。
  3. 双输出流:
  • 文本解码器: 一个分支生成结构化的文本命令 (例如，ACTION_PARA: REPLACE, COMPONENT: TEXT) 。
  • 掩码 Transformer (Mask Transformer) : 另一个分支生成“分割图”。这是一个像素掩码，精确地高亮显示文档中需要更改的部分。

视觉定位实战

能够准确分割文档是这种方法与众不同的地方。模型不是仅仅猜测坐标，而是预测一个覆盖特定文本或对象的掩码。

视觉定位示例: 识别表格。

在上面的例子中 (图 5b) ，请注意模型 (以亮白色高亮显示) 是如何根据请求准确识别复杂的表格结构的。它不只是在整页周围画一个框；它隔离了感兴趣的特定元素。

视觉定位示例: 区分相同的文本。

此外，如图 5c 所示，该模型具有上下文感知能力。如果存在多个相似文本的实例，它会利用位置线索 (如“从中间到左边”) 来定位正确的实例。

2. 命令重构: 跨越鸿沟

Doc2Command 模块输出结构化命令，但这些命令通常是僵化且特定于软件的 (源自为程序化编辑设计的数据集) 。它们可能看起来像 MODIFY ACTION_PARA TEXT...。

虽然精确，但这些命令并不是通用大型多模态模型 (如 GPT-4V) 的最佳“提示词 (prompt) ”。这些模型更喜欢自然、描述性的指令。

为了解决这个问题，研究人员利用了 命令重构 。 他们使用 LLM 将 Doc2Command 的僵化命令翻译成流畅、明确的指令。

原始命令与重构指令的对比。

图 3 展示了这种转换。

  • (a) 左侧: 原始命令可能只是简单地说“MODIFY… FINAL_STATE”。这很晦涩。
  • (b) 右侧: 重构后的命令将其翻译为一个清晰的指令: “修改文本内容……专门针对出现排放相关术语的组件。”

这一步解决了歧义。如果用户请求很模糊，重构步骤会利用上下文在最终编辑发生之前充实细节。

3. 基于 HTML/CSS 的生成式文档编辑

这最后一步或许是最关键的设计选择。DocEdit-v2 没有使用扩散模型来“修补 (inpaint) ”新文档 (这有文本模糊的风险) ，而是要求 LMM 生成 HTML 和 CSS 。

HTML 提供层级结构 (标题、段落、表格) ，CSS 提供样式 (字体、颜色、对齐) 。

该框架为 LMM 构建了一个提示词，其中包括:

  1. 重构后的指令 (做什么) 。
  2. 视觉定位 (由 Doc2Command 找到的边界框坐标) 。
  3. 文档图像 。

然后，LMM 充当程序员的角色，重写文档的结构以反映更改。这确保了输出清晰、可搜索且完美对齐。

实验与结果

研究人员在 DocEdit 数据集上测试了 DocEdit-v2，并将其与包括标准 GPT-4 和特定任务模型 (如 DocEditor) 在内的强基线进行了比较。

定位与检测性能

首先，系统找到正确位置的能力如何？

表 2: 边界框检测结果。

表 2 显示了边界框检测任务的结果。 Doc2Command 实现了 48.69% 的 Top-1 准确率 , 超过了之前的最先进技术 (DocEditor) 12% 以上。这是视觉定位方面的巨大飞跃，证明了专用的编码器-解码器架构在定位方面非常有效。

端到端编辑质量

终极测试是最终文档的质量。研究人员使用标准文本指标 (ROUGE-L) 和人工评估指标 (样式复刻、编辑正确性) 对此进行了测量。

表 3: 使用 GPT-4V 的端到端编辑结果。

表 3 显示了使用 GPT-4V 作为骨干网络时的性能。

  • 完整流程胜出: 底部几行 (“DocEdit-v2”) 在几乎所有指标上都显示出最高分。
  • 消融研究: 注意那些“VG” (视觉定位) 或“CR” (命令重构) 标记为“X”的行。性能显著下降。例如，如果没有视觉定位，系统很难知道 在哪里 应用编辑，导致“编辑正确性”较低。

当使用 Gemini 作为基础模型时，同样的趋势也成立，如下面的表 4 所示:

表 4: 使用 Gemini 的端到端编辑结果。

定性示例

数字虽好，但眼见为实。让我们看一个涉及移动元素的复杂示例。

图 10: 移动布局元素的示例。

在图 10 中，用户要求“将 ‘Bridge Loan and Bond’ 从中间移到左边。”

  1. 定位: 中间面板显示 Doc2Command 识别出了特定的文本块和页码。
  2. 重构: 系统将其解释为涉及特定组件的“移动”动作。
  3. 结果: 最终面板显示了 HTML 输出，其中文本块已成功重新定位到左栏，并保持了字体样式和周围布局。

新任务的新指标

由于像素级指标 (如 RMSE) 对文档来说很糟糕，研究人员引入了两个新指标:

  1. DOM 树编辑距离 (DOM Tree Edit Distance) : 衡量 HTML 结构改变了多少。
  2. CSS IoU (交并比) : 衡量样式与真实情况的匹配程度。

指标的相关性热图。

图 4 显示这些新指标与人类判断有很好的相关性。特别是 CSS IoU 与“样式复刻 (Style Replication) ”有很强的正相关性 (0.73) ，证实了如果 CSS 代码匹配，文档在人眼看来就是正确的。

结论

DocEdit-v2 代表了智能文档处理向前迈出的重要一步。通过摆脱纯像素编辑并拥抱结构化表示 (HTML/CSS) ，它解决了在自动编辑过程中保持文档清晰和专业的问题。

该框架的成功依赖于其组件的协同作用:

  • Doc2Command 提供“眼睛”，准确发现 哪里 需要更改。
  • 命令重构 充当翻译官，将模糊的意图转化为清晰的指令。
  • 多模态 LMM 充当执行者，编写代码来重建文档。

对于该领域的学生和研究人员来说，这篇论文突显了 混合方法 的力量——结合专用的视觉模块与通用的大型语言模型来解决复杂的多步骤任务。该领域未来的工作可能会集中在更复杂的视觉元素上，例如直接在文档结构内编辑图表和图解。