恒美微站
首页
关于我们
建站服务
主题模板
案例展示
资讯中心
联系我们
墙面瓷砖缺陷检测实战:从数据集构建到YOLO模型部署全流程
首页
资讯中心
/
墙面瓷砖缺陷检测实战:从数据集构建到YOLO模型部署全流程
墙面瓷砖缺陷检测实战:从数据集构建到YOLO模型部署全流程
发布时间:2026/10/21 5:38:12
前阵子接了一个工地验收相关的项目甲方要我们对新交付的楼盘做墙面瓷砖质量抽检。传统做法是让验收人员拿小锤敲、拿肉眼盯两个人一组满墙扫过去一栋楼下来腰酸背痛不说漏检还要靠后期业主投诉来找补。所以项目立项的时候就直接定了方向把“智慧识别”落到墙面瓷砖检测上做一套基于图像的缺陷识别系统核心产物就是一个持续迭代的墙面瓷砖检测数据集以及跑在这个数据集上的检测模型。标题里的“第10433期”很多人可能不理解其实这是数据集在持续更新过程中的版本编号。做算法的人一看就明白数据从来不是一次性采集完就封盘的而是随着现场反馈不断补数据、修标注、加难例每一期都在为模型“上新”。这篇文章我打算把整个项目的实践链路完整梳理一遍数据怎么采、标签怎么打、模型怎么选、训练参数怎么调、现场部署要注意什么以及这中间踩过的坑。不管你是要做建筑质量验收、装修质量评估还是做墙面维护监测这套思路都能直接参考。1. 项目到底在解决什么问题1.1 一个听起来简单、做起来不简单的需求瓷砖缺陷检测表面上看就是“识别裂缝”和“识别脱落”两件事但要落地成真正能用的系统难点全在细节上。先说裂缝瓷砖上的裂缝很多时候比头发丝还细在照片里只有不到十个像素宽环境光一变就看不出来而墙砖之间的勾缝线、釉面裂纹、运输过程产生的划痕又都长得和裂缝很像。再说脱落脱落区域边缘是不规则的表面还有反光和阴影水渍、霉斑、水泥残留都能造成误判。如果系统只是“能识别”那精度和稳定性根本扛不住实际验收场景。所以这个项目本质上不是做一个Demo模型而是做一套“能进工地”的检测工具。它要能回答三个问题墙面上有没有缺陷、缺陷具体在哪个位置、这个缺陷到底属于裂缝还是脱落还是更严重的破损。只要这三个问题回答清楚建筑质量验收、装修质量评估、墙面维护监测就都能基于同一套底层能力去展开。1.2 三类典型应用场景一类是新建建筑的交付验收。这时候瓷砖是刚贴完的表面干净缺陷主要是施工过程中造成的瓷砖崩边、裂缝以及水泥未干导致的空鼓引发的表面轻微移位。检测系统能把这些区域标记出来形成验收报告让施工方在交付前就整改完成。另一类是装修质量评估。客户请第三方监理看装修工地或者装修公司和业主之间对施工质量有争议时都需要有客观的、可量化的检测依据。人工拍照留证常常位置对不准、尺度说不清而检测系统输出的坐标和缺陷尺寸可以当作客观证据。有些装修公司还在用这套系统做自己的施工自检瓦工铺完砖拍一圈当场就知道哪些地方要返工效率提升非常明显。还有一类是既有建筑的维护监测。地铁站、医院、商场、办公楼这些公共场所的墙面瓷砖长期使用后会出现空鼓、脱落风险人工巡检周期长、覆盖不全而且高处的墙面根本看不到。用设备周期性采集墙面图像再跑检测系统就可以把巡检从“随缘”变成“全覆盖”。1.3 检测目标要定义清楚项目最初只设了两个类别裂缝和脱落。但实际标注第一批图像时我们就发现脱落和“崩边”“破损”在视觉上边界很模糊。比如一块瓷砖角上崩掉一小块算不算脱落严格来说算瓷砖破损但和整片墙砖掉落的风险等级不一样。后来我们把类别调整为三类裂缝crack、脱落detachment、破损breakage。其中破损指局部崩边、磕碰、边缘碎裂脱落则特指瓷砖表面成片起翘或整体与基层分离后产生的明显位移区域。这个调整很重要。类别定义不清模型学到的特征就是一团浆糊标注师傅也会越标越混乱。做任何视觉检测项目第一件事不是选模型而是把“到底检测什么”和“边界条件是什么”用书面规则固定下来。2. 数据集是怎么建起来的2.1 数据采集的三要素设备、角度、场景这套数据集能支撑检测系统关键不在数量而在覆盖度。采集设备我们用过三类手机、微单、工业相机。手机方便但不同型号的拍照算法差异很大画质也不稳定微单画质好适合做精细标注的高清样本工业相机是到了后期做产线级采集才用的因为要固定距离、固定曝光数据一致性最好。实际项目里不可能只用一台设备所以数据集里必须包含多种设备的图像否则模型换一个摄像头就崩。角度和距离也需要刻意覆盖。距离墙面0.5米拍出来的裂缝特写和站在1.5米外拍的整体墙面缺陷的尺度完全不一样。我们规定现场采集至少包含三个距离段近距离观测0.3~0.6米、中距离普查0.8~1.2米、远距离概览1.5米以上。同时要求有正对墙面的视角也要有侧面约30度到45度的斜视角。原因是实际巡检时手举设备很难一直保持完全垂直一定角度的图像如果模型没见过到了现场就会漏检。光照条件更是重中之重。自然光、室内灯光、逆光、顺光、阴影下的瓷砖表面差异极大。釉面砖反光强烈缺陷区域在反光下有时会完全“隐身”。数据采集时我们专门安排过一批“不完美”样本背光拍摄、局部阴影、窗户反光、卫生间潮湿有水渍的状态。这些样本在标注时非常痛苦但对模型泛化能力的提升非常关键。2.2 标注规范不只是画框标注是决定模型上限的环节也是最容易出问题的地方。缺陷在图像里不是规则的矩形尤其是裂缝这种细长条目标如果直接用水平包围框标注框里会塞进大量背景信息模型学到的特征会被稀释。我们在标注时对裂缝采用多点折线加外接框的方式先描出裂缝的实际走向再生成能框住整个裂缝的包围框。对于脱落和破损则直接用多边形描出边缘轮廓。这样后期如果想做裂缝长度估算或者脱落面积测量多边形标注就能直接派上用场。标注规则里还要处理大量模糊案例。比如裂缝和勾缝线的区分我们的规则是如果裂纹沿勾缝线延伸且颜色接近优先判定为勾缝线而不是裂缝如果裂纹横穿瓷砖表面或勾缝线附近有分叉、碎裂才标注为裂缝。脱落和污渍的区分规则是必须有明显的颜色跃变和边缘阴影特征只靠颜色差异不标。数据质量上我们做了双重标注加仲裁机制每张图至少由两名标注员独立标注不一致的样本由项目技术负责人审核仲裁。刚开始时有接近7%的样本需要仲裁训练集跑过两版之后仲裁比例降到了2%左右。这个投入非常值得因为标注错误会直接被模型放大越到后期越难以清理。2.3 版本化迭代和“第10433期”的含义很多团队做数据集就是一锤子买卖采完标完训完就结束了。但真正长期维护的检测系统数据集是活的。每一期迭代会干三件事补充真实工地反馈回来的新样本、修正上一版标注里的错误、清理重复或低质量的图像。标题里的“第10433期”就是这么来的它代表这个数据集在持续演进过程中的一个版本号。别小看这个编号习惯它实际上是在为模型溯源做支撑。哪个版本出的模型在某个工地上表现异常可以通过数据集版本回查看看那一期到底改了什么、加了什么。我们的做法是每一个正式版本都打标签记录新增样本数量、标注改动统计、验证集指标变化。没有这套版本管理模型出问题的时候你连“模型是拿什么数据训出来的”都说不清。3. 技术路线怎么选3.1 检测、分割还是分类面对瓷砖缺陷有三种技术路线图像分类、目标检测、实例分割。图像分类只能告诉你“这张图有没有问题”不能告诉你在哪里对验收来说几乎没用直接排除。目标检测输出包围框能定位、能计数、能框出大致区域速度和硬件要求都比较友好是当前最实用的选择。实例分割输出每个缺陷的像素级轮廓定位最精确还能额外计算裂缝长度、脱落面积、破损范围对质量评估来说价值更高但标注成本和模型推理成本都更大。我的建议是如果第一阶段目标是快速落地验收和巡检直接上目标检测如果后续要做缺陷尺寸量化评估再在检测的基础上引入分割模型做二次精查。我们实际项目里就是这么做的检测模型跑第一遍筛出所有可疑区域分割模型只对检测框内部做细化把计算量用在需要的地方。3.2 模型选型对比目标检测模型家族里我们认真对比了一阶段检测器、两阶段检测器和带注意力机制的检测器核心考察指标是精度、速度、部署难度三件事。模型方向代表思路精度推理速度部署难度适用场景一阶段检测YOLO系列中上小目标一般快手机和边缘设备都能跑低生态成熟现场实时巡检、移动端两阶段检测Faster R-CNN思路高小目标更稳慢需要GPU中离线高精度抽检实时端到端RT-DETR思路高依赖训练数据中快资源占用高中服务器端批量分析实例分割Mask R-CNN思路高轮廓精确慢中高缺陷尺寸量化评估最终我们主力选了YOLO系列作为实时检测主线不是因为它最强而是因为它在一个640x640的输入尺寸下能给到很平衡的精度和速度。对于瓷砖裂缝这种小目标YOLO虽然不如两阶段模型在小目标指标上漂亮但通过提高输入分辨率、调整锚框、增加小目标样本权重实测精度差距能缩小到两个点以内而推理速度快了四五倍现场巡检的体验完全不同。3.3 数据增强怎么加才不帮倒忙数据增强是提高模型泛化能力的好办法但用不对会帮倒忙。我们踩过的教训是对裂缝目标强烈的几何畸变增强会坏事。马赛克增强里会把瓷砖纹理拉伸变形容易让模型学到不真实的形状偏差90度旋转、大角度旋转可以适量做但过度旋转会让细长裂缝的走向变得没有物理意义。光照增强、对比度增强、噪声模糊增强这几类对瓷砖缺陷非常有效因为现场的光照变化是最大的干扰因素。另一个实用技巧是做针对性增强在训练时把脱落类样本叠加常见的阴影和反光把裂缝类样本叠加勾缝线上的纹理干扰。这种“围绕难例做增强”的思路比盲目的随机增强更划算。我们还在标注数据里专门加入了一批“负难例”——就是长得像裂缝或脱落但实际正常的瓷砖图像比如水渍、胶带痕迹、水泥印子。负难例不会增加正类样本数量但能大幅压低误检率这个比例我们控制在正样本数量的10%到15%左右。4. 实操过程从数据到可用的检测系统4.1 数据准备和目录组织数据整理阶段一定要把训练集、验证集、测试集彻底分开而且划分的粒度要按“采集批次”而不是按“图片”来分。否则同一面墙的连续照片会同时出现在训练集和验证集里指标虚高得离谱。我们的做法是先把所有采集批次分成互不重叠的三组再在组内随机抽图保证验证集和测试集里的场景在训练集里完全没见过。目录结构可以参考下面这种组织方式tile_defect_dataset/ ├── images/ │ ├── train/ │ ├── val/ │ └── test/ ├── labels/ │ ├── train/ │ ├── val/ │ └── test/ ├── annotations/ │ ├── train_polygon.json │ └── val_polygon.json ├── configs/ │ └── data_config.yaml └── versions/ └── v10433_changelog.mdlabels目录下每张图对应一个txt文件记录类别、归一化坐标和包围框信息annotations里保存完整的多边形标注数据用于后续做分割或尺寸计算。版本目录里记录每一期数据集的改动说明这一步看起来是文档工作实际项目推进时会救你很多次。4.2 训练参数配置参考训练基于预训练权重做迁移学习。我们使用在大型通用视觉数据集上预训练好的权重作为起点然后冻结前若干层骨干网络先训练50轮再解冻全部参数微调。输入分辨率我们最终设为640x640这对于现场1米距离拍到的中等尺寸缺陷够用如果追求对细微裂缝更敏感可以试1280x1280但推理帧率会明显下降。关键超参数可以参考这份配置思路优化器SGDmomentum0.937weight_decay0.0005初始学习率0.01采用余弦退火衰减批次大小GPU显存允许的前提下尽量到32以上但数据集类别不平衡就不建议开满训练轮数300轮左右配合早停验证集mAP不再提升就停类别权重脱落类初始样本只有裂缝类的三分之一我们给脱落类损失加权到1.8倍评估指标以mAP0.5和mAP0.5:0.95两个指标为准mAP0.5主要看能不能框准mAP0.5:0.95看定位精细度。对裂缝这种长条目标mAP0.5:0.95一开始很难看因为IoU稍微偏差一点就掉档这个正常重点守住0.5档的同时尽量往上拉。4.3 模型导出和现场部署训练出来的模型不能只躺在服务器上要能跑进现场的设备里。我们的部署分两路一路是服务器端批量分析把现场采集的照片打包上传GPU跑完生成报告另一路是边缘端实时检测采用类似面阵相机加边缘计算盒子的方案边采边检。导出环节统一走ONNX中间格式再转换到目标平台。重点检查三件事算子兼容性、动态输入支持、量化精度损失。我们起初为了压推理延迟做了FP16量化掉点不到1%但要小心某些芯片上的量化处理对细小裂缝不友好必须在量化前后用测试集跑一遍对比确认缝宽最小的那批样本没有大面积丢失。NMS阈值和置信度阈值的设置也要根据现场调整。验收场景要求查全率高置信度阈值可以降到0.25左右宁可多标一些可疑区域让工人复核维护监测场景希望减少无效工单置信度阈值可以提到0.5以上把明显无误判的结果才推给巡检人员。4.4 验收报告要输出什么检测系统要真正用起来光画框不够还要输出可复核的报告。我们的标准输出包括缺陷类型、置信度、包围框在原始图像中的坐标、缺陷在墙面上的大致位置编号、现场照片裁剪图。后处理阶段会把同一块瓷砖上的多个检测框合并为一个缺陷簇再做一次严重程度分级轻微只影响观感、一般需要修补、严重有脱落风险需立即处理。报告最终呈现给甲方的形式是一张带缺陷标记的墙面展开图加上表格化的缺陷清单。这个环节前期被我们严重低估了因为你做得再准验收人员也不可能对着原始照片去数框。反而是这份汇总报告真正决定了这套系统能不能在工地上被持续使用。5. 踩坑记录和常见问题排查5.1 采集阶段的坑第一个大坑是勾缝线误认为裂缝。深色勾缝剂和裂缝在低分辨率下几乎一样尤其当勾缝线做在瓷砖边缘、光照又很暗时。解决方法有两个一是采集时尽量保证对焦准确二是把“沿着勾缝线延伸且在勾缝线内部”的样本在标注时明确划为负难例。第二个坑是釉面反光。亮面瓷砖在窗户、灯具照射下会出现大片高光高光区域里裂缝完全被“淹没”。这种样本不能简单放弃它们是检验模型鲁棒性的重要压力测试但也不能全部丢进训练集否则模型会学成“见高光就报裂”。我们的处理是保留一部分反光样本同时用图像增强模拟更多反光效果。第三个坑更隐蔽采集人员习惯挑显眼的缺陷拍导致数据集里全是“大裂缝、大脱落”细腻的细微裂缝几乎为零。算法是用数据喂出来的数据里没有小缺陷模型自然就检不出小缺陷。后来我们强制要求每个采集批次里必须有至少30%的“难发现”样本比如细小发丝裂缝、早期局部脱落。5.2 训练阶段的坑训练阶段最折磨人的是类别不平衡。脱落和破损样本少模型一开始就能在验证集上拿高mAP但仔细看混淆矩阵会发现脱落几乎全漏。我们在损失函数里加了类别权重后有改善但更有效的是用公开的脱落图像辅助数据集做预训练先把脱落类别的视觉特征学会再回到我们的场景微调。还有一个坑是小目标裂缝的尺度。裂缝在640x640图像里常常只有二三十个像素长、两三个像素宽很容易被降采样直接抹掉。我们后来专门在训练时保留了一个高分辨率分支固定对输入图像做局部放大裁剪增强效果立竿见影。做项目时不要迷信某个模型“小目标能力强”不如在数据层面直接给小目标更多出场机会。5.3 部署和验收的坑现场部署第一个坑是相机畸变。广角摄像头在靠近墙面时会把人眼可见的直线拉弯裂缝的走向和宽度在图像边缘都会失真。解决办法是提前做相机标定畸变校正后再送入模型如果条件不允许就要求采集设备用中长焦段减少广角畸变影响。第二个坑是距离不一致。巡检人员手持设备时离墙0.5米和1.2米拍的同一块缺陷在图像上的尺度差出两倍多。我们做了一个简单的距离归一化用检测框物理尺寸结合相机内参反推缺陷实际大小这样报告里输出的“裂缝长度”“脱落面积”才有物理意义。第三个坑是现场验收流程的衔接。甲方的验收工程师习惯看“疑似缺陷”然后现场复核如果系统直接下结论说“这就是脱落”会引发信任危机。我们后来的呈现方式是“可疑区域标记置信度参考建议复核”让系统的角色从“裁判”变成“助手”反而更受欢迎。这个体会我要强调一下算法在现场的接受度很多时候取决于你如何设计人机交互而不只是精度指标。5.4 问题速查表整理一份实际项目中最常遇到的问题方便直接对照排查现象可能原因解决思路裂缝漏检、小缺陷看不见输入分辨率低、小目标增强不足提高分辨率加入局部放大裁剪增强勾缝线大量误报为裂缝负难例太少、标注规则不清晰增加勾缝线负样本明确标注规则脱落检测不准、时有时无类别不平衡、脱落特征多样性不足类别加权补充脱落难例迁移训练换一台手机就漏检严重设备画质差异大、数据集设备覆盖少采集多品牌多设备样本加入图像增强推理速度太慢模型太大、输入尺寸过高换轻量模型做量化边缘端部署上线后误报率升高现场光照和训练分布差异大用现场数据做在线难例挖掘快速迭代报告不能复核、甲方不认输出形式不符合工作流输出可疑区域裁剪图和坐标配合人工复核6. 这个项目还能怎么延伸6.1 从“识别”到“质量评估”单单识别出裂缝和脱落还不够真正值钱的是评估。接入分割模型后可以计算裂缝的像素长度、最大宽度、脱落区域的像素面积再通过标定换算成物理尺寸。有了这些量化指标就可以建立缺陷严重等级规则表。我们试过自动生成维护建议裂缝宽度小于0.2毫米且无延伸趋势的列为可观察宽度在0.2到0.5毫米且沿瓷砖边缘延伸的建议修补超过0.5毫米或脱落面积达到单个瓷砖面积10%以上的直接生成紧急维修工单。这一步把检测系统从“眼”变成了“脑”也是甲方愿意持续付费的原因。纯检测是成本项能给出维护决策建议的系统才是价值项。6.2 从固定点到移动采集目前很多巡检场景还是靠人工举着设备对墙拍。下一阶段的趋势是移动巡检把检测模型集成进手机App巡检人员沿墙走一圈视频流实时抽帧检测后台把每一帧的缺陷位置拼接成一面墙的缺陷分布图。手机端推理延迟目前已经能做到单帧50毫秒以内配合GPS或室内定位锚点缺陷坐标的现场可复核性会进一步提高。这个方向的真正难点不在模型而在视频流中的目标跟踪和去重。同一块缺陷在连续几十帧里反复出现不能让报告里重复计数需要用目标跟踪算法做跨帧关联。我们在模拟项目中用轻量跟踪器加特征相似度匹配缺陷去重准确率做到了接近95%体感已经可以接受。6.3 与楼宇管理系统联动再往后走检测结果不应该孤零零躺在报告里最好能和楼宇管理系统或者物业工单系统对接。某一次巡检的缺陷数据写入平台后自动生成整改工单指派给责任施工方整改完成后再次检测系统自动对比前后差异确认缺陷是否消除。这套闭环逻辑对装修公司尤其有价值瓦工施工、系统自检、返工、复检把质量管控变成数据驱动流程。如果积累了多轮历史数据还能做趋势分析哪些楼栋、哪些朝向、哪类瓷砖工艺更容易出脱落进而指导下一批项目的工艺改进。这一步已经不是检测算法本身的问题而是数据产品思维的问题但对任何做智能建造方向团队来说都是值得规划的方向。最后分享一点我个人的体会。这个项目让我印象最深的不是模型精度刷到多高而是数据集版本管理给整个项目带来的底气。没有第10433期这样一个持续迭代的机制模型可能训出来当天很好用三个月后工地一换就崩你连怎么修都无处下手。做缺陷检测这类长尾分布极强的事情永远不要想着一口吃成胖子建好采集、标注、训练、反馈这个循环系统才会越用越聪明。如果你也在做类似的视觉检测项目我建议从第一天就按这个思路搭好数据迭代的架子后面会省很多事。