做智能驾驶感知这几年，交通标志识别一直是我心里分量很重的一块。很多人觉得标志检测不是最难的任务，但在L5级智能驾驶场景里，它是一个必须同时满足高召回、低误检、低延迟和强鲁棒性的任务：高速匝道口、雨夜模糊、逆光反光、连续弯道遮挡，任何一次漏识别都可能让下游规划做出错误决策。我选择把YOLOv8作为这套交通标志识别系统的检测主干，不是因为它参数最炫，而是因为它工程化成熟、推理效率高、训练容错好。这篇文章就围绕这个落地方案，把数据、训练、部署和踩过的坑都摊开讲清楚。适合正在做车载视觉感知但还没把YOLOv8跑通的人，也适合想了解L5场景下真实工程约束的算法工程师。

1. 项目思路与方案拆解

1.1 L5级场景为什么把交通标志识别单独拎出来

L5级智能驾驶意味着系统需要在所有条件下自行完成决策和执行，没有人类兜底。感知层的每一项输出都会被规划模块直接当作“事实”来用，而不是像辅助驾驶那样还有人机共驾的纠错空间。交通标志识别在这类场景里的地位很特殊：它不像车道线那样每帧都在，也不像障碍物那样有雷达做冗余验证，它往往出现在特定位置、持续若干帧之后消失，一旦漏检，系统可能会在限速区段保持过高车速，或者在禁行路口继续规划通行路径。

所以L5的交通标志识别不能只做到“框出来了”，必须做到“我能确定这个标志存在，并且置信度达到阈值，并且连续多帧一致”。这就决定了整个方案不能只依赖一个检测网络，而是需要把检测结果和时序关联、地图先验融合起来。后面我会重点讲如何在YOLOv8之外构建这套确认机制。

1.2 YOLOv8选型理由与备选方案对比

项目启动时我对比过几类检测方案，既有传统的两阶段检测器，也有新一代端到端Transformer结构，但最终选了YOLOv8。核心原因是车端感知对延迟和部署稳定性的要求非常苛刻，而YOLOv8在满足精度的前提下，把训练、导出、量化、裁剪的链路做得非常完整。下面是我当时整理的对比。

YOLOv8采用的anchor-free检测头、C2f特征提取结构和动态标签分配策略，让它在处理小尺寸交通标志时比上一代YOLO更稳。另一个重要原因是它的解耦头把分类和回归分成两条分支，这对交通标志这种“类别非常相似、位置非常精准”的任务很有帮助。比如限速30和限速80，外形几乎一样，只是数字不同，解耦后分类头能更专注地学习数字特征，回归头则专注于边框位置。

1.3 整体技术栈与数据流设计

整套系统的数据流设计比单模型训练更关键。摄像头采集到图像后，先做分辨率归一化和曝光校正，再送入YOLOv8检测，得到所有候选标志框；这些候选框进入一个轻量级IOU跟踪器，用卡尔曼滤波维护位置和速度；连续若干帧确认后，才会把标志语义送入规划模块。地图先验会提前告诉系统“这个路段大概率有哪些标志”，用来在检测置信度很低时做加权，而不是直接替代检测结果。

这里有个设计原则：检测网络永远承担“发现”职责，时序模块承担“确认”职责，地图先验承担“优先级”职责。三个环节互相独立，任何一个环节出问题都不会导致整个系统完全失效。这样的分层结构也为后续做故障隔离提供了便利。

2. 数据准备：从原始图像到可训练样本

2.1 类别体系与样本分布设计

交通标志类别设计不能太细，也不能太粗。太细会导致类别间样本数量极度不均衡，比如“注意儿童”和“注意施工”可能只有几十张样本；太粗又会让规划层拿不到精确语义，比如把所有限速牌归为一类，却不知道具体限速值。我采用的方案是把标志分成两个层级：第一层是“基础语义类别”，包括限速类、解除限速类、禁令类、警告类、指示类；第二层是具体属性，限速类通过另一个轻量OCR模块识别数字。

这样设计的直接好处是检测网络只需要区分二三十个视觉差异明显的类别，数字识别任务从分类中剥离出来，避免去硬学“30”和“80”这类相似数字的微小差异。最终的类别列表大约有28类，覆盖常用的限速、禁令、警告、指路牌和施工标志。每个类别至少保证训练集里有2000个有效标注实例，低于这个阈值的类别会做针对性增广。

2.2 标注格式转换与难点标注处理

交通标志的标注看起来简单，实际上有大量边界案例。有些标志被杆子、树枝、车辆遮挡，框的边界怎么定？我的做法是：只标注可辨识的完整标志区域，如果遮挡面积超过一半就直接标为“ignore”，不参与训练。这样做避免了模型学习到残缺目标特征。

标注格式统一使用COCO格式，方便YOLOv8工程直接读取。转换过程中要特别注意坐标系的坑：有些标注工具导出的是多边形坐标，有些导出的是归一化中心点坐标，YOLOv8训练需要的是归一化的xywh格式。我在转换脚本里专门加了对异常坐标的校验，比如检测框超出图像边界的自动裁剪，宽度或高度小于1像素的丢弃，类别ID超出配置范围的跳过。这些细节看似不起眼，却能避免训练时出现loss变成NaN或者mAP异常波动。

2.3 数据增强与预处理流水线

车载摄像头的图像特点是强烈运动模糊、动态范围大、光照变化剧烈，所以增强策略不能只做常规的翻转和色彩抖动。以下是我的关键增强配置：

# 关键数据增强策略，使用albumentations实现 import albumentations as A train_transform = A.Compose([ # 先做随机裁剪，保留主要路面区域 A.RandomSizedBBoxSafeCrop(width=1280, height=1280, erosion_rate=0.2), # 模拟白天到黄昏的色温变化 A.HueSaturationValue(hue_shift_limit=10, sat_shift_limit=30, val_shift_limit=30, p=0.6), # 模拟逆光导致的对比度变化 A.RandomBrightnessContrast(brightness_limit=0.25, contrast_limit=0.2, p=0.7), # 模拟摄像头运动模糊 A.MotionBlur(blur_limit=(3, 9), p=0.5), # 模拟传感器噪声和夜间噪点 A.GaussNoise(var_limit=(10, 50), p=0.4), # 模拟雨滴对镜头的干扰 A.RandomRain(slant_range=(-10, 10), drop_length=10, drop_width=1, blur_value=0.5, p=0.2) ], bbox_params=A.BboxParams(format='coco', label_fields=['labels']))

有一个必须注意的地方：不要对包含文字的交通标志做水平翻转。翻转之后“限速”数字会变成镜像，模型可能学到错误的字形特征。尤其是指路牌上的地名文字，翻转后语义完全错误。所以我的增强流水线里只做垂直方向的小范围平移和旋转，水平翻转的p值设置为0。对于对称性很强的警告标志，即使允许翻转，也应该单独判断，不能一刀切。

3. YOLOv8模型训练与调优

3.1 环境配置与工程目录结构

训练环境我推荐Python 3.10或3.11，配合PyTorch 2.x。这里不展开安装过程，只提醒一个容易出错的点：CUDA版本和PyTorch必须匹配，否则训练时会报出类似“no kernel image available”的错。工程目录建议按数据处理、模型配置、训练脚本、评估脚本四层拆分，不要全堆在同一个文件里。我的习惯是每个实验单独建一个输出目录，把训练日志、权重、评估结果都归档，方便回溯。

一个比较实用的做法是先用小数据集跑通完整流程，确认数据读取、标签映射、损失计算都没有问题，再上全量数据训练。交通标志任务如果一开始就上几千张图片，标签错误会被淹没在庞大的数据里，等到loss异常时很难定位原因。

3.2 模型规格选择与结构YAML配置

YOLOv8有n、s、m、l、x几个规格。车端算力有限，我以m作为主力模型，数据类目变多之后再蒸馏一个轻量版。选择m而不是n，是因为交通标志属于小目标，n的通道数太少，特征表达不够；选择m而不是l，是因为l在GPU上推理延迟翻倍，在低功耗车规芯片上跑不动。每个项目要根据实际算力平台重新评估，不能只盯mAP。

类别配置文件结构如下：

# traffic_sign_dataset.yaml path: /data/traffic_sign train: images/train val: images/val test: images/test nc: 28 names: 0: speed_limit 1: speed_limit_end 2: no_overtaking 3: no_overtaking_end 4: stop 5: yield 6: no_entry 7: no_left_turn 8: no_right_turn # ... 其余类别按实际标注顺序补充

这个配置文件里最重要的是names的顺序必须和训练标签的类别ID完全一致。很多人训练时mAP突然变成0，就是因为后来重排了类别顺序，但历史标签没有同步更新。建议把names清单固定下来，后续新增类别一律追加到末尾，不允许插入或重排。

3.3 训练参数设置与启动命令

训练命令我会写成bash脚本，方便记录每次实验的参数组合。以m模型、输入分辨率1280为例：

yolo detect train \ data=traffic_sign_dataset.yaml \ model=yolov8m.yaml \ epochs=200 \ imgsz=1280 \ batch=16 \ device=0 \ lr0=0.01 \ lrf=0.01 \ momentum=0.937 \ weight_decay=0.0005 \ warmup_epochs=3.0 \ warmup_momentum=0.8 \ mosaic=0.5 \ close_mosaic=10 \ box=7.5 \ cls=0.5 \ dfl=1.5

