سجل مقياس التدريب: هل القيمة المعروضة هي الأفضل؟

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

لا؛ قراءة قيمة واحدة لا تحدد أفضل حالة تدريب. حدد طريقة الاسترجاع وقاعدة العرض، ثم اقرأ التاريخ إذا احتجت تغير المقياس.

• ينص مرجع REST لـGet Run على أحدث timestamp، وعند تعادله أكبر قيمة للاسم نفسه. ^[1] هذا عقد الصفحة المقروءة، لا اختبار لكل إصدار أو عميل.
• سجلنا للخسارة يحوي 0.4 عند الزمن 10، و 0.6 و 0.9 عند الزمن 20؛ تطبيق القاعدة المذكورة يعطي 0.9، بينما أصغر قيمة 0.4.
• المتوسط اليدوي للقيم الثلاث نحو 0.6333؛ القيمة المعروضة وأصغر خسارة والمتوسط تجيب عن أسئلة مختلفة، ولا تختار منها وزنًا محفوظًا تلقائيًا.
• Get Metric History يسترجع تاريخ المفتاح والتشغيل، وقد يقسم الاسترجاع بصفحات عند تحديد max_results؛ تابع next_page_token إن وجد. ^[1] لم نستدع الخدمة.

ما العقد الذي يختار قيمة العرض؟

تذكر صفحة REST أن Get Run يعيد قيمة أحدث طابع زمني للمقياس المتكرر، ثم الأكبر عند تعادل الطابع. ^[1]

نحصر الشرح في هذه العبارة من مرجع الخدمة. لا ندمجها بعقد Python أو تطبيق خلفي آخر لم نراجعه، ولا نحول كلمة «أحدث» إلى «أعلى خطوة» دون نص يدعم ذلك. إذا اختلف ما شاهدته في بيئتك، تحتاج تحديد الإصدار والواجهة قبل تطبيق مقارنة.

واسم المفتاح جزء من الوحدة: سجل «الخسارة» غير سجل «الدقة»، حتى لو اتفقا في رقم أو وقت. وكذلك القيم من تشغيلين مختلفين لا تصبح تاريخًا واحدًا لأن الاسم مكتوب بالطريقة نفسها.

كيف تعطي القاعدة خسارة أكبر؟

نؤلف تشغيلًا واحدًا اسمه ت، ومفتاحًا نسميه الخسارة. سجله الكامل في تمريننا ثلاثة إدخالات: 0.4 عند طابع 10، ثم 0.6 و 0.9 عند طابع 20. الطوابع أرقام ترتيب زمنية معلنة، وليست أوقاتًا حقيقية أو ثواني تدريب.

الأحدث هنا 20، وفيه قيمتان. تطبيق الأكبر على هاتين فقط يختار 0.9. لا يختار 0.4 لأنه أصغر خسارة في التاريخ، ولا يجمع 0.6 و 0.9. نحتاج إلى معرفة القاعدتين بالترتيب لنفهم هذا الاختيار.

ولو اكتفينا بقول «الخسارة 0.9»، لحذفنا وجود 0.4 سابقًا وتعدد القيم عند أحدث طابع. لم يثبت الرقم أن التدريب تحسن أو تراجع باستمرار، لأننا لا نعرف حتى سياق القياس أو تعريفه التفصيلي.

أي سؤال يجيب عنه كل تلخيص؟

إذا أردنا أصغر خسارة في القائمة المعلنة، فالجواب 0.4. وإذا أردنا متوسط الإدخالات الثلاثة بالتساوي، نجمع 1.9 ونقسم على 3، فيكون نحو 0.6333. وإذا أردنا قيمة العرض وفق العبارة السابقة، فالجواب 0.9. لا يوجد تناقض حسابي بين هذه الأجوبة.

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

لا نختار ملف أوزان بمجرد العثور على أصغر خسارة. يحتاج الربط إلى تعريف أي قياس يخص أي حالة وما حفظ فعلًا. سجل رقم جيد ووجود نسخة مقابلة صالحة شيئان مختلفان في خطة المراجعة.

كيف تطلب التاريخ دون افتراض اكتمال صفحة؟

يصف Get Metric History قيم مفتاح محدد وتشغيل محدد؛ مع max_results يمكن أن يظهر next_page_token، وغيابه يعني عدم وجود صفحة إضافية وفق العقد. ^[1]

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

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