我喜欢能够消除无聊胶水代码的工具。计算机视觉中这类代码太多了：一个模型返回边界框，另一个返回掩码，第三个返回关键点，接着你就要不断重写格式转换、颜色、标签、跟踪、区域、导出和评估逻辑。
Roboflow Supervision 有意思的地方在于，它正是针对这一层展开的。它不是另一个模型，而是围绕计算机视觉工作的 Python 层：`Detections`、标注器、数据集加载器、跟踪、指标，以及将原始推理结果转化为产品逻辑所需的各种工具。
我有几个计划用它构建的应用想法。目前还不能透露这些应用的具体内容，但模式很清晰：输入视频或图像，输出结构化观察结果，然后生成适用于真实产品的决策、时间线或提醒。
Supervision 目前的状态
我在 2026 年 7 月 3 日检查了相关来源。`roboflow/supervision` GitHub 仓库显示 `0.29.1` 是最新版本，于 2026 年 6 月 23 日发布。PyPI 显示的也是同一版本。该仓库目前约有 46,000 个 stars、超过 4,000 个 forks，并采用 MIT license。
这些数字并不能证明这个库解决了所有问题，但它们说明许多开发者遇到了同样的痛点：模型只是工作的一部分。在模型之外，你仍然需要：
最后一点对我来说最重要。我希望能够替换模型，而不必大幅改动应用逻辑。如果应用内部使用 `sv.Detections`，那么模型可以是 RF-DETR、YOLO、Roboflow Inference、Ultralytics，或者任何 Supervision 能够读取的其他模型。
基准测试：数字说明了什么
Roboflow 运行着一个使用 Supervision 构建的公开 Computer Vision Model Leaderboard。其方法很容易检查：Roboflow 将模型与 Microsoft COCO 2017 进行比较，独立执行基准测试，并遵循每个模型提供商公开的说明。Roboflow 还指出，COCO 是常见对象的标准基准，但不足以覆盖特定领域的工作。特殊领域需要自己的数据或更广泛的基准。
以下样本来自 `roboflow/model-leaderboard` 中的原始 `aggregate_results.json` 文件，并按 `mAP 50:95` 排序。百分比已四舍五入。
| 模型 | 架构 | 参数量 | mAP 50:95 | mAP 50 | Small AP | Medium AP | Large AP | License |
|---|---|---|---|---|---|---|---|---|
| --- | ---: | ---: | ---: | ---: | ---: | ---: | ---: | --- |
| RF-DETR-XXL | RF-DETR | 126.9M | 59.9% | 78.2% | 43.2% | 64.8% | 76.0% | PML-1.0 |
| RF-DETR-XL | RF-DETR | 126.4M | 58.5% | 77.1% | 40.1% | 63.8% | 76.1% | PML-1.0 |
| DEIM-D-FINE-X | DEIM-D-FINE | 61.7M | 56.5% | 74.0% | 38.8% | 61.4% | 74.2% | Apache-2.0 |
| YOLO26x | YOLO26 | 55.7M | 56.3% | 73.4% | 40.5% | 60.6% | 72.4% | AGPL-3.0 |
| RF-DETR-L | RF-DETR | 33.9M | 56.3% | 74.8% | 37.4% | 60.8% | 73.8% | Apache-2.0 |
| DEIM-RT-DETRv2-X | DEIM-RT-DETRv2 | 74.9M | 55.5% | 73.5% | 37.9% | 59.9% | 72.9% | Apache-2.0 |
| RF-DETR-M | RF-DETR | 33.7M | 54.8% | 73.6% | 36.0% | 59.8% | 73.7% | Apache-2.0 |
| YOLOv12x | YOLOv12 | 59.1M | 54.0% | 70.3% | 38.2% | 59.6% | 69.8% | AGPL-3.0 |
我的看法是：RF-DETR 在 COCO 质量榜单的顶部占据主导地位，尤其是在较大的变体中。但这并不意味着 RF-DETR-XXL 自动就是适合应用的模型。模型大小、license、延迟、部署目标以及错误成本，与 mAP 同样重要。
小型模型呈现出不同的情况：
| 模型 | 参数量 | mAP 50:95 | mAP 50 | Small AP | License |
|---|---|---|---|---|---|
| --- | ---: | ---: | ---: | ---: | --- |
| YOLO26n | 2.4M | 39.9% | 55.2% | 19.2% | AGPL-3.0 |
| YOLOv13n | 2.5M | 40.4% | 56.2% | 19.4% | AGPL-3.0 |
| YOLOv12n | 2.6M | 39.7% | 55.0% | 19.1% | AGPL-3.0 |
| YOLO11n | 2.6M | 38.6% | 53.9% | 18.9% | AGPL-3.0 |
| YOLOv8n | 3.2M | 36.5% | 51.4% | 17.4% | AGPL-3.0 |
对于应用来说，这张表往往比榜单第一行更重要。本地 Mac 应用、移动端原型、零售边缘设备或视频工具，通常不需要一开始就使用最大的模型。它们需要的是一个足够好的初始结果、快速的响应时间、可预测的行为，以及明确的错误特征。
Roboflow 自己的目标检测模型指南还提供了有用的延迟背景：其中列出 RF-DETR-M 在 COCO 上的 mAP 为 54.7%，在 NVIDIA T4 上的延迟为 4.52 ms；YOLOv12-X 的 mAP 为 55.2%，延迟为 11.79 ms。这些数字来自 Roboflow 的一篇文章，而不是榜单原始文件，因此我将它们视为补充背景，而不是同一轮基准测试的结果。
有用的部分不止 mAP
当基准测试从一张表转化为应用决策时，Supervision 才真正变得有用。
产品需要一些榜单本身无法回答的问题：
Supervision 适合这一阶段。你可以让多个模型在同一数据集上运行，将输出标准化为相同的结构，绘制可比较的结果，并使用相同的指标进行衡量。你还可以在检测对象之上构建产品规则：区域、越线、停留时间、速度、计数、CSV/JSON 导出和可视化审查。
许多计算机视觉应用在模型绘制出边界框的演示阶段就停止了。产品真正开始于你理解这个边界框在一段时间内意味着什么。
值得关注的小版本细节
更新日志很实用。在 `0.26.0` 中，Roboflow 写道，`sv.HeatMapAnnotator` 在 1920x1080 帧上的 HSV 颜色映射速度提升了约 28 倍。同一版本还让 `sv.MeanAveragePrecision` 与 `pycocotools` 完全对齐；如果你希望信任 COCO 风格的测量，这一点很重要。
在 `0.28.0` 中，Roboflow 添加了 `sv.CompactMask`。它不再存储全分辨率位图，而是将稀疏掩码存储为裁剪边界框加 RLE。Roboflow 列出的稀疏掩码内存使用量最高可降低 240 倍。这项变化在演示中听起来可能并不惊人，但它可能决定一个视频应用能否支撑更长的会话。
他们还修复了一些实际问题：`VideoInfo` 中的浮点 FPS、`process_video` 中的音频封装、通过 Python 的 `logging` 进行日志记录，以及加载 COCO 标注时的路径遍历保护。这不是营销。这些都是当你构建一个必须持续运行的东西时会注意到的库维护工作。
我会如何为自己的想法进行基准测试
我会从三个层次开始。
第一，模型基准测试：在符合应用真实环境的数据集上测试 mAP 50:95、mAP 50、small/medium/large AP、F1 和混淆矩阵。COCO 提供方向，但不是最终决策。
第二，运行时基准测试：每帧延迟、内存峰值、CPU/GPU 负载、电池影响，以及在更长视频中的表现。我想要的是运行 5 分钟后的数字，而不是一张干净图像上的结果。
第三，产品基准测试：用户需要多频繁地纠正系统，有多少事件被错误保存，需要存储多少数据，以及 UX 是否能够处理不确定性。即使模型在表格中表现良好，一个隐藏不确定性的计算机视觉应用仍然可能导致糟糕的决策。
这就是我现在关注 Supervision 的原因。它提供了一个中立层，让模型可以保持可替换，同时使标注、跟踪、测量和导出维持相同的结构。
我的结论
Roboflow Supervision 并不会让计算机视觉变得简单，但它会让计算机视觉变得不那么混乱。
这正是我在意的区别。当我构建那些目前还不能讨论的应用想法时，我不想陷入自定义格式转换和一堆维护不善的脚本中。我希望能够测试模型 A 和模型 B，直观检查结果，使用相同的指标衡量它们，并在一个值得信赖的结构上构建产品逻辑。
Supervision 看起来是一个适合这类工作的强大层。