隧道贯通后最让人头疼的不是盾构机本身，而是那几公里灰扑扑的管壁。渗水、裂缝、错台、剥落，过去全靠巡检人员踩着高空作业车、打着强光灯，仰着脖子一米一米地看。这次做的项目，就是把这套人工巡检换成AI：基于LeYOLO全系列n/s/m/l参数模型，在嵌入式端构建盾构管壁缺陷病害的实时检测预警系统。简单说，巡检台车装上相机和边缘计算设备，模型在现场实时识别管壁异常，发现问题当场报警。

这套系统一开始就不是奔着“论文指标”去的，目标很实际：让一线巡检工不用那么辛苦，让缺陷台账从“凭经验写”变成“由模型标”，让渗漏、裂缝这类风险能被及时发现、及时处置。对做施工监测、隧道运维、边缘AI部署的同行来说，这篇文章里的数据闭环、模型选型思路和现场踩坑记录，应该都能直接参考。

1. 盾构隧道管壁巡检的痛点：为什么这项基建安全工作必须交给AI

1.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四档给出的一套完整模型族，而不是单一模型。四个档位覆盖了从“极低算力设备实时检测”到“高精度离线复核”的不同需求，我们可以用同一套数据训练出不同规格的模型，按场景切换：

实际工程中，我们并不是只用一个档位。巡检车日常跑的时候用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档为例）如下：

如果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档位规划任务，后面会省掉大量返工。

再分享一个小经验：上线初期别贪多。先集中精力把渗水这一类缺陷做到稳定，让现场人员信任系统，再逐步扩展到裂缝、错台、剥落等更多类别。一步到位往往意味着处处不稳，而信任一旦丢失，再好的技术也很难让人重新接受。这套系统的价值不在于模型跑得多快，而在于它真的能帮现场工人少走几公里路、少仰几次头，把隐患早一点找出来。