这几年，文档智能和多模态模型的发展速度很快。很多时候，看完几个演示视频，人很容易产生一种判断：OCR 已经很成熟了，版面分析、表格识别、图片理解也都在持续进步，那么工程文档的结构化整理，是不是也差不多该进入“可以全面落地”的阶段了？

如果只看一些相对干净、相对标准的样例，这个判断并不奇怪。今天确实已经可以把一份 PDF、几张截图，甚至一组混杂的图片丢给系统，然后快速得到一份看起来还不错的结构化输出。它能识别出文字，划分出表格，甚至还能顺手给出一段总结。问题在于，这种“看起来能用”的效果，和真实工程场景里“长期稳定可用”的能力，中间其实还隔着很长一段距离。

因为工程文档从来不是普通意义上的文档。它往往同时包含成段的技术文字、复杂表格、公式、图纸截图、实物照片，以及大量专业术语、编号体系、单位符号和跨页引用关系。到这里，问题的重点就已经不再是“把内容识别出来”，而是如何把整份文档的结构重新还原出来，把文字、表格、公式、图片之间的关系串起来，再把这些内容变成可追溯、可复核、可入库、可检索的工程数据。真正卡住落地的，不是某一个字符认错了，而是系统并没有真正理解这份文档在工程语义上是如何组织起来的。

【01 为什么工程文档结构化这件事一直不好做】

很多团队最开始都会低估这件事的难度，因为它表面上看起来像是 OCR 的延伸问题。但真实情况恰恰相反。OCR 在工程文档结构化整理里只是基础能力，而且往往还不是最难的一层。真正麻烦的地方，首先来自输入本身的不规则。

工程资料很少是干净统一的：数字原生 PDF 和扫描件会混在一起；其中还会有工程图，图纸有时来自 CAD 导出的PDF，有时只是屏幕截屏；现场照片则还可能伴随反光、阴影、模糊、透视变形和背景干扰。再叠加印章、水印、页眉页脚、批注、多语言混排以及不同项目模板之间巨大的差异，系统面对的第一道题其实不是识别，而是如何在高度异构而且经常并不“机器友好”的输入条件下，先把文档接稳。

这也是为什么很多项目一开始就会遇到落差。实验环境里几份格式规整的样本跑得很好，但一旦切换到真实归档资料、扫描图纸、历史规范书或者现场拍照件，整体效果就开始波动。问题不一定出在某个模型能力不够强，而是工程文档本身就不是一个单一格式、单一模态、单一规则的问题。

【02 很多问题不在识别，而在结构没有还原出来】

即便输入接住了，接下来也不是直接进入 OCR。对复杂工程文档来说，更关键的前置能力其实是页面理解。系统必须先知道页面上哪些区域是标题，哪些是正文，哪些是表格，哪些是公式，哪些是图片，哪些又只是图题、注释、页眉页脚或者签字栏。只有先把这些内容切对，后面的识别才有意义。

很多实际项目里，最终效果不好，并不是因为某个字没有被识别出来，而是整页文档的结构关系在最开始就被切错了。阅读顺序一旦错位，段落逻辑就会断裂；图题如果没有挂到对应图片上，后续引用关系就会丢失；跨页表格如果没有被正确拼接，看似每个单元格里的字都认出来了，真正到了字段抽取和入库时，依然可能整片错位。

也就是说，很多问题的本质并不是“看不见”，而是“看错了位置和关系”。这恰恰是工程文档比普通文档难得多的地方。普通文档很多时候只要保证文本顺序大致正确，就已经能支撑搜索和摘要；但工程文档不同，它的很多信息价值都依赖结构。条款层级、图表引用、跨页续表、脚注说明、局部注释，这些关系一旦丢了，识别出来的内容就会迅速失去可用性。

【03 表格、公式、图纸截图，为什么总是反复出问题】

