轻量级多任务文档理解模型的技术解析

一、背景：文档理解为什么要走向”单一轻量模型”

文档理解长期以来是一个被拆散的技术栈。传统方案通常由三到四个相互独立的模块拼接而成：版面分析负责切分标题、正文、表格、公式等区域；文本识别（OCR）负责把区域图像转成字符；表格结构恢复和公式识别各有一套专门的解析器；最后再用规则或小模型做关键字段抽取。这套流水线的问题在于错误会级联——版面切分偏一点，OCR 就会截断半行文字；公式识别错一个符号，后续的结构化输出就整体失效。更现实的问题是部署成本：多个模型意味着多份显存占用、多套推理调度逻辑，在手机端、边缘设备上几乎是不可承受的。

由此产生了一个明确的工程命题：能否用单一模型同时覆盖文档解析、关键信息抽取与 OCR 视觉问答三类任务，并且把参数量压到 1B 以下，使其可以真正落到端侧？本文围绕这一命题，解析一个 0.8B 规模的轻量级文档理解模型在架构设计、数据构造、训练范式和部署集成上的完整思路。

需要说明的是，参数量小并不等于能力弱。0.8B 这个量级的设计取向是：用高质量数据和精心设计的训练目标，替代单纯的参数堆叠，从而在受限算力下获得可用的文档结构化能力。

二、统一建模：三类任务、一个模型

2.1 任务定义与输出形态

所谓”统一覆盖三类任务”，指的是模型在同一个权重下，通过不同的输入提示（prompt）完成任务切换：

• 文档解析：输入整页或区域图像，输出结构化的 Markdown，保留标题层级、段落、列表、表格、公式等结构信息；
• 关键信息抽取：输入文档图像加字段描述，输出 JSON 格式的键值对，例如从账单中抽取金额、商户、时间；
• OCR 视觉问答：输入图像加自然语言问题，输出自由文本答案，例如”这张取餐码的号码是多少”。

用代码示意其调用形态大致如下：

# 伪代码：统一接口，任务由 prompt 决定
def infer(image, task, schema_or_question):
    if task == "parse":
        prompt = "将文档解析为 Markdown，保留表格与公式结构。"
        return model.generate(image, prompt)          # -> Markdown string
    elif task == "extract":
        prompt = f"按以下字段抽取信息，返回 JSON：{schema_or_question}"
        return model.generate(image, prompt)          # -> JSON string
    elif task == "vqa":
        return model.generate(image, schema_or_question)  # -> free text

这种设计的价值在于：解析任务产出的中间结构，本身就是抽取任务最好的上下文。多任务联合训练让模型在处理表格时，天然带着”这个单元格将来可能被当作字段值”的意识，从而在结构恢复时更注重语义边界，而不是纯粹的视觉边界。

2.2 结构化输出为何关键

支持 Markdown 与 JSON 两类结构化输出，是把模型能力接入业务系统的前提。自然语言描述对下游不可用，而 Markdown 可以直接渲染、可以索引、可以再切分，JSON 可以直接入库、可以参与字段级校验。因此模型在训练阶段就把”输出必须是合法结构”当作硬约束的一部分，而非事后用解析器兜底。

三、数据：异构专家共识与闭环校验

轻量模型的瓶颈几乎永远在数据，而不在架构。该模型训练累计使用约 1.7 亿条 OCR 与文档理解样本，其构造流程有两个值得拆解的机制。

3.1 异构专家共识机制

对同一份文档，正文、表格、公式等不同区域的识别难度差异很大：正文考验连字和倾斜，表格考验行列线与合并单元格，公式考验上下标与符号结构。单一标注来源很难在三类区域都保持高准确率，因此采用多专家模型交叉校验 + 投票筛选的方式：

1. 让多个来源不同、结构不同的识别模型分别对同一区域产出候选结果；
2. 对候选结果做一致性比对，字符级和结构级同时计算；
3. 只有达到高置信度的一致结果才进入训练集，分歧样本进入人工或规则复核队列。

这样做的收益不只是”标注更准”，更重要的是标注噪声的分布是可控的——分歧集中在真正困难的区域，而不是随机散布在简单样本上。

3.2 预测—重渲染—视觉比对的闭环

表格和公式的错误往往非常隐蔽：少一条竖线、错一个下标、行序颠倒，在字符层面看可能只差一两个 token，但语义已经完全改变。针对这类问题，引入了一个可自我验证的闭环：

• 预测：模型或标注器给出候选解析结果；
• 重渲染：把候选结果按标准排版重新渲染成图像；
• 视觉比对：将重渲染图像与原始文档区域做像素级与结构级比对，定位行列错位、符号缺失、对齐异常；
• 定向修正：只针对比对出的差异位置做修正，而不是整页重标。

