上周接了个旧厂房改造项目的图纸整理活儿业主抱来一箱泛黄的蓝图说是过去二十多年陆续攒的一共1000张要求两天内交出一份符合归档要求的图纸目录方便后续设计院调图。放以前这活儿一个熟练资料员至少得干三四个工作日还得冒着看错图号、誊错图名的风险。这次我没加班。用一套“OCR文字识别 大模型信息抽取 脚本自动汇总”的流程1000张图纸两小时建目录业主拿到手核对了三天没挑出大毛病。这篇文章就把这套方案掰开揉碎讲清楚从需求拆解、工具选型到分阶段实操、踩坑复盘全部摊开来写。搞工程资料、档案数字化、图纸管理的人还有想用AI处理成批文档的朋友都能直接照着抄思路。1. 需求拆解1000张图纸的目录为什么必须用AI做1.1 图纸目录这件事儿的真实难度图纸目录也叫图纸清单或Drawing List是设计文件里最不起眼却又缺不了的东西。正常一套施工图的目录表头上无非是序号、图号、图纸名称、设计阶段、图幅、版次、张数、备注这么几列。看着简单真放到1000张老图纸面前就完全不是那么回事了。首先是图纸本身的状态千奇百怪。我这次接手的旧厂房图纸既有当年晒出来的蓝图也有后来补的硫酸纸底图还有几批从别的设计院转过来的电子档打印件。蓝图上白字是线条和标注标题栏里的字迹有的浓有的浅有些图被叠过、折过图签部分正好被折痕压出一道白印。更麻烦的是老图纸的标题栏格式根本不统一有的在右下角有的在右上角还有的没有正经标题栏就手写一行图名加图号。这意味着不能指望一套固定模板把所有图都框进去。其次是信息字段的规范化。图号这东西是有行规的常见的是“专业代号-子项-序号”这种段位式编码比如建施-01、结施-03也有的设计院用“分项-部位-专业-流水号”的长编码。可老图纸上标注的图号往往缺胳膊少腿有的写成“JZ-01”有的写成“建施/01”还有的干脆只写个“01”得靠旁边的图名猜专业。版本信息更是散乱有的标题栏里盖着“修改A版”的红章有的只在图框角落手写了个日期。再就是目录本身要能复核、能追溯。业主拿去归档是要跟纸质图纸一一对应的。哪张图在哪个柜子、是哪个子项、属于哪个专业目录里都得能查。这就要命在图号不能重复、张数不能对不上、版本不能标错否则后面调设计图的时候找不着图工期就耽误在自己手上了。1.2 人工干这个活儿为什么又慢又容易错咱们算一笔账。一个熟练的资料员拿着一张图先肉眼定位标题栏再逐字认图号、图名、日期脑子过一遍专业分类然后手动填进Excel表格。一张图顺利的话两三分钟遇到字迹糊的、标题栏格式怪的五六分钟打不住。1000张图按平均4分钟一张算那就是4000分钟接近67个小时不吃不喝不休息也要整整两天半。而且人眼长时间盯泛黄的蓝图越到后面越疲劳图号“0”和“O”分不清、“建施”看成“建结”这种事太常见了。返工核对的时间还没算进去呢。更重要的是人工方案不好并行。你可以安排三个人同时录但最后合并的时候顺序、格式、编号规则谁说了算三个人对同一张画的图名解读可能不一样核对起来比重新录还折磨。所以这个活儿本质上不是一个“体力问题”而是一个“认知分工问题”——识别、理解、归类、排版的每个环节都应该让合适的工具去干而不是全堆给人工。1.3 AI方案的整体设计思路我的整体思路是三步走。第一步用OCR工具把每张图纸标题栏区域的文字先“读”出来转成可编辑的文本第二步把文本喂给大模型让模型按工程图纸的行业常识去理解输出结构化的JSON字段包括图号、图名、专业、版本等第三步用脚本把这些字段清洗、校验、排序生成规范的Excel目录并自动标出异常项供人工复核。为什么这么分层而不是直接用多模态大模型对着图纸图片输出结果我试过技术上确实可行但成本翻了好几倍。图纸上的有效信息九成集中在标题栏那一小块而OCR对印刷体汉字的识别精度已经能做到95%以上足够后续抽取使用。先OCR再抽取每张图的处理成本可能就是几厘钱直接上视觉模型1000张图光API费用就是几百块时间也拉长好几倍。工具分工各干各擅长的这才是工程项目的思维。2. 工具链选型OCR、大模型与Excel输出的落地选择2.1 OCR识别层开源自部署还是云端API图纸OCR这块市面上的选择无非三类开源的PaddleOCR、Tesseract商业云OCR以及设计院自带的专业软件。我这次选的是PaddleOCR的本地部署版原因很直接免费、中文识别效果好、能跑在普通CPU上、表格和竖排文字也支持得不错。选型的时候有几个参数特别关键。一个是识别语言工程图纸上以中文简体为主夹杂少量英文代号所以语言包要选ch另一个是方向分类老图纸扫描进去可能是歪的必须开启use_angle_cls参数让模型自动检测图片是否旋转了90度或者180度还有一个是文本检测的阈值默认的det_db_thresh在0.3左右遇到褪色图纸容易漏检可以适当调低到0.2但调太低了会把噪点也当成文字所以得测试着来。我用的一段最基础的调用代码是这样from paddleocr import PaddleOCR ocr PaddleOCR(use_angle_clsTrue, langch, show_logFalse) result ocr.ocr(drawing_001.jpg, clsTrue) for line in result[0]: print(line[1][0], round(line[1][1], 4))需要注意PaddleOCR返回的每个识别框里包含坐标、文本和置信度。坐标信息特别有用后面要用它来判断哪些文字属于标题栏区域哪些只是图框四周的标注。置信度低于0.8的条目我会单独拎出来等大模型抽取时结合上下文去猜不让OCR的错误直接带歪后面的流程。如果是完全没有本地GPU的环境PaddleOCR跑CPU版也行就是速度慢一些。我实测一张A2幅面的扫描图CPU单线程识别大约5到8秒1000张图全跑CPU大概要2小时左右。这个做“两小时目录”项目是不够的所以后面要加并发或者退而求其次用云厂商的OCR接口。但云OCR一张图一两毛钱1000张图一两百块看预算决定吧。2.2 大模型抽取层提示词怎么设计才能稳定输出OCR读出来的是一堆带坐标的文字框比如“[建施] [01] [一层平面图] [2021.03]”但这些字段是散着的得靠大模型把它们认出来、归到正确的字段里。这一步我用的方式是调用通用大模型API输入一段精心设计的提示词输出固定格式的JSON。提示词是整个环节里最看功夫的地方。第一次我写得特别随意“请提取图号和图名”结果模型一会儿输出中文键名一会儿输出英文键名还有几次把“备注”里的内容也当成“图名”塞进来了。后来我改成严格约束型的提示词实测稳定了很多你是工程图纸目录整理助手。下面是一段从图纸标题栏OCR识别出的文本请提取以下字段 图号、图纸名称、专业、设计阶段、图幅、版次、日期。 要求 1. 只输出JSON对象不要任何解释。 2. 图号优先匹配包含“建施”“结施”“水施”“电施”“暖施”等专业代号的字符串。 3. 无法确定的字段填null不要编造。 4. 文本已经被OCR处理过可能有少量错字请结合工程常识修正。 OCR文本 {ocr_text}大模型的输出是可控了但还有两个问题要处理。一个是并发控制API接口大多有限流我用线程池把并发限制在8到10路再加一个简单的重试机制基本不会触发429错误。另一个是字段兜底大模型也有抽风的时候所以JSON解析失败的话我就用正则从原始OCR文本里直接抠图号抠不到的再标记为“需人工确认”。2.3 目录生成层Excel、PDF还是数据库目录的交付形态得看业主的归档习惯。大部分情况Excel就够了因为它能筛选、能排序、能改格式。我用openpyxl生成目录表表头固定为“序号、图号、图纸名称、专业、设计阶段、图幅、版次、日期、备注”每一行对应一张图纸最后加一个“汇总”Sheet。生成的时候一定要设置好列宽和边框打印出来也整齐。另外一个容易被忽略的细节是Excel的“图号”列必须设成文本格式不然图号里带前导零的会被Excel自动转成数字。PDF或数据库形态不是不行但部署和交付成本都比Excel高这次项目没走那条路。3. 手把手实操两小时建目录的完整流程与脚本3.1 第0-30分钟图纸预检与影像预处理这个阶段很多人会忽视但我建议千万别跳。拿到1000张图第一步不是直接扔进OCR而是先按“子项-专业”做个简单的物理分组哪怕只分三级也不要细到每一张。为什么要这么做因为后续的目录表是按专业归类的如果一开始就混在一起后面排序归类的时间反而更长。分完组之后如果是纸质图纸得扫描或拍照。扫描参数上有讲究分辨率建议300dpi以上低于200dpi的话标题栏里的小五号字识别率会明显下降彩色扫描出来的文件太大黑白模式下蓝图的蓝底白字能正常保留吗不一定最好用灰度模式既保留字迹细节文件体积也可控。扫描件如果是歪的PaddleOCR的方向分类能自动纠正90度旋转但如果是5度、8度的小角度倾斜建议先用图像处理库做一下透视矫正不然标题栏里的文字框会对不齐。批量预处理的Python脚本核心逻辑是统一图片格式和文件名from PIL import Image from pathlib import Path src_dir Path(raw_drawings) out_dir Path(preprocessed) out_dir.mkdir(exist_okTrue) for idx, img_path in enumerate(src_dir.glob(*.*)): if img_path.suffix.lower() not in (.jpg, .jpeg, .png, .tif): continue img Image.open(img_path) if img.mode ! L: img img.convert(L) # 统一重命名保留原图映射关系 out_path out_dir / fdwg_{idx:04d}.jpg img.save(out_path, quality95) print(f{img_path.name} - {out_path.name})文件重命名这一步特别关键。因为AI识别的结果最终要能对应回原始图纸文件如果你把1000张图全部按照“dwg_0001.jpg”这种流水号重命名那目录表里就必须再加一列“原文件名”或者直接把原文件名作为唯一标识字段写进JSON结果里。我这次选择保留一个“原始文件名”映射表保证不管后面怎么处理都能找到原始图纸。3.2 第30-50分钟批量OCR识别的并发调优OCR这一步是纯计算密集型的活儿单张串行跑太慢了必须上并发。我自己的做法是先用Python的multiprocessing开4到8个进程每个进程各自加载一份PaddleOCR实例然后对图纸列表做分片处理。这里有个小坑PaddleOCR模型加载本身就要占内存4个进程同时加载8GB内存的机器就有点吃紧所以我建议8G内存以下用2进程16G内存用4到6进程。批量识别的流程简单说就是先读图片列表再做多进程map每个进程返回该图片的OCR文本和置信度最后汇总成一份中间结果JSON。中间结果文件一定要落地保存千万不要只放在内存里因为后面大模型抽取步骤还要用这份数据一旦程序中途崩了OCR结果还能复用不用重新跑一遍。批处理完之后我习惯做一次快速巡检随机抽几十张图的OCR文本人工扫一眼验证识别质量。重点看几个方面图纸名称是否完整、图号里的字母数字是否混在一起、专业代号有没有被误识别。如果抽检的图里错误率超过20%就得考虑调整图片预处理参数如果低于5%说明可以放心进入下一阶段。3.3 第50-90分钟AI字段抽取与规则兜底OCR结果拿到了接下来就是把每张图的文本喂给大模型。这里有一个重要的优化点不要每张图都把整页OCR文本全喂进去而是先用坐标把标题栏区域裁剪出来。标题栏通常在右下角宽高大约占整张图的15%我根据坐标范围简单做一次过滤只保留右下角区域的文本这样喂给模型的token数量大幅下降API费用能省一大半。字段抽取的完整流程我用一个函数串起来import json import re from concurrent.futures import ThreadPoolExecutor def extract_fields(ocr_text): prompt build_prompt(ocr_text) try: response call_llm_api(prompt) data json.loads(response) except Exception: # 大模型失败时用规则兜底正则匹配图号 m re.search(r(建施|结施|水施|电施|暖施)[-/]?\d{2,4}, ocr_text) data { 图号: m.group(0) if m else None, 图名: None, 专业: classify_by_keyword(ocr_text), } return data with ThreadPoolExecutor(max_workers8) as executor: results list(executor.map(extract_fields, ocr_texts))调用大模型API时我用的是流式还是非流式非流式就行因为输出不长等个一两秒就返回了流式反而增加代码复杂度。重试逻辑建议做成最多3次、指数退避第一次失败等1秒第二次失败等2秒第三次放弃并标记为异常。实际跑下来1000张图的信息抽取8路并发大概25分钟搞定。识别效果方面清晰图纸的字段准确率能到95%以上旧图、盖章遮挡图会降到85%左右。这个阶段千万要记得凡是置信度低、字段缺失、JSON解析失败的条目全部打上“needs_review”标签后面统一人工处理不要试图让AI把每张图都猜对。3.4 第90-120分钟目录合成、校验与交付所有字段抽完之后合成Excel目录反而是最轻松的环节。用openpyxl逐行写入图号列设成文本列宽按内容自适应再加一个自动筛选。但真正重要的工作是“校验”这一关我把它分成四步做第一步总数核对。目录总行数应该等于图纸总数多一张少一张都说明OCR或抽取环节丢了图必须回去查。第二步重复图号检查。同一个图号出现两次基本可以断定是两张图纸共用一个号或者识别出的图号有误。第三步专业分布检查。把目录按专业列做个透视表看看建施、结施、水、电、暖的数量跟项目子项是否对得上如果某个专业数量是0大概率是抽取时写错了字段。第四步按比例抽检。随机抽10%到15%的条目对照原始图纸核图号和图名。做完校验没问题再把Excel交给业主。交付之前老规矩输出一份PDF预览版同时把中间过程文件OCR结果、抽取结果、异常标记表一并打包存好。很多资料整理项目业主当时只看目录但三个月后归档审计时可能会问“这张图为什么没进目录”到那时候中间过程数据就是你的自证材料。4. 踩坑实录图纸目录项目中的那些意外与对策4.1 扫描件歪斜、褪色OCR识别率直线下降第一次跑OCR的时候我扔了一批旧蓝图进去结果识别出来的文字简直没法看“结施”识别成“给施”“一层平面图”识别成“一层干面图”。排查之后发现问题出在图片本身一个是扫描时纸张没放正标题栏整体歪了大约6度文字框跟检测框错位另一个是蓝图的蓝色底纹太深灰度化之后文字和背景对比度不够。解决办法有两招一是用OpenCV做边缘检测找图框四角做透视矫正二是做自适应阈值二值化。两招都补上识别率立刻回到正常水平。后来我还总结出一条经验遇到褪色特别严重的图与其反复调算法不如直接换一份电子档重新生成图片省下的时间够干好几轮识别。4.2 图号格式不统一正则匹配差点翻车工程图号的编码规则比我预想中乱得多。同一个项目里“JZ-01”、“建施01”、“建施-01-改”三种写法都有还有的设计院用“A1-01-001”这种长编码。一开始我打算用正则规则把图号全部“规范”成固定格式结果被一堆特殊字符打败了。后来我调整了策略不试图统一格式而是保留抽取结果里的原始写法再把“专业代号”单独拆出来作为分类字段。目录表里同时保留“原图号”和“专业”两列以后需要按专业筛选就用“专业”列需要精确定位就用“原图号”列。别跟格式死磕数据结构上多一列比写一堆正则优雅得多。4.3 印章、折痕把图名挡了一半怎么办旧图纸上有不少红色归档章、竣工图章盖的位置还很刁钻正好压在标题栏上。OCR对红色印章区域的处理能力有限经常把印章上的字和图名混在一起或者干脆把被盖住的文字识别成乱码。这个问题的解法是分层看遇到红色印章干扰先对图像做颜色通道分离把红色通道提出来单独存一张然后把红章区域在原始灰度图里抹成白色再去跑OCR。实测下来这个预处理动作能救回大约三成原本识别不了的老图纸。还有一些图纸是被长期折叠过的折痕正好压在图名中间这种就只能靠大模型的语义猜测了——把前后的文字上下文喂进去让它根据“一层”“平面图”这些碎片猜出完整图名。猜对了就用猜错了反正有人工复核兜底。4.4 大模型API偶尔抽风别把鸡蛋放一个篮子里整个流程跑下来大模型环节出问题的概率是最高的。有时候是网络超时有时候是返回的JSON格式带了额外文字有时候是模型突然“一本正经地胡说八道”把图纸名称编得跟真的一样。应对手段有三层第一层是重试机制超时或解析失败就重新请求第二层是规则兜底用正则从OCR文本里直接提取图号字段至少保证关键信息不全丢第三层是置信度分级每张图都让模型给自己输出一个conf字段0到1之间的数低于0.7的自动标记为待人工复核。这三层下来整体流程的稳定性已经从“偶尔翻车”到了“基本可交付”的状态。4.5 成本与时间账本这套方案到底值不值最后算一笔细账。本地OCR部分主要成本是时间和电费1000张图并发处理大约40分钟一台普通办公电脑就能带得动。大模型API部分按1000张图、每张压缩后约300到500字符的OCR文本计算加上提示词每张大概消耗1200个token1000张就是120万token。按目前市面上的主流API价格大约几十元人民币。人工复核部分抽检100张图每张1分钟一个半小时就打住了。整体算下来两小时的机器时间加上一百多块的API费用再加一个半天的抽检人工对比传统人工三到五天的工作量高下立判。用这个方案处理其他批量文档也是一样的逻辑。合同发票、产品手册、老旧报刊只要是“大量图片/扫描件需要提取固定字段汇成表格”的场景都可以直接套用这一整套流程。我个人经验是工具链跑通之后难点永远不在技术本身而在前期的字段定义和后期的人工抽检标准——这两块想清楚了AI处理批量目录就是水到渠成的事。