जब आपके "बेहतर" फीचर्स आपका मॉडल खराब कर दें

जब आपके "बेहतर" फीचर्स आपका मॉडल खराब कर दें

वो एहसास आपको पता है? आप दिनों तक एक शानदार नया फीचर बनाने में लगे रहते हैं। वो बिल्कुल वही सिग्नल पकड़ता है जो आप चाहते थे। आप ट्रेन करते हैं, इवैल्यूएट करते हैं, और आपका Class 2 F1 0.72 से उछलकर 0.78 पर पहुँच जाता है। आप मुस्कुराते हैं। फिर लीडरबोर्ड पर सबमिट करते हैं, और आपका स्कोर गिर जाता है। क्या हुआ? आपने अभी-अभी feature engineering trade-off का सामना किया है।

यह एक ऐसा जाल है जिसमें लगभग हर डेटा साइंटिस्ट कम से कम एक बार फँसता है। मैं खुद कुछ महीने पहले इसमें फँसा था, और इसने मेरा पूरा एक हफ्ता बर्बाद कर दिया डिबगिंग में। तो चलिए, मैं आपको बताता हूँ कि असल में अंदर क्या हो रहा होता है, आपके चतुर मैनुअल फीचर्स क्यों उल्टा पड़ सकते हैं, और ऐसा feature evaluation workflow कैसे बनाएं जो आपसे झूठ न बोले।

क्लासिक ट्रैप: एक मेट्रिक की जीत, दूसरी मेट्रिक की हार

एकदम सटीक सीन समझिए। मैं एक क्लाइंट के लिए multi-class classification मॉडल बना रहा था। बेसलाइन ठीक-ठाक थी। फिर मैंने दो हाथ से बनाए गए फीचर्स जोड़े: **Impact Severity** और **Energy Ratio**। दोनों raw sensor data से निकाले गए थे, और एक दुर्लभ fault class को पकड़ने के लिए डिज़ाइन किए गए थे। उनमें फिजिक्स की समझ थी। वैलिडेशन पर Class 2 F1 0.72 से बढ़कर 0.78 हो गया। सुंदर, है ना?

अभी रुकिए। जब मैंने पूरी तस्वीर देखी, तो Class 0 और Class 1 के F1 दोनों गिर चुके थे। लीडरबोर्ड — जो सभी क्लासेज का weighted average इस्तेमाल करता था — मेरी बेसलाइन से नीचे था। मॉडल ने असल में यह सीख लिया था कि माइनॉरिटी क्लास को बेहतर दिखाने के लिए मेजॉरिटी क्लासेज की बलि चढ़ा देनी है।

यह बदकिस्मती नहीं है। यह shared probability budget का गणितीय सच है। ज़्यादातर multi-class मॉडल्स में, एक क्लास का कॉन्फिडेंस बढ़ाने का मतलब दूसरी क्लास का कॉन्फिडेंस घटाना होता है। अगर आपके नए फीचर्स मौजूदा फीचर्स से काफी हद तक correlated हैं, तो आप जानकारी नहीं जोड़ रहे — आप noise और skew को बढ़ा रहे हैं।

मैनुअल फीचर्स उल्टा क्यों पड़ते हैं?

Multicollinearity एक खामोश किलर है

जब आपका नया फीचर दो-तीन मौजूदा फीचर्स से correlated होता है, तो मॉडल उनके बीच क्रेडिट बाँट देता है। Tree-based मॉडल्स में यह महत्वपूर्ण splits को छिपा सकता है। Linear मॉडल्स में यह coefficients को फुला देता है। नतीजा? कम स्थिर प्रेडिक्शन, खासकर अनदेखे डेटा पर।

सबसे बुरी बात यह है कि multicollinearity हमेशा ट्रेनिंग अक्यूरसी को नुकसान नहीं पहुँचाती। यह आपको noise याद करने में मदद भी कर सकती है। लेकिन जैसे ही टेस्ट डिस्ट्रीब्यूशन में हल्का-सा बदलाव आता है, आपका शानदार नया फीचर एक बोझ बन जाता है।

Precision/Recall ट्रेड-ऑफ

अगर आपने Class 2 को खोजने के लिए फीचर बनाया है, तो संभवतः आप Class 2 की recall बढ़ा रहे हैं जबकि Class 1 की precision तबाह हो रही है। मान लीजिए आपका थ्रेशोल्ड शिफ्ट होता है। ज़्यादा उदाहरण Class 2 के रूप में क्लासिफाई होते हैं, लेकिन उनमें से कई असल में Class 1 या Class 0 हैं। आपका macro स्कोर गिर जाता है, भले ही आपकी "टारगेट क्लास" बेहतर दिख रही हो।

