1. 从 SORT 到 Deep OC-SORT先搞清楚它在解决什么问题多目标跟踪MOT这几年一直是计算机视觉里“看着简单、做起来头疼”的方向。输入一段视频检测器把每一帧的行人、车辆框出来跟踪器负责把这些框串成一条条轨迹还要给同一个目标分配稳定的 ID。听起来像是“把检测结果连起来就行了”但真做起来遮挡、漏检、目标交错、摄像头抖动、低帧率任何一个环节出问题ID 就会乱跳轨迹就会断。你可能遇到过这种情况检测器 mAP 很高一上跟踪器MOTA 却惨不忍睹ID Switch 多到没法看。Deep OC-SORT 就是冲着这个问题来的。它是 OC-SORTObservation-Centric SORT的深度关联版本核心思路很直接不要过度相信滤波器的预测位置要相信观测本身也就是检测框。在此基础上它又引入了外观特征Re-ID embedding辅助数据关联专门解决遮挡后 ID 恢复、目标交叉时跟丢这类经典痛点。这篇文章我会从原理、配置、调优、指标验证、性能优化几个维度完整讲一遍适合两类人看一类是刚接触 MOT、想在自定义数据集上把精度跑上去的同学另一类是已经在用 SORT / ByteTrack但被 ID Switch 和轨迹断裂折磨得够呛想换一个更稳的方案的人。2. Deep OC-SORT 的核心原理为什么“观测中心”这四个字这么重要2.1 先看 SORT 和它的老毛病SORT 的思路很简洁检测器输出检测框卡尔曼滤波器预测目标在下一帧的位置然后用 IoU 做匹配。速度快、工程简单但它有两个硬伤。第一个硬伤是“线性运动假设”。卡尔曼滤波器假设目标在短时间内做匀速直线运动一旦目标突然转弯、急停、被人挡住再出现预测位置就和真实位置差得远IoU 匹配直接失败。人群里两个人交错而过SORT 经常把 ID 换掉就是因为预测框和检测框对不上。第二个硬伤是“误差累积”。目标被遮挡时没有新的检测观测来修正滤波器状态卡尔曼滤波器只能靠运动模型往前推。遮挡时间越长预测位置漂移越严重等目标再次出现时预测框已经偏到不知道哪里去了。这时候再来一个新检测框SORT 会把它当成新目标原来的轨迹就断了。这两个问题在行人密集场景里几乎是必然发生的。MOT17、MOT20 这些基准数据集考验的恰恰就是这种场景。所以 SORT 的简单高效是有代价的它在遮挡、密集、运动非线性场景下并不稳。2.2 OC-SORT 的做法把“观测”当作锚点OC-SORT 的论文我建议直接读一遍标题已经说明了一切Observation-Centric SORT重点是“以观测为中心”。它的核心观点是滤波器的预测值不一定可靠但检测器输出的观测值也就是检测框是可验证的在关联时应该优先依赖观测。围绕这个观点OC-SORT 做了四个关键设计每一项都是在补 SORT 的洞C-MOTIONObservation-Centric Momentum用“观测的方向”代替“滤波器预测的方向”来估计目标运动趋势。它不再只依赖卡尔曼滤波器内部状态而是用最近几帧的观测位置计算运动方向作为关联时的先验。这样做的好处是当目标确实在做非线性运动时跟踪器不会因为一条不准确的运动模型把关联带偏。ORUObservation-Centric Recovery当目标从遮挡中恢复时用新观测来校准轨迹位置。简单说如果一条轨迹处于“丢失”状态一旦出现一个可靠的检测框和这条轨迹的历史特征或位置对得上就把它“拉回来”而不是直接放弃这条轨迹。这个机制专门解决轨迹断裂后无法恢复的问题。OCRObservation-Centric Re-Update在轨迹和检测完成一轮匹配后用匹配上的检测框重新更新卡尔曼滤波器状态而不是让滤波器只依赖自己的预测。这个设计减少了滤波器累积误差让跟踪器对检测噪声更鲁棒。OCMObservation-Centric Momentum for Camera Motion针对摄像头运动场景用全局运动补偿来修正检测框坐标。摄像头抖动或移动时所有目标在图像上的位置都会发生系统性偏移不补偿的话跟踪框会和检测框错位。OCM 本质上是做一个背景运动估计把坐标统一到同一参考系下再关联。这四个机制加在一起OC-SORT 在遮挡、密集场景下的稳定程度比 SORT 提升了一个档次。官方的 MOT17 结果 MOTA 可以跑到 78 左右比 SORT 高出一大截。但 OC-SORT 还有一个短板它只用了位置和运动信息做关联一旦两个目标靠得很近运动趋势又相似它还是容易认错人。2.3 Deep OC-SORT 补上的最后一块外观特征Deep OC-SORT 的定位很明确就是在 OC-SORT 做足运动模型的基础上引入外观 embedding 来提升关联的区分度。它可以理解为 OC-SORT 的一个扩展配置当你的检测器能同时输出检测框和外观特征时跟踪器在计算代价矩阵时不再只用 IoU而是把外观相似度也放进去两者加权求和后再做匈牙利匹配。这个设计最大的价值在于检测和特征提取共用同一个骨干网络几乎不增加额外推理时间。很多人一听到 Re-ID 就觉得要单独跑一个特征提取模型算力翻倍。Deep OC-SORT 的做法不是这样它依赖检测器本身的中间特征通过一个额外的 embedding head 输出 512 维的外观向量。也就是说你只需要在训练检测器时多接一个分支推理时从同一个网络里把特征一起取出来成本非常低。外观特征解决的是什么问题我举个例子。密集人群里两个人擦肩而过运动轨迹短暂相交。纯靠 IoU 和运动模型跟踪器在交错瞬间很容易匹配错两个 ID 就换了。但如果两个目标的外观特征有差异代价函数会倾向于把检测框匹配给外观更接近的那条轨迹ID 就稳住了。这就是 Deep OC-SORT 在 MOT17、DanceTrack 这类数据上 IDF1 明显高于纯 OC-SORT 的原因。3. 环境配置与跑通基线从克隆仓库到第一份跟踪结果3.1 环境准备与依赖安装Deep OC-SORT 的官方实现集成在 OC_SORT 仓库里代码结构比较清晰分为检测器YOLOX、跟踪器tracker、评估TrackEval三块。安装步骤如下我用的是 Python 3.8 CUDA 11.3 PyTorch 1.11 的组合实测稳定。git clone https://github.com/yfeng95/OC_SORT.git cd OC_SORT conda create -n ocsort python3.8 conda activate ocsort pip install torch1.11.0cu113 torchvision0.12.0cu113 --extra-index-url https://download.pytorch.org/whl/cu113 pip install cython pip install -r requirements.txtrequirements.txt 里主要包含 opencv-python、scipy、numba、pycocotools、motmetrics、tensorboardX 这些常见库。装完后需要编译一些 Cython 扩展执行cd src python setup.py build_ext --inplace提示如果你在安装 numba 后遇到LLVM-related报错或者编译卡住的问题优先检查 numpy 版本是否与 numba 兼容。我之前用 numpy 1.24 和 numba 0.57 组合没问题升级到更高版本反而出现过编译失败。3.2 权重准备检测器权重和转换脚本Deep OC-SORT 依赖检测器输出“检测框 外观 embedding”。官方实验用的是 YOLOX-x 在 MOT17/MOT20 上训练的模型权重可以从仓库 README 里的模型列表下载。拿到的是 YOLOX 风格的权重文件需要先转换成跟踪器可加载的格式仓库提供了转换脚本python tools/convert_model.py --ckpt /path/to/yolox_x_mot17.pth.tar --out /path/to/ocsort_yolox_x_mot17.pth.tar如果你用的是自己训练的检测器那么关键问题是你的检测器有没有输出 embedding 的能力YOLOX 默认检测头只输出类别和框不带 Re-ID 分支。Deep OC-SORT 的官方配置是在 YOLOX 的 head 里加了一个 embedding head输出 512 维向量然后在训练时用 triplet loss 或者 softmax loss 拉近同类目标的特征。这个头部在官方仓库的yolox/models/yolox_head.py里有实现你在自定义训练时可以直接照着加。如果没有条件重新训练检测器也有变通方案单独用一个 Re-ID 模型为每个检测框提取特征然后改造成 Deep OC-SORT 的数据流。后面第 4 节我会讲接入方法但先明确一点共用主干是最省算力的方案单独跑 Re-ID 模型会让速度折损明显自己权衡。3.3 跑通官方 Demo配置好权重后先用官方 demo 验证整个链路通不通不要急着换自己的数据。命令如下python tools/demo_track.py \ --expn demo \ --fp16 \ --fuse \ --test \ --exp_file exps/example/mot/yolox_x_ablation.py \ --ckpt pretrained/ocsort_yolox_x_mot17.pth.tar \ --video /path/to/your/video.mp4跑通后你会看到检测框和跟踪 ID 同时标注在视频上。这一步能确认环境、权重、跟踪链路都正常。如果输出正常再进入自己的数据流程。3.4 自定义检测结果如何接入跟踪器Deep OC-SORT 的跟踪器本质上是一个“检测结果后处理模块”。它不关心检测框来自哪个框架只要按约定格式传入即可。每帧的检测结果通常组织为一个矩阵行代表目标列代表[x1, y1, x2, y2, score, cls]如果带外观特征就继续往后追加[embedding_0, embedding_1, ...]。在代码里你需要把检测结果喂给DeepOcSort的update接口。核心伪代码如下from tracker.deep_oc_sort import DeepOcSort tracker DeepOcSort( det_thresh0.4, max_age30, min_hits3, iou_threshold0.3, emb_dim512, emb_dist_thresh1.2, ) for frame in video_loader: dets detector(frame) # shape: [N, 6 emb_dim] tracks tracker.update(dets, frame_info)几个参数先有个印象下面会详细说含义det_thresh是检测框进入跟踪器的置信度门槛max_age是轨迹在丢失状态下的最大存活帧数min_hits是新轨迹最少需要连续命中多少帧才转正iou_threshold是 IoU 匹配的阈值emb_dim是外观特征维度emb_dist_thresh是外观距离的上限超过这个距离即使 IoU 很接近也不会匹配。4. 精度提升实战调优影响 MOTA 和 IDF1 的关键因素4.1 检测器才是精度的天花板这是我在实际项目里最大的体会跟踪器的精度上限由检测器决定。Deep OC-SORT 再强也无法凭空弥补检测器的漏检和误检。你去看 MOT17 榜单排名靠前的方法检测器几乎都是 YOLOX-x 或同级别的大模型。这不是巧合而是 MOTA 的计算方式决定的。MOTA 的公式是$$ MOTA 1 - \frac{FN FP IDSW}{GT} $$其中 FN漏检和 FP误检占主导IDSW 只是其中一项。如果检测器每帧漏掉 10% 的目标MOTA 直接少 10 个点跟踪器怎么调都补不回来。所以拿到一个新场景第一件事永远是优化检测器而不是调跟踪器参数。我踩过一个很典型的坑在一个低照度的室内监控场景里把 YOLOX-s 换成 YOLOX-x 后MOTA 提升了 6 个点而跟踪器参数一分没动。后来我又用 TensorRT 把检测器做了 FP16 加速在精度几乎不掉的情况下推理速度翻倍跟踪器的表现也跟着提升因为检测框更稳定了卡尔曼滤波器的输入噪声更小。4.2 核心超参怎么调阈值、max_age、min_hits跟踪器的参数不多但每一个都值得仔细调。det_thresh控制进入跟踪器的检测质量。设低了会有大量低置信度检测框进入跟踪器被迫处理噪声设高了会漏掉一些置信度不高的目标造成轨迹断裂。官方默认 0.4实际项目中我一般在 0.3~0.5 之间搜索。具体取多少取决于检测器的校准程度。建议做法是在验证集上画一张“置信度 vs 准确率”曲线找一个“误检率开始快速上升”的拐点作为阈值的起点。max_age控制轨迹丢失后能存活多久。目标被遮挡三五帧你希望它还能在恢复后重新接上就需要一个较大的值比如 30。但如果场景里经常出现短暂的误检被当成目标值太大就会形成残影轨迹干扰后续关联。密集场景我建议 10~15稀疏场景可以放到 30。min_hits控制新轨迹“考察期”的长度。太小容易把单帧误检直接当成新轨迹太大则真实新目标出现时要等待很久才有 ID。MOT 场景我一般取 3 左右。4.3 外观特征的接入方式与权重分配Deep OC-SORT 和纯 OC-SORT 的差别就在外观特征怎么用。代价矩阵可以写成$$ C \lambda \cdot C_{iou} (1 - \lambda) \cdot C_{emb} $$C_iou是 IoU 距离C_emb是外观特征距离通常是余弦距离或欧氏距离lambda是两者的平衡权重。默认配置下lambda在 0.5 左右但根据场景要调。我做过的实验经验是如果目标外观差异明显比如行人的衣服颜色、车辆的车型可以加大emb的权重ID Switch 会明显下降。但如果场景里所有人穿统一制服或者目标非常小、分辨率极低外观特征本身不可靠那就要降低emb的权重否则反而会引入错误匹配。另外emb_dist_thresh也要跟随权重一起调特征距离超过这个上限就禁止匹配。4.4 不同场景的针对性配置建议我用一张表总结一下不同场景下的配置倾向这都是实测过的经验值不是官方默认值你可以按需调整。场景特点det_threshmax_agemin_hitsemb 权重备注行人密集、相互遮挡多0.4~0.515~303~50.5~0.7优先保证轨迹不中断emb 辅助抗遮挡车辆稀疏、速度较快0.3~0.410~152~30.3~0.5运动模型为主emb 辅助纠错低帧率视频10fps 以下0.320~3020.6~0.8帧间位移大IoU 不可靠靠 emb 关联夜间/低照度低一点0.315~2030.4~0.5检测框噪声大阈值太高会漏检严重低帧率场景值得单独说。当视频帧率低时目标在两帧之间移动的距离可能超过自身尺寸IoU 直接为零这时候 SORT 和 OC-SORT 都会失效。解决方案就是加大外观特征的权重靠 Re-ID 特征跨帧匹配。我做过一个 3fps 的摄像头视频项目纯 OC-SORT 的 IDF1 只有 45换成 Deep OC-SORT 并调高 emb 权重后IDF1 直接到了 62差距非常大。5. 指标怎么算、怎么用从 MOTA 到 IDF1 的完整解读5.1 四个核心指标的含义与直觉多目标跟踪的评价体系比检测要复杂因为除了“框得准不准”还要看“ID 稳不稳”。四个指标分别回答不同问题MOTAMultiple Object Tracking Accuracy综合计算漏检、误检和 ID Switch 的惩罚数值越高越好。它代表了整体跟踪质量但也因为它把 IDSW 和检测错误混在一起有时候 MOTA 高不代表跟踪器真的“认人”认得准。IDF1ID F1 Score从“ID 分配是否正确”的角度计算精确率和召回率的调和平均。它衡量的是轨迹 ID 的一致性ID Switch 多的话 IDF1 会大幅下降。Deep OC-SORT 最擅长优化的就是 IDF1。HOTAHigher Order Tracking Accuracy近年来被 MOT Challenge 推荐的指标把检测精度和关联精度分别计算再结合比 MOTA 更均衡地评估跟踪质量。它分成了 DetA 和 AssA 两个子项检测误差影响 DetA关联误差影响 AssA这样可以定位问题到底出在检测还是关联。IDSWID Switch轨迹 ID 发生跳变的次数越少越好。这个指标最直观看视频时你的“体感”好不好基本就是 IDSW 多不多。5.2 用 TrackEval 在自定义数据集上评估官方仓库集成了 TrackEval在验证集上可以这样跑python tools/eval.py \ --expn eval_test \ --exp_file exps/example/mot/yolox_x_ablation.py \ --ckpt pretrained/ocsort_yolox_x_mot17.pth.tar \ --benchmark MOT17 \ --eval \ --fp16 \ --fuse如果你想评估自己的数据集需要把数据整理成 MOT Challenge 的格式核心是gt/gt.txt和seqinfo.ini。gt.txt每行是这样frame_id, track_id, x, y, w, h, is_marked, category, ...其中frame_id从 1 开始track_id是真实 IDx, y, w, h是边界框坐标和尺寸is_marked通常填 1category对于行人填 1。这里有一个新手最容易踩的坑边界框坐标必须和检测器输出保持一致。如果你的检测器输出的是x1, y1, x2, y2左上右下入评估前必须先转换成x, y, w, h左上角 宽高转换反了的话MOTA 会暴跌几十个点但你还不知道哪里出了问题。我刚开始跑评估时就吃过这个亏“为什么我的指标这么低”——结果只是坐标格式没对齐。5.3 指标解读的三个经验第一MOTA 和 IDF1 是此消彼长的。有些方法为了压 IDSW会让跟踪器更保守倾向于不开启新轨迹导致漏检变多MOTA 下降但 IDF1 上升。所以不要只看一个指标两个都要看还要结合 HOTA 判断整体水平。第二和 SOTA 对比时务必确认对比的检测器是什么。同一个跟踪器换一个更强的检测器MOTA 可以差 5~8 个点。别人用 YOLOX-x你用 YOLOX-s结果比不过非常正常问题未必出在跟踪器上。第三注意训练集和测试集的分布差异。MOT17 上表现良好的参数直接搬到园区车辆场景大概率要重新调。因为数据集的目标尺寸、密度、遮挡方式都不一样参数迁移是有风险的。6. 性能优化从推理提速到嵌入式部署6.1 先定位瓶颈跟踪器本身开销很小很多人在“性能优化”上乱使劲一上来就想着改跟踪器代码。但实际上 Deep OC-SORT 的数据关联部分非常轻量——卡尔曼滤波预测、IoU 计算、匈牙利匹配在几千个目标以内单帧耗时基本都是个位数毫秒级别。瓶颈几乎永远是检测器。用工具实测一下最直接。在 N 卡上用nvidia-smi看 GPU 利用率用time命令统计单帧耗时。我做过一次 profilingYOLOX-x 推理占单帧总耗时的 80% 以上而跟踪器 update 只占不到 10%。所以性能优化的大头必然在检测器那边。6.2 检测器加速的四个手段第一个手段是半精度推理。YOLOX 支持 FP16在主流 GPU 上可以带来接近一倍的推理加速同时检测精度几乎不退化。只需要在 demo_track 或自定义推理脚本中加上--fp16即可。如果追求极致可以用 TensorRT 做 INT8 量化但需要校准数据集精度会有一点点损失部署周期也更长。第二个手段是模型剪枝和轻量化。把 YOLOX-x 换成 YOLOX-s 或者 YOLOX-nano跟踪器的鲁棒性会发生什么变化我的经验是如果场景简单、遮挡少精度差距不大但一旦出现密集遮挡轻量模型漏检增加跟踪器会频繁断轨。所以轻量化模型的代价不在检测 mAP 上而在跟踪精度的稳定性上。第三个手段是跳帧推理。如果业务对实时性要求高可以每 2~3 帧跑一次检测器中间帧只做卡尔曼滤波预测和轨迹外推。这样检测器的计算量直接降低为原来的 1/2 甚至 1/3跟踪精度会有一定下降但往往在可接受范围内。这个方法尤其适合目标运动速度不快、遮挡不严重的场景。第四个手段是批量推理。如果服务器端处理多路视频流可以把多帧图像拼成一个 batch 输入检测器GPU 利用率会更高。注意 batch 大小要配合显存和模型大小我用 YOLOX-x 时 batch8 和 batch16 的耗时差距并不大但显存占用翻倍。6.3 嵌入式设备的落地经验Deep OC-SORT 本身不挑设备因为跟踪器的计算量很小纯 CPU 跑都没问题。真正要解决的是检测器的部署问题。我在 RK3588 上做过一次落地流程大致是先把 YOLOX 导出成 ONNX再用 RKNN-Toolkit 转成 NPU 可运行的模型。检测器跑到 NPU 上之后跟踪器在 ARM CPU 上跑整个系统能维持在 15fps 左右。嵌入式部署有几个细节容易踩坑。一是归一化方式要和训练时保持一致YOLOX 用的是 0~1 归一化有些 SDK 默认 0~255搞错了检测框会漂移。二是输出层的解析ONNX 导出的输出 tensor 格式可能是 [batch, num_anchors, 5 num_classes] 的排列需要先做 decode 再进跟踪器。三是内存管理长时间跑视频流时要复用缓存 buffer避免每帧重新分配大数组导致内存碎片。6.4 性能监控与验证优化做完了怎么验证效果不能只看 FPS还要同时看精度指标。我习惯的做法是固定一个验证集记录三组数据FPS、MOTA、IDF1。每次优化完成后跑一遍记录下来画一张表。你会发现有些“优化”实际上是把精度换成了速度这时候就要回到业务需求去权衡是 30fps 65 MOTA 更好还是 15fps 70 MOTA 更好这没有标准答案但你不做记录、不做对比就没法做决策。7. 常见问题与排查技巧实录7.1 ID Switch 频繁这是最最常见的反馈。排查思路按步骤来先判断是检测框抖动导致的还是关联错误导致的。方法很简单把检测框渲染在视频上关掉跟踪 ID 显示只看检测框是否在目标身上稳定跟随。如果检测框本身就来回抖说明检测器后处理NMS 阈值、类别阈值需要优化。如果检测框稳定但 ID 乱跳才是跟踪器的关联问题。关联层面优先检查外观距离阈值emb_dist_thresh是不是太宽松。我调过的一个案例就是特征距离阈值设成了 1.5结果不同外观的目标也能匹配上ID 乱得离谱压到 1.0 之后立马好转。其次是检查 IoU 的阈值如果设得太低相距很远的目标也能匹配上同样会导致 ID 混淆。还有一个容易被忽略的原因检测框坐标没有做平滑帧间抖动大。图像增强、摄像头自动曝光、HDR 切换都可能导致检测框位置在连续帧间跳变。可以考虑在进跟踪器之前对检测框做一次轻量平滑或者在图像层面做去抖。7.2 轨迹频繁断裂和重连轨迹断裂通常和max_age、min_hits设置有关。如果目标只是短暂被遮挡max_age太短会导致轨迹直接被删掉。我的排查顺序是先看断裂是发生在遮挡点还是随机位置。如果是在遮挡点就把max_age调大比如从 15 调到 30如果随机位置也断就要看检测器是不是存在间歇性漏检。另一个原因是低频目标。小目标在图像中只有几十个像素检测器对这种目标的输出本就不稳定会出现“有一下没一下”的情况。解法有两个一是专门训练检测器提高小目标的召回率二是把min_hits调低让跟踪器更容易接受短轨迹但这会引入噪声轨迹实际效果要看评估指标。7.3 跟踪速度达不到实时先按第 6 节的方法定位瓶颈。如果瓶颈确实在检测器考虑跳帧推理或模型轻量化。如果瓶颈在跟踪器通常是 numba 编译或者数据格式转换拖慢了速度。Deep OC-SORT 的 IoU 计算用了 numba JIT第一次调用会有一个编译延迟之后会快起来。如果多进程场景下速度不稳定检查是不是 numba 缓存和 PyTorch 的线程竞争资源可以限制 PyTorch 的线程数torch.set_num_threads(1)另外检测结果的 numpy 数组如果频繁从 GPU 拷贝到 CPU也会成为隐形的开销。建议尽量让检测器的输出直接以 tensor 形式传入跟踪器减少一次拷贝。7.4 显存不足和内存泄漏显存不足多半是模型太大或 batch 太大。用 YOLOX-x 跑 1080P 视频8G 显存会非常紧张建议降分辨率或改 FP16。内存泄漏通常是视频处理循环里没有正确释放历史帧数据或者跟踪器内部的轨迹列表不断增长。记得定期清理超过max_age的轨迹否则长时间运行内存会缓慢爬升。我之前遇到过一个看似奇怪的问题跑了 20 分钟后跟踪开始变卡。查了下是cv2.VideoCapture读帧后没有release同时视频帧的 ndarray 被保存在一个列表里没删。清理掉之后连续跑了 8 小时内存占用保持稳定。7.5 numba 编译和相关报错ModuleNotFoundError: No module named numba之类的问题直接按 requirements 重装即可。如果遇到TypingError或者版本不兼容导致的编译失败可以先设一个环境变量禁用 JIT确认是 numba 的问题还是代码的问题export NUMBA_DISABLE_JIT1禁用 JIT 后 IoU 计算会变慢一些但可用于排查。确认是版本兼容问题后再对齐 numpy、numba 和 Python 版本。8. 最后分享一点我的实际体会做了好几个 MOT 项目之后我越来越觉得 Deep OC-SORT 是一个“性价比”很高的追踪器。它没有特别复杂的结构不像一些端到端方法那样对训练数据和算力要求苛刻但它在遮挡、交叉、低帧率这些真实场景里确实比 SORT 系的老方法稳定太多。尤其是外观特征共用检测器主干这个设计让我在做工程部署时省了很多力气不用额外维护一套 Re-ID 模型。如果你准备在自己的项目里用 Deep OC-SORT我的建议是第一步先不加任何调优把官方权重在自己的测试视频上跑一遍看效果、看速度建立 baseline第二步优化检测器把 mAP 和漏检率降到可控范围这一步通常能带来最大的收益第三步再动跟踪器参数抱着一两个指标MOTA、IDF1微调即可不要一上来就想着每个参数都调一遍。最后各种优化手段都做完了记得把结果记录下来哪怕只是简单的一张表也能帮你清楚知道每一步改动到底带来了什么。