复杂表格就是这种问题最典型的放大器。普通文档里的表格，很多时候只要把行列分清，把单元格内容抄出来，任务就完成得差不多了。但工程文档里的表格通常并不规整。多级表头、跨行跨列、合并单元格、跨页续表、缺线表、斜线表头、表格中混合公式和符号，都是常见情况。更复杂的是，即便表格结构恢复得还可以，业务语义也未必天然清晰。同样一个“规格”列，在不同项目或不同模板里可能对应完全不同的含义；相同字段的表达方式，也可能因为供应商或专业方向不同而有很大差异。

所以工程表格真正难的，从来不是单个字符能不能识别出来，而是单元格拓扑、表头层级和业务字段之间的对应关系能不能稳定恢复。很多表格识别结果在展示层面看上去“差不多”，但一旦真的进入数据库、统计分析或者知识抽取链路，问题就会很快暴露，因为只要有一处行列关系错位，后面的结果就不再可靠。

公式和各种工程符号，则构成了另一类更容易被低估的难题。工程文档里的公式、公差、上下标、希腊字母、焊接符号、几何公差、表面粗糙度标记，本质上都不是简单的线性文本。它们是带空间层次和结构关系的表达，一处上下标识别错误，影响的往往不是版面美观，而是整个工程含义。更麻烦的是，这些公式和符号很少是孤立存在的，它们往往要结合前后的正文说明、表格里的参数、甚至图片中的注释一起解释。于是问题就变成了双重的：一方面，公式本身的结构化识别还远没有稳定到可以完全放心自动交付；另一方面，即便识别成了 LaTeX 或 MathML，也仍然要继续面对变量定义、单位对齐、语义归一和可计算化这些后续问题。

图像部分的困难则更进一步说明，工程文档结构化不能被简单理解为“多模态识别”。很多时候，工程图纸截图和实物照片都会被笼统地归为图片处理，但这实际上是两类非常不同的任务。图纸截图更接近文档视觉解析，它要求系统读懂尺寸标注、引出线、部件编号、局部视图关系和图题说明；实物照片则更接近场景视觉理解，它更关注设备、部件、缺陷、环境状态和铭牌内容。前者难在图纸一旦变成截图，就丢失了 CAD 的原始矢量和图层信息，系统只能从像素中重新推测结构；后者难在真实拍摄带来的光照变化、遮挡、视角偏差和背景复杂性。也就是说，很多系统之所以在图片相关任务上不够稳定，并不是因为模型整体不够先进，而是因为一开始就没有把图纸截图和现场照片当成两套不同的问题去设计。

【04 大模型已经很强了，为什么还是不够】

但即便文字、表格、公式和图片各自都处理得不错，工程文档结构化仍然可能离“可用”差很远。真正把整个系统推向复杂化的，往往是跨模态关联。因为工程文档的价值从来不是把一页页内容拆散，而是把它们重新组织成一套可理解、可引用、可追溯的知识结构。正文中的“见表 3-2”“详见图 5”“按公式(7)”并不是修辞性表达，而是文档逻辑的一部分；图纸上的编号，需要和表格中的部件条目对应起来；一张现场照片，可能需要映射回某个缺陷项、某个设备对象或某条技术要求。

很多系统最后能产出很多看似丰富的识别结果，但这些结果彼此之间没有可靠的关系链，最终也就无法形成工程上真正有价值的结构化资产。它能抽取内容，却不能还原工程含义。

这也是为什么，尽管多模态大模型已经展现出很强的能力，工程文档结构化整理这件事仍然不能简单地被交给一个端到端模型去“统一解决”。大模型的优势非常明显，它擅长总结、归纳、分类、解释和跨块语义整合，也很适合做字段归类、关系补全和人机交互层面的增强。但问题在于，工程文档最需要的往往不是“大意正确”，而是结构精确、结果稳定、来源可追溯、字段可校验。复杂表格的拓扑恢复、公式结构的唯一表达、字段与坐标的精确绑定、多次解析结果的一致性，这些恰恰都不是当前多模态大模型最稳的部分。所以在真实项目里，我们经常会看到一种很典型的落差：整体看起来很聪明，细节却不够可靠；概念上像是“懂了”，但真正落到数据库、审校和知识治理流程里，还是会暴露出很多问题。

【05 现阶段技术到底卡在了哪里】

这正是当前工程文档结构化整理最核心的技术瓶颈所在。今天的技术确实已经可以把很多局部问题做得比过去好得多，但还远没有到“在广泛工程场景中稳定、通用、低成本解决”的阶段。复杂文档的泛化能力仍然有限，复杂表格的结构恢复和业务语义映射仍然容易出错，公式识别距离工程可用还有差距，图纸截图缺少真正成熟的通用解法，跨页拼接和跨模态引用恢复也依然是高频难点。

更进一步说，很多系统并不是底层识别彻底失败，而是卡在“最后一公里”上：术语没有统一、单位没有归一、编号规则没有建立、实体关系无法对齐、结果无法追溯到原文位置、低置信度内容也没有有效送审机制。于是系统看似做出了很多识别结果，却很难变成一个真正能进入业务流程的能力。

这里还有一个很现实的问题，就是评估方式本身也经常有偏差。很多团队仍然习惯用 OCR 准确率、表格识别率、页面分类准确率来衡量系统表现，但工程文档结构化真正应该关心的，是关键字段能不能稳定抽对，表格拓扑是否正确，跨页续表是否拼准，公式是否还能被后续系统利用，图文关系是否完整，人工复核成本是否真的下降。如果评估标准还停留在模型层面的局部指标，最后得到的往往是“技术上看起来还行，业务上始终不够稳”的结果。

【06 真正能落地的方案，往往不是“一个模型全包”】

也正因为如此，面向落地更现实的路线，通常不会是“寻找一个万能模型一次性端到端解决所有问题”，而是构建一套分层、可控、可替换的混合架构。底层先用成熟的解析组件完成 OCR、版面分析、表格结构恢复、公式检测和图片区域切分；中层再做文档级重建，解决阅读顺序、标题层级、跨页拼接、图文挂接和引用回链；再往上，建设领域语义层，把识别结果映射成工程可用的字段、对象和关系，完成术语归一、单位标准化、编号解析和实体对齐；最后，在应用层对接检索、问答、审校、比对、知识图谱和数据库系统。

到了这个阶段，多模态大模型最适合扮演的角色就不再是底层唯一主引擎，而是作为语义整合器、补全器和交互增强器，发挥它真正擅长的能力。比如，它可以帮助做跨块语义整合、标题层级修复、图文关系补全、字段归类、实体关系抽取，甚至可以在人工复核界面中辅助说明为什么某个字段可能存在歧义。但如果一开始就把所有底层解析任务全都直接交给它，系统往往很快会在稳定性、可解释性和可追溯性上碰到天花板。

换句话说，今天真正值得坚持的思路，不是急着追求“全自动”，而是优先建立一套“高置信度自动通过、低置信度高效送审”的半自动系统。这听起来不像“一个模型包打天下”那么吸引眼球，但它更符合工程场景的基本规律。因为工程资料处理最怕的，从来不是平均准确率不够高，而是关键字段偶发错误、表格局部错位、公式含义偏差、编号关系混乱，却又没有办法快速定位、校验和修正。相比之下，一个具备清晰分层、明确追溯锚点、人工复核入口和持续优化闭环的系统，反而更有机会在真实环境里建立信任，并逐步提升自动化水平。

【07 这件事最后拼的，其实是工程语义重建能力】

说到底，工程文档结构化整理真正难的，并不是把内容看见，而是把工程含义还原出来。它难在输入异构，难在版面复杂，难在表格拓扑和公式结构，难在图像任务的双重差异，难在语义高度依赖上下文，也难在结果必须进入一个要求严谨、可追溯、可审计的工程体系。

今天的技术已经足够让我们在不少局部问题上取得明显进展，但距离“稳定、通用、低成本地解决整个问题”仍然有不小的距离。也正因为如此，现阶段最靠谱的路线并不是迷信一个万能模型，而是先把结构化重建做扎实，把领域语义标准化做好，再把多模态模型用在它真正擅长的地方。

这条路线也许不算最炫，但大概率最接近真正能落地的工程现实。工程文档结构化整理的难点，从来不只是识别，而是重建。重建结构，重建关系，最终重建工程含义。

往期推送: