मशीन लर्निंग में डेटा लीकेज (Data Leakage) का पता लगाना और उसकी रोकथाम करना

प्रॉम्ट और उपयोग के मामले

एक फ्रॉड मॉडल ऑफ़लाइन रैंडम स्प्लिट पर असाधारण रूप से अच्छा प्रदर्शन करता है लेकिन प्रोडक्शन में काफी खराब प्रदर्शन करने लगता है। प्रत्येक पंक्ति (row) एक ट्रांजेक्शन को दर्शाती है, और मॉडल को यह तय करना होता है कि जब ट्रांजेक्शन हो तो उसे ब्लॉक किया जाए या नहीं। लेबल यह है कि क्या ट्रांजेक्शन के 30 दिनों के भीतर चार्जैबक की पुष्टि होती है। संभावित फीचर्स ट्रांजेक्शन इवेंट्स, अकाउंट-हिस्ट्री एग्रीगेट्स, अंतिम चार्जैबक परिणामों और मैन्युअल-रिव्यू स्थितियों से आते हैं।

डेटा लीकेज की व्याख्या करें, टारगेट, टेम्पोरल, एंटिटी-डुप्लिकेशन और प्रीप्रोसेसिंग लीकेज की जाँच करें, तथा फीचर जनरेशन, ट्रेन/वैलिडेशन/टेस्ट स्प्लिटिंग, क्रॉस-वैलिडेशन और अंतिम मूल्यांकन को फिर से डिज़ाइन करें। यह भी स्पष्ट करें कि लीकेज को ट्रेनिंग-सर्विंग स्क्यू (skew) और वास्तविक डिस्ट्रीब्यूशन ड्रिफ्ट से कैसे अलग किया जाए।

यह प्रश्न मशीन लर्निंग इंजीनियरिंग, डेटा साइंस, रिस्क और रिकमेंडर-सिस्टम साक्षात्कारों में पूछा जाता है। साक्षात्कारकर्ता शायद ही कभी केवल “प्रीप्रोसेसिंग से पहले स्प्लिट करें” को पूर्ण उत्तर के रूप में स्वीकार करते हैं। वे पूछेंगे कि क्या कोई फीचर वास्तविक प्रेडिक्शन के समय मौजूद था, क्या वही एंटिटी अलग-अलग पार्टिशन्स में जा सकती है, और क्या टीम ने टेस्ट सेट के आधार पर बार-बार ट्यूनिंग की थी।

साक्षात्कारकर्ता क्या मूल्यांकन करता है

पहला, क्या उम्मीदवार एक व्यावहारिक परिभाषा (operational definition) दे सकता है? डेटा लीकेज तब होता है जब मॉडल डेवलपमेंट या मूल्यांकन में ऐसी जानकारी का उपयोग किया जाता है जो वास्तविक प्रेडिक्शन के समय अनुपलब्ध थी, या जब वैलिडेशन या टेस्ट पार्टिशन की जानकारी ट्रेनिंग, फीचर चयन या मॉडल चयन को प्रभावित करती है। लीकेज अक्सर ऑफ़लाइन मेट्रिक्स को अत्यधिक आशावादी बना देता है, लेकिन केवल प्रोडक्शन में गिरावट ही लीकेज का प्रमाण नहीं होती। डेटा ड्रिफ्ट, असंगत लेबल्स, और गलत ऑनलाइन फीचर गणना भी इसके समान दिख सकती हैं।

दूसरा, क्या उम्मीदवार पहले प्रेडिक्शन अनुबंध को परिभाषित करता है? प्रत्येक पंक्ति के लिए prediction_at, एक लेबल-ऑब्जर्वेशन विंडो, एक डेटा-उपलब्धता कटऑफ, और प्रोडक्शन में सर्व की जाने वाली एंटिटीज़ का विवरण आवश्यक होता है। उस सीमा के बिना, यहाँ तक कि “पिछले सात दिनों के ट्रांजेक्शन” में भी प्रेडिक्शन के बाद के इवेंट्स शामिल हो सकते हैं। कोई व्यावसायिक फ़ील्ड लीक करती है या नहीं, यह इस बात पर निर्भर करता है कि वह कब उपलब्ध होती है, न कि इस बात पर कि उसका नाम कितना उचित लगता है।

तीसरा, क्या स्प्लिट डिप्लॉयमेंट की वास्तविक स्थिति को दोहराता है? साधारण रैंडम स्प्लिटिंग केवल स्वतंत्र और समान रूप से वितरित (IID) नमूनों के लिए उपयुक्त है। क्रमित (ordered) डेटा के लिए फॉरवर्ड वैलिडेशन की आवश्यकता होती है। यूजर, डिवाइस, मर्चेंट, या अन्य ग्रुप स्ट्रक्चर के लिए ग्रुप आइसोलेशन या कम से कम ग्रुप-आधारित स्ट्रेस टेस्ट की आवश्यकता होती है। स्केलिंग, इम्प्यूटेशन, फीचर चयन, और एन्कोडिंग को प्रत्येक ट्रेनिंग फोल्ड के भीतर फिट किया जाना चाहिए, और अंतिम टेस्ट सेट को ट्यूनिंग में भाग नहीं लेना चाहिए।

अंत में, क्या निदान एक साक्ष्य श्रृंखला (evidence chain) बनाता है? उपयोगी जाँचों में पॉइंट-इन-टाइम रीप्ले, एक फीचर-उपलब्धता लेजर, क्रॉस-पार्टिशन डुप्लिकेट ऑडिट, संदिग्ध-फीचर एब्लेशन, लेबल-परम्यूटेशन नेगेटिव कंट्रोल्स, और रैंडम बनाम डिप्लॉयमेंट-अनुरूप स्प्लिट्स के बीच तुलना शामिल हैं। एक मजबूत उत्तर ट्रेड-ऑफ को भी स्वीकार करता है: सख्त मूल्यांकन अक्सर स्कोर को कम करता है और कम ट्रेनिंग डेटा छोड़ता है, लेकिन जनरलाइजेशन का अधिक विश्वसनीय अनुमान प्रदान करता है।

उत्तर देने से पहले स्पष्ट करने योग्य प्रश्न

• प्रेडिक्शन कब होता है? मान लें कि ट्रांजेक्शन के आने पर ही उसे स्कोर किया जाता है। उसके बाद उत्पन्न जानकारी उस पंक्ति के फीचर्स में प्रवेश नहीं कर सकती।
• लेबल कब परिपक्व (mature) होता है? पॉज़िटिव का अर्थ है 30 दिनों के भीतर पुष्ट किया गया चार्जैबक। डेटासेट कटऑफ के पास की वे पंक्तियाँ जिनकी ऑब्जर्वेशन विंडो अधूरी हैं, उन्हें नेगेटिव नहीं माना जा सकता।
• क्या मॉडल मौजूदा या अनदेखी एंटिटीज़ को सर्व करता है? यदि प्रोडक्शन बार-बार पुराने अकाउंट्स को देखता है, तो टेम्पोरल स्प्लिटिंग प्राथमिक मूल्यांकन है। नए मर्चेंट्स या डिवाइसेस के लिए जनरलाइजेशन हेतु एंटिटी-आइसोलेटेड टेस्टिंग की भी आवश्यकता होती है।
• ऐतिहासिक एग्रीगेट्स की गणना किस समय की जाती है? इवेंट के समय और पॉइंट-इन-टाइम/as-of गणना के माध्यम से उस समय वास्तव में दिखाई देने वाले डेटा का उपयोग करें, न कि आज के वेयरहाउस स्नैपशॉट का जिसे इतिहास में बैकफिल किया गया हो।
• क्या डुप्लिकेट्स या लगभग-डुप्लिकेट्स (near duplicates) मौजूद हैं? एक ही ट्रांजेक्शन के री-ट्राई, मिरर्ड लॉग्स, एक ही मामले के लिए कई पंक्तियाँ, और अत्यधिक समान टेक्स्ट सभी पार्टिशन्स को पार कर सकते हैं।
• कौन से चरण डेटा से पैरामीटर्स सीखते हैं? इम्प्यूटेशन, नॉर्मलाइजेशन, वोकैबुलरी, फीचर चयन, डाइमेंशनलिटी रिडक्शन, टारगेट एन्कोडिंग, और थ्रेशोल्ड चयन सभी इसमें शामिल हैं। केवल अंतिम मॉडल का ऑडिट करना अपर्याप्त है।
• टेस्ट सेट को कितनी बार देखा गया है? यदि इसके परिणामों ने फीचर या हाइपरपैरामीटर परिवर्तनों को निर्देशित किया है, तो इसने मॉडल चयन में भाग लिया है और एक नए अछूते होल्डआउट की आवश्यकता है।
• प्रोडक्शन में वास्तव में क्या खराब हुआ? हर विफलता को लीकेज कहने के बजाय इनपुट डिस्ट्रीब्यूशन्स, फीचर मिसिंगनेस, लेबल देरी, ऑफ़लाइन रीप्ले और सर्विंग लॉग्स की तुलना करें।

30-सेकंड उत्तर का ढाँचा

“मैं प्रेडिक्शन समय और 30-दिन की लेबल विंडो को परिभाषित करूँगा, फिर सत्यापित करूँगा कि प्रत्येक फीचर वास्तव में उस समय उपलब्ध था या नहीं। मैं चार लीकेज पाथ्स की जाँच करूँगा: परिणाम के बाद के फ़ील्ड्स (post-outcome fields), भविष्य का डेटा, क्रॉस-पार्टिशन डुप्लिकेट्स, और सभी डेटा पर फिट की गई प्रीप्रोसेसिंग। डेवलपमेंट में फॉरवर्ड वैलिडेशन का उपयोग किया जाता है, जहाँ आवश्यकता हो वहाँ एंटिटी आइसोलेशन होता है, और प्रत्येक सीखा गया ट्रांसफॉर्म केवल ट्रेनिंग फोल्ड्स पर फिट होता है। मॉडल और थ्रेशोल्ड को लॉक करने के बाद, मैं अंतिम होल्डआउट का एक बार मूल्यांकन करता हूँ। पॉइंट-इन-टाइम रीप्ले, ओवरलैप ऑडिट, फीचर एब्लेशन, और लेबल परम्यूटेशन लीकेज का पता लगाने में मदद करते हैं; सर्विंग स्क्यू और ड्रिफ्ट की अलग से जाँच की जाती है।”

चरण-दर-चरण गहन विश्लेषण

स्प्लिटर चुनने से पहले प्रेडिक्शन अनुबंध लिखें। कम से कम, प्रत्येक पंक्ति एक व्यावसायिक एंटिटी, event_at, जिस समय सिस्टम ने वास्तव में इवेंट को available_at के रूप में देखा, prediction_at, और label_ready_at रिकॉर्ड करती है। कोई फीचर केवल तभी पात्र होता है जब available_at <= prediction_at हो और यही बात उसकी गणना के लिए उपयोग किए जाने वाले प्रत्येक अपस्ट्रीम इनपुट पर भी लागू होती है।

इस परिदृश्य के लिए फीचर समीक्षा इस प्रकार दिख सकती है:

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

स्प्लिट को प्रोडक्शन के प्रश्न का पालन करना चाहिए:

1. prediction_at के आधार पर सॉर्ट करें। डेवलपमेंट के लिए पुराने अवधियों का उपयोग करें और अंतिम टेस्ट सेट के रूप में परिपक्व लेबल्स वाली नवीनतम निरंतर अवधि को सील करें।
2. डेवलपमेंट डेटा के भीतर फॉरवर्ड क्रॉस-वैलिडेशन चलाएं: प्रत्येक फोल्ड पुराने डेटा पर ट्रेन होता है और अगली अवधि पर वैलिडेट करता है। यदि लेबल ऑब्जर्वेशन किसी सीमा को पार करता है, तो ट्रेनिंग के अंत को हटा दें (purge) या एक गैप डालें ताकि ट्रेनिंग लेबल्स वैलिडेशन अवधि के परिणामों पर निर्भर न हों।
3. पंक्तियों को असाइन करने से पहले डुप्लिकेट क्लस्टर्स और एंटिटी ग्रुप्स बनाएं। यदि लक्ष्य अनदेखी-एंटिटी का जनरलाइजेशन है, तो प्रत्येक ग्रुप को एक ही तरफ रखें। यदि प्रोडक्शन बार-बार पुरानी एंटिटीज़ को सर्व करता है, तो टेम्पोरल स्प्लिटिंग प्राथमिक मीट्रिक बनी रहती है, लेकिन अकाउंट-, डिवाइस-, या मर्चेंट-आइसोलेटेड स्ट्रेस टेस्ट की भी रिपोर्ट करें।
4. केवल एक ट्रेनिंग फोल्ड ही fit को कॉल कर सकता है। वैलिडेशन फोल्ड्स और टेस्ट सेट को उस ट्रेनिंग फोल्ड पर सीखे गए पैरामीटर्स से transform प्राप्त होता है। ट्रेनिंग के भीतर टारगेट एन्कोडिंग क्रॉस-फिटिंग का उपयोग करती है ताकि प्रत्येक पंक्ति की एन्कोडिंग अन्य फोल्ड्स से आए जो इसके अपने लेबल को बाहर रखते हैं।
5. फीचर्स, हाइपरपैरामीटर्स और डिसीजन थ्रेशोल्ड का चयन करने के लिए क्रॉस-वैलिडेशन का उपयोग करें। एक बार जब हर निर्णय फ्रीज हो जाए, तो सभी डेवलपमेंट डेटा पर एक बार फिर से रीफिट करें और अंतिम टेस्ट का एक बार मूल्यांकन करें। उस परिणाम को पढ़ने के बाद मॉडल को संशोधित करना जारी रखने के लिए एक नए टेस्ट सेट की आवश्यकता होगी।

निम्नलिखित स्यूडोकोड इस वर्कफ़्लो को दर्शाता है। forward_splits टेम्पोरल क्रम और लेबल-विंडो पृथक्करण को लागू करता है, जबकि make_pipeline प्रत्येक सीखे गए ट्रांसफॉर्म को मॉडल से जोड़ता है:

dev, test = point_in_time_split(rows, test_period="latest_mature_period")

for train_idx, valid_idx in forward_splits(
    dev,
    time="prediction_at",
    purge="label_horizon",
):
    pipeline = make_pipeline(
        imputer="fit_on_train_fold",
        scaler="fit_on_train_fold",
        target_encoder="out_of_fold",
        model="candidate",
    )
    pipeline.fit(dev[train_idx].X, dev[train_idx].y)
    record(pipeline, dev[valid_idx])

locked_pipeline = select_and_lock()
locked_pipeline.fit(dev.X, dev.y)
final_result = evaluate_once(locked_pipeline, test)

फिर निदान करें। पहली परत एक स्टैटिक वंशावली (lineage) ऑडिट है: प्रत्येक फीचर के लिए सोर्स टेबल, इवेंट टाइम, उपलब्धता समय, एग्रीगेशन विंडो, अपडेट में देरी, और लेबल निर्भरता रिकॉर्ड करें, और कटऑफ के बाद के डेटा को स्वचालित रूप से अस्वीकार करें। दूसरी परत एक पार्टिशन ऑडिट है: सटीक हैश, लगभग-डुप्लिकेट फिंगरप्रिंट्स, और एंटिटी-आईडी इंटरसेक्शन्स की तुलना करें। एक डुप्लिकेट क्लस्टर एक स्प्लिटिंग यूनिट होना चाहिए। तीसरी परत एक प्रायोगिक नेगेटिव कंट्रोल है: सबसे संदिग्ध फीचर्स को हटा दें, वैध समूहों के भीतर लेबल्स को बदलें (permute), और रैंडम स्प्लिट को टेम्पोरल या ग्रुप स्प्लिट्स से बदलें। एक परम्यूटेड परिणाम को नो-सिग्नल बेसलाइन पर वापस आना चाहिए। डिप्लॉयमेंट-अनुरूप स्प्लिट के तहत एक बड़ी गिरावट एक लीकेज अलार्म है, अपने आप में कोई प्रमाण नहीं।

चौथी परत पॉइंट-इन-टाइम रीप्ले है। ऐतिहासिक ट्रांजेक्शन्स चुनें, उस समय फीचर सर्विस की घड़ी को फ्रीज करें, और सर्विंग लॉग्स में वास्तव में दिखाई देने वाले फ़ील्ड्स के साथ ऑफ़लाइन ट्रेनिंग पंक्ति की तुलना करें। एक ऑफ़लाइन मान जो बाद के बैकफिल को शामिल करता है वह टेम्पोरल लीकेज है। दोनों पाथ्स के बीच अलग-अलग गणना नियम, डिफॉल्ट्स, या वर्जन्स ट्रेनिंग-सर्विंग स्क्यू हैं। भले ही दोनों सही हों, बदलते यूजर समूह या फ्रॉड की रणनीतियाँ डिस्ट्रीब्यूशन ड्रिफ्ट का कारण बन सकती हैं, इसलिए टाइम कोहोर्ट (cohort) के अनुसार इनपुट्स, लेबल दरों, और सेगमेंट मेट्रिक्स की तुलना करें।

अंत में, इन कंट्रोल्स को उत्पाद के बुनियादी ढांचे (infrastructure) में बदलें: इम्यूटेबल डेटासेट स्नैपशॉट्स, पुनरुत्पादक स्प्लिट मैनिफेस्ट्स, फीचर परिभाषाओं में उपलब्धता टाइमस्टैम्प, वर्जन्ड ट्रेनिंग पाइपलाइन्स, और अंतिम होल्डआउट के लिए एक्सेस लॉग्स। प्रत्येक नए फीचर को एक प्रश्न का उत्तर देना होगा: “इस पंक्ति के लिए, क्या सर्विंग सिस्टम ठीक यही मान prediction_at पर निकाल सकता था?” यदि उत्तर स्पष्ट नहीं है, तो यह ट्रेनिंग में प्रवेश नहीं करता है।

उच्च गुणवत्ता वाला नमूना उत्तर

“लीकेज का अर्थ है कि जानकारी ने उस प्रेडिक्शन सीमा को पार कर लिया है जिसे हम लागू करने का दावा करते हैं। यह मॉडल ट्रांजेक्शन के होते ही उसे स्कोर करता है, इसलिए मैं प्रति पंक्ति prediction_at को परिभाषित करूँगा और इसके लेबल को परिपक्व मानने से पहले 30-दिवसीय चार्जैबक विंडो की प्रतीक्षा करूँगा। अंतिम चार्जैबक कारण और अंतिम मैन्युअल-रिव्यू स्थितियाँ स्पष्ट परिणाम लीकेज हैं। सात-दिन का अकाउंट काउंट वैध लगता है, लेकिन यदि आज का वेयरहाउस स्नैपशॉट ऐतिहासिक पंक्ति में देर से आए या प्रेडिक्शन के बाद के इवेंट्स जोड़ता है, तो यह भी लीक करता है।

मैं प्रत्येक फीचर के लिए इवेंट टाइम, उपलब्धता समय, एग्रीगेशन विंडो, और लेबल निर्भरता को बनाए रखूँगा, फिर as-of जॉइन्स के साथ मानों का पुनर्निर्माण करूँगा। नवीनतम परिपक्व समय अवधि को टेस्ट सेट के रूप में सील किया जाता है, और डेवलपमेंट में फॉरवर्ड क्रॉस-वैलिडेशन का उपयोग होता है। यदि लेबल विंडो फोल्ड सीमाओं को पार करती है, तो मैं सीमा को पर्ज (purge) कर देता हूँ। डुप्लिकेट ट्रांजेक्शन्स, मामले, और लगभग-डुप्लिकेट रिकॉर्ड्स स्प्लिटिंग से पहले क्लस्टर्स बन जाते हैं। क्या अकाउंट्स को पूरी तरह से अलग किया जाना चाहिए, यह इस बात पर निर्भर करता है कि प्रोडक्शन पुराने या अनदेखे अकाउंट्स का अनुमान लगाता है; मैं प्राथमिक मीट्रिक के रूप में डिप्लॉयमेंट-अनुरूप केस का उपयोग करता हूँ और जनरलाइजेशन स्ट्रेस टेस्ट के रूप में एंटिटी आइसोलेशन का उपयोग करता हूँ।

इम्प्यूटेशन, स्केलिंग, फीचर चयन, और एन्कोडिंग सभी पाइपलाइन में रहते हैं और केवल प्रत्येक ट्रेनिंग फोल्ड पर फिट होते हैं। टारगेट एन्कोडिंग को क्रॉस-फिट किया जाता है ताकि किसी पंक्ति का अपना लेबल उसे एन्कोड करने में मदद न कर सके। वैलिडेशन परिणाम फीचर्स, हाइपरपैरामीटर्स और थ्रेशोल्ड का चयन करते हैं। मैं तब प्रक्रिया को लॉक करता हूँ, सभी डेवलपमेंट डेटा पर फिर से रीफिट करता हूँ, और अंतिम टेस्ट का एक बार निरीक्षण करता हूँ।

निदान के लिए, मैं पार्टिशन्स में हैश, लगभग-डुप्लिकेट्स, और एंटिटी ओवरलैप का ऑडिट करता हूँ; संदिग्ध-फीचर एब्लेशन और वैध ग्रुप्स के भीतर लेबल परम्यूटेशन चलाता हूँ; और रैंडम की तुलना टेम्पोरल या ग्रुप स्प्लिट्स से करता हूँ। मैं सर्विंग लॉग्स के मुकाबले ऐतिहासिक फीचर्स को भी रीप्ले करता हूँ। टेम्पोरल स्प्लिट के तहत कम स्कोर केवल मूल सीमा को संदिग्ध बनाता है। पॉइंट-इन-टाइम डेटा का पार होना लीकेज है; समान पॉइंट-इन-टाइम डेटा लेकिन अलग ऑनलाइन गणना ट्रेनिंग-सर्विंग स्क्यू है; समान पाइपलाइन के बाद बाद के कोहोर्ट्स में प्रदर्शन में गिरावट वास्तविक ड्रिफ्ट की ओर संकेत करती है। सख्त प्रक्रिया ऑफ़लाइन स्कोर को कम कर सकती है, लेकिन यह लॉन्च के निर्णय के लिए उपयुक्त अनुमान प्रदान करती है।”

सामान्य गलतियाँ

