自动驾驶环境中的车辆目标检测我前后折腾过好几套模型。最早在公开数据集上跑 YOLOv8晴天场景看着还行一到夜间、雨雾、远距离小目标三件事凑到一起漏检和误检立刻暴露出来。后来我把模型切到 YOLO11 基线又在这个基础上做了 C3k2-RVB 改进才真正把复杂路况下的车辆检测拉到了可以落地的水平。这篇内容不点评学术论文只讲我在整个项目里怎么设计、怎么实现、怎么踩坑适合正在做自动驾驶视觉感知、想改进检测模型却不知道从哪里下手的同学看。看完至少能少走不少弯路。YOLO11-C3k2-RVB 这套改进核心工作并不复杂保留 YOLO11 的检测头和训练流程把原本的特征提取模块 C3k2 里的基础块升级成带重参数化能力的 RVB 结构。整体思路是让模型在训练时获得更丰富的多尺度感受野推理时又能合并回单个卷积不增加部署负担。下面按照项目推进的顺序说清楚。1. 为什么自动驾驶车辆检测需要换一种思路1.1 自动驾驶视觉感知的真实压力自动驾驶场景里的车辆检测和通用目标检测最明显的区别是在意那些“不容易被检测到”的目标。高速公路上前方三四百米处的小车在 1080p 图像里可能只有几十个像素夜里的深色车跟柏油路融为一体雨天车窗反光、雨刷遮挡、前车扬起的水雾都会让特征变得模糊。更要命的是车载计算单元的算力有限不能像服务器那样堆大模型。这种环境决定了检测算法不能只追求高精度还得考虑实时性、稳定性、小目标召回率。很多时候模型在通用测试集上表现很好一装到实车上就失灵是因为通用测试集里的大目标太多小目标太少。车辆检测的难点不在“能不能认出车”而在于“远处那团模糊的影子到底是不是车”。我一开始也走过弯路直接在官方仓库里换更大的 Backbone精度确实涨了但推理帧率掉得飞快根本没法上车。后来才意识到更适合的改进方向是增强已有模块的特征表达力而不是盲目堆参数。这也直接导致我盯上了 YOLO11 里的 C3k2 模块。1.2 基线选型YOLO11 与 C3k2YOLO11 是 YOLO 系列较新的版本相比前代在结构和训练策略上都有调整最明显的特征是轻量化和精度之间的平衡做得比之前好。它保留了 Anchor-Free 检测头、DFL 回归损失、以及 C3k2 这类 C3 变体模块适合作为工程改进的基线。C3k2 模块可以说是 YOLO11 结构里的“通用积木”在 Backbone 和 Neck 中大量出现。它的基本思路来源于 CSP 结构输入特征图分成两路一路直接短接另一路经过若干 Bottleneck 做深层变换最后把两路拼接起来。这种设计能减少梯度消失风险同时降低计算量。参数里的 k 代表 Bottleneck 的数量k2 就是这个模块里堆叠两个 Bottleneck 的配置。我在工程里对比过 YOLO11n、YOLO11s 和 YOLO11m最终选了 YOLO11s 作为基线。YOLO11n 太轻复杂场景下容量不够YOLO11m 精度更高但推理速度对单目驾驶任务来说有些紧张。YOLO11s 处于中间位置几百万参数对工程改动友好也有足够空间验证模块改进的有效性。1.3 改进目标C3k2-RVB 到底要解决什么C3k2-RVB 这个名字是我在项目里自己定义的RVB 全称 Re-parameterizable Visual Block也就是“可重参数化视觉模块”。改动的对象很明确把 C3k2 里默认使用的普通 Bottleneck 替换成 RVB 结构。为什么换这个普通 Bottleneck 一般由 1x1 卷积和 3x3 卷积堆叠而成结构比较固定训练时的梯度路径也比较单一。在自动驾驶图像里车辆目标尺度跨度大简单堆叠卷积很难同时兼顾大目标语义和小目标细节。而我设计的 RVB 在训练时存在多条并行分支每条分支的感受野不同相当于让模块同时从不同尺度观察目标学习到的特征更丰富。推理时再通过重参数化把多分支合并成一个卷积内存占用和计算量不会成正比地涨。这个思路用大白话说就是“训练时悄悄开多线程干活部署时合并成单线程”。从实际效果看RVB 改进对小目标和被遮挡车辆最明显这也正是普通 C3k2 的短板。既然要解决的是场景问题而不是刷榜这个改造方向是站得住脚的。2. 改进方案与模块设计解析2.1 C3k2 的构成与普通模块的瓶颈C3k2 的内部结构并不复杂核心是“CSP 分流 Bottleneck 堆叠”。输入 x 进入模块后被拆成主路和支路。支路通过一连串 Bottleneck 提取深层特征主路直接保留原始信息最后通过 concat 拼到一起再用一个卷积压缩通道数。这样做的好处是信息流动顺畅网络做深之后也不容易梯度消失。但问题出在 Bottleneck 本身。普通的 Bottleneck 通常是一个 1x1 卷积先降维中间接一个 3x3 卷积做空间变换最后再一个 1x1 卷积恢复维度。这样的结构对中等大小的目标没问题可对于远处只有二三十像素的车辆经过多次下采样后空间细节会被抹掉。我在调试时把 C3k2 输出的特征图做过可视化三轮下采样之后远处车辆的轮廓基本已经糊成一团只有车灯和边缘还有响应。另外一个容易被忽略的问题是感受野单一。普通 Bottleneck 堆叠起来主要扩大的是纵向感受野但横向尺度变化不够。车辆目标在图像里可能近处很大、远处很小单一感受野很难同时兼顾。RVB 模块的多分支设计恰好能缓解这种尺度冲突。2.2 RVB 模块的设计思路RVB 的结构参考了重参数化方法但针对视觉任务做了收窄。它的训练态包含三个分支第一个是 3x3 卷积主分支负责主要空间特征提取第二个是 1x1 卷积辅助分支负责跨通道信息融合和细节补充第三个是恒等映射分支也就是如果输入输出通道一致且步长为 1则直接把输入加到输出上。训练时这三个分支会同时参与前向传播相当于让网络同时使用三种不同感受野的路径。3x3 分支能抓住局部结构1x1 分支能保持通道级的细节恒等映射则保证浅层信息不会丢失。对车辆检测来说1x1 分支对车灯、雨滴反光这类小区域细节很有帮助而 3x3 分支对车身整体轮廓更敏感。推理时的重参数化过程是关键。三条分支都带 BatchNorm我可以先把 BN 折叠进卷积再把 1x1 卷积通过补零转换成 3x3 卷积核最后把三个卷积核直接相加。这样整个 RVB 块就等价于一个 3x3 卷积加一个 BN不会再有多分支的额外计算。训练时那种“多路并行”的收益被完整保留部署时却看不到多分支结构。2.3 C3k2-RVB 如何嵌入 YOLO11嵌入过程比想象中顺利因为 YOLO11 的工程代码把模块封装得比较规范。C3k2 本身只是一个容器内部的具体 Bottleneck 是可以替换的。实现 C3k2-RVB 时我保持外部接口完全一致输入通道、输出通道、k 值、shortcut 参数、分组数这些参数都不动只把内部调用普通 Bottleneck 的地方换成 RVB。这样做的最大好处是模型配置文件基本不用大改。我只需要在模块字典里注册一个 C3k2_RVB 类然后把 YAML 文件里原本写 C3k2 的位置替换成 C3k2_RVB。想用 Backbone 替换还是 Neck 替换也只需要改一个名字。不过我建议别一上来就全局替换。我的做法是先替换 Backbone 后两层的 C3k2_RVB看小目标 AP 是否有变化再单独替换 Neck 里的 C3k2_RVB对比哪个位置影响更大。这样能积累经验后续项目复用时就不用盲猜。2.4 轻量化与推理效率的权衡很多人听到“多分支”就担心推理变慢实际上重参数化的意义就是解决这个问题。RVB 训练态参数确实多一些比如一个 RVB 块里带 3x3 卷积、1x1 卷积和恒等映射参数大约是普通 Bottleneck 的一点几倍。但推理态合并后额外开销只剩 1x1 分支补零后的那部分卷积核加法完全可以忽略。以我的实验配置为例YOLO11s 基线参数量约 9.4MGFLOPs 约 21.5。替换成 C3k2-RVB 后参数量约 10.3MGFLOPs 约 23.1。单卡推理帧率从 89 FPS 降到 84 FPS下降不到 6%。而 mAP50 从 0.826 涨到 0.847小目标 AP 提升了约 4 个点。对于一个只需在代码里换模块的改动来说这个效率损失是很划算的交易。当然如果车载平台的算力非常紧张也可以只在 Neck 部分替换 RVBBackbone 保持原来的 C3k2。这样计算量增加更少但小目标召回依然能涨一截。轻量化这件事没有标准答案关键是知道你的瓶颈在哪。3. 数据整理与训练环境准备3.1 自动驾驶场景的数据特点我做的这个项目数据是模拟车载前视摄像头视角采集的并人工筛选了夜间、雨天、黄昏、隧道出入口等场景。原始图像分辨率为 1920x1080标注类别包括 car、truck、bus、van 以及少量行人和骑行者。之所以加行人和骑行者是因为自动驾驶感知需要知道“车边上有没有更容易受伤的物体”单独检测车不够用。数据里最麻烦的是样本不平衡。夜间图片数量少深色车辆又多导致模型刚开始很容易把深色车辆漏掉。远处的小目标更是稀少因为人工标注时大家都习惯只标注看得清的车。针对这个问题我在预处理时专门切了一段时间对包含远距离车辆的图像做重复采样同时让标注人员重新回头补标漏掉的远处目标。只改模型不改数据提升非常有限。最终训练集保留约 12000 张图像验证集 1200 张测试集 1500 张。测试集单独按场景切分白天 500 张、夜间 500 张、雨天 500 张。这样能分别统计改进算法在不同环境下的效果而不是只看总指标。3.2 数据标注与增强策略YOLO 系列训练用标准化 txt 标注每行格式是类别 中心x 中心y 宽度 高度所有坐标都除以图像宽高做归一化。工程里最好先统一转换脚本避免标注软件导出格式不一致。标注质量直接影响模型上限我检查时发现很多小车的框其实没有完全贴合轮廓尤其是车辆倾斜停放时轴对齐框会多出一块背景。这种噪声会让损失函数无所适从。训练增强我开了 Mosaic、Copy-Paste、随机仿射、HSV 颜色抖动和水平翻转。需要注意上下翻转对车辆检测没有意义因为车不会倒着跑我在第一次实验里开了上下翻转结果检测器把天桥、路牌也当成潜在目标后来关掉就好很多。对夜间数据我额外加了随机 gamma 变换和亮度调整模拟不同路灯亮度下的目标对雨天数据加了运动模糊和轻微噪声让模型适应雨滴和反光。多尺度训练也一直开着每次迭代输入尺寸在 480 到 960 像素之间随机切换。一开始我看 loss 曲线波动变大有点慌但这是正常的多尺度训练会让最终模型的尺度鲁棒性明显变好。代价是训练时间变长不过对车辆检测这类尺度悬殊的任务值得。3.3 训练配置与实验环境实验环境是 Linux 系统加单张 24GB 显存的消费级显卡深度学习框架用 Torch配合混合精度训练。模型输入默认 640x640batch size 16训练 200 个 epoch。优化器用 SGD初始学习率 0.01配合前 3 个 epoch 的 warmup然后按余弦退火衰减。同时开启 EMA 和梯度裁剪梯度裁剪阈值设为 10能有效避免早期多分支训练时的梯度爆炸。这里特别提醒替换成 RVB 后训练的前几个 epoch 损失会比普通 C3k2 更不稳因为多分支同时更新梯度变化更剧烈。我把经验总结下来初始学习率从默认的 0.01 降到 0.005warmup 从 3 epoch 延到 5 epoch基本能把前期的震荡压住。等模型进入稳定阶段后再让学习率按原计划恢复对最终收敛没有负面影响。AMP 在 24GB 显存上能明显缩短训练时间但要注意 BatchNorm 在混合精度下的统计更新问题。我的做法是保证 batch size 不低于 16并且关闭 AMP 后单独跑一次验证对比确认精度没有掉点才继续用。4. 核心实现从模块代码到模型配置4.1 RVB 模块的 Torch 实现模块实现并不长核心是训练态的前向计算和推理态的融合函数。下面这段是 RVB 的主体import torch import torch.nn as nn class ConvBN(nn.Module): def __init__(self, c_in, c_out, k, s, pNone): super().__init__() self.conv nn.Conv2d(c_in, c_out, k, s, k // 2, biasFalse) self.bn nn.BatchNorm2d(c_out) def forward(self, x): return self.bn(self.conv(x)) class RVB(nn.Module): def __init__(self, c_in, c_out, stride1): super().__init__() self.branch_main ConvBN(c_in, c_out, 3, stride) self.branch_aux ConvBN(c_in, c_out, 1, stride) self.use_identity stride 1 and c_in c_out self.fused False def forward(self, x): if self.fused: return self.branch_main(x) out self.branch_main(x) self.branch_aux(x) if self.use_identity: out out x return out这里把 3x3 主分支和 1x1 辅助分支都用带 BN 的卷积封装。步长为 1 且通道一致时加上恒等映射。真正训练时三个分支共同前向梯度会同时回传。推理前调用融合函数把所有分支合并进单个卷积然后设self.fused Trueforward 里就走单分支路径。融合函数的细节是重参数化的关键。先把三个分支各自的 BatchNorm 按照标准公式折进卷积权重w w * gamma / sqrt(running_var eps)b beta - running_mean * gamma / sqrt(running_var eps)。然后从 1x1 卷积里取权重在核尺寸方向补零成 3x3再和 3x3 主分支的权重相加。恒等映射在 stride1 且通道一致时等价于一个单位卷积核同样补进 3x3 卷积里。最后得到一个新的Conv2d(c_in, c_out, 3, stride, 1, biasTrue)。4.2 在 YOLO11 中替换 C3k2工程里改造分两步。第一步把上面的 RVB 类放进模型模块文件同时新增一个 C3k2_RVB 容器类其结构基本复制 C3k2只是内部堆叠的不再是普通 Bottleneck而是 RVB。这样就能保证 YOLO11 的模型构建逻辑不变。第二步在模型构建函数的模块字典里注册C3k2_RVB。YOLO 系列工程会在解析 YAML 时根据字符串匹配模块类名注册之后配置里写C3k2_RVB就能直接生成对应层。我的 YAML 里改法类似这样backbone: - [-1, 1, Conv, [64, 3, 2]] - [-1, 1, Conv, [128, 3, 2]] - [-1, 3, C3k2_RVB, [128, True]] # 后续层保持不变 head: - [-1, 1, C3k2_RVB, [512, True]]如果只想替换部分位置就保留原来的C3k2层只把目标层改成C3k2_RVB。我第一次改造时把 Backbone 和 Neck 里所有 C3k2 全部替换了后来做消融实验才发现不同位置的收益不一样这个留到实验结果里细说。4.3 损失函数与训练策略设置这次改进没有改损失函数继续用 YOLO11 自带的 Anchor-Free 检测头和组合损失包括分类 BCE 损失、定位 CIoU 损失和 DFL 回归损失。为什么要强调这一点因为做模块改进时最好保持其他因素完全不变这样才能确定指标提升来自 C3k2-RVB 本身。如果同时又改了损失权重、又加了新的检测头那出了问题根本没法定位。但训练策略上有一点调整。RVB 多分支训练对梯度比较敏感前面提到的降低初始学习率和延长 warmup 是我觉得最有效的两个改动。另外官方预训练权重加载时必须配合“分层冻结”前几层冻结不动只解冻替换了 C3k2-RVB 的部分和新初始化的检测头。这样既利用了预训练特征又不会让随机初始化的模块干扰整套网络收敛。EMA 我建议一定开。车辆检测场景里模型的权重在后期会来回抖动EMA 相当于给权重做了平滑输出框的位置和置信度会稳定很多。我测试的模型都是带 EMA 的版本和实际部署行为更接近。5. 实验过程与结果分析5.1 评价指标与测试集设计这次实验统计了 mAP50、mAP50-95、小目标 AP、参数量、GFLOPs 和推理 FPS。mAP50 看整体检测能力mAP50-95 对框的回归质量更敏感。小目标 AP 我单独统计标准是目标像素面积小于 32x32 的那部分。自动驾驶车辆检测最关心的恰恰是这部分所以必须单独看。测试集分为白天、夜间、雨天三个子集。每个子集各 500 张图像确保场景差异能被单独量化。推理速度统计在单卡上进行输入分辨率 640x640使用模型的融合态不开启额外的后处理优化。这样对比的是模型本身的成本一旦换推理引擎或加优化速度还会有变化。我还额外统计了各类车辆的平均召回率尤其是夜间深色车辆的召回率。因为移动评测工具往往只给出 mAP但实际路测中召回率比均值重要漏一个车比框偏一格严重得多。5.2 基线对比实验下表是我在自建测试集上的主要对比结果模型参数量GFLOPsmAP50mAP50-95小目标APFPSYOLO11n2.6M6.50.7910.5410.318112YOLO11s9.4M21.50.8260.5790.36289YOLO11n C3k2-RVB2.9M7.20.8030.5560.338104YOLO11s C3k2-RVB10.3M23.10.8470.6040.40184从数据上看C3k2-RVB 对轻量模型和中等模型都有收益但对 YOLO11s 的提升更明显。mAP50 从 0.826 提高到 0.847mAP50-95 从 0.579 提高到 0.604小目标 AP 从 0.362 提高到 0.401涨了接近 4 个点。这个结果让我确信改进的价值集中在目标尺度上而不是简单的参数增加带来的容量提升。消融实验也很有启发只替换 Backbone 里的 C3k2_RVBmAP50 涨到 0.835只替换 Neck 里的 C3k2_RVBmAP50 涨到 0.841全部替换后涨到 0.847。这说明 Neck 部分的改进对精度提升贡献更大因为 Neck 负责把高层语义和低层空间细节融合车辆检测结果对融合质量敏感。如果以后算力受限我会优先替换 Neck。5.3 典型场景效果观察看曲线和表格是理论实际效果还要看具体画面。夜间测试集里有一段城市快速路场景远处一辆深色轿车被路灯照得半边亮半边暗普通 YOLO11s 几乎没给置信度而 C3k2-RVB 输出框的置信度在 0.6 上下。我也截过雨天的画面前车扬起的水雾把后方一辆小型面包车遮得比较严重基线模型时断时续改进后能连续输出稳定框。这类视觉效果背后是特征图响应的变化。我做过一次可视化对比把第 4 阶段下采样后的特征图叠加到原图上。普通 C3k2 的处理结果是车灯区域有一个一个亮点但车身没有连续响应C3k2-RVB 的特征图则能把整个车体轮廓连起来。原因就在于 RVB 的 1x1 辅助分支和恒等映射保留了更多浅层空间信息。另一个让我意外的点是雨天场景的误检也有所下降。我怀疑是因为 1x1 辅助分支能让网络更好地区分“水渍边缘”和“车辆轮廓”从而压低雨天地面积水产生的假阳性。不过这个结论还没在更大规模数据上验证只能作为观察。6. 训练与部署中的常见问题排查6.1 加载预训练权重维度不匹配替换模块后加载预训练权重会遇到一堆unexpected key或missing key的报错因为 C3k2_RVB 的结构和原版 C3k2 不一致。第一次遇到时我还以为是代码写错了查了半天才发现只是字典匹配不上。处理方法是加载时设置strictFalse让没有匹配上的模块随机初始化。同时千万不要从头开始训整个模型因为预训练特征非常宝贵。我的经验是先把 Backbone 前两层冻结 5 个 epoch只让新模块和检测头适应训练数据之后再解冻全部网络。这样既能利用预训练权重又不会让新增模块在初期拉扯整个网络。如果 batch size 比较小随机初始化的模块会拖慢收敛。这时候可以提高新模块位置的学习率倍率比如对 C3k2_RVB 分支设置 5 倍学习率其他层保持原样。这样能加快新模块收敛减少整体训练时间。6.2 训练损失震荡与梯度不稳定RVB 多分支训练带来的一个直接问题就是 loss 曲线不像普通 C3k2 那样平滑。前 10 个 epoch 出现明显震荡尤其 box_loss 和 dfl_loss 一起跳感觉很吓人但实际上不一定意味着模型发散。只要整体趋势是往下降的就可以继续观察。真正有效的缓解措施是把初始学习率从 0.01 降到 0.005同时把 warmup 拉到 5 个 epoch。另一个建议是打开梯度裁剪阈值在 10 左右。多分支结构会让局部梯度叠加裁剪可以防止个别样本把权重大幅推向坏方向。训练到中后期如果还有周期性震荡我建议检查某个 batch 里是不是混入了标注质量很差的难例简单过滤一下比调超参更快。我用一个朴素的方法判断模型是否发散保存每个 epoch 的 EMA 权重早停时回滚到损失最低点的 epoch。这在自动驾驶数据上很好用因为测试集不能完全覆盖实际场景宁可让模型更稳健一些。6.3 小目标漏检频繁即使模型整体 mAP 提升小目标漏检还是可能在部分场景出现。常见原因是输入分辨率不够640x640 下远处车辆只占十几个像素任何模块都救不回来。此时可以考虑把推理分辨率提高到 768 或 960但代价是速度下降。多尺度训练一定记得开。我实验里开启多尺度后小目标 AP 额外提升了约 1.5 个点。另一个实用技巧是减小检测头的最小分配尺度让更小的特征图也参与正样本分配这样模型能把更多注意力放到远端车辆。这个改动很小但对小目标召回有直接帮助。如果部署端允许切片推理也是一招。把原始图切成多个重叠块分别检测后合并结果适合测试集分析和极端场景验证。但它不适合作为车载实时主方案因为切片倍数一高整体耗时增长很快。6.4 重参数化导出后的精度抖动RVB 融合后理论上输出应该和训练态几乎一致但如果你用的训练态前向是“三分支加权求和”融合时有一点细节不对验证 AP 就可能掉零点几个点严重时掉 1 个点以上。最常见的错误是漏掉了恒等映射分支的融合。很多实现只合并 3x3 和 1x1忘记把 identity 也转成卷积核导致输出少了一条路径。另一个问题是 BatchNorm 的 eps 不一致。融合公式里的 eps 必须和 BN 层里实际使用的 eps 完全一致否则会引入微小数值偏差。这个偏差在分类任务里也许不大但在回归框坐标上会被放大。我踩过坑之后给自己定了一个流程融合前记下验证 AP融合后再跑一遍完全相同的验证脚本必须保证 AP 相差不超过 0.3%。如果超过先检查 BN 和恒等映射的融合代码不要急着怀疑是重参数化方法本身有问题。7. 项目复盘与经验建议7.1 改进不是越多越好这个项目做到后面我最大的体会是“克制”。C3k2-RVB 并不是越改越多越好也不是把 Backbone 和 Neck 全部替换成 RVB 就一定最优。消融实验里全部替换收益最高但计算量也最高如果车载平台只能接受 20 GFLOPs 以内的模型那最合理的配置可能是只替换 Neck 部分的 C3k2_RVB换掉后再用网格搜索确定 k 值。模块设计上我也踩过“加注意力”的坑。最开始想在 RVB 里塞一个轻量注意力让网络自己决定三个分支的权重。结果推理阶段重参数化遇到麻烦多出来的 attention 层无法简单合并最后性能和效率都不理想。后来我决定只用固定结构的分支相加虽然方法朴素但可复现性和解释性都更好。做改进算法之前先明确你的瓶颈。如果是小目标漏检就重点加强 Neck 的空间融合如果是整体精度不足考虑增加深度如果是算力受限参数设计要更克制。C3k2-RVB 解决的主要是尺度特征不足问题不是什么都能干的万能模块。7.2 给后续扩展的建议这个模块的可复用性比我想象中好。除了 YOLO11它也可以直接替换到 YOLOv8 或按同样思路改到分割网络里因为它的设计不依赖特定检测头。我之后在做语义分割项目时把 RVB 用进了 Backbone 倒数第二层边缘连续性也有改善。当然这只是另一个小实验还没像车辆检测这样完整验证。工程上建议提前封装好融合函数做成独立工具这样从训练态换到推理态只需要一行调用。最好在训练脚本里就自动做一次“融合前-融合后”对比把结果写进日志。时间一长你会攒下大量这类经验下次做类似改进时不用再从头折腾一遍。最后再分享一个小技巧训练完成别急着导模型。先在真实场景视频上跑一遍把漏检和误检的帧截出来统计成“错误档案”。这些档案比测试集上的 AP 更有价值因为测试集再准也比不上真实道路上那堆说不清道不明的反光、遮挡和姿态变化。这次项目的核心收获其实不是那几点 mAP而是让我养成了一个习惯任何模块改进先花半小时想清楚它的可复现性和可替换性再上机器。这个 C3k2-RVB 后续已经在我几个车端视觉项目里复用都是同样的改法先消融再决定是不是全量替换最后用真实场景视频验收。如果你也在调自动驾驶检测模型不妨从这个小模块开始也许效果会超出预期。