मैं यह fraud detection में हर समय देखता हूँ। कोई एक ऐसा फीचर बनाता है जो ज़्यादा fraud पकड़ता है, लेकिन साथ में ढेर सारे असली ट्रांज़ैक्शन को भी फ्लैग कर देता है। मॉडल की fraud recall बढ़ जाती है, लेकिन false positive rate दोगुनी हो जाती है। असल दुनिया में इसका मतलब है गुस्सैल कस्टमर और तनाव में डूबी सपोर्ट टीम।

लीडरबोर्ड मेट्रिक्स आमतौर पर एग्रीगेटेड होती हैं

ज़्यादातर लीडरबोर्ड एक ही scalar मेट्रिक इस्तेमाल करते हैं — accuracy, macro-F1, weighted kappa, या log loss। वह scalar हर क्लास का अलग-अलग हाल छिपा देता है। अगर आप सिर्फ एक हिस्से के लिए ऑप्टिमाइज़ कर रहे हैं, तो आप पूरे के लिए ऑप्टिमाइज़ नहीं कर रहे। Class 2 F1 में पाँच पॉइंट की बढ़त, दूसरी दो क्लासेज में तीन-तीन पॉइंट की गिरावट से मिट सकती है — यह क्लास वेट्स पर निर्भर करता है।

इसीलिए अब मैं सबसे पहले कॉम्पिटिशन या प्रोजेक्ट की मेट्रिक को बड़े ध्यान से पढ़ता हूँ। अगर weighted F1 है, तो दुर्लभ क्लास में सुधार का महत्व बहुत छोटा है। अगर macro-F1 है, तो हर क्लास बराबर मायने रखती है — चाहे आप उनकी परवाह करें या न करें।

एक असल दुनिया का उदाहरण: सेंसर डेटा केस

मैं आपको एक ठोस उदाहरण देता हूँ। एक मैन्युफैक्चरिंग प्लांट है जहाँ सेंसर तापमान, कंपन और दबाव मापते हैं। बेसलाइन मॉडल: तीन fault क्लासेज पर 0.85 macro-F1।

मैंने एक **energy ratio** बनाया = vibration amplitude / pressure variance। यह फिजिकली समझ में आता था। हाई-एनर्जी इम्पैक्ट्स का मतलब गंभीर फॉल्ट होना चाहिए। ट्रेनिंग सेट पर Class 2 F1 उछलकर 0.81 पर पहुँच गया। लेकिन cross-validation में यह फायदा टिक नहीं पाया। क्यों? energy ratio raw vibration और pressure से बहुत ज़्यादा correlated था — फिर वही multicollinearity। टेस्ट डेटा में, कम दबाव पर सेंसर नॉइज़ ने ratio को विस्फोटित कर दिया, और मॉडल झूठे Class 2 प्रेडिक्शन देने लगा।

समाधान उल्टा था: raw ratio जोड़ने के बजाय, मैंने एक residual feature इस्तेमाल किया — vibration का वह हिस्सा जो pressure द्वारा *स्पष्ट नहीं* होता। उस orthogonalized सिग्नल ने वास्तव में नई जानकारी दी, और लीडरबोर्ड स्कोर सभी क्लासेज में सुधरा। सबक: यह मत पूछिए "क्या मेरा फीचर समझ में आता है?" पूछिए "क्या मेरा फीचर ऐसी जानकारी देता है जो मौजूदा मॉडल के पास पहले से नहीं है?"

एक और उदाहरण: ई-कॉमर्स चर्न प्रेडिक्शन

मैंने एक सब्सक्रिप्शन बॉक्स कंपनी के साथ काम किया। मार्केटिंग टीम एक **customer engagement score** चाहती थी जो लॉगिन फ्रीक्वेंसी, सपोर्ट टिकट्स और सोशल मीडिया मेंशन को जोड़ता। सुनने में शानदार लगा। लेकिन वह स्कोर मौजूदा फीचर्स का एक weighted sum मात्र था। जब मैंने उसे मॉडल में जोड़ा, feature importance रैंकिंग उलट-पुलट हो गई, लेकिन AUC वहीं की वहीं रही। बदतर यह कि low-engagement यूज़र्स के लिए calibration खराब हो गई, क्योंकि स्कोर loss पर हावी हो गया।

हमने वह handcrafted स्कोर हटाकर एक आसान-सा फीचर रखा: पिछले सात दिनों में संपर्क किए गए अलग-अलग फीचर कैटेगरी की गिनती। उस छोटे, कम correlated फीचर ने असली फायदा दिया। सबक फिर वही: कभी-कभी सबसे कम चमकने वाला फीचर सबसे अच्छा होता है।

