隧道衬砌检测这一行提到探地雷达没人陌生但真正能把B-scan雷达图像里的缺陷一次判对的人每个施工项目部也就那么一两个。我在某个新建高速公路隧道项目上负责衬砌质量检测时最头疼的不是采集数据而是海量雷达图像的人工判读空洞、不密实、裂缝、渗水这些缺陷藏在错综复杂的反射波里看久了眼睛发花不同判读员给出的结果还对不上。后来我把深度学习目标检测模型引入这条链路用YOLOv8在探地雷达图像上做缺陷智能识别从标注规范、训练调参到现场推理部署完整跑了一遍这套方案最终把单个标段的图像初筛时间从两周压到三天空洞类缺陷的召回率稳定在0.88左右。把整个过程写下来给打算做工程无损检测加AI落地的同行做个参照。1. 先把判读痛点摆清楚探地雷达在隧道衬砌检测里到底难在哪1.1 探地雷达图像是怎么画出缺陷的探地雷达的原理说穿了不复杂发射天线向衬砌内部打高频电磁脉冲电磁波在遇到介电常数差异明显的界面时会发生反射接收天线把反射波的双程走时和振幅记录下来。混凝土的相对介电常数一般在6到9之间空气接近1水大约在80左右介电常数差异越大界面反射越强。这也是为什么二衬背后如果存在空洞雷达图上会出现非常醒目的强反射信号。B-scan图像是沿测线连续采集后拼出来的剖面图横轴是测线里程纵轴是双程走时通常再按估算的介电常数换算成深度。所以一张图里藏着两层信息横向看的是缺陷的延续长度纵向看的是缺陷埋深和形态。空洞、蜂窝、裂缝、含水区域在图像上各有各的长相有经验的判读员就是在这些波形和同相轴的排列组合里找异常。1.2 人工判读的三座大山效率、主观性和经验断层先说效率。隧道二衬检测的测线动不动就是几公里每延米积累下来的雷达剖面图按波形数据压缩后也有上千幅图要过。判读员要逐屏拖动、放大、截图、标注一天高强度工作下来能处理的量非常有限。我在项目上统计过一个熟练判读员一天认真看下来大概只能处理两到三个台班的数据遇到可疑区还要反复比对相邻测线速度更是直线下降。再说主观性。同样的一个反射异常A判读员觉得是空洞B判读员觉得只是钢筋网引起的干扰。判读标准里虽然有异常振幅多次波同相轴错断这些描述但落到具体的波形上阈值全靠个人感觉。我们曾经拿同一组雷达图让三位判读员独立标注相互之间的一致率只有七成出头。这个数字在小范围数据上可能还能接受放大到一条几公里长的隧道漏判和误判的风险就完全不可控了。第三座大山是经验断层。能独立看雷达图的判读员基本都是靠在现场一次次钻孔验证、一次次对比地质情况慢慢磨出来的。一个新人从入行到能独立出报告周期往往按年算。而这批老手数量有限项目一多根本排不过来。说到底人工判读本质上是一种经验驱动的小规模生产它和工程检测本身需要的标准化、规模化之间天然存在矛盾。1.3 把问题翻译成深度学习目标检测任务我当时的判断是与其想办法给判读规则写死一堆if-else不如把问题直接翻译成计算机视觉里的目标检测任务。探地雷达B-scan图就是一帧二维图像缺陷在图上占据的区域就是一个带类别标签的检测框只是图像源比较特殊而已。只要数据量足够、标注规范统一深度学习模型完全可以从大量人工判读结果里学到那些说不清但判得对的特征。这个判断后来被验证是对的但过程中也踩了不少坑。最大的一个误区是我一开始直接把整幅上万像素宽的雷达图缩放后丢给YOLO训练结果小目标全被压没了mAP惨不忍睹。后面改成沿测线方向滑窗把图像先切成几段再分别训练和推理效果才明显起来。这个细节后面会详细说但它是整套方案能不能成立的第一个关键点。2. 数据是第一道关卡四类缺陷在雷达图像上的物理形态与标注思路2.1 先认清目标四类典型衬砌缺陷的图像特征隧道衬砌质量缺陷种类不少但雷达检测能稳定识别、施工现场最关心的大致可以归成四类空洞、不密实、裂缝、水囊或渗水带。这四类在B-scan图上的特征差异其实挺明显关键是判读员要能区分缺陷信号和正常结构信号。缺陷类型典型雷达图像特征常见成因检测难度空洞强反射、同相轴错断、振铃式多次反射二衬与初支脱空、防水板后方空腔中容易被钢筋双曲线干扰不密实反射波杂乱、振幅偏低、同相轴不连续混凝土振捣不充分、骨料离析高边界模糊裂缝倾斜相位带、同相轴明显错位温度收缩、围岩变形高尺度小水囊/渗水带低频强反射、界面下方振幅快速衰减排水不畅、围岩渗水中空洞为什么容易出现多次反射因为空气层的上下两个界面都是强反射面电磁波在中间来回弹跳图像上就会形成一条又一条平行且等间距的振铃状波形。这个特征几乎是空洞的身份证模型如果学会了看多次波会比单纯看强振幅可靠得多。真正考验模型的是钢筋和钢架的干扰。二衬里的钢筋网在雷达图上会产生非常密集的绕射双曲线形态上跟点状空洞异常有相似之处人工判读都要反复推敲模型初期的误报绝大多数都集中在这里。所以数据准备阶段钢筋干扰样本绝对不能少否则模型学到的空洞特征其实是强反射特征。2.2 标注方案别一上来就做像素级分割第一次设计标注方案时我差点选了语义分割觉得把缺陷轮廓精确抠出来更高端。但冷静下来算了一笔账项目上可用的标注人力本来就紧一张640x640的雷达图画一个矩形框十几秒就完成画分割掩码要两三分钟起步。五百张图分割标注做完项目工期都过了一半。而且工程质检真正需要的信息是哪里有缺陷、属于哪一类、大概多大范围矩形框已经能给到这些。所以我最终选了目标检测框并在标注规范里加了三条硬性要求。第一框要尽量贴合异常区域边缘但不强求精确到同相轴的边界像不密实这种弥散性目标宁可框大一点也别框一半。第二一条连续的空洞带如果中间没有明显隔断就合并成一个大框不要拆成好几个小框否则模型训练时会困惑到底是多个目标还是一个目标。第三标注完成后至少两个人交叉复核用检测框的重叠率来筛掉明显不合格的标注。标注工具用的是常见的开源标注软件导出为LabelMe格式再写脚本转成YOLO的txt格式。类别名我建议按物理成因来定义不要用异常1异常2这种占位符。我们最终定的四类是void、honeycomb、crack、water训练时中文名和英文名做个映射文件放在数据集目录里后面做报告输出时直接用映射关系转换成现场能看懂的名字。2.3 数据增强与样本平衡的实操策略数据增强方面有一条红线必须记住B-scan图可以做水平翻转但绝对不能做垂直翻转。水平翻转相当于把测线方向反过来走物理上完全成立雷达图语义不变垂直翻转等于把深度方向颠倒表面的直达波和衬砌界面反射会跑到图底部这种样本在真实采集里永远不会出现喂给模型只会教出错误的位置先验。我们实际用的增强组合包括随机亮度对比度扰动、高斯噪声、按比例裁剪、Mosaic拼接、还有模拟不同采集设备增益差异的灰度拉伸。雷达图像受设备参数、天线频率、增益设置影响很大增强TGC时间增益补偿之后再做灰度拉伸能明显提升模型对不同采集条件的适应能力。样本量方面我给出一个比较保守的经验值四类缺陷加起来的有效标注图像达到1500到2000张之前模型性能会随数据量快速上升超过这个量之后增速放缓但泛化能力还会持续变好。我们最初只有800张可用标注mAP只能到0.67左右补到1800张以后同一套验证集上mAP接近0.82。另外类别不平衡是必然的空洞和不密实的样本多裂缝和渗水样本少处理方式是给损失函数按类别设置权重同时用Cutout和复制粘贴增强给少数类多造样本千万不要简单粗暴地删掉多数类样本。3. 模型选型与训练设计为什么YOLO系在B-scan图像上够用且好用3.1 为什么不是Faster R-CNN也不是U-Net模型选型时我对比过三条路线两阶段检测器、单阶段检测器、语义分割模型。Faster R-CNN的精度上限确实高但推理速度慢现场工控机上跑不快而且雷达图滑窗检测的场景下一张长剖面要切成几十个窗口速度劣势会被放大很多。U-Net这类分割模型对小目标和大尺度结构都友好但结合前面的标注成本问题工程性价比太低。YOLO系模型尤其是v8之后的版本属于anchor-free设计检测头解耦多尺度特征层对B-scan图里那种又小又分散的缺陷目标处理得很不错。更实际的好处是生态成熟开箱即用的训练接口、预训练权重、导出ONNX的链路都现成省去大量工程时间。如果后面想换成YOLO11或者RT-DETR接口基本一致我已经把这条链路设计成了可替换结构。这里有个容易忽略的点预训练权重必须保留。B-scan图虽然和自然图像完全不同但COCO上预训练出来的骨干网络学到的低级特征比如边缘、纹理、局部对比度在雷达图上依然有效。直接从头训练不仅收敛慢最终精度也要低一截。我试过同样的数据和超参用不用预训练权重最终mAP能差七八个点。3.2 训练配置里容易被忽略的关键细节输入图像格式要单独处理。探地雷达的B-scan本质是单通道灰度图但YOLO的预训练权重是按三通道分布初始化的。正确做法是直接把灰度图复制成三通道不要自己写一个单通道版本去替换网络输入层那样等于丢掉了迁移学习的意义。更关键的输入尺寸策略针对的是雷达图超宽的问题。原始B-scan图动辄几千甚至上万像素宽如果整体resize到640x640小尺寸的空洞和裂缝会在缩放过程中直接消失。我的处理方式是沿测线方向滑窗切块每个窗口尺寸选640x640相邻窗口重叠50%这样既保证了小目标不被压没又让同一个缺陷在相邻窗口里重复出现为后面的多窗口投票合并留了余地。训练超参我直接给出项目上验证过的组合供参考参数取值说明模型规格YOLOv8s速度和精度的平衡点现场可用输入尺寸640与滑窗窗口一致批大小16显存够就往上加不影响收敛优化器AdamW收敛稳定配合余弦退火效果好初始学习率0.001迁移学习场景下不宜太大轮数200配合早停实际140轮左右收敛冻结骨干前10轮保护预训练特征防止数据不足时被打乱冻结骨干这个操作很多人不重视。数据量只有一两千张时一上来就让全局参数剧烈更新预训练特征很容易被雷达图的独特分布冲坏结果就是训练集上表现好、验证集上崩得厉害。我习惯先用冻结backbone的策略训10到20轮让检测头先适应新数据再解冻全部参数做全量微调稳定性明显提升。3.3 评价指标怎么定才不会骗自己做工程安全相关的检测评价指标和发论文的指标完全是两回事。mAP要参考但真正拍板的是每类缺陷的召回率和误报率。漏掉一个空洞在隧道运营期可能就意味着渗水、掉块甚至结构隐患而多给几个疑似框现场还有人工复核环节可以筛掉代价小得多。我们的评估流程是在验证集上画出每个类别的P-R曲线然后选择一个偏保守的置信度阈值。实际使用中阈值设在0.35到0.4之间宁可把不确定的区域都标成疑似也绝不让真缺陷被阈值过滤掉。另外我还会统计一个每千张图误报框数的指标这个数如果超过15个说明模型在学习噪声而不是缺陷需要回去补数据而不是调阈值。多窗口合并的细节也在这里发挥作用同一个缺陷被相邻滑窗重复检测到两次以上才最终输出。这个至少出现2次的投票机制能把随机误检削掉一大半代价只是遗漏一些恰好落在窗口边缘的缺陷。配合重叠率50%的滑窗设计这种遗漏概率很低可以接受。4. 代码链路实战从标注数据到训练、滑窗推理与导出部署4.1 数据格式转换把标注成果变成模型能吃的格式原始标注我统一用LabelMe的JSON格式保存训练前需要转成YOLO的txt格式。转换脚本不复杂但要注意坐标必须做归一化类别id和类别名的映射要固定好这两个地方出错会在训练阶段产生让人抓狂的报错。import json from pathlib import Path def labelme2yolo(json_path: str, out_txt: str, classes: list, img_w: int, img_h: int): with open(json_path, encodingutf-8) as f: data json.load(f) lines [] for shape in data[shapes]: label shape[label] if label not in classes: continue xs [p[0] for p in shape[points]] ys [p[1] for p in shape[points]] xmin, xmax min(xs), max(xs) ymin, ymax min(ys), max(ys) cx (xmin xmax) / 2 / img_w cy (ymin ymax) / 2 / img_h bw (xmax - xmin) / img_w bh (ymax - ymin) / img_h lines.append(f{classes.index(label)} {cx:.6f} {cy:.6f} {bw:.6f} {bh:.6f}) Path(out_txt).write_text(\n.join(lines), encodingutf-8)数据集目录建议按YOLO标准的images和labels分文件夹存放训练集和验证集按8比2比例划分划分前最好先按类别数量做分层抽样保证验证集里每个类别都足够。雷达图本身分辨率高文件不大不需要做存储压缩直接原图保存。4.2 训练配置与启动一个配置文件加一段代码数据集配置用YAML描述注意path路径要写相对路径避免换机器后路径失效。path: ./tunnel_gpr_dataset train: images/train val: images/val nc: 4 names: 0: void 1: honeycomb 2: crack 3: water训练脚本用官方训练接口封装好的API参数我在前一节已经列过代码层面就是把这些参数填进去。from ultralytics import YOLO model YOLO(yolov8s.pt) # 加载COCO预训练权重 model.train( datatunnel_gpr.yaml, epochs200, imgsz640, batch16, optimizerAdamW, lr01e-3, cos_lrTrue, freeze10, patience30, seed42, device0, )训练过程中重点看两个日志验证集上的类别人均值mAP50以及每类的召回率。如果某个类别的召回率明显低于其他类说明样本不够平衡需要回去增强那个类别的数据而不是盲目加训练轮数。训练结束后取验证集上F1最高那个checkpoint作为最终权重不要习惯性地用最后一个epoch的权重。4.3 滑窗推理与多窗口结果合并推理阶段把训练好的权重加载进来对完整雷达剖面做滑窗预测再把所有窗口的检测框汇总后做一次全局NMS。注意OpenCV的NMS接口需要的是左上角加宽高的格式我第一次用的时候直接传了xyxy格式结果输出的框位置全错了排查了很久才发现是格式问题。import cv2 from ultralytics import YOLO model YOLO(best.pt) def slide_predict(model, img, window640, stride480, conf0.35, iou0.5): h, w img.shape[:2] boxes, scores, labels [], [], [] for y0 in range(0, h, stride): for x0 in range(0, w, stride): patch img[y0:y0 window, x0:x0 window] result model.predict(patch, confconf, iouiou, verboseFalse)[0] for box in result.boxes: x1, y1, x2, y2 box.xyxy[0].tolist() boxes.append([x0 x1, y0 y1, x0 x2, y0 y2]) scores.append(float(box.conf[0])) labels.append(int(box.cls[0])) boxes_tlwh [[b[0], b[1], b[2] - b[0], b[3] - b[1]] for b in boxes] keep cv2.dnn.NMSBoxes(boxes_tlwh, scores, score_thresholdconf, nms_thresholdiou) keep keep.flatten() return [(boxes[i], scores[i], labels[i]) for i in keep]如果你想用至少出现2次的投票机制就在全局NMS之前加一步统计把滑窗得到的框映射到原图坐标后按类别和重合率聚类某类簇内框数少于2的直接丢弃。这一步对误报率高的场景特别管用我们实际部署时就是靠这个机制把每公里误报数从40多压到10个以内。4.4 导出ONNX与现场部署模型在服务器上训练好后现场工控机不一定装得了PyTorch全家桶所以导出成ONNX是更稳的部署方式。model.export(formatonnx, imgsz640, opset12)导出后用ONNX Runtime加载import onnxruntime as ort sess ort.InferenceSession( best.onnx, providers[CUDAExecutionProvider, CPUExecutionProvider], )这样现场设备只需要装一个轻量推理运行时不需要搭深度学习训练环境依赖少出问题也好排查。推理速度方面一张640x640的窗口图在普通工控机配一张入门级显卡上大约30到50毫秒一条三公里长的测线滑窗全跑完加NMS合并十分钟内肯定结束比人工快了一个数量级。5. 现场实测与泛化之坑指标达标不等于现场能用5.1 实验室数据与现场数据的第一道落差模型在自己验证集上跑到0.8以上的mAP我当时以为就稳了直到拿着权重去处理另一个项目新采集的雷达数据结果被现实狠狠上了一课。现场数据的工况远比训练集复杂衬砌表面有挂布残留、混凝土龄期和强度不同、采集设备增益参数不一样、测线经过施工缝时信号突变。这些差异在人工判读时都能被有意识地忽略但模型没见过这些模式就会把它们当成新目标甚至异常目标。解决办法有两个方向。第一是数据层面在训练集里主动加入不同工地、不同设备、不同增益设置的多源数据哪怕每类样本数量少一点对泛化能力的提升也远大于重复看同一个工地的海量数据。第二是预处理层面推理前对雷达图做归一化重点做时间增益补偿和道间能量均衡让不同设备采集的图像在灰度分布上尽量接近。5.2 误检漏检的主要来源与对策把现场踩坑中遇到的高频问题整理成一张对照表比长篇大论更实用问题现象典型场景我的对策钢筋/钢架双曲线被误判为空洞二衬钢筋网密集区大幅增加钢筋干扰样本后处理中如果某空洞框与密集双曲线簇完全重合则降低优先级微小空洞漏检缺陷尺寸小于10x10像素减小滑窗stride对高置信度区域做二次放大检测不密实与表面不平整噪声混淆衬砌表面粗糙、有附属物增加负样本用同相轴连续性作为辅助过滤规则水囊与空洞混淆围岩含水率变化大补充不同含水率样本结合相位信息作辅助判断这里重点说说钢筋干扰。二衬钢筋网在雷达图上的绕射双曲线形态上和点状空洞异常太像了模型初期几乎每三四个误报就有一个来自钢筋。后来我单独标注了一批钢筋干扰图像不是作为缺陷类别而是作为负样本参与训练同时在后处理里加了一条规则如果模型输出的空洞框区域内有明显的等间距双曲线簇就把这个框的置信度乘一个0.5的衰减系数。条条大路通罗马这类启发式规则虽然不优雅但在工程现场确实管用。5.3 跨隧道跨标段的泛化能力到底能到多少我在不同项目的实测中积累了一组数据用A隧道的数据训练直接拿到B隧道数据上测试各类别召回率平均下降10到15个百分点个别难检类的下降更多在B隧道标注三五十张图做小样本微调之后召回率能恢复到接近A隧道水平的九成。这个规律意味着试图训练一个包打天下的通用权重是不现实的每个新项目都应该采集少量现场数据做一轮快速微调。微调的具体做法很简单用已有的best.pt作为初始权重把新项目的几十张文图混入原训练集按第3节同样的超参只训20到30轮learning rate降到原来的十分之一。整个流程半天就能跑完效果立竿见影。如果你连一张新项目的标注都没有那至少要把新采集的雷达图按0.35的阈值过一遍模型让现场判读员把模型的输出当成辅助线索一边复核一边顺手标注数据滚起来之后再去微调。5.4 现场使用不能是AI替代人而是AI先初筛、人再复核和现场检测单位磨合之后最终落地的流程是数据采集车在现场完成雷达扫描后算法自动完成滑窗推理输出带坐标、类别、置信度的疑似缺陷清单判读员在软件界面上逐条查看模型框出的区域决定保留还是删除保留的疑似缺陷再进入钻孔验证闭环用实际取芯结果反哺标注库。模型的角色是帮判读员把几千幅图缩成几十个待重点关注的窗口把人的精力花在最值得看的地方。这套流程里有个容易被忽略但非常重要的设计人工复核时的一键标注。判读员确认一个缺陷的同时就会产生一条新标注这条标注自动进入训练集增量池每周或每两周重训一次模型。这样模型会越来越贴近现场的实际情况比一次性训练完放在那里不动要实用得多。6. 这套工作流真正跑起来之前建议先补上三块拼图6.1 标注规范文档让不同人画出来的框一致我见过太多项目死在标注质量上其中最典型的就是不同标注员对不密实的边界理解不一致导致模型被矛盾的标签反复拉扯。所以在正式标注开始前花半天时间写一份标注规范文档配典型图像示例明确规定每个类别的判定依据、框的包裹范围、边界模糊时怎么取舍。文档写完之后让每个标注员先标10张固定图像逐一讨论他们的框和参考答案的差异一致率提到90%以上再开工。这部分前期成本不高但能省掉训练阶段大量的返工时间。6.2 现场数据回流机制模型越用越准的前提深度学习模型的性能上限由数据质量决定这条规律在隧道衬砌检测里体现得特别明显。只靠项目启动时人工集中标注的那一两千张图模型能做到可用但做不好越用越好用。真正让它越用越准的办法是把现场检测、钻孔验证、人工复核的闭环数据持续回流到训练集里。每次现场验证确认了模型漏掉的缺陷它就是一条宝贵的难例样本每次人工复核删掉的误检框它也是一条同样宝贵的负样本。以周为周期增量重训模型的现场表现会持续向上走。6.3 与检测报告流程的整合算法再准如果不能直接对接现有的报告流程现场就不会有人愿意用。我们最后做了一个很朴素的小功能把模型输出的检测框按测线里程和深度算成实际坐标自动生成带截图、缺陷类别、疑似等级的检测记录表格直接喂给报告软件。判读员只需要在生成初稿的基础上做确认和微调而不是从头打字做报告。这一步看起来不起眼但正是它让整套系统真正留在了生产流程里。如果让我重新来一遍这个项目我会在第一天就同时启动现场数据收集和标注规范制定而不是先把模型跑起来再回头补数据。数据、标注、算法这三件事在隧道衬砌智能检测这个场景里永远是数据最贵、标注最重、算法最省心。谁先把数据闭环理顺谁就能在工程落地这条路上走得更快。
