隧道贯通后最让人头疼的不是盾构机本身而是那几公里灰扑扑的管壁。渗水、裂缝、错台、剥落过去全靠巡检人员踩着高空作业车、打着强光灯仰着脖子一米一米地看。这次做的项目就是把这套人工巡检换成AI基于LeYOLO全系列n/s/m/l参数模型在嵌入式端构建盾构管壁缺陷病害的实时检测预警系统。简单说巡检台车装上相机和边缘计算设备模型在现场实时识别管壁异常发现问题当场报警。这套系统一开始就不是奔着“论文指标”去的目标很实际让一线巡检工不用那么辛苦让缺陷台账从“凭经验写”变成“由模型标”让渗漏、裂缝这类风险能被及时发现、及时处置。对做施工监测、隧道运维、边缘AI部署的同行来说这篇文章里的数据闭环、模型选型思路和现场踩坑记录应该都能直接参考。1. 盾构隧道管壁巡检的痛点为什么这项基建安全工作必须交给AI1.1 传统人工巡检的三个死结先说可达性。盾构隧道是一个狭长的筒状结构管壁分布在拱顶、拱腰、拱底各个位置。人站在巡检台车上受作业高度和角度限制很多位置只能远远看一眼看不清楚。尤其是江底隧道或者山岭隧道贯通后内部湿度大、粉尘重、照明条件差人长时间仰头观察视线容易疲劳漏掉一条细微裂缝是很正常的事。再说主观性。同一处渗水老工程师可能判断成“表面湿渍”新来的人可能觉得是“结构渗漏”同一个缺陷在不同人手里写出的记录可能完全不同。病害尺寸靠目测估位置靠里程桩号加手记回来后整理台账还要人工誊写一遍中间环节越多信息失真越严重。最后是时效性。人工巡检通常是按计划周期进行的发现缺陷后还要回到项目部整理报告再上报处置。遇到渗漏水这类动态发展的病害晚发现一天背后可能就多流失一天的水土风险攒到一定程度才会暴露。这三大死结决定了一件事靠人眼做全断面、高频率的缺陷普查注定只能“抽查”很难做到“全覆盖”。1.2 从“事后人工排查”到“实时边缘预警”的范式变化这套系统做的是范式层面的改变巡检设备上安装工业相机沿着隧道走一圈连续采集管壁图像边缘端嵌入式设备直接跑AI模型对视频流逐帧推理一旦发现缺陷当场声光报警、自动截图、记录里程位置。整个过程不需要把视频传回机房隧道里网络信号差也没关系数据在采集端就完成了处理。这个“数据不出现场”的特点也是我们选嵌入式端方案的一个重要原因。盾构隧道刚建成的阶段洞内经常没有稳定的有线网络和无线覆盖如果用“前端采集后台分析”的云端架构视频传输带宽和时延都是大问题。边缘端实时推理把计算前移网络只用来上报结果和报警信息数据量从GB级降到了KB级现场部署的工程难度一下子小了很多。1.3 盾构管壁缺陷到底指的是什么AI需要检测什么聊系统之前先把检测对象说清楚。盾构隧道管壁通常由预制混凝土管片拼装而成环环相接。我们重点检测的缺陷病害主要包括这几类缺陷类型典型视觉特征主要风险渗漏水及湿渍颜色明显深于周围管壁边缘不规则面积大小不一管周水土流失长期可能引发地层沉降裂缝线状纹理分为环向、纵向、斜向宽度较小结构受力异常水汽可能沿裂缝渗入错台相邻管片接缝处出现高低差伴随阴影棱线拼装质量缺陷影响防水和受力剥落与破损混凝土表层脱落露出骨料甚至钢筋结构耐久性受损螺栓孔异常螺栓缺失、渗水、周围混凝土破损管片连接可靠性下降需要说明的是这类检测和工业质检的“毫米级精度”思路不完全一样。工业质检要求把0.1mm的划痕分出来而盾构管壁巡检的核心是“发现—定位—分级—处置”先把异常目标找出来给它一个位置和类别再按严重程度决定是否需要人工复核。这个定位决定了模型设计、数据标注和预警策略的走向。2. 为什么选LeYOLO全系列嵌入式端检测模型的选型逻辑2.1 嵌入式端到底“轻”在哪里做端侧部署的人都有体会“轻量级”不是一个模糊的形容词而是一组硬约束。隧道巡检设备算力有限常见的嵌入式板卡算力只有几个TOPS内存几个G供电和散热条件也远不如机房服务器。就在这样的环境下我们要求模型跟随巡检车运动时保持实时推理——视频流不能掉帧检测结果不能滞后太多。一个常规的目标检测模型在服务器上用GPU跑可能很快搬到嵌入式端帧率立刻掉到个位数。这不是显卡不行而是端侧推理无论是带宽、算子优化还是内存调度都和服务器差异很大。“轻”必须是端到端的轻前处理、模型推理、后处理全链路加起来的延迟可控而不是光看模型参数量小不小。这里我强调一个反直觉的点有时候一个模型参数量不大但里面某些算子对端侧硬件极不友好实际跑起来反而比参数量更大的模型还慢。所以选型时候不能只看一个数字要看目标硬件上的实测帧率。2.2 LeYOLO n/s/m/l四档如何分布定位LeYOLO系列最方便的地方在于它是按n/s/m/l四档给出的一套完整模型族而不是单一模型。四个档位覆盖了从“极低算力设备实时检测”到“高精度离线复核”的不同需求我们可以用同一套数据训练出不同规格的模型按场景切换模型档位定位典型算力需求适用场景n极轻量档较低功耗设备即可实时运行长时间连续视频流巡检低功耗嵌入式盒子s均衡档中等算力边缘板卡常规巡检主力性价比最高m精度档较高算力设备对错台、细小裂缝等难检目标有更高召回l复核档高性能板卡或离线服务器关键断面抽检复核、数据集中批量审阅实际工程中我们并不是只用一个档位。巡检车日常跑的时候用s档遇到高风险区段或者重点复测时切到m档后期对采回来的数据做批量离线复查时用l档。n档则用在一些需要长续航的低功耗采集设备上。全系列最直接的收益是一套标注数据、四个档位模型按任务切换配置不用每个任务都从零开始调一个模型出来。2.3 为什么不像传统做法那样把大模型瘦身有一类常见的做法是先训练一个大模型达到目标精度后再做剪枝、蒸馏、量化硬塞进端侧设备。这个方法在很多场景能成但工程成本不低——剪枝的比例、蒸馏的温度、量化后的精度损失每一项都要反复试错才能平衡好。而且大模型被压缩后很多时候精度说掉就掉排查起来非常折腾。LeYOLO这类原生轻量化模型就不太一样。它的网络结构本身就是针对边缘计算设计的在保证检测能力的同时把计算量控制在了端侧可接受的范围。用大白话讲一个是“给胖子减肥费劲还要小心反弹”另一个是“天生瘦子底子就适合跑步”。如果你也遇到“端上跑不动”的问题我建议先看看有没有原生轻量模型可以直接用不要一上来就想着把手头的大模型改造下去那样调试周期会拉得很长。3. 缺陷数据闭环从现场图像到高质量训练集3.1 图像采集的现实条件模型要检测得好数据是地基。盾构隧道里的图像采集条件和普通拍照差别很大。隧道内部昏暗只有施工照明灯和巡检车自带光源直接拍出来的照片往往存在严重的明暗不均。我们的做法是给巡检设备加装补光灯并尽量让相机以固定距离、固定角度正对管壁这样模型学到的特征相对稳定部署时也不需要频繁调整参数。采集工况的覆盖度非常关键。不同盾构区间的地质条件差异很大地下水丰富的区域渗水病害明显更多软弱地层里管片错台更常见不同厂家生产的管片在表面纹理上也存在差异。如果数据只在某一个区间采集模型换到另一个区间很容易出现误检。我们当时特意安排了几次跨区域采集把不同光照、不同湿度、不同管片厂家的样本都收进来才敢正式训练。采集参数上有个容易被忽略的点就是“图像分辨率对应的物理尺寸”。管壁上的细小裂缝在图像里可能只有几十个像素宽如果拍摄距离太远或者分辨率不够裂缝从物理上就无法被检测出来。这不是模型能力问题而是成像极限问题。我们根据现场需要识别的裂缝最小宽度倒推出了相机分辨率、拍摄距离和工作焦距的匹配关系确保在图像层面先满足检出条件。3.2 标注细节决定模型上限数据标注是决定模型上限的关键步骤这里值得多说几句。我们建立了和业务对应的类别体系渗水/湿渍、裂缝、错台、剥落/破损、螺栓孔异常。标注时要求标注框尽量贴住缺陷边缘尤其是裂缝这类细长目标标注框松一点模型的定位精度就明显下降后续计算缺陷宽度、面积也容易出错。标注中最麻烦的是边界模糊问题。渗水和水渍在视觉上非常接近裂缝和管片接缝又都有线条特征标注人员如果不理解现场工况很容易标错。我们的处理方式是给标注团队做了一次现场培训带着他们到隧道里看了一遍真实缺陷同时制定了两级审核制度——第一遍初标第二遍由有现场经验的人复核再定期做一致性抽检避免同一批数据里出现“同一种现象两种标准”。还有一个值得强调的细节数据划分不能简单随机切分。同一环管壁在视频里会连续出现在很多帧里如果这些帧一部分进训练集、一部分进验证集相当于模型“提前见过答案”评估指标会虚高。我们把数据按断面、按环号划分保证同一位置的图像不会横跨训练集和验证集这样测出来的性能才有参考价值。3.3 数据增强与样本平衡隧道场景有自己的专属增强手段。亮度扰动和对比度扰动是必须的因为现场光照变化很大运动模糊模拟巡检台车移动带来的拖影水汽和尘雾模糊可以模拟隧道内湿气大、能见度低的情况。我们还加入了一定比例的随机遮挡模拟管壁上有管线、支架等遮挡物时的情况增强模型在复杂背景下的鲁棒性。类别不平衡是这个场景里很突出的问题。渗水类样本数量通常远多于螺栓孔异常类模型训练出来容易偏向大类少数类缺陷被漏检。我们的处理手段包括对少数类样本做更激进的增强训练时给少数类更高的损失权重以及采用分层采样让每个批次里尽量包含多个类别的样本。这些手段组合使用之后少数类召回率提升非常明显。4. 全系列n/s/m/l训练与调优精度与算力的折中艺术4.1 统一训练流程和迁移学习策略四个档位虽然模型大小不同但我们的训练流程是统一的方便对比和维护。第一步用公开的预训练权重做初始化第二步在盾构管壁数据集上做迁移学习。迁移学习不是直接全量训练而是分阶段先冻结backbone的前若干层只训练检测头让模型快速适应新数据然后再解冻部分层做微调最后在所有数据上做一次全量微调。超参数方面输入分辨率我们统一用了检测小目标相对友好的配置。学习率采用warmup加余弦衰减的组合批次大小根据显卡内存调整。如果发现某个档位收敛速度偏慢我们会先在n档上快速验证一组超参数是否有效再迁移到m/l档上做完整训练这样能节省大量试错时间。有个细节是锚框设计。管壁裂缝是典型的细长目标长宽比极大普通默认锚框对这类目标不友好。我们按裂缝的实际长宽分布重新聚类了一组锚框让模型对“细长条”形状有更好的初始匹配。改完这步裂缝类别的召回率提升了不少属于性价比很高的操作。4.2 各档位的训练差异和过拟合欠拟合控制四个档位的模型容量不同训练时对数据量的需求也不一样。n档模型容量小在数据量充足时容易表现为欠拟合需要更多的训练轮次同时数据增强力度不能太猛否则模型学不过来。s档最均衡按常规节奏训练就行。m/l档模型容量大数据量跟不上时就容易过拟合这时候要加大数据增强、加正则项并配合早停策略。实际训练中判断一个档位是否练到位不能只看mAP。盾构管壁检测更关心的是召回率——宁可误报多一点也尽量不要漏掉真实缺陷。所以我们评估时重点看mAP50和召回率曲线同时统计误报率确保提召回的同时误报没有失控。每轮训练结束我们都会导出推理结果做人工抽看比如“模型把哪类东西当成渗水了”这类定性分析比单个数字更能指导下一步优化。4.3 量化、剪枝与嵌入式端加速模型训练完只是第一步部署到嵌入式端之前通常还要做量化。量化分为训练后量化和量化感知训练两种。训练后量化简单直接转换就行但在精度敏感的类别上往往有损失量化感知训练在训练阶段就模拟量化误差精度保持更好但训练成本略高。我们的实测对比以s档为例如下方案相对精度推理时延备注浮点FP32基准较高保留完整精度半精度FP16基本无损明显降低多数端侧平台可支持训练后量化INT8略有下降最低部署最快需验收精度量化感知训练INT8接近基准最低推荐用于精度敏感场景如果n档的浮点模型已经满足现场要求就不必强行量化。量化省下来的算力虽然诱人但一旦精度掉到不可接受的范围排查起来比训练还麻烦。我们在实际项目里优先采用了量化感知训练的INT8方案换来的是巡检视频流的实时帧率而缺陷检出率基本保持住了。4.4 难例挖掘与迭代训练现场永远是模型的试金石。第一轮模型上线后我们把误检和漏检案例全部回收按bad case整理成新的训练集。比如把反光管壁误判为渗水的例子、把管片接缝误判为裂缝的例子全部标注后回流到训练集里重新训练。迭代两三轮之后误报率下降非常明显。这里有个经验难例挖掘不能只看置信度低的样本置信度很高的误检才是真正要命的问题。高置信度误检意味着模型学到了一个错误的强特征比如“管壁上有阴影”被当成“错台”如果不及时纠正系统会反复在同类位置误报。我们会定期抽看高置信度误检图分析出错原因后再决定是加数据还是调整后处理规则。5. 嵌入式端部署实战把模型真正跑在巡检设备上5.1 部署硬件怎么选部署硬件的选型我们依据的基准很简单当前要跑的模型档位、视频路数、目标帧率以及现场的供电和防护条件。n档对算力要求最低一颗低功耗处理器就能带起来s档适合中等算力的边缘板卡是目前巡检主力m档和l档需要更高算力通常用于重点区段复测或者离线批量处理。除了算力内存带宽和散热往往是被低估的因素。模型推理不仅看TOPS还要看数据搬运效率内存带宽不足会导致算力发挥不出来。隧道内粉尘大、湿度高嵌入式设备如果散热做不好连续跑几个小时就会降频。我们后来统一给设备加了主动散热方案做了防尘处理才把长期运行的稳定性提上来。5.2 模型转换与推理框架部署链路我们走的是常规路线训练框架导出ONNX再转换到目标设备对应的推理格式最后用推理框架加载运行。推理框架的选择主要看设备平台主流的有面向通用x86的OpenVINO、面向GPU的TensorRT、面向特定NPU的RKNN等。不同框架对算子的支持程度不同转换时可能遇到算子不支持的情况需要把模型里的某些结构改写成兼容形式。前处理在端上是个容易被轻视的环节。训练时我们用的resize方式、归一化参数部署时如果稍有不同检测精度会直接掉块。尤其是letterbox的填充方式必须和训练时保持一致。我们统一封装了一个前处理函数训练和部署共用同一套逻辑从源头避免这类问题。后处理也是一样NMS的置信度阈值、IOU阈值都做成可配置参数方便现场根据误报情况调整。5.3 性能优化与实时链路部署完之后最重要的就是性能调优。以我们的巡检车速和相机配置为例车速约0.5米/秒相机每秒采集3帧那么模型推理帧率只要稳定在3帧以上就能满足实时覆盖。但这个数字看着低实际调起来并不轻松因为设备还要同时做采集、码流处理、报警联动等其他任务。我们把整个链路做成了多线程流水线采集线程负责收图推理线程负责模型计算上报线程负责报警和状态记录。三个线程之间用队列解耦避免采集等推理、推理等上报这种互相阻塞的情况。实测中线程优先级也要注意推理线程不能因为其他线程的任务抢占而出现帧率抖动。推理前还做了一步很小但很有效的优化零拷贝。端侧推理框架加载视频帧时如果每次都做一次内存拷贝耗时相当可观。我们通过对底层缓冲区复用让采集线程直接把数据交给推理引擎省掉了中间的内存复制整体时延大约降低了三分之一。5.4 现场掉帧、断点续传与容错隧道巡检是移动作业现场难免出现设备电压波动、存储异常、程序崩溃等情况。我们做了两个层面的容错一是采集端在本地循环缓存最近的视频流推理程序重启后可以从缓存中恢复尚未处理的帧避免漏检二是所有检测结果和报警记录先写本地再异步上报到平台平台端支持断点续传网络恢复后自动补齐数据。程序稳定性上我们加了看门狗机制设备异常死机后自动重启拉起检测程序和上报服务。重启后自动回到断点位置继续巡检不需要现场人工介入。盾构隧道里的作业环境毕竟不比机房设备越“无人值守”越好。6. 从模型到预警系统盾构管壁缺陷检测预警整体链路设计6.1 系统整体数据流这套预警系统从架构上看分三个层次。前端是巡检车或轨道机器人搭载的相机和边缘计算设备负责图像采集和现场推理中间层是项目部的本地服务负责汇总各台设备的检测结果、报警记录和状态信息上层是管理平台面向施工方和监测方提供缺陷台账、统计分析和处置工单。现场端最核心的交互是报警。模型在视频流里检测到缺陷后设备立即声光报警同时截取当前帧和前后若干帧填写当前里程桩号和环号一并写入本地记录。后端平台收到报警记录后按断面生成管壁缺陷分布图工程人员可以直观看到哪些区段问题集中、哪些缺陷需要优先处理。数据流里有一个容易被忽视的设计检测结果要包含“多帧信息”而不只是单帧的一个框。我们保存的是缺陷目标在连续帧中的出现位置、置信度变化以及对应的时间戳这为后续的连续帧确认和重复报警抑制提供了原始依据。6.2 缺陷分级与预警策略预警策略做得好不好直接决定系统在工地上能不能被信任。如果天天误报现场人员很快就不当回事了如果经常漏报又失去了系统的意义。我们的做法是组合了三个机制第一分级预警。缺陷按类别和置信度划分为“提示”“重点关注”“紧急报警”三个级别。比如高置信度渗水或剥落属于紧急报警低置信度湿渍可能只是提示需要人工复核。这就避免了所有报警都一个待遇现场人员能分清主次。第二连续帧确认。模型单帧检测到目标不立即报警而是在连续若干帧中都检测到同一目标且位置稳定才触发报警。单帧检测受噪声影响较大连续帧确认能滤掉大量偶发的误检。代价是报警稍有延迟但在巡检车速下这个延迟完全可以接受。第三重复报警抑制。同一个缺陷在视频中会被很多帧拍到如果每帧都报后台会收到大量重复记录。我们为每个报警目标生成一个唯一的空间标识在设定的时间窗口内同一位置的重复检测只合并为一条记录保留最高置信度、首次出现帧号和末次出现帧号。置信度阈值我们做成可配置的并且分类别单独设置。比如渗水的阈值可以稍微低一些因为渗水形态多样、边缘模糊螺栓孔异常的阈值可以高一些因为这类目标特征相对明确宁可少报一点也要保证准头。6.3 数据回流与模型迭代闭环预警系统不是一个上线就完事的静态系统。我们每轮巡检数据定期回收由后台标注人员对新增的缺陷案例做标注补充进训练集。每个月做一次模型重训发布前在历史数据集上做回归测试重点看两个指标新增的缺陷召回有没有提升原有的误报有没有反弹。这套闭环跑起来后模型会慢慢适应现场的真实工况分布。第一个月可能误报很多三个月后就会明显收敛。如果只训一次就上线不管后续数据系统永远停留在初始状态和现场环境的匹配度会越来越差。7. 实战踩坑盾构隧道现场常见的漏检与误报问题7.1 反光和水汽干扰的矛与盾隧道里的水汽是我们遇到的第一个“硬茬”。管壁表面经常覆盖一层水膜灯光照上去产生大面积反光反光区域的亮度和形状与渗水区域非常相似模型很容易把反光误判成渗水。反过来水汽造成的模糊又会降低裂缝和剥落的检出率让真正的缺陷被漏掉。硬件层面我们试过偏振补光灯能在一定程度上滤掉镜面反光让管壁表面纹理更清晰。软件层面我们在训练集里专门加入了反光增强样本把正常管壁图像叠加上不同类型的反光斑块让模型学会区分“反光强度渐变”和“渗水边缘不规则”之间的差异。配合后处理时对大面积高亮区域的单独判断误报率降了不少。7.2 裂缝与管片接缝的类间混淆管片接缝本来就是天然的线条状结构在图像上呈现为规则的长直线或弧线。裂缝也呈线状两者纹理接近模型经常把接缝误报成裂缝。这个问题最让人头疼的地方在于接缝在整条隧道里到处都是只要误报率稍微高一点报警数量就会爆炸。我们的解决办法分两条线。一条是位置先验管片接缝在空间上有固定节律可以在系统里预先标定各环接缝的标准位置检测结果落入接缝附近区域时降低优先级或直接滤除。另一条是模型层面给训练数据标注“接缝”作为背景类别让模型在学习过程中看到足够多的接缝与裂缝对比样本逼迫它学到两者的细微差异。两条线配合裂缝误报基本控制到了可接受范围。7.3 小目标和运动模糊细小裂缝是漏检的重灾区。原因是多方面的裂缝宽度在图像里只占很少像素小目标特征不足巡检车移动带来的运动模糊进一步抹平了裂缝边缘再加上管壁纹理本身就有很多不规则痕迹模型很难在低分辨率的模糊信号中确定“这是裂缝”。在n档模型上这个问题尤其明显。后来我们做了三个调整。采集端提高帧率、缩短曝光时间减少单帧运动模糊算法端对疑似区域做局部裁剪放大再检测相当于在不提高全局分辨率的前提下提升小目标的可识别度决策端对重点区段主动切换m档模型。这样一套组合下来细小裂缝的召回率才勉强达到了现场能够接受的水平。7.4 样本不平衡与长尾问题样本不平衡在初期几乎让螺栓孔异常这个类别处于“半失明”状态。渗水样本可能有上千张螺栓异常只有几十张模型把所有精力都花在了学好渗水上螺栓孔异常类基本学不到有效特征。这不是调参能解决的问题是数据分布问题。我们做了三类处理一是专门组织采集小组针对螺栓部位批量采集异常样本二是对已有少数类样本做裁剪、旋转、尺度缩放等增强把几十张变出几百张三是在训练损失里给少数类加了更高的权重让模型“重视”这些稀缺类别。最后一轮评估时螺栓孔异常的召回率从不足三成提升到了八九成算是补上了最弱的短板。7.5 设备在工地环境的稳定性最后一批坑基本都来自现场环境。设备在隧道里长时间运行粉尘吸附在散热片上导致温度升高主控降频后推理帧率大幅波动湿度大导致电路板凝露偶尔出现静电复位供电不稳定时设备重启后如果没有自动恢复机制整条巡检链路就断了。我们把这些都当成“必修课”处理设备选型时优先看防护等级和宽温设计机箱加防尘滤网并定期清理软件层面做掉电自启和看门狗关键数据实时落盘。做完这些之后设备才能算真正达到了“现场可用”的标准而不是只能在实验室里跑。8. 最后再分享几点体会项目做到后面我越来越觉得模型本身不是最难的难的是让一个实验室里跑得很好的检测系统在潮湿昏暗的隧道里连续稳定地工作。数据闭环、部署稳定性、预警策略任何一环出了问题系统在工地上都会被迅速否定。如果让我给后来者一个建议那就是从第一天起就把部署约束想清楚不要先训练一个大模型再想办法往端上塞。选LeYOLO这类原生轻量化模型一开始就按n/s/m/l档位规划任务后面会省掉大量返工。再分享一个小经验上线初期别贪多。先集中精力把渗水这一类缺陷做到稳定让现场人员信任系统再逐步扩展到裂缝、错台、剥落等更多类别。一步到位往往意味着处处不稳而信任一旦丢失再好的技术也很难让人重新接受。这套系统的价值不在于模型跑得多快而在于它真的能帮现场工人少走几公里路、少仰几次头把隐患早一点找出来。