• केवल टेस्ट-लेबल एक्सपोज़र को लीकेज कहना → यह भविष्य के फीचर्स, डुप्लिकेट नमूनों, और फुल-डेटा प्रीप्रोसेसिंग को अनदेखा कर देता है → कच्चे डेटा से लेकर मॉडल चयन तक पूरी जानकारी के पाथ का ऑडिट करें।
• प्रोडक्शन में प्रदर्शन गिरते ही लीकेज घोषित करना → ड्रिफ्ट, लेबल पूर्वाग्रह, और सर्विंग बग्स भी प्रदर्शन को खराब करते हैं → पॉइंट-इन-टाइम वंशावली, ऑफ़लाइन रीप्ले, और टाइम-कोहोर्ट डिस्ट्रीब्यूशन्स की अलग-अलग जाँच करें।
• स्प्लिटिंग से पहले सभी डेटा पर फीचर्स को स्केल या चयनित करना → मूल्यांकन डेटा सीखे गए ट्रांसफॉर्म पैरामीटर्स को प्रभावित करता है → पहले स्प्लिट करें और पाइपलाइन को प्रत्येक ट्रेनिंग फोल्ड के भीतर फिट करें।
• प्रत्येक डेटासेट को बेतरतीब ढंग से (randomly) स्प्लिट करना → भविष्य के नमूने या उसी एंटिटी की प्रतियां ट्रेनिंग में प्रवेश कर सकती हैं → डिप्लॉयमेंट के समय और एंटिटी संरचना के आधार पर स्प्लिटर चुनें।
• एग्रीगेट्स को केवल event_at द्वारा फ़िल्टर करना → देर से आए या बैकफिल किए गए रिकॉर्ड उस समय दिखाई नहीं दे सकते थे → इवेंट समय और उपलब्धता समय दोनों को सीमित करें।
• लगभग-डुप्लिकेट्स और केस ग्रुप्स की उपेक्षा करते हुए केवल पंक्तियों को डुप्लिकेट-मुक्त करना → मॉडल अभी भी लगभग समान नमूनों को याद रख सकता है → असाइनमेंट से पहले डुप्लिकेट क्लस्टर्स और व्यावसायिक ग्रुप्स बनाएं।
• सभी ट्रेनिंग पंक्तियों पर सीधे टारगेट एन्कोडिंग की गणना करना → प्रत्येक पंक्ति का लेबल उसके अपने फीचर में प्रवेश कर सकता है → आउट-ऑफ-फोल्ड एन्कोडिंग या आंतरिक क्रॉस-फिटिंग वाले इम्प्लीमेंटेशन का उपयोग करें।
• टेस्ट सेट को बार-बार देखना और मॉडल को बदलना → टेस्ट धीरे-धीरे एक वैलिडेशन सेट बन जाता है → एक एक्सेस-नियंत्रित अंतिम होल्डआउट रखें और निर्णय फ्रीज होने के बाद एक बार इसका निरीक्षण करें।
• लेबल परम्यूटेशन से एक निश्चित “रैंडम स्कोर” की उम्मीद करना → नो-सिग्नल बेसलाइन मीट्रिक और क्लास डिस्ट्रीब्यूशन के अनुसार बदलती है → समान सैंपलिंग और मीट्रिक नियमों के तहत बेसलाइन के खिलाफ तुलना करें।
• लीकेज को खत्म करने के लिए सभी एंटिटी इतिहास को हटाना → यह प्रोडक्शन में वास्तविक रूप से उपलब्ध उपयोगी जानकारी को हटा सकता है → प्रेडिक्शन-समय की जानकारी रखें और सही सीमा के साथ इसका मूल्यांकन करें।

फॉलो-अप प्रश्न और उनके उत्तर

फॉलो-अप 1: रैंडम स्प्लिट कब उपयुक्त होता है?

यह तब उचित होता है जब नमूने लगभग स्वतंत्र और समान रूप से वितरित (IID) हों, प्रोडक्शन ट्रैफ़िक और एकत्रित डेटा एक ही जेनेरेटिव प्रक्रिया साझा करते हों, और कोई सार्थक समय, यूजर, डिवाइस, प्रयोग-बैच या डुप्लिकेट-क्लस्टर संरचना न हो। डुप्लिकेट्स और प्रीप्रोसेसिंग सीमाओं को अभी भी ऑडिट करने की आवश्यकता होती है। यदि प्रोडक्शन कार्य भविष्य का अनुमान लगाना है, तो एक टेम्पोरल होल्डआउट आमतौर पर अधिक विश्वसनीय होता है।

फॉलो-अप 2: विलंबित लेबलिंग (delayed labeling) के लिए पर्ज (purge) या गैप की आवश्यकता क्यों होती है?

एक ट्रेनिंग ट्रांजेक्शन के लेबल का फैसला 30 दिनों बाद तक हो सकता है। यदि ट्रेनिंग वैलिडेशन शुरू होने से ठीक पहले समाप्त होती है, तो वह ट्रेनिंग लेबल वैलिडेशन अवधि के परिणामों पर निर्भर हो सकता है, जो जानकारी वास्तविक वैलिडेशन की शुरुआत में अनुपलब्ध थी। सीमा में लेबल-ऑब्जर्वेशन क्षितिज शामिल होना चाहिए, या प्रत्येक ट्रेनिंग कटऑफ में केवल वे लेबल्स शामिल होने चाहिए जो उस बिंदु पर पहले से ही परिपक्व हैं।

