Jag gillar verktyg som tar bort tråkig limkod. Computer vision har för mycket av den: en modell returnerar boxar, en annan returnerar masker, en tredje returnerar keypoints, och sedan börjar du skriva om formatkonvertering, färger, etiketter, tracking, zoner, export och utvärdering.
Roboflow Supervision är intressant eftersom det angriper det lagret. Det är inte ännu en modell. Det är ett Python-lager runt computer vision-arbete: `Detections`, annotators, dataset loaders, tracking, metrics och verktygen du behöver för att omvandla rå inference till produktlogik.
Jag har några appidéer som jag planerar att bygga med detta. Jag kan inte avslöja något om apparna ännu, men mönstret är tydligt: video eller bild in, strukturerad observation ut, sedan ett beslut, en tidslinje eller en alert som hör hemma i en riktig produkt.
Var Supervision står nu
Jag kontrollerade källorna den 3 juli 2026. GitHub-repot `roboflow/supervision` visar `0.29.1` som den senaste releasen, publicerad den 23 juni 2026. PyPI visar samma version. Repot ligger på omkring 46 000 stjärnor, fler än 4 000 forks och en MIT-licens.
De siffrorna bevisar inte att biblioteket löser alla problem. De visar att många utvecklare stöter på samma problem: modellen är bara en del av arbetet. Runt modellen behöver du fortfarande:
Den sista punkten är viktigast för mig. Jag vill kunna byta modeller utan att riva upp appens logik. Om appen internt fungerar med `sv.Detections` kan modellen vara RF-DETR, YOLO, Roboflow Inference, Ultralytics eller något annat som Supervision kan läsa.
Benchmarks: vad siffrorna säger
Roboflow driver en offentlig Computer Vision Model Leaderboard som är byggd med Supervision. Metoden är enkel att granska: Roboflow jämför modeller mot Microsoft COCO 2017, kör benchmarkingen oberoende och följer varje modellleverantörs offentliga instruktioner. Roboflow uppger också att COCO är en standardbenchmark för vanliga objekt, men att den inte räcker för domänspecifikt arbete. Särskilda domäner behöver sina egna data eller bredare benchmarks.
Det här urvalet kommer från den råa filen `aggregate_results.json` i `roboflow/model-leaderboard`, sorterad efter `mAP 50:95`. Procenttalen är avrundade.
| Modell | Arkitektur | Parametrar | mAP 50:95 | mAP 50 | Small AP | Medium AP | Large AP | Licens |
|---|---|---|---|---|---|---|---|---|
| --- | ---: | ---: | ---: | ---: | ---: | ---: | ---: | --- |
| 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 |
Min tolkning: RF-DETR dominerar toppen av COCO-tabellen för kvalitet, särskilt bland de större varianterna. Det gör inte automatiskt RF-DETR-XXL till rätt appmodell. Storlek, licens, latency, deployment-mål och kostnaden för misstag är minst lika viktiga som mAP.
Små modeller berättar en annan historia:
| Modell | Parametrar | mAP 50:95 | mAP 50 | Small AP | Licens |
|---|---|---|---|---|---|
| --- | ---: | ---: | ---: | ---: | --- |
| 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 |
För appar är den här tabellen ofta viktigare än leaderboardens topprad. En lokal Mac-app, mobil prototyp, edge-box för retail eller videoverktyg behöver sällan den största modellen först. Den behöver ett bra första svar, snabb responstid, förutsägbart beteende och en känd felprofil.
Roboflows egen guide till object detection-modeller ger användbar latency-kontext: den listar RF-DETR-M med 54.7% mAP på COCO och 4.52 ms latency på en NVIDIA T4, medan YOLOv12-X listas med 55.2% mAP och 11.79 ms latency. De siffrorna kommer från en Roboflow-artikel, inte från leaderboardens råfil, så jag ser dem som stödjande kontext snarare än som samma benchmarkkörning.
Den användbara delen är större än mAP
Supervision blir användbart när benchmarking går från en tabell till ett appbeslut.
En produkt behöver svar som leaderboarden inte kan ge på egen hand:
Supervision passar den fasen. Du kan köra flera modeller mot samma dataset, normalisera outputen till samma struktur, rita jämförbara resultat och mäta dem med samma metrics. Du kan också bygga produktregler ovanpå detection-objekt: zoner, linjepassager, vistelsetid, hastighet, antal, CSV/JSON-export och visuell granskning.
Många computer vision-appar stannar vid demon där modellen ritar en box. Produkten börjar när du vet vad boxen betyder över tid.
Små release-detaljer som spelar roll
Changeloggen är praktisk. I `0.26.0` skrev Roboflow att `sv.HeatMapAnnotator` fick ungefär 28 gånger snabbare HSV-färgkartläggning på 1920x1080-bildrutor. Samma release gjorde `sv.MeanAveragePrecision` helt kompatibel med `pycocotools`, vilket spelar roll om du vill kunna lita på COCO-liknande mätning.
I `0.28.0` lade Roboflow till `sv.CompactMask`, som lagrar glesa masker som crop bounding boxes plus RLE i stället för bitmaps i full upplösning. Roboflow anger upp till 240 gånger lägre minnesanvändning för glesa masker. Den förändringen låter kanske inte dramatisk i en demo, men den kan avgöra om en videoapp klarar längre sessioner.
De har också åtgärdat praktiska problem: flyttals-FPS i `VideoInfo`, audio muxing i `process_video`, loggning genom Pythons `logging` och skydd mot path traversal vid inläsning av COCO-annotationer. Det är inte marknadsföring. Det är biblioteksunderhåll som du märker när du bygger något som måste fortsätta fungera.
Så skulle jag benchmarka mina egna idéer
Jag skulle börja på tre nivåer.
Först modellbenchmarks: mAP 50:95, mAP 50, small/medium/large AP, F1 och confusion matrix på ett dataset som matchar appens verkliga miljö. COCO ger riktning, inte det slutliga beslutet.
Sedan runtime-benchmarks: latency per bildruta, minnesanvändning, CPU/GPU-belastning, batteripåverkan och beteende över längre video. Jag vill ha siffror efter 5 minuter, inte en enda ren bild.
Till sist produktbenchmarks: hur ofta användaren måste korrigera systemet, hur många events som sparas felaktigt, hur mycket data som måste lagras och om UX:en hanterar osäkerhet. En computer vision-app som döljer osäkerhet kan leda till dåliga beslut även när modellen ser bra ut i en tabell.
Det är därför jag tittar på Supervision nu. Det ger mig ett neutralt lager där modellen kan förbli utbytbar medan annotation, tracking, mätning och export behåller samma form.
Min slutsats
Roboflow Supervision gör inte computer vision enkelt. Det gör det mindre rörigt.
Det är skillnaden jag bryr mig om. När jag bygger appidéerna som jag ännu inte kan diskutera vill jag inte fastna i anpassad formatkonvertering och en halvt underhållen hög med skript. Jag vill testa modell A mot modell B, granska resultaten visuellt, mäta dem med samma metrics och bygga produktlogik på en struktur jag kan lita på.
Supervision ser ut som ett starkt lager för det arbetet.