从识别到理解：轻量文档模型让识屏主动办事

一、从“看见文字”到“看懂屏幕”：识屏交互的新一跳

过去十年，OCR在手机上的角色基本停留在“复制粘贴”：截图后框选一段文字，识别出来，供用户二次编辑。这条链路解决的是“看见”的问题，而真实高频的需求往往在下游，取餐码淹没在消息流里需要被拎出来，海报上的时间地点需要写进日历，账单里的金额和商户需要逐项归档。这些场景的共同点是：系统不仅要输出文字，还要输出结构，并进一步输出“可以执行的语义”。

传统OCR技术栈难以胜任这件事。典型流水线由文本检测、文本识别、版面分析、信息抽取等多个独立模块串联而成，模块间的误差会逐级放大，且各模块输出格式各异，工程上需要大量胶水代码。更重要的是，流水线只回答“这里有什么字”，不回答“这是一张票据吗、该提取哪些字段、用户下一步想干什么”。近年端到端多模态文档理解模型的兴起，本质上就是把这条长流水线折叠进一个统一的视觉—语言模型：输入一张文档图像或屏幕截图，输出带版面结构的Markdown/JSON，或直接回答自然语言问题。

二、能力三角：解析、抽取、问答一体化

业界公认的文档理解能力可以拆成三类，轻量级模型的核心价值在于把三类能力收敛到同一份权重里：

1. 文档解析：将整页内容转换为可机读结构，包括段落阅读顺序、多级标题、跨行合并的表格、公式等，评测上通常以生成结果与标注结果之间的归一化编辑距离或相似度衡量。
2. 关键信息抽取（KIE）：给定字段模式（如票据的商户、金额、日期），从版面中定位并抽取对应值，常用字段级F1评估。它要求模型具备“字段语义—版面位置—文本内容”三者对齐的能力。
3. 文档视觉问答：围绕文档内容回答自由形式的问题，例如“这份合同的有效期到哪天”，考察跨区域推理而非局部识别。

一体化带来的工程收益非常直接：端侧只需维护一个模型、一套推理栈、一种结构化输出契约，三类需求共享同一个视觉编码器，内存与算力复用率高，也避免了多模型结果冲突时难以仲裁的问题。

三、0.8B量级如何做到：架构与数据的关键取舍

在通用认知里，多模态模型能力与参数规模强相关，但文档理解是一个“领域收窄、模式规整”的任务，这为小模型留出了空间。主流技术方案通常由三部分组成：

• 视觉编码器：基于ViT结构的图像编码器。文档图像文字密集，普遍采用动态高分辨率策略——按长宽比切分图块，再对全图做一次缩略编码，兼顾细节与全局版面。
• 连接层：将视觉特征投影到语言模型空间，部分方案会插入位置感知token，使模型能输出文本框坐标，支撑“识别即定位”。
• 轻量语言解码器：承担最终的结构化生成与问答。参数量压缩到1B以下后，推理内存可控制在很小的量级，为端侧部署创造条件。

训练侧的共性经验包括：用大规模合成数据（渲染排版、程序化生成表格与票据）打底，混合真实扫描件与截图数据做多任务指令微调；用更大的教师模型蒸馏解析与抽取能力；针对阅读顺序和坐标回归设计专门监督信号。0.8B级模型之所以能在权威解析基准上站上第一梯队、在文档问答平均分上逼近参数量大数倍的通用模型，正是因为它把容量集中投在了“文档”这一垂直域，而非追求全领域通用。

四、评测怎么看：两组指标与选型维度

公开评测一般关注两族指标。其一是综合文档解析：在跨版式（书籍、论文、财报、试卷、笔记）的测试集上对比生成结果与金标准的一致性，并单独考核表格结构相似度。其二是文档问答集：覆盖票据、表单、图表等多种版式的问答准确率。从近期公开榜单看，1B以下小模型已在解析基准上取得领先成绩，问答能力亦能逼近更大的通用多模态模型——这说明“小模型+垂直数据”的路线在文档域是成立的。

但选型不能只看分数，工程上还需纳入：量化后的精度衰减（INT8/INT4下解析指标掉多少）、高分辨率大图的内存峰值与首token延迟、中英文与手写体覆盖、输出格式稳定性（是否严格遵循JSON契约）、以及模型许可对商用与端侧分发的限制。建议为自有业务构建一套小规模评测集，覆盖真实截图、翻拍、特殊屏幕比例等边角情况，再做横向对比。

五、工程落地：端云协同的识屏链路

一个可直接参考的方案是“端侧轻模型处理高频简单场景，云端文档服务兜底复杂长文档”：

# 伪代码：识屏 → 结构化 → 意图执行
screenshot = capture_screen()
regions = layout_detector.crop(screenshot)   # 版面粗切
doc = light_doc_model.parse(regions)         # 轻量多模态模型，输出JSON
intent = intent_router(doc, user_context)    # 规则+小分类器
if intent == "ADD_CALENDAR":
    calendar.create(title=doc["title"], time=doc["time"])
elif intent == "SAVE_BILL":
    ledger.append(doc)

模型输出应约定严格的JSON契约，例如票据类固定输出：

{
  "doc_type": "receipt",
  "merchant": "示例商户",
  "total": "128.00",
  "date": "2025-10-30",
  "items": [{"name": "商品A", "price": "64.00"}]
}

端侧部署要点：优先走设备NPU推理框架，对视觉编码器做INT8、对语言解码器做INT4权重量化，把常驻内存控制在数百MB量级；仅在用户明确授权的场景触发识屏，敏感票据默认本地处理、不出端。对于多页合同、低画质扫描件等复杂输入，则回传云端，调用云服务商提供的通用文字识别与文档智能解析类服务完成，这类能力在主流云平台上均以标准API形式提供，例如百度智能云的文字识别、文档解析等通用产品类别，即可与端侧模型形成互补分工。

六、实践建议与常见坑

1. 数据先行：通用开源权重在票据、行业单据上往往不够贴合，建议收集数百到数千张真实样本，用LoRA做低成本微调，重点补充字段缺失、印章遮挡、跨页表格等难例。
2. 控制幻觉：对抽取字段增加坐标回验（用检测模型核对文本是否真实出现在对应区域），置信度低的字段降级为“待确认”，避免直接写入下游系统。
3. 长文档策略：按页切分推理，再用规则合并跨页表格与段落；页间携带摘要上下文，可显著改善问答一致性。
4. 评测闭环：把线上用户纠正行为回流为评测样本，持续监控量化版本与全精度版本的指标差。

七、结语

从“识别文字”到“理解文档”再到“主动办事”，屏幕正在成为端侧智能体最重要的输入入口。轻量级文档理解模型的成熟，让“看懂”这一步可以常驻在每个人的口袋里；而“办成”这一步，则依赖结构化输出、意图路由与系统服务的紧密协作。对开发者而言，合理的入手路径是：用权威基准完成初筛，用自有数据完成微调，用端云协同架构平衡成本与隐私边界，小模型的时代，功夫更多在模型之外。