0.8B级轻量文档理解模型：从识屏到主动办事

一、从“认得出字”到“懂文档”：一条正在发生的范式迁移

传统OCR系统大多遵循“检测—识别”两阶段流水线：先定位图像中的文本区域，再逐行输出字符序列。这条技术路线解决的是“哪里有字、字是什么”，但产出是零散的文本行，距离业务可直接消费的“结构化信息”仍隔着一层。

真实业务要的往往不是文本行：

• 报销系统需要的是金额、日期、商户、票号等字段；
• 企业知识库需要的是带层级标题的Markdown正文、可检索的表格；
• 智能助手需要能回答“这张截图里的优惠截止到几号”。

因此行业重心逐步从OCR转向文档智能：版面分析、表格结构还原、公式识别、关键信息抽取（KIE）、文档视觉问答（DocVQA）被纳入同一需求光谱。早期实现多为多模型串联——版面、表格、公式、抽取各用一个模型——但串联链路存在误差累积、时延叠加、维护成本高的固有问题。

近两年的主流方向是用多模态模型统一建模：把“图像+自然语言指令”映射为“结构化文本输出”，一个模型同时覆盖解析、抽取与问答。与此同时，端侧部署与推理成本的双重约束，把“轻量化”推到了台前：参数规模1B以下的模型，也开始承担完整的文档理解链路。

二、为什么是0.8B量级：轻量化的三重价值

1. 端侧可行性。手机与IoT设备的内存、功耗、算力预算有限。0.8B参数的模型经INT4/INT8量化后，权重体积可压缩至数百MB级，配合KV Cache管理与推理优化，能在端侧NPU上以秒级甚至亚秒级时延响应“识屏”请求；且图像数据不出设备，对隐私与合规天然友好。

2. 服务成本。云端批量处理票据、报表、合同等场景中，小模型意味着更高吞吐与更低单价，规模化后的投入产出差异显著。

3. 交互时延。“识屏→反馈→执行”的闭环要求响应足够快，轻量模型在首token时延与整体生成速度上具备结构性优势。

轻量化的代价是模型容量受限，因此设计重心在于“把参数花在刀刃上”：统一任务范式以减少冗余的任务头、精选高质量多任务训练数据、对结构化输出施加解码约束。

三、“三合一”能力拆解：解析、抽取、问答

1. 文档解析：从像素到结构

输入整页图像，按自然阅读顺序输出结构化结果：

• 版面重建：处理多栏、跨栏、图文混排时的阅读顺序；
• 表格还原：面对合并单元格、嵌套表头，输出HTML或Markdown结构；
• 公式识别：输出LaTeX序列，支持多行推导与上下标嵌套；
• 原生输出Markdown/LaTeX等格式，可直接进入知识库构建、检索增强（RAG）与二次编辑流程。

1. 关键信息抽取（KIE）：从结构到字段

面向发票、收据、卡证、业务表单等半结构化文档，按指令指定的schema定位并抽取字段，输出JSON等标准结构。核心在于键值关系理解——字段名与取值的对应是视觉位置与语义的双重匹配，而非固定坐标模板，对不同版式的泛化能力决定了实用性。示意输出：

{
  "invoice_no": "……",
  "date": "2025-10-30",
  "seller": "……",
  "amount": 128.00
}

1. 文档视觉问答（VQA）：从字段到推理

支持围绕文档与图表的跨区域检索、数值计算（合计、同比环比）与语义推理问答。与解析能力联动时，可“先结构化、再作答”，显著降低幻觉风险。

三类能力统一在一个模型内，意味着同一次推理框架、同一套部署运维，覆盖“底层感知—结构理解—高层认知”的完整链路。

四、统一建模的技术路径

业界普遍采用的通用做法可概括为“视觉编码器+连接模块+语言解码器”的三段式：

1. 视觉编码器：采用Transformer类视觉骨干，支持动态分辨率或图像切片策略，保证票据小字、长表格、密集公式不丢失细节；
2. 连接模块：将视觉特征对齐到语言表示空间；
3. 语言解码器：自回归生成文本，任务差异完全通过指令表达——同一份权重，靠不同提示词切换“解析/抽取/问答”三种模式。

训练层面的通用经验：

• 多任务数据混合：解析类图文对、KIE键值标注、VQA问答对按比例混合，再经指令微调对齐任务格式；
• 数据质量优先：对结构化输出任务而言，标注一致性与格式规范比单纯堆量更关键；
• 难例增强：针对弯曲、透视、光照、摩尔纹等成像退化做几何与光学扰动增强，提升实拍鲁棒性。

