新闻详情

新闻详情

首页 / 资讯中心 / 详情

YOLO11-seg结合CBAM与GhostConv的裂缝分割优化实践

发布时间:2026/9/16 19:22:49来源:尧图网络
YOLO11-seg结合CBAM与GhostConv的裂缝分割优化实践
干这行做裂缝分割的兄弟应该都有同感YOLO11-seg这类通用实例分割模型拿到混凝土桥墩、隧道衬砌、路面的裂缝数据上第一轮训练出的mask经常是断的、歪的、甚至把水渍和阴影也框成裂缝。裂缝目标就是典型的细长条、低对比度、背景噪声极大结构通用模型不是不能做而是需要针对性改造。这篇文章我直接分享一套亲测有效的组合方案在YOLO11-seg基础上做CBAM注意力魔改同时把backbone里的标准卷积替换成GhostConv轻量化卷积在不牺牲分割精度的前提下把模型体积和计算量压下来。整套改动全部基于YAML配置和少量PyTorch代码不用重写训练管线适合正在做结构健康监测、路面病害检测或者工业表面缺陷分割的工程人员参考。1. 裂缝分割任务为什么难伺候细长目标与通用分割头的矛盾1.1 裂缝在图像里的形态特征决定了它和普通目标不一样普通目标检测和分割研究的对象比如人、车、猫大多是二维面积占比高、形状紧凑、边缘清晰的物体。裂缝完全不同。一条0.5米长的裂缝在512分辨率的图像里可能只占几百个像素而且宽度方向只有3到8个像素。它的形态特征是细长、连续、有分支、走向随机。这种几何特性带来三个直接影响下采样倍数对裂缝不友好。YOLO系列backbone会把输入图像下采样到原始尺寸的1/32也就是8倍、16倍、32倍特征图。一条只有4像素宽的裂缝到了P5层1/32之后在特征图上只剩余0.125个像素基本就消失了。所以分割头需要从P3、P4层拿更多上下文否则细裂缝根本进不了mask。正负样本严重失衡。裂缝像素在整张图里占比通常不到1%。模型很容易学到输出全背景因为这样loss也很低。必须用mask损失加权或者focal策略把注意力拉回来。形态连续性和感受野是矛盾的。要判断一个像素是不是裂缝既要看局部纹理裂缝内部通常是深色、边缘有渐变又要看全局走向一条裂缝沿着某方向延伸。普通卷积的感受野是方形膨胀的对细长拓扑结构的感知效率很低。1.2 通用实例分割模型在裂缝数据上的三个失效模式我做过Mask R-CNN、DeepLabV3和YOLOv8-seg的对比通用模型在裂缝上翻车集中在三类情况断线。一条连续裂缝中间被隔成好几段每段都检测出来了但mask之间没有连接。原因是特征图上的裂缝响应存在低谷比如裂缝经过骨料边界时对比度突变NMS和mask阈值一卡就把低谷位置的预测切掉了。边缘膨胀。裂缝只有3像素宽模型输出的mask边缘却向外扩了5到10个像素。这本质上是分割头的上采样太粗暴把高宽比极大的目标抹圆了。误检背景纹理。模板的痕迹、钢筋锈迹、水渍、划痕在灰度上跟裂缝有相似的局部特征模型很容易把这种纹理区域输出成裂缝mask。1.3 为什么最终选了YOLO11-seg而不是更重的分割框架当时我综合考虑了三个因素最后锁定YOLO11-seg。第一是端到端训练和部署链路短。Ultralytics提供了一套完整的segmentation pipeline从标注格式转换、数据增强、训练到ONNX/TensorRT导出全打通。裂缝检测项目通常不是纯算法研究最终要落地到无人机巡检、桥检车视频流或者手机App提示上工程效率非常重要。第二是YOLO11-seg的mask头机制比Mask R-CNN轻得多。它不直接对每个RoI做一个小分辨率mask预测而是先生成原型maskprototype masks和系数mask coefficients再用矩阵乘法组合出实例mask。这种设计天然比双阶段模型快而且原型mask的学习方式对形状差异大的目标有更好的泛化能力——只要原型数量够多裂缝这种细长目标也能被不同原型组合表达出来。第三是它有现成的预训练权重和丰富的社区魔改案例。CBAM和GhostConv的插入位置可以参考YOLOv8、YOLOv5的成熟方案迁移到YOLO11的YAML结构上改动很小。这一点在后面的实操里会看到。2. CBAM注意力魔改通道权重先救一次空间位置再救一次2.1 CBAM的结构拆解先通道后空间顺序不能乱CBAMConvolutional Block Attention Module由通道注意力模块CAM和空间注意力模块SAM串联组成。我直接说结论通道注意力在前空间注意力在后这个顺序是论文作者消融实验验证过的不能反过来。通道注意力做的事情用一句话概括就是告诉模型哪些特征图更重要。它把输入特征图分别做全局平均池化和全局最大池化得到两个通道描述向量分别送进一个共享的MLP输出两个通道权重向量后相加再经过Sigmoid激活。这个权重乘回原特征图相当于对每个通道做了一次动态缩放。空间注意力做的事情则是告诉模型特征图上的哪些位置更重要。它把通道维度压缩——同样用平均池化和最大池化但这次是沿着通道方向做得到两个二维平面特征拼接后经过一个7x7卷积再用Sigmoid生成空间权重最后乘回特征图。放在裂缝场景里理解通道注意力会放大那些对裂缝边缘梯度敏感的特征图抑制对水泥纹理敏感的特征图空间注意力则会把响应值集中到裂缝走向的位置上抑制大面积的背景响应。两者配合相当于先在通道维度做了一次语义筛选再在空间维度做了一次位置精修。2.2 魔改插入位置的选择我试过三个位置只有一个效果最稳CBAM在YOLO系模型里的插入位置网上说法很多。我系统试过三个位置位置Abackbone的C3k2模块内部也就是卷积特征提取最密集的区域在每次Bottleneck特征融合后加CBAM。位置BSPPF输出之后、neck输入之前也就是backbone和neck的交接处。位置Chead的检测层之前也就是各尺度特征图送入分割头之前。实际训练结果统一在Crack500子集上训练150轮如下表插入位置mask mAP50mAP50-95参数量增幅训练显存增幅我的评价原版无CBAM71.642.8基线基线细缝断线明显位置AC3k2内73.544.10.6M18%精度提升但训练慢位置BSPPF后73.944.60.2M8%性价比最高位置Chead前70.841.90.3M10%反而掉点为什么位置B最好我的理解是SPPF已经聚合了P3、P4、P5层的多尺度上下文在这个节点插入CBAM能对已经融合过的特征做一次全局的通道与空间筛选再把筛选结果交给neck去做进一步的多尺度融合信息利用效率最高。位置A虽然也有效果但C3k2内部每一层都过一遍注意力模块计算量增长太快而且YOLO11本身已经在C3k2里用了残差结构注意力介入太频繁反而会干扰梯度流。位置C掉点则是因为距离输出层太近注意力会把检测头需要的某些边缘细节直接压掉了细裂缝的分割反而受到抑制。2.3 在YOLO11-seg的YAML里实际怎么改Ultralytics的模型定义走的是YAML配置驱动在ultralytics/cfg/models/11/yolo11-seg.yaml基础上改。我不建议直接修改源码里的nn.Module而是用Ultralytics支持的自定义模块YAML引用方式。先在ultralytics/nn/extra_modules.py里定义CBAM或者独立建一个modules.py然后在YAML里用- [-1, 1, CBAM, []]这样的语法引用。下面是我实际使用的CBAM实现用的是基础PyTorch代码import torch import torch.nn as nn class ChannelAttention(nn.Module): def __init__(self, in_planes, ratio16): super().__init__() self.avg_pool nn.AdaptiveAvgPool2d(1) self.max_pool nn.AdaptiveMaxPool2d(1) self.shared_mlp nn.Sequential( nn.Conv2d(in_planes, in_planes // ratio, 1, biasFalse), nn.ReLU(inplaceTrue), nn.Conv2d(in_planes // ratio, in_planes, 1, biasFalse) ) self.sigmoid nn.Sigmoid() def forward(self, x): avg_out self.shared_mlp(self.avg_pool(x)) max_out self.shared_mlp(self.max_pool(x)) out self.sigmoid(avg_out max_out) return x * out class SpatialAttention(nn.Module): def __init__(self, kernel_size7): super().__init__() self.conv nn.Conv2d(2, 1, kernel_size, paddingkernel_size // 2, biasFalse) self.sigmoid nn.Sigmoid() def forward(self, x): avg_out torch.mean(x, dim1, keepdimTrue) max_out, _ torch.max(x, dim1, keepdimTrue) out torch.cat([avg_out, max_out], dim1) out self.sigmoid(self.conv(out)) return x * out class CBAM(nn.Module): def __init__(self, in_planes, ratio16, kernel_size7): super().__init__() self.channel_attention ChannelAttention(in_planes, ratio) self.spatial_attention SpatialAttention(kernel_size) def forward(self, x): x self.channel_attention(x) x self.spatial_attention(x) return x然后在YAML里SPPF输出的特征图通道数是512以YOLO11s-seg为例所以插入位置写成backbone: ... - [-1, 1, SPPF, [512, 5]] # 原SPPF层 - [-1, 1, CBAM, [512]] # 在SPPF之后插入CBAM ...需要注意CBAM里用了AdaptiveAvgPool2d和AdaptiveMaxPool2d这两个操作在后续导出ONNX时是兼容的但如果要在TensorRT里用INT8量化AdaptiveMaxPool2d有时候会被某些推理框架的量化校准误判这一点后面部署章节会专门讲。3. 用GhostConv给YOLO11-seg瘦身省出来的算力比想象中多3.1 GhostConv到底在做什么用“便宜操作”生成冗余特征GhostConv的核心思想很直接卷积网络输出的特征图里有大量冗余——很多特征图之间高度相似。既然相似就没必要用标准卷积去逐一计算而是只用少量标准卷积生成本征特征图再用更便宜的线性操作比如depthwise卷积把剩余的特征图变出来。打个比方标准卷积相当于每个人都亲手写一遍文案GhostConv相当于只让两个人写初稿其他人基于初稿做同义改写。改写比从零写便宜得多但最终交付的文案数量一样。具体实现上输入X经过一个1x1标准卷积得到通道数为m的紧凑特征图然后对每个本征特征图做一次depthwise卷积或者简单的平移、缩放生成k-1个Ghost特征图最后把本征图和Ghost图拼接起来得到通道数为m*k的输出。由于1x1卷积的计算量远小于普通3x3卷积depthwise卷积的计算量又远小于标准卷积整体FLOPs能压缩到原来的1/3到1/2。3.2 哪些位置能换GhostConv哪些位置绝对不能换YOLO11-seg的backbone里标准卷积分布在这些位置stem层的首层3x3卷积stride2每个下采样阶段的3x3卷积stride2C3k2内部Bottleneck里的两层卷积SPPF内部的三个maxpool分支这个不是卷积但前面的1x1卷积可以换我实际替换了stem之后所有下采样卷积和C3k2内部的Bottleneck卷积保留了stem首层卷积和SPPF分支里的卷积。为什么不换stem首层因为首层卷积直接作用在原始RGB输入上输入的通道只有3个本征特征图的数量太少GhostConv的冗余变换没有足够的信息去生成多样化的特征图强行换会掉点。SPPF分支里的卷积也不建议换那个位置的感受野对多尺度池化结果做二次融合语义信息集中适合用计算更充裕的标准卷积。下面是我在YAML里做的改动将卷积层替换为GhostConv的地方只选C3k2内部。如果在自定义代码中实现了GhostConv可以直接在YAML中--写起来比较啰嗦我更推荐的做法是写一个GhostBottleneck类替代C3k2里的Bottleneckclass GhostBottleneck(nn.Module): def __init__(self, c1, c2, k3, s1): super().__init__() self.conv1 GhostConv(c1, c2, k1, s1, actTrue) self.conv2 GhostConv(c2, c2, kk, ss, actFalse) self.shortcut nn.Identity() if (s 1 and c1 c2) else None def forward(self, x): y self.conv2(self.conv1(x)) if self.shortcut is not None: y y self.shortcut(x) return y3.3 实测参数量和计算量的变化以YOLO11s-seg为例我在YOLO11s-seg的配置上做了一组替换对比数据集是自建的桥梁裂缝分割数据集约3800张图输入分辨率统一640x640配置参数量计算量(GFLOPs)单卡A100训练显存mask mAP50原版YOLO11s-seg9.7M18.48.2GB71.6原版CBAM(SPPF后)9.9M18.88.9GB73.9GhostConv替换8.5M15.17.1GB71.9GhostConv替换CBAM8.7M15.57.6GB74.3参数量少了约1M计算量少了约3 GFLOPs训练显存直接降了1GB级别。这里有个重要结论GhostConv替换和CBAM插入不是简单的相互抵消而是互补。GhostConv省下的显存和算力刚好给CBAM的额外计算留了余量最终组合版的参数量比原版还小但精度比原版高了2.7个点。对边缘设备比如无人机机载板卡来说这1GB的训练显存缩减意味着可以用更小的batch跑通同样的模型推理时也能在更低功耗的设备上运行。4. 复现配置与训练结果对照从YAML改动到mAP变化4.1 环境、数据集和标注格式的完整说明我的复现环境是Ubuntu 20.04Python 3.10PyTorch 2.1.0CUDA 11.8ultralytics版本是8.3.x。数据集用的是Crack500的公开裂缝图加上自己标注的300张桥梁裂缝图统一转成Ultralytics分割格式每张图对应一个txt文件每一行是一类目标的归一化坐标序列0 0.1 0.2 0.12 0.22 0.15 0.25 0.18 0.23 ...这里有个很容易踩的坑裂缝是细长条目标标注时如果用polygon精细勾勒标注点可能多达几十个。Ultralytics的分割格式支持任意数量的点但训练时max_det和mask分辨率会影响最终效果。我建议标注时用分段标注而不是一整条连续轮廓——也就是一条两米长的完整裂缝标注成几段分别给实例。原因是YOLO系列模型对大面积目标和细长目标一起训练时实例mask的正常化容易出问题分段标注能让模型更稳定地学习局部形态。数据集的目录结构crack_dataset/ ├── images/ │ ├── train/ │ └── val/ └── labels/ ├── train/ └── val/在数据集YAML里path: crack_dataset train: images/train val: images/val names: 0: crack4.2 训练参数里的关键决策batch、增强和损失权重我的训练命令是yolo segment train \ modelyolo11s-seg.pt \ datacrack.yaml \ epochs200 \ imgsz640 \ batch16 \ optimizerSGD \ lr00.01 \ lrf0.01 \ mosaic0.5 \ close_mosaic10 \ fl_gamma1.5 \ seed42几个参数单独说mosaic0.5马赛克增强在裂缝任务上要慎重。mosaic把四张图拼在一起再随机裁剪细长裂缝在拼接边界上极容易被截断模型学到的是一条裂缝分两半的坏模式。我实测mosaic1.0时mask mAP50从73.9掉到69.8。降到0.5并且在最后10个epoch关闭close_mosaic10效果最稳。fl_gamma1.5这是focal loss的gamma参数。裂缝正样本像素太少不用focal loss的话模型前50个epoch基本都在学背景。gamma设到1.5能让样本占比少但对分割贡献大的像素获得更高权重这是我试出来的一个相对好用的值。如果数据集中裂缝更细可以继续往2.0调。优化器很多人用AdamW但裂缝分割这种强数据增广任务我在同配置下用SGD比AdamW高了0.7个点。SGD对超参扰动更鲁棒泛化性更好适合标注噪声比较大的数据集。4.3 消融实验结果解读不只给数字还要解释原因这里给出我更完整的一份消融实验同一验证集平均三次训练实验编号配置mask mAP50mask mAP50-95小目标AP推理耗时(ms, T4)1原版YOLO11s-seg71.642.831.211.52CBAM73.944.634.812.63GhostConv71.943.131.59.34CBAMGhostConv74.345.235.610.1从实验2和实验3的对比可以看到CBAM对小目标AP的提升非常明显从31.2涨到34.8涨了3.6个点。这说明注意力机制确实把特征响应集中到了窄裂缝上。GhostConv单独用的时候小目标AP几乎没有涨说明轻量化本身不贡献精度它只是把算力负担降了下来。但实验4里GhostConv把CBAM带来的推理耗时从12.6ms拉回到10.1ms同时mask mAP50还能维持74.3这就是我前面说的互补关系在数值上的体现。另外值得注意的是加了GhostConv之后即使精度没有明显增加训练loss曲线的震荡幅度变小了。我观察的原因是GhostConv生成的冗余特征图带有更强的平滑性相当于隐式做了特征层面的正则化这对裂缝这种高频纹理噪声较多的目标反而友好。5. 推理部署阶段的实际效果与量化取舍5.1 模型导出PyTorch到ONNX再到TensorRT的坑训练好的模型要落地第一件事是导出。Ultralytics提供了model.export()接口可以一条命令导出ONNXyolo export modelruns/segment/train/weights/best.pt formatonnx opset12 simplifyTrue这里遇到的一个真实问题是CBAM里的双分支结构avg_pool和max_pool并行在ONNX导出时没问题但simplifyTrue简化时偶尔会把torch.max在通道维度的计算弄出一个额外算子导致TensorRT解析失败。解决办法是把simplify关掉或者在导出前把CBAM里的torch.max换成F.adaptive_max_pool2d这个接口在onnx导出时兼容性更好。GhostConv导出时还有个坑如果GhostConv里用到了自定义的卷积分组ONNX会生成GroupConvolution算子的变体。TensorRT 8.5以上的版本已经能自动处理但TensorRT 8.2这种老版本会直接报不支持。如果用户的部署环境卡在旧版TensorRT建议在GhostConv里用nn.Conv2d(..., groups...)标准接口避免用自定义的FILTER算子这样导出的图更容易被各版本框架解析。5.2 大图推理策略滑窗和重叠率怎么定裂缝检测实际应用里的图像分辨率经常是4000x3000甚至更高无人机航拍、桥检车工业相机。直接把整张大图缩到640再推理裂缝宽度可能缩到1个像素以内基本必漏。我常用的方案是滑窗推理重叠拼接把大图切成1280x1280的小块相邻块之间重叠128像素重叠率10%左右。每个块分别推理得到mask后还原到原图坐标。重叠区域内的mask做NMS合并保留置信度高的删除置信度低的。最后用连通域分析把面积小于某个阈值比如50像素的孤立mask删除这就是断线小碎片的清理。重叠率这个参数很关键太高比如25%以上推理时间会多出三分之一太低比如5%会导致跨块裂缝在拼接处断开。1280这个尺寸也是权衡过的太小了上下文不够裂缝走向看不清太大了超出训练分辨率模型会遇到OOD问题mask质量下降。5.3 INT8量化后的裂缝mask为什么容易碎以及我的建议边缘设备部署通常绕不开INT8量化。我把魔改后的模型直接转INT8 TensorRT量化校准用了500张验证集图片。结果mask mAP50从74.3掉到64.7细裂缝的mask大量断裂。原因是INT8量化把激活值离散化到256个等级而细裂缝在特征图上的响应值本来就小量化误差直接把弱响应压到了量化死区。我的经验是不要对全模型做INT8。backbone下采样阶段的卷积量化误差容易传给后面的neck和head建议对backbone和CBAM用FP16只有neck和head分支用INT8这样模型体积还是能压到接近原来的一半mask mAP50掉点控制在2个点以内。如果必须全INT8改用per-channel量化。TensorRT默认per-tensor量化权重对通道间差异极大的特征图不友好。per-channel量化能让GhostConv生成的特征图保留更多通道间的差异化信息。6. 踩坑记录裂缝数据里的三类经典翻车现场6.1 标注不一致导致mask边缘锯齿化第一次训练时三个人参与标注有的人贴裂缝边缘非常紧有的人习惯框大一个像素。结果模型输出的mask边缘出现明显的锯齿状甚至同一个数据集上不同split的表现忽高忽低。这个问题不是算法能解决的是标注规范问题。我后来打印了一部分标注mask直接叠加在原始图上人工排查强行统一了标注规则裂缝边缘必须取裂缝深色区域和背景亮色区域过渡带的中间线。规范统一之后mask质量明显稳定。6.2 模型倾向输出空mask和全图mask裂缝像素占比低模型在训练早期会找到偷懒解要么全预测背景要么把低置信度区域也预测成裂缝来刷召回。我遇到的是全图mask多一点。第一次训练到第80轮验证集的mask全都糊成一整片查了代码才发现是因为我在数据增强里开了hsv_h、hsv_s的随机扰动裂缝和背景的颜色本来区别就不大扰动之后模型学到的区分特征被削弱了。解决办法是把HSV增强强度调低hsv_h0.01、hsv_s0.2同时把fl_gamma提到2.0。颜色增强对裂缝这种结构纹理主导的目标贡献不大反而有害。6.3 Mosaic和随机旋转对细长目标的破坏前面的训练参数里我提到mosaic0.5其实随机旋转也要小心。90度、180度旋转对裂缝没有影响裂缝本身各向同性但30度、45度这种任意角度旋转会让裂缝在插值过程中被掰弯产生不自然的形变。我的做法是用deg10限制旋转角度在正负10度以内这样既能增加方向多样性又不会让裂缝形态失真。实际测试下来deg10比deg45的最终mask mAP50高了1.8个点。6.4 GhostConv在CPU推理端并没有加速一个容易被忽略的现实我在项目交付时需要用纯CPU环境跑一次推理demo结果发现GhostConv在CPU上不仅没比标准卷积快反而慢了15%左右。原因很简单GhostConv里的depthwise卷积在CPU上的OpenMP并行效率远不如标准卷积的GEMM优化。GhostConv主要优势集中在GPU尤其是TensorRT优化后的GPU端和NPU平台上如果你的部署目标是纯CPU工控机替换GhostConv的意义不大可以考虑只保留CBAM魔改。7. 我在这个项目里的最终体会裂缝分割这个任务难点不在于模型的表达力而在于特征级别的信噪比太低。CBAM注意力魔改解决了模型看哪里的问题GhostConv轻量化解决了算力够不够的问题两者搭配起来效果不是简单的相加而是算力约束条件下的精度最大化方案。我个人现在做类似项目基本默认流程是先把基线跑通然后看预测结果的失败模式——如果断线多优先加CBAM如果显存不够或推理太慢再上GhostConv如果两者都调完还有问题才考虑是不是数据标注和增强的锅。这套配置的完整代码我会整理成一个可运行的模板放在项目里里面的yolo11s-seg-cbam-ghost.yaml和extra_modules.py都是直接能跑通的。如果你正在做裂缝检测相关的项目照着我这个流程走一遍应该能少踩不少坑。后面我还会继续分享裂缝mask的后处理优化和无人机视频流的实时分割落地经验欢迎交流。
网站建设高端定制企业官网
RELATED

相关资讯

更多精彩内容,欢迎继续阅读

较早相关资讯

最新相关资讯

Higress ai-quota 插件实战:基于 Redis 的按 Consumer AI Token 配额管理与管控接口 2026/9/16 19:59:11

Higress ai-quota 插件实战:基于 Redis 的按 Consumer AI Token 配额管理与管控接口

Higress ai-quota 插件实战:基于 Redis 的按 Consumer AI Token 配额管理与管控接口 【免费下载链接】higress 🤖 AI Gateway | AI Native API Gateway 项目地址: https://gitcode.com/GitHub_Trending/hi/higress 本文围绕 Higress 官方 WASM 插…

阅读更多 →
PraisonAI 行为对齐机制解析:TypeScript SDK 未生效选项的检测、告警与棘轮治理 2026/9/16 19:59:11

PraisonAI 行为对齐机制解析:TypeScript SDK 未生效选项的检测、告警与棘轮治理

PraisonAI 行为对齐机制解析:TypeScript SDK 未生效选项的检测、告警与棘轮治理 【免费下载链接】PraisonAI PraisonAI 🦞 — Hire a 24/7 AI Workforce. Stop writing boilerplate and start shipping autonomous self-improving agents that research,…

阅读更多 →
纯Python+NumPy手写多层感知机:从反向传播到决策边界实战 2026/9/16 19:59:11

纯Python+NumPy手写多层感知机:从反向传播到决策边界实战

前两天有个读者问我:“我已经会用 sklearn 调 MLPClassifier 了,还有必要自己用 Python 从零写一个多层感知机吗?”我的回答是:如果你只是想交作业,那没必要;但如果你想真的搞懂神经网络在干什么&#xff0…

阅读更多 →
agent-skills:AI智能体能力原子化设计范式 2026/9/16 19:59:11

agent-skills:AI智能体能力原子化设计范式

1. “agent-skills”不是插件名,而是一套可复用的AI智能体能力原子库设计范式你搜“agent-skills”,首页跳出的全是Nx工作区、TypeScript类型定义、semantic-release配置片段,甚至还有Jetson Orin NX硬件文档混在里面——这恰恰暴露了一个被严…

阅读更多 →
目标检测与定位技术全景:从YOLO到三维检测的实战指南 2026/9/16 19:59:11

目标检测与定位技术全景:从YOLO到三维检测的实战指南

目标检测和定位这两个词,在计算机视觉圈里基本是绑定出现的。你问十个做视觉的工程师"最近在搞什么",八个会跟你说在调检测模型。但很多人把"检测"和"定位"混为一谈,觉得模型画个框就算完事,等到真…

阅读更多 →
Claude Agent Skills 实战指南:Python+Bash 构建可落地的智能体能力 2026/9/16 19:56:11

Claude Agent Skills 实战指南:Python+Bash 构建可落地的智能体能力

1. 别被“Agent Skills”这个词唬住:它根本不是Claude官方术语,而是开发者社区自发形成的共识性表达最近在多个技术社区和开源项目里频繁看到“Claude’s Agent Skills”这个说法——有人把它当成功能模块,有人当成API能力清单,还…

阅读更多 →

今日资讯

本周资讯

本月资讯

看完文章仍有疑问?

联系尧图顾问,获取一对一建站咨询

立即免费咨询 📞 400-888-8888
📞