交通灯识别这个题目，每年毕业季都会被大量翻出来做一遍，但我见过太多做出来的东西只能在自己剪的那几段视频上跑通，换个路口、换个光照就全线崩。问题不在于模型不够新，而在于大多数人从选题那一刻就没想清楚：这个系统到底要解决什么场景下的什么问题，数据从哪来，评价标准是什么。我前后带过几届做这类题目的同学，也自己复现过若干套方案，踩过的坑基本能凑成一本小册子。这篇就把基于深度学习的交通灯识别与目标检测这套东西，从任务定义、数据构建、模型选型、训练调参到部署演示，完整拆一遍，重点讲那些文档里不会写、但直接决定你系统能不能跑起来的关键细节。不管你是刚定题、还在纠结用YOLO哪个版本，还是已经训完模型但指标上不去，应该都能从里面找到能直接抄的部分。
1. 先把任务边界划清楚：交通灯识别到底在检测什么
很多人一上来就写"基于YOLO的交通灯识别"，然后拿COCO预训练权重直接开训，训完发现模型根本分不清红黄绿，甚至把车尾灯、路灯、广告牌上的圆形图案全框成交通灯。这不是模型的问题，是任务定义从一开始就糊了。交通灯识别在工程上其实是两个耦合但可以拆开的子任务：交通灯目标检测（在图像里定位出交通灯的位置）和交通灯状态分类（判断这个灯当前是红、黄、绿还是灭）。你把它们当成一个多分类检测任务做也行，但必须清楚这两件事的难度分布完全不同。
1.1 检测难还是分类难：一个常被搞反的认知
直觉上大家觉得分类简单，检测难。实际在交通灯这个场景里恰好反过来。检测的难点在于小目标和密集遮挡——一个1080P的行车记录仪画面里，远处的交通灯可能只有十几个像素宽，YOLO下采样到特征图最后一层时这个目标可能已经消失了。而分类的难点在于颜色在真实光照下极不稳定：逆光时红灯发白，黄昏时黄灯和红灯肉眼都难分，雨夜里绿灯的光晕会糊成一团。
我做过一个统计，在某批自采数据上，检测框的召回率能到0.92，但框对了之后状态分类的准确率只有0.81，错误主要集中在黄昏和强逆光两个时段。这个数字说明什么？说明如果你的系统在演示时"认不出灯"，大概率不是没检测到，而是检测到了但状态判错了。所以设计系统时，分类头的设计和数据增强策略，优先级不低于检测主干。
1.2 输出定义：你要的是框还是决策
还有一个必须提前定的问题：系统的最终输出是什么。是输出一堆带类别标签的检测框，还是输出一个"当前该走该停"的决策信号？这两者的评价体系完全不同。如果只是毕设演示，输出检测框加状态标签就够了；但如果想做得像样一点，加一层基于检测结果的决策逻辑——比如取画面中面积最大的交通灯、结合其位置判断是否属于当前车道——会让整个系统看起来完整得多，也更能体现你理解了应用场景。
我建议的输出结构是这样的：每个检测结果包含bbox、state（red/yellow/green/off）、confidence，然后在上层做一个简单的后处理，按置信度和框面积加权选出"主交通灯"，再映射成通行建议。这个后处理逻辑不复杂，但它是把"检测模型"变成"识别系统"的关键一步，答辩时也特别好讲。
2. 数据这一关：自采、公开集与标注的取舍
交通灯数据是这个项目里最容易被低估的部分。网上能下到的公开交通灯数据集不少，但直接拿来训往往效果一般，原因很简单：域不匹配。欧洲的数据集里交通灯样式、安装位置、道路环境和你本地采集的画面差异很大，模型学到的特征迁移过来会掉点。我的经验是公开集用来做预训练或者扩充类别多样性，真正决定效果的还是你自己采的那批数据。
2.1 数据采集的实操细节
采集设备不用太讲究，手机固定在车内支架上录视频就行，但有几个参数必须注意。分辨率尽量上1080P，因为交通灯是小目标，分辨率低了远处目标直接没了；帧率不用高，15到30帧足够，反正相邻帧高度冗余；录制时段要覆盖白天顺光、白天逆光、黄昏、夜间四个典型场景，每个场景至少录10分钟有效片段。我见过有同学只录了中午晴天，训出来的模型一到傍晚就瞎，返工重采的成本比一开始就规划好高得多。
从视频抽帧时别按固定间隔无脑抽，那样会抽出一堆几乎一样的帧，标注成本浪费严重。正确做法是先做帧间差分或简单的相似度过滤，把连续重复的帧去掉，保证抽出来的帧在视角和场景上有变化。一般一段10分钟的视频，抽200到400帧有效样本就够用了，多了边际收益很低。
2.2 标注规范：类别体系和框的松紧
标注类别建议就设四类：red、yellow、green、off（不亮或损坏）。不要设"交通灯"这个父类再分子类，那会让标注和训练都变复杂。框的松紧度要统一：框住灯体发光部分即可，不要把整个灯箱外壳框进去。这一点必须写进标注规范，因为不同人标出来的松紧不一致，模型学到的边界会很模糊，检测框抖动会很明显。
还有一个坑：箭头灯和圆形灯要不要分开标？如果只是做基础识别，建议先不区分，统一按颜色标，否则类别数翻倍、样本需求也翻倍。等基础版本跑通了，再考虑加箭头方向这个维度。
2.3 数据增强：针对交通灯场景的定制策略
通用增强（翻转、缩放、色彩抖动）当然要用，但交通灯场景有几个特殊增强值得单独设计。亮度对比度扰动要做得比常规更激进，模拟逆光和夜间；运动模糊要加，模拟车载抖动；马赛克增强（Mosaic）对小目标检测帮助很大，因为它把多张图拼在一起，变相增加了小目标的出现频率。但要注意，颜色相关的增强不能过头——你把红灯的色调抖到偏橙，模型就学不到准确的颜色特征了，所以HSV增强里H通道的幅度要收着点，S和V可以放开。
我一般用的增强组合是：Mosaic（概率0.5）、随机缩放（0.5到1.5）、HSV扰动（H±10，S±30，V±30）、随机亮度对比度、轻微运动模糊。这套组合在自采数据上实测比默认增强的mAP高3到5个点，主要提升来自小目标召回。
3. 模型选型：为什么我最终落在YOLO系而不是两阶段
选型这件事，网上争论很多，但放到毕业设计这个约束条件下，答案其实比较明确。两阶段检测器（如Faster R-CNN系）精度上限高，但训练慢、显存吃紧、部署麻烦，对一个要在有限算力上跑通并演示的项目来说性价比不高。YOLO系单阶段检测器在速度和精度之间平衡得好，生态成熟，预训练权重多，改起来也方便，是这类项目最务实的选择。
3.1 版本选择的现实考量
YOLOv5、v8、v10、v11都有人用，我的建议是：优先选你环境里能稳定跑起来、文档最全的那个版本，而不是盲目追新。v5的生态最成熟，改网络结构、加注意力模块的教程最多，适合需要"做出改动"来体现工作量的毕设；v8及以后版本在工程化上更完善，训练脚本和导出流程更顺。如果你只是想稳稳跑通，v8是个不错的折中。
这里有个容易被忽略的点：交通灯是小目标，模型输入的分辨率比版本更重要。默认640的输入对远处交通灯来说太小了，把输入提到960甚至1280，小目标召回会有肉眼可见的提升，代价是显存和推理时间上升。我的做法是训练时用960，部署时如果算力允许也保持960，实在不行再降。
3.2 针对小目标的网络改动
如果要在结构上做点文章（毕设通常需要），针对交通灯最有效的改动集中在特征融合层。交通灯目标小，靠的是浅层高分辨率特征图，但浅层语义弱，所以要加强浅层和深层的融合。具体做法可以是：在PANet结构里增加一条从更浅层引出的融合路径，或者引入一个轻量的注意力模块（如CBAM）加在特征融合之后，让网络更关注灯体区域。
我不建议一上来就大改主干网络，收益不确定还容易训崩。先把融合层和注意力这块做扎实，配合高输入分辨率，小目标问题基本能解决大半。实测下来，加CBAM到融合层之后，小目标（面积小于32×32像素）的召回率能提升4到6个点，这个提升在演示时是能看出来的。
3.3 损失函数与分类头的微调
交通灯类别少（4类），但类别极不平衡——大部分时间是绿灯或红灯，黄灯和灭灯样本很少。直接训会导致模型对少数类不敏感。解决办法有两个：一是在损失里对少数类加权，二是采样时对含黄灯、灭灯的帧做上采样。我倾向后者，因为改采样比改损失更直观、更好调。
分类头这块，如果发现红绿混淆严重（实际中确实常见），可以考虑把颜色判断从纯分类改成分类加颜色空间辅助约束，比如在损失里加一项对预测框内像素平均色相的约束。这个做法稍微进阶，但效果确实有，尤其对逆光场景。
4. 训练调参：那些让指标从"能跑"到"能用"的细节
模型结构定了，训练过程才是真正拉开差距的地方。我见过太多人用默认超参训完就交，指标卡在mAP 0.6上下上不去，然后怀疑是模型不行。其实大部分时候是训练策略没调对。
4.1 学习率与预热
交通灯数据集通常不大（几千张量级），从头训容易过拟合，所以必须用预训练权重。在预训练基础上微调时，学习率不能照搬从头训的设置，一般用1e-3到1e-4量级，配合余弦退火或阶梯衰减。预热（warmup）对小数据集微调很重要，前几个epoch用很小的学习率把分类头"焐热"，能明显减少训练初期的震荡。
我踩过的一个坑是：一开始学习率设太大，训到第3个epoch loss直接炸了，模型输出全变成同一类。后来把初始学习率降到3e-4、加3个epoch的warmup，训练曲线就平滑多了。这个参数没有万能值，但小数据集微调时"宁小勿大"是稳妥原则。
4.2 正负样本分配与置信度阈值
YOLO系的正负样本分配策略直接影响小目标的召回。默认策略下，小目标因为和anchor匹配度低，容易被判成负样本，导致漏检。如果用的是较新版本，可以调整分配阈值让更多小目标参与正样本；老版本则可以通过调整anchor尺寸来适配交通灯的小尺度分布。这一步建议先用聚类方法统计一下你数据集里交通灯框的宽高分布，再据此设anchor，比默认anchor效果好不少。
推理时的置信度阈值也要调。默认0.25对交通灯来说偏低，会引入大量误检（车尾灯、圆形标志）；调到0.4到0.5之间通常更合适。但这个值要在验证集上扫一遍确定，不能拍脑袋。
4.3 训练监控：看什么指标
别只盯着mAP。交通灯项目里，我更关注三个数：小目标召回率、各类别AP（尤其黄灯和灭灯）、混淆矩阵。混淆矩阵能直接告诉你红绿是不是在互串，这比一个总mAP有用得多。如果发现绿灯被大量判成红灯，那问题多半在颜色特征学习上，回头去查数据增强和分类损失。
训练轮数上，小数据集一般50到100个epoch就收敛了，配合早停（验证集指标连续若干轮不升就停）。训太久只会过拟合，验证集指标反而掉。
5. 部署与演示：让系统真的"跑起来"
模型训完只是半成品，能演示、能交互才算完整系统。这部分往往被毕设忽视，但恰恰是答辩时最出彩的地方。
5.1 推理加速与框架选择
如果只是本地演示，PyTorch直接推理就够了，配上GPU能到实时。如果要部署到边缘设备或者追求更快的CPU推理，可以导出成ONNX再转TensorRT或OpenVINO。导出时注意输入尺寸和动态batch的设置，交通灯检测一般固定输入尺寸就行，动态尺寸反而增加复杂度。
我一般会准备两条推理路径：一条PyTorch原生的用于调试和对比，一条导出的用于演示。导出后一定要做数值一致性校验，确认导出模型和原模型在同一张图上的输出差异在可接受范围内，否则可能出现"训练时好好的，部署后全错"的尴尬。
5.2 演示界面的最小可用设计
演示界面不用花哨，但要能体现系统能力。最小可用版本包含：视频/摄像头输入、实时检测框叠加、状态标签显示、以及一个简单的统计面板（当前帧检测到的交通灯数量、各状态计数）。用OpenCV就能搭起来，不需要前端框架。
有个细节值得做：把检测结果按置信度着色，高置信度用实线框、低置信度用虚线框，这样演示时观众能直观感受到模型的不确定性，也显得你对系统有掌控。
5.3 常见演示翻车点
演示翻车最多的三个场景：一是夜间画面，模型没在夜间数据上充分训练，一进隧道或天黑就失效；二是远距离小目标，演示视频里交通灯太远，框不出来；三是多灯同框，一个画面里出现多个交通灯时，后处理逻辑没写好，决策信号乱跳。前两个靠数据和分辨率解决，第三个靠后处理逻辑的鲁棒性设计——比如加一个时间维度的平滑，连续几帧结果一致才输出决策，避免单帧误检导致信号闪烁。
6. 几个我反复踩过的坑和对应的解法
最后集中说几个具体问题，都是我在实际做这类项目时真实遇到过的，写出来省得你再走一遍。
坑一：把车尾灯当交通灯。这是误检的头号来源。解法是在负样本里专门加入大量含车尾灯、路灯、圆形广告牌的图像，让模型学会区分。光靠调阈值治标不治本。
坑二：标注框抖动导致训练不稳。同一批数据不同人标，框的松紧不一致，模型学到的边界模糊。解法是制定标注规范并做交叉校验，抽10%的样本让两个人重复标，算一下IoU一致性，低于0.85就返工统一标准。
坑三：验证集和训练集同分布，指标虚高。随机划分数据集会让同一段视频的相邻帧同时出现在训练和验证集里，指标虚高但实际泛化差。正确做法是按视频片段划分，保证验证集的场景和训练集不重叠，这样测出来的指标才可信。
坑四：忽略黄灯和灭灯。这两类样本少，模型容易忽略。除了上采样，还可以在评估时单独看这两类的AP，别被总mAP掩盖了问题。
坑五：后处理逻辑写死。比如硬编码"取面积最大的框作为主灯"，遇到远近两个灯同时出现就出错。后处理要考虑多灯场景，用置信度加权或位置先验来选主灯，而不是简单取最大。
这套流程走下来，一个能稳定演示、指标说得过去的交通灯识别系统基本就成型了。真正决定成败的从来不是用了多新的模型，而是数据质量、任务定义和那些琐碎但关键的工程细节。我个人的体会是，把80%的精力花在数据和评估上，剩下20%花在模型上，最终效果反而比反过来好得多。