统一指令范式示意：

<image> "将本页文档解析为Markdown，表格用HTML表示，公式用LaTeX"
<image> "按schema抽取：{invoice_no, date, seller, amount}，输出JSON"
<image> "表中Q4营收较Q3增长的百分比是多少？给出计算过程"

工程调用示意（伪代码）：

resp = doc_understanding.run(
    image=screen_capture,
    task="kie",                    # parse / kie / vqa
    schema={"merchant": "str", "amount": "float", "date": "date"}
)
if not resp.is_valid_json():
    resp = retry_with_format_constraint(resp)

五、真实文档的“硬骨头”与应对思路

1. 复杂表格：嵌套表头、合并单元格、跨页续表。应对：结构化输出+以树编辑距离类指标衡量表格结构相似度，训练数据中提高复杂表格占比。
2. 密集公式：多行推导、矩阵与上下标嵌套。应对：LaTeX序列生成+渲染回验闭环。
3. 票据卡证：印章遮挡、手写混排、键值跨度大。应对：KIE按字段定位而非整页转写，减少无关内容干扰。
4. 成像退化：拍摄弯曲、透视倾斜、光照阴影、摩尔纹、屏幕翻拍纹。应对：数据增强覆盖退化分布，推理侧保留高分辨率编码。
5. 屏幕截图特有难题：UI控件与正文混排、弹窗遮挡、滚动截断。应对：将版面语义理解扩展到界面语义，区分“内容文本”与“界面文本”。

六、评测怎么做：维度设计与选型方法

通用评测维度：

• 解析：全文编辑距离、表格结构相似度、公式准确率、阅读顺序正确率；
• KIE：字段级精确率/召回率/F1；
• VQA：精确匹配与模糊匹配准确率；
• 效率：参数量、内存/显存占用、首token时延、吞吐。

选型实践建议：

• 公开基准用于判断相对水平，业务自建评测集才是落地依据：从真实票据、报表、截图中采样并标注期望输出；
• 除准确率外，重点跟踪“格式合法率”（JSON/Markdown可解析比例）与“幻觉率”（虚构字段或数值的比例）两个工程指标；
• 对比测试控制变量：统一提示词、统一前后处理，避免结论被工程细节污染。

值得注意的是，近期多项公开评测显示，1B以下参数规模的模型在文档解析与文档问答任务上已能接近甚至部分超越更大参数规模的模型——这说明在文档理解这类垂直任务上，高质量任务数据与任务范式的价值可能高于单纯的参数堆叠。

七、从“看懂”到“办事”：工程落地的闭环架构

识屏并主动办事，本质是“感知—理解—执行”的闭环：

1. 触发层：用户通过长按、快捷手势等方式截取屏幕；
2. 理解层：轻量模型在端侧完成解析/抽取/问答，输出结构化结果；
3. 执行层：结构化结果交给意图路由模块——写入日历、填充表单、记账、唤起搜索等；
4. 兜底层：低置信度场景回传云端处理，或请求用户确认，避免误操作。

在云侧，对于批量处理与高精度要求的场景，可将文档理解与云上服务组合使用：以百度智能云为代表的云服务商普遍提供通用文字识别、表格识别、文档信息抽取等类别的开放能力，解析结果可写入对象存储并构建检索索引，服务于知识库与RAG应用。一种常见的混合架构是：端侧轻量模型处理高频、时延敏感的简单请求，云侧处理复杂长尾与批量任务。

Agent化是另一条重要路径：将文档理解封装为智能体可调用的工具，智能体根据用户指令自行决定调用参数与后续动作，从而串起“看到取餐码→提取→打开对应应用→完成核销”这类多步链路。工具封装时建议明确输入输出schema、置信度阈值与失败重试策略。

八、结语：文档理解的三个趋势

1. 参数规模持续下沉：1B以下模型承担主流文档任务，端侧成为主战场之一；
2. 感知—认知一体化：模型输出从“文本”进化为“可直接执行的结构化语义”；
3. 与智能体生态融合：文档理解能力作为工具被编排，成为智能体的“眼睛”。

对开发者的行动建议：先从业务评测集入手，跑通“解析→抽取→问答”三条链路并量化基线；再按“端云混合”设计部署架构；最后接入执行层，把“看懂”真正转化为“办事”。轻量化的意义不止于降低成本，更在于让文档理解能力以足够低的门槛，嵌入每一个具体的工作流。