0.8B文档理解模型：让终端看懂文档、主动办事

一、需求变迁：从“认得出字”到“办得成事”

日常生活中，文档处理的“最后一公里”始终存在：外卖取餐码淹没在长串聊天记录里，需要翻找截图；看到一张演出海报，时间地点还要手动敲进日历；报销时，账单金额、商户名称、交易时间得逐项誊抄进表格。这些琐碎场景共同指向一个尚未被充分满足的需求——设备能否不只是“看见”屏幕上的内容，而是“看懂”其中的信息结构，并在恰当的时机顺手完成下一步动作。

这一需求正推动OCR技术范式发生迁移。传统OCR的核心指标是识别准确率，即把图像中的文字逐行转写为文本；但在真实业务里，识别只是起点。学术论文包含跨行公式与多栏排版，财务研报内嵌层级复杂的表格，票据卡证则隐含“字段名—字段值”的键值关系；拍照与屏幕翻拍还会引入透视倾斜、弯曲形变、光照阴影与摩尔纹等干扰。因此，一套实用的文档智能系统必须同时做到三件事：认得出字、拆得开结构、答得上问题。行业的能力重心也因此从“文字识别”推进到“文档理解”——在感知层之上叠加版面分析、结构还原与语义推理。

二、三合一能力矩阵：解析、抽取与问答

近期业界的一个代表性方向，是在0.8B（约8亿参数）量级的轻量模型中统一建模三类能力，以尽量小的参数规模覆盖从底层感知到高层认知的完整链路。

1. 文档解析（Parsing）：识别并还原文档的正文、复杂表格与数学公式，按自然阅读顺序输出结构化结果，原生支持Markdown、LaTeX等通用格式。这类输出可直接用于二次编辑、知识库构建与检索增强（RAG）场景——文档一旦被还原为带层级的Markdown，切块、向量化与召回的质量都会显著提升，而不是把版面信息压扁成无结构的纯文本。

2. 关键信息抽取（KIE）：面向发票、收据、卡证与业务表单等半结构化文档，按指定字段定位并抽取目标信息，输出JSON等标准结构化数据。与“先全文识别、再后处理正则”的两段式方案相比，端到端的字段级抽取能天然利用位置与键值关系线索，对“字段名与字段值分行排布”“表格内嵌字段”等复杂情况更鲁棒，也更易对接下游自动化工作流。

3. 视觉问答（VQA）：支持围绕文档与图表的跨区域检索、数值计算与语义推理问答。例如“这份研报中毛利率最高的季度是哪个”“表格第三列的合计是多少”，模型需要在多个区域间跳转定位、完成运算再作答。VQA相当于把文档变成“可对话的数据源”，是交互式理解的关键形态。

三类能力并非简单拼接。解析为抽取提供版面先验，抽取为问答提供字段级定位，问答反过来倒逼模型对语义与数值细节保持敏感。统一建模让三者共享视觉编码与语言解码主干，在训练中相互增益，也避免了多模型串联带来的误差累积与推理开销。

三、轻量化为何难：约束下的工程取舍

在1B以下参数量里同时做好三件事，难度远高于做一个“缩小版大模型”。主要矛盾体现在三方面：

其一，表征带宽与版面复杂度的矛盾。高分辨率输入是文档理解的刚需——跨页大表格的单元格边界、一个不起眼的上标符号，在低分辨率下会直接消失。但高分辨率意味着视觉token数量激增，对轻量模型构成序列长度压力。业界通行的解法是动态分辨率与视觉token压缩：对文字密集区域保留高精度表征，对空白与装饰区域做激进下采样，在信息量与序列长度之间取得平衡。

其二，任务异质性与联合训练的矛盾。解析要求逐token的忠实还原，抽取要求字段级精确定位，问答要求跨区域推理，三者的监督信号形态各不相同。常见做法是采用统一的指令化数据格式，把三类任务都表述为“图像+指令→文本”，再通过课程学习控制任务配比与难度递进：先夯实识别与版面，再进阶到抽取与推理。

其三，真实退化的泛化难题。扫描件、翻拍屏、褶皱票据的形变与噪声，靠人工标注难以穷举。合成数据因此成为标配：用文档渲染引擎批量生成带可控退化（模糊、透视、摩尔纹、水印）的训练样本，再辅以少量高质量真实数据对齐分布，可显著提升鲁棒性。

从结果看，轻量并不必然意味着能力妥协。近期公开的评测实践显示，0.8B量级的文档理解模型已能在业界权威综合文档解析基准上取得96分以上的成绩，在1B以下档位位居前列；在多项文档VQA任务上平均分超过83，不仅优于同量级方案，甚至逼近参数规模数倍于己的更大模型。这说明文档理解这一任务族与模型规模并非线性关系——任务结构性强、输出空间相对收敛，配合充分的数据工程，小模型同样能打出极高的性价比。

