检测跟踪文献综述写作指南：从技术脉络到落地选型

简介：这份《检测跟踪文献综述》面向计算机视觉、智能视频监控方向的学生与研究人员，系统梳理运动目标检测与跟踪领域的技术脉络，帮助读者快速建立从传统监控到智能分析的整体认知。资源包内含1个docx文档，约24KB，以综述性文字为主，适合作为开题调研、课程作业或论文写作的参考资料。内容围绕视频监控技术从模拟、数字到全数字网络化的三代演进展开，重点讲解智能视频分析模块中运动目标检测与跟踪的基础地位，并对比基于区域、基于活动轮廓、基于特征和基于模型四类主流跟踪方法的原理、优势与局限，同时涉及遮挡、形变、模板更新等实际难点及深度学习、5G与物联网带来的发展趋势。目前已有68人学习，适合希望用较短时间把握该方向研究框架与关键问题的读者。

1. 一份“检测跟踪文献综述.docx”到底能帮你解决什么问题

如果你正在做多目标跟踪（MOT）方向，大概率经历过这个场景：导师或主管丢过来一句“先把检测跟踪的文献综述整理一下”，你打开搜索引擎，扑面而来的是 SORT、DeepSORT、ByteTrack、OC-SORT、BoT-SORT、FairMOT、JDE、TrackFormer、MOTR……名字记了一堆，但真到要动手选方案的时候，还是不知道从哪篇开始读、哪些是真正能落地的、哪些只是刷榜好看。一份高质量的“检测跟踪文献综述.docx”本质上不是论文堆砌，而是一张技术路线地图——它要回答的核心问题是：检测和跟踪这两件事在过去几年是怎么从“各干各的”走向“联合优化”的，每条路线的适用边界在哪，以及你手上的场景该选哪条路。这篇文章面向的是需要快速建立检测跟踪领域全局认知、并且准备落地一个具体跟踪方案的工程师和研究生，我会按“先理清技术脉络、再拆解关键方法、最后给出选型与复现路径”的顺序，把这份综述该有的骨架和血肉讲清楚。

2. 检测跟踪的技术脉络：从“先检测后关联”到“端到端联合”

2.1 两阶段范式：TBD 为什么长期占据主流

检测跟踪领域最早、也是最成熟的范式是 Tracking-by-Detection（TBD），中文一般叫“先检测后跟踪”。它的逻辑非常直白：每一帧先用目标检测器把画面里所有感兴趣的目标框出来，然后通过某种关联策略把当前帧的检测框和上一帧已经存在的轨迹匹配起来，匹配上了就延续轨迹，没匹配上的就新建轨迹，连续多帧没匹配上的就删除轨迹。

这个范式之所以长期占据主流，核心原因有三个。第一是模块解耦带来的工程灵活性——检测器可以用 YOLO 系列、Faster R-CNN、DETR 等任意方案，关联模块可以独立替换和调参，出了问题容易定位是检测漏了还是关联错了。第二是检测模型的快速迭代可以直接惠及跟踪——过去几年目标检测的性能提升非常快，TBD 范式天然享受这波红利。第三是数据标注成本相对可控——检测标注只需要框，不需要轨迹 ID，后者标注代价高得多。

但 TBD 的天花板也很明显。检测器在遮挡、运动模糊、小目标场景下漏检时，关联模块再强也巧妇难为无米之炊。而且检测和关联两个模块各自优化目标不一致，检测器追求的是每帧的 AP 最高，但跟踪需要的是跨帧 ID 一致性，这两者之间存在天然的 gap。

2.2 联合检测与嵌入：JDE 和 FairMOT 的取舍

为了解决 TBD 的割裂问题，联合检测与嵌入（Joint Detection and Embedding，JDE）范式出现了。核心思路是让一个网络同时输出检测框和 ReID 特征，这样检测和重识别共享骨干网络的特征提取，推理效率大幅提升。

JDE 是最早的尝试之一，它在 YOLOv3 的框架上增加了一个 ReID 特征分支，每个检测框对应的位置同时输出一个嵌入向量。但 JDE 有个明显问题：检测和 ReID 任务对特征的需求是冲突的。检测需要的是语义级别的特征来区分“人”和“车”，ReID 需要的是实例级别的细粒度特征来区分“张三”和“李四”。JDE 把两个任务塞进同一个特征图，导致 ReID 精度不够理想。

FairMOT 针对这个问题做了改进，它采用 Anchor-Free 的检测框架（基于 CenterNet），并且把 ReID 特征提取放在高分辨率特征图上，而不是和检测共享低分辨率特征。这个设计让 FairMOT 在 MOT 基准上取得了很好的平衡——精度高、速度也不慢。但 FairMOT 的局限在于它对检测器的依赖仍然很重，如果检测器在拥挤场景下表现不好，ReID 特征再强也救不回来。

