企业官网建设流程全解析

做了大半年行人动作识别方向，从数据标注到模型训练再到前端展示，完整走通了一套基于YOLOv8的“一条龙”方案。这篇东西不是那种跑个官方demo就发出来的水文，而是把我踩过的坑、调参的心得、改进点的取舍逻辑、以及最终怎么把模型塞进Web前端展示的完整路径整理出来，给正在做类似项目的同学做个参照。

这套系统说白了就是：摄像头画面进来，实时识别画面里行人的动作状态——走路、跑步、骑自行车、蹲下、挥手、摔倒、打架这类行为，然后在网页上把识别结果、统计图表、视频流一起展示出来。涵盖了数据集标注、YOLOv8训练、70+改进点、前后端部署这一整条链路，适合研究生做课题、做毕设，也适合工程上想快速落地一套行为分析Demo的开发者。

1. 项目概述与整体设计思路

1.1 这个系统能解决什么问题

行人动作行为识别说起来不算新鲜，但真正落地的时候场景差别很大。同一套模型，放在智慧安防里要的是异常行为告警——摔倒、打架、闯入禁区；放在智慧零售里要看的是顾客动线、停留时长、拿放动作；放在交通场景里则要识别行人横穿、奔跑、骑车载人等。动作类别的定义不同，后续的数据、模型、前后端设计就完全不一样。

这个项目我把动作类别定在8个常见类别上：站立（standing）、行走（walking）、跑步（running）、下蹲（squatting）、骑自行车（cycling）、挥手（waving）、摔倒（falling）、打架（fighting）。这8类覆盖了监控场景里大部分高频行为，也基本是论文实验里比较标准的动作集合。实际上你可以根据需求替换，类别的增删不影响整体流程，但要重新标注数据、重新训练。

系统要解决的三个核心问题也很明确：第一，动作识别不是简单的人体分类，视频时序信息很关键；第二，单帧检测容易误判，工程上要用合理的策略去平滑结果；第三，模型训练和部署割裂，很多人训练完模型不知道怎么接到业务系统里。所以我做这套系统时，除了模型本身，更把训练脚本、推理服务、前端页面串成了一条完整链路，拿到源码就能直接跑起来看效果。

1.2 技术选型：YOLOv8为什么是合适的底座

选型之前我对比过几类方案。两阶段的Faster R-CNN系列精度不错，但推理速度在视频流场景下很难保证实时，部署成本高；基于Transformer的检测模型精度天花板更高，但数据量少的情况下容易过拟合，训练周期长；YOLO系列作为单阶段检测的代表，在速度和精度的平衡上一直是最稳的选择。

YOLOv8选为底座有几层考虑。结构上它用了Anchor-Free的检测头，省掉了Anchor聚类和匹配的复杂度；主干网络的C2f模块相比之前的C3结构，梯度流动更好，参数量和计算量控制得很合理；检测头改成解耦头之后，分类和回归分支各管各的事，收敛更快。这些改动让它在默认参数下就能有不错的精度表现，给后续的自己加改进点留下了余地。

另外YOLOv8的生态成熟度也是我重点考虑的因素。模型导出支持ONNX、TensorRT，训练脚本完善，分布式训练、混合精度、EMA这些都有内置支持。这意味着我可以把精力集中在数据、训练策略、改进点和部署上，不用在工程基建上浪费时间。

1.3 系统整体架构拆解

整套系统分成四个层次：数据层、训练层、推理服务层、Web展示层。

数据层负责标注格式的统一管理，原始视频抽帧、图片标注、YOLO格式的txt生成、数据集划分，全部走标准化的脚本处理，保证喂给训练脚本的数据干净一致。训练层围绕YOLOv8的训练管线改造，支持一键训练、自定义数据配置、改进点开关。推理服务层用WebSocket和HTTP接口接收视频流，调用训练好的模型做检测，再结合时序逻辑对动作结果做优化，输出结构化结果。Web展示层负责对接推理服务，实时显示视频画面、识别框、动作统计曲线和告警信息。

这种分层的好处是每层都能独立替换。比如前端不做Web，改做桌面端或小程序，只需要把推理层的API保留好；训练层换了数据集，只改配置文件，不用动代码。我自己在一开始就明确了这条链路，后面两个月迭代基本没有返工过。