फीचर्स को बिना धोखा खाए इवैल्यूएट कैसे करें?

1. Multi-Metric स्कोरकार्ड बनाइए

सिर्फ Class 2 के F1 पर नज़र मत रखिए। एक स्कोरकार्ड बनाइए जिसमें शामिल हो:

- Macro-F1 और weighted-F1
- हर क्लास के लिए precision और recall
- Log loss या Brier score (कैलिब्रेशन के लिए)
- एक नोट कि क्या per-class मेट्रिक्स एक ही दिशा में चलीं

हर एक्सपेरिमेंट के बाद मैं आमतौर पर यह प्रिंट करता हूँ:

| मेट्रिक | बेसलाइन | नया फीचर | परिणाम |
|---|---|---|---|
| Class 0 F1 | 0.88 | 0.84 | खराब |
| Class 1 F1 | 0.82 | 0.79 | खराब |
| Class 2 F1 | 0.72 | 0.78 | अच्छा |
| Macro-F1 | 0.81 | 0.80 | खराब |

एक नज़र में पूरी कहानी साफ है। चमकता हुआ नया फीचर एक क्लास की मदद करता है लेकिन बाकी को नुकसान पहुँचाता है। इस स्कोरकार्ड के बिना मैं मॉडल सबमिट कर देता और बुरी तरह चौंकता।

2. Correlation ऑडिट चलाइए

मैनुअल फीचर जोड़ने से पहले, मौजूदा फीचर्स के साथ उसका correlation जाँचिए। pandas `df.corr()` इस्तेमाल करें और 0.7 से ऊपर के absolute values देखें। अगर आपका नया फीचर मौजूदा फीचर्स के बहुत करीब है, तो विकल्प:

- किसी redundant फीचर को हटाना
- Residualization इस्तेमाल करना (नए फीचर को पुराने फीचर्स पर regress करें, residual लें)
- scikit-learn के `SelectKBest` या `RFECV` से feature selection करना

Scikit-learn का आधिकारिक feature selection गाइड व्यावहारिक तरीकों से भरा है: https://scikit-learn.org/stable/modules/feature_selection.html

3. SHAP से दिशा-निर्देशित प्रभाव समझिए

ट्रेनिंग के बाद, SHAP values निकालकर देखिए कि आपका नया फीचर हर क्लास को कैसे प्रभावित करता है। कभी-कभी कोई फीचर Class 2 के लिए उपयोगी होता है लेकिन Class 1 के लिए सक्रिय रूप से हानिकारक। SHAP summary plot आपको यह तुरंत दिखा देगा। यह लाइब्रेरी open-source है और अच्छी तरह maintained है: https://github.com/shap/shap.

मैंने कई "शानदार" फीचर्स पकड़े हैं जिनके SHAP values एक क्लास के लिए बहुत सकारात्मक थे, लेकिन दूसरी क्लास के लिए और भी ज़्यादा नकारात्मक। यही वह trade-off है जिसे आपको सबमिट करने से पहले देखना है।

4. Ablation आज़माइए

Ablation का मतलब है फीचर हटाकर देखना कि क्या होता है। हैरानी की बात है कि मैनुअल feature engineering में यह बहुत कम किया जाता है। मैं हमेशा तीन एक्सपेरिमेंट चलाता हूँ:

- पुराने फीचर्स के साथ बेसलाइन
- बेसलाइन + नया फीचर
- बेसलाइन + नया फीचर, एक पुराना correlated फीचर हटाकर

अगर तीसरा एक्सपेरिमेंट दूसरे से बेहतर है, तो आपने multicollinearity की समस्या हल कर ली है। अगर दूसरा पहले से खराब है, तो फीचर हटा दें। अगर दूसरा बेहतर है लेकिन लीडरबोर्ड कुछ और कहता है, तो अपने वैलिडेशन सेटअप में गहराई से जाँच करें।

तीसरा उदाहरण: मेडिकल ट्रायेज क्लासिफिकेशन

मैंने एक symptom-checker प्रोटोटाइप पर काम किया था। लक्ष्य मरीजों को तीन urgency स्तरों में वर्गीकृत करना था। मैंने एक **comorbidity score** बनाया — पहले से मौजूद बीमारियों की संख्या जोड़कर। इसने हाई-अर्जेंसी मरीजों की पहचान में सुधार किया, लेकिन साथ ही मॉडल ने *वर्तमान* लक्षण की गंभीरता को अनदेखा करना शुरू कर दिया। एक मरीज जिसे एक हल्का लक्षण था और एक comorbidity थी, उसे हाई-अर्जेंसी क्लासिफाई किया गया — हालाँकि उसका असली जोखिम कम था।