फॉलो-अप 3: क्या उसी अकाउंट का इतिहास एक फीचर हो सकता है?

हाँ, यदि सर्विंग के पास वास्तव में प्रेडिक्शन के समय वह इतिहास है और एग्रीगेट केवल उस समय दिखाई देने वाले पिछले इवेंट्स का उपयोग करता है। क्या एक अकाउंट ट्रेनिंग और टेस्ट को पार कर सकता है, यह लक्ष्य पर निर्भर करता है: पुराने अकाउंट्स को सर्व करते समय इसे समय के साथ बनाए रखें, और अनदेखे-अकाउंट जनरलाइजेशन का मूल्यांकन करते समय अकाउंट्स को अलग करें। दोनों परिदृश्यों की रिपोर्टिंग एक स्कोर को दो अलग-अलग प्रश्नों का उत्तर देने से रोकती है।

फॉलो-अप 4: क्रॉस-फिटिंग टारगेट-एन्कोडिंग लीकेज को कैसे रोकती है?

ट्रेनिंग डेटा को फोल्ड्स में विभाजित करें। अन्य फोल्ड्स के लेबल्स से प्रत्येक फोल्ड के कैटेगरी स्टैटिस्टिक्स की गणना करें, फिर उस होल्ड-आउट फोल्ड को एन्कोड करें। इसलिए किसी पंक्ति का अपना लेबल सीधे उसके फीचर के निर्माण में मदद नहीं कर सकता। वैलिडेशन और टेस्ट संबंधित ट्रेनिंग डेटा से सीखी गई मैपिंग का उपयोग करते हैं। क्रॉस-फिटिंग एन्कोडर के अंदर लीकेज को ठीक करती है; यह सही बाहरी टेम्पोरल या ग्रुप वैलिडेशन का विकल्प नहीं है।

फॉलो-अप 5: आप डेटा लीकेज को डिस्ट्रीब्यूशन ड्रिफ्ट से कैसे अलग करते हैं?

सबसे पहले, यह साबित करने के लिए पॉइंट-इन-टाइम रीप्ले का उपयोग करें कि प्रत्येक ऑफ़लाइन फीचर प्रेडिक्शन के समय उपलब्ध था। फिर सत्यापित करें कि ऑनलाइन और ऑफ़लाइन सिस्टम समान पंक्तियों के लिए समान मानों की गणना करते हैं। पहली जाँच की विफलता लीकेज है; दूसरी की विफलता ट्रेनिंग-सर्विंग स्क्यू है। दोनों के पास होने के बाद, बाद के कोहोर्ट्स में इनपुट्स, लेबल दरों और सेगमेंट मेट्रिक्स में परिवर्तन ड्रिफ्ट का प्रमाण प्रदान करते हैं। कई विफलताएं एक साथ भी मौजूद हो सकती हैं।

फॉलो-अप 6: प्रीट्रेन्ड या बड़े भाषा मॉडल्स (LLMs) के साथ कौन से अतिरिक्त लीकेज जोखिम आते हैं?

मूल्यांकन के नमूने या लगभग-डुप्लिकेट्स प्रीट्रेनिंग डेटा, रिट्रीवल इंडेक्स, या प्रॉम्ट उदाहरणों में पहले से मौजूद हो सकते हैं, एक ऐसा पाथ जो स्थानीय ट्रेन/टेस्ट मैनिफेस्ट में अनुपस्थित होता है। ट्रेनिंग कटऑफ के बाद बनाए गए होल्डआउट्स, निजी तौर पर उत्पन्न किए गए सेट्स, या लगभग-डुप्लिकेट्स के लिए ऑडिट किए गए सेट्स का उपयोग करें, और रिट्रीवल इंडेक्स व प्रॉम्ट्स को वर्जन्ड करें। जब प्रीट्रेनिंग डेटा के साथ पूर्ण गैर-ओवरलैप स्थापित नहीं किया जा सकता है, तो परिणाम को पूर्ण जनरलाइजेशन के बजाय संदूषण जोखिम (contamination risk) के अधीन एक अनुमान के रूप में वर्णित करें।