2. 数据集准备与标注：决定模型上限的苦活

2.1 数据采集与类别定义规则

数据质量直接决定模型上限，这句话说了无数遍，但实际做的时候很多人还是草率。行人动作数据集，类别定义是第一道坎。同一个“行走”在不同俯仰角、不同画质下差异巨大，如果你的数据集里只有平视视角，部署到高位摄像头场景就直接崩。

初始标注的类别定义，我建了一份标注规范文档，写明每个类别的判别标准。比如“站立”只算两脚基本不动且上身直立，“下蹲”要求髋关节明显低于站立高度，“摔倒”限定为人体由直立姿态快速变为接近水平姿态。规范文档的意义在于多人标注时保持一致性——多人协作标注如果没有统一标准，类间混淆会让训练曲线永远不收敛。

数据来源我用了三种方式混合：一是公共行为数据集（注意筛选许可证允许使用的），二是自己架相机在校园、走廊、操场上录制的场景数据，三是从公开视频网站下载后人工筛选的片段。自己录制部分虽然工作量大，但能拿到和最终部署场景最接近的视角、光照、画质，对模型在真实场景的表现提升很明显。公共数据集负责增加动作多样性，自己拍的负责贴近目标场景。

最终数据集规模在2万张左右，训练集、验证集、测试集按8:1:1划分。划分时按视频片段分组，而不是按图片随机分——同一段视频抽出来的连续帧如果既在训练集又在测试集，会带来严重的数据泄漏，测出来的精度会虚高。

2.2 标注工具与YOLO格式转换

标注工具我用的开源的图形化标注工具。框出人体目标并打上动作类别标签，导出为Pascal VOC格式的XML，再通过脚本转换成YOLO训练要用的txt格式。YOLO格式比较特别，一行一个目标，内容依次是类别id、归一化后的中心点x、中心点y、宽、高，五个值全是0到1之间的小数。

import xml.etree.ElementTree as ET import os def voc_to_yolo(xml_dir, out_dir, classes): os.makedirs(out_dir, exist_ok=True) for xml_file in os.listdir(xml_dir): if not xml_file.endswith('.xml'): continue tree = ET.parse(os.path.join(xml_dir, xml_file)) root = tree.getroot() img_w = int(root.find('size/width').text) img_h = int(root.find('size/height').text) name = os.path.splitext(xml_file)[0] with open(os.path.join(out_dir, name + '.txt'), 'w') as f: for obj in root.iter('object'): cls = obj.find('name').text if cls not in classes: continue box = obj.find('bndbox') xmin = int(box.find('xmin').text) ymin = int(box.find('ymin').text) xmax = int(box.find('xmax').text) ymax = int(box.find('ymax').text) # 转成YOLO格式 x_center = (xmin + xmax) / 2 / img_w y_center = (ymin + ymax) / 2 / img_h w = (xmax - xmin) / img_w h = (ymax - ymin) / img_h f.write(f"{classes.index(cls)} {x_center:.6f} {y_center:.6f} {w:.6f} {h:.6f}\n")

标注的时候有几个容易被忽略的细节。遮挡超过一半的目标要标注还是忽略，要提前定规则——我的规则是可见面积大于30%就标注，且只标可见部分。边缘截断的人体目标不要舍弃，这类样本对模型抗干扰能力很重要。还有小目标问题，远处行人可能只有几十个像素，这种样本要刻意保留，否则模型在远距离场景下会大量漏检。标注完成之后建议做一次交叉复核，随机抽20%的图片让标注员互相检查，能显著减少错标。

2.3 类别平衡与数据增强策略

标注完先统计类别分布。如果“摔倒”只有“站立”的十分之一，训练出来的模型大概率对新摔倒样本不敏感。类别不平衡的常规处理有几种：对少数类做过采样、用类别权重调整损失函数、把多数类随机丢弃一部分。我在这个项目里先统计各类别数量，再做针对性补充，把高频类多的图片删一部分，再补拍和网上筛选低频类的数据，尽量让类别数量差距控制在3倍以内。

