زيادة صناديق الحدود في الكشف: التنسيقات والأخطاء والممارسات الأفضل

تكرس مقالة منشورة على منصة Habr للسبب الشائع وغالباً المتجاهل للفشل في تدريب نماذج كشف الأجسام: ليس البنية الشبكية نفسها، بل ما يحدث لصناديق المحيط (bbox) — مستطيلات التعليق — بعد تطبيق التعزيزات.

حيث ينقطع الترميز الأكثر تكراراً

يسرد المؤلف الأخطاء النموذجية التي لا تسبب توقف الكود مع استثناء، لكنها تفسد مجموعة البيانات التدريبية صمتياً: تنسيق إحداثيات محدد بشكل غير صحيح (coord_format)، والبلبلة بين الإحداثيات المحمية والمطلقة، وعمليات القطع العدوانية جداً، وظهور صناديق فارغة بعد تصفية الأجسام التي خرجت عن الإطار. لا تسبب مثل هذه الأخطاء فشل صريح للخط الأنابيب — النموذج يتدرب ببساطة على ترميز مشوه، وينسب انخفاض الجودة الناتج إلى الهندسة المعمارية أو المعاملات الفائقة، على الرغم من أن السبب يكمن في المعالجة المسبقة.

تتفاقم المشكلة بسبب حقيقة أن مجموعات البيانات المختلفة والمكتبات المختلفة تاريخياً تستخدم اتفاقيات مختلفة لتخزين إحداثيات bbox: أحياناً تكون إحداثيات بكسل مطلقة من الزوايا اليمنى العلوية والسفلية اليسرى، وأحياناً قيم محمية من الصفر إلى واحد نسبة إلى أبعاد الصورة، وأحياناً — إحداثيات مركز الصندوق مع العرض والارتفاع. يكفي الخلط بين هذه التمثيلات مرة واحدة عند نقل الترميز بين مراحل خط الأنابيب لمتابعة التدريب دون أخطاء، لكن النموذج يتعلم إيجاد الأجسام ليس حيث تكون بالفعل في الصورة.

• المكتبة المناقشة: Albumentations
• تنسيقات bbox المدعومة: COCO، YOLO، pascal_voc
• المعاملات الرئيسية: A.BboxParams، min_area، min_visibility
• المشكلة النموذجية: RandomCrop غالباً ما يعمل بشكل سيء لمهام الكشف
• المصدر: Habr

كيفية تكوين Albumentations بشكل صحيح؟

تفصل المقالة الجانب العملي من المسألة باستخدام مثال مكتبة Albumentations — واحدة من أكثر أدوات تعزيز الصور شيوعاً في رؤية الحاسوب. يناقش تنسيقات bbox المدعومة من قبل المكتبة والتكوين الصحيح لمعامل A.BboxParams، وكذلك الغرض من معاملات min_area و min_visibility، التي تحدد الحد الأدنى للحجم أو الرؤية الكائن بعد التحويل لكي تُعتبر bbox صالحة بدلاً من أن تُرفض أو تُشوه.

يتم استخدام Albumentations على نطاق واسع لأنها يمكنها تحويل صورة ومميزاتها المرتبطة بها بشكل متزامن — عند الدوران أو الانعكاس أو تغيير حجم الصورة، تعيد المكتبة حساب إحداثيات جميع bbox عليها تلقائياً، مما يعفي المطور من كتابة هذا المنطق يدوياً. لكن هذه الأتمتة نفسها تصبح مصدر مشاكل إذا كانت معاملات A.BboxParams محددة بشكل غير صحيح: لن تنتج المكتبة خطأ، فهي ستعيد حساب الإحداثيات ببساطة وفقاً للتنسيق المحدد (حتى لو كان غير صحيح)، والمطور سيحصل على خط أنابيب تعزيز يبدو صحيحاً شكلياً لكنه فعلياً معطوب.

لماذا RandomCrop ليس دائماً خياراً آمناً

تُكرس اهتمام خاص في المادة للسبب في أن RandomCrop العادي — تعزيز شهير لتصنيف الصور — يتبين غالباً أنه حل ضعيف وخاصة لكشف الأجسام. عندما يتم قطع الإطار عشوائياً، قد تُقطع الأجسام على الحواف جزئياً أو كلياً، وبدون تصفية دقيقة لاحقة من خلال min_area و min_visibility، يحتوي الترميز على صناديق مشوهة أو صناديق فارغة تماماً، التي يعتبرها النموذج بيانات تدريب صالحة.

تُوجه المادة لأولئك الذين يعملون مع تنسيقات الترميز الشهيرة COCO و YOLO و pascal_voc ويريدون فهم السبب في أن التعزيزات "لا تعمل" — أي لماذا إضافة التحويلات القياسية الجاهزة لا تحسن، وأحياناً حتى تزيد من سوء، مقاييس النموذج. القيمة العملية لمثل هذا التفصيل هي أنها تحول التركيز على التصحيح من المعاملات الفائقة والبنى إلى مصدر مشاكل أكثر عادية، لكن متكرر — صحة التحويلات الهندسية للترميز، التي يقلل متخصصو رؤية الحاسوب غالباً من شأنها في بداية المشروع.

بالنسبة للفرق التي تعمل مع مجموعات بيانات الترميز الصناعي، يكون مثل هذا التفصيل ذا قيمة خاصة في مرحلة الانتقال بين التنسيقات: على سبيل المثال، عندما تُترمز البيانات بصيغة COCO، لكن التدريب يُجرى على بنية توقع صيغة YOLO، أو العكس. التحويل اليدوي بين هذه التنسيقات هو مصدر متكرر للأخطاء الغامضة، والمادة تقدم بشكل أساسي قائمة تحقق من الأشياء التي تستحق الفحص قبل نسبة منخفضة جودة النموذج إلى الهندسة المعمارية نفسها أو نقص البيانات.