简介：手机端OCR正从“文字识别”走向“文档理解”。本文从技术架构、能力设计、推理部署到应用实践，拆解如何在1B以下参数规模内实现文档解析、关键信息抽取与视觉问答三类任务的统一建模，并给出端侧部署与自动化工作流的可行方案。
过去，手机上的OCR能力通常被理解为一套相对单一的技术链路：检测文字区域、识别字符内容、输出一段文本。这种模式在扫描名片、提取验证码等简单场景中已经足够可用，但当面对真实世界中的复杂文档时，瓶颈就迅速暴露出来。
取餐码被聊天消息淹没后，用户真正需要的不是识别出“取餐码”三个字，而是从整屏信息中定位那串数字；海报上的时间地点信息，用户希望的不是复制一段文字后再手动整理，而是直接生成日历事件所需的字段；账单上的金额、商户名称、交易时间，如果仍然要靠逐项摘录，效率提升就非常有限。
这些需求指向一个共同的趋势：OCR系统不能只完成“视觉感知”，还必须完成“语义理解”和“任务导向的结构化输出”。也就是说，系统不仅要认出文字，还要理解文字之间的关系、判断哪些信息是关键字段、并能按照指定格式返回结果。
这一变化的本质是——OCR正在从感知任务演变为理解任务。
对于云端大模型而言，这类任务可以依靠数十亿甚至上百亿参数的视觉语言模型来完成。但在手机端，算力、内存、功耗、时延以及数据隐私都构成了硬性约束。因此，如何在1B以下参数规模内实现文档解析、关键信息抽取与视觉问答三类能力的统一建模，就成为一个具有高度工程价值的技术命题。
本文将以这一技术目标为主线，从模型设计思路、三类核心能力、训练数据组织、推理部署方式到实际应用形态，系统性地拆解一个轻量级文档理解模型应该如何构建与落地。
在展开架构设计之前，首先要明确需要统一建模的三类任务分别是什么，以及它们之间的边界在哪里。
文档解析（Document Parsing） 的目标是识别并还原文档的物理结构与逻辑结构。物理结构包括段落、标题、表格、公式、图片等版面元素的位置与范围；逻辑结构则包括阅读顺序、层级关系、表格行列关系等。输出结果通常需要采用结构化格式——例如Markdown或LaTeX——以便后续编辑、知识库构建或检索增强生成（RAG）流水线直接消费。
关键信息抽取（Key Information Extraction, KIE） 面向发票、收据、证照、业务表单等半结构化文档。其输入是文档图像与目标字段描述，输出是结构化的键值对数据，通常以JSON格式返回。与文档解析不同，KIE不需要完整还原整篇文档，而是聚焦于用户关心的字段，例如“总金额”“商户名称”“有效期至”等。
视觉问答（Visual Question Answering, VQA） 允许用户围绕文档内容进行自然语言提问。问题可能涉及跨区域的文本检索、基于文档数据的数值计算、逻辑推理等。例如：“这份合同的有效期是多少天？”“表格中第三季度的总营收是多少？”VQA的输出可以是文本答案，也可以是带有定位信息的答案。
三类任务虽然形态不同，但在底层共享同一套视觉编码与文本理解能力。统一建模的关键在于：能否让模型在参数共享的前提下，按照不同任务的输入输出约定完成各自的推理目标。
轻量级模型无法像大型多模态模型那样通过海量参数的涌现能力来同时处理多种任务，因此必须通过精心设计的任务格式与训练策略来实现能力复用。
一种可行方案是采用统一的序列生成框架。模型接收图像和任务指令作为输入，输出则统一为文本序列。不同任务的差异通过任务指令和输出格式约束来区分：
这种设计将三类任务归约为“条件文本生成”，模型在训练时通过混合多任务数据学习不同任务之间的共同表示与差异表示。图像编码器负责提取视觉特征，文本解码器则根据任务指令和视觉特征生成目标输出。
这种做法的优势在于：
技术难点则主要体现在：如何在有限的模型容量内，让视觉编码器充分捕获版面信息、表格结构、公式语义等细粒度特征；以及如何让文本解码器在生成结构化输出时保持格式的严格正确性。这两个问题需要在训练数据构造和模型架构细化上做针对性设计。
文档解析是三类任务中感知要求最高的。复杂论文中的跨行公式、财务报告中的嵌套表格、扫描件中的倾斜与阴影，都对模型的鲁棒性提出挑战。
在技术实现上，文档解析通常被拆解为两个子过程：版面分析与内容重建。
版面分析负责检测文档中的各类版面元素——正文段落、各级标题、表格区域、公式区域、插图区域等——并判断这些元素之间的空间关系与逻辑顺序。在轻量级模型中，版面分析不一定要作为独立输出阶段，也可以由视觉编码器隐式完成。模型在训练过程中，通过大量带版面标注的数据学习如何将版面信息编码到视觉特征中。
内容重建则负责将版面分析结果转换为结构化的Markdown或LaTeX文本。对于表格，模型需要正确推断行列关系以及跨行跨列合并规则；对于公式，模型需要正确生成LaTeX表达式；对于正文，则需要按照自然阅读顺序组织段落。
训练这类能力的关键在于数据多样性。真实文档中的干扰因素——透视畸变、弯曲形变、光照不均、摩尔纹、低分辨率翻拍——都需要在训练数据中被充分覆盖。通常的做法是对高质量的电子版文档进行“退化模拟”，通过随机加入噪声、形变、模糊、透视变换等操作，生成接近真实拍摄效果的训练样本。
KIE任务的特点在于，文档的不同区域对用户的重要性是不对称的。一张发票上，用户关心的是金额、日期和商户名称，而不是发票抬头下方的说明文字。因此，KIE不仅需要理解文档内容，还需要根据用户指定的字段名称执行定向检索。
在统一生成框架下，KIE任务的指令可以设计为：
请从文档中提取以下字段，并以JSON格式返回：- 总金额- 商户名称- 交易时间- 发票号码
模型需要理解这些字段的语义，并在文档中找到对应的值。这一步隐含了一个重要能力：键值关联推理。模型需要知道“大写金额”和“小写金额”可能指向同一个字段，“商户名称”在发票上的常见位置，以及当字段缺失时如何正确返回空值。
在训练阶段，KIE数据的标注通常包含文档图像、字段定义以及标准JSON输出。为了让模型具备较好的泛化能力，训练数据需要覆盖不同版式、不同语言、不同字段集合的文档类型。特别是在面对未见过的新字段时，模型应当能够根据字段名称的语义自行推理其含义，而不是仅仅记住训练集中出现过的模板。
VQA是三类任务中认知要求最高的。它要求模型不仅理解文档内容，还要能够执行用户提出的具体问题。
文档VQA中的问题类型大致可以分为几类：
轻量级模型的VQA能力训练，核心在于构造高质量的问答对数据。通常的做法是：先利用文档解析结果生成文档的结构化表示，然后基于结构化内容自动生成不同难度和类型的问题。这种“文档到问答”的自动生成管线可以在较大规模上扩展训练数据，同时保证问题与文档内容的一致性。
值得特别指出的是，VQA与文档解析、KIE之间存在天然的能力互补关系。文档解析为VQA提供了结构化的版面信息，使模型可以更准确地定位相关信息所在区域；KIE则训练模型对指定字段的定向关注能力，这种能力在回答检索型问题时同样有效。因此，在统一模型中进行多任务联合训练，往往能带来比单独训练各任务更好的整体效果。
0.8B参数的模型在理论计算量上远小于数十亿参数的大模型，但要真正在手机端流畅运行，仍需关注几个瓶颈。
首先是视觉编码器的计算量。文档图像通常需要以较高的分辨率输入，以保证小字号文字和细线表格的可辨识度。高分辨率意味着更长的视觉token序列，这会成倍增加后续文本解码器的注意力计算量。因此，视觉编码器往往需要采用降采样策略，在保持关键信息的同时减少token数量。
其次是文本解码的序列长度。文档解析任务需要生成完整的Markdown文本，对于包含大量表格和公式的复杂文档，输出序列可能达到数千token。在自回归生成模式下，解码时间与序列长度成正比。优化方向包括：使用更高效的解码策略（如lookahead decoding或并行解码）、对长序列的输出进行分块处理、以及在保证格式正确性的前提下压缩不必要的格式字符。
内存占用方面，0.8B参数的模型在使用INT8量化后，权重占用可以控制在约800MB以内。如果采用INT4量化并配合高效的推理引擎，内存占用可以进一步降低。对于中高端手机，这个量级在可接受范围内。
量化是端侧部署的关键步骤。常见的做法包括：
除量化外，推理框架的选择也直接影响实际体验。现代端侧推理引擎通常在算子融合、内存复用、指令集优化等方面做了大量工作。对于Transformer结构，KV Cache的优化管理也是降低内存峰值的重要手段。
在工程实践中，一个常见的策略是分层混合精度：对视觉编码器的浅层保留较高精度，因为浅层特征对最终识别效果影响较大；对文本解码器的中后层采用更激进的量化，因为这些层的冗余度相对更高。
轻量级模型在处理结构化输出（Markdown、LaTeX、JSON）时，可能面临格式错误问题——例如JSON缺少引号或括号不匹配、Markdown表格分隔符缺失等。这些问题会直接影响下游自动化工作流的可用性。
针对这一挑战，实践中有几类有效手段：
约束解码（Constrained Decoding） 是在生成过程中强制模型遵循预定义的语法规则。例如在JSON输出模式下，解码器每一步只允许生成符合JSON语法约定的token。这种方式在推理框架中实现后，可以从根本上保证输出格式的正确性。
格式校验与重试机制 部署在模型服务层。当检测到输出不符合目标格式时，服务可以自动触发重试，必要时调整生成参数重新解码。在大多数情况下，一两次重试即可解决偶发的格式错误。
后处理修复 对于一些确定性的格式问题，可以通过规则进行修复。例如补全JSON缺失的右括号、修正Markdown表格的分隔行等。这种方式虽然简单，但在实际系统中作为最后一道防线非常有效。
在端侧实际应用中，文档理解模型的推理能力需要通过合适的系统集成方式暴露给上层场景。当前的主流做法包括以下几种形态：
端侧SDK集成：将模型与推理引擎打包为SDK，嵌入到手机系统或应用中。调用方通过接口传入图像和任务指令，同步或异步获取结构化结果。这种形态的优点是时延低、数据不出端，适合对隐私要求较高的场景。
本地服务化封装：在手机端以系统服务的形式运行模型，通过进程间通信提供给多个应用共享。这种方式可以避免每个应用各自加载一份模型权重，节省整体资源占用。系统级的一次部署、多处复用，也有利于模型版本统一管理。
轻量级Agent封装：在模型之上封装一层Agent逻辑，使模型能力可以被自然语言指令触发，并以“输入文档图像-输出可执行结果”的闭环方式工作。例如用户说“帮我从这张发票中提取金额和商户名”，Agent层将指令翻译为KIE任务的字段列表，调用模型获取结构化结果，再将结果格式化返回或对接后续处理流程。
结合开篇所述的用户痛点，轻量文档理解模型在端侧的核心应用场景可以从“识别”延伸至“行动”：
信息提取与自动填充：在即时通信场景中，用户长按屏幕截图，系统识别其中的地址、电话、日期等信息，并自动提供“添加到联系人”“创建日历事件”“开始导航”等操作入口。用户只需一次点击，信息就从图像流转到了目标应用中。
账单与票据管理：面对支付凭证、消费小票、电子发票等文档，系统自动提取金额、时间、商户、交易类别等字段，并以结构化数据存入本地账本或报销草稿。对于财务处理流程而言，这意味着数据在源头就完成了结构化。
文档数字化与知识管理：拍摄纸质文档后，系统直接输出Markdown格式的结构化文本，保留标题层级、表格和公式。用户可以将结果存入笔记或知识库，后续的全文检索、摘要生成、问答系统都可以直接基于结构化内容构建。
辅助阅读与交互问答：对于篇幅较长的文档，用户可以通过自然语言提问快速定位关键信息。系统在端侧完成视觉文本理解，答案直接返回，数据不经过网络。这在处理合同、协议等敏感文档时尤为关键。
轻量级文档理解模型的出现，指向了一个更广阔的趋势：感知、理解与行动在终端侧的一体化。
传统的AI应用范式依赖于云端大模型承担全部认知任务，终端只负责采集和展示。但随着端侧芯片算力的持续提升和模型压缩技术的进步，越来越多的认知型任务可以在本地完成。文档理解正是一个典型的例证——它在感知层面需要处理图像和文字，在认知层面需要理解结构和语义，在行动层面需要对接到日历、联系人、票据系统等具体工作流。
对于开发者而言，这意味着一个新的技术栈正在形成。其核心层是一个小体积但具备多任务能力的视觉语言模型；中间层是格式保障、量化推理、任务编排等工程能力；最上层则是面向具体场景的Agent封装与应用集成。能够在这些层面形成完整能力的团队，将在端侧智能的下一阶段占据有利位置。
对于企业用户而言，这类技术带来的直接收益是：文档处理流程可以前置到数据产生的源头，减少对云端服务的依赖，降低数据流转中的隐私风险与合规成本。同时，结构化数据的提前生成也为后续的自动化流程——无论是财务报销、合同审查还是知识管理——奠定了更高质量的数据基础。
轻量级模型当然有其能力边界。在极端复杂的文档类型、需要广域知识背景的问题、以及长篇幅文档的深度推理任务中，更大规模的模型仍然具有优势。因此在实践中，端侧轻量模型与云端大模型之间更可能形成“端侧优先处理、云端兜底增强”的分层协作关系。端侧模型负责高频、时延敏感、隐私要求高的任务；当任务超出本地能力阈值时，再请求云端模型介入。
这种端云协同的架构，或许正是OCR从“工具”走向“智能体”的必经之路。
本文围绕1B以下参数规模的端侧文档理解模型展开，系统讨论了其技术定位、三类核心能力的实现路径、端侧部署的关键工程问题以及实际落地形态。
核心结论可以归纳为几点：
随着端侧算力的持续演进和模型压缩技术的成熟，轻量级文档理解模型将在智能手机、平板电脑甚至更轻量的设备上扮演越来越重要的角色。对于正在构建文档智能应用的开发者和企业来说，现在正是深入理解这一技术路径、完成能力储备的最佳时机。