أحب الأدوات التي تزيل الشيفرة الوسيطة المملة. تحتوي الرؤية الحاسوبية على قدر كبير منها: يعيد نموذجٌ ما مربعات، ويعيد آخر أقنعة، ويعيد ثالث نقاطًا مميّزة، ثم تبدأ في إعادة كتابة تحويل التنسيقات والألوان والتسميات والتتبّع والمناطق والتصدير والتقييم.
يُعد Roboflow Supervision مثيرًا للاهتمام لأنه يستهدف هذه الطبقة تحديدًا. فهو ليس نموذجًا آخر، بل طبقة Python حول أعمال الرؤية الحاسوبية: `Detections`، وأدوات التعليق، ومحملات مجموعات البيانات، والتتبّع، والمقاييس، والأدوات المساعدة التي تحتاج إليها لتحويل الاستدلال الخام إلى منطق منتج.
لديّ بعض أفكار التطبيقات التي أخطط لبنائها باستخدامه. لا يمكنني الكشف عن أي شيء عن التطبيقات بعد، لكن النمط واضح: فيديو أو صورة يدخلان، وتخرج ملاحظة منظّمة، ثم قرار أو خط زمني أو تنبيه ينتمي إلى منتج حقيقي.
أين يقف Supervision الآن
تحققت من المصادر في 3 يوليو 2026. يعرض مستودع GitHub `roboflow/supervision` الإصدار `0.29.1` بوصفه أحدث إصدار، وقد نُشر في 23 يونيو 2026. ويعرض PyPI الإصدار نفسه. يضم المستودع نحو 46,000 نجمة، وأكثر من 4,000 تفرّع، وترخيص MIT.
لا تثبت هذه الأرقام أن المكتبة تحل كل مشكلة. لكنها تُظهر أن عددًا كبيرًا من المطورين يواجهون الألم نفسه: النموذج ليس سوى جزء واحد من المهمة. وحول النموذج، ما زلت تحتاج إلى:
النقطة الأخيرة هي الأهم بالنسبة إليّ. أريد تبديل النماذج دون تمزيق منطق التطبيق. إذا كان التطبيق يعمل داخليًا باستخدام `sv.Detections`، فيمكن أن يكون النموذج RF-DETR أو YOLO أو Roboflow Inference أو Ultralytics أو أي شيء آخر يستطيع Supervision قراءته.
المعايير: ماذا تقول الأرقام
تشغّل Roboflow لوحة متصدرين عامة لنماذج الرؤية الحاسوبية مبنية باستخدام 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 محلي أو نموذج أولي للهاتف أو جهاز طرفي للبيع بالتجزئة أو أداة فيديو إلى أكبر نموذج أولًا. بل يحتاج إلى إجابة أولى جيدة، وزمن استجابة سريع، وسلوك متوقع، وملف أخطاء معروف.
يضيف دليل Roboflow الخاص بنماذج اكتشاف الكائنات سياقًا مفيدًا حول زمن الاستجابة: فهو يذكر أن RF-DETR-M يحقق mAP بنسبة 54.7% على COCO مع زمن استجابة قدره 4.52 ms على NVIDIA T4، بينما يُذكر أن YOLOv12-X يحقق mAP بنسبة 55.2% مع زمن استجابة قدره 11.79 ms. تأتي هذه الأرقام من مقال لدى Roboflow، لا من ملف البيانات الخام للوحة المتصدرين، لذلك أتعامل معها كسياق داعم لا بوصفها جزءًا من عملية القياس نفسها.
الجزء المفيد أكبر من mAP
يصبح Supervision مفيدًا عندما ينتقل قياس الأداء من جدول إلى قرار داخل التطبيق.
يحتاج المنتج إلى إجابات لا تستطيع لوحة المتصدرين تقديمها بمفردها:
يناسب 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`، والتسجيل عبر `logging` في Python، والحماية من اجتياز المسارات عند تحميل تعليقات COCO. هذا ليس تسويقًا، بل صيانة للمكتبة تلاحظها عندما تبني شيئًا يجب أن يستمر في العمل.
كيف سأقيس أفكاري الخاصة
سأبدأ بثلاثة مستويات.
أولًا، معايير قياس النماذج: mAP 50:95 وmAP 50 وAP للكائنات الصغيرة/المتوسطة/الكبيرة وF1 ومصفوفة الالتباس على مجموعة بيانات تطابق البيئة الحقيقية للتطبيق. تمنحك COCO اتجاهًا، لا القرار النهائي.
ثانيًا، معايير قياس وقت التشغيل: زمن الاستجابة لكل إطار، وذروة الذاكرة، وحمل CPU/GPU، وتأثير البطارية، والسلوك خلال الفيديو الأطول. أريد أرقامًا بعد 5 دقائق، لا صورة نظيفة واحدة.
ثالثًا، معايير قياس المنتج: عدد المرات التي يضطر فيها المستخدم إلى تصحيح النظام، وعدد الأحداث التي تُحفظ بصورة غير صحيحة، وكمية البيانات التي يجب تخزينها، وما إذا كانت تجربة المستخدم تتعامل مع عدم اليقين. قد ينشئ تطبيق الرؤية الحاسوبية الذي يخفي عدم اليقين قرارات سيئة حتى عندما يبدو النموذج جيدًا في جدول.
لهذا السبب أنظر إلى Supervision الآن. فهو يمنحني طبقة محايدة يمكن أن يظل فيها النموذج قابلًا للاستبدال، بينما تحافظ التعليقات والتتبّع والقياس والتصدير على البنية نفسها.
خلاصة رأيي
لا يجعل Roboflow Supervision الرؤية الحاسوبية سهلة. لكنه يجعلها أقل فوضوية.
هذا هو الفرق الذي يهمني. عندما أبني أفكار التطبيقات التي لا أستطيع مناقشتها بعد، لا أريد أن أعلق في تحويلات تنسيق مخصصة وكومة من البرامج النصية التي لا تتم صيانتها جيدًا. أريد اختبار النموذج A مقابل النموذج B، وفحص النتائج بصريًا، وقياسها باستخدام المقاييس نفسها، وبناء منطق المنتج على بنية يمكنني الوثوق بها.
يبدو Supervision طبقة قوية لهذا العمل.