2.3 基于 Transformer 的端到端方案：MOTR 和 TrackFormer

Transformer 进入跟踪领域之后，出现了一批端到端方案，代表工作是 TrackFormer 和 MOTR。它们的核心思路是用 Transformer 的 query 机制来同时完成检测和跟踪——每个轨迹对应一组 query，通过注意力机制在帧间传递信息，不需要显式的关联步骤。

TrackFormer 基于 DETR 框架，通过 track query 在帧间自回归地传递目标信息。MOTR 则引入了 tracklet-aware 的标签分配策略，让 query 和轨迹之间建立更稳定的对应关系。这类方案的理论优雅程度很高，端到端训练、无需后处理关联，但实际落地时面临几个硬伤：训练数据需求大、收敛慢、对长序列的泛化能力还不够稳定，而且在 MOT Challenge 等基准上的表现还没有全面超越精心调优的 TBD 方案。

2.4 当前 SOTA 方案的技术共识

综合来看，当前检测跟踪领域在实际落地中最受认可的方案仍然集中在 TBD 范式，但关联策略已经从简单的 IoU 匹配进化到了“运动模型 + 外观特征 + 置信度加权”的多线索融合。ByteTrack 的出现是一个标志性事件——它发现了一个被长期忽视的问题：低分检测框里其实包含大量被遮挡的目标信息，直接丢掉太浪费了。ByteTrack 的做法是先用高分框做第一次关联，再用低分框对未匹配的轨迹做第二次关联，这个简单但有效的策略在多个基准上取得了显著提升。

OC-OTS 则针对遮挡场景做了进一步优化，引入了以观测为中心的在线平滑策略，在遮挡恢复时能更准确地重新关联。BoT-SORT 在 ByteTrack 基础上增加了相机运动补偿和更鲁棒的 ReID 特征融合。这些方案的共同趋势是：不再追求单一模块的极致，而是在检测质量、运动预测、外观匹配三个维度上做精细的平衡。

3. 写一份能用的检测跟踪综述：结构、工具与关键参数

3.1 综述文档的骨架该怎么搭

一份能真正帮到人的检测跟踪文献综述，结构上应该按“问题定义 → 技术演进 → 方法分类 → 基准对比 → 选型建议”来组织，而不是按时间顺序罗列论文。具体来说，我一般会建议按下面这个骨架来写：

第一部分是问题定义与评价体系。把 MOT 的核心评价指标讲清楚——MOTA、IDF1、HOTA、ID Switch、Fragmentation 各自衡量什么，为什么 MOTA 高不代表跟踪好（MOTA 主要反映检测性能），为什么 HOTA 是更均衡的指标。这部分不写清楚，后面的方法对比就没有统一的标尺。

第二部分是技术演进脉络。按 TBD → JDE → Transformer-based 三条主线来梳理，每条线讲清楚核心动机、代表方法、解决了什么问题、又引入了什么新问题。这部分是综述的主体，需要覆盖 SORT/DeepSORT/ByteTrack/OC-SORT/BoT-SORT/FairMOT/MOTR 等关键工作。

第三部分是基准与实验对比。把 MOT16/17/20、DanceTrack、KITTI 等常用基准的特点说清楚，然后整理各方法在这些基准上的公开结果。这里要注意的是，不同论文的训练数据、检测器、后处理策略不同，直接比数字容易误导，最好标注清楚实验条件。

第四部分是选型建议与落地路径。针对不同场景（行人跟踪、车辆跟踪、拥挤场景、长时跟踪）给出推荐方案和理由。

3.2 用 Python 脚本批量整理文献信息

写综述最耗时的环节之一是整理文献信息。我一般会用 Python 脚本从 BibTeX 文件或 CSV 中批量提取关键字段，生成结构化的对比表格。下面是一个从 BibTeX 提取信息的示例：

