التنصيف المتتابع: لماذا يقل المرشحون وتكبر موارد كل منها؟

الخلاصة السريعة

في جدول التنصيف تقل المرشحات بينما تزيد الموارد لكل مرشح؛ حاصل الضرب حساب ميزانية معلنة، وليس قياسًا لوقت تشغيل.

• يربط HalvingGridSearchCV عامل التنصيف بتقليل المرشحين وزيادة الموارد، وتوثيقه يصف الواجهة بأنها تجريبية. ^[1]
• جدولنا المعلن يبدأ بثمانية مرشحين وثلاث وحدات لكل واحد، ثم أربعة مع ست وحدات، ثم اثنين مع اثنتي عشرة؛ نحسب 24 في كل مرحلة.
• مجموع 14 زيارة مرشح و 72 وحدة مرشح حساب للجدول؛ لا يثبت عدد أمثلة فريدة أو وقت جهاز أو استكمال التدريب السابق.
• المورد الافتراضي n_samples؛ استعمال معامل آخر موردًا يحتاج تحديد max_resources صراحة. ^[1] جدولنا ليس تشغيلًا أو إعدادًا تحققنا من قبوله.

أي عدد يقسمه العامل؟

يوثق HalvingGridSearchCV عاملًا يقسم عدد المرشحين ويزيد الموارد لكل مرشح، والواجهة تجريبية. ^[1]

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

يختلف «ثمانية مرشحين» عن «ثلاث وحدات لكل مرشح». العدد الأول يصف عرض المنافسة، والثاني يصف المورد الفردي في مرحلتها. تسجيلهما في عمودين يجعل زيادة أحدهما مع نقصان الآخر قابلة للفهم دون عبارة عامة عن التوسع.

كيف تتساوى منتجات ثلاث مراحل؟

نعلن جدولًا بسيطًا: ثمانية مرشحين بموارد ثلاثة لكل منهم، ثم أربعة بموارد ستة، ثم اثنان بموارد اثنتي عشرة. المنتجات هي 8×3 و 4×6 و 2×12 ، وكل واحد يساوي 24 وحدة مرشح في حسابنا.

لا تتساوى الأعداد التي ضربناها: لدينا منافسة واسعة قليلة الموارد أولًا، ثم منافسة أضيق أكثر موارد للفرد. إذا عرضنا 24 وحدها، ضاعت هذه البنية. والمساواة هنا تعتمد على جدول يقبل القسمة تمامًا؛ لم نقدم قاعدة لتقريب أعداد لا تقبلها.

كما لا نصف الناتج بأنه 24 ثانية. الموارد قد تكون وحدات غير زمنية، والعلاقة بينها وبين الوقت تحتاج قياسًا. حتى إن كان عدد الموارد نفسه متساويًا، لم نثبت تساوي أعباء المرشحين أو سرعة أي مرحلة.

ماذا يعني جمع الزيارات والموارد؟

عد الزيارات عبر المراحل يعطي 8+4+2=14. هذه ليست 14 هوية جديدة: بعض المرشحين يعودون في مرحلة لاحقة. وجمع المنتجات يعطي 24+24+24=72 وحدة مرشح وفق طريقة الحساب المعلنة.

إذا كان المورد عدد صفوف مستخدمة، فلا يصبح 72 عدد صفوف فريدة؛ قد تستعمل صفوف نفسها مع أكثر من مرشح أو مرحلة. لم نعلن هويات الصفوف أو طريقة أخذها، لذلك لا نملأ ذلك الفراغ من حاصل الضرب.

كذلك لا نقرر أن المرحلة التالية تستكمل معاملات تدريب السابقة، أو أنها تبدأها من جديد. جدول أعداد وحده لا يبين هذا المسار. ولم نقس وقتًا أو طاقة أو ذاكرة تسمح بتحويل 72 إلى كلفة جهاز فعلية.

ما الذي يتغير مع اسم المورد؟

المورد الافتراضي في الواجهة n_samples؛ إذا استعملنا معاملًا آخر، يطلب العقد تحديد max_resources صراحة. ^[1]

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

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