尧图网站建设 
简介本资源是面向大学生人工智能竞赛选手的实战型备赛资料包聚焦中国计算机设计大赛人工智能挑战赛核心赛题涵盖移动物体检测、口罩识别、疲劳检测、安全帽识别等典型CV应用场景提供从模型训练YOLOv3、数据预处理到结果可视化的一站式解决方案。压缩包共55个文件含15个可直接运行的Python主程序与工具脚本如train_voc.py、predict.py、show_yolo_anno.py、8个配置文件.cfg/.names、7个数据相关文件、6个演示GIF动图及结构化说明文档README.md、LICENSE整体体积55.4MB目录组织清晰模块职责分明便于快速定位与二次开发。已有114人学习下载所有源码均经实测验证支持开箱即用并附带竞赛总结与工程实践要点助力参赛者理解技术选型逻辑、规避常见部署陷阱、提升答辩材料组织能力。 国二这套东西说实话代码本身的价值远没有大家想象得那么高真正值钱的是选择方案时的思路、踩坑之后的权衡、以及答辩台上那几分钟怎么把工作讲清楚。这篇文章我就把从选题到答辩的完整链路拆开聊包括源码目录怎么组织、训练时那些坑具体长什么样、答辩被追问最多的问题是什么以及一些在获奖名单里看不到的细节。1. 先搞懂这场比赛的“游戏规则”1.1 比赛分层与评审逻辑中国计算机设计大赛人工智能挑战赛全国赛的评审材料通常包含五样东西作品说明书、演示视频、答辩PPT、可运行的源代码、以及必要的部署说明文档。很多人以为代码写完就结束了实际上在国赛评审体系里代码只是下限说明书写得是否清楚、视频演示是否流畅、现场答辩能不能扛住追问才是和同水平队伍拉开差距的地方。评分权重上从我和评委的私下交流以及赛后公布的分项成绩来看大致是创新性与实用价值占三成左右技术难度和实现完整度占三成系统演示与答辩表现占四成。也就是说你代码再漂亮如果视频录得模糊、答辩结结巴巴一样拿不到好成绩。反过来一个技术含量中等但展示做得干净利落的项目名次往往比预想中更高。1.2 赛道的真实构成很多人误以为“人工智能挑战赛”只有一个赛道其实它有多个子方向比如边缘智能应用、多模态信息处理、智能视觉识别、自然语言处理应用等。每个子方向下又有若干道赛题题目发布时会给一个基础数据集和一个基线模型然后要求在这个基础上做方案创新或性能提升。我当时的选题落在智能视觉方向赛题关键词是“复杂场景下的车辆属性识别”。官方给了大概两万张车辆图片每张图需要输出车身的颜色、车型类别、车辆朝向这三个属性。这题目听起来不算难但实际上有个很恶心的坑官方提供的训练集类别分布极不均衡深色车辆数量是白色车辆的好几倍SUV的数量远多于跑车和皮卡这直接导致前期模型在少数类上表现惨不忍睹。2. 选题定生死技术方案反而不是最难的2.1 为什么选“车辆属性识别”而不是“通用目标检测”组队初期我们其实纠结过两个方向一个是直接做通用目标检测另一个是做属性识别。通用目标检测赛道报名人数最多开源资源也最丰富看起来似乎更好出成果。但和指导老师聊过一轮之后我们决定避开热门赛道去选属性识别原因有三。第一目标检测赛道竞争太激烈裁判对效果的心理预期已经被前几年的优秀作品拉得很高想拿高分必须有明显的创新点。第二属性识别领域虽然也有开源方案但大多数论文关注的是单属性识别多属性联合建模的资料相对少反而更容易做出差异化。第三车辆属性识别有非常明确的落地场景比如智慧交通、停车场管理、安防布控答辩时可以非常自然地讲清楚应用价值这一点在评委眼里是加分项。现在回头看选题时避开的那些“热门”恰恰是我们能拿国二的重要原因。能力中上的队伍扎堆的地方内卷只会让分数越来越难看。2.2 官方数据与真实差距官方提供的两万张数据集看起来数量不少但做深度学习的人都清楚这种量级的数据直接训练一个深层网络效果一定很一般。而且官方图片大多是白天、晴天、单一视角拍摄的真实应用场景里会出现夜间、逆光、雨天、遮挡等情况。我们当时做了两件事来补齐这个差距。第一从公开的车辆数据集里筛选了另外一万张图片专门挑选官方案例中较少的夜间和侧面角度样本做数据补充。第二自己写了一个数据增强pipeline在做随机裁剪、随机翻转、颜色抖动这些常规操作之外增加了一个亮度扰动区间设在0.6到1.4之间专门模拟天亮前和天黑后的光照条件。这里有个值得注意的细节增广策略不能闭着眼睛猛加。我们早期把旋转角度设到30度结果车型识别准确率反而下降了因为车辆图片旋转太多之后形状信息被破坏模型学到了一些奇怪的伪特征。最后把旋转角度限制在10度以内问题就消失了。2.3 标注那些事工欲善其事必先利其器官方给的图片是有标注的但补充的样本需要自己标。数据标注是很多人会轻视的环节真正做起来才发现标一晚上图比训练一晚上模型还累。三个属性加起来每张图平均要标三轮一万张补充图我们三个人标了整整四天。工具用的是LabelImg和一款国产的标注软件前者用于画目标框后者用于填属性标签。两条铁律要记住一是标注规范必须提前写好颜色属性这一项就统一了“颜色深浅判断标准”避免不同人标的标签打架二是标注完成后要做一致性抽检我们当时随机抽了5%的图片人工复查发现了一个反复出现的标注错误——红色和橙色在某些光照条件下容易被混淆后来把这些样本单独拎出来重新标模型的混淆率才降下来。3. 模型选型与训练心法不要盲目追新3.1 主干网络与检测头的选择车辆属性识别这个任务本质上可以拆成两步先定位车辆区域再对区域内的图像做属性分类。因此整个系统天然分成检测模块和分类模块。检测模块我们直接采用了YOLOv8没有自己从头设计任何网络结构。理由非常朴素YOLOv8在目标检测上已经足够成熟社区资料多调参方便而且自带TensorRT导出支持。在国产边缘设备上测试转成TensorRT之后一张640x640的推理时间能压到30毫秒左右这个性能足够满足实时的需求。分类模块这里多讲两句。我们比较了ResNet50、EfficientNet-B3和ConvNeXt-Tiny三个候选模型。最终选择ResNet50作为主干不是因为它是三个里最好的而是因为它最“稳”。EfficientNet理论上FLOPs更低但在我们自己补的小数据集上验证精度并没有超过ResNet50ConvNeXt精度最好可是训练收敛速度慢需要更细的调参习惯不利于我们有限的时间预算。模型参数量验证集准确率训练耗时部署难度ResNet5025.6M92.3%4小时低EfficientNet-B312.3M91.8%4.5小时中ConvNeXt-Tiny28.6M93.1%7小时中3.2 多任务学习一次前向同时输出三个属性车辆颜色、车型、朝向这三个属性如果用三个独立的分类器分别处理训练简单但推理时要做三次前向计算而且三个头之间无法共享特征信息。我们最终采用了多任务学习的方案检测到车辆区域后把区域图像输入一个主干网络然后在网络末端分出三个分类头分别输出颜色11类、车型8类和朝向4类的预测结果。这样做的好处一是共享特征让模型学到更通用的车辆表征颜色分类头在训练时学到的特征也能帮助车型分类头二是推理时一次前向就拿到全部结果实测在边缘设备上单车辆属性识别只需约15毫秒完全满足实时性要求三是网络整体的参数量比三个独立模型小得多部署更友好。多任务学习唯一要小心的是loss权重平衡。最开始我们三个分支都直接用交叉熵结果颜色分支loss下降很快但车型分支一直上不去。原因很明显颜色分类相对简单梯度大主导了整个网络的更新方向。解决方案是给三个loss分别乘上权重系数颜色分支设为0.4车型分支设为0.4朝向分支设为0.2。调整之后车型分支的收敛速度明显加快。3.3 训练策略迁移学习、学习率与关键调参记录模型初始化方面我们使用了ImageNet上的预训练权重作为起点这是计算机视觉任务的标准做法能大幅缩短模型收敛时间。训练时先冻结backbone前40层只训练后面的分类头部分跑20个epoch之后再解冻全部层用更低的学习率对整个网络做微调。优化器选择了AdamW初始学习率设为1e-4weight decay设为1e-4。batch size在单张RTX 3090上设为32。训练总轮数80个epoch在第40和第60个epoch时分别把学习率降低到原来的0.1倍。还有一个比较关键的处理针对类别不均衡问题我们没有采用复杂的采样器而是借鉴了Focal Loss的思路在分类头里把标准的交叉熵换成带权重的版本。给样本量少的类别比如皮卡、橙色车身提高了损失权重权重值直接按“总样本数 / (类别数 x 该类样本数)”来算效果立竿见影少数类的召回率提升了大约14个百分点。4. 源码组织能拿给评委看的代码长什么样4.1 目录结构与模块划分“竞赛资料源码”这个东西评委看的不只是能不能跑而是代码组织是否体现工程素养。我们最终提交的源码目录长这样vehicle-attribute-recognition/ ├── checkpoints/ # 训练好的模型权重 ├── configs/ # 配置文件 │ ├── train_config.yaml │ └── deploy_config.yaml ├── data/ # 数据加载与预处理 │ ├── dataset.py │ └── augmentations.py ├── models/ # 模型定义 │ ├── detector.py │ └── attribute_head.py ├── scripts/ # 训练与推理脚本 │ ├── train.py │ ├── infer.py │ └── export_onnx.py ├── web_demo/ # Web展示端 │ ├── app.py │ └── templates/ └── requirements.txt每个目录都有独立的README.md说明文件对模块职责、输入输出格式、依赖环境都做了描述。这个细节在答辩时被评委专门表扬过说“代码组织得像正经项目而不是课程作业”。4.2 训练脚本的核心逻辑训练脚本是整个源码的核心我在这里贴一段简化但保留了关键逻辑的代码感兴趣的同学可以直接参考import torch import torch.nn as nn from torch.utils.data import DataLoader from models.detector import get_detector from models.attribute_head import AttributeHead def train_one_epoch(model, loader, optimizer, criterion, device): model.train() total_loss 0.0 for images, targets in loader: images images.to(device) color_labels targets[color].to(device) type_labels targets[type].to(device) direction_labels targets[direction].to(device) # 前向推理返回 (B, 11), (B, 8), (B, 4) color_logits, type_logits, dir_logits model(images) # 多任务损失权重经验值0.4 / 0.4 / 0.2 loss 0.4 * criterion(color_logits, color_labels) \ 0.4 * criterion(type_logits, type_labels) \ 0.2 * criterion(dir_logits, direction_labels) optimizer.zero_grad() loss.backward() # 梯度裁剪防止训练初期loss爆炸 nn.utils.clip_grad_norm_(model.parameters(), max_norm5.0) optimizer.step() total_loss loss.item() return total_loss / len(loader)这里面最值得关注的是权重参数0.4 / 0.4 / 0.2和梯度裁剪。前者解决的是多任务间的梯度竞争问题后者解决的是训练初期模型输出不稳定导致梯度爆炸的问题。没有这两个细节训练过程不会这么顺畅。4.3 推理Pipeline怎么把模型跑成真正的系统训练只是项目的一部分最终演示需要通过Web界面展示效果。我们用Flask搭建了一个轻量级Web应用用户上传一张车辆图片后端依次执行目标检测、车辆区域裁剪、多属性分类最后把识别结果叠加在原图上并返回。这里有一个容易被忽略的工程问题检测模型和分类模型需要“接力”运行检测模型输出的是未归一化的坐标值直接传给分类模型会出问题。解决方案是在检测输出后接了一个坐标归一化步骤把已经裁剪出来的车辆区域缩放到224x224再做归一化到[0, 1]区间的张量转换。import cv2 import torch import numpy as np def infer_single_image(model, image_path, device): # 读取图片 img cv2.imread(image_path) img_rgb cv2.cvtColor(img, cv2.COLOR_BGR2RGB) # 预处理缩放 转Tensor 归一化 resized cv2.resize(img_rgb, (224, 224)) tensor torch.from_numpy(resized).permute(2, 0, 1).float() tensor tensor / 255.0 tensor tensor.unsqueeze(0).to(device) # 推理 model.eval() with torch.no_grad(): color_logits, type_logits, dir_logits model(tensor) # 后处理argmax 映射为可读标签 color_id torch.argmax(color_logits, dim1).item() type_id torch.argmax(type_logits, dim1).item() dir_id torch.argmax(dir_logits, dim1).item() return { color: COLOR_LABELS[color_id], type: TYPE_LABELS[type_id], direction: DIRECTION_LABELS[dir_id] }如果准备复现建议直接把这段代码替换成自己的标签映射表不要照抄类的顺序否则会出现“模型输出绿色代码显示蓝色”这种搞笑但致命的bug我们团队在开发阶段就遇到过。5. 从省赛到国赛那些在实验室熬夜踩过的坑5.1 类别不均衡少数类几乎全军覆没第一次完整训练结束验证集上颜色分类的准确率到了91%当时的我们非常兴奋。但把混淆矩阵拉出来一看就傻眼了橙色车辆的召回率只有37%白色车辆的召回率只有52%大量少数类样本被误判成了黑色或灰色。造成这个问题的根本原因是官方数据集中深色车辆占比超过65%浅色和鲜艳色车辆占比很低。模型在训练时看到的深色样本太多学到了一个“把所有车辆往深色猜”的懒惰策略。解决这个问题花了两天时间。第一给少数类别做过采样让每个batch里面不同颜色的样本数量接近均匀分布。第二如上文提到的给分类loss加上类别权重少数类样本的loss被放大模型必须更认真对待这些样本。两招一起上橙色召回率从37%提升到了82%白色从52%提升到了89%最终颜色分类F1值从0.86提升到了0.91。5.2 过拟合验证集疯狂上涨测试集原地不动训练第50个epoch左右我们发现一个诡异现象验证集loss持续下降模型迭代越来越顺但自己拍的真实场景照片测试时识别结果惨不忍睹。这个问题的原因非常典型——训练集和验证集其实来自同一个官方数据发布源分布高度相似而真实场景的车辆图片在背景、拍摄角度、光照条件上和官方数据差异较大。当时的解决办法一是强化数据增强把前面提到的亮度扰动强度加大同时加入高斯模糊和随机遮挡模拟真实场景中的各种干扰二是采用模型集成用不同随机种子训练了3个模型推理时对三个模型的输出取平均。这两招加起来在自建的真实场景测试集上准确率大约提升了8个百分点。这里想给所有参赛队伍一个建议在省赛和国赛之间一定要自己准备一套“野路子”测试数据它不需要很多几百张就够专门用来验证模型在理想环境之外的泛化能力。评委现场演示时用的图大概率不是官方数据集里的图。5.3 推理速度的极限拉扯从90毫秒压到30毫秒国赛的评审过程中有现场演示环节演示环境只提供一块国产边缘计算开发板性能和普通笔记本差距明显。一开始我们把PyTorch模型直接部署上去单张图片的推理时间接近90毫秒勉强能用但画面有明显卡顿感预期演示效果不太理想。优化分了三步走。第一步把模型导出成ONNX格式去掉PyTorch动态图的额外开销推理时间降到约70毫秒。第二步用开发板自带的深度学习加速库做RT推理大部分算子在硬件上做了优化推理时间降到约45毫秒。第三步压缩输入分辨率检测模块从640x640降到512x512分类模块从224x224降到192x192推理时间进一步降到约30毫秒。部署方式单张推理耗时准确率影响PyTorch 原始90ms无ONNX Runtime70ms无深度学习加速库推理45ms无明显变化加速库 降分辨率30ms降低了0.4%最终选择了第三档和第四档之间的平衡即检测用512x512、分类用224x224推理时间约35毫秒准确率几乎没有损失。这段部署经验后来被写进了作品说明书的技术难点章节答辩时也作为“工程实践能力”的证据。6. 材料制作与答辩决定奖项高度的临门一脚6.1 演示视频录制的关键细节评委看视频的时候心里一直在琢磨一个问题这个系统到底是真能用还是只是跑了几个预置样例所以演示视频的制作原则是必须让人感受到系统的“实时反馈”和“真实操作”。我们录视频时没有用预置好的样例图而是现场拍摄。手机拍摄一张停车场照片立刻传给系统几秒钟后界面上显示出识别结果。整个过程一镜到底没有任何剪辑拼接。视频里特意展示了一个遮挡了约30%车身的车辆图片——系统依然能正确识别——然后在视频旁白里解释为什么能识别是因为训练数据中包含部分遮挡样本。这种“自己给自己出难题然后解出来”的设计在答辩现场获得了不错的反应。6.2 答辩PPT的逻辑线答辩PPT切忌把所有的实验过程、所有调参细节都堆上去评委没有兴趣看你训练了多少轮。我们最终的结构是四页核心内容第一页问题和场景一句话说明这个问题在现实世界中非常重要智慧交通、车辆轨迹追踪、安防布控。第二页方案和技术路线画一张简单的流程图检测模块加多任务分类模块强调为什么设计成两阶段而不是端到端。第三页实验结果和对比一张表格展示各模型在三个子任务上的准确率突出我们方案的优势。第四页应用演示直接放视频和实时截图。答辩时不用背稿但要结合PPT把逻辑讲顺。评委如果要问细节就在那页停留如果评委不深究就快速推进。在几个关键节点留出“可能会被追问”的空间已经准备好答案主动等评委来问。6.3 评委最爱问的问题根据我们的答辩经验和赛后交流评委在人工智能挑战赛中最常问的问题大概是下面几类。第一类为什么用两阶段方案而不是端到端的单阶段方案这个问题考验你对任务本身的思考深度。我们的回答是端到端方案训练复杂度高需要大量精准标注的检测框而我们的任务里车辆定位是相对简单的子问题分开做可以各自优化项目后期维护也更容易。第二类你的模型在极端情况夜间、大雨、极端光照下表现如何这是个很现实的问题。我们如实回答在夜间和雨天场景下准确率会有明显下降但通过补充训练数据和数据增强已经在逐步改善并展示具体数据评委很认可这种坦诚的态度。第三类如果把你的方案用到移动端你还会做哪些优化这个问题考的是工程思维。我们提到可以模型剪枝、知识蒸馏、使用Int8量化甚至可以把检测模型替换成更轻量的模型。评委关注的是你有没有想过而不是你现在是否已经做到了。7. 国二之后源码能给你什么又不能给你什么到这里关于中国计算机设计大赛人工智能挑战赛国家二等奖的全过程复盘基本上讲完了。最后说几句掏心窝子的话。“竞赛资料源码”听起来像是一份打包好的“通关秘籍”但真正拿奖之后回看代码和文档只是整个项目的外皮真正有价值的是当时做技术决策和权衡时的判断逻辑。为什么选ResNet50而不用EfficientNet为什么多任务权重是0.4比0.4比0.2为什么演示视频要一镜到底这些问题的答案没有写在任何一行代码里但它们恰恰是所有项目成败的关键。如果你能拿到国奖的源码我的建议是不要急着跑通它先看懂数据流是怎么走的再看清loss曲线在哪个epoch出现了变化最后看模型在部署时经过了哪些压缩和适配。把这三个问题搞明白对你自己的项目帮助会非常大。尤其想说的是答辩这个环节。很多队伍技术实力很强但到了现场讲不出来被评委一追问就慌最后拿到的名次远低于预期。比赛比的从来不只是代码还有你把自己做的事讲清楚的能力——这种能力在以后工作汇报、项目评审、技术分享中同样重要。如果这篇内容对准备参赛的同学有哪怕一点参考价值也就不算白写了。本文还有配套的精品资源点击获取 国赛国二：车辆属性识别项目从选题到答辩的完整复盘
简介本资源是面向大学生人工智能竞赛选手的实战型备赛资料包聚焦中国计算机设计大赛人工智能挑战赛核心赛题涵盖移动物体检测、口罩识别、疲劳检测、安全帽识别等典型CV应用场景提供从模型训练YOLOv3、数据预处理到结果可视化的一站式解决方案。压缩包共55个文件含15个可直接运行的Python主程序与工具脚本如train_voc.py、predict.py、show_yolo_anno.py、8个配置文件.cfg/.names、7个数据相关文件、6个演示GIF动图及结构化说明文档README.md、LICENSE整体体积55.4MB目录组织清晰模块职责分明便于快速定位与二次开发。已有114人学习下载所有源码均经实测验证支持开箱即用并附带竞赛总结与工程实践要点助力参赛者理解技术选型逻辑、规避常见部署陷阱、提升答辩材料组织能力。 国二这套东西说实话代码本身的价值远没有大家想象得那么高真正值钱的是选择方案时的思路、踩坑之后的权衡、以及答辩台上那几分钟怎么把工作讲清楚。这篇文章我就把从选题到答辩的完整链路拆开聊包括源码目录怎么组织、训练时那些坑具体长什么样、答辩被追问最多的问题是什么以及一些在获奖名单里看不到的细节。1. 先搞懂这场比赛的“游戏规则”1.1 比赛分层与评审逻辑中国计算机设计大赛人工智能挑战赛全国赛的评审材料通常包含五样东西作品说明书、演示视频、答辩PPT、可运行的源代码、以及必要的部署说明文档。很多人以为代码写完就结束了实际上在国赛评审体系里代码只是下限说明书写得是否清楚、视频演示是否流畅、现场答辩能不能扛住追问才是和同水平队伍拉开差距的地方。评分权重上从我和评委的私下交流以及赛后公布的分项成绩来看大致是创新性与实用价值占三成左右技术难度和实现完整度占三成系统演示与答辩表现占四成。也就是说你代码再漂亮如果视频录得模糊、答辩结结巴巴一样拿不到好成绩。反过来一个技术含量中等但展示做得干净利落的项目名次往往比预想中更高。1.2 赛道的真实构成很多人误以为“人工智能挑战赛”只有一个赛道其实它有多个子方向比如边缘智能应用、多模态信息处理、智能视觉识别、自然语言处理应用等。每个子方向下又有若干道赛题题目发布时会给一个基础数据集和一个基线模型然后要求在这个基础上做方案创新或性能提升。我当时的选题落在智能视觉方向赛题关键词是“复杂场景下的车辆属性识别”。官方给了大概两万张车辆图片每张图需要输出车身的颜色、车型类别、车辆朝向这三个属性。这题目听起来不算难但实际上有个很恶心的坑官方提供的训练集类别分布极不均衡深色车辆数量是白色车辆的好几倍SUV的数量远多于跑车和皮卡这直接导致前期模型在少数类上表现惨不忍睹。2. 选题定生死技术方案反而不是最难的2.1 为什么选“车辆属性识别”而不是“通用目标检测”组队初期我们其实纠结过两个方向一个是直接做通用目标检测另一个是做属性识别。通用目标检测赛道报名人数最多开源资源也最丰富看起来似乎更好出成果。但和指导老师聊过一轮之后我们决定避开热门赛道去选属性识别原因有三。第一目标检测赛道竞争太激烈裁判对效果的心理预期已经被前几年的优秀作品拉得很高想拿高分必须有明显的创新点。第二属性识别领域虽然也有开源方案但大多数论文关注的是单属性识别多属性联合建模的资料相对少反而更容易做出差异化。第三车辆属性识别有非常明确的落地场景比如智慧交通、停车场管理、安防布控答辩时可以非常自然地讲清楚应用价值这一点在评委眼里是加分项。现在回头看选题时避开的那些“热门”恰恰是我们能拿国二的重要原因。能力中上的队伍扎堆的地方内卷只会让分数越来越难看。2.2 官方数据与真实差距官方提供的两万张数据集看起来数量不少但做深度学习的人都清楚这种量级的数据直接训练一个深层网络效果一定很一般。而且官方图片大多是白天、晴天、单一视角拍摄的真实应用场景里会出现夜间、逆光、雨天、遮挡等情况。我们当时做了两件事来补齐这个差距。第一从公开的车辆数据集里筛选了另外一万张图片专门挑选官方案例中较少的夜间和侧面角度样本做数据补充。第二自己写了一个数据增强pipeline在做随机裁剪、随机翻转、颜色抖动这些常规操作之外增加了一个亮度扰动区间设在0.6到1.4之间专门模拟天亮前和天黑后的光照条件。这里有个值得注意的细节增广策略不能闭着眼睛猛加。我们早期把旋转角度设到30度结果车型识别准确率反而下降了因为车辆图片旋转太多之后形状信息被破坏模型学到了一些奇怪的伪特征。最后把旋转角度限制在10度以内问题就消失了。2.3 标注那些事工欲善其事必先利其器官方给的图片是有标注的但补充的样本需要自己标。数据标注是很多人会轻视的环节真正做起来才发现标一晚上图比训练一晚上模型还累。三个属性加起来每张图平均要标三轮一万张补充图我们三个人标了整整四天。工具用的是LabelImg和一款国产的标注软件前者用于画目标框后者用于填属性标签。两条铁律要记住一是标注规范必须提前写好颜色属性这一项就统一了“颜色深浅判断标准”避免不同人标的标签打架二是标注完成后要做一致性抽检我们当时随机抽了5%的图片人工复查发现了一个反复出现的标注错误——红色和橙色在某些光照条件下容易被混淆后来把这些样本单独拎出来重新标模型的混淆率才降下来。3. 模型选型与训练心法不要盲目追新3.1 主干网络与检测头的选择车辆属性识别这个任务本质上可以拆成两步先定位车辆区域再对区域内的图像做属性分类。因此整个系统天然分成检测模块和分类模块。检测模块我们直接采用了YOLOv8没有自己从头设计任何网络结构。理由非常朴素YOLOv8在目标检测上已经足够成熟社区资料多调参方便而且自带TensorRT导出支持。在国产边缘设备上测试转成TensorRT之后一张640x640的推理时间能压到30毫秒左右这个性能足够满足实时的需求。分类模块这里多讲两句。我们比较了ResNet50、EfficientNet-B3和ConvNeXt-Tiny三个候选模型。最终选择ResNet50作为主干不是因为它是三个里最好的而是因为它最“稳”。EfficientNet理论上FLOPs更低但在我们自己补的小数据集上验证精度并没有超过ResNet50ConvNeXt精度最好可是训练收敛速度慢需要更细的调参习惯不利于我们有限的时间预算。模型参数量验证集准确率训练耗时部署难度ResNet5025.6M92.3%4小时低EfficientNet-B312.3M91.8%4.5小时中ConvNeXt-Tiny28.6M93.1%7小时中3.2 多任务学习一次前向同时输出三个属性车辆颜色、车型、朝向这三个属性如果用三个独立的分类器分别处理训练简单但推理时要做三次前向计算而且三个头之间无法共享特征信息。我们最终采用了多任务学习的方案检测到车辆区域后把区域图像输入一个主干网络然后在网络末端分出三个分类头分别输出颜色11类、车型8类和朝向4类的预测结果。这样做的好处一是共享特征让模型学到更通用的车辆表征颜色分类头在训练时学到的特征也能帮助车型分类头二是推理时一次前向就拿到全部结果实测在边缘设备上单车辆属性识别只需约15毫秒完全满足实时性要求三是网络整体的参数量比三个独立模型小得多部署更友好。多任务学习唯一要小心的是loss权重平衡。最开始我们三个分支都直接用交叉熵结果颜色分支loss下降很快但车型分支一直上不去。原因很明显颜色分类相对简单梯度大主导了整个网络的更新方向。解决方案是给三个loss分别乘上权重系数颜色分支设为0.4车型分支设为0.4朝向分支设为0.2。调整之后车型分支的收敛速度明显加快。3.3 训练策略迁移学习、学习率与关键调参记录模型初始化方面我们使用了ImageNet上的预训练权重作为起点这是计算机视觉任务的标准做法能大幅缩短模型收敛时间。训练时先冻结backbone前40层只训练后面的分类头部分跑20个epoch之后再解冻全部层用更低的学习率对整个网络做微调。优化器选择了AdamW初始学习率设为1e-4weight decay设为1e-4。batch size在单张RTX 3090上设为32。训练总轮数80个epoch在第40和第60个epoch时分别把学习率降低到原来的0.1倍。还有一个比较关键的处理针对类别不均衡问题我们没有采用复杂的采样器而是借鉴了Focal Loss的思路在分类头里把标准的交叉熵换成带权重的版本。给样本量少的类别比如皮卡、橙色车身提高了损失权重权重值直接按“总样本数 / (类别数 x 该类样本数)”来算效果立竿见影少数类的召回率提升了大约14个百分点。4. 源码组织能拿给评委看的代码长什么样4.1 目录结构与模块划分“竞赛资料源码”这个东西评委看的不只是能不能跑而是代码组织是否体现工程素养。我们最终提交的源码目录长这样vehicle-attribute-recognition/ ├── checkpoints/ # 训练好的模型权重 ├── configs/ # 配置文件 │ ├── train_config.yaml │ └── deploy_config.yaml ├── data/ # 数据加载与预处理 │ ├── dataset.py │ └── augmentations.py ├── models/ # 模型定义 │ ├── detector.py │ └── attribute_head.py ├── scripts/ # 训练与推理脚本 │ ├── train.py │ ├── infer.py │ └── export_onnx.py ├── web_demo/ # Web展示端 │ ├── app.py │ └── templates/ └── requirements.txt每个目录都有独立的README.md说明文件对模块职责、输入输出格式、依赖环境都做了描述。这个细节在答辩时被评委专门表扬过说“代码组织得像正经项目而不是课程作业”。4.2 训练脚本的核心逻辑训练脚本是整个源码的核心我在这里贴一段简化但保留了关键逻辑的代码感兴趣的同学可以直接参考import torch import torch.nn as nn from torch.utils.data import DataLoader from models.detector import get_detector from models.attribute_head import AttributeHead def train_one_epoch(model, loader, optimizer, criterion, device): model.train() total_loss 0.0 for images, targets in loader: images images.to(device) color_labels targets[color].to(device) type_labels targets[type].to(device) direction_labels targets[direction].to(device) # 前向推理返回 (B, 11), (B, 8), (B, 4) color_logits, type_logits, dir_logits model(images) # 多任务损失权重经验值0.4 / 0.4 / 0.2 loss 0.4 * criterion(color_logits, color_labels) \ 0.4 * criterion(type_logits, type_labels) \ 0.2 * criterion(dir_logits, direction_labels) optimizer.zero_grad() loss.backward() # 梯度裁剪防止训练初期loss爆炸 nn.utils.clip_grad_norm_(model.parameters(), max_norm5.0) optimizer.step() total_loss loss.item() return total_loss / len(loader)这里面最值得关注的是权重参数0.4 / 0.4 / 0.2和梯度裁剪。前者解决的是多任务间的梯度竞争问题后者解决的是训练初期模型输出不稳定导致梯度爆炸的问题。没有这两个细节训练过程不会这么顺畅。4.3 推理Pipeline怎么把模型跑成真正的系统训练只是项目的一部分最终演示需要通过Web界面展示效果。我们用Flask搭建了一个轻量级Web应用用户上传一张车辆图片后端依次执行目标检测、车辆区域裁剪、多属性分类最后把识别结果叠加在原图上并返回。这里有一个容易被忽略的工程问题检测模型和分类模型需要“接力”运行检测模型输出的是未归一化的坐标值直接传给分类模型会出问题。解决方案是在检测输出后接了一个坐标归一化步骤把已经裁剪出来的车辆区域缩放到224x224再做归一化到[0, 1]区间的张量转换。import cv2 import torch import numpy as np def infer_single_image(model, image_path, device): # 读取图片 img cv2.imread(image_path) img_rgb cv2.cvtColor(img, cv2.COLOR_BGR2RGB) # 预处理缩放 转Tensor 归一化 resized cv2.resize(img_rgb, (224, 224)) tensor torch.from_numpy(resized).permute(2, 0, 1).float() tensor tensor / 255.0 tensor tensor.unsqueeze(0).to(device) # 推理 model.eval() with torch.no_grad(): color_logits, type_logits, dir_logits model(tensor) # 后处理argmax 映射为可读标签 color_id torch.argmax(color_logits, dim1).item() type_id torch.argmax(type_logits, dim1).item() dir_id torch.argmax(dir_logits, dim1).item() return { color: COLOR_LABELS[color_id], type: TYPE_LABELS[type_id], direction: DIRECTION_LABELS[dir_id] }如果准备复现建议直接把这段代码替换成自己的标签映射表不要照抄类的顺序否则会出现“模型输出绿色代码显示蓝色”这种搞笑但致命的bug我们团队在开发阶段就遇到过。5. 从省赛到国赛那些在实验室熬夜踩过的坑5.1 类别不均衡少数类几乎全军覆没第一次完整训练结束验证集上颜色分类的准确率到了91%当时的我们非常兴奋。但把混淆矩阵拉出来一看就傻眼了橙色车辆的召回率只有37%白色车辆的召回率只有52%大量少数类样本被误判成了黑色或灰色。造成这个问题的根本原因是官方数据集中深色车辆占比超过65%浅色和鲜艳色车辆占比很低。模型在训练时看到的深色样本太多学到了一个“把所有车辆往深色猜”的懒惰策略。解决这个问题花了两天时间。第一给少数类别做过采样让每个batch里面不同颜色的样本数量接近均匀分布。第二如上文提到的给分类loss加上类别权重少数类样本的loss被放大模型必须更认真对待这些样本。两招一起上橙色召回率从37%提升到了82%白色从52%提升到了89%最终颜色分类F1值从0.86提升到了0.91。5.2 过拟合验证集疯狂上涨测试集原地不动训练第50个epoch左右我们发现一个诡异现象验证集loss持续下降模型迭代越来越顺但自己拍的真实场景照片测试时识别结果惨不忍睹。这个问题的原因非常典型——训练集和验证集其实来自同一个官方数据发布源分布高度相似而真实场景的车辆图片在背景、拍摄角度、光照条件上和官方数据差异较大。当时的解决办法一是强化数据增强把前面提到的亮度扰动强度加大同时加入高斯模糊和随机遮挡模拟真实场景中的各种干扰二是采用模型集成用不同随机种子训练了3个模型推理时对三个模型的输出取平均。这两招加起来在自建的真实场景测试集上准确率大约提升了8个百分点。这里想给所有参赛队伍一个建议在省赛和国赛之间一定要自己准备一套“野路子”测试数据它不需要很多几百张就够专门用来验证模型在理想环境之外的泛化能力。评委现场演示时用的图大概率不是官方数据集里的图。5.3 推理速度的极限拉扯从90毫秒压到30毫秒国赛的评审过程中有现场演示环节演示环境只提供一块国产边缘计算开发板性能和普通笔记本差距明显。一开始我们把PyTorch模型直接部署上去单张图片的推理时间接近90毫秒勉强能用但画面有明显卡顿感预期演示效果不太理想。优化分了三步走。第一步把模型导出成ONNX格式去掉PyTorch动态图的额外开销推理时间降到约70毫秒。第二步用开发板自带的深度学习加速库做RT推理大部分算子在硬件上做了优化推理时间降到约45毫秒。第三步压缩输入分辨率检测模块从640x640降到512x512分类模块从224x224降到192x192推理时间进一步降到约30毫秒。部署方式单张推理耗时准确率影响PyTorch 原始90ms无ONNX Runtime70ms无深度学习加速库推理45ms无明显变化加速库 降分辨率30ms降低了0.4%最终选择了第三档和第四档之间的平衡即检测用512x512、分类用224x224推理时间约35毫秒准确率几乎没有损失。这段部署经验后来被写进了作品说明书的技术难点章节答辩时也作为“工程实践能力”的证据。6. 材料制作与答辩决定奖项高度的临门一脚6.1 演示视频录制的关键细节评委看视频的时候心里一直在琢磨一个问题这个系统到底是真能用还是只是跑了几个预置样例所以演示视频的制作原则是必须让人感受到系统的“实时反馈”和“真实操作”。我们录视频时没有用预置好的样例图而是现场拍摄。手机拍摄一张停车场照片立刻传给系统几秒钟后界面上显示出识别结果。整个过程一镜到底没有任何剪辑拼接。视频里特意展示了一个遮挡了约30%车身的车辆图片——系统依然能正确识别——然后在视频旁白里解释为什么能识别是因为训练数据中包含部分遮挡样本。这种“自己给自己出难题然后解出来”的设计在答辩现场获得了不错的反应。6.2 答辩PPT的逻辑线答辩PPT切忌把所有的实验过程、所有调参细节都堆上去评委没有兴趣看你训练了多少轮。我们最终的结构是四页核心内容第一页问题和场景一句话说明这个问题在现实世界中非常重要智慧交通、车辆轨迹追踪、安防布控。第二页方案和技术路线画一张简单的流程图检测模块加多任务分类模块强调为什么设计成两阶段而不是端到端。第三页实验结果和对比一张表格展示各模型在三个子任务上的准确率突出我们方案的优势。第四页应用演示直接放视频和实时截图。答辩时不用背稿但要结合PPT把逻辑讲顺。评委如果要问细节就在那页停留如果评委不深究就快速推进。在几个关键节点留出“可能会被追问”的空间已经准备好答案主动等评委来问。6.3 评委最爱问的问题根据我们的答辩经验和赛后交流评委在人工智能挑战赛中最常问的问题大概是下面几类。第一类为什么用两阶段方案而不是端到端的单阶段方案这个问题考验你对任务本身的思考深度。我们的回答是端到端方案训练复杂度高需要大量精准标注的检测框而我们的任务里车辆定位是相对简单的子问题分开做可以各自优化项目后期维护也更容易。第二类你的模型在极端情况夜间、大雨、极端光照下表现如何这是个很现实的问题。我们如实回答在夜间和雨天场景下准确率会有明显下降但通过补充训练数据和数据增强已经在逐步改善并展示具体数据评委很认可这种坦诚的态度。第三类如果把你的方案用到移动端你还会做哪些优化这个问题考的是工程思维。我们提到可以模型剪枝、知识蒸馏、使用Int8量化甚至可以把检测模型替换成更轻量的模型。评委关注的是你有没有想过而不是你现在是否已经做到了。7. 国二之后源码能给你什么又不能给你什么到这里关于中国计算机设计大赛人工智能挑战赛国家二等奖的全过程复盘基本上讲完了。最后说几句掏心窝子的话。“竞赛资料源码”听起来像是一份打包好的“通关秘籍”但真正拿奖之后回看代码和文档只是整个项目的外皮真正有价值的是当时做技术决策和权衡时的判断逻辑。为什么选ResNet50而不用EfficientNet为什么多任务权重是0.4比0.4比0.2为什么演示视频要一镜到底这些问题的答案没有写在任何一行代码里但它们恰恰是所有项目成败的关键。如果你能拿到国奖的源码我的建议是不要急着跑通它先看懂数据流是怎么走的再看清loss曲线在哪个epoch出现了变化最后看模型在部署时经过了哪些压缩和适配。把这三个问题搞明白对你自己的项目帮助会非常大。尤其想说的是答辩这个环节。很多队伍技术实力很强但到了现场讲不出来被评委一追问就慌最后拿到的名次远低于预期。比赛比的从来不只是代码还有你把自己做的事讲清楚的能力——这种能力在以后工作汇报、项目评审、技术分享中同样重要。如果这篇内容对准备参赛的同学有哪怕一点参考价值也就不算白写了。本文还有配套的精品资源点击获取