这里两个关键参数需要解释。第一，imgsz=1280。交通标志在画面中的尺寸往往只有几十个像素，是典型小目标，用默认的640分辨率训练，很多小标志会被下采样到几个像素，特征全部丢失。提升到1280后，mAP50-95通常能提升3到5个百分点。第二，mosaic=0.5和close_mosaic=10。mosaic增强能提升模型的上下文理解能力，但交通标志的尺寸差异太大，过度mosaic会生成大量不真实的小目标，所以我把概率降到0.5，并在训练最后10个epoch关闭mosaic，让模型在接近真实分布的样本上收敛。

3.4 训练指标解读与模型筛选

训练过程中我主要盯着三个指标：loss曲线、验证集mAP50-95、单类recall。交通标志识别必须优先保证recall，也就是漏检率尽可能低。一个常见的误区是只追求mAP高分，结果虽然整体精度好，但最危险的那几个类别召回率很低。比如夜间“停车”标志召回率只有0.7，可停车标志直接决定车辆是否在路口停下，这个隐患绝不能接受。

筛选模型时，我会对比每个类别的recall矩阵，把recall低于0.9的类别单独拉出来分析。如果是样本太少导致的，就做针对性增广；如果是特征混淆导致的，就要考虑类别合并或后处理规则。训练日志里保存的confusion matrix非常有用，能直观看到哪些类别互相误判。

4. 车端部署：从训练模型到实时推理

4.1 模型导出与FP16量化

训练好的PyTorch模型不能直接上车，通常需要导出为ONNX再转换为TensorRT引擎。导出时有两件事必须做：一是固定输入尺寸，对于车载场景我直接固定到1280x1280，避免动态shape带来的额外延迟；二是开启FP16精度，车规GPU/SoC对FP16支持很好，精度损失通常在一个百分点以内，但延迟能下降约40%。

转换命令可以参考：

trtexec \ --onnx=yolov8m.onnx \ --saveEngine=yolov8m.engine \ --fp16 \ --minShapes=images:1x3x1280x1280 \ --optShapes=images:1x3x1280x1280 \ --maxShapes=images:4x3x1280x1280

如果遇到精度异常，第一步要检查图像预处理是否和训练时一致。YOLOv8训练时用的是letterbox填充，推理时也必须用同样的letterbox参数，包括填充值和缩放比例。很多部署事故都出在这里：训练时图像被缩放填充成灰色边，推理时直接resize成训练尺寸，导致目标形变，检测框偏移严重。

4.2 车端推理Pipeline设计

推理Pipeline我采用“采集-预处理-推理-后处理-跟踪”五级流水线，用独立线程跑每个环节。采集线程只负责从相机驱动拿图，预处理线程做letterbox和归一化，推理线程独占GPU，后处理线程解析输出，跟踪线程维护目标生命周期。这样做的好处是GPU不会因为相机的帧率波动而出现空闲，CPU和GPU可以重叠工作。

伪代码大致如下：

# 简化版车端推理主循环 while True: frame = camera.get_frame() tensor = preprocess(frame) # letterbox + normalize + to_gpu output = engine.infer(tensor) # TensorRT FP16推理 boxes = postprocess(output) # 解码 + NMS tracks = tracker.update(boxes) # IOU + 卡尔曼 planner.push(tracks) # 送交规划模块

这里有一个工程经验：不要在后处理里用Python写循环遍历所有候选框，而是尽量用向量化运算或TensorRT插件处理。1280分辨率下输出的候选框数量可能达到上千个，Python循环会轻松吃掉几十毫秒，直接破坏实时性。我用的是纯C++实现解码和NMS，推理整体延迟稳定在10毫秒左右。

4.3 帧间关联与异常抑制

单帧检测结果不能直接作为最终决策依据，原因很简单：任何检测器都有偶然的误检和漏检。我的策略是做“连续帧确认”：一个交通标志只有连续3到5帧都被检测到，且类别一致、位置变化符合运动模型，才送进“已确认”队列。如果连续5帧丢失，才从已确认队列中移除。

帧间关联的另一个作用是可以处理置信度抖动。某些标志在强光下置信度会波动，但位置稳定。我会为每个track维护一个置信度滑动平均，用滑动平均值去跟阈值比较，而不是用单帧瞬时值。这样能显著减少标志闪烁输出带来的规划抖动。对动态场景中忽然闪过的假标志，这种机制也能抑制掉。

5. 高频踩坑与排查速查表

5.1 小目标与远处标志漏检

这是所有交通标志识别项目里最普遍的问题。小目标漏检的根源是骨干网络连续下采样后，小目标的特征信息几乎消失。单纯调高阈值没有用，真正有效的手段有三个：第一是提高推理分辨率到1280甚至1536；第二是将训练集中的小目标实例通过复制粘贴进行过采样；第三是增加一个专门输出小目标特征的检测头，例如在骨干网络的浅层额外接一个更小的Head分支。第三点改动较大，我最终只在m模型上用了前两个手段，效果已经足够。