import bibtexparser from bibtexparser.bparser import BibTexParser def parse_bibtex(bib_file): """解析 BibTeX 文件，提取标题、作者、年份、关键词""" with open(bib_file, encoding='utf-8') as f: parser = BibTexParser(common_strings=True) parser.ignore_nonstandard_types = False bib_database = bibtexparser.load(f, parser) records = [] for entry in bib_database.entries: records.append({ 'title': entry.get('title', '').replace('{', '').replace('}', ''), 'author': entry.get('author', '').split(' and ')[0], # 只取第一作者 'year': entry.get('year', ''), 'keywords': entry.get('keywords', ''), 'venue': entry.get('journal', entry.get('booktitle', '')) }) return records # 使用示例 records = parse_bibtex('mot_papers.bib') for r in sorted(records, key=lambda x: x['year']): print(f"{r['year']} | {r['author']} | {r['title'][:60]}")

这段脚本的逻辑很直接：用bibtexparser库读取.bib文件，遍历每一条文献记录，提取标题、第一作者、年份、关键词和发表 venue。参数方面，ignore_nonstandard_types=False是为了兼容一些非标准条目类型（比如 arXiv 预印本），common_strings=True能正确处理 BibTeX 中的缩写字符串。实际使用时，你可以把输出结果直接导入 Excel 或 Pandas DataFrame 做进一步筛选和排序。

3.3 关键参数对比表的制作方法

综述里最有价值的部分之一是多方法关键参数的横向对比。下面这张表是我在综述中常用的格式，覆盖了检测跟踪领域几个代表性方法的核心设计选择：

这张表的关键在于标注清楚每个方法的设计选择，而不是只列最终指标。比如 ByteTrack 的 MOTA 很高，但它的 ReID 列是“无”，说明它完全靠运动信息和检测质量取胜，在 appearance 变化剧烈的场景下可能不如 BoT-SORT。参数方面，MOT17 上的 MOTA 数值来自各论文公开报告，实际复现时由于检测器版本、NMS 阈值、轨迹生命周期参数不同，结果会有波动。

3.4 用 Pandas 做基准结果的统计分析

当你收集了足够多的方法结果之后，可以用 Pandas 做一轮统计分析，看看不同设计选择对性能的影响趋势：

import pandas as pd # 假设已经从各论文中整理了如下数据 data = { 'method': ['SORT', 'DeepSORT', 'ByteTrack', 'OC-SORT', 'BoT-SORT', 'FairMOT', 'MOTR'], 'paradigm': ['TBD', 'TBD', 'TBD', 'TBD', 'TBD', 'JDE', 'E2E'], 'use_reid': [0, 1, 0, 0, 1, 1, 0], 'mota': [59.8, 61.4, 80.3, 80.4, 80.6, 73.7, 73.4], 'idf1': [39.2, 62.2, 77.3, 77.5, 79.5, 72.3, 68.5], 'fps': [60, 30, 30, 25, 20, 25, 8] } df = pd.DataFrame(data) # 按范式分组看平均性能 print(df.groupby('paradigm')[['mota', 'idf1', 'fps']].mean().round(1)) # 看 ReID 对 IDF1 的影响 print(df.groupby('use_reid')['idf1'].mean().round(1))

这段代码的输出能帮你快速看出几个趋势：TBD 范式在当前基准上仍然领先，ReID 特征对 IDF1 的提升明显但对 MOTA 影响不大，端到端方案在速度上还有明显劣势。这些统计结论可以直接写进综述的分析部分，比单纯罗列数字有说服力得多。

4. 检测跟踪综述写作中的避坑指南

4.1 坑一：把 MOTA 当成唯一评价标准

现象：综述里所有方法的对比都只看 MOTA，结论是“ByteTrack 最好”。

原因：MOTA 主要由检测性能驱动，一个检测器强的 TBD 方法即使关联做得很粗糙，MOTA 也不会低。但实际跟踪场景中，ID Switch 和轨迹碎片化往往比 MOTA 更影响用户体验。

解决：综述中至少同时报告 MOTA、IDF1、HOTA 三个指标，并且说明各自侧重什么。HOTA 是近年公认更均衡的指标，它把检测精度、关联精度、定位精度做了几何平均，建议作为主要参考。

4.2 坑二：忽略检测器版本对跟踪结果的影响

现象：综述里写“ByteTrack 在 MOT17 上达到 80.3 MOTA”，读者复现时用不同版本的 YOLOX 只跑出 75。

原因：ByteTrack 原文用的是特定配置的 YOLOX-X，输入分辨率、NMS 阈值、置信度阈值都会显著影响最终跟踪指标。很多论文在报告结果时不会把所有检测器配置写全。

解决：综述中引用指标时，务必标注检测器型号和关键配置。如果原文没有提供，标注“检测器配置未完全公开”比直接给一个数字更负责任。

4.3 坑三：把不同基准的结果混在一起比较

现象：表格里把 MOT17 上的结果和 DanceTrack 上的结果放在同一列比较。

原因：不同基准的数据分布、场景难度、评价协议完全不同。DanceTrack 专门设计来测试关联能力，检测器在它上面的表现普遍很好，但关联难度极高，MOTA 普遍偏低。

解决：按基准分表呈现，每个基准单独一张对比表。如果要做跨基准的趋势分析，只比较相对排名而不是绝对数值。

4.4 坑四：综述只罗列不分析

现象：每篇论文一段话概括，读完之后读者还是不知道该怎么选。

原因：综述的价值不在于“有哪些论文”，而在于“这些论文之间的关系是什么、各自适合什么场景”。

解决：每个方法至少写清楚三个问题——它解决的前一个方法存在的什么问题、它自己引入了什么新问题、它在什么场景下是当前最优选择。这样读者才能建立决策树而不是论文列表。

4.5 坑五：忽略工程落地中的轨迹管理细节

现象：综述里只讲算法创新，不讲轨迹初始化、生命周期管理、级联匹配阈值这些工程细节。

原因：这些细节在论文中往往一笔带过，但在实际落地中直接决定跟踪器能不能用。

解决：在综述的落地建议部分，专门用一节讲轨迹管理的最佳实践，包括：新轨迹的确认帧数（通常 3 帧）、轨迹丢失后的保留帧数（通常 30 帧）、级联匹配的 IoU 阈值（通常 0.3 左右）、卡尔曼滤波的过程噪声和观测噪声怎么调。

5. 从综述到落地：选型决策与快速验证技巧

5.1 按场景选方案的决策路径

读完综述、整理完对比表之后，下一步就是选一个方案动手跑。我一般会按下面这个决策路径来选：

如果是行人跟踪、场景相对干净，首选 ByteTrack 或 OC-SORT。这两个方案不需要 ReID 模型，推理速度快，在 MOT17 上表现稳定，代码开源质量高，改起来方便。ByteTrack 的官方实现基于 YOLOX，如果你已经有一套 YOLO 系列的检测器，迁移成本很低。

如果是拥挤场景、遮挡频繁，优先考虑 BoT-SORT 或 DeepSORT 的改进版。这类场景下外观特征的价值会体现出来，ReID 模型能帮助在目标交叉后恢复正确 ID。但要注意 ReID 模型会带来额外的推理开销，需要根据你的算力预算做取舍。

如果是车辆跟踪、相机运动明显，BoT-SORT 的相机运动补偿（CMC）模块是必须的。普通卡尔曼滤波假设相机静止，车载场景下这个假设不成立，不加 CMC 会导致轨迹漂移严重。

如果是长时跟踪、目标频繁出入画面，需要特别关注轨迹生命周期管理。建议把轨迹保留帧数调大（比如 60 帧），并且引入基于外观的长期 ReID 特征库，在目标重新出现时能快速恢复 ID。

5.2 用最小代价验证一个跟踪方案

选定方案之后，不要一上来就在自己的数据集上跑全量。我一般会先用 MOT17 的某个子序列做快速验证，确认环境配置、模型加载、推理流程都通了，再迁移到自己的数据上。下面是一个用 ByteTrack 做快速验证的最小命令示例：

# 克隆 ByteTrack 官方仓库（假设你已经有了） # 下载 YOLOX-X 预训练权重和 MOT17 数据 # 运行跟踪推理 python tools/track.py \ -f exps/example/mot/yolox_x_mix_det.py \ -c pretrained/yolox_x.pth \ -b 1 -d 1 --fp16 --fuse \ --conf 0.1 --nms 0.7 \ --min-box-area 10 --track-thresh 0.5 --match-thresh 0.8

关键参数说明：--conf 0.1是检测置信度阈值，ByteTrack 需要较低的第一阶段阈值来保留低分框；--track-thresh 0.5是轨迹激活阈值，新轨迹需要连续多帧匹配上才会被确认；--match-thresh 0.8是关联时的 IoU 匹配阈值，这个值越高匹配越严格，漏匹配会增多但误匹配会减少。实际调参时，如果发现 ID Switch 偏多，优先降低--match-thresh；如果发现轨迹碎片化严重，优先提高--track-thresh。

5.3 一个容易被忽视的验证技巧

最后分享一个我在实际项目中反复用到的技巧：用跟踪结果的可视化视频来定位问题，而不是只看指标数字。指标告诉你“IDF1 是多少”，但可视化视频能告诉你“ID 在哪个位置、哪一帧发生了跳变、跳变时画面里发生了什么”。我一般会用 OpenCV 把跟踪结果画成带 ID 标注的视频，逐帧检查 ID Switch 的高发区域。很多时候你会发现，问题不是出在关联算法上，而是检测器在某个特定角度或光照条件下漏检了，导致轨迹断裂后重新初始化时分配了新 ID。这种问题看指标是看不出来的，但看视频一目了然。

希望这些经验能帮你在检测跟踪这个方向上少走一些弯路。

本文还有配套的精品资源，点击获取