简介：OCR完成只是第一步，真正的难点在于把版面、表格、公式与阅读顺序还原为可检索的结构化知识，并在本地算力约束下选对总结模型。本文从多模态文档解析管线出发，对比判别式版面模型、小参数指令模型与中型推理模型三类本地方案的适用边界，给出分阶段部署、量化裁剪与评测闭环的工程方法，帮助读者在精度、显存与集成成本之间找到可落地的平衡点。
很多团队在立项时会把文档智能化简化为“把图片转成文字”，于是把预算全部压在识别率上。但真正进入生产环境后会发现，识别出来的是一大段线性文本，表格被压扁、公式变成乱码、双栏排版被错误地串行拼接，后续的检索、抽取与问答几乎无法直接使用。这说明业务真正需要的不是“字符级转录”，而是“文档级理解”。
从技术视角看，一份复杂文档至少包含四类信息：视觉信息（字体、字号、加粗、颜色、印章、签名）、语言信息（自然语言文本）、版面结构（分栏、段落、标题层级、阅读顺序）、场景上下文（文档类型、业务语义、字段含义）。只做“图像→文本”的转换，会丢失后三类信息中的大部分。因此完整的处理链路应当是：
前三步通常由专门的文档解析管线完成，第四步决定输出是否“可机读”，而第五步才是本文讨论的核心——本地部署哪类模型来做结构化总结最合适。需要强调的是，第五步的输入不应该是原始图像，而应该是第四步产出的结构化中间表示（如带版面标注的 Markdown 或 JSON）。这一设计能显著降低总结模型的输入长度与推理难度，也让本地部署的显存需求变得可控。
讨论“哪个模型最好”之前，必须先承认一个事实：不存在单一模型在所有场景下都最优。更合理的做法是按能力维度分类，再按业务约束做匹配。本地部署场景下，可选的模型大致分为三类。
这类模型不生成自然语言，只做分类与回归：判断某个区域是标题、正文、表格还是公式，预测阅读顺序，还原表格的行列结构。它们参数规模小、推理快、显存占用低，通常可以在单张消费级显卡上以较高吞吐运行。
其优势在于确定性高、可解释性强、易于做后处理校验，适合作为结构化管线的“骨架”。劣势是无法生成摘要或自然语言归纳，必须与生成式模型配合。在工程上，把它放在管线前端承担“结构还原”职责，是性价比最高的选择。
参数量在十亿级别上下、经过指令微调的模型，经过量化后可在单卡甚至边缘设备上运行。它们擅长短文本的字段抽取、分类、格式化输出，对提示词遵循度较好，输出可以通过约束解码保证 JSON 合法性。
这类模型的适用场景是：发票字段抽取、合同关键条款定位、收据金额与日期提取等“窄而深”的任务。它们的短板是长文档理解能力有限，面对几十页的财报容易丢失中间信息，且对复杂表格的推理能力较弱。因此更适合做“逐段处理 + 结果聚合”的流水线，而不是一次性喂入整份文档。
参数量在数十亿级别、具备较强长上下文能力与推理能力的模型，是结构化总结任务中质量上限最高的一类。它们能处理跨段落的信息整合、表格数据的对比分析、多页文档的要点归纳，并在提示词设计得当的情况下输出稳定的结构化结果。
代价是显存占用与推理延迟显著上升。本地部署时通常需要量化（如 4bit 或 8bit 权重）、张量并行或分层加载，并且要仔细设计批大小与上下文窗口。工程上更现实的做法是“分级调用”：简单文档走小模型，复杂文档路由到中型模型，用路由策略平衡成本与质量。
典型场景是批量票据、收据、标准合同。这类文档版式相对固定，字段位置稳定，业务诉求是“准确抽取 + 快速入库”，而不是“自由问答”。
推荐管线：版面判别模型完成区域切分与阅读顺序还原 → 表格结构模型输出 HTML 或标记语言表格 → 小参数指令模型按固定 schema 做字段抽取 → 规则引擎做校验与补全。
这条路径的优势是吞吐高、结果稳定、易于做质量监控；生成式模型只承担字段级的轻量任务，即使出错也容易定位到具体字段。工程上建议为每类文档维护一份字段 schema，并用约束解码强制输出结构，避免模型自由发挥带来的解析失败。
典型场景是研报、财报、项目文档、长篇合同。业务诉求不只是抽字段，还要生成摘要、提炼要点、回答“这份文档的核心风险是什么”之类的问题。
推荐管线：文档解析产出带层级标题的 Markdown → 按标题层级做语义分块，保留块与块之间的父子关系 → 每个块单独送入中型模型生成局部摘要与要点 → 再用一次聚合调用（或按层级的树状归并）生成全局摘要。
这里的关键工程点是分块策略。按固定字数切分容易切断表格与上下文，建议按标题层级切分，并对超长表格单独处理：先由表格模型转成结构化数据，再以“表格摘要 + 关键行”的形式喂给生成模型。聚合阶段要控制输入长度，可采用递归归并或先做要点去重再汇总。
典型场景是私有化一体机、边缘网关、内网离线环境。算力有限、无法联网、运维人力紧张。
推荐管线：轻量版面模型 + 量化后的小参数指令模型，配合严格的输出模板与规则校验。对于模型无法处理的低置信度样本，进入人工复核队列，而不是强行生成。工程上应把“拒答”设计成一等公民：当置信度低于阈值或输出不满足 schema 时，明确标记为待复核，避免错误结果污染下游数据。
输入表示的选择。 直接把原始图像喂给多模态大模型看似省事，但在本地部署下显存开销大、延迟高，且模型对细粒度表格的还原能力未必优于专用解析管线。更稳妥的做法是让专用管线负责“看得准”，让生成模型负责“想得深”，两者解耦后各自可独立升级。
输出契约的设计。 结构化总结的价值在于下游可用，因此必须定义稳定的输出 schema，例如：
{"doc_type": "contract","summary": "...","key_fields": {"party_a": "...", "effective_date": "..."},"risks": ["..."],"confidence": 0.87}
配合约束解码或输出后校验，可以大幅降低解析失败率。对于关键字段，建议同时保留原文出处（页码与坐标），便于人工核验与审计追溯。
评测闭环的建立。 选型不能靠主观感受。建议构造一份覆盖各类文档的评测集，指标至少包括：字段级准确率、摘要的事实一致性（是否出现原文没有的结论）、结构化输出的合法率、单页平均延迟与显存峰值。上线后持续采样线上低置信度样本回流，形成“评测—调优—再评测”的闭环。
安全与合规。 本地部署的核心动因往往是数据不出域。因此要确保推理进程、日志、缓存均不产生外发流量，模型权重与提示词模板纳入版本管理，敏感字段在入库前做脱敏处理。对于多租户场景，还要隔离不同租户的检索索引与缓存。
回到最初的问题，本地部署做结构化总结并不存在一个通用最优解。判别式结构模型负责把文档“还原正确”，小参数指令模型负责把字段“抽取准确”，中型推理模型负责把内容“归纳到位”。三者不是替代关系，而是分层协作关系。
选型的正确顺序应当是：先明确业务是抽取型还是归纳型，再评估文档复杂度与版式稳定性，最后在算力预算内确定模型规模与量化方案。对于大多数企业场景，一条“专用解析管线 + 小模型抽字段 + 中型模型做摘要”的混合架构，往往比押注单一超大模型更稳、更省、也更易维护。把管线拆清楚、把输出契约定义好、把评测闭环建起来，比纠结“哪个模型最强”更能决定项目成败。