退屈なグルーコードを取り除いてくれるツールが好きです。computer visionには、それが多すぎます。あるモデルはボックスを返し、別のモデルはマスクを返し、3つ目のモデルはキーポイントを返します。すると、フォーマット変換、色、ラベル、tracking、ゾーン、export、evaluationを何度も書き直すことになります。
Roboflow Supervisionが興味深いのは、そのレイヤーに取り組んでいるからです。これは別のモデルではありません。computer visionの作業を取り巻くPythonレイヤーです。`Detections`、annotators、dataset loaders、tracking、metrics、そして生のinferenceをプロダクトのロジックに変えるために必要なユーティリティが含まれています。
これを使って作る予定のアプリのアイデアがいくつかあります。まだアプリの詳細は明かせませんが、パターンは明確です。videoまたはimageを入力し、構造化された観測結果を出力し、その後に実際のプロダクトに必要なdecision、timeline、またはalertを生成します。
Supervisionの現在地
2026年7月3日にソースを確認しました。`roboflow/supervision` GitHub repoでは、2026年6月23日に公開された`0.29.1`がlatest releaseになっています。PyPIでも同じversionが表示されています。repoはおよそ46,000 stars、4,000以上のforks、そしてMIT licenseを有しています。
これらの数字は、このlibraryがあらゆる問題を解決することを証明するものではありません。多くのdeveloperが同じ痛みに直面していることを示しています。modelは仕事の一部にすぎません。modelの周囲には、次の作業がまだ必要です。
私にとって最も重要なのは最後の点です。アプリのロジックを壊さずにmodelsを入れ替えたいのです。アプリが内部的に`sv.Detections`を使って動作していれば、modelはRF-DETR、YOLO、Roboflow Inference、Ultralytics、その他Supervisionが読み込めるものにできます。
Benchmarks：数字が示すこと
Roboflowは、Supervisionで構築した公開Computer Vision Model Leaderboardを運営しています。方法は簡単に確認できます。RoboflowはmodelsをMicrosoft COCO 2017と比較し、benchmarkingを独立して実行し、各model providerの公開手順に従っています。Roboflowはまた、COCOが一般的なobjects向けのstandard benchmarkである一方、domain-specificな作業には不十分だと説明しています。特殊なdomainには、独自のdataまたはより広範なbenchmarksが必要です。
このサンプルは、`roboflow/model-leaderboard`にあるrawの`aggregate_results.json` fileから取得し、`mAP 50:95`でsortしたものです。パーセンテージは丸めています。
| Model | Architecture | Parameters | 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 |
私の見方では、COCOのquality table上位はRF-DETRが占めており、特にlarge variantsで顕著です。ただし、それだけでRF-DETR-XXLが適切なapp modelになるわけではありません。size、license、latency、deployment target、そしてミスのコストは、mAPと同じくらい重要です。
Small modelsは別のストーリーを示します。
| Model | Parameters | 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 |
アプリにとっては、このtableのほうがleaderboardの最上段より重要なことがよくあります。local Mac app、mobile prototype、retail edge box、video toolが、最初から最大のmodelを必要とすることはほとんどありません。必要なのは、十分に良い最初の回答、速いresponse time、予測可能な挙動、そして把握されたerror profileです。
Roboflow自身のobject detection modelsに関するguideは、latencyについて有用なcontextを加えています。そこでは、RF-DETR-MをCOCOで54.7% mAP、NVIDIA T4で4.52 ms latency、YOLOv12-Xを55.2% mAP、11.79 ms latencyとして掲載しています。これらの数字はleaderboardのraw fileではなくRoboflowの記事に由来するため、同じbenchmark runの結果ではなく、補足的なcontextとして扱っています。
役立つ部分はmAPより大きい
Supervisionが役立つのは、benchmarkingがtableからappのdecisionへ移ったときです。
productには、leaderboardだけでは答えられない問いがあります。
Supervisionはその段階に適しています。複数のmodelsを同じdatasetに対して実行し、outputsを同じstructureにnormalizeし、比較可能なoutputsを描画し、同じmetricsで測定できます。さらに、detection objectsの上にproduct rulesを構築できます。zones、line crossings、dwell time、speed、counts、CSV/JSON export、visual reviewなどです。
多くのcomputer vision appsは、modelがboxを描画するdemoの段階で止まります。productが始まるのは、そのboxが時間の経過とともに何を意味するのかを理解したときです。
重要な小さなrelease details
changelogは実用的です。`0.26.0`で、Roboflowは`sv.HeatMapAnnotator`について、1920x1080 framesでHSV color mappingが約28倍高速になったと記載しています。同じreleaseでは、`sv.MeanAveragePrecision`が`pycocotools`と完全に整合するようになりました。COCO-style measurementを信頼したい場合、これは重要です。
`0.28.0`では、Roboflowが`sv.CompactMask`を追加しました。これはfull-resolution bitmapsの代わりに、crop bounding boxesとRLEとしてsparse masksを保存します。Roboflowは、sparse masksで最大240倍のmemory削減を挙げています。この変更はdemoでは劇的に聞こえないかもしれませんが、video appが長時間のsessionに耐えられるかどうかを左右する可能性があります。
実用的な問題も修正されています。`VideoInfo`のfloat FPS、`process_video`のaudio muxing、Pythonの`logging`を通じたlogging、COCO annotationsのloading時のpath traversal protectionなどです。これはmarketingではありません。動き続けなければならないものを構築するときに気づく、library maintenanceです。
自分のアイデアをどうbenchmarkするか
私は3つのレベルから始めます。
まず、model benchmarksです。アプリの実際の環境に合ったdatasetで、mAP 50:95、mAP 50、small/medium/large AP、F1、confusion matrixを測定します。COCOは方向性を示しますが、最終的なdecisionではありません。
次に、runtime benchmarksです。frameあたりのlatency、memory peak、CPU/GPU load、battery impact、そして長時間videoでの挙動を測定します。1枚のきれいなimageではなく、5分後の数字が欲しいのです。
最後に、product benchmarksです。userがsystemを修正しなければならない頻度、誤って保存されるeventsの数、保存が必要なdata量、そしてUXが不確実性を扱えるかどうかを測定します。不確実性を隠すcomputer vision appは、modelがtable上で良く見えても、悪いdecisionを生む可能性があります。
だからこそ、今Supervisionに注目しています。modelをreplaceableな状態に保ちながら、annotation、tracking、measurement、exportを同じ形に維持できるneutral layerを提供してくれるからです。
私の結論
Roboflow Supervisionはcomputer visionを簡単にするわけではありません。よりmessyでなくします。
私が重視しているのは、その違いです。まだ話せないapp ideasを構築するとき、custom format conversionや、半端に保守されたscriptsの山に行き詰まりたくありません。model Aとmodel Bを試し、結果をvisualに確認し、同じmetricsで測定し、信頼できるstructureの上にproduct logicを構築したいのです。
Supervisionは、その作業に適した強力なlayerに見えます。