数据增强层面，YOLOv8自带的Mosaic、MixUp、随机仿射变换在训练时默认是开着的。Mosaic把四张图拼成一张，这在小数据集上效果极为明显——它增加了单张图片的目标数量和背景多样性，还能变相缓解小目标不足的问题。我自己额外加了随机亮度和对比度扰动，因为监控场景下光照变化很大，白天强光、晚上昏暗、阴雨天偏灰，这些都要通过增强模拟出来。

注意：Mosaic增强虽然效果好，但训练到后期建议逐渐关闭，或者降低概率。训练全程开着Mosaic会导致模型在真实分布的单张图片上表现不稳定，很多人的模型训练loss看着很低、验证mAP也不错，但实际抓拍图片一测就崩，跟Mosaic的分布不一致有很大关系。我一般设置前80%的epoch开启Mosaic，后20%关闭。

3. 模型训练实战：从配置到一键跑通

3.1 环境搭建与工程目录规划

环境这块我建议直接用conda建独立环境，避免把系统Python搞乱套。核心依赖就是Python 3.8以上，PyTorch 1.8以上（我用的是1.13），加上YOLOv8框架本身以及opencv-python、numpy、pandas、matplotlib这些常规库。GPU环境建议CUDA 11.7以上，显存8G起步，我训练用了单张12G显存的显卡，batch_size跑16没有问题。

conda create -n yolov8 python=3.9 conda activate yolov8 pip install torch==1.13.1 torchvision==0.14.1 --index-url https://download.pytorch.org/whl/cu117 pip install ultralytics opencv-python numpy pandas matplotlib

工程目录结构我这样规划：

project_root/ ├── dataset/ │ ├── images/ │ │ ├── train/ │ │ └── val/ │ └── labels/ │ ├── train/ │ └── val/ ├── config/ │ ├── data.yaml │ └── improve.yaml ├── models/ │ ├── yolov8n.pt │ └── yolov8s.pt ├── runs/ │ ├── train/ │ └── detect/ ├── scripts/ │ ├── train.py │ ├── export.py │ └── predict.py ├── server/ │ ├── main.py │ └── ws_handler.py └── web/ ├── index.html ├── main.js └── style.css

这种目录看起来简单，但对后续的迭代非常关键。数据集、脚本、输出目录各归各的，跑一次实验的结果都留在runs/train下，日志、曲线、权重按时间戳分开，不会互相覆盖。我有段时间偷懒把多个实验塞同一个输出目录，结果想对比几次训练的曲线时根本分不清是哪次跑的，后来老老实实按时间戳归档。

3.2 数据集配置与训练参数说明

数据集配置用YAML文件组织，告诉训练脚本图片目录、标签目录、类别列表都在哪。这里有一个很容易踩的坑：标签txt里类别索引必须和YAML里classes列表的顺序严格对应。如果classes里“站立”排第0，标注脚本里index也要从0开始按相同顺序映射，顺序错了训练出来的模型就是一本正经的胡乱识别。

# config/data.yaml train: dataset/images/train val: dataset/images/val test: dataset/images/val nc: 8 names: ['standing', 'walking', 'running', 'squatting', 'cycling', 'waving', 'falling', 'fighting']

训练参数我用的实配如下：

python scripts/train.py \ --data config/data.yaml \ --model yolov8s.pt \ --epochs 200 \ --imgsz 640 \ --batch 16 \ --device 0 \ --optimizer AdamW \ --lr0 0.002 \ --lrf 0.01 \ --warmup_epochs 3.0 \ --patience 30

说几个参数的经验值。输入尺寸imgsz用640是性价比比较高的选择，行人属于中等尺度目标，再往上调1280对小目标有提升，但推理耗时几乎翻倍，实时的视频流场景扛不住。epochs我设200，配合early stopping（patience=30），基本上130到160轮就会收敛。学习率用默认的0.01在SGD上通常没问题，但我换AdamW时把初始学习率降到0.002，适应性更好，后期不容易震荡。

batch_size的选取要看显存。12G显存跑yolov8s、640输入，batch16比较稳妥。显存占用估算可以按batch * 输入分辨率相关常数来粗算，但最可靠的办法是先跑一个batch，用nvidia-smi看实际占用，再往上试探。如果遇到OOM，优先减batch，不要硬扛。