四、端侧落地：识屏、办事与智能体集成

轻量化的真正意义在端侧。0.8B量级模型经INT8/INT4量化后，权重体积与运行内存可压缩至主流移动设备可承受的范围，并能利用端侧NPU加速，实现无网、低延迟、隐私数据不出设备的本地推理。这为“一键识屏”类体验提供了技术底座，其典型流水线为：

截屏 → 文档解析（还原版面与结构）→ 语义理解（判断屏幕上是什么信息）→ 意图触发（推测用户可能需要的下一步）→ 动作执行（写入日历、复制取餐码、生成待填表单）。

在智能体（Agent）架构下，这套能力还能进一步产品化。业界通行做法是同步开放模型权重与推理代码，并提供交互式Demo与技能工具包：把模型能力封装为标准化工具描述，智能体读取一份技能说明文件后，即可按需调用解析、抽取与问答接口。示意如下：

# 示意性伪代码：将文档理解能力接入智能体工具链
skill = load_skill("doc-understanding.skill")   # 读取技能描述
agent.register_tools(skill.tools)               # 注册 parse / extract / ask 三类工具
result = agent.run("帮我把这张海报的时间地点加进日历")
# 内部流程：
# 1. 获取屏幕截图 -> doc_parse() 还原结构化版面
# 2. doc_extract(fields=["event", "time", "location"]) 输出JSON
# 3. 调用系统日历接口写入日程

三类任务的调用形态也可各自独立封装，形成稳定的输出契约：

# 解析：图像 -> Markdown/LaTeX 结构化文本
md = model.parse(image, output_format="markdown")
# 抽取：按字段契约输出 JSON，便于对接自动化工作流
bill = model.extract(image, schema={"商户": str, "金额": float, "日期": "YYYY-MM-DD"})
# 问答：面向图表的跨区域检索与数值计算
answer = model.ask(image, question="表中Q3的环比增速是多少？")

值得强调的是输出契约设计：解析任务约定格式后缀，抽取任务约定字段schema，问答任务约定引用定位。稳定的输出契约是“模型能力可被程序可靠消费”的前提，也是从Demo走向生产的关键一步。

对于计算密集或长尾复杂的文档任务，端云协同是更务实的选择：高频、简单、隐私敏感的请求留在端侧处理；复杂版面还原、跨页深度推理等任务上传云端更大规模模型完成。云端可依托百度智能云的模型服务、容器平台与对象存储等通用产品类目，完成模型托管、弹性扩缩容与文档归档，形成“端侧轻模型保体验、云端大模型保上限”的分层架构。

五、评测与选型：别只看单一榜单

文档理解模型的评估容易失真，建议从四个维度建立自己的评测体系：

1. 综合解析质量：在业界通行的综合文档解析基准上考察整体得分，同时拆开看正文、表格、公式三个子项——多数模型强于正文而弱于公式，短板往往藏在子项里。
2. 字段级抽取准确率：用业务真实的票据卡证构造评测集，按字段统计精确率与召回率，重点关注金额、日期等高错误代价的关键字段。
3. 问答与计算能力：设计需要跨区域定位与数值运算的问题，检验模型是“看懂了”还是在“编造”。
4. 端侧工程指标：量化后的精度损失、内存峰值、首token延迟与每页处理耗时，这些指标决定了体验的下限。

选型时还建议自建bad case库：把线上失败样本持续回流进评测集，形成“评测—发现—迭代”的闭环。文档场景的长尾性决定了公开榜单只是入场券，业务数据分布内的稳定性才是生产可用性的真正标尺。

六、边界与风险控制

轻量文档理解并非万能，落地时需正视三类风险：

• 幻觉与编造：VQA场景下模型可能“脑补”文档中不存在的数值。对金额、日期等高后果字段，应引入引用定位（答案须可回溯至文档具体区域）与规则校验（如日期合法性、金额与合计的勾稽关系）双重防线。
• 结构还原错误：嵌套表格与合并单元格仍是高错误率区域，关键业务流程应保留人工抽检与快速修正入口，而非完全信任端到端输出。
• 隐私与合规：端侧推理天然缓解数据外流风险，但一旦引入云端协同链路，就需要配套做好数据脱敏、传输加密与访问审计。

结语

从“识别文字”到“理解文档”，再到“基于理解去办事”，OCR正在完成一次从感知工具到认知组件的跃迁。0.8B量级模型证明了这条路径的可行性：以克制的参数规模换取端侧可部署性，以三合一的统一建模换取能力完整性，以标准化工具封装换取与智能体生态的即插即用。对开发者而言，真正值得关注的不是某一次榜单成绩，而是这套“轻量模型+结构化输出+智能体集成”的工程范式——它决定了文档智能能否走出实验室，成为用户随手可得的日常能力。