从OTB到LaSOT：单目标跟踪数据集评测协议演进与避坑指南

单目标跟踪这个方向很多人入门时都是被一张“成功率曲线图”劝退的——图上一堆方法名字挤在一起曲线差个零点几就排名大变但你真去跑一遍发现自己复现出来的数字跟论文差了三四个点。这种落差八成不是你的代码写错了而是你没搞清楚这些数据集各自的评测协议、标注规范和隐藏前提。从OTB到LaSOT单目标跟踪数据集这十几年“卷”得相当凶序列从几十段涨到几万段平均帧长从几百帧涨到两千多帧标注从稀疏的矩形框进化到逐帧密集框加语言描述评测协议从“一次性跑完算平均”变成“失败就重置、按重叠期望算分”。这篇文章就把这条演进线捋清楚讲明白每一代数据集是为了解决上一代的什么毛病才出现的顺便把我自己搭评测脚本时踩过的坑和可直接抄的代码一并放出来。不管你是刚进组要跑baseline的新手还是准备投稿、需要挑数据集设计实验的老手这些内容都用得上。1. 先把评测这件事说透单目标跟踪到底在比什么1.1 任务定义给一个框后面全靠自己单目标跟踪的任务定义朴素得有点过分视频第一帧给出目标的位置框之后每一帧输出一个框全程只有这一个目标、只有这一次初始化。没有类别标签告诉你这是人还是车没有检测器帮你兜底模型唯一的信息来源就是第一帧那个模板和后续帧的搜索区域。这跟目标检测、分割完全不是一回事——检测每帧独立错了下一帧还有机会跟踪是串行的一旦漂到背景上误差会顺着模板更新一路累积下去越跑越偏。正因为这种“一次性初始化、误差累积”的特性评测方式才变得特别讲究。你不能只看某一帧准不准得看整段序列的平均表现你不能只在一个初始化点上试得考虑初始化位置偏差带来的敏感性你还得考虑目标跑出画面、被完全遮挡之后怎么办——是判失败还是允许重新捕获。这些问题的答案就写在各个数据集的评测协议里。所以要理解数据集的演进本质上是理解“大家都在为什么样的失败模式打分”。OTB关心的是短序列里的平均重叠度VOT关心的是失败后重置的鲁棒性LaSOT关心的是长时序列里目标消失又重现的恢复能力。搞清楚这一层你再看那些排行榜就知道哪些数字是可以横向比的哪些根本不是一个赛道。1.2 为什么数据集会成为这个领域的话语权单目标跟踪有个挺特殊的现象算法结构的创新速度长期落后于数据集和评测体系的更新速度。很多年份里排行榜前排的方法架构差别并不大真正的分水岭是“谁先在新的、更难的数据集上把指标做上去”。这背后有个很现实的逻辑——跟踪任务没有统一的大规模预训练语料模型能力的天花板很大程度上由训练数据的分布决定。一个在OTB上能跑到0.7成功率的方法扔到LaSOT上可能只有0.4出头原因不是代码退化了而是LaSOT的序列平均两千多帧、目标会长时间消失再出现、背景更杂模型没见过这种分布。所以每次有新数据集发布本质上是在给整个领域重新划一条“能力及格线”。GOT-10k把训练集和测试集的类别完全隔离开逼着方法去学“通用跟踪”而不是“记住某个类别”TrackingNet把规模推到三万段视频逼着方法必须处理数据规模带来的过拟合问题LaSOT把序列拉长到两千帧以上逼着方法必须设计模板更新和重检测机制。这条线索捋下来你会发现数据集不是被动地“考”算法而是在主动地“塑造”算法。你想发论文就得顺着当前主流数据集的偏好去设计模块这就是“卷”的真实驱动力。2. OTB那个让所有人第一次有了“公共考场”的年代2.1 OTB50 与 OTB100 的构成OTB是这套体系里资历最老的一批最早版本只有几十段序列后来扩充到100段社区里习惯叫OTB50和OTB100后者也常被称作OTB2015。这些序列的来源很杂有监控画面、有街头随手拍的片段、有电影剪辑、也有体育比赛录像分辨率参差不齐很多只有三百多像素宽。序列长度普遍偏短几百帧是常态一两千帧的就算长的了。它最有价值的设计是视觉属性标注。每段序列被打上若干标签比如光照变化、尺度变化、遮挡、形变、运动模糊、快速运动、平面内旋转、平面外旋转、出视野、背景杂波、低分辨率。这套属性体系后来被几乎所有数据集沿用成了分析算法短板的标准工具。你做实验时按属性分组统计成功率就能看出方法到底是在“快速运动”上崩了还是在“背景杂波”上崩了比只看一个总分有用得多。不过要注意OTB的属性标注覆盖率并不高只有大约四分之一的序列带属性标签剩下的序列在这个维度上是空白的。做属性分析时如果不筛掉这批统计结果会被稀释得很厉害。2.2 OPE、TRE、SRE三种初始化方式OTB给出了三种评测流程名字听起来玄其实都很直白。OPEOne-Pass Evaluation就是最常规的做法第一帧给真值框跑完整段算平均重叠度或平均中心误差。这是主指标也是大家最常引用的那个。TRETemporal Robustness Evaluation是把序列按时间切成若干段通常是20段每段的第一帧用真值框重新初始化然后各段独立跑最后把结果拼起来。这个设计的意图是模拟“中途被纠正”的场景考察方法在任意起点重新起步的能力。但这里有个很要命的细节切段之后目标在段首可能正处于被遮挡状态这时候用真值框初始化等于给了一个“被遮挡目标的模板”实际部署中根本不会出现这种情况所以TRE的分数有时会虚高或者虚低参考价值要打折。SRESpatial Robustness Evaluation是在第一帧的真值框周围做扰动生成一组不同偏移和尺度的初始化框常见是12组每组各跑一遍。这个指标考察的是“初始化不准时方法会不会崩”实用性比TRE强但也更吃算力。三个指标里SRE最能反映工程落地时的鲁棒性因为实际场景中第一帧的框多半是人工或者检测器给的不可能和真值严丝合缝。我在实际项目里就遇到过这种情况标注框偏了十几个像素成功率直接掉五个点模型本身没问题是初始化偏差被放大到了后续帧。2.3 精度图与成功率图怎么读OTB的两张经典曲线很多人看的时候只盯着曲线下的面积其实读法有讲究。精度图Precision Plot的横轴是中心点误差阈值纵轴是误差小于该阈值的帧占比。常用的代表值取阈值20像素。这个指标只关心中心点距离完全不看框的大小所以对尺度估计不准的方法比较宽容。反过来说如果一个方法中心点很准但框一直缩放不对精度图会很好看成功率图却很难看。成功率图Success Plot的横轴是IoU阈值纵轴是IoU大于该阈值的帧占比代表值取曲线下面积AUC。这个指标同时惩罚位置和尺度错误更严格也更贴近实际观感。两张图一起看才有意义。如果精度高、成功率低多半是尺度估计出了问题常见于只用单一尺度模板、缺少尺度惩罚的方法如果两个都低那基本是跟踪本身漂了。我在给团队做内部评测时会强制要求两张图都贴只贴一张的汇报一律打回因为这个组合能快速定位问题方向。2.4 OTB 的天花板在哪OTB被诟病最多的三点序列太短、场景太干净、指标太容易饱和。到后来主流方法在OTB100上的成功率都能上到0.65以上前几名的差距只有零点几统计意义已经很不明显了。更麻烦的是短序列带来的偏差——几百帧的序列里只要目标有一段时间被遮挡模型漂了也没关系因为序列快结束了后面的误差不会累积太多。这种“跑一半就交卷”的评测很难反映真实的长时跟踪能力。还有一个隐蔽问题OTB的序列数量少单段序列的权重就很大。某一段特别难的序列表现差了整体分数就被拉下去而这段序列恰好又被很多方法共同拉低导致排名区分度不足。这也是后来大家拼命往大规模、长时序列走的原因。3. VOT 的规则革命把“失败”和“重置”写进协议3.1 重置式评测解决了什么OTB的OPE有个根本缺陷目标完全消失、跟踪器跑到画面外之后后面的帧全是无效输出这些无效帧会一路拉低平均分但你没法区分“失败一次”和“失败之后再也没回来”。VOT的做法很直接一旦预测框和真值的重叠度掉到零判定为一次失败然后跳过若干帧通常是5帧后用真值重新初始化继续跑。这个改动看着小影响却很大。它把一次长时失败拆成了若干次短时失败每次失败单独计数最终指标里同时体现“准确度”和“失败次数”。这样评测的重点就从“平均有多准”转向了“多久崩一次”更贴近工程上关心的鲁棒性。我第一次切换到VOT协议时最大的感受是“分数变难看了”。同一个模型OTB上0.62的成功率VOT的EAO只有0.28。不是模型变差了是评测变严了——重置机制让每一次漂移都被记录下来藏不住。3.2 EAO 的计算逻辑与坑VOT最核心的指标是EAOExpected Average Overlap中文一般叫期望平均重叠。它的计算流程值得展开说说因为这是很多人对不上榜的直接原因。第一步把每段序列按“重置点”切成若干段每段算平均重叠度得到一组长度精度的点对。第二步把所有序列的短段按长度分桶同一长度的段求平均得到一条“长度-精度”曲线。第三步对一定长度范围内的曲线求平均得到一个标量。坑就在第三步。不同年份的VOT参与平均的长度范围不一样早期是取所有序列的中位长度附近后来改成了固定区间。如果你用错了区间或者序列集合跟官方不一致算出来的EAO就跟榜上差一截。我见过有同学拿自己划分的序列子集去算EAO结果比别人高出一大截兴冲冲以为是新SOTA最后一查是区间设错了。实际复现时我建议直接用官方提供的评测工具包不要自己重写EAO。如果非要自己实现一定要拿官方的示例结果做一次对齐验证输入官方给的原始预测看能不能复现出官方公布的数值对上了再往下做。3.3 旋转框、视觉属性与实时性赛道VOT还有几个容易被忽略的设计。一是旋转边界框目标倾斜时用带角度的框标注这比水平框更贴合真实轮廓但对预测框的格式转换要求更高很多方法输出的还是水平框评测时需要一个外接矩形或者拟合的转换步骤这一步处理不好会白白丢分。二是视觉属性标注VOT的属性体系比OTB更细而且每年会调整。做属性分析时要看清楚用的是哪一年的定义不同年份的标签不可混用。三是实时性赛道。VOT有一年专门设了实时性评测要求方法在规定帧率以上运行把速度也纳入考量。这个设置在当时挺有争议因为速度和精度往往互斥但它确实推动了轻量化方向的研究。我在边缘设备上部署过跟踪器深有体会论文里50 FPS的模型到了实际硬件上跑15 FPS都费劲速度这个维度不设约束工程上就没法用。3.4 VOT 带来的新麻烦重置式评测也不是没毛病。最典型的问题是重置时机的主观性。跳过5帧再重新初始化这5帧里的信息被丢弃了如果目标恰好在这5帧里重新出现方法就失去了自我恢复的机会被强行判了一次失败。这对那些设计了重检测机制的长时跟踪方法其实不太公平——它们本来有机会自己找回目标但协议不给这个机会。另一个问题是序列数量少。VOT每年的序列数在几十段量级单段序列的权重很大随机性带来的波动不可忽视。同一批方法隔一年重跑排名互换的情况时有发生。所以看VOT榜单时我一般只看趋势不看具体名次的小数点后两位。4. 大规模时代UAV123、NFS、GOT-10k、TrackingNet 各自补了哪块拼图4.1 UAV123低空视角与小目标无人机视角的跟踪和地面视角差别很大相机俯视、目标尺度小、视角变化剧烈、背景以地面纹理为主。UAV123就是针对这个场景建的序列全部来自低空飞行拍摄平均帧长比OTB长不少而且包含大量小目标序列。这个数据集的价值在于把“尺度变化”和“小目标”这两个维度单独拎出来考。在通用数据集上表现很好的方法到了UAV123上经常掉得很厉害原因就是搜索区域设得太大、模板分辨率不够小目标在特征图上只有几个像素压根提取不出有效特征。做无人机相关应用的话这个数据集基本绕不开。需要注意的是它的标注框尺度普遍偏小评估时如果用固定像素阈值算精度会显得所有方法都很差。这时候更该看归一化后的精度或者成功率别被绝对像素值误导。4.2 NFS帧率把速度维度拉了进来NFS的特点是高帧率拍摄很多序列是两百多帧每秒录的。高帧率意味着相邻帧之间目标位移很小看起来“变简单了”但实际上它引入了另一个挑战目标外观变化在时间上被拉长了一段几秒的序列可能有上千帧模板更新的频率和策略就成了关键。这个数据集当年提出的一个观点挺有意思很多方法在低帧率数据集上表现好是因为帧间差异大、信息冗余少模型不需要处理太多“几乎一样”的帧而高帧率下大量高度相似的帧会让模板更新策略的缺陷暴露出来——更新太频繁会累积噪声更新太慢会跟不上外观变化。实际用的时候要注意帧率对齐。如果你的方法内部有基于帧间隔的运动先验比如卡尔曼滤波的状态转移在高帧率数据上必须重新调参否则运动模型的预测会严重滞后。4.3 GOT-10k类别隔离的“零样本”协议GOT-10k最狠的设计是训练集和测试集的类别完全不重叠。训练集覆盖几百个类别测试集用的是另外几十个类别一个都不重合。这直接堵死了“靠记住训练类别来提分”的路子逼着方法去学通用的外观匹配能力。这个协议对整个领域的影响很深远。在此之前很多方法在训练集和测试集类别重叠的数据集上刷分指标虚高一换场景就崩。GOT-10k出来之后“零样本跟踪”成了一个正式的评测维度大家开始认真对待泛化问题。它的评测指标也比较全除了常规的成功率曲线AO和成功率阈值SR还有一些针对性的统计。使用时要特别注意提交格式官方对结果文件的目录结构和命名有严格要求格式错了直接评测失败跟模型好坏没关系。4.4 TrackingNet把数据规模推到万级TrackingNet的思路是从大规模视频里自动挖掘跟踪序列。做法大致是先用检测和分割模型在视频里找出可能的目标再用跟踪算法把目标串成轨迹最后做一致性过滤剔除质量差的片段。这样能低成本产出几万段带框的序列规模比手工标注的数据集大两个数量级。代价是标注噪声。自动挖掘出来的框不可能帧帧精准尤其在目标形变、遮挡的片段里框会飘。所以在这个数据集上训练时损失函数的选择要更宽容一点别用对标注误差极度敏感的目标否则模型会去拟合噪声。这个数据集真正改变的是训练范式。在此之前跟踪模型的训练数据规模普遍在几百段量级模型容量上不去TrackingNet出来之后大家开始敢用大 backbone、敢做大规模预训练整个方向的模型复杂度上了一个台阶。4.5 这一代数据集的共同特征把这一批放在一起看能看出几条共性规模从百级跳到万级场景从单一来源变成多来源混合评测从“单一指标”变成“多指标加属性分析”训练测试的隔离从“同一分布随机划分”变成“类别隔离”。还有一个容易被忽视的变化评测代码的工程化程度提高了。早期数据集给的评测脚本往往很短几百行 Python自己改改就能用后来的数据集普遍提供完整的工具包支持多线程、支持结果缓存、支持增量评测。这既是好事也是坏事——好事是省事坏事是黑盒程度变高出了问题不好排查。5. LaSOT长时跟踪的分水岭5.1 规模、类别与密集标注LaSOT在这个演进线里的位置很特殊它不是规模最大的但它在“长时”和“标注质量”这两个维度上立了标杆。序列数量在千级类别覆盖几十种常见目标平均每段序列的帧数超过两千帧最长的一些接近一万帧。标注是逐帧的密集矩形框没有跳帧没有插值。密集标注这一点看起来是基本要求实际上成本极高。两千帧乘一千段就是两百万帧级别的框标注而且要求标注员逐帧核对。这也是为什么后来的数据集即便规模更大标注密度往往也做不到这个水平。它还有个常被忽略的细节目标在场率的统计。长时序列里目标会离开画面、被完全遮挡、或者缩到极小这些帧的框要么标记为不可见要么标成特殊值。评测时必须正确处理这些帧否则分数会莫名其妙地低。5.2 长时跟踪难在哪消失、重现、漂移长时跟踪的核心难点不是“跟得准”而是“丢得起、找得回”。短时序列里目标基本全程可见模型只要不漂就行长时序列里目标可能消失几百帧然后从完全不同的位置、不同的尺度、不同的姿态重新出现。这时候模型必须做到两件事判定目标当前不可见以及在目标重现时重新定位。这两个能力对模型结构提出了新要求。搜索区域不能再是固定的小窗口否则目标跑到画面另一边就彻底找不到了模板不能只保留第一帧否则目标外观变化大了就匹配不上还需要某种“全局搜索”或者“置信度判定”机制用来决定什么时候该扩大搜索范围、什么时候该更新模板。我在复现长时跟踪方法时最深的一个体会是模板更新策略比主干网络重要得多。换个更强的 backbone指标可能涨一个点把更新策略从“固定间隔”改成“基于置信度的动态更新”指标能涨三个点以上。这也解释了为什么LaSOT出来之后一大批工作都集中在模板管理和重检测上。5.3 LaSOT 的评测细节与常见误用LaSOT用的是常规的成功率曲线AUC和归一化精度Normalized Precision另外还有成功率阈值P0.5之类的写法。归一化精度这个指标值得说一下它把中心点误差用目标框的宽高做归一化再算阈值内的比例。这样做的好处是消除了目标尺度的绝对影响大目标和小目标可以公平比较。常见误用有几个。一是直接拿水平框去评所有序列但部分序列的真值框有特殊标注格式不匹配会导致整段序列算出零重叠。二是忽略了“目标不可见帧”的处理规则有些实现把这些帧的重叠度直接当零算结果分数被严重拉低。三是把训练集和测试集的划分搞混LaSOT有明确的训练/测试类别划分用测试集调参是典型的作弊。还有一个坑是评测工具包的版本差异。不同版本的评测脚本在边界情况处理上略有不同算出来的分数能差零点几。投稿时最好在论文里注明用的版本号或者干脆自己实现一份并做对齐验证。5.4 LaSOT-ext 与它的争议LaSOT后来出了一个扩展版本加了新的类别和序列目的是缓解原版类别分布不均的问题。原版的类别分布确实偏——某些类别的序列特别多某些类别只有寥寥几段做类别级别的分析时统计意义不足。扩展版引入的新类别填补了一部分空白。但这个扩展也带来新的问题新加的序列和原版在拍摄风格、分辨率、难度上不完全一致混在一起评会让结果的可比性下降。社区里的做法一般是分开报告或者明确说明用的是哪个版本。我自己做横向对比时会先确认所有对比方法用的是同一版本的结果不同版本的数字绝不放在一张表里。6. 数据集“卷”的四条主线6.1 规模从几十段到几万段规模的增长不是线性的是跳跃式的。第一代是几十到一百段第二代是几百段第三代直接跳到一万到几万段。每次跳跃都伴随着训练范式的变化百级规模只能训小模型千级规模可以训中等模型万级规模才撑得起大 backbone 加预训练。但规模不是越大越好。规模上去之后标注噪声、类别分布不均、评测成本这三个问题会同时放大。几万段序列跑一遍评测单卡可能要跑好几天这时候评测效率本身就成了瓶颈逼着大家去搞分布式评测和结果缓存。6.2 时长平均帧数背后的设计意图平均帧数这个指标经常被忽略但它直接决定了任务的难度类型。平均几百帧的序列考的是短时匹配精度平均两千帧以上的序列考的是长时鲁棒性。两者的技术侧重点完全不同。我一般用“平均帧数 / 目标平均可见帧数”这个比值来判断数据集的“消失率”。比值越高说明目标消失的时间占比越大对重检测能力的要求越高。这个比值在选数据集做实验时很有参考价值——如果你的方法主打重检测就该选消失率高的数据集来验证否则优势体现不出来。6.3 标注质量框、掩码、语言、属性标注形态的演进也很有意思。最早只有矩形框后来加了属性标签再后来加了像素级掩码最近几年开始加自然语言描述。每加一种模态就打开一个新的研究方向。掩码标注催生了分割式跟踪把跟踪从“框回归”变成“像素分类”精度上限更高但速度下来了。语言描述催生了语言引导跟踪可以用一句“穿红衣服从左往右走的人”来指定目标解决了第一帧框无法表达语义的问题。这些方向的评测协议还在完善中不同数据集的指标定义差异很大横向比较要格外小心。6.4 公平性类别隔离与协议统一公平性是最近几年越来越被重视的维度。类别隔离是最直接的手段训练见过的类别不能在测试里出现。还有更细的做法把同一段原始视频切出来的片段全部划到同一侧避免同一场景既在训练又在测试把同一拍摄设备、同一地点的素材做隔离避免模型记住背景纹理。协议统一是另一回事。同一个数据集不同论文用的预处理、输入分辨率、评测脚本版本不一样结果就没法比。这两年一些数据集开始提供标准化的评测服务上传结果文件统一算分这在很大程度上缓解了这个问题。7. 评测指标怎么反向塑形算法7.1 从短时到长时搜索区域与记忆指标变了算法设计就跟着变。短时数据集时代搜索区域取目标框的四倍大小就够了因为目标跑不远长时数据集时代这个设置直接失效必须放大搜索区域或者引入多尺度搜索。但搜索区域一放大背景干扰就变多误检率上升于是又需要更好的判别力。记忆机制也是被逼出来的。短时序列里第一帧模板够用长时序列里第一帧模板和目标当前外观可能差了几十帧甚至上千帧的演化只用初始模板必然失配。于是就有了模板库、模板更新、长期记忆加短期记忆的双分支结构。这些设计不是凭空想出来的全是被长时数据集的指标逼出来的。7.2 模板更新策略的取舍模板更新是个典型的“怎么做都有坑”的问题。不更新跟不上外观变化更新太频繁误差累积模板被背景污染更新太慢目标形变后匹配不上。常见的折中方案是基于置信度动态决策当前帧的匹配置信度高于阈值就更新低于阈值就保留旧模板同时限制更新频率比如每隔若干帧才允许更新一次。这个阈值怎么定没有通用答案得在验证集上扫。我试过的经验值是取置信度分布的中位数偏上一点既能跟上变化又不会被单帧噪声带偏。还有个细节容易被忽略更新的时候用哪一帧的预测框来裁剪模板。用当前帧的预测框如果预测偏了模板就被污染用高置信度的历史帧又可能过时。比较稳的做法是维护一个小容量的模板队列更新时做加权融合而不是直接替换。7.3 指标偏好导致的“刷分”行为只要指标存在就会有针对性优化。成功率曲线关注的是整体分布方法就会倾向于把大部分帧做得“还行”而不是把难帧做对归一化精度关注的是中心点方法就会在位置回归上过度用力尺度估计放松实时性赛道加了速度约束方法就会砍掉后处理。这些行为本身不算错但如果只盯着一个指标优化很容易做出“榜单好看、实际难用”的东西。我自己的习惯是至少看三个指标成功率、归一化精度、以及按属性分组后的最差组表现。最差组的表现最能反映方法的真实短板比平均分有信息量得多。8. 自己搭一套可信评测流程能直接抄的配置8.1 目录结构与数据格式统一多数据集评测最烦的是格式不统一。我的做法是先写一层适配器把所有数据集转成统一格式每个序列一个目录里面放帧图像和一个文本文件每行是frame_id x y w h缺失帧用特殊值标记。这样上层评测代码只认一种格式换数据集只改适配器。dataset_root/ sequence_name/ frames/0001.jpg, 0002.jpg, ... groundtruth.txt # 每行: x y w h absence.label # 可选: 每行 0/1 标记目标是否可见适配器里要处理几个恶心的情况坐标是左上角还是中心点、框是xywh还是x1y1x2y2、有没有越界坐标、缺失帧怎么表示。这些转换写错一个后面全白搭。8.2 核心代码IoU、成功率、精度、AUCimport numpy as np def iou_xywh(a, b): ax, ay, aw, ah a bx, by, bw, bh b ix1, iy1 max(ax, bx), max(ay, by) ix2, iy2 min(ax aw, bx bw), min(ay ah, by bh) iw, ih max(0.0, ix2 - ix1), max(0.0, iy2 - iy1) inter iw * ih union aw * ah bw * bh - inter return inter / union if union 0 else 0.0 def success_curve(ious, thresholdsnp.arange(0, 1.05, 0.05)): ious np.asarray(ious, dtypenp.float64) return np.array([(ious t).mean() for t in thresholds]) def success_auc(ious, thresholdsnp.arange(0, 1.05, 0.05)): curve success_curve(ious, thresholds) return float(np.trapz(curve, thresholds)) def center_error(pred, gt): px, py pred[0] pred[2] / 2.0, pred[1] pred[3] / 2.0 gx, gy gt[0] gt[2] / 2.0, gt[1] gt[3] / 2.0 return float(np.hypot(px - gx, py - gy)) def normalized_center_error(pred, gt): err center_error(pred, gt) w, h gt[2], gt[3] return err / np.sqrt(w * h) if w * h 0 else 1e9 def precision_at(errors, thr20.0): return float((np.asarray(errors) thr).mean()) def normalized_precision_at(errors, thr0.2): return float((np.asarray(errors) thr).mean())这段代码看着简单但有几个细节必须对齐阈值网格的步长、AUC是用梯形积分还是矩形求和、精度阈值取20像素还是归一化后的0.2。这些选择不同结果就差零点几跟榜上对不上大多出在这里。8.3 参数怎么算一个具体的数值例子假设某段序列共1000帧目标全程可见。统计出所有帧的IoU后按0.05步长从0算到1得到21个阈值点。假设在阈值0处成功率是1.0在0.5处是0.72在0.7处是0.45在0.9处是0.08阈值1.0处是0.0。用梯形积分近似算AUC大约在0.55到0.60之间。再看精度。假设中心误差的中位数是12像素阈值取20像素时的精度是0.78归一化之后中位归一化误差是0.09阈值0.2时的归一化精度是0.81。注意这两个数不能混着看——归一化精度普遍比绝对像素精度高因为大目标的误差被摊薄了。如果要算EAO还得先做重置切段。假设这段序列中途判定失败两次切成三段长度分别是400、350、250各段平均重叠度是0.62、0.55、0.48。这三段分别进入长度分桶最后和所有序列的同长度段一起平均。这里就能看出EAO为什么对序列集合敏感——你的分段长度分布和官方不一致平均出来的结果必然对不上。8.4 跑分时的注意事项第一固定随机种子和输入分辨率。有些方法内部有随机采样不固定种子跑三次能出三个结果。分辨率不一致导致的结果差异更大尤其对基于深度特征的方法。第二预处理要和训练时一致。很多方法训练时做了均值方差归一化评测时忘了结果掉得莫名其妙。我见过最离谱的一次是通道顺序搞反了分数直接腰斩。第三单线程跑一遍做基准再开多线程加速。多线程评测时如果用了共享状态结果可能不对先验一遍单线程的数字做对照。第四保存原始预测结果。别只存指标把每帧的预测框存下来后面做属性分析、可视化、case study 都要用。重新跑一遍的成本远高于存文件。第五把失败帧标记出来。成功率曲线是平均值看不出分布。把失败集中的帧段找出来往往能定位到具体原因比如某个遮挡段、某个尺度突变点。这个分析比多跑几个模型有价值得多。9. 常见问题速查与避坑清单9.1 指标对不上榜的六个原因评测脚本版本不一致。官方工具包更新过好几次边界情况处理有差异。先拿官方给的样例预测跑一遍能复现官方数字再往下做。真值格式转换错误。中心点和左上角的区别、框的宽高是否包含边界、坐标是否从0还是1开始任何一个错了都会系统性偏差。目标不可见帧的处理方式不同。有的实现把这些帧排除有的当零算有的用上一帧的预测填充。三种做法分数差异很大要和对比方法保持一致。序列集合不完整。少了几段序列或者多了不该有的序列平均分就变了。用之前先核对序列清单。输入分辨率或预处理不一致。这条最隐蔽因为不报错只是分数低。评测时的初始化方式不同。第一帧用真值还是用检测器输出差别巨大。看论文时要明确它报的是哪种。9.2 速查表现象最可能的原因排查动作成功率整体低3到5个点预处理或分辨率不一致对齐均值和方差、检查输入尺寸某几段序列分数为0真值格式或缺失帧处理错误单独打印这几段的IoU序列精度高但成功率低尺度估计有问题检查是否只有位置回归没有尺度分支归一化精度远高于普通精度大目标占比高按目标尺寸分组统计EAO和榜上差一截长度区间或序列集合不对用官方工具包复核多线程和单线程结果不同共享状态竞争改成进程隔离或加锁换数据集后指标暴跌域差异或类别分布差异看属性分组的最差组表现提醒任何横向对比之前先确认三个东西——数据集版本、评测脚本版本、序列清单。这三样对不上后面的分析全是无用功。我在实际做横向评测时养成了一个习惯每接入一个新方法先只跑五段序列手工核对每段的IoU曲线和最终指标确认跟自己手算的对得上再放开跑全量。这五段序列挑的是难度分布不同的有长有短、有遮挡有尺度变化。这个前置检查花不了多少时间但能挡掉八成以上的低级错误。毕竟跑全量动辄几个小时跑完发现格式错了重来一遍那个心情是真的很糟。