عدد حسابات الخسارة في خطوة LBFGS ليس اسمًا آخر لعدد مرات تغيير الوزن. تحدد الوثائق step يستقبل closure تعيد تقييم النموذج وتعيد الخسارة، وتفصل حد التكرارات من حد تقييم الدالة. [1] نصنع سجلًا حسابيًا يميز هذه الوحدات دون تشغيل المحسن.
الخلاصة السريعة
لا؛ عد الاستدعاءات والتقييمات والتغييرات كلًا بوحدته. تكرار حساب الخسارة لا يثبت أن الوزن تغير في كل مرة.
- تستقبل step في LBFGS دالة closure تعيد التقييم والخسارة؛ max_iter للتكرارات وmax_eval لتقييمات الدالة في الخطوة. [1]
- نعلن خسارة (w − 1)² وثلاثة تقييمات عند أوزان 2 ثم 1 ثم 1؛ خسائرها 1 ثم صفر ثم صفر، والتقييم الأخير لا يضيف تغير وزن.
- في سجلنا استدعاء خارجي واحد وتقييمات ثلاثة وانتقال عددي واحد؛ هذا تمرين وحدات مستقل، لا مسار LBFGS استخرجناه أو برهان تقارب.
- الإعدادان حدان موصوفان، لا عددان رصدناهما. سجل الظروف ومواضع التقييم والتغير فعلًا؛ لا تحول تكرار القيمة أو اسم الخطوة إلى تحديث جديد.
ماذا تعيد الدالة التي تستقبلها الخطوة؟
توثق LBFGS أن closure تعيد تقييم النموذج وتعيد الخسارة، وتفصل max_iter عن max_eval لكل خطوة تحسين. [1]
نحتاج هذا الفصل عند قراءة سجل كتبته دالة التقييم. قد يزيد عدد سطور الخسارة، لكن اسم السطر لا يحدد هل تغيرت المعاملات أو هل انتهى استدعاء step أو بدأ آخر. نعلن الأحداث التي نعدها بدل تسميتها جميعًا «خطوات».
وفي هذا المقال لا نكتب closure جاهزة لتدريب شبكة، ولا نقرر ما يجب أن تعيده مهمة بعينها من معلومات أخرى. نقرأ وظيفة موثقة ثم نستعمل جدولًا مستقلًا لتمييز حساب قيمة عن تغير الحالة التي حسبت عندها.
هل تقييمان عند الوزن نفسه تحديثان؟
نختار دالة عددية بسيطة: الخسارة L = (w − 1)². ونؤلف ثلاثة أحداث تقييم مرتبة: عند w يساوي 2، ثم عند 1، ثم عند 1 مرة أخرى. نفترض أن كل حدث يعيد حساب الدالة في النقطة المذكورة، لا أنه سطر مكرر بسبب نسخ سجل.
في الأول الخسارة (2 − 1)² = 1. في الثاني والثالث (1 − 1)² = صفر. حصلنا على ثلاث قيم تقييم، لكن بين الأوزان المتجاورة تغير واحد: 2 إلى 1، ثم بقيت القيمة 1. إعادة الحساب الأخيرة حدث تقييم رغم عدم وجود تغير عددي جديد.
لم ننسب اختيار الأوزان إلى بحث خطي أو شروط قبول من LBFGS. لا يكفي هذا الجدول لإعادة بناء تلك الآلية، كما لا يثبت أن برنامجًا فعليًا كان سيستدعي الدالة بهذا الترتيب. الأرقام تحدد المثال الحسابي فقط.
أي وحدة تظهر في تقريرنا؟
نضع الأحداث الثلاثة داخل استدعاء خارجي واحد افترضناه. تكون بطاقة العد: استدعاءات خارجية واحدة، تقييمات ثلاث، انتقالات عددية غير صفرية واحدة بين النقاط المسجلة. هذه ثلاثة تعريفات، وليست ثلاث إجابات متعارضة على السؤال نفسه.
إذا حسب تقرير كل تقييم تحديثًا، نسب إلى مثالنا ثلاثة تحديثات دون أن يعلن تغيرات تقابلها. وإذا حسب استدعاء step ثلاثة استدعاءات لأنه رأى ثلاثة أسطر، أعاد تسمية الوحدة. نطلب حدود الاستدعاء وموضع تقييمه ولقطة المعامل إذا احتجنا هذا التفصيل.
وجود ثلاث خسائر لا يثبت ثلاث دفعات أو مرورًا على البيانات ثلاث مرات؛ لم نقدم بيانات أصلًا. وحتى خسارة صفر عند نقطة مختارة ليست شهادة نجاح مهمة تعلم حقيقية. إنها ناتج دالة اخترناها عند قيمة نعرفها.
هل الحد المضبوط هو العدد الفعلي؟
تصف الصفحة max_iter بحد التكرارات داخل خطوة، وmax_eval بحد تقييمات الدالة داخلها. [1]
الإعداد المطلوب لا يمثل سجلًا وقع فعلًا. إذا كتبنا الحد أربعة، لا نحول أربعة إلى خبر أن أربع تقييمات تمت، ولا نقيس منه زمنًا بلا تجربة. وللحديث عن تفاصيل التوقف أو البحث الخطي نحتاج إعدادًا وإصدارًا ومسارًا محددًا؛ لم نفحص تلك الفروع هنا.
نقترح حفظ عداد للتقييم وعدّ الاستدعاءات الخارجية وتعريف التغيير الذي نريد الإبلاغ عنه، ثم مقارنة ما سجل فعلًا بالإعدادات. يفصل الرسم هذه الوحدات، ولا يعرض نتيجة محسن شغلناه أو وعدًا بأن جمع حسابات أكثر يعطي وزنًا أفضل.
المصادر ومتابعة القراءة
- PyTorch main: LBFGS (يفتح في نافذة جديدة)docs.pytorch.org
أُعدّ هذا المقال بصياغة عربية أصلية بالاستناد إلى المصادر أعلاه، وهو مدخل تمهيدي إلى الموضوع. اقرأ منهجية المحتوى وحدوده.