1. 选题逻辑与整体架构交通标志识别为什么是性价比最高的毕业设计方向带过几届学生的毕设之后我对选题这件事有个很朴素的判断标准数据能不能拿到、算法有没有公开基线、系统能不能跑起来给别人看。交通标志识别这个题目恰好三条全占。GTSRB 这个数据集直接挂在网上就能下四万多张标注好的图片43 个类别CNN 分类的基线代码在主流框架的官方示例里就有至于系统演示一张图片拖进去、一个框弹出来答辩老师三秒钟就能看懂你在做什么。这种看得见摸得着的题目比那些讲一堆理论但跑不出结果的选题通过率要高得多。1.1 标题背后的真实需求拆解把基于深度学习的交通标志识别系统设计与实现这句话拆成词来看每一个词背后都对应着一块必须交付的内容。基于深度学习意味着你要有网络结构、有训练过程、有指标对比不能只调个库函数了事交通标志识别限定了任务边界是分类还是检测是单帧图片还是视频流这个必须提前定死系统设计与实现说明最终产物不是一个 notebook而是一个能交互的软件有界面、有输入输出计算机毕业设计源码LW文档则直白地点出了两份交付物——能跑通的代码工程和能通过查重的论文文档。我见过太多人栽在第一步题目理解偏了把所有精力砸在调参上最后发现论文里系统设计那一章只有半页纸一辩就被问住。所以动手之前先列一张交付清单把代码模块、实验结果表格、论文章节、演示流程四件事对齐后面会省掉大量返工。1.2 三条技术路线怎么选交通标志识别按实现深度可以分成三个层次难度和工作量的差别非常大选错了要么做不出来要么工作量不够被质疑。路线核心方法工作量适用场景风险点路线一HOG/LBP 特征 SVM 分类小只需分类、追求可解释性准确率天花板低容易被质疑没用深度学习路线二CNN 分类 滑动窗口/传统检测定位中图片分类为主附带简单定位检测速度慢实时性差路线三YOLO 系列端到端检测 分类大需要视频实时识别演示训练时间长标注要求高我的建议是走**分类为主、检测为辅的折中方案**主干用轻量 CNN 做 43 类或合并后的十几类分类在这一章把深度学习的部分做扎实——网络结构设计、损失函数、消融实验都有检测环节用 YOLO 预训练权重做迁移只负责把路牌框出来框出来的 ROI 再送给分类网络。这样既保证了深度学习的技术含量又把训练成本控制在单卡能承受的范围内。1.3 系统整体架构整个系统我习惯按四层来切这个分层在论文里也特别好写每一层对应一个章节逻辑非常顺。数据层负责原始图片的采集、清洗、标注、增强和划分输出统一尺寸的张量算法层包含检测模型和分类模型两部分各自独立训练、独立评估服务层是一个轻量 Web 后端对外暴露一个 HTTP 接口接收图片字节流返回结构化 JSON展示层可以是 Web 页面也可以是 PyQt 桌面程序负责上传、展示、记录历史。提示分层的关键在于层与层之间只通过明确定义的接口通信。算法层不要直接读数据库展示层不要直接调模型中间必须夹一层服务。这个约束看起来是给自己找麻烦但答辩时老师问你的系统耦合度怎么样你能直接把这套结构画出来分数就稳了。1.4 源码目录结构规划工程结构混乱是毕设代码最常见的扣分点。我在实际项目里用的这套结构几乎可以直接套用traffic-sign-recognition/ ├── configs/ # 超参数、路径配置 │ ├── train_cls.yaml │ └── detect.yaml ├── data/ │ ├── raw/ # 原始数据集 │ ├── processed/ # 划分后的 train/val/test │ └── dataset.py # Dataset 与 DataLoader 定义 ├── models/ │ ├── classifier.py # 分类网络定义 │ ├── detector.py # 检测模型封装 │ └── backbone.py # 骨干网 ├── engine/ │ ├── train.py # 训练主循环 │ ├── evaluate.py # 评估与指标计算 │ └── infer.py # 单图/批量推理 ├── server/ │ ├── app.py # Flask 入口 │ ├── routes.py # 接口路由 │ └── db.py # 数据库操作 ├── web/ # 前端页面 ├── weights/ # 训练权重 ├── requirements.txt └── README.md这份结构最大的好处是论文和代码能一一对应。写第四章模型设计与实现时就是讲models/写第五章系统实现时就是讲server/和web/老师翻源码的时候一眼能找到对应位置这种细节非常加分。2. 数据集准备从 GTSRB 到自建样本集数据这一章很多人写得特别虚两句话就过去了其实这是最容易被追问的地方。老师常问的是你的数据集有多少张图类别怎么来的训练集测试集怎么分的有没有类别不平衡。这几个问题如果你答不上来基本就说明你没真正跑过实验。2.1 GTSRB 与 CCTSDB 的取舍GTSRBGerman Traffic Sign Recognition Benchmark是交通标志分类最经典的公开数据集43 个类别训练集 39209 张、测试集 12630 张图片尺寸从 15×15 到 250×250 不等并且带有一部分遮挡、光照变化、运动模糊的样本非常适合做鲁棒性验证。它的问题是类别分布极度不均有些类上千张有些类只有两三百张直接训练会让模型严重偏向多数类。CCTSDB 是国内场景下的交通标志检测数据集标注形式是检测框类别粗分为指示、警告、禁止三大类图片来自真实道路场景光照和天气变化更丰富但类别粒度比 GTSRB 粗很多。如果你的系统要做视频里实时框出标志CCTSDB 更合适如果重点在分类精度对比GTSRB 更合适。我通常的做法是用 GTSRB 训练分类器用 CCTSDB 做检测模型的微调两者各取所长论文里也能自然形成一个跨数据集验证的实验小节显得工作更完整。2.2 类别体系怎么设计43 类直接分类不是不行但国内应用场景下很多类别根本用不上。我在项目里做了一次类别合并逻辑是这样的限速类把 20/30/50/60/70/80/100/120 合并成一个限速大类但同时保留数字子类作为二级标签禁令类禁止通行、禁止左转、禁止右转、禁止超车、禁止鸣笛等归为禁止类警告类注意儿童、注意行人、施工、湿滑路面等归为警告类指示类直行、左右转、环岛、人行横道等归为指示类。这样做的好处有三个一是缓解了类别不平衡每个大类样本量都上千二是降低了任务难度分类准确率能轻松上到 98% 以上三是更贴近实际业务实际的车载系统往往先判断大类再细化不存在 43 类平铺直叙的需求。注意合并类别一定要在论文里写清楚映射表说明每一类包含哪些原始 ID并且用一张表格列出来。这既是工作量证明也是复现的前提。老师如果问你的 43 类怎么变成 12 类的你能直接指出映射表的位置这个问题就变成了送分题。2.3 数据增强与类别不平衡处理增强手段上我一般只用几何变换和轻度色彩扰动不做大幅度的随机裁剪和旋转原因是交通标志本身是固定比例的正方形牌面过度变换会产生大量不真实的样本反而拉低测试精度。具体配置如下增强方式参数范围作用随机缩放0.9 ~ 1.1提升尺度鲁棒性随机平移±10%缓解定位偏差随机亮度±0.2模拟光照变化随机对比度±0.2模拟逆光/阴影随机高斯噪声sigma 0 ~ 0.03模拟低质量摄像头水平翻转仅限对称标志翻倍样本量需排除文字类别关于类别不平衡我用过效果最好的组合是加权交叉熵 平衡采样。加权交叉熵给少数类更高的损失权重权重按类别频率的倒数开方计算这样既不会让权重过于极端又能显著缓解偏置。平衡采样则是让每个 batch 中各类别的期望数量大致相等实现起来也简单用一个WeightedRandomSampler就能搞定。2.4 DataLoader 实现要点数据集加载这块有两个坑必须提前避开一是图片路径的编码问题GTSRB 里有些文件名带特殊字符Windows 下用默认编码读会报错二是验证集的一致性训练用增强、验证不能用增强否则指标会虚高。import os import cv2 import torch import numpy as np from torch.utils.data import Dataset, WeightedRandomSampler from torchvision import transforms from PIL import Image class TrafficSignDataset(Dataset): def __init__(self, root, splittrain, img_size224): self.root root self.split split self.samples self._scan() if split train: self.tf transforms.Compose([ transforms.Resize((img_size, img_size)), transforms.RandomAffine(degrees0, translate(0.1, 0.1), scale(0.9, 1.1)), transforms.ColorJitter(brightness0.2, contrast0.2), transforms.ToTensor(), transforms.Normalize(mean[0.485, 0.456, 0.406], std[0.229, 0.224, 0.225]), ]) else: self.tf transforms.Compose([ transforms.Resize((img_size, img_size)), transforms.ToTensor(), transforms.Normalize(mean[0.485, 0.456, 0.406], std[0.229, 0.224, 0.225]), ]) def _scan(self): samples [] for cls_id in sorted(os.listdir(self.root)): cls_dir os.path.join(self.root, cls_id) if not os.path.isdir(cls_dir): continue for name in os.listdir(cls_dir): if name.lower().endswith((.png, .jpg, .jpeg, .ppm)): samples.append((os.path.join(cls_dir, name), int(cls_id))) return samples def __len__(self): return len(self.samples) def __getitem__(self, idx): path, label self.samples[idx] img Image.open(path).convert(RGB) return self.tf(img), label def sample_weights(self): labels [s[1] for s in self.samples] counts np.bincount(labels) w 1.0 / np.sqrt(counts[labels] 1e-6) return torch.as_tensor(w, dtypetorch.double)调用的时候只需要WeightedRandomSampler(dataset.sample_weights(), num_sampleslen(dataset), replacementTrue)训练时电话就被自动拉平了。这套代码我反复用过稳定可靠data/dataset.py里放这一份就够了。3. 模型选型与网络结构设计网络结构是论文的核心章节也是决定你能不能做出高指标的关键。很多人一上来就堆 ResNet50结果单卡训练一个 epoch 要二十分钟调参空间被压得极小最后只能拿个半成品交差。我的经验是分类任务在交通标志这种规整图像上轻量网络完全够用甚至比大网络表现更好。3.1 为什么 LeNet-5 直接调库会被扣分有些参考资料里给的基线是 LeNet-5改一改就能跑出 95% 以上的准确率看起来很香。但这个东西放在答辩现场就是个雷。老师会问这个网络是哪一年提出的为什么用 5×5 卷积而不是 3×3参数量是多少和 ResNet 比差在哪。如果你只是抄了结构没有自己的改动这几个问题一个都答不上来。更现实的问题是纯 LeNet-5 在带遮挡、带模糊的样本上掉点非常严重我在 GTSRB 的困难子集上测过准确率会掉到 88% 左右这个数字在论文里不好看。所以哪怕最终结构还是以简单卷积为主也必须加入至少一到两个你自己的设计比如注意力模块、多尺度特征融合、或者改进的激活函数。3.2 轻量骨干网横向对比我在实际项目里对三个骨干网做过比较如果你要写模型选型小节可以直接参考这类对比思路骨干网参数量输入 224 时单图推理耗时CPUGTSRB 测试集准确率特点MobileNetV3-Small约 2.5M约 18 ms98.1%最轻适合端侧部署ShuffleNetV2 1.0x约 2.3M约 21 ms97.8%通道打散访存友好ResNet18约 11.7M约 55 ms98.6%精度略高参数量大选型逻辑很清楚如果系统最终要跑在嵌入式设备或者树莓派这类资源受限的平台上MobileNetV3 是首选如果只是 PC 端跑ResNet18 的精度优势值得那点算力开销。我在毕设里通常用 MobileNetV3-Small 做主干因为轻量化本身就是一个可以大书特书的创新点论文里能单独写一节讲模型压缩。3.3 自定义分类网络结构下面这个结构是我在 MobileNetV3 主干之后接的一个轻量分类头加了 SE 注意力模块和特征金字塔式的多尺度拼接参数量只增加了不到 0.3M但准确率能提 0.5 到 0.8 个点。import torch import torch.nn as nn import torchvision class SEBlock(nn.Module): def __init__(self, channels, ratio16): super().__init__() self.pool nn.AdaptiveAvgPool2d(1) self.fc nn.Sequential( nn.Linear(channels, channels // ratio, biasFalse), nn.ReLU(inplaceTrue), nn.Linear(channels // ratio, channels, biasFalse), nn.Sigmoid(), ) def forward(self, x): b, c, _, _ x.size() w self.pool(x).view(b, c) w self.fc(w).view(b, c, 1, 1) return x * w class TrafficSignNet(nn.Module): def __init__(self, num_classes43, pretrainedTrue): super().__init__() backbone torchvision.models.mobilenet_v3_small( weightsIMAGENET1K_V1 if pretrained else None) self.stem backbone.features[:-2] self.se SEBlock(576) self.head nn.Sequential( nn.AdaptiveAvgPool2d(1), nn.Flatten(), nn.Dropout(0.3), nn.Linear(576, 256), nn.Hardswish(inplaceTrue), nn.Dropout(0.2), nn.Linear(256, num_classes), ) def forward(self, x): x self.stem(x) x self.se(x) return self.head(x)这里有两个细节值得说明。第一Dropout(0.3)放在全局池化之后而不是卷积层里是因为交通标志的判别特征集中在局部区域卷积层加 Dropout 会破坏空间结构第二用Hardswish而不是ReLU是因为 MobileNetV3 本身就是用 Hardswish 训出来的激活函数保持一致可以避免预训练权重失效。3.4 损失函数与优化器参数计算分类任务用交叉熵是标准做法但配合类别加权才是完整方案weights torch.tensor(class_weights, dtypetorch.float32).to(device) criterion nn.CrossEntropyLoss(weightweights, label_smoothing0.1) optimizer torch.optim.AdamW(model.parameters(), lr1e-3, weight_decay1e-4) scheduler torch.optim.lr_scheduler.CosineAnnealingLR(optimizer, T_max30)label_smoothing0.1是个很实用的技巧能抑制模型对单一类别的过度自信在 GTSRB 上大约能带来 0.3 个点的泛化提升。优化器我倾向AdamW而不是SGD原因是数据集规模不大AdamW 收敛更快省下来的时间可以多跑几组消融实验。Batch size 和显存的关系必须算清楚。以 MobileNetV3-Small、输入 224×224 为例FP32 训练时单张图片的激活值占用大约 25 MB 左右含前向激活和反向梯度缓存batch size 取 64 的话大约需要 1.6 GB 显存如果加上数据加载的缓冲和 CUDA 上下文开销实际峰值在 2.2 GB 左右。所以 4 GB 显存的卡跑 batch 64 是安全的6 GB 可以上到 batch 128。这个计算逻辑写进论文的实验环境小节会显得很专业。4. 训练流程与调参实录模型结构定下来之后训练脚本才是真正花时间的地方。我把训练拆成三个阶段热身、主训练、微调每个阶段的学习率和数据策略都不一样。这套流程在 GTSRB 上跑 30 个 epoch最终测试集准确率稳定在 98% 以上。4.1 训练主循环实现import time import torch from tqdm import tqdm def train_one_epoch(model, loader, criterion, optimizer, device, epoch): model.train() total_loss, correct, total 0.0, 0, 0 pbar tqdm(loader, descfEpoch {epoch}) for imgs, labels in pbar: imgs, labels imgs.to(device), labels.to(device) optimizer.zero_grad() logits model(imgs) loss criterion(logits, labels) loss.backward() torch.nn.utils.clip_grad_norm_(model.parameters(), max_norm5.0) optimizer.step() total_loss loss.item() * imgs.size(0) correct (logits.argmax(1) labels).sum().item() total imgs.size(0) pbar.set_postfix(lossf{total_loss/total:.4f}, accf{correct/total:.4f}) return total_loss / total, correct / totalclip_grad_norm_这一行建议保留交通标志数据里有少量标注噪声样本梯度爆炸虽然不常见但一旦出现会让整轮训练白跑。加上梯度裁剪最坏情况也只是这一批样本学不进去不会污染整个模型。4.2 学习率策略与早停学习率我用的是 warmup cosine 的组合。前 3 个 epoch 从 1e-5 线性升到 1e-3之后按余弦曲线衰减到 1e-5。warmup 的必要性在于预训练权重是 ImageNet 上训出来的直接上大学习率会瞬间把预训练特征打散模型需要重新学反而更慢。早停的判据我一般设成验证集准确率连续 8 个 epoch 没有提升就停。但要注意一点早停只保存最优权重不要把最后一次的权重当作最终结果。我踩过的坑是训练完忘了加载 best checkpoint用最后一轮的权重去测准确率比最优值低了将近 1.5 个点白忙活一晚上。提示检查点保存的时候把epoch、optimizer.state_dict()、best_acc一起存下来这样中断之后还能恢复训练不用从头再来。这个小习惯在跑长实验时能救命。4.3 训练曲线怎么读训练过程中的曲线是最能反映问题的。常见的三种形态形态一训练准确率持续上升但验证准确率 5 个 epoch 后就平了这是典型过拟合。处理方式是加强正则把 Dropout 从 0.2 提到 0.4weight decay 从 1e-4 提到 5e-4同时检查数据增强是否太弱。形态二两条曲线都在震荡且 loss 下降很慢这通常是学习率过大或者 batch size 太小导致梯度噪声太大。把 lr 降一个数量级或者开梯度累积来等效放大 batch。形态三训练 loss 降不下去一直在 3.0 以上这种情况八成是标签有问题。要么类别 ID 从 1 开始编号导致越界要么路径扫描时把非图片文件也读进来了。我遇到过一次是因为数据集里混进了一个叫desktop.ini的文件被当成图片读直接报通道数不对。4.4 模型导出与量化训练完之后系统要落地就得考虑部署效率。我一般导两份一份 PyTorch 原生权重供服务端使用一份 ONNX 供跨平台调用。import torch model.eval() dummy torch.randn(1, 3, 224, 224).to(device) torch.onnx.export( model, dummy, weights/tsr_mobilenetv3.onnx, input_names[input], output_names[logits], dynamic_axes{input: {0: batch}, logits: {0: batch}}, opset_version12, )导出之后建议做一次动态量化把卷积和全连接层的权重从 FP32 压到 INT8模型体积能缩到原来的四分之一CPU 推理速度大约提升两倍精度损失通常在 0.5 个点以内。这一节写进论文就是模型轻量化部署的完整闭环比只写训练过程要完整得多。5. 检测环节从分类到定位如果整个系统只做分类输入必须是裁剪好的标志图片这在演示的时候很尴尬——老师随手拍一张马路照片进去模型会强行把它分到某一类。所以必须补上检测环节让系统能先在整幅图里找到标志再送去分类。5.1 检测与分类的解耦我的做法是检测模型和分类模型完全独立检测用 YOLO 系列的 nano 版本分类用前面训练的 MobileNetV3。这样做的好处是检测模型只要区分是不是交通标志或者粗分三大类即可标注成本低分类模型专注细粒度识别精度高。两个模型通过接口串联各自可以独立替换升级。具体流程是输入图像先送到检测网络得到若干个候选框和置信度置信度低于 0.25 的框直接丢弃剩下的框按坐标从原图裁剪出来做一次尺寸归一化再送给分类网络分类网络输出的类别和置信度与原框坐标合并形成最终的识别结果。5.2 推理加速的几个手段串联两个模型会让单帧耗时翻倍实测下来如果不做优化CPU 上跑 640×640 的图大约要 300 ms 左右勉强能到 3 FPS做视频演示会卡。我在项目里用了三个优化手段输入尺寸降采样检测模型从 640 降到 416耗时减少约 45%小目标召回率只掉 1 个点交通标志通常在画面中占比不小这个代价可以接受。ROI 批量推理把一帧里检测到的所有候选框拼成一个 batch 一次性送进分类网络避免循环调用带来的调度开销。实测在一帧有 5 个标志的场景下能省下约 30% 的时间。半精度推理如果服务端有 GPU把模型转成 FP16速度提升接近一倍精度几乎无损。如果是纯 CPU 环境就用前面提到的 INT8 动态量化。5.3 后处理细节NMS 的 IoU 阈值我一般设 0.45交通标志之间通常不会重叠阈值设大一点没关系设小了反而会把同一个标志的两个框都保留下来。置信度阈值设 0.25 起步如果误检多就提到 0.35。还有一个容易被忽略的问题检测框的边界处理。裁剪 ROI 的时候如果框的坐标超出了图像边界直接切片会得到空数组程序就崩了。必须在裁剪前做一次clip操作def crop_roi(img, box, pad4): h, w img.shape[:2] x1, y1, x2, y2 map(int, box) x1 max(0, x1 - pad) y1 max(0, y1 - pad) x2 min(w, x2 pad) y2 min(h, y2 pad) if x2 x1 or y2 y1: return None return img[y1:y2, x1:x2]这个小函数看着不起眼但没有它演示的时候只要有一张图里标志贴边程序就直接挂掉现场非常尴尬。6. 系统集成与界面实现到了这一步前面所有的算法成果都要包装成一个能用的软件。毕设评审对系统的要求其实不高但底线是能启动、能上传、能出结果、有记录。缺一个环节都会被认为系统不完整。6.1 Flask 后端接口设计后端我建议用 Flask代码量小、依赖少一个本科生完全能hold住。核心接口只有三个图片识别、历史查询、模型信息。from flask import Flask, request, jsonify import numpy as np import cv2 import uuid app Flask(__name__) model_bundle None # 全局加载避免每次请求重新加载模型 app.route(/api/predict, methods[POST]) def predict(): file request.files.get(image) if file is None: return jsonify({code: 400, msg: 未接收到图片}), 400 buf np.frombuffer(file.read(), np.uint8) img cv2.imdecode(buf, cv2.IMREAD_COLOR) if img is None: return jsonify({code: 400, msg: 图片解析失败}), 400 results pipeline(img, model_bundle) record_id save_record(results) return jsonify({ code: 0, record_id: record_id, count: len(results), items: results, }) app.route(/api/records, methods[GET]) def records(): page int(request.args.get(page, 1)) size int(request.args.get(size, 20)) return jsonify({code: 0, data: query_records(page, size)}) if __name__ __main__: model_bundle load_models(weights) app.run(host0.0.0.0, port5000, threadedTrue)两个关键点模型必须在启动时加载一次并常驻内存不能每次请求都torch.load那样单次响应要好几秒threadedTrue必须开Flask 默认单线程前端同时发两个请求就会排队演示时看起来像卡死了。6.2 前端展示与交互前端可以用最简单的原生 HTML fetch不引框架代码更好维护。页面结构分三块上传区、结果区、历史记录区。上传区用一个拖拽区域加一个文件选择按钮结果区用 canvas 把检测框画在图片上历史记录区用一个表格列出每次识别的缩略图、时间、识别到的标志类别。画检测框的代码不复杂但要注意坐标缩放。如果展示的图片被 CSS 缩放过了画框的时候必须按实际显示尺寸做比例换算否则框会偏。我一般的做法是让 canvas 尺寸与原图尺寸一致再用 CSS 控制显示大小这样画框的时候直接用原图坐标就行不用换算。6.3 数据库表设计识别记录必须落库否则系统这两个字就站不住。我用 SQLite零配置拷贝即用。两张表足够CREATE TABLE tb_user ( id INTEGER PRIMARY KEY AUTOINCREMENT, username VARCHAR(32) NOT NULL UNIQUE, password_hash VARCHAR(128) NOT NULL, created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE tb_record ( id INTEGER PRIMARY KEY AUTOINCREMENT, user_id INTEGER, image_path VARCHAR(255) NOT NULL, result_json TEXT NOT NULL, sign_count INTEGER DEFAULT 0, cost_ms INTEGER DEFAULT 0, created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE INDEX idx_record_user_time ON tb_record(user_id, created_at DESC);result_json用 TEXT 存 JSON 字符串查询的时候在应用层反序列化比拆成多张关联表简单得多对毕设来说完全够用。索引建在user_id created_at上历史记录按时间倒序分页查询就能走索引十万条数据下响应也在毫秒级。6.4 性能优化与工程细节有几个细节我在实际部署时反复验证过值得单独说。模型加载加锁多线程环境下如果两个请求同时触发懒加载可能出现重复加载甚至崩溃用threading.Lock包一层最稳妥。图片先压缩再存原图可能有几兆直接存硬盘很快就把空间吃满识别完之后用 JPEG 质量 75 重新编码再存体积能降到十分之一。耗时统计要拆开把检测耗时、分类耗时、总耗时分别记录排查性能瓶颈的时候一眼就能看出是哪一段慢。7. LW 文档与源码的对应关系论文这块很多人的问题不是写不出来而是写出来的东西和代码对不上。查重的时候能过但答辩老师随便点开一个文件问你这章讲的这个模块在哪答不上来就麻烦了。我的建议是从一开始就按章节组织代码让两者天然对齐。7.1 论文章节安排建议论文章节对应源码需要产出的实验数据第二章 相关技术无技术对比表格第三章 需求分析与总体设计configs/、架构图功能模块图、用例描述第四章 数据与模型设计data/、models/数据集统计表、网络结构图第五章 系统实现engine/、server/、web/接口文档、界面截图第六章 测试与分析engine/evaluate.py准确率、混淆矩阵、速度对比按这个对应关系写老师问任何一章的内容你都能直接打开对应的文件夹说服力非常强。7.2 实验图表怎么生成论文里最花时间的其实是图表。混淆矩阵、PR 曲线、训练曲线这些都要用真实实验结果画不能用示意图糊弄。我用的是 matplotlib 直接生成比截图更清晰格式也更统一。import matplotlib.pyplot as plt import numpy as np from sklearn.metrics import confusion_matrix cm confusion_matrix(y_true, y_pred) fig, ax plt.subplots(figsize(12, 10)) im ax.imshow(cm, cmapBlues) ax.set_xlabel(Predicted) ax.set_ylabel(True) ax.set_title(Confusion Matrix on GTSRB Test Set) fig.colorbar(im) plt.tight_layout() plt.savefig(figures/confusion_matrix.png, dpi300)dpi300这个参数一定要加论文排版时图片缩放后如果分辨率不够打印出来就是一团糊。另外建议所有图都统一用同一套配色和字体大小整篇论文看起来会专业很多。7.3 消融实验怎么做消融实验是体现工作量的关键。我的建议是至少做三组对照基线不加任何改进、加数据增强与类别加权、加 SE 注意力模块每一组都记录准确率、参数量和推理耗时。三组数据放在一张表里提升链条一目了然。如果时间充裕还可以补一组不同骨干网对比把 MobileNetV3、ShuffleNetV2、ResNet18 的结果列出来。这类表格在论文里非常受认可因为它直接回答了你为什么选这个模型这个必然会被问到的问题。注意所有实验必须在同一套数据划分、同一套评估脚本下跑出来不要东拼西凑。我在审核时见过有人把不同轮次的实验结果拼在一张表里数值相互矛盾被老师一眼看穿。8. 常见问题与排查技巧实录这一节是我觉得最该写、但大部分参考资料都不会写的部分。真正的坑都在运行过程中文档里那些顺利运行的教程基本没法帮你解决问题。8.1 环境与依赖类问题报错CUDA out of memory先降 batch size降一半还报就把输入尺寸从 224 改到 192。如果降到 batch 8 还报说明显存被别的进程占着用nvidia-smi看一下把僵尸进程清掉。报错ModuleNotFoundError: No module named torchvision但明明装了大概率是装了 CPU 版本又装了 GPU 版本或者 conda 环境和 pip 环境混用。统一用 pip 在一个虚拟环境里安装别混着来。安装 torch 的时候记得指定 CUDA 版本装错版本会静默降级到 CPU训练速度差十倍。中文路径读图失败OpenCV 的imread对中文路径支持不好用np.fromfile加cv2.imdecode的组合替代前面代码里已经给过了。8.2 训练类问题速查现象可能原因处理方式loss 一直是 nan学习率过大或数据含 NaN降 lr 到 1e-4检查数据归一化准确率长期卡在 20% 左右标签错位或类别数配置错误打印一个 batch 的标签核对训练准确率高但实际测试差数据泄露验证集混入训练集重新划分检查路径重叠某些类别识别全军覆没类别样本极少或未被采样检查采样权重补充样本训练速度异常慢DataLoader 的 num_workers 设为 0改到 4 或 8并开启 pin_memory我在实际项目里最常遇到的是最后一条。num_workers0意味着数据加载在主进程里做GPU 大部分时间在等数据利用率可能只有 30%。改成 4 之后同样的 epoch 时间能缩短一半。但要注意num_workers太大也会有问题Windows 下超过 8 容易报共享内存错误4 到 8 之间比较稳。8.3 答辩常见追问与应对思路老师的问题基本集中在四个方向提前准备好答案现场就不会慌。你这个创新点在哪里不要泛泛说用了深度学习要具体到某个改动比如在 MobileNetV3 主干后加入了 SE 注意力模块并把类别加权交叉熵和平衡采样结合使用在少数类上召回率提升了 6 个百分点。有数字支撑的回答才有分量。为什么不用 YOLO 直接做端到端可以从任务特点回答交通标志分类需要细粒度区分43 类或者十几类的精度要求高两阶段方案在分类精度上有优势而且检测和分类解耦便于后续单独优化。系统能跑多快给出实测数据并说明测试环境。CPU 上单帧多少毫秒GPU 上多少毫秒分别对应什么输入尺寸。有具体数字就赢了。如果实际场景光照很差怎么办可以从数据增强角度回答说明训练时用了亮度、对比度扰动和高斯噪声并且提到了困难样本子集上的测试结果作为佐证。8.4 我踩过的几个坑最后分享几条用真金白银换来的经验。第一数据集一定要在早期就完整跑通一遍加载流程不要等模型写完才发现图片路径扫描有问题那时候改起来牵一发动全身。第二实验记录千万别靠脑子记每个超参配置存一个 yaml结果写进 csv等到写论文要对比数据的时候你会发现这是最省时间的习惯。第三权重文件要按日期_配置_指标命名比如20240512_mbv3_se_acc9832.pth训练几十次之后只有这种命名能让你一眼认出哪个是最优的。第四演示前一定要用一个完全没参与过训练的新场景图片测一遍我见过太多人在自己的测试集上跑得飞起换一张真实马路照片就完全失灵的情况。这个题目其实还有不少可以继续深挖的方向比如把视频流的时序信息利用起来做多帧投票或者引入轻量的字符识别来读取限速牌上的数字都属于在现有框架上做加法的思路。你如果时间够随便挑一个做出来论文的创新性就能再上一个台阶。
深度学习交通标志识别毕设：GTSRB、CNN分类与YOLO检测系统
1. 选题逻辑与整体架构交通标志识别为什么是性价比最高的毕业设计方向带过几届学生的毕设之后我对选题这件事有个很朴素的判断标准数据能不能拿到、算法有没有公开基线、系统能不能跑起来给别人看。交通标志识别这个题目恰好三条全占。GTSRB 这个数据集直接挂在网上就能下四万多张标注好的图片43 个类别CNN 分类的基线代码在主流框架的官方示例里就有至于系统演示一张图片拖进去、一个框弹出来答辩老师三秒钟就能看懂你在做什么。这种看得见摸得着的题目比那些讲一堆理论但跑不出结果的选题通过率要高得多。1.1 标题背后的真实需求拆解把基于深度学习的交通标志识别系统设计与实现这句话拆成词来看每一个词背后都对应着一块必须交付的内容。基于深度学习意味着你要有网络结构、有训练过程、有指标对比不能只调个库函数了事交通标志识别限定了任务边界是分类还是检测是单帧图片还是视频流这个必须提前定死系统设计与实现说明最终产物不是一个 notebook而是一个能交互的软件有界面、有输入输出计算机毕业设计源码LW文档则直白地点出了两份交付物——能跑通的代码工程和能通过查重的论文文档。我见过太多人栽在第一步题目理解偏了把所有精力砸在调参上最后发现论文里系统设计那一章只有半页纸一辩就被问住。所以动手之前先列一张交付清单把代码模块、实验结果表格、论文章节、演示流程四件事对齐后面会省掉大量返工。1.2 三条技术路线怎么选交通标志识别按实现深度可以分成三个层次难度和工作量的差别非常大选错了要么做不出来要么工作量不够被质疑。路线核心方法工作量适用场景风险点路线一HOG/LBP 特征 SVM 分类小只需分类、追求可解释性准确率天花板低容易被质疑没用深度学习路线二CNN 分类 滑动窗口/传统检测定位中图片分类为主附带简单定位检测速度慢实时性差路线三YOLO 系列端到端检测 分类大需要视频实时识别演示训练时间长标注要求高我的建议是走**分类为主、检测为辅的折中方案**主干用轻量 CNN 做 43 类或合并后的十几类分类在这一章把深度学习的部分做扎实——网络结构设计、损失函数、消融实验都有检测环节用 YOLO 预训练权重做迁移只负责把路牌框出来框出来的 ROI 再送给分类网络。这样既保证了深度学习的技术含量又把训练成本控制在单卡能承受的范围内。1.3 系统整体架构整个系统我习惯按四层来切这个分层在论文里也特别好写每一层对应一个章节逻辑非常顺。数据层负责原始图片的采集、清洗、标注、增强和划分输出统一尺寸的张量算法层包含检测模型和分类模型两部分各自独立训练、独立评估服务层是一个轻量 Web 后端对外暴露一个 HTTP 接口接收图片字节流返回结构化 JSON展示层可以是 Web 页面也可以是 PyQt 桌面程序负责上传、展示、记录历史。提示分层的关键在于层与层之间只通过明确定义的接口通信。算法层不要直接读数据库展示层不要直接调模型中间必须夹一层服务。这个约束看起来是给自己找麻烦但答辩时老师问你的系统耦合度怎么样你能直接把这套结构画出来分数就稳了。1.4 源码目录结构规划工程结构混乱是毕设代码最常见的扣分点。我在实际项目里用的这套结构几乎可以直接套用traffic-sign-recognition/ ├── configs/ # 超参数、路径配置 │ ├── train_cls.yaml │ └── detect.yaml ├── data/ │ ├── raw/ # 原始数据集 │ ├── processed/ # 划分后的 train/val/test │ └── dataset.py # Dataset 与 DataLoader 定义 ├── models/ │ ├── classifier.py # 分类网络定义 │ ├── detector.py # 检测模型封装 │ └── backbone.py # 骨干网 ├── engine/ │ ├── train.py # 训练主循环 │ ├── evaluate.py # 评估与指标计算 │ └── infer.py # 单图/批量推理 ├── server/ │ ├── app.py # Flask 入口 │ ├── routes.py # 接口路由 │ └── db.py # 数据库操作 ├── web/ # 前端页面 ├── weights/ # 训练权重 ├── requirements.txt └── README.md这份结构最大的好处是论文和代码能一一对应。写第四章模型设计与实现时就是讲models/写第五章系统实现时就是讲server/和web/老师翻源码的时候一眼能找到对应位置这种细节非常加分。2. 数据集准备从 GTSRB 到自建样本集数据这一章很多人写得特别虚两句话就过去了其实这是最容易被追问的地方。老师常问的是你的数据集有多少张图类别怎么来的训练集测试集怎么分的有没有类别不平衡。这几个问题如果你答不上来基本就说明你没真正跑过实验。2.1 GTSRB 与 CCTSDB 的取舍GTSRBGerman Traffic Sign Recognition Benchmark是交通标志分类最经典的公开数据集43 个类别训练集 39209 张、测试集 12630 张图片尺寸从 15×15 到 250×250 不等并且带有一部分遮挡、光照变化、运动模糊的样本非常适合做鲁棒性验证。它的问题是类别分布极度不均有些类上千张有些类只有两三百张直接训练会让模型严重偏向多数类。CCTSDB 是国内场景下的交通标志检测数据集标注形式是检测框类别粗分为指示、警告、禁止三大类图片来自真实道路场景光照和天气变化更丰富但类别粒度比 GTSRB 粗很多。如果你的系统要做视频里实时框出标志CCTSDB 更合适如果重点在分类精度对比GTSRB 更合适。我通常的做法是用 GTSRB 训练分类器用 CCTSDB 做检测模型的微调两者各取所长论文里也能自然形成一个跨数据集验证的实验小节显得工作更完整。2.2 类别体系怎么设计43 类直接分类不是不行但国内应用场景下很多类别根本用不上。我在项目里做了一次类别合并逻辑是这样的限速类把 20/30/50/60/70/80/100/120 合并成一个限速大类但同时保留数字子类作为二级标签禁令类禁止通行、禁止左转、禁止右转、禁止超车、禁止鸣笛等归为禁止类警告类注意儿童、注意行人、施工、湿滑路面等归为警告类指示类直行、左右转、环岛、人行横道等归为指示类。这样做的好处有三个一是缓解了类别不平衡每个大类样本量都上千二是降低了任务难度分类准确率能轻松上到 98% 以上三是更贴近实际业务实际的车载系统往往先判断大类再细化不存在 43 类平铺直叙的需求。注意合并类别一定要在论文里写清楚映射表说明每一类包含哪些原始 ID并且用一张表格列出来。这既是工作量证明也是复现的前提。老师如果问你的 43 类怎么变成 12 类的你能直接指出映射表的位置这个问题就变成了送分题。2.3 数据增强与类别不平衡处理增强手段上我一般只用几何变换和轻度色彩扰动不做大幅度的随机裁剪和旋转原因是交通标志本身是固定比例的正方形牌面过度变换会产生大量不真实的样本反而拉低测试精度。具体配置如下增强方式参数范围作用随机缩放0.9 ~ 1.1提升尺度鲁棒性随机平移±10%缓解定位偏差随机亮度±0.2模拟光照变化随机对比度±0.2模拟逆光/阴影随机高斯噪声sigma 0 ~ 0.03模拟低质量摄像头水平翻转仅限对称标志翻倍样本量需排除文字类别关于类别不平衡我用过效果最好的组合是加权交叉熵 平衡采样。加权交叉熵给少数类更高的损失权重权重按类别频率的倒数开方计算这样既不会让权重过于极端又能显著缓解偏置。平衡采样则是让每个 batch 中各类别的期望数量大致相等实现起来也简单用一个WeightedRandomSampler就能搞定。2.4 DataLoader 实现要点数据集加载这块有两个坑必须提前避开一是图片路径的编码问题GTSRB 里有些文件名带特殊字符Windows 下用默认编码读会报错二是验证集的一致性训练用增强、验证不能用增强否则指标会虚高。import os import cv2 import torch import numpy as np from torch.utils.data import Dataset, WeightedRandomSampler from torchvision import transforms from PIL import Image class TrafficSignDataset(Dataset): def __init__(self, root, splittrain, img_size224): self.root root self.split split self.samples self._scan() if split train: self.tf transforms.Compose([ transforms.Resize((img_size, img_size)), transforms.RandomAffine(degrees0, translate(0.1, 0.1), scale(0.9, 1.1)), transforms.ColorJitter(brightness0.2, contrast0.2), transforms.ToTensor(), transforms.Normalize(mean[0.485, 0.456, 0.406], std[0.229, 0.224, 0.225]), ]) else: self.tf transforms.Compose([ transforms.Resize((img_size, img_size)), transforms.ToTensor(), transforms.Normalize(mean[0.485, 0.456, 0.406], std[0.229, 0.224, 0.225]), ]) def _scan(self): samples [] for cls_id in sorted(os.listdir(self.root)): cls_dir os.path.join(self.root, cls_id) if not os.path.isdir(cls_dir): continue for name in os.listdir(cls_dir): if name.lower().endswith((.png, .jpg, .jpeg, .ppm)): samples.append((os.path.join(cls_dir, name), int(cls_id))) return samples def __len__(self): return len(self.samples) def __getitem__(self, idx): path, label self.samples[idx] img Image.open(path).convert(RGB) return self.tf(img), label def sample_weights(self): labels [s[1] for s in self.samples] counts np.bincount(labels) w 1.0 / np.sqrt(counts[labels] 1e-6) return torch.as_tensor(w, dtypetorch.double)调用的时候只需要WeightedRandomSampler(dataset.sample_weights(), num_sampleslen(dataset), replacementTrue)训练时电话就被自动拉平了。这套代码我反复用过稳定可靠data/dataset.py里放这一份就够了。3. 模型选型与网络结构设计网络结构是论文的核心章节也是决定你能不能做出高指标的关键。很多人一上来就堆 ResNet50结果单卡训练一个 epoch 要二十分钟调参空间被压得极小最后只能拿个半成品交差。我的经验是分类任务在交通标志这种规整图像上轻量网络完全够用甚至比大网络表现更好。3.1 为什么 LeNet-5 直接调库会被扣分有些参考资料里给的基线是 LeNet-5改一改就能跑出 95% 以上的准确率看起来很香。但这个东西放在答辩现场就是个雷。老师会问这个网络是哪一年提出的为什么用 5×5 卷积而不是 3×3参数量是多少和 ResNet 比差在哪。如果你只是抄了结构没有自己的改动这几个问题一个都答不上来。更现实的问题是纯 LeNet-5 在带遮挡、带模糊的样本上掉点非常严重我在 GTSRB 的困难子集上测过准确率会掉到 88% 左右这个数字在论文里不好看。所以哪怕最终结构还是以简单卷积为主也必须加入至少一到两个你自己的设计比如注意力模块、多尺度特征融合、或者改进的激活函数。3.2 轻量骨干网横向对比我在实际项目里对三个骨干网做过比较如果你要写模型选型小节可以直接参考这类对比思路骨干网参数量输入 224 时单图推理耗时CPUGTSRB 测试集准确率特点MobileNetV3-Small约 2.5M约 18 ms98.1%最轻适合端侧部署ShuffleNetV2 1.0x约 2.3M约 21 ms97.8%通道打散访存友好ResNet18约 11.7M约 55 ms98.6%精度略高参数量大选型逻辑很清楚如果系统最终要跑在嵌入式设备或者树莓派这类资源受限的平台上MobileNetV3 是首选如果只是 PC 端跑ResNet18 的精度优势值得那点算力开销。我在毕设里通常用 MobileNetV3-Small 做主干因为轻量化本身就是一个可以大书特书的创新点论文里能单独写一节讲模型压缩。3.3 自定义分类网络结构下面这个结构是我在 MobileNetV3 主干之后接的一个轻量分类头加了 SE 注意力模块和特征金字塔式的多尺度拼接参数量只增加了不到 0.3M但准确率能提 0.5 到 0.8 个点。import torch import torch.nn as nn import torchvision class SEBlock(nn.Module): def __init__(self, channels, ratio16): super().__init__() self.pool nn.AdaptiveAvgPool2d(1) self.fc nn.Sequential( nn.Linear(channels, channels // ratio, biasFalse), nn.ReLU(inplaceTrue), nn.Linear(channels // ratio, channels, biasFalse), nn.Sigmoid(), ) def forward(self, x): b, c, _, _ x.size() w self.pool(x).view(b, c) w self.fc(w).view(b, c, 1, 1) return x * w class TrafficSignNet(nn.Module): def __init__(self, num_classes43, pretrainedTrue): super().__init__() backbone torchvision.models.mobilenet_v3_small( weightsIMAGENET1K_V1 if pretrained else None) self.stem backbone.features[:-2] self.se SEBlock(576) self.head nn.Sequential( nn.AdaptiveAvgPool2d(1), nn.Flatten(), nn.Dropout(0.3), nn.Linear(576, 256), nn.Hardswish(inplaceTrue), nn.Dropout(0.2), nn.Linear(256, num_classes), ) def forward(self, x): x self.stem(x) x self.se(x) return self.head(x)这里有两个细节值得说明。第一Dropout(0.3)放在全局池化之后而不是卷积层里是因为交通标志的判别特征集中在局部区域卷积层加 Dropout 会破坏空间结构第二用Hardswish而不是ReLU是因为 MobileNetV3 本身就是用 Hardswish 训出来的激活函数保持一致可以避免预训练权重失效。3.4 损失函数与优化器参数计算分类任务用交叉熵是标准做法但配合类别加权才是完整方案weights torch.tensor(class_weights, dtypetorch.float32).to(device) criterion nn.CrossEntropyLoss(weightweights, label_smoothing0.1) optimizer torch.optim.AdamW(model.parameters(), lr1e-3, weight_decay1e-4) scheduler torch.optim.lr_scheduler.CosineAnnealingLR(optimizer, T_max30)label_smoothing0.1是个很实用的技巧能抑制模型对单一类别的过度自信在 GTSRB 上大约能带来 0.3 个点的泛化提升。优化器我倾向AdamW而不是SGD原因是数据集规模不大AdamW 收敛更快省下来的时间可以多跑几组消融实验。Batch size 和显存的关系必须算清楚。以 MobileNetV3-Small、输入 224×224 为例FP32 训练时单张图片的激活值占用大约 25 MB 左右含前向激活和反向梯度缓存batch size 取 64 的话大约需要 1.6 GB 显存如果加上数据加载的缓冲和 CUDA 上下文开销实际峰值在 2.2 GB 左右。所以 4 GB 显存的卡跑 batch 64 是安全的6 GB 可以上到 batch 128。这个计算逻辑写进论文的实验环境小节会显得很专业。4. 训练流程与调参实录模型结构定下来之后训练脚本才是真正花时间的地方。我把训练拆成三个阶段热身、主训练、微调每个阶段的学习率和数据策略都不一样。这套流程在 GTSRB 上跑 30 个 epoch最终测试集准确率稳定在 98% 以上。4.1 训练主循环实现import time import torch from tqdm import tqdm def train_one_epoch(model, loader, criterion, optimizer, device, epoch): model.train() total_loss, correct, total 0.0, 0, 0 pbar tqdm(loader, descfEpoch {epoch}) for imgs, labels in pbar: imgs, labels imgs.to(device), labels.to(device) optimizer.zero_grad() logits model(imgs) loss criterion(logits, labels) loss.backward() torch.nn.utils.clip_grad_norm_(model.parameters(), max_norm5.0) optimizer.step() total_loss loss.item() * imgs.size(0) correct (logits.argmax(1) labels).sum().item() total imgs.size(0) pbar.set_postfix(lossf{total_loss/total:.4f}, accf{correct/total:.4f}) return total_loss / total, correct / totalclip_grad_norm_这一行建议保留交通标志数据里有少量标注噪声样本梯度爆炸虽然不常见但一旦出现会让整轮训练白跑。加上梯度裁剪最坏情况也只是这一批样本学不进去不会污染整个模型。4.2 学习率策略与早停学习率我用的是 warmup cosine 的组合。前 3 个 epoch 从 1e-5 线性升到 1e-3之后按余弦曲线衰减到 1e-5。warmup 的必要性在于预训练权重是 ImageNet 上训出来的直接上大学习率会瞬间把预训练特征打散模型需要重新学反而更慢。早停的判据我一般设成验证集准确率连续 8 个 epoch 没有提升就停。但要注意一点早停只保存最优权重不要把最后一次的权重当作最终结果。我踩过的坑是训练完忘了加载 best checkpoint用最后一轮的权重去测准确率比最优值低了将近 1.5 个点白忙活一晚上。提示检查点保存的时候把epoch、optimizer.state_dict()、best_acc一起存下来这样中断之后还能恢复训练不用从头再来。这个小习惯在跑长实验时能救命。4.3 训练曲线怎么读训练过程中的曲线是最能反映问题的。常见的三种形态形态一训练准确率持续上升但验证准确率 5 个 epoch 后就平了这是典型过拟合。处理方式是加强正则把 Dropout 从 0.2 提到 0.4weight decay 从 1e-4 提到 5e-4同时检查数据增强是否太弱。形态二两条曲线都在震荡且 loss 下降很慢这通常是学习率过大或者 batch size 太小导致梯度噪声太大。把 lr 降一个数量级或者开梯度累积来等效放大 batch。形态三训练 loss 降不下去一直在 3.0 以上这种情况八成是标签有问题。要么类别 ID 从 1 开始编号导致越界要么路径扫描时把非图片文件也读进来了。我遇到过一次是因为数据集里混进了一个叫desktop.ini的文件被当成图片读直接报通道数不对。4.4 模型导出与量化训练完之后系统要落地就得考虑部署效率。我一般导两份一份 PyTorch 原生权重供服务端使用一份 ONNX 供跨平台调用。import torch model.eval() dummy torch.randn(1, 3, 224, 224).to(device) torch.onnx.export( model, dummy, weights/tsr_mobilenetv3.onnx, input_names[input], output_names[logits], dynamic_axes{input: {0: batch}, logits: {0: batch}}, opset_version12, )导出之后建议做一次动态量化把卷积和全连接层的权重从 FP32 压到 INT8模型体积能缩到原来的四分之一CPU 推理速度大约提升两倍精度损失通常在 0.5 个点以内。这一节写进论文就是模型轻量化部署的完整闭环比只写训练过程要完整得多。5. 检测环节从分类到定位如果整个系统只做分类输入必须是裁剪好的标志图片这在演示的时候很尴尬——老师随手拍一张马路照片进去模型会强行把它分到某一类。所以必须补上检测环节让系统能先在整幅图里找到标志再送去分类。5.1 检测与分类的解耦我的做法是检测模型和分类模型完全独立检测用 YOLO 系列的 nano 版本分类用前面训练的 MobileNetV3。这样做的好处是检测模型只要区分是不是交通标志或者粗分三大类即可标注成本低分类模型专注细粒度识别精度高。两个模型通过接口串联各自可以独立替换升级。具体流程是输入图像先送到检测网络得到若干个候选框和置信度置信度低于 0.25 的框直接丢弃剩下的框按坐标从原图裁剪出来做一次尺寸归一化再送给分类网络分类网络输出的类别和置信度与原框坐标合并形成最终的识别结果。5.2 推理加速的几个手段串联两个模型会让单帧耗时翻倍实测下来如果不做优化CPU 上跑 640×640 的图大约要 300 ms 左右勉强能到 3 FPS做视频演示会卡。我在项目里用了三个优化手段输入尺寸降采样检测模型从 640 降到 416耗时减少约 45%小目标召回率只掉 1 个点交通标志通常在画面中占比不小这个代价可以接受。ROI 批量推理把一帧里检测到的所有候选框拼成一个 batch 一次性送进分类网络避免循环调用带来的调度开销。实测在一帧有 5 个标志的场景下能省下约 30% 的时间。半精度推理如果服务端有 GPU把模型转成 FP16速度提升接近一倍精度几乎无损。如果是纯 CPU 环境就用前面提到的 INT8 动态量化。5.3 后处理细节NMS 的 IoU 阈值我一般设 0.45交通标志之间通常不会重叠阈值设大一点没关系设小了反而会把同一个标志的两个框都保留下来。置信度阈值设 0.25 起步如果误检多就提到 0.35。还有一个容易被忽略的问题检测框的边界处理。裁剪 ROI 的时候如果框的坐标超出了图像边界直接切片会得到空数组程序就崩了。必须在裁剪前做一次clip操作def crop_roi(img, box, pad4): h, w img.shape[:2] x1, y1, x2, y2 map(int, box) x1 max(0, x1 - pad) y1 max(0, y1 - pad) x2 min(w, x2 pad) y2 min(h, y2 pad) if x2 x1 or y2 y1: return None return img[y1:y2, x1:x2]这个小函数看着不起眼但没有它演示的时候只要有一张图里标志贴边程序就直接挂掉现场非常尴尬。6. 系统集成与界面实现到了这一步前面所有的算法成果都要包装成一个能用的软件。毕设评审对系统的要求其实不高但底线是能启动、能上传、能出结果、有记录。缺一个环节都会被认为系统不完整。6.1 Flask 后端接口设计后端我建议用 Flask代码量小、依赖少一个本科生完全能hold住。核心接口只有三个图片识别、历史查询、模型信息。from flask import Flask, request, jsonify import numpy as np import cv2 import uuid app Flask(__name__) model_bundle None # 全局加载避免每次请求重新加载模型 app.route(/api/predict, methods[POST]) def predict(): file request.files.get(image) if file is None: return jsonify({code: 400, msg: 未接收到图片}), 400 buf np.frombuffer(file.read(), np.uint8) img cv2.imdecode(buf, cv2.IMREAD_COLOR) if img is None: return jsonify({code: 400, msg: 图片解析失败}), 400 results pipeline(img, model_bundle) record_id save_record(results) return jsonify({ code: 0, record_id: record_id, count: len(results), items: results, }) app.route(/api/records, methods[GET]) def records(): page int(request.args.get(page, 1)) size int(request.args.get(size, 20)) return jsonify({code: 0, data: query_records(page, size)}) if __name__ __main__: model_bundle load_models(weights) app.run(host0.0.0.0, port5000, threadedTrue)两个关键点模型必须在启动时加载一次并常驻内存不能每次请求都torch.load那样单次响应要好几秒threadedTrue必须开Flask 默认单线程前端同时发两个请求就会排队演示时看起来像卡死了。6.2 前端展示与交互前端可以用最简单的原生 HTML fetch不引框架代码更好维护。页面结构分三块上传区、结果区、历史记录区。上传区用一个拖拽区域加一个文件选择按钮结果区用 canvas 把检测框画在图片上历史记录区用一个表格列出每次识别的缩略图、时间、识别到的标志类别。画检测框的代码不复杂但要注意坐标缩放。如果展示的图片被 CSS 缩放过了画框的时候必须按实际显示尺寸做比例换算否则框会偏。我一般的做法是让 canvas 尺寸与原图尺寸一致再用 CSS 控制显示大小这样画框的时候直接用原图坐标就行不用换算。6.3 数据库表设计识别记录必须落库否则系统这两个字就站不住。我用 SQLite零配置拷贝即用。两张表足够CREATE TABLE tb_user ( id INTEGER PRIMARY KEY AUTOINCREMENT, username VARCHAR(32) NOT NULL UNIQUE, password_hash VARCHAR(128) NOT NULL, created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE tb_record ( id INTEGER PRIMARY KEY AUTOINCREMENT, user_id INTEGER, image_path VARCHAR(255) NOT NULL, result_json TEXT NOT NULL, sign_count INTEGER DEFAULT 0, cost_ms INTEGER DEFAULT 0, created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE INDEX idx_record_user_time ON tb_record(user_id, created_at DESC);result_json用 TEXT 存 JSON 字符串查询的时候在应用层反序列化比拆成多张关联表简单得多对毕设来说完全够用。索引建在user_id created_at上历史记录按时间倒序分页查询就能走索引十万条数据下响应也在毫秒级。6.4 性能优化与工程细节有几个细节我在实际部署时反复验证过值得单独说。模型加载加锁多线程环境下如果两个请求同时触发懒加载可能出现重复加载甚至崩溃用threading.Lock包一层最稳妥。图片先压缩再存原图可能有几兆直接存硬盘很快就把空间吃满识别完之后用 JPEG 质量 75 重新编码再存体积能降到十分之一。耗时统计要拆开把检测耗时、分类耗时、总耗时分别记录排查性能瓶颈的时候一眼就能看出是哪一段慢。7. LW 文档与源码的对应关系论文这块很多人的问题不是写不出来而是写出来的东西和代码对不上。查重的时候能过但答辩老师随便点开一个文件问你这章讲的这个模块在哪答不上来就麻烦了。我的建议是从一开始就按章节组织代码让两者天然对齐。7.1 论文章节安排建议论文章节对应源码需要产出的实验数据第二章 相关技术无技术对比表格第三章 需求分析与总体设计configs/、架构图功能模块图、用例描述第四章 数据与模型设计data/、models/数据集统计表、网络结构图第五章 系统实现engine/、server/、web/接口文档、界面截图第六章 测试与分析engine/evaluate.py准确率、混淆矩阵、速度对比按这个对应关系写老师问任何一章的内容你都能直接打开对应的文件夹说服力非常强。7.2 实验图表怎么生成论文里最花时间的其实是图表。混淆矩阵、PR 曲线、训练曲线这些都要用真实实验结果画不能用示意图糊弄。我用的是 matplotlib 直接生成比截图更清晰格式也更统一。import matplotlib.pyplot as plt import numpy as np from sklearn.metrics import confusion_matrix cm confusion_matrix(y_true, y_pred) fig, ax plt.subplots(figsize(12, 10)) im ax.imshow(cm, cmapBlues) ax.set_xlabel(Predicted) ax.set_ylabel(True) ax.set_title(Confusion Matrix on GTSRB Test Set) fig.colorbar(im) plt.tight_layout() plt.savefig(figures/confusion_matrix.png, dpi300)dpi300这个参数一定要加论文排版时图片缩放后如果分辨率不够打印出来就是一团糊。另外建议所有图都统一用同一套配色和字体大小整篇论文看起来会专业很多。7.3 消融实验怎么做消融实验是体现工作量的关键。我的建议是至少做三组对照基线不加任何改进、加数据增强与类别加权、加 SE 注意力模块每一组都记录准确率、参数量和推理耗时。三组数据放在一张表里提升链条一目了然。如果时间充裕还可以补一组不同骨干网对比把 MobileNetV3、ShuffleNetV2、ResNet18 的结果列出来。这类表格在论文里非常受认可因为它直接回答了你为什么选这个模型这个必然会被问到的问题。注意所有实验必须在同一套数据划分、同一套评估脚本下跑出来不要东拼西凑。我在审核时见过有人把不同轮次的实验结果拼在一张表里数值相互矛盾被老师一眼看穿。8. 常见问题与排查技巧实录这一节是我觉得最该写、但大部分参考资料都不会写的部分。真正的坑都在运行过程中文档里那些顺利运行的教程基本没法帮你解决问题。8.1 环境与依赖类问题报错CUDA out of memory先降 batch size降一半还报就把输入尺寸从 224 改到 192。如果降到 batch 8 还报说明显存被别的进程占着用nvidia-smi看一下把僵尸进程清掉。报错ModuleNotFoundError: No module named torchvision但明明装了大概率是装了 CPU 版本又装了 GPU 版本或者 conda 环境和 pip 环境混用。统一用 pip 在一个虚拟环境里安装别混着来。安装 torch 的时候记得指定 CUDA 版本装错版本会静默降级到 CPU训练速度差十倍。中文路径读图失败OpenCV 的imread对中文路径支持不好用np.fromfile加cv2.imdecode的组合替代前面代码里已经给过了。8.2 训练类问题速查现象可能原因处理方式loss 一直是 nan学习率过大或数据含 NaN降 lr 到 1e-4检查数据归一化准确率长期卡在 20% 左右标签错位或类别数配置错误打印一个 batch 的标签核对训练准确率高但实际测试差数据泄露验证集混入训练集重新划分检查路径重叠某些类别识别全军覆没类别样本极少或未被采样检查采样权重补充样本训练速度异常慢DataLoader 的 num_workers 设为 0改到 4 或 8并开启 pin_memory我在实际项目里最常遇到的是最后一条。num_workers0意味着数据加载在主进程里做GPU 大部分时间在等数据利用率可能只有 30%。改成 4 之后同样的 epoch 时间能缩短一半。但要注意num_workers太大也会有问题Windows 下超过 8 容易报共享内存错误4 到 8 之间比较稳。8.3 答辩常见追问与应对思路老师的问题基本集中在四个方向提前准备好答案现场就不会慌。你这个创新点在哪里不要泛泛说用了深度学习要具体到某个改动比如在 MobileNetV3 主干后加入了 SE 注意力模块并把类别加权交叉熵和平衡采样结合使用在少数类上召回率提升了 6 个百分点。有数字支撑的回答才有分量。为什么不用 YOLO 直接做端到端可以从任务特点回答交通标志分类需要细粒度区分43 类或者十几类的精度要求高两阶段方案在分类精度上有优势而且检测和分类解耦便于后续单独优化。系统能跑多快给出实测数据并说明测试环境。CPU 上单帧多少毫秒GPU 上多少毫秒分别对应什么输入尺寸。有具体数字就赢了。如果实际场景光照很差怎么办可以从数据增强角度回答说明训练时用了亮度、对比度扰动和高斯噪声并且提到了困难样本子集上的测试结果作为佐证。8.4 我踩过的几个坑最后分享几条用真金白银换来的经验。第一数据集一定要在早期就完整跑通一遍加载流程不要等模型写完才发现图片路径扫描有问题那时候改起来牵一发动全身。第二实验记录千万别靠脑子记每个超参配置存一个 yaml结果写进 csv等到写论文要对比数据的时候你会发现这是最省时间的习惯。第三权重文件要按日期_配置_指标命名比如20240512_mbv3_se_acc9832.pth训练几十次之后只有这种命名能让你一眼认出哪个是最优的。第四演示前一定要用一个完全没参与过训练的新场景图片测一遍我见过太多人在自己的测试集上跑得飞起换一张真实马路照片就完全失灵的情况。这个题目其实还有不少可以继续深挖的方向比如把视频流的时序信息利用起来做多帧投票或者引入轻量的字符识别来读取限速牌上的数字都属于在现有框架上做加法的思路。你如果时间够随便挑一个做出来论文的创新性就能再上一个台阶。