समस्या यह थी कि मेरा फीचर बहुत हावी हो गया था। मॉडल ने उसे इसलिए पकड़ा क्योंकि उस पर split करना आसान था, और उसने ज़्यादा समृद्ध, बारीक टेक्स्ट फीचर्स को अनदेखा कर दिया। यह एक और प्रमुख trade-off है: **feature dominance**। एक मज़बूत handcrafted फीचर कमज़ोर लेकिन अधिक सूचनात्मक फीचर्स को किनारे कर सकता है। Regularization और feature interactions मदद कर सकते हैं, लेकिन अक्सर सरल समाधान बेहतर होता है।

बड़ा सबक: फीचर्स मुफ्त नहीं हैं

हर फीचर जोड़ने से मॉडल की जटिलता बढ़ती है, ट्रेनिंग समय बढ़ता है, और overfitting का खतरा बढ़ता है। Regularization मदद कर सकती है, लेकिन वह मूल रूप से redundant फीचर को ठीक नहीं कर सकती। आपको हर फीचर को एक शर्त की तरह सोचना होगा: उसे कई मेट्रिक्स पर नई, स्थिर जानकारी जोड़कर अपनी जगह साबित करनी होगी।

मैंने यह भी सीखा है कि जब कोई फीचर जोड़ने के बाद लीडरबोर्ड गिरता है, तो मूल कारण लगभग कभी "मेट्रिक गलत है" नहीं होता। असल में मैं एक local optimum के पीछे भाग रहा था। मॉडल बेवकूफ नहीं है — वह बिल्कुल वही कर रहा है जो मैंने कहा। मैंने बस गलत चीज़ माँगी।

FAQ

मेरा F1 एक क्लास पर ऊपर गया, लेकिन कुल लीडरबोर्ड स्कोर नीचे क्यों गया?

क्योंकि लीडरबोर्ड शायद weighted या macro average का उपयोग करता है। आपका मॉडल दूसरी क्लासेज की precision या recall की कुर्बानी देकर उस एक क्लास पर फायदा कमा रहा है जिस पर आपने ध्यान केंद्रित किया। उत्साहित होने से पहले हमेशा पूरा confusion matrix देखिए।

Multicollinear फीचर्स के साथ सबसे अच्छा तरीका क्या है?

पहले correlation जाँचिए। अगर दो फीचर्स अत्यधिक correlated हैं, तो एक को हटाइए या नए फीचर का residualized संस्करण इस्तेमाल कीजिए। L1 या L2 जैसे Regularization मॉडल को स्थिर करने में मदद कर सकते हैं, लेकिन redundancy हटाना आमतौर पर जुर्माने से ठीक करने की तुलना में अधिक प्रभावी होता है।

क्या आधुनिक मशीन लर्निंग में मैनुअल feature engineering अभी भी उपयोगी है?

हाँ, लेकिन केवल तब जब यह domain knowledge को एनकोड करता है जो मॉडल में पहले से मौजूद नहीं है। अगर कोई फीचर मौजूदा फीचर्स का केवल गणितीय संयोजन है, तो वह आमतौर पर मदद नहीं करेगा। अगर वह वास्तव में नया सिग्नल पकड़ता है, तो वह शक्तिशाली हो सकता है। असली कुंजी यह सत्यापित करना है कि वह वास्तव में स्वतंत्र जानकारी जोड़ रहा है।

मुझे कैसे पता चलेगा कि कोई फीचर वास्तव में मदद कर रहा है?

बेसलाइन मॉडल और फीचर वाले मॉडल की तुलना कई मेट्रिक्स और cross-validation के साथ कीजिए। Ablation चलाइए। Feature importance और SHAP values देखिए। अगर सुधार folds या मेट्रिक्स के बीच असंगत है, तो संभवतः वह overfitting है।

आखिरी बातें

मुझे पता है वह रोमांच कैसा होता है जब आप एक आदर्श फीचर बनाते हैं। लगता है जैसे आपने कोई कोड क्रैक कर लिया। लेकिन लीडरबोर्ड ही असली रेफरी है। जितनी जल्दी आप multi-metric evaluation को अपने workflow में शामिल करेंगे, उतना ही कम समय आप उन फीचर्स पर बर्बाद करेंगे जो समस्या के सिर्फ एक हिस्से की मदद करते हैं।

अगली बार जब आप वह चतुर "impact severity" फीचर शिप करने वाले हों, तो रुकिए। खुद से पूछिए: "क्या यह नई जानकारी जोड़ रहा है, या सिर्फ उसी सिग्नल को बढ़ा रहा है जो मेरे पास पहले से है?" आपका भविष्य — और आपकी लीडरबोर्ड रैंकिंग — आपको धन्यवाद देगी।