这个闭环的工程意义在于，它把”标注对不对”这个难以判断的问题，转化成了”渲染回来像不像”这个可以自动计算的问题，从而大幅降低了人工复核成本。

3.3 长尾样本的合成

真实场景中的文档远比标准扫描件复杂。为此按版面复杂度、字体形态与物理退化因素三个维度合成困难样本，并补充多语种、古籍手写、屏幕摩尔纹、扭曲光照等长尾数据。屏幕拍摄类样本尤其重要，因为手机端真实输入大量来自”对着屏幕拍照”而非”导出 PDF”。

四、三阶段训练：从视觉锚定到可验证奖励

训练被划分为三个阶段，每一阶段解决一个明确的问题。

4.1 阶段一：Q-Mask 文本锚定

多模态模型在早期容易出现”视觉与文本对不上”的问题，即模型倾向于靠语言先验猜内容，而不是真的看图。Q-Mask 文本锚定通过掩蔽部分文本 token，强制模型将视觉局部区域与对应文字 token 建立空间对应关系。可以理解为一种细粒度的对齐监督，让注意力真正落到正确的图像区域上。

4.2 阶段二：OCR 持续预训练

在基座模型之上，用百亿级 Token 的多任务混合数据做持续预训练，把通用语言能力迁移到文档领域。这一阶段的目标是打底：让模型熟悉版面语言、表格语法、公式符号体系，形成稳定的领域先验。

4.3 阶段三：混合任务强化学习

第三阶段是最有技术特色的部分。在困难样本上使用可验证奖励信号做强化学习，具体包括三类：

奖励信号	适用任务	说明
结构编辑距离	文档解析	衡量输出 Markdown 与参考结构的差异
表格匹配度	表格解析	单元格级、行列级的匹配程度
问答准确率	OCR 视觉问答	答案是否正确

选择”可验证奖励”而非人工偏好打分，是因为文档任务的正确性大多可以被程序化判定——表格对不对可以逐格比对，JSON 字段对不对可以精确匹配。这让强化学习信号更稳定、更廉价，也更适合在小模型上收敛。

五、部署与集成：从权重到智能体工具链

模型权重与推理代码公开之后，真正的落地还差”最后一公里”。围绕这一点，除了权重之外，还提供了几类配套形态：

• 浏览器交互式 Demo：无需本地环境即可试跑，适合快速验证能力边界；
• MCP 服务：以标准协议对外暴露文档理解能力，便于接入各类智能体框架；
• Agent Skill 工具包：以指令文件的形式描述安装与调用流程，向智能体发送该指令后，可自动完成环境配置与本地部署。

这实际上是一种”面向智能体分发”的思路：模型不再只是一个需要工程师写代码调用的库，而是一个可以被智能体自行发现、自行安装、自行编排的能力单元。对于希望把文档理解嵌入自有业务流的团队，这意味着集成成本从”读文档写适配层”降低到”描述需求”。

六、典型应用场景

在端侧场景中，文档理解最直接的价值是屏幕信息解析。手机屏幕上出现的文本，绝大多数不是标准文档，而是被界面切割、被状态栏遮挡、被动态刷新的碎片化信息。典型场景包括：

• 即时生活服务：外卖取餐码、快递取件码、退货码、寄存柜编号、餐厅排队号。系统需要识别屏幕字段与状态，并提取时效性信息（例如”该码 30 分钟内有效”）；
• 财务管理：从消费账单详情中提取交易金额、商户名称、支付时间与消费类别，直接用于记账，省去手工录入。

这两类场景的共同点是：输入是截图、输出是结构化字段、时延要求高、隐私要求强。0.8B 的轻量设计正好匹配这种需求——可以在本地完成推理，不必把包含金额、取件码的截图上传到远端。

七、小结与工程启示

从这一方案中可以提炼出几条对做端侧多模态应用有普遍参考价值的经验：

1. 统一多任务优于流水线拼接。任务之间的结构信息可以互相增强，且只需维护一份权重和一套调度。
2. 小模型的胜负在数据，不在参数。专家共识投票、重渲染闭环校验、长尾合成，本质都是在有限的标注预算下最大化数据质量。
3. 把正确性变成可计算量。无论是渲染比对还是强化学习的奖励设计，核心思路都是让”对不对”可被程序判定，从而摆脱对人工评估的依赖。
4. 能力分发要面向智能体。标准协议服务加可执行的技能指令，正在成为模型落地的新形态。

对于需要在移动端、边缘设备或隐私敏感场景中处理文档的开发者而言，轻量多任务模型提供了一条兼顾能力、成本与合规的现实路径。选型时应重点验证三件事：结构化输出的合法性、困难样本（表格、公式、屏幕拍摄）上的稳定性，以及本地推理的实际时延与内存占用。