Мені подобаються інструменти, які прибирають нудний клейовий код. У комп’ютерному зорі його надто багато: одна модель повертає рамки, інша — маски, третя — ключові точки, а потім ви починаєте знову писати перетворення форматів, кольори, мітки, трекінг, зони, експорт і оцінювання.
Roboflow Supervision цікавий тим, що працює саме з цим шаром. Це не ще одна модель. Це Python-шар навколо роботи з комп’ютерним зором: `Detections`, анотаторів, завантажувачів датасетів, трекінгу, метрик і утиліт, потрібних для перетворення необробленого inference на продуктову логіку.
У мене є кілька ідей застосунків, які я планую створити за допомогою цього інструмента. Я поки не можу розкривати подробиці, але закономірність очевидна: на вході відео або зображення, на виході — структуроване спостереження, а потім рішення, часова шкала або сповіщення, які мають бути частиною реального продукту.
На якому етапі зараз Supervision
Я перевірив джерела 3 липня 2026 року. Репозиторій `roboflow/supervision` на GitHub показує `0.29.1` як останній реліз, опублікований 23 червня 2026 року. PyPI показує ту саму версію. Репозиторій має близько 46 000 зірок, понад 4 000 форків і ліцензію MIT.
Ці цифри не доводять, що бібліотека розв’язує кожну проблему. Вони показують, що багато розробників стикаються з одним і тим самим болем: модель — лише одна частина роботи. Навколо моделі все одно потрібно:
Останній пункт для мене найважливіший. Я хочу змінювати моделі, не руйнуючи логіку застосунку. Якщо всередині застосунок працює з `sv.Detections`, моделлю може бути RF-DETR, YOLO, Roboflow Inference, Ultralytics або будь-що інше, що вміє читати Supervision.
Бенчмарки: що показують цифри
Roboflow підтримує публічний Computer Vision Model Leaderboard, створений за допомогою Supervision. Метод легко перевірити: Roboflow порівнює моделі з Microsoft COCO 2017, проводить бенчмаркінг незалежно й дотримується публічних інструкцій кожного постачальника моделей. Roboflow також зазначає, що COCO — це стандартний бенчмарк для поширених об’єктів, але його недостатньо для роботи у спеціалізованих сферах. Для таких сфер потрібні власні дані або ширші бенчмарки.
Цей приклад взято з необробленого файлу `aggregate_results.json` у `roboflow/model-leaderboard`, відсортованого за `mAP 50:95`. Відсотки округлено.
| Модель | Архітектура | Параметри | mAP 50:95 | mAP 50 | AP для малих об’єктів | AP для середніх об’єктів | AP для великих об’єктів | Ліцензія |
|---|---|---|---|---|---|---|---|---|
| --- | ---: | ---: | ---: | ---: | ---: | ---: | ---: | --- |
| 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 правильною моделлю для застосунку. Розмір, ліцензія, затримка, ціль розгортання та ціна помилок мають не менше значення, ніж mAP.
Малі моделі розповідають іншу історію:
| Модель | Параметри | mAP 50:95 | mAP 50 | AP для малих об’єктів | Ліцензія |
|---|---|---|---|---|---|
| --- | ---: | ---: | ---: | ---: | --- |
| 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-застосунку, мобільному прототипу, edge-пристрою для роздрібної торгівлі або відеоінструменту рідко одразу потрібна найбільша модель. Їм потрібні хороша перша відповідь, швидкий час відгуку, передбачувана поведінка та відомий профіль помилок.
Власний посібник Roboflow щодо моделей виявлення об’єктів додає корисний контекст про затримку: у ньому для RF-DETR-M вказано 54.7% mAP на COCO із затримкою 4.52 мс на NVIDIA T4, тоді як для YOLOv12-X — 55.2% mAP із затримкою 11.79 мс. Ці цифри походять зі статті Roboflow, а не з необробленого файлу leaderboard, тому я сприймаю їх як додатковий контекст, а не як результати того самого запуску бенчмарку.
Корисна частина більша за mAP
Supervision стає корисним тоді, коли бенчмаркінг переходить із таблиці до рішення для застосунку.
Продукту потрібні відповіді, яких leaderboard сам по собі не дає:
Supervision добре підходить для цього етапу. Ви можете запускати кілька моделей на одному датасеті, нормалізувати результати до однакової структури, малювати порівнювані результати й вимірювати їх за допомогою однакових метрик. Також можна будувати продуктові правила поверх об’єктів виявлення: зони, перетини ліній, час перебування, швидкість, підрахунки, експорт у CSV/JSON і візуальний перегляд.
Багато застосунків комп’ютерного зору зупиняються на демонстрації, де модель малює рамку. Продукт починається тоді, коли ви розумієте, що ця рамка означає з часом.
Невеликі деталі релізів, які мають значення
Журнал змін практичний. У `0.26.0` Roboflow написав, що `sv.HeatMapAnnotator` отримав приблизно 28-кратне прискорення HSV-відображення кольорів на кадрах 1920x1080. У тому самому релізі `sv.MeanAveragePrecision` було повністю узгоджено з `pycocotools`, що важливо, якщо ви хочете довіряти вимірюванням у стилі COCO.
У `0.28.0` Roboflow додав `sv.CompactMask`, який зберігає розріджені маски як рамки обрізання плюс RLE замість повнорозмірних растрових зображень. Roboflow вказує на до 240-кратне зменшення використання пам’яті для розріджених масок. У демонстрації ця зміна може не здаватися драматичною, але вона здатна визначити, чи витримає відеозастосунок довші сеанси.
Також було виправлено практичні проблеми: дробове значення FPS у `VideoInfo`, об’єднання аудіо в `process_video`, журналювання через Python-модуль `logging` і захист від обходу шляхів під час завантаження COCO-анотацій. Це не маркетинг. Це обслуговування бібліотеки, яке ви помічаєте, коли створюєте щось, що має працювати безперервно.
Як я б проводив бенчмаркінг власних ідей
Я б почав із трьох рівнів.
По-перше, бенчмарки моделей: mAP 50:95, mAP 50, AP для малих/середніх/великих об’єктів, F1 і матриця помилок на датасеті, який відповідає реальному середовищу застосунку. COCO задає напрямок, але не ухвалює остаточне рішення.
По-друге, бенчмарки виконання: затримка на кадр, пікове споживання пам’яті, навантаження на CPU/GPU, вплив на батарею та поведінка під час тривалішої роботи з відео. Мені потрібні цифри після 5 хвилин, а не лише на одному чистому зображенні.
По-третє, продуктові бенчмарки: як часто користувачеві доводиться виправляти систему, скільки подій зберігається неправильно, який обсяг даних потрібно зберігати та чи справляється UX із невизначеністю. Застосунок комп’ютерного зору, який приховує невизначеність, може призводити до поганих рішень, навіть якщо модель добре виглядає в таблиці.
Саме тому я зараз придивляюся до Supervision. Він дає мені нейтральний шар, у якому модель можна замінювати, а анотація, трекінг, вимірювання та експорт зберігають однакову структуру.
Мій висновок
Roboflow Supervision не робить комп’ютерний зір простим. Він робить його менш хаотичним.
Саме ця різниця для мене важлива. Коли я створюватиму ідеї застосунків, про які поки не можу розповідати, я не хочу застрягнути у власних перетвореннях форматів і напівпідтримуваній купі скриптів. Я хочу тестувати модель A проти моделі B, візуально перевіряти результати, вимірювати їх за допомогою однакових метрик і будувати продуктову логіку на структурі, якій можу довіряти.
Supervision виглядає сильним шаром для такої роботи.