多目标跟踪(MOT)原理与实战：SORT、DeepSORT、ByteTrack选型指南

写多目标跟踪MOT这几年我最常被身边朋友问的一句话是检测框不是已经有了吗为什么还要单独做一个Trackers模块这问题特别典型相当于你问我“人脸都认出来了为什么还需要身份证”。检测框只告诉你“这一帧里有个目标”但它不告诉你“这个框是刚才第37号那个人还是新入场的人”。多目标跟踪干的就是这件事给检测框发一张长期有效的身份证并且在整个视频里盯着他保证他不被冒名顶替、不把身份证弄丢。这期内容就围绕“给检测框发身份证”这条主线展开我把项目里用到的Trackers多目标跟踪原理、算法选型、工程实现和踩坑记录一次性串起来讲清楚。内容面向两类人一类是刚接触MOT、打算在项目里加跟踪能力的同学另一类是检测已经跑通、但被ID SwitchID切换和轨迹断裂折磨得头疼的工程师。看完之后你能搞懂SORT、DeepSORT、ByteTrack这些主流tracker到底在算什么也能直接参考我的工程配置把一套基础的多目标跟踪流水线跑起来。先说明一件事有朋友看到“Trackers”这个词第一反应是比特彗星这类下载工具里填的那个tracker列表。这两者完全不是一回事。下载工具里的tracker是BT协议中用来协调各客户端互相发现、交换数据的调度服务器而视觉里的tracker是视频感知里的“跟踪器”模块负责把逐帧的检测框串联成持续存在的目标轨迹。我在这篇里说的只涉及后者。1. 先搞清楚“Trackers”到底在跟踪什么1.1 任务拆解MOT不是单模块而是检测加关联多目标跟踪Multiple Object Tracking简称MOT的标准做法是把任务拆成两步第一步是目标检测在每一帧图像里找出所有目标输出一组检测框第二步是数据关联把当前帧的检测框和历史轨迹接起来判断哪些框属于同一个人或同一个物体。Trackers这个词一般指第二步里的核心算法模块但实际工程里它是包围检测结果、特征提取和运动预测在内的整套机制。你可以把检测理解成“这一帧里发现了几个人、分别在哪个位置”把跟踪理解成“这些位置对应的是几号人”。检测的输出是“帧内”信息跟踪的输出是“跨帧”信息。如果只做检测不做跟踪视频里一个人走两步、停一下他的框就每帧重新编号一次下游的计数、行为分析、轨迹回放全都没法做。MOT还有一个分支叫SOT单目标跟踪两者的区别很关键。SOT在第一帧给定一个目标框后面所有帧只追这一个目标不负责发现新目标MOT则是全程自动每帧都要同时处理新目标出现、旧目标消失、目标之间互相遮挡这些情况。正因为要自动处理目标的增删和遮挡MOT的数据关联才需要一套更完整的生命周期管理机制。1.2 核心痛点ID Switch才是难啃的骨头做MOT的人嘴里最常说的一句黑话是“这个ID稳不稳”。这里说的ID就是目标在整个视频片段里唯一编号相当于身份证号。跟踪算法做得好不好最直观的指标就是ID有没有频繁切换明明是同一个人走了一段路之后编号从3变成了17这就叫ID Switch也就是我常说的“身份证被换了”。ID Switch出现的原因基本可以归为三类检测框漏检导致轨迹中断、目标之间互相遮挡导致身份混淆、匹配算法在两种特征冲突时做出了错误取舍。最典型的一幕是两人交叉走过在交叉点之前A在左B在右交叉的一瞬间两个框重叠交叉之后A到了右边算法却把A原来的ID给了B。这就是身份交换跟踪效果差的视频里这种错误会刷屏。所以多目标跟踪本质上不是在“画框”而是在“守身份”。所有算法改进——不管是卡尔曼滤波、外观特征提取还是两级匹配策略——目标都是同一个让ID在遮挡、运动模糊、检测报警抖动的情况下依然能保持连续。1.3 把跟踪器放到完整感知链路里看我画了一条完整的感知链路视频流进入检测模型输出第t帧的检测框集合检测框经过预处理和第t-1帧维护好的轨迹集合一起送进匹配模块匹配模块用重叠度、运动预测、外观相似度等信息计算代价矩阵再用匈牙利算法做最优分配分配完成后匹配上的轨迹更新位置没匹配上的轨迹进入“待定”状态等下一帧再找机会续上太久没匹配上的轨迹直接删除释放ID。这条链路里检测模型的质量决定了跟踪的天花板。检测频繁漏检再好的关联算法也救不回来因为派不由“无米之炊”。反过来也一样检测每帧都很准但关联算法不会分配那就会看到同一批人每帧换一个编号等于白做。2. 给检测框“发身份证”的核心机制拆解2.1 数据关联用IoU把新框和旧轨迹绑在一起数据关联要解决的问题是当前帧有20个检测框上一帧留下了15条轨迹这20个框分别对应这15条里的哪几个最简单的办法是直接看几何重叠度。假设一条轨迹t在上一次更新时有个框位置是(x1, y1, x2, y2)当前帧检测出一个新框把这两个框做交并比Intersection over UnionIoUIoU越高说明两个框重合度越大越可能是同一个目标。IoU关联在目标低速移动、相机不抖的场景下极其好用因为它只靠位置信息不需要额外跑特征提取网络速度非常快。但它的短板也很明显如果目标跑得快上一帧和下一帧的框完全不重叠IoU就变成0关联直接失败。这时候就需要运动预测来“猜”一下目标在当前位置用上一帧的位置结合目标的速度推算出这一帧可能出现在哪里再用预测框去和检测框计算IoU。实际工程里我会用一个经验值IoU阈值一般设在0.3到0.4之间低于这个值就不算同一个目标。阈值太高容易漏关联目标稍微动得快一点就断轨迹阈值太低又容易乱关联挨得近的两个人框重叠度不高也强行绑在一起。要根据自己视频里目标的大小和运动速度去调。2.2 匈牙利算法解决“一个框只能跟一条轨迹”的分配问题有了IoU或其他特征算出来的代价矩阵下一步就是做“最优分配”。这里的难点在于约束条件一个检测框只能分配给一条轨迹一条轨迹也只能接受一个检测框一个目标不能同时拥有两个身份证这是硬性条件。这类问题在计算机里是有标准解的——匈牙利算法。它做的事情可以这么理解假设有3条轨迹、3个检测框每对组合都有一个匹配代价匈牙利算法能在多项式复杂度内找到一个总代价最小的配对方案且严格满足一对一约束。相比之下贪心算法虽然更快但它每步只看当前最优解很容易出现“强者通吃”的局部最优问题。比如轨迹A和轨迹B同时靠近检测框C贪心先把C给了重叠度更高的AB就只能干等着下一帧B就断了。匈牙利算法则会考虑全局宁愿让A匹配代价稍高一点的那个框也不让B被饿死。DeepSORT和ByteTrack的后端都用了匈牙利算法区别在于它们构造的代价矩阵不同。DeepSORT使用外观特征的马氏距离和运动预测的IoU做加权组合ByteTrack则干脆用IoU做单一代价。代价矩阵怎么构造决定了匈牙利算法拿什么牌去发身份证。2.3 卡尔曼滤波像导航软件一样持续修正轨迹预测给检测框发身份证光靠当前帧的位置还不够。更稳的做法是让每条轨迹拥有一个“运动模型”能够预测它下一时刻的位置。这时候就要请出卡尔曼滤波Kalman Filter。卡尔曼滤波的直观理解就是手机导航里的路径预测它根据你上一时刻的位置和速度先预测下一个点在哪等到新的GPS信号也就是新的检测框来了再拿预测值和观测值做加权融合得到一个修正后的更准位置。这个“预测-修正-再预测-再修正”的循环正是卡尔曼滤波的核心。在MOT里卡尔曼滤波通常会维护一个8维状态中心点坐标、宽高比、高度以及它们各自的速度分量。整个工作过程可以分成两步预测步用上一帧的状态和恒速运动模型推算当前帧的预测框位置。更新步用当前帧匹配到的检测框来修正预测值让轨迹位置更贴近真实目标。这套机制在目标做匀速直线运动时效果很好但遇到突然转弯、急停急走恒速模型的假设就不成立了预测框会明显偏斜ID切换率也会上升。这就是为什么后面很多改进算法的重点不是换掉卡尔曼滤波而是让预测更“懂”目标运动的不确定性。3. 主流通用Trackers算法全景与选型建议3.1 SORT开山最朴素的“只用位置”方案SORT是很多人入门MOT的第一个算法全称Simple Online and Realtime Tracking特别能体现它的气质简单、在线、实时。SORT顺理成章地组合了检测、卡尔曼滤波和匈牙利算法用IoU做关联不需要任何外观特征。因为只算几何信息SORT速度非常快在CPU上就能跑是很多实时系统的底线方案。但SORT有个很明显的代价ID切换非常普遍。因为一旦目标被遮挡或者检测漏了几帧原本的轨迹可能丢了等目标重新出现时SORT只看到新检测框和旧轨迹已经彻底断联只能给他发一张新身份证。SORT适合用在场景相对简单、目标运动平稳且遮挡少的固定摄像头监控里比如仓库里的叉车任务、单通道排队场景。3.2 DeepSORT给身份证加了“人脸”防伪标识既然SORT纯靠位置容易认错人那自然想到给每条轨迹加一个外观特征作为“防伪标识”。DeepSORT就是在SORT的基础上引入一个ReID行人重识别特征提取网络。具体来说每条轨迹会保留一个由多个历史外观特征取平均得到的特征向量每个新检测框也会算出一个特征向量。匹配时除了IoU的几何关系还要计算外观特征的余弦相似度两者加权作为最终的代价矩阵。有了外观特征的加持DeepSORT在目标被短暂遮挡、重新出现后能靠“长相”把ID接回来而不是直接发新证。这是它相对SORT最大的改进。代价在于多跑了一个ReID网络计算量明显上升同时在目标尺度特别小、图像模糊时重识别特征并不够可靠反而会带来额外的误匹配。DeepSORT最适合行人为主、摄像头角度固定、遮挡较多的场景是很多智慧零售、客流统计项目里的默认选择。3.3 ByteTrack让低置信度检测框不再被白白扔掉ByteTrack是我在不少项目里最终落地的算法它的思路特别接地气大多数检测器输出框时会带一个置信度分数传统做法是设定一个阈值低于阈值的框直接扔掉只留高置信度的框去做关联。但问题在于当目标被遮挡或者较远时检测器给出的置信度本来就会降低这些低置信度框恰恰可能对应着真实的被遮挡目标。如果一扔了之这些轨迹就断了ID切换自然变多。ByteTrack的解决办法是分两阶段匹配第一阶段把高置信度检测框与现有轨迹做关联用的是跟踪框和检测框的IoU第二阶段把第一阶段没匹配上的轨迹再用低置信度检测框去关联一次试图找回那些被遮挡的目标。这样既保证了正常移动目标的准确跟随又尽量让被短暂遮挡的目标不掉线。ByteTrack没有引入重识别特征结构相对简单在MOT17等数据集上表现突出是“花小钱办大事”的典型案例。3.4 其他改进方案与最终选型速查表除了上面三个经典算法近几年还涌现出一批针对性改进。OC-SORT针对“运动非线性”问题在匹配时加入了“观察中心性”约束有效减少目标在遮挡后轨迹插队、错位的情况BoT-SORT则在ByteTrack基础上融合了相机运动补偿ECM以及更强健的外观特征让结果更平滑StrongSORT在DeepSORT基础上加入了更强的ReID、轨迹插值和矫正模块主打离线场景下刷高分。算法并没有绝对的好坏只有适不适合你的场景。我给自己的项目做选型时会按照下面这个思路来场景特点推荐方案理由实时性优先、目标少且运动平稳SORT计算量最小延迟可接受行人为主、遮挡频繁、对象外观差异明显DeepSORT外观特征能显著减少ID切换检测质量波动大、目标经常被遮挡ByteTrack两级匹配策略能“捞回”低置信度目标监控场景有相机轻微晃动BoT-SORT加入了相机运动补偿更抗抖离线分析、追求高准确率、不苛求实时StrongSORT可以牺牲速度换更精确的轨迹高速路、车辆少、车速极快OC-SORT对运动模型假设要求更贴合动态场景这个表格只是起点真正干项目时我会先用ByteTrack慢跑一两组数据统计ID Switch出现的位置再判断要不要升级到带ReID或相机补偿的版本。不要一上来就在所有算法里反复横跳那样只会浪费时间在调参而不是解决问题的根源上。4. 跑通一个实际工程结构、代码与调参记录4.1 一个最小MOT工程长什么样我习惯把整个工程拆成四个文件detector.py负责接入检测模型、tracker.py负责轨迹管理和匹配、visualizer.py负责画框和ID、main.py串联整个流程。下面是一段高度精简但结构完整的伪代码展示在main里每帧的处理逻辑class ObjectTracker: def __init__(self): self.tracks [] # 活跃轨迹集合 self.next_id 1 # 身份证号发号器 self.max_age 30 # 轨迹连续多少帧没匹配就删除 self.min_hits 3 # 轨迹至少连续命中几帧才对外公布 def update(self, detections): # 1. 用卡尔曼滤波预测所有轨迹在当前帧的位置 for trk in self.tracks: trk.predict() # 2. 第一阶段高置信度检测框与轨迹做IoU匹配 matched, unmatched_trks, unmatched_dets \ self.match(self.tracks, detections, threshold0.3) # 3. 更新已匹配轨迹的状态 for trk_idx, det_idx in matched: self.tracks[trk_idx].update(detections[det_idx]) self.tracks[trk_idx].age 0 # 4. 第二阶段用低置信度检测框匹配未命中的轨迹ByteTrack思路 matched_low, unmatched_trks, unmatched_dets \ self.match_low(self.tracks, unmatched_trks, detections) # 5. 为仍未匹配的新检测框创建新轨迹发新身份证 for det_idx in unmatched_dets: new_trk Track(self.next_id, detections[det_idx]) self.next_id 1 self.tracks.append(new_trk) # 6. 清理超过max_age还没命中的轨迹回收ID self.tracks [trk for trk in self.tracks if trk.age self.max_age] return self.tracks这个框架虽然只有几十行但已经包含了所有核心步骤预测、匹配、更新、新建、删除。真实工程里match函数里会调用匈牙利算法和代价矩阵计算步骤2、4的匹配往往还要按score从高到低排列保证高置信度优先分配。4.2 轨迹生命周期出生、在册、失联和注销身份证不能乱发所以轨迹的生命周期必须管理清楚。我把一条轨迹的状态拆成四个阶段候选期新检测框出现时先给一张临时凭证连续命中几帧后转正避免把误检当成新目标。活跃期轨迹正常匹配持续更新位置和特征对外输出ID和bbox。失联期连续多帧没有匹配到任何检测框但还没超过阈值保留预测状态继续等待重新匹配。注销期失联超过阈值直接删除轨迹后续即使在同一位置出现目标也按新目标处理。min_hits这个参数非常容易忽略。我试过把min_hits设成1结果检测器一个误检冒出来就会形成一条假轨迹然后这个假ID会在画面里乱飘几秒调高到3到5之后单个孤立的误检基本就不会产生轨迹了。max_age则是给“遮挡记忆”设的时长步行场景下我通常设在25到30帧如果目标可能被立在眼前的卡车挡住很久我会调到60帧以上。4.3 关键超参对照表参数名推荐范围作用调参经验det_conf_thr0.4 ~ 0.6检测框置信度阈值调高会漏检调低会引入大量候选框需配合min_hits保护iou_thr0.3 ~ 0.4第一、二阶段匹配的IoU阈值目标速度快时调低目标密集时警惕误配max_age25 ~ 60失联轨迹最大存活帧数目标被遮挡频繁的场景要调大min_hits3 ~ 5新轨迹转正所需命中次数误检多时调大目标小且移速快时调小track_buffer30 ~ 120输出轨迹最多保留的帧数影响可视化拖尾稳定感不影响核心关联这组参数不是拍脑袋定的而是我在一个固定路口的行人视频上逐项调过的结果。核心思路是先用默认参数跑一遍把视频拖到出问题的那几帧看是“多了ID”还是“断了ID”再反向去调对应参数。调任何一个超参都要同时观察ID Switch率和MOTA变化不能只看tracking丢失的数量。4.4 可视化输出把轨迹画出来才能发现问题跟踪做完之后可视化不是摆设。我会在main里同时输出两个画面一个只画检测框和ID号另一个画轨迹尾巴用最近N帧的位置点连成线。别小看轨迹尾巴这几根线它能把匹配错误直观暴露出来如果两个人的轨迹线交叉但ID没有交换说明匹配基本没问题如果轨迹线突然断掉又从一个角度冒出来大概率是这里发生了ID Switch。一个人从左边走向右边他的轨迹点应该平滑地延展成一条曲线。一旦这条曲线上出现了一个明显跳变的“折角”那附近一定藏着一次错误关联。我甚至会在调试阶段把每个ID的轨迹点单独记录成JSON用脚本来统计ID Switch发生的帧号这样比肉眼盯视频高效得多。5. 实战中常见的坑与排查思路实录5.1 现象行人交替穿过时ID频繁互换这是提得最多的问题通常发生在两人相对而行、擦肩而过的瞬间。排查时我会先在视频里定位到ID互换的那几帧把检测框的置信度、轨迹预测框和检测框的IoU值全部打印出来。如果发现互换发生时IoU阈值正好都在临界点那说明是匹配逻辑分不清两个靠得太近的框这时候最好升级方案要么引入ReID特征计算外观相似度要么调低IoU阈值来减少错误关联。另一个思路是修改代价矩阵增大“运动预测”的权重两个人的运动方向相反即使位置重叠速度方向的差异也足以让匈牙利算法选择更合理的分配。我有时候会在代价矩阵里额外加一项“方向一致性约束”实测下来ID交换能有明显改善。5.2 现象相机轻微晃动导致轨迹乱跳固定摄像头并不等于画面静止。风把杆子吹得轻微晃动或者设备安装支架存在微小位移都会让整个画面周期性抖动。此时卡尔曼滤波的“恒速模型”会把相机抖动当成目标的真实运动轨迹预测位置不断偏移ID自然不稳定。处理思路有两个一是做相机运动补偿用视频前后帧的特征点光流算出一个全局仿射变换矩阵先把画面对齐再做tracking二是开启“检测框平滑”模式对同一轨迹的连续多帧检测结果做指数滑动平均降低单帧抖动的影响。BoT-SORT里集成的ECM模块就是干这件事的。遇到这个坑想靠调IoU解决基本没用。5.3 现象轨迹看起来一直贴着某个目标但框不对齐有时候跟踪没有ID中断但轨迹框和真实目标总有半个身位的偏移看起来像是尾巴拖着走。这种情况下问题大概率不在tracker而在检测器和卡尔曼滤波的“反应速度”上。卡尔曼滤波更新时会按比例把预测值和观测值融合如果卡尔曼增益偏低轨迹位置会更偏向预测值导致框移动滞后看起来像拖影。做法是把更新公式里的噪声参数适当调大让算法更信任检测结果而不是死守预测值。也可以直接在代码里删掉卡尔曼预测那一行只用检测框位置做更新看是不是就没有偏移。如果删掉后问题消失基本就能确定是运动模型参数背锅。5.4 现象不同类别的目标互相抢ID当场景同时出现人和车且类别多种时tracker最容易犯的一个错误是把一辆车的ID带到一个人身上。这是因为底层匹配只管框的几何重叠度根本不关心框里是什么类别。出现这个坑说明你的tracker没有把检测类别纳入关联条件。解法很简单在构造代价矩阵之前先按类别把检测框和轨迹分流。类别不同的检测框与轨迹直接不让它们参与匹配代价矩阵对应位置填一个极大值。这条规则在工程里是零成本高性能的改进永远不要忽略。5.5 现象目标长时间被遮挡后回来无法续上ID公交车把人完全挡住5秒人从车尾走出来此时旧轨迹早就超过max_age被删了。想续回ID就只能靠外观特征。但注意如果你用的是纯IoU方案那无论如何都不可能续回来如果用了ReID也要看特征检索的阈值是否合理——阈值太严同一个人的两次特征相似度也过不了门那就等于没有ReID。我从这个坑里学到的教训是目标被遮挡场景多的项目要么把max_age调得非常大要么干脆在frame级别做“全局特征重匹配”也就是在轨迹删除后不立即清除它的外观特征而是保留一个“休眠轨迹”列表定期用新检测框去和休眠轨迹匹配。这个思路类似于给目标发一张“可挂失”的身份证而不是人一消失就销毁记录。写在最后的一点个人体会和检测模型的训练调参相比多目标跟踪是个更需要“雕花”的活。检测网络指标看mAP就好而tracker好不好得看它在被遮挡、运动模糊、光照变化、相机抖动这些乱七八糟的真实场景里的整体表现。我做了几个项目之后最深的感受是一切跟踪技巧的前提是先把检测调理稳定tracker解决不了检测反复横跳带来的根本问题。现在我手里接新项目时会先花半天时间用ByteTrack跑一遍视频把输出结果里ID Switch的帧号统计出来再决定要不要上ReID、上相机补偿或者直接换OC-SORT。这样看起来绕了一圈实则是效率最高的路径——你永远不知道自己的计算瓶颈和效果瓶颈卡在哪只有跑了才清楚。最后再提醒一件事坏结果不等于算法差。输出结果里出现ID切换先查自己的检测阈值、遮挡环境和参数配置不要一上来就把算法换了。跟踪工程做久了你会发现大部分问题不是算法不够高级而是使用它的姿势还需要再调整。