企业官网建设流程全解析

单目标跟踪这个方向，很多人入门时都是被一张“成功率曲线图”劝退的——图上一堆方法名字挤在一起，曲线差个零点几就排名大变，但你真去跑一遍，发现自己复现出来的数字跟论文差了三四个点。这种落差，八成不是你的代码写错了，而是你没搞清楚这些数据集各自的评测协议、标注规范和隐藏前提。从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给出了三种评测流程，名字听起来玄，其实都很直白。

OPE（One-Pass Evaluation）就是最常规的做法：第一帧给真值框，跑完整段，算平均重叠度或平均中心误差。这是主指标，也是大家最常引用的那个。

TRE（Temporal Robustness Evaluation）是把序列按时间切成若干段（通常是20段），每段的第一帧用真值框重新初始化，然后各段独立跑，最后把结果拼起来。这个设计的意图是模拟“中途被纠正”的场景，考察方法在任意起点重新起步的能力。但这里有个很要命的细节：切段之后，目标在段首可能正处于被遮挡状态，这时候用真值框初始化，等于给了一个“被遮挡目标的模板”，实际部署中根本不会出现这种情况，所以TRE的分数有时会虚高或者虚低，参考价值要打折。

SRE（Spatial 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最核心的指标是EAO（Expected 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），另外还有成功率阈值（P@0.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、成功率、精度、AUC

import 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, thresholds=np.arange(0, 1.05, 0.05)): ious = np.asarray(ious, dtype=np.float64) return np.array([(ious > t).mean() for t in thresholds]) def success_auc(ious, thresholds=np.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, thr=20.0): return float((np.asarray(errors) <= thr).mean()) def normalized_precision_at(errors, thr=0.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 速查表

提醒：任何横向对比之前，先确认三个东西——数据集版本、评测脚本版本、序列清单。这三样对不上，后面的分析全是无用功。

我在实际做横向评测时养成了一个习惯：每接入一个新方法，先只跑五段序列，手工核对每段的IoU曲线和最终指标，确认跟自己手算的对得上，再放开跑全量。这五段序列挑的是难度分布不同的，有长有短、有遮挡有尺度变化。这个前置检查花不了多少时间，但能挡掉八成以上的低级错误。毕竟跑全量动辄几个小时，跑完发现格式错了重来一遍，那个心情是真的很糟。