ARTICLE DETAIL

资讯详情

深耕网站视觉设计与运营推广的一线实战洞察。

AI审图系统落地全解析:从架构设计到模型训练与规则引擎实战

AI审图系统落地全解析:从架构设计到模型训练与规则引擎实战 AI审图这几年在我这个圈子里已经不算新鲜词了但真正动手把一套系统搭出来的团队并不多。大部分人停在“测试了一个模型”或者“用商用小工具跑了几张图”的阶段而一套能进生产、能出审查报告、能让设计院或者审图机构日常用起来的AI审图系统链路远比想象中长。这篇文章把我自己搭这套系统的完整思路、架构分层、模型训练细节、规则引擎写法和踩过的坑一次性说透适合设计院信息化负责人、施工图审查机构的技术团队、以及想在建筑工程场景落地AI的算法工程师参考。1. 为什么审图值得上AI先看清这行字背后的活1.1 审图审查到底在审什么很多人以为“审图”就是看图纸有没有画错实际上施工图审查的工作量非常大。一套常规的住宅楼施工图建筑、结构、水、暖、电五个专业加起来少则几十张、多则上百张A0/A1图纸。审查内容分两大部分一是合规性审查也就是图纸内容是否满足国家和地方的工程建设标准、消防规范、节能规范二是安全性审查比如结构配筋是否满足计算要求、疏散通道宽度是否符合防火规范。这两部分工作里真正适合AI先吃下来的是建筑专业里可以被明确量化的规则。比如防火分区的面积是否超限、疏散门的开启方向是否指向疏散方向、楼梯间和前室的布置是否满足规范、某个房间的面积是否达标。这类检查有清晰的条文依据、有固定的图面表达方式本质上就是“在图纸上找构件、再按规则做判断”的过程天然适合拆成计算机视觉加规则引擎两条流水线。不太适合一上来就交给AI的是结构计算书的复核、暖通负荷计算这种需要大量数值计算和专业判断的内容。这部分数据不在图面上或者即使在看图也只能看到结论机器无法还原计算过程。所以一个清醒的项目起点是先划清系统边界不要试图做一个全专业无人审图机那是终极形态不是第一版。1.2 AI审图系统的工作边界该管的和不该管的我最初犯过一个方向性错误想让模型直接输出“这里违反了哪条规范”。后来发现这是一个典型的坏目标目标检测模型擅长的是“图里有什么、在哪”不擅长“这个事实是否合规”。规范判断涉及上下文、构件之间的相对关系、甚至要结合设计说明的文字这些超过了一个检测头的能力范围。正确的边界应该是识别层管事实图纸里有什么构件、构件在什么位置、尺寸大概多少。比如这层有几个疏散楼梯、走道宽多少、喷头间距多少。规则层管合规把识别出来的事实喂给规则引擎由代码逐条判断是否满足规范。比如走道宽度是否不小于1.2米、疏散距离是否超长。人工层管终审系统输出疑似问题清单审查工程师逐条复核确认后写入正式审查意见。这个三层结构贯穿了我整个系统设计后面所有模块都是围绕它展开的。它最大的好处是让每一层的错误可以被单独定位和修正识别错了改模型规则错了改代码系统误报率高就调阈值而不是一切搅在一起。2. 整体架构图纸进来、问题单出去的完整链路2.1 图纸输入层DWG、PDF、光栅图的三条路审图系统第一步要解决“图纸从哪里来”的问题。我接触到的图纸来源主要有三种处理方式完全不同。DWG/DXF矢量图纸是最理想的数据源。这里面不光有图形还有图层、线型、块定义、文字属性这些结构化信息。但DWG是封闭格式解析门槛不低需要用ODA、LibreDWG这类库做转换。我当时的做法是先统一转成DXF再按图层把墙体、门窗、标注文字、图框分离出来。这一步做得好后面识别模型的压力能小一半。PDF图纸是审图机构里最普遍的存在。设计院交付的往往是一套PDF优点是不会被随意篡改缺点是图层信息完全丢失只剩矢量线条和文字。这种图需要专门做解析把矢量路径按几何特征重新聚类尽可能还原出墙体轮廓、门窗图块。效果不如原生DWG但足够支撑后续识别。扫描光栅图在老项目和改造项目里经常出现。这种图没有矢量信息只能当纯图像处理。识别难度最大因为图面经常有褶皱、倾斜、污渍构件边缘不干净。对这类图我建议第一版系统不要承诺太高的检出率先把DWG和PDF两类吃透光栅图作为后续迭代项。工程上有一个容易忽略的点图纸比例尺。一套图里平面图通常是1:100节点详图可能是1:20总图可能是1:500。模型只做目标检测时比例尺问题不大但到了规则引擎算实际距离时必须从图框或标题栏里解析出比例尺把像素距离换算成毫米。这个信息在DWG里可以直接读出PDF里往往要配合图签解析我见过不少团队在模型上跑出了漂亮结果一算距离全错了问题就出在换算系数上。2.2 识别层从像素到构件再到空间关系识别层是整个系统的技术核心我最终采用的是目标检测模型加后处理的空间关系抽取两步走。第一步是目标检测用模型找出图纸上的构件。我最初用YOLOv8后来切换到了RT-DETR检测头处理A0大图的密集小目标效果更好。需要识别的物件类型集中在建筑专业墙体、门、窗、疏散楼梯、电梯、消火栓、灭火器、喷头、疏散指示标志、房间边界、走道区域等。第二步是空间关系抽取这一步很多人会忽略。检测模型输出的只是一个个孤立框但审图规则要的是关系。比如“这个门是不是开向疏散方向”“这个房间的疏散门是否通向走道”“这个防火分区的面积有多大”都需要把散落的构件框组装成有意义的结构。我为此写了一套后处理模块专门做三件事墙线合并把断开的墙段按共线、方向一致、距离接近三个条件合并成完整墙体并识别出墙体厚度。房间闭合检测用墙体线段围合出房间多边形算面积、周长并标记门窗开口位置。连通关系提取判断每个房间和走道之间有哪些门洞相连建立房间邻接表。这套后处理在工程上很关键。检测模型哪怕单个构件的召回率只有95%到了房间闭合这一步如果墙体缺了一小段房间边界就闭合不上面积计算直接失败。所以我在后处理阶段做了大量形态学修复包括断点连接、短线段清理、直角规整才让整条链路稳定下来。2.3 规则层与输出层审查结论怎么生成规则层设计讲究“把规范条文变成数据”。我维护了一个规则配置库每条规则有唯一的规则编号、适用的规范条款号、需要的输入字段、判断逻辑、严重等级和提示话术。比如疏散距离检查输入是房间门的坐标、最近安全出口的坐标、走道障碍物边界规则引擎先算实际疏散路径长度再和规范限值比较超限就生成一条问题记录。输出层是我花了很多心思的地方。审查结果不能只给一句“这里有问题”必须做到每条问题都带截图、位置坐标、涉及构件清单、规则依据和修改建议。审查工程师拿到这样的问题单能在几十秒内定位到图面并复核系统才能真正融进工作流。我自己开发了一套问题单生成模块把模型输出的bbox坐标、规则引擎的判断条件、规范条文内容和图面裁剪图打包成结构化JSON再渲染成网页版的审查意见表。2.4 为什么纯视觉大模型一时半会儿接不了审图这两年多模态大模型很热也经常有人问我为什么不直接用视觉大模型看图纸我认真试过结论是大模型目前做不了审图。核心原因有三个尺寸精度不行审图大量规则依赖毫米级数值判断比如走道净宽是否≥1.2米、喷头间距是否在2.4米到3.6米之间。大模型对“大概多宽”有概念但给不出稳定精确的像素级坐标和数值。图纸超出常规图像比例A0图纸在模型里缩放后本该仔细看的小构件只剩几个像素大模型的视觉编码器在这种超高分辨率输入上表现很差。规则召回不稳定同样的一个问题换个图幅、换个设计院的画法大模型可能时对时错。审图场景要的是可复现、可解释的判断不是统计意义上的概率。所以我最终的路线是传统目标检测模型做识别规则引擎做判断大模型只在后期做一个辅助能力——把规范条文检索、审查意见润色这类文本工作接进来。这样既避免了大模型的不稳定性又享受了它在语言理解上的优势。3. 检测模型训练审图场景和数据标注实战3.1 标注规范AOI定义比模型结构更值得花时间要说整个项目里最值钱的部分我认为不是模型代码而是标注规范。图纸上的构件和自然图像里的物体不一样存在大量“边界模糊”的情况。比如一扇平开门要标注的范围是什么门扇门洞还是包含门套楼梯间算是走道的一部分还是独立构件这些不定义清楚不同标注员标出来的框五花八门模型根本学不到稳定特征。我的做法是先花了整整两周时间写标注规范文档每种构件类型都给出标注对象定义什么情况下标、什么情况下不标。框选范围标准比如墙体标注包含两侧抹灰层不包含填充图案疏散指示标志只标标志本体不标安装支架。边界遮挡处理构件被家具、设备遮挡时按可推断的完整轮廓标不要因为遮挡就只标露出部分。最小尺寸过滤小于8像素的构件不标避免噪声样本。规范写完还要做一次标注一致性测试找5个标注员同一张图各自标一遍计算框之间的IOU一致性低于0.7的类别要重新定义标准。整个流程跑下来训练数据的质量比一开始直接甩给标注平台高了一个档次。3.2 超大图切片推理与跨切片目标合并建A0图纸的图像分辨率动辄上万乘上万像素任何检测模型都不可能直接整图推理。必须先切片再推理。我用的方案是滑窗切片加重叠推理切片尺寸固定为1024×1024像素。相邻切片重叠128像素保证跨切片的目标至少完整出现在一个切片里。每张切片独立推理得到局部bbox。所有切片的结果投影回全图坐标用NMS非极大值抑制合并重叠区域重复检出的目标。听起来是个标准流程但工程里有几个细节很阴险。第一是跨切片目标的置信度不一致同一个构件被两个切片各检测到一次置信度可能一个是0.9一个是0.6如果简单按0.5阈值过滤低置信度那个会被误删导致目标被切开后两边都保留、中间断开。我最后的处理是按类别合并两个框的IOU大于0.3且中心距离小于目标尺寸一半时保留置信度高的一方同时把坐标修正为两个框的加权平均。第二是图幅方向。A0竖版、横版、加长版都有模型推理前要读图框角点做旋转矫正统一成固定方向。不矫正的话同一类构件在不同旋转角度下的特征差异会显著拉低检测精度。我踩过这个坑后面单独写了一节。3.3 跨设计院风格的泛化问题检测模型最容易翻车的场景是训练集来自本院图纸拿来审另一个设计院的图召回率直接掉十几个点。原因是不同设计院的画图习惯差别太大了。同一个“消火栓”甲院用标准图例填充乙院用自定义块丙院直接画个圆圈加文字标注。墙体表达也是有的院用双线表示墙体有的院用PLINE粗线填充模型对线型、填充模式的敏感度远高于我们的预期。应对策略是三管齐下训练集里刻意混合多个设计院的图纸每个院的图不超过总量的30%防止模型学到院风格偏好。在预处理阶段做风格归一化统一线宽、统一图层颜色、把填充图案栅格化后做形态学滤波尽量抹平风格差异。建立跨院验证集每个月用新接入设计院的图纸做盲测一旦发现某类构件召回率低于阈值就针对性补充该院所风格的数据再微调。这个方法论比调模型结构参数重要得多。我后来统计过同等模型结构下光靠扩充数据风格多样性跨院mAP能从0.72涨到0.85以上。4. 规则引擎设计把规范条文翻译成机器能执行的逻辑4.1 三类规则存在性、距离数值、空间关系审图规则看起来五花八门抽象下来就三类。存在性规则最简单图纸上必须出现某类构件。比如“这个防火分区必须设置两个安全出口”“这个房间必须设置机械排烟口”。这类规则只需要对检测结果做数量统计低于阈值直接报缺失。工程上要注意的是必须结合图幅范围判断不能全图统计。因为一张图里可能有多个防火分区漏了区域划分的话缺口的判断就会错位。数值规则稍微复杂点构件的尺寸、间距、面积要落在某个区间。比如“走道净宽不小于1.2米”“两个安全出口之间的距离不小于5米”“喷头间距不大于3.6米”。这类规则要先把像素坐标换算成实际尺寸再做判断。数值规则还要处理好一个边界问题规范规定的是“净宽”“净高”图面上画的是轴线尺寸和建筑完成面尺寸中间差了墙体厚度和粉刷层。我一开始没注意结果大量走道宽度判超限后来统一在规则引擎里加了尺寸修正系数才解决。空间关系规则最难判断两个或多个构件之间的拓扑关系。比如“疏散门是否开向疏散方向”“楼梯间是否直接通向室外”“房间门是否开向走道”。这类规则没法靠单次检测完成必须依赖第2章说的空间关系抽取结果。我实现了基础的拓扑判断算子包括点在多边形内、线段与多边形相交、多边形相邻、方向向量判断等一套下来代码量不小但都是通用组件写一次能复用很久。4.2 疏散距离为什么不能算直线疏散距离检查是审图里的高频规则也是规则引擎里最坑的一个。刚写第一版的时候我用的是欧氏距离房间门的坐标到安全出口坐标画一条直线看距离超没超。后来被审查工程师朋友一句话点醒“你这条线穿墙穿柱穿楼梯疏散的人能穿过去吗”疏散距离必须沿实际的疏散路径计算。人要推开房间门、走到走道、绕过家具和设备、下楼梯、到达安全出口路径是绕着障碍物走的折线不是直线。要算准这个必须有房间墙体和走道边界的完整几何数据然后做路径规划。我第一反应是上A*算法后来发现图纸场景里其实可以简化疏散路径主要沿着走道中线走。我的实现方式是这样先把走道多边形做骨架化提取走道中心线生成一张节点图。再把房间门的出口映射到最近的走道中心线节点上用Dijkstra算法算出从门到安全出口沿走道的通行距离。最后再加上从门到走道的那一小段垂直距离。这套算法跑下来计算的疏散距离和审查工程师手工量出来的结果误差控制在5%以内才算真正能用于审查。4.3 置信度阈值和确定性分级让机器知道自己不确定规则引擎的输入来自检测模型检测模型不可能100%准确。如果规则引擎对低置信度的检测结果一视同仁会产生大量“幽灵问题”。比如某个框其实不是疏散指示标志置信度只有0.4但规则引擎因为它“不存在”就报缺失这就是纯噪音。我的解法是给每条审查结论加一个确定性等级高确定检测目标置信度大于0.9且多个独立证据链互相印证规则引擎直接给出审查意见。中确定置信度在0.6到0.9之间规则引擎给出“疑似问题”需要人工复核。低确定置信度低于0.6或者证据链不完整系统不直接下结论只做提醒。这个分级设计完全改观了使用方的态度。审查工程师不再被一堆明显错误的提示淹没系统从“总是报错”变成“大多数时候靠谱、偶尔需要确认”信任度一下就上来了。5. 实测踩坑记录从模型跑通到系统可用的五十个日夜5.1 把CAD当成自然图像处理的坐标系悲剧这个坑是我整个项目里最后悔的一个。最开始我做预处理时直接把DWG转成PNG图片扔给检测模型跑。模型的mAP在测试集上刷得很高但一到实际图纸就稀碎。后来定位才发现问题出在DWG文件的坐标系上。CAD的坐标系是绝对的世界坐标一张图纸里的模型空间可能横跨几百米但图签、图框、详图往往分布在不同的坐标位置。转成PNG时刚才那些分散的内容全部被塞进一张图片里有的构件出现了两次有的比例完全失真。正确的做法必须分两步先通过图框识别切出每张图纸的实际绘图区域再在绘图区域内做坐标归一化和比例换算。DWG里有真实的坐标信息这些信息直接解析出来做几何计算和规则判断远比转成图片再让模型去猜要可靠。我后来把所有规则引擎的输入都改成了“DWG解析出的矢量坐标加检测模型的补充识别”两条数据源互相校验效果才稳定。5.2 图层信息丢失导致识别率暴跌还有一个让我印象很深的翻车现场。有一批PDF图纸没有原始DWG只能走PDF解析路线。一开始直接对PDF渲染出来的图片跑检测门窗小构件识别率惨不忍睹墙体倒是很清晰。后来仔细对比了PDF和DWG的差异才发现PDF里的图纸虽然看起来一样但很多构件是短线堆出来的没有DWG里图层的语义信息。而且PDF的文字标注和图例特别多模型把大量注意力浪费在无关文字上。解决的办法是对PDF做图层还原的逆向工程把矢量路径按线宽、颜色、几何形态聚类。粗的连续线大概率是墙细的闭合框大概率是门窗和标注框。经过这一层预处理再对还原出的几何对象做检测而不是对全图做检测识别率立刻回升到和DWG差不多的水平。5.3 漏报比误报更可怕审图场景的召回率策略做视觉系统的人通常习惯追求“精度优先”宁可少报也不要报错一堆噪音。但审图场景恰恰相反漏报的代价远大于误报。人工审查本来就会看漏AI如果也漏了等于双重漏筛这个问题就彻底从系统中消失了。而误报只是多一条待复核记录审查工程师扫一眼就能排除。所以我在系统里专门做了一个“低阈值召回模式”把检测置信度阈值降到0.3让模型把所有可疑目标全部报出来再通过规则引擎和人工复核把低置信度结果逐条过滤。这套策略牺牲了小部分规则引擎的自动化率但换来了极高的漏检兜底能力。我在评估指标上也做了对齐不再用mAP作为最终效果指标而是用“审查问题检出率”和“人工复核效率”这两个业务指标。这一转变是我认为整个项目能真正落地最重要的一步。5.4 性能瓶颈一栋楼几千张图怎么排产AI审图系统不是跑通一个Demo就完事真上线后性能瓶颈立刻暴露。一套完整的住宅项目建筑专业图纸少说几百张每张A0图切成几十个1024×1024切片一个切片推理要几十毫秒全楼跑一遍就是几个小时。单机串行推进审查周期根本等不起。我的解决思路是分三层优化第一层GPU推理队列并行。用消息队列把所有切片任务分发到多张GPU卡上单张图的推理时间能压缩到1-2分钟。第二层规则引擎和识别层并行流水线。识别完一部分构件就开始算规则不用等全图识别完。第三层缓存机制。同一栋楼不同楼层的图纸结构高度相似对重复的构件区域直接命中缓存不重复推理。三层优化加完一栋10多层的住宅楼建筑图纸全流程审查从最初的3-4个小时压到了40分钟以内。这个速度对审查机构来说已经属于“完全能用并且想天天用”的状态。6. 选型对照与从零起步的建议6.1 商用平台、自研与混合方案怎么选动手之前一定要先做选型评估别一上来就准备自研。我把市面上能看到的路径分成三条方案类型优点缺点适用团队商用施工图审查平台开箱即用构件库覆盖广规则引擎预置多有售后规则黑盒难定制数据合规和图纸保密问题敏感年费不便宜没有算法团队、以快速提效为目标的审图机构完全自研规则定制灵活数据资产完全自有可以围绕内部流程深度定制周期长算法团队成本高初期识别效果不一定比商用平台好有算法和工程团队、且图纸保密要求高的大型设计院开源模型自建规则引擎成本可控模型可迭代规则完全自主前期需要不小的工程投入构件识别效果依赖训练数据量有少量算法能力、想掌握核心能力的中间型团队我最终选的是第三条路。理由很实际商用平台改不动的“冷门规则”在我们这里层出不穷完全自研又没有那么大的团队规模开源模型加自建规则引擎正好卡在我这个团队的资源边界上。6.2 起步场景先做消防疏散还是先做建筑合规很多团队一上来就想把所有专业全做了这是最大的坑。审图系统落地一定要选一个可量化、频度高、规则清晰的窄场景切入。我强烈建议从消防审查起步理由是消防规则在图面上表达最明确疏散距离、安全出口数量、防火分区面积、喷头间距、疏散宽度。这些规则不需要复杂的专业数值计算全部可以转化为第4章说的三类规则目标检测也不需要识别冷门构件。建筑合规净高、日照、无障碍设计这类虽然也高频但很多判断依赖气候区、建筑类型、功能分区等上下文信息第一版做起来容易失控。等消防审查的链路全部跑通、团队积累了稳定的训练数据和处理经验再横向扩展到人防、绿建、无障碍每个新场景都是对已有架构的一次复用边际成本会低很多。6.3 数据回流与标准库沉淀审图模型的复利效应最后说说数据资产这件事。AI审图系统上线后真正的价值放大器是数据回流机制。我在系统里设计了一条完整的数据闭环每次审查工程师复核问题单时凡是对AI结论做了修正增加一条问题、删掉一条误报、调整框的位置这些修正数据都会自动记录下来。定期汇总成新的训练样本进入下一轮模型微调。刚开始系统表现平平但每跑一个项目、每被人工纠正一次模型就在变强。半年下来我明显感觉到误报率在下降新项目的识别准确率已经接近甚至超过了商用平台的常见水平。同时我还把规则的版本管理做成了标准库每条规范条文的启用、修订、废止都在系统里留痕审图结论可以精确追溯到当时采用了哪个版本的规则。这在审查责任认定和跨期归档的时候非常重要。一个AI审图系统的长期价值一半在模型另一半也在这个不断积累的规则标准库里。这两样东西都会随着使用次数增多而越来越值钱这是我认为这个方向值得持续投入的最根本原因。
返回列表