AI竞赛国奖项目复盘:YOLOv8目标检测与行为识别实战

发布时间:2026/10/13 18:34:45
AI竞赛国奖项目复盘:YOLOv8目标检测与行为识别实战
简介本资源是面向大学生人工智能竞赛选手的实战型备赛资料包聚焦中国计算机设计大赛人工智能挑战赛核心赛题涵盖移动物体检测、口罩识别、疲劳检测、安全帽识别等典型CV应用场景提供从模型训练YOLOv3、数据预处理到结果可视化的一站式解决方案。压缩包共55个文件含15个可直接运行的Python主程序与工具脚本、8个配置文件.cfg/.names、7个数据相关文件、6个演示GIF动图及2份结构化说明文档.md整体55.4MB目录层级清晰模块解耦明确便于快速定位与二次开发。已有114人学习下载所有源码均经实测验证支持开箱即用并附LICENSE与完整README说明适合作为计算机设计大赛、智能车、机器人、AI创新类赛事的算法基线参考与工程实践范本。 我很久没有这么认真地复盘一个比赛项目了。最近整理硬盘翻出了中国计算机设计大赛人工智能挑战赛国家二等奖的完整资料包包括源码、数据集处理脚本、模型权重、答辩PPT和比赛录像。当时组队、备赛、通宵调参的场景还历历在目。这个奖项对我和队友来说不只是一张证书更像是一次对AI工程落地能力的全方位检验。这篇文章不打算泛泛而谈什么“参赛感悟”而是完全围绕“代码怎么写、模型怎么调、答辩怎么讲”展开。我会把整套竞赛资料源码的架构、关键实现细节、训练过程中的坑、以及答辩时评委最关心的点全部拆开来讲。如果你正在准备高校的学科竞赛尤其是计算机设计大赛、人工智能挑战赛这类偏综合应用赛道的比赛这篇文章大概率能帮你少走很多弯路。1. 赛题分析与整体设计思路1.1 核心需求解析比赛到底在考什么中国计算机设计大赛虽然名字里有“设计”但人工智能挑战赛这个赛道完全是硬核技术流重点考察三个维度问题建模能力、工程实现能力、创新应用能力。我们当年的赛题方向是“特定场景下的智能视觉识别”具体任务是对一个相对复杂的环境进行实时目标检测和行为分析。很多人拿到这类赛题第一反应就是“我直接上YOLO”但这恰恰是最容易翻车的思路。评审专家一天要看几十个队伍的作品你如果只是调个现成模型跑个demo根本进不了国赛第二轮。我们当时做赛题拆解时把需求分成了四层第一层基础检测能在复杂背景中准确框出目标物体这是底线任务类似“找得到”。第二层行为理解不只是框出来还要判断目标的状态和动作比如“目标在做什么”。第三层场景适配算法要能在不同光照、不同角度、不同密度的真实场景下稳定运行不能只在实验室数据集上有效。第四层实时性要求整个推理链路要有实际应用价值不能离线跑完再出结果核心指标是端到端延迟。也就是说评委要看的不是一个模型demo而是一套“能解决实际问题的完整方案”。基于这个认知我们整个方案的设计主轴就定为以轻量化检测模型为底座以行为识别模块为亮点以工程化部署为保障。1.2 技术选型背后的取舍逻辑技术选型阶段我们内部其实吵过好几轮。方案A是走纯检测路线用YOLOv7或者YOLOv8做高精度检测把mAP刷上去稳妥但缺乏亮点。方案B是检测行为识别双模块复杂度翻倍但更容易体现“智能”两个字。最后我们选了方案B理由很简单大赛名字里带了“人工智能”三个字评委一定希望看到“理解”层面的能力而不只是“感知”层面。具体选型如下检测模块YOLOv8s输入尺寸640x640为什么是s而不是m或者l因为我们评估过决赛现场的机器配置单张消费级显卡RTX 3060级别v8s能满足实时性要求mAP在自建数据集上也能到87%左右性价比最高。行为识别模块选用了基于骨骼关键点的方案具体是用MediaPipe提取人体骨架再配合一个轻量级的时序分类网络判断行为类别。为什么不用3D-CNN直接做端到端因为3D卷积网络吃显存太猛训练数据需求量也大短时间内很难收敛到稳定效果。后端服务模型训练用PyTorch模型部署用ONNX RuntimeWeb端用Flask搭了一个简单的推理服务前端页面展示实时识别结果。数据增强这一点特别关键。现场赛和平时训练不一样比赛现场的摄像头角度、光线、背景都是未知的。我们训练时用了Mosaic、MixUp、随机仿射变换、HSV扰动、随机遮挡等多种增强策略保证模型在未知场景下的泛化能力。选型这一步一定要多花时间因为后面所有的代码、数据、训练、答辩都建立在选型之上。换模型等于推倒重来这个代价很多人低估了。2. 核心细节解析与实操要点2.1 数据集的构建决定上限的隐藏战场我一直跟身边人说竞赛比的不是谁的模型结构更花哨比的是谁的数据更干净、更贴近真实场景。我们拿到的官方数据量并不大大概只有几千张标注好的图片直接拿来训练很容易过拟合。为了扩充数据集我们做了三件事。第一件事是人工采集补充。用手机在多个不同场景拍摄目标对象包括室内强光、室外逆光、阴天、夜晚用补光灯模拟低照度把手机拍的照片和官方数据混合在一起。这一步让训练集的场景多样性提升了一大截。第二件事是半自动标注。手工标注几千张图太痛苦我们先用一个预训练模型跑一遍所有新增图片生成初步标注框然后人工只修正框的位置和类别。这样把标注效率提升了三倍以上。注意一个细节修正标注框的时候我建议把置信度低于0.85的框全部删掉重新标不要贪图省事只改边角否则模型学到的边界框回归质量会很差。第三件事是构建负样本。这是很多人忽略的。我们在数据集中加入了大量“什么都没有”的背景图类别标签为空。这么做的好处是显著降低误检率让模型学会在找不到目标时“闭嘴”而不是随便框一堆乱七八糟的东西。负样本比例控制在总数据量的15%左右效果最好。最终数据集规模是两万三千多张标注类别五个每张图平均标注框数量在3到8个之间。数据集的质量直接决定了模型效果的天花板这一块投入的时间绝对值得。2.2 模型训练的三个关键技巧训练阶段我总结出三个直接决定比赛成绩的技巧。第一个技巧是分阶段训练。先冻结backbone主干网络只训练检测头head用较小的学习率跑几十个epoch让模型先学会基础的分类和回归任务。然后解冻整个网络把学习率降一个数量级再精调几十个epoch。这样做的原因是避免训练初期梯度震荡太大导致模型不稳定。我们在YOLOv8s上采用这个策略后收敛速度明显加快最终精度也比直接端到端训练高约2个百分点。第二个技巧是学习率的动态调整。固定学习率是新手最容易犯的错误。我用的是一段式余弦退火策略初始学习率0.01warmup阶段从0.001线性升到0.01然后按余弦曲线衰减到最低值。这种策略的好处是前期学得快后期学得稳能有效避开局部最优解。YOLOv8框架里直接配置lr0和lrf两个参数就能实现不用自己写回调。第三个技巧是类别不平衡处理。五个类别里有两个类别的样本量明显偏少只有几百张如果直接训练模型会对这两个类别的召回率特别低。解决办法是在损失函数里给少数类别更高的权重YOLOv8里可以用cls_pw参数设置每个类别的权重我们当时把少数类别的权重调到了1.5到2.0效果立竿见影。这里放一段训练启动命令的示例方便你直接参考yolo taskdetect modetrain modelyolov8s.pt data./dataset.yaml epochs200 imgsz640 batch16 lr00.01 lrf0.01 warmup_epochs3.0 cos_lrTrue workers4 device0训练过程中记得每5个epoch保存一次checkpoint并且监控mAP0.5和mAP0.5:0.95两个指标。很多队伍训练一晚上起来发现loss已经降到很低但mAP反而掉了这就是过拟合的信号要立即停止并回滚到之前的checkpoint。2.3 行为识别模块的工程实现行为识别模块是整个项目的差异化亮点也是答辩时评委提问最多的地方。我们采用的是“骨骼关键点时序分类”两段式方案思路和市面上很多动作识别方案类似但工程实现上做了不少优化。第一段是骨骼关键点提取直接用MediaPipe的Pose模块每帧输出33个关键点的坐标和置信度。为了减少后续计算量我们只取了其中17个核心关节点去掉脸部的一些冗余点。这里有一个细节MediaPipe对单人效果很好但比赛场景中可能出现多人这时候需要做目标框和骨骼点的匹配。我们的做法是计算检测框和骨骼点中心点的距离把骨骼点分配给距离最近的检测框然后截取对应区域送入行为识别网络。第二段是行为分类。我们把连续30帧的骨骼序列17个点x2维坐标总共1020维向量送入一个三层全连接网络中间层用ReLU激活最后一层用Softmax输出行为类别的概率。这个轻量网络参数量才几十万CPU上跑都毫无压力完全不会拖累整个系统的实时性。训练行为识别网络时我们自己录制了一大批动作视频然后用MediaPipe抽帧提取骨骼序列标注动作类别。这个过程重复性高但必须做因为公开的行为识别数据集大多面向日常动作和比赛场景中的动作差异很大直接用公开数据集训练会严重影响现场识别效果。行为识别网络结构示意如下import torch.nn as nn class ActionClassifier(nn.Module): def __init__(self, input_dim1024, num_classes4): super(ActionClassifier, self).__init__() self.fc1 nn.Linear(input_dim, 512) self.fc2 nn.Linear(512, 128) self.fc3 nn.Linear(128, num_classes) self.relu nn.ReLU() self.dropout nn.Dropout(0.3) def forward(self, x): x self.relu(self.fc1(x)) x self.dropout(x) x self.relu(self.fc2(x)) x self.fc3(x) return x有个小坑提醒如果不加Dropout这个网络非常容易过拟合因为输入维度高但样本量有限。我们一开始不加Dropout验证集准确率只有82%加上Dropout之后直接跳到94%差距非常大。3. 实操过程与核心环节实现3.1 环境配置与依赖版本锁定很多人在比赛前最喜欢踩的坑就是环境不一致。实验室里跑得好好的代码到了比赛现场机器上各种报错原因就是依赖库版本没锁死。比赛前一周我专门整理了一份requirements.txt把每个核心库的版本号都固定住现场部署的时候直接一键安装省掉了所有排查环境的时间。这里强调一下几个关键依赖的版本组合我们实测下来配合最稳定依赖库版本号说明Python3.9.x不建议用3.11部分库兼容性有坑PyTorch2.0.1CUDA 11.8配套版本CUDA11.8太新太老都容易出问题torchvision0.15.1与PyTorch版本严格对应ultralytics8.0.47YOLOv8训练框架onnxruntime-gpu1.15.1部署加速用opencv-python4.7.0.72图像处理mediapipe0.10.3骨骼关键点提取Flask2.3.2Web端推理服务特别注意MediaPipe和PyTorch的兼容性偶尔有奇怪问题如果你遇到import时死锁或崩溃先检查一下opencv-python的版本是否冲突这个坑我们踩了整整一个下午。3.2 模型部署与推理优化训练好的模型不能直接用PyTorch跑因为PyTorch的推理速度其实不算快而且现场机器的CUDA环境可能存在差异。我们统一用ONNX Runtime做推理有两种格式一种是YOLOv8导出的ONNX另一种是行为识别模型转换后的ONNX。导出命令很简单yolo taskdetect modeexport modelbest.pt formatonnx opset12 simplifyTrue导出ONNX之后我们用onnxruntime-gpu做推理加速单帧检测耗时从PyTorch的约30毫秒降到了ONNX Runtime的约15毫秒RTX 3060。全程加上骨骼点提取和行为识别整个链路的端到端延迟稳定在40到50毫秒之间算下来每秒能处理20帧以上完全满足实时性要求。部署时我们还做了两个优化。第一个是输入图像预处理把视频帧缩放到640x640之前先等比缩放再填充灰度边避免直接拉伸导致目标变形这个细节能提升框的准确度。第二个是推理结果后处理NMS的IoU阈值在公开数据集上默认是0.45但我们自己调到了0.5因为比赛场景里目标拥挤度高阈值太低会丢掉一些有效重叠框阈值太高又会产生大量重复框0.5是我们在自建验证集上测出来的最优值。Web端我们用的是Flask加一个极简前端页面页面实时显示视频流和检测结果同时把行为识别结果用标签形式展示在画面上方。评委演示的时候这一套可视化方案比单纯在终端里跑代码直观得多操作起来也几乎没有学习成本。3.3 答辩演示的完整流程答辩环节的演示我建议遵循“问题导入—方案展示—亮点呈现—现场问答”四段式结构总时长控制在12到15分钟。我们当时的流程是开场用30秒介绍比赛场景痛点比如“某些特定场所的安全巡检目前仍依赖人工存在效率低、漏检率高的问题”把评委代入到“你在解决一个真实问题”的语境里。然后展示系统界面用事先录制好的三段视频不同场景、不同光线、不同密度轮播每段大约1分钟期间穿插说明检测模块和行为识别模块各自的工作原理。接着展示训练数据样例、模型结构图、训练过程loss曲线和mAP曲线证明整个方案是“训出来的”而不是“抄来的”。最后留出3到5分钟给评委提问这个环节尤其要准备充分。现场演示翻车是大家最怕的事我的应对策略是“录制视频兜底现场实时备用”。录制好的视频在出现意外时可以直接播放即使现场摄像头坏了、网络断了也有应急方案。我们比赛当天确实遇到了现场机器性能不足的情况因为提前准备了录制视频整体演示没有受到太大影响。这里强调一句永远不要赌现场环境一切正常。4. 常见问题与排查技巧实录4.1 训练过程中的典型问题速查表我把备赛期间遇到最多的几个问题整理成了一张速查表这些问题几乎每个做竞赛的队伍都会碰到现象可能原因排查思路与解决方案loss不降反升学习率过大降学习率检查数据集中是否有大量错误标注mAP一直很低数据集质量差或类别不平衡检查标注框是否偏移调整类别权重训练后期mAP波动大学习率未衰减或batch太小改用余弦退火增大batch size模型对某个场景效果明显差该场景在训练集中占比过低补充该场景数据做针对性增强推理时显存溢出输入分辨率太高或batch过大降低imgsz到640推理时batch设为1ONNX导出后结果与PyTorch不一致某些算子在ONNX中不支持打开simplify模式必要时用onnxruntime重写预处理有一个问题特别想强调如果训练过程中loss正常下降但mAP始终上不去先别急着调模型结构优先去检查数据。我们曾经有个类别标注框偏移了大约10个像素导致模型对这个类别的预测框一直偏大mAP被拖低了五六个点。把标注修好之后同一个模型精度直接涨回来。数据质量永远是最优先的排查项。4.2 现场部署的避坑指南比赛现场的机器环境通常和实验室完全不一样这一块我有几条血泪经验。第一提前确认比赛现场的显卡型号和CUDA版本。如果现场只有CPU而无GPU你的整个推理链路设计都要改。我们当时做了两套部署方案一套走GPU加速一套走CPU推理检测部分用ONNX Runtime的CPU版本行为识别网络本身就对CPU友好。虽然最后现场有GPU但双方案给了我们极大的心理保障。第二所有模型和权重文件要做双重备份U盘一份、云端一份。现场如果U盘损坏或者文件拷贝不完整至少还能从云端快速下载。别笑真的有队伍因为U盘被误格式化和网络速度太差导致现场无法加载权重整场答辩只能用PPT硬撑。第三代码中涉及文件路径的部分全部用相对路径并加上异常判断。现场电脑的目录结构和实验室可能完全不同如果代码里写死了绝对路径到了现场就是“文件不存在”的连环报错。我们统一改成相对路径后任何目录结构下都能直接运行。第四提前准备好一个“一键启动脚本”。双击脚本自动激活conda环境、启动Flask服务、打开浏览器页面。这个小细节在答辩现场特别加分也给评委留下“工程素养高”的印象。4.3 答辩问答环节的应对策略评委提问是答辩中最难控场也最体现水平的环节。根据我们的经验评委关注点集中在五个方向数据来源与标注方式、模型选择依据、创新点归属、系统局限性、可推广性。每个方向都要提前准备好两三句话的简洁回答。比如评委问“你这个行为识别部分为什么不直接用现成的动作识别模型”如果回答“因为效果不好”就太虚了应该直接说“我们评估过OpenPose和MediaPipeOpenPose精度更高但对多人场景和遮挡场景鲁棒性差而且部署体积大、推理速度慢MediaPipe在轻量化和实时性上更符合我们的场景需求所以选型的时候做了取舍”。这种回答既展示了调研深度也显得有理有据。另外一个容易被问住的问题是“你的模型在极端情况下会怎么表现”。面对这类问题不要回避直接承认局限性然后说清楚你在哪些方面做了针对性优化哪些方面还受限于数据和时间没能完善。坦诚比硬撑更有说服力。5. 项目源码结构说明与复用建议5.1 源码目录设计整个项目源代码的目录结构如下这份结构也是我们当初反复调整后的最终形态competition_project/ ├── config/ # 配置文件数据集路径、模型参数、类别映射 ├── data_process/ # 数据标注、预处理、增强脚本 ├── detection/ # YOLOv8模型训练、导出、推理封装 ├── action_recognition/ # 骨骼点提取、行为分类训练与推理 ├── web_ui/ # Flask后端服务和前端页面 ├── scripts/ # 一键启动、环境配置等工具脚本 ├── weights/ # 模型权重文件 ├── docs/ # 技术文档、答辩PPT和演示视频 └── requirements.txt # 依赖库版本锁定文件源码结构设计的原则是“各模块独立、接口清晰”。检测模块和行为识别模块互不依赖任何一方出问题都可以单独替换和调试web_ui层只负责调用接口不关心底层模型细节。这个分层思想在答辩时也是一个很好的话题点。有一点想强调写竞赛代码不要追求过度工程化。我们见过一些队伍把代码抽了很多层抽象用各种设计模式包装结果改一个参数要找五个文件。竞赛代码的第一要务是“能跑、能改、能扛现场压力”架构清晰比过度设计重要得多。5.2 如何基于这份源码复现和扩展如果你打算复用这份源码我建议按照下面这个顺序来先跑通Web端demo。安装环境、配置权重路径、启动Flask服务看到实时检测画面对整个系统建立直观认识。替换为自己的数据集。修改config里的类别配置和数据集路径重新训练检测模型。替换行为识别部分。录制自己的动作视频用data_process里的脚本提取骨骼序列并训练分类网络。根据比赛要求扩展功能。比如增加异常行为告警、识别结果的统计分析、多路视频流并发处理等。这个项目的核心价值不在于某一处代码写得多么漂亮而在于提供了一条完整的“从数据到部署”的技术链路。你踩过的坑、积累的经验都沉淀在这份源码的各个模块里。就算不用这份代码按照它的模块划分方式重新组织自己的项目也会让你在备赛过程中思路清晰很多。5.3 代码风格与文档规范最后说一个很容易被忽视但很重要的点代码注释和文档。大赛评委虽然不会逐行读你的代码但在提交材料的时候一份结构清晰、注释到位、文档完整的源码包会直接拉高评委对你的工程能力评价。我们要求所有核心函数都要有docstring说明输入参数、输出结果和功能含义训练脚本和推理脚本头部注明运行环境和使用方法关键代码段的注释必须解释“为什么这么写”而不是“做了什么”。另外写一份简短的README说明项目背景、环境依赖、目录结构、运行步骤和常见问题。这份README我们花了两个晚上才写完但每次被人问“你们项目怎么跑起来”直接把README发过去就能解决90%的问题省下来大量解释时间。6. 从获奖项目里提炼出的通用方法国赛结束之后我反复复盘过整个备赛过程发现能够拿到国家二等奖不是因为某一个模型有多强而是因为整个流程中没有明显的短板。这里总结几条通用方法适配大多数AI类竞赛。第一从比赛评分标准反推项目设计。比赛前先搞清楚评分细则到底技术分占多少、创新分占多少、演示效果占多少。我们拿到评分标准后发现演示效果和答辩表现在总分中占的比例接近一半因此特意投入了大量精力在可视化界面和演示流程上而不是全部时间都耗在打磨模型精度上。竞赛永远是“综合考虑”的博弈技术只是其中一环。第二留出足够的时间做抗风险准备。备赛的最后一周我们每天都在做“故障演练”假设各种可能出问题的场景并提前准备预案比如模型文件损坏、现场断网、投影仪分辨率不对、系统突然重启等。这些准备看起来琐碎但在比赛当天真的全部派上了用场。很多队伍死在现场技术故障上而不是死在方案设计上这个比例比你想象中高得多。第三多轮内部评审和模拟答辩。我们在比赛前找了三拨不同背景的人帮忙模拟评委包括同实验室的博士生、非AI方向的本科同学、甚至还有一位文科背景的朋友。每一轮模拟答辩之后根据反馈调整讲稿和演示方式。非AI方向的评委特别能帮我们发现“自以为讲清楚了但别人根本没听懂”的环节这对提升答辩表现力非常有效。第四抱持“方案可落地”的心态做技术选型。比赛不是论文不需要最前沿的模型但需要最稳定可靠的表现。我们在做行为识别方案时不是没有考虑过用Transformer或者图神经网络但评估完训练成本和现场环境后坚定选择了轻量级方案。事实证明这个决定是对的复杂模型不一定带来更好的结果但一定带来更高的风险和更大的调试成本。这个项目的历程让我深刻体会到竞赛的价值不仅仅是那张获奖证书更是在时间压力下训练出的工程直觉和系统思维。如果你正在备战类似的比赛希望这份源码分析能帮你理清思路。有问题欢迎在评论区和我交流我会尽量把自己踩过坑的细节都告诉你。本文还有配套的精品资源点击获取