3.3 一键训练脚本与训练过程监控

所谓一键训练，核心就是把训练配置、数据校验、模型初始化、训练循环、结果评估、模型导出打包成统一入口。我写的train.py逻辑不复杂，但做了几个自动化处理：启动前自动校验数据集完整性（图片和标签数量是否对应、标签是否有越界坐标、类别索引是否越界），训练结束后自动跑验证集输出mAP指标，再把最优权重转成ONNX。

# scripts/train.py（精简版） import yaml from ultralytics import YOLO def check_dataset(data_cfg): with open(data_cfg) as f: cfg = yaml.safe_load(f) train_imgs = len(os.listdir(cfg['train'])) # 此处省略具体校验逻辑：图片文件夹和标签文件夹数量必须一致 return cfg if __name__ == '__main__': cfg = check_dataset('config/data.yaml') model = YOLO('models/yolov8s.pt') model.train( data='config/data.yaml', epochs=200, imgsz=640, batch=16, optimizer='AdamW', lr0=0.002, patience=30, project='runs/train', name='pedestrian_action', exist_ok=True ) # 自动导出ONNX best = YOLO('runs/train/pedestrian_action/weights/best.pt') best.export(format='onnx', imgsz=640, simplify=True)

训练过程中我建议盯几个指标：训练loss是否稳定下降、验证集mAP50是不是持续抬升、验证集loss有没有在后期反转向上。如果验证loss先降后升，训练loss还在降，那就是过拟合，把epochs往后砍，或者启用更强的正则化（weight decay调大、dropout打开）。如果loss从一开始就震荡不下降，大概率是数据问题——标签错乱、类别索引对不上、或者学习率太高。

正常训练结果出来的mAP50-95如果能在0.65以上，对这个8类行人动作数据集来说已经是不错的水平。mAP50能到0.85以上，单帧推理在GPU上8到12毫秒，基本满足实时检测的需求。

4. 70+改进创新点：涨点与发刊的两条腿

4.1 70+改进点的分类框架

标题里那个“70+全套改进创新点”是吸引人的点，但实际干过这个方向的人都知道，改进点不是堆上去就有用。我按改进作用对象把这些点分成几大类：主干网络结构改进、注意力机制改进、颈部特征融合改进、检测头改进、损失函数改进、以及后处理优化。

主干网络层面的常见思路包括在C2f模块里插入不同位置和类型的注意力模块、把标准卷积替换为重参数化卷积或可变形卷积、引入多分支结构提升特征表达。注意力机制是最常见也最稳妥的涨点手段，通道注意力、空间注意力、混合注意力、频域注意力各有侧重，插到主干的不同位置效果差异很大。颈部改进主要围绕BiFPN式的加权双向特征融合，或者增加跨层连接让深层语义和浅层细节更好融合。

检测头改进集中在解耦头结构再设计、增加小目标检测头（P2层）、引入Transformer attention到检测头。损失函数改进是发论文的重灾区，IoU系列的变体多，各种加权方式层出不穷。后处理优化主要是NMS的改进，比如Soft-NMS、DIoU-NMS在密集行人场景下能明显减少漏检。

4.2 三个典型改进点的原理与实测

我这里挑三个我实际加过、有明确收益的改进点展开说，方便你理解这类改进的“套路”。

第一，注意力机制注入。我在backbone的C2f模块之后接了一个轻量级的混合注意力模块，同时建模通道间依赖和空间位置关系。原理并不复杂，通道注意力通过全局平均池化压缩空间信息，得到一个通道维度的权重向量，把重要的特征通道放大；空间注意力则反过来压缩通道信息，得到空间维度的权重矩阵，把重要的像素位置放大。两者串行组合，计算开销增加很小（整个模型多了大概0.5M参数），但验证集mAP50有1.2个点的提升。注意力的插入位置不是随便选的，插在浅层会影响底层纹理特征，插在深层会影响语义特征，我测下来在P3、P4层的输出位置效果最均衡。