另一个行之有效的技巧是“多尺度训练”。训练时让输入尺寸在960到1536之间随机变化，模型对不同距离下的标志尺度都会更适应。推理时固定为最高分辨率，虽然训练时间变长，但召回率提升明显。

5.2 类别混淆：限速与解除限速、禁止超车与解除禁止超车

限速标志和解除限速标志外形非常相似，都是一个圆，一个带斜杠一个不带斜杠，斜杠的角度稍有差异。纯检测网络容易在这种精细纹理上出错。我的解决办法是引入“上下文规则”：如果同一路口检测到限速标志，同时地图先验显示该路段有限速，那么“解除限速”类别的置信度要做抑制。反过来也一样。这些规则放在后处理阶段，不增加任何推理成本。

更彻底的做法是把这类近邻标志合并成一个大类“限速相关”，再用一个额外的小分类头区分具体子类。但我实测下来，先按大类别检测，再对检测框区域做更精细的裁剪分类，对大目标效果好，对远处小目标反而会因裁剪分辨率不足而失效。最终我保留了规则抑制的方案，简单且稳定。

5.3 夜间、逆光过曝下的召回率骤降

车载相机和手机不同，曝光策略是全局的，夜间路灯下经常出现局部过曝，标志牌高反光时更是白成一片。模型在正常光照样本上训练良久，遇到这种完全不同的亮度分布，召回率下降是必然的。我用了两层手段来缓解。

数据层面，我将训练集中的一部分图像做了高光模拟，把标志区域的亮度局部拉高，甚至加上轻微光晕。算法层面，我加入了一个显式的亮度感知分支，在预处理时统计全图亮度直方图，如果判定为逆光或夜间，会先做一次局部自适应增益再送入模型。这个分支非常轻量，只增加约1毫秒，却把夜间recall提升了5个百分点。

5.4 部署延迟抖动与显存峰值

TensorRT引擎冷启动时第一次推理特别慢，这是GPU算子初始化和显存分配造成的。解决方法是启动预热：车辆点火后、正式运行前，先用一张黑图跑几十次推理，把引擎热起来。此外，显存峰值往往来自后处理时临时分配了大量CPU和GPU内存。我会给推理线程和后处理线程分别预分配固定大小的缓冲区，避免在循环体内反复new或malloc。

还有一个很隐蔽的坑：如果多个线程同时调用同一个TensorRT引擎上下文，会出现隐式锁竞争，表现就是延迟偶尔从10毫秒跳变到30毫秒。正确做法是每个GPU线程持有独立的ExecutionContext，但共享同一个engine的权重。这个改动对稳定帧率贡献非常大。

6. 实测结果与后续扩展方向

6.1 场景实测数据与结论

在一个约8000张的验证集上（混合公开样本和自采园区样本，覆盖白天、黄昏、夜晚、雨雾天），我最终选定的YOLOv8m模型取得了如下效果：

这个成绩不是靠单一模型硬撑出来的，而是检测+时序确认+地图先验协同的结果。特别值得注意的是，加入时序确认后，整条链路的“最终输出误检率”比单帧检测低了接近一个数量级，因为绝大多数单帧误检都是短暂噪声，无法通过连续帧一致性验证。

6.2 可扩展方向：多模态融合与在线学习

YOLOv8检测方案已经足够稳定，但L5场景还有更多信息可以利用。一个很自然的扩展是引入语义分割支路，把标志牌区域和路面区域的分割结果与检测框融合，能够进一步提升遮挡情况下的鲁棒性。另一个方向是在检测框内增加一个轻量OCR模块，用来识别限速数字、方向箭头甚至前方的临时交通指示牌内容，这比单纯做分类能表达的信息更丰富。

在线学习也是交通标志识别值得探索的方向。不同区域的标志风格、新旧国标差异很大，离线模型很难覆盖全部情况。可以设计一个数据回传闭环：当车辆在某个地点反复检测到同一未知标志且置信度偏低时，车端把脱敏图像上传到云端，云端经过人工或半自动标注后定期增量训练。这个闭环一旦跑通，系统的长期适应能力会有质的提升。

最后分享一个我个人的调试习惯：每次跑完评估，我都会把误检和漏检的样本按场景和类别单独拉出来，逐张查看，而不是只看mAP数字。交通标志识别是一个细节决定成败的任务，很多问题只有人眼看过错误样本之后才能找到真正的规律。比如你可能发现所有漏检都集中在“标志离相机超过60米”这个距离段，那下一步思路就非常明确了：提升分辨率，或者在更浅层的特征图上增加检测头。保持这种“看数据、找规律、再改模型”的循环，比盲目堆模型参数有效得多。