मॉडल गुणवत्ता के आधार पर मर्ज रोकें

एक गुणवत्ता द्वार pull request को merge होने से रोकता है, जब तक नया मॉडल पर्याप्त अच्छा न हो। यह मॉडल की गुणवत्ता को आशा नहीं, बल्कि कठोर नियम बना देता है। 🚧

कोड हर test में सफल हो सकता है और फिर भी खराब मॉडल बना सकता है। उपयोगकर्ताओं की सुरक्षा के लिए आपको metric, जैसे accuracy या F1, की अलग जाँच चाहिए।

ऐसा एक मुख्य metric चुनें जो आपके task की सफलता दर्शाता हो। एक साथ बहुत-से numbers पर gate लगाने से हर PR एक उलझी हुई बातचीत बन जाता है।

एक न्यूनतम सीमा, यानी अपना threshold, तय करें। यदि नया मॉडल इससे कम score करता है, तो build विफल हो जाता है और merge अपने-आप रुक जाता है।

हमेशा उसी अलग रखे गए test set पर score करें। स्थिर evaluation set हर pull request और run के बीच तुलना को निष्पक्ष बनाता है।

CI में non-zero code के साथ समाप्त होने वाला step job को विफल चिह्नित करता है। इसलिए यदि metric अपेक्षित स्तर तक नहीं पहुँचता, तो merge रोकने के लिए आप जानबूझकर एक error उत्पन्न करते हैं।

एक अधिक समझदार gate नए मॉडल की तुलना production में मौजूद वर्तमान baseline से करता है और केवल कोई निश्चित number पाने के बजाय खराब प्रदर्शन करने वाले merges को रोकता है।

GitHub में branch protection के अंतर्गत CI job को अनिवार्य जाँच के रूप में चिह्नित करें। इसके बाद आपका gate सफल होने तक merge button disabled रहेगा।

Score print करें, ताकि reviewers उसे देख सकें। metric दिखाने वाली स्पष्ट log line या PR का comment लाल X को ऐसे explanation में बदल देता है जिस पर लोग भरोसा कर सकें।

कभी-कभी थोड़ी गिरावट स्वीकार्य होती है। review approval के माध्यम से किसी व्यक्ति को विफल gate को override करने दें, ताकि नियम team को दिशा दे, लेकिन उसे पूरी तरह रोक न दे।

एक seed और स्थिर test set तय करें, ताकि वही मॉडल वही number दे। एक नियतात्मक eval gate को केवल संयोग के कारण विफल होने से बचाता है।

एक metric चुनें, threshold तय करें या baseline से बेहतर score करें, और score कम होने पर build विफल करें। Job को अनिवार्य चिह्नित करें, ताकि कमज़ोर मॉडल चुपचाप कभी merge न हो सके।