第二，损失函数改造。原始CIoU损失在目标框回归中表现已经不错，但对边界框质量差异不够敏感。我在回归分支换成了Wise-IoU风格的动态加权策略，核心思路是根据预测框和真实框的重合质量动态调整梯度权重——高质量样本给稳定梯度，低质量样本和异常框给小权重，从而降低错标框对训练的干扰。这个改动在数据不太干净的时候收益特别明显，我的实验里训练loss曲线更平滑，最终mAP提升了0.8个点。

第三，增加小目标检测层。YOLOv8默认从P3层开始检测，对远处的小行人目标比较吃力。我在颈部增加了一个P2检测层，利用更高分辨率的浅层特征图专门负责小目标检测。代价是计算量增加约20%，但小目标上的召回率提升非常可观，测试集里像素面积小于32x32的行人目标召回率从0.52涨到0.74。如果你的部署场景以近距离监控为主，这个改进优先级可以往后放，因为收益不直观。

4.3 创新点组合策略与消融实验方法

做过论文实验的人都懂，改进点组合不是越多越好。把十几个改进全部塞进网络，训练时间翻倍、推理速度下降，最后mAP可能只涨零点几个点，还因为模块之间相互干扰而说不清楚各自贡献。

我的建议是采用递进式组合。先确定一个基线改进（比如注意力模块），训练一轮看涨点；再在基线上加第二个改进，看增量收益是正还是负。如果两个改进加一起反而负收益，很可能是功能重复，比如两个注意力模块作用维度一致，抵消了各自效果。论文里的ablation表本质就是这个过程的结构化记录——让每个模块的贡献可解释、可对比。

注意：同一种改进在不同数据集上的表现可能方向相反。我见过有人把一个在密集检测数据集上很有效的注意力模块搬到行人动作识别里，结果训练集loss正常、验证集mAP掉了，原因就是这种注意力过度关注了局部纹理，忽略了全局动作语义。所以任何改进都必须在自己的数据集上跑验证，不要盲目照搬别人论文里的结论。

发刊这块，动作识别方向比较看重的是：改进点的motivation是否清晰（你为什么要改）、模块设计是否简洁有效、对比实验是否完整、可视化结果是否直观。很多人在可视化上栽跟头——热力图和检测框图画得粗糙，审稿人第一印象就差了。我的经验是，每个改进点都要生成对应的特征热力图对比（用过Grad-CAM类的工具），把改进前后的响应差异展示清楚，这部分工作要直接写进项目源码里，作为一个可视化脚本。

5. Web前端展示：让模型能力真正可用

5.1 部署架构选型：后端推理服务 + 前端展示页

模型训练完只是第一步，要让别人能直观看到效果，必须有一个前端界面。我先说一下架构选型：后端用Python的FastAPI框架做推理服务，负责加载模型、接收视频流、执行推理、返回结构化结果；前端用Vue这类框架写页面，通过WebSocket接收实时推流和检测结果，再配合图表库画统计面板。

这里有一个重要的设计取舍：是前端直接调Python推理，还是前后端完全分离。我的建议是前后端分离。前端页面上传到服务器，和后端推理服务放在同一个域名下两个路径即可。推理服务这一层最好封装成独立的HTTP/WebSocket接口，这样哪怕以后换成Flask、换成Java后端，前端完全不用动。

为什么不直接在模板渲染里写死模型调用？因为项目一旦要扩展，比如同时接入多路摄像头、支持多个模型切换，分离架构的扩展性要远好于单体应用。我后来加一路摄像头的接入只花了半天，就是得益于接口和服务分离。

5.2 后端推理服务实现要点

后端推理服务有几个核心细节值得注意。一是模型加载和推理的线程安全问题。PyTorch模型在多个线程并发推理时如果不做控制，轻则性能下降，重则爆显存。我用了全局锁配合批处理：同一时刻只允许一个推理任务执行，其他请求排队。对单路视频流场景这种设计完全够用，如果是多路并发就要考虑异步推理队列。

