0.8B！轻量文档理解模型开源，让手机识屏主动办事

一、背景：OCR的第三阶段——从“认字”到“懂文”

过去十年，OCR技术大致经历了三个阶段的演进：

1. 识别阶段：以“检测+识别”两段式流水线为主，解决“图里有什么字”，典型输出是文本行及其坐标；
2. 解析阶段：在识别之上叠加版面分析、阅读顺序还原、表格结构重建，目标是把一页文档变成机器可读的结构化文本（如Markdown、HTML表格）；
3. 理解阶段：多模态模型将视觉编码器与语言模型结合，以“图文输入—文本输出”的端到端方式直接完成解析、抽取与问答，跳过了传统流水线中多个易错环节。

近期开源的这款0.8B（8亿）参数轻量模型，正是第三阶段的代表性思路：用一个统一模型同时覆盖文档解析、关键信息抽取、视觉问答三类任务，并在公开权威基准中取得96.83分的端到端解析成绩，位列1B参数以下模型第一；在五项文档视觉问答任务上平均得分83.2，接近参数规模更大的主流模型。

它所回应的是一类真实的高频需求：取餐码被消息流淹没、海报上的时间地点要手动敲进日历、账单金额和商户信息仍需逐项摘录。手机能否不只“看见”屏幕内容，而是“看懂”之后顺手把下一步做完？这背后，正是文档理解能力向端侧迁移的技术趋势。

二、0.8B如何做到“三合一”：统一架构与统一输出

1. 典型架构：视觉编码器 + 连接层 + 小型语言模型

业界轻量文档理解模型普遍采用三段式结构：

• 视觉编码器：基于ViT类结构，将文档图像切分为图像块并编码。文档场景的特殊性在于高分辨率与密集小字，因此通常配合动态分辨率或切片策略，避免票据上的小号文字“看糊”；
• 连接层：将视觉特征压缩对齐到语言模型的输入空间，视觉token的数量直接决定推理开销，是轻量化的关键杠杆；
• 语言模型解码器：0.8B量级的小型语言模型承担语义理解与文本生成，是“看懂”能力的来源。

2. 统一任务范式：一切输出皆文本

真正让小模型“全能”的设计在于任务统一——三类任务共享同一套“图像+指令→文本”的接口：

• 文档解析 → 输出Markdown或HTML表格；
• 信息抽取 → 按给定Schema输出JSON；
• 视觉问答 → 直接回答自然语言问题。

训练上通常采用多任务指令微调，混合版面标注、表格、票据、论文、公式、图表等多样化数据。对工程团队而言，这意味着一个模型可以替代“检测+识别+版面分析+规则后处理”的整条流水线，大幅降低维护成本，也消除了级联架构中“上游错、下游全错”的误差放大问题。

3. 为什么小参数也能打

• 文档理解的知识密度集中在文字、版面、位置与语义四类信息，相比开放域对话，任务空间更收敛，小模型经充分的多任务训练即可在垂直任务上逼近更大参数的模型；
• 端到端训练让视觉特征直接服务于最终任务，信息传递路径更短；
• 结构化输出便于程序化校验，容错空间比开放式生成更大。

三、评测怎么看：分数之外还要看什么

原文中的两类成绩可对应到业界通用指标体系：

• 端到端解析：常用整页文本编辑距离、表格结构相似度（如TEDS）、阅读顺序准确率衡量。96.83分及“1B以下第一”的排名，说明其版面还原已具备实用水准；
• 文档视觉问答：常用ANLS或答案准确率衡量，五项异构任务平均83.2分，体现的是跨票据、表单、图表等版面的泛化能力。

给开发者的建议是：公开基准用于初筛，真实业务数据用于终审。票据畸变、印章遮挡、拍照阴影、非标准排版等真实噪声，往往比基准集更严苛。建议自建数百条标注样本做回归评测，再决定是否引入生产链路。

四、从识屏到办事：端侧技术链路拆解

智能助手“一键识屏”背后的完整链路可以拆成五步：

1. 截取与预处理：截屏、裁剪兴趣区域，必要时做去噪与透视矫正；
2. 端侧推理：轻量文档理解模型完成结构化解析或定向抽取；
3. 意图判断：基于内容类型与用户上下文，路由到对应动作；
4. 能力调用：通过系统级接口创建日历、添加提醒、复制文本、填充表单；
5. 结果确认：以结构化卡片向用户展示，允许修改后执行。

示意代码如下：

# 伪代码：识屏即服务的处理链路
def on_screen_capture(screenshot):
    doc = doc_llm.generate(
        image=screenshot,
        task="parse",            # 可选：parse / kie / vqa
        schema=SCREEN_SCHEMA     # 约束输出结构
    )
    intent = route_intent(doc)   # 根据内容类型决策
    if intent == "calendar":
        calendar.create(doc.event)   # 海报 → 日程
    elif intent == "copy_code":
        clipboard.write(doc.code)    # 消息 → 取件码

票据抽取的典型输出示例：

{
  "merchant": "某连锁餐饮",
  "amount": 36.5,
  "date": "2025-10-30",
  "items": [
    {"name": "套餐A", "price": 32.0},
    {"name": "纸巾", "price": 1.0}
  ]
}

端侧方案还有两个隐性收益：一是隐私，截图不出设备，对账单、证件等敏感内容尤其重要；二是时延，省去网络往返，交互反馈可控制在百毫秒量级（具体取决于芯片与量化方案）。

五、工程落地要点：让0.8B跑得快、稳、省

1. 量化部署：0.8B参数在FP16下约需1.6GB内存，INT8约0.8GB，INT4可压至约0.5GB，叠加视觉编码器与运行时开销后，中高端机型的NPU即可承载。量化后需重点回归表格数字、长串数字（金额、证件号）的识别稳定性；
2. 结构化输出约束：为抽取任务传入JSON Schema，解码时做格式校验与有限次重试；对金额、日期等关键字段增加正则与业务规则二次校验，抑制小模型偶发的幻觉；
3. 分辨率与长文档策略：超长文档采用“切片解析+结果合并”，注意跨页表格与上下文衔接；超高分辨率图像先按版面切图再送模型；
4. 端云协同：简单票据、截屏场景走端侧；成批扫描件、超长论文、复杂盖章合同等高难度件，可回传云端文档智能服务处理，例如百度智能云等厂商提供的OCR与文档理解类服务，形成“端侧保隐私低时延、云端保复杂度”的混合架构；
5. 持续迭代：将线上badcase沉淀为微调数据。小模型参数少，领域微调的数据与算力成本显著低于大模型，更容易形成“数据飞轮”。

六、选型建议与趋势判断

• 传统OCR流水线：适合版面高度固定、只需提取文字内容的场景，成本最低、可控性最强；
• 轻量统一模型（1B以下）：适合端侧识屏、票据抽取、表单理解等需要“结构+语义”双重能力的场景，是当前端侧多模态落地的甜点位；
• 云端大模型：适合复杂推理、跨文档问答与深度多模态理解，可作为兜底与增值能力。

可以预期，随着“更小参数、更强结构理解”的持续演进，端侧文档理解将成为智能助手的默认能力：手机不再只是“看见”屏幕，而是在理解内容之后，直接把下一步动作做完。对开发者而言，现在正是把“截图—抽取—执行”这条链路跑通、将结构化输出接入自身业务流的窗口期。