# server/main.py（核心逻辑示例） import cv2 import numpy as np from ultralytics import YOLO from fastapi import FastAPI, WebSocket import threading app = FastAPI() model = YOLO('runs/train/pedestrian_action/weights/best.onnx') infer_lock = threading.Lock() action_names = ['站立', '行走', '跑步', '下蹲', '骑自行车', '挥手', '摔倒', '打架'] @app.websocket('/ws/video') async def video_stream(ws: WebSocket): await ws.accept() cap = cv2.VideoCapture(0) # 实际部署时替换为RTSP流地址 while True: ret, frame = cap.read() if not ret: continue with infer_lock: results = model.predict(frame, imgsz=640, conf=0.35, verbose=False) # 封装检测结果：类别、置信度、坐标框 boxes = results[0].boxes detections = [] for box in boxes: cls_id = int(box.cls[0]) conf = float(box.conf[0]) xyxy = box.xyxy[0].cpu().numpy().tolist() detections.append({ 'action': action_names[cls_id], 'conf': round(conf, 3), 'bbox': [round(v, 1) for v in xyxy] }) # 发送给前端 await ws.send_json({'frame_id': frame_id, 'detections': detections})

视频流处理这里有个关键优化：抽帧策略。摄像头25帧到30帧每秒，但动作识别不需要每帧都推理。我按时间间隔抽样推理，比如每秒推理5次，其他帧直接透传显示不做检测。这样做的好处是CPU和GPU负担大幅降低，画面流畅度也更好。对于摔倒这类瞬时动作，5Hz的抽样频率已经足够捕捉到关键姿态。

置信度阈值conf我调到了0.35。这里需要解释一下：阈值设置太高会导致漏检，太低会产生大量误检。动作识别里漏检的后果比误检严重——摔倒没报出来是重大事故。所以工程部署时我会把阈值调低一些，再在后端加一个“连续N帧识别到同一行为才触发告警”的时序平滑逻辑，来过滤单帧误检。

5.3 前端页面设计与实时展示效果

前端页面布局我分了三个区域：中间是实时视频画面，左侧是行为识别结果列表（每帧检测到的人和动作标签），右侧是统计面板——各类行为出现的次数、占比饼图、拥挤度曲线和告警记录。配色以深色监控风格为主，告警信息用高亮色文本标出。

视频展示这块实现起来有个选择：把解码后的视频帧通过网络传过去，还是前端直接播放标准视频流。我前端用WebSocket接收后端传过来的JPEG编码帧，在Canvas上绘制，同时叠加检测框和标签。这样做的好处是检测框、标签和画面对齐简单，因为render信息就是基于同一帧生成的。如果分开两路，前端播放RTSP流、WebSocket只传检测结果，还得自己同步时间戳，麻烦得多。

// web/main.js（视频帧渲染核心片段） const ws = new WebSocket('ws://' + location.host + '/ws/video'); const canvas = document.getElementById('videoCanvas'); const ctx = canvas.getContext('2d'); ws.onmessage = async (event) => { const data = JSON.parse(event.data); if (data.image) { const img = new Image(); img.onload = () => { ctx.drawImage(img, 0, 0, canvas.width, canvas.height); drawDetections(data.detections); }; img.src = 'data:image/jpeg;base64,' + data.image; } updateStats(data.detections); };

实时统计面板我用的是纯前端方案，每收到一条检测结果就更新一次计数器和图表。整个页面做到60FPS流畅刷新完全够用，不需要额外的图表服务端渲染。前端这块最花时间的其实不是画框和统计，而是页面在不同显示器分辨率下的自适应布局，我最终用了一套栅格布局配合媒体查询把桌面端和宽屏监控大屏都兼容了。

6. 常见问题与排查技巧实录

6.1 训练阶段的典型问题与排查清单

我把这几轮实操里最常遇到的问题整理成一张速查表，都是真实撞过墙才总结出来的。

最隐蔽的一个坑是数据集里图片和标签文件名不完全一致。我中途换过一次标注版本，有一批标签文件复制时丢了，训练脚本校验时图片数量比标签多几十张，模型虽然能训练，但没标签的图片在损失函数里没有对应监督，等于白喂。后来校验逻辑里强制要求图片和标签一一对应，数量不一致直接报错，宁可停下来补数据也不稀里糊涂跑下去。

6.2 部署阶段的推理性能问题

部署到实际视频流之后，性能问题比训练阶段更折磨人。最常见的现象是：模型单独测试很快，接到视频流里就卡顿、延迟高。原因往往不是模型推理本身，而是整个链路里某个环设计不合理。

我的排查顺序是这样的：先看推理耗时是否正常，用一条测试脚本直接对单帧图推理，如果单帧要50毫秒以上，说明模型剪枝、量化、换TensorRT都还没做，先解决模型速度。如果单帧推理正常而整个视频流卡顿，接着看帧读取和编码环节。OpenCV读RTSP流如果网络抖动，cap.read()会阻塞，必须加超时和重连机制。

编码传输也是个隐形瓶颈。后端把每一帧完整JPEG发给前端，如果分辨率大、图片压缩率低，WebSocket带宽会被打满。我实测1080P的JPEG帧约150KB，1秒传输10帧就是1.5MB的流量，普通内网没问题，跨公网就会出现严重延迟。解决方案有三个方向：降低传输分辨率（统一缩放到960宽）、提高JPEG压缩率、降低推理频率（每秒检测5次而不是10次）。实际我把三者组合后，延迟从700毫秒降到200毫秒以内，体验已经接近实时。

注意：Model predict默认会做整张图的标准化、缩放等预处理，如果视频流场景对延迟极度敏感，建议把预处理和推理这两步用原生部署框架来管理，避免每次推理都带上一整套框架开销。ONNX Runtime下的推理明显比直接用框架API快，实际部署一定要做格式导出。

6.3 标注质量导致的模型误判问题

训练集数据看着没问题，部署后误判频发，这类问题在动作识别里特别典型。我在测试阶段遇到过一个场景：大风吹动树叶、行人正常走路，模型连续报出“摔倒”。最后定位发现是数据集里“摔倒”类样本大量是躺在地上的静态姿态，而真实摔倒过程中有快速下坠的动作过渡，模型只学到了“人横躺在地上”这个外观特征，没学到“从站立快速变为横躺”的过程模式。

这个问题的深层原因是单帧检测模型的天然缺陷——它没有时序建模能力。工程上的对策是在后端加时序滤波：对每个跟踪目标维护一个行为状态队列，只有连续多帧（比如3到5帧）识别为同一行为才输出最终结果。这会牺牲一点响应速度，但能过滤掉绝大多数单帧噪声。如果项目对准确率要求更高，就应该上动作识别领域的时序模型，比如SlowFast、TSM这类双流或时序移位方案，把连续帧信息真正引入模型输入。

误判的另一大来源是类别间的外观相似。站立和蹲下的侧影有时很难区分，跑步和快速行走的边界也很模糊。除了增加这些相似类别的样本外，我还在标注规范里规定：模糊两可的统一归到更安全的类别。比如“跑步”和“快走”无法确定时归“行走”，避免模型被互相矛盾的标签搞混。这种策略牺牲了一点点细粒度精度，但换来了整体识别稳定性的提升。

7. 结尾想再啰嗦几句

做这套系统最深的体会是：行人动作识别看起来就是“目标检测+动作分类”，真正跑通一条链路之后才知道，数据标注的规范性、训练策略的细节、部署架构的取舍，每一环都能决定最终效果的上限。很多人拿到源码跑出来就以为万事大吉，但换到自己的场景、自己的摄像头、自己的光照条件下，原来的权重基本都要重新训练、重新调参。这也是我做这套“一条龙”方案时坚持要把数据标注规范、训练脚本、前端展示全部开源出来的原因——真正的价值不在于那一份权重文件，而在于你可以沿着这条链路替换自己的数据、扩展自己的改进点、改造自己的展示界面。

最后再分享一个小技巧：如果你打算在这个方向上继续深入，建议一开始就把实验记录习惯建立起来。每一次训练的参数、数据集版本、改进点开关、验证指标，都写进一个统一的记录文件里。我早期迭代的时候没有这个习惯，调了几十版参数，回头写报告的时候根本说不清楚哪个改动带来了哪个提升。后来老老实实按实验编号归档，论文实验表格那一部分几乎就是现成的内容，省了太多返工的力气。这套方法不止适用于算法项目，任何需要反复试错的开发工作都值得借鉴。