डेटा इंजीनियरिंग इंटरव्यू: आप ट्रेनिंग-सर्विंग स्क्यू के बिना एक ML फ़ीचर पाइपलाइन कैसे डिज़ाइन करते हैं?

प्रश्न और यह कब लागू होता है

रियल-टाइम फ्रॉड स्कोरिंग के लिए एक ML फ़ीचर पाइपलाइन डिज़ाइन करें। ट्रेनिंग सेट पिछले 12 महीनों में फैला है, और ऑनलाइन सिस्टम प्रति सेकंड लगभग 5,000 प्रेडिक्शन्स को संभालता है। प्रत्येक प्रेडिक्शन के लिए लगभग 50 फ़ीचर्स की आवश्यकता होती है, जिसमें फ़ीचर रिट्रीवल के लिए 5 ms p99 का बजट है। ये संख्याएं ट्रेड-ऑफ़ पर चर्चा करने के लिए क्षमता संबंधी धारणाएं हैं, न कि इंडस्ट्री डिफ़ॉल्ट्स।

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

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

इंटरव्यूअर क्या मूल्यांकन कर रहा है

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

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

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

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

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

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

• प्रेडिक्शन का समय और लेबल विंडो क्या है? मान लें कि स्कोरिंग तब होती है जब कोई ट्रांजैक्शन आता है और चार्जबैक लेबल अगले 30 दिनों में परिपक्व होते हैं। लेबल की जानकारी कभी भी वापस फ़ीचर्स में प्रवाहित नहीं होनी चाहिए।
• ऑनलाइन लेटेंसी बजट में क्या शामिल है? क्या 5 ms p99 में केवल फ़ीचर रिट्रीवल शामिल है, या नेटवर्किंग, सीरियलाइज़ेशन और इन्फ़रेंस भी? यह उत्तर इसे फ़ीचर-रिट्रीवल बजट के रूप में मानता है।
• प्रत्येक फ़ीचर कितना ताज़ा होना चाहिए? एक घंटे के ट्रांजैक्शन योग के लिए मिनट-स्तर की ताज़गी की आवश्यकता हो सकती है, जबकि अकाउंट आयु दैनिक अपडेट को सहन कर सकती है। प्रत्येक फ़ीचर पर एक ही TTL लागू नहीं किया जाना चाहिए।
• इवेंट्स कितने देर से, डुप्लिकेट या आउट-ऑफ़-ऑर्डर हो सकते हैं? यह वॉटरमार्क, डिडुप्लीकेशन, पुनः गणना और ऑनलाइन ओवरराइट नियमों को निर्धारित करता है।
• क्या ऐतिहासिक बैकफ़िल को “उस समय क्या ज्ञात था” या “नवीनतम सही सत्य” को पुनरुत्पादित करना चाहिए? पिछली सर्विंग को पुनरुत्पादित करने के लिए पूर्व की आवश्यकता होती है; पोस्ट-हॉक विश्लेषण के लिए बाद वाले की आवश्यकता हो सकती है। उन्हें एक डेटासेट में मिश्रित नहीं किया जा सकता।
• अनुपलब्ध या बासी ऑनलाइन डेटा पर बिज़नेस को कैसे डिग्रेड होना चाहिए? फ्रॉड सिस्टम प्रत्येक अनुपलब्ध मान को शून्य में बदलने के बजाय बेसलाइन मॉडल, मैन्युअल समीक्षा या रूढ़िवादी निर्णय का उपयोग कर सकते हैं।
• मॉडल और फ़ीचर्स स्वतंत्र रूप से कैसे डिप्लॉय किए जाते हैं? हमें यह जानना होगा कि क्या कई वर्जन्स को समानांतर में मटीरियलाइज़ किया जा सकता है, पुराने वर्जन्स कितने समय तक रहते हैं, और रोलबैक लक्ष्य क्या है।
• पहले से कौन सा इंफ्रास्ट्रक्चर मौजूद है? एक कम-ट्रैफ़िक, केवल-बैच मॉडल के लिए, शेयर्ड वर्जन्ड ट्रांसफ़ॉर्मेशन्स और इम्यूटिएबल स्नैपशॉट्स पर्याप्त हो सकते हैं। एक पूर्ण फ़ीचर प्लेटफ़ॉर्म शुरुआती धारणा नहीं होनी चाहिए।

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

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

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

चरण 1: प्रत्येक फ़ीचर परिभाषा को एक एक्ज़ीक्यूटेबल कॉन्ट्रैक्ट में बदलें।

प्रत्येक फ़ीचर के लिए कम से कम निम्नलिखित फ़ील्ड्स दर्ज करें:

एक बार फ़ीचर का नाम जारी होने के बाद, उसकी परिभाषा चुपचाप नहीं बदलनी चाहिए। यदि txn_amount_sum_1h “अधिकृत ट्रांजैक्शन्स” से बदलकर “सभी प्रयास किए गए ट्रांजैक्शन्स” हो जाता है, तो एक नया वर्जन या फ़ीचर नाम प्रकाशित करें। किसी पुराने मॉडल को अनजाने में नए अर्थ का उपभोग नहीं करना चाहिए।

चरण 2: ऑफ़लाइन और ऑनलाइन पाथ्स को समान तथ्यों से शुरू करें।

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

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

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

चरण 3: वास्तव में पॉइंट-इन-टाइम-करेक्ट ट्रेनिंग डेटा बनाएं।

प्रत्येक ट्रेनिंग उदाहरण में एक prediction_at होता है। उसी एंटिटी के लिए, एक बुनियादी as-of जॉइन event_at <= prediction_at के साथ नवीनतम फ़ीचर वर्जन का चयन करता है। जब इवेंट्स देर से आ सकते हैं या बैकफ़िल किए जा सकते हैं, तो इसे available_at <= prediction_at को भी संतुष्ट करना होगा:

eligible_feature = same_entity
  AND event_at <= prediction_at
  AND available_at <= prediction_at

selected_feature = latest eligible_feature by event_at, then available_at

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

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

चरण 4: मटीरियलाइज़ेशन और कंप्यूट-ऑन-रीड के बीच चयन करें।

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

ऑनलाइन स्टोर रिक्वेस्ट के समय इतिहास को स्कैन करने के बजाय एंटिटी की और feature_set_version द्वारा नवीनतम मान प्राप्त करता है। ऑफ़लाइन स्टोर ट्रेनिंग, बैकफ़िल्स और ऑडिट के लिए टाइम सीरीज़ को सुरक्षित रखता है। मानों के साथ, रिट्रीवल API को फ़ीचर टाइमस्टैम्प्स, गणना वर्जन्स और अनुपलब्धता स्थितियों को वापस करना या रिकॉर्ड करना चाहिए ताकि सर्विंग बासीपन और असंगति का पता लगा सके।

चरण 5: अनुपलब्ध, बासी और आउटेज व्यवहार को परिभाषित करें।

प्रत्येक फ़ीचर या फ़ीचर समूह का अपना ताज़गी बजट होता है। रीड के समय, prediction_at - feature_timestamp की गणना करें और उस बजट से अधिक होने पर मानों को बासी के रूप में चिह्नित करें। अनुपलब्ध, बासी और वैध संख्यात्मक मान शून्य तीन अलग-अलग स्थितियां हैं। ट्रेनिंग डेटा को अनुपलब्धता को उसी तरह प्रदर्शित करना चाहिए जैसे सर्विंग करती है।

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

चरण 6: रोलबैक को सुरक्षित रखते हुए वर्जन्स को रोल आउट करें।

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

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

चरण 7: ऑनलाइन सर्विंग के तथ्यों का उपयोग करके समानता सत्यापित करें।

ऑनलाइन रिक्वेस्ट्स का सैंपल लें और एंटिटी, prediction_at, feature_set_version, प्रत्येक फ़ीचर मान, फ़ीचर टाइमस्टैम्प, अनुपलब्ध/बासी स्थिति और अंतिम मॉडल वर्जन रिकॉर्ड करें। केवल मॉडल स्कोर रिकॉर्ड करने से यह पता लगाना असंभव हो जाता है कि कोई बेमेल मान, समय सीमा या वर्जन से आया था या नहीं।

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

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

रिलीज़ से पहले, ऑनलाइन-स्टोर अनुपलब्धता, आंशिक रूप से अनुपलब्ध कीज़, डेटा टाइमआउट और एक v2-से-v1 रोलबैक इंजेक्ट करें। रनटाइम पर, p50/p95/p99 रिट्रीवल लेटेंसी, मटीरियलाइज़ेशन लैग, अनुपलब्ध दर, डिफ़ॉल्ट दर, बासी दर, वर्जन बेमेल दर और रीप्ले बेमेल दर की निगरानी करें। मॉडल-परफ़ॉर्मेंस मॉनिटरिंग परिणामों को उजागर कर सकती है, लेकिन यह इस फ़ीचर-स्तरीय साक्ष्य की जगह नहीं ले सकती।

एक मजबूत उत्तर का उदाहरण

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

ट्रेनिंग उदाहरण पॉइंट-इन-टाइम जॉइन्स के लिए एंकर के रूप में prediction_at का उपयोग करते हैं। एक फ़ीचर को event_at <= prediction_at और available_at <= prediction_at दोनों को संतुष्ट करना होगा। यह उन रिकॉर्ड्स को बाहर करता है जो पहले घटित हुए थे लेकिन अभी तक नहीं आए थे। ऐतिहासिक सर्विंग को पुनरुत्पादित करने के लिए, मैं एक as-known डेटासेट का उपयोग करता हूं; सही किए गए डेटा को पोस्ट-हॉक विश्लेषण के लिए अलग से रखा जाता है। चार्जबैक लेबल्स उनकी 30-दिन की विंडो परिपक्व होने के बाद ही प्रवेश करते हैं, और लेबल स्रोत कभी भी फ़ीचर पाइपलाइन में प्रवेश नहीं करते हैं।

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

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

यदि केवल एक कम-ट्रैफ़िक वाला बैच मॉडल है, तो मैं एक वर्जन्ड ट्रांसफ़ॉर्मेशन और इम्यूटिएबल ट्रेनिंग स्नैपशॉट्स से शुरुआत करूंगा। मैं एक पूर्ण फ़ीचर प्लेटफ़ॉर्म केवल तभी पेश करूंगा जब कई मॉडल वास्तव में फ़ीचर्स साझा करते हैं और दोनों को ऐतिहासिक रिट्रीवल व कम-लेटेंसी वाली सर्विंग की आवश्यकता होती है।”

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

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

फॉलो-अप प्रश्न

फॉलो-अप 1: इवेंट टाइम और उपलब्धता समय को मर्ज क्यों नहीं किया जा सकता है?

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

फॉलो-अप 2: क्या बैच और स्ट्रीम प्रोसेसिंग को बिल्कुल समान कोड साझा करना चाहिए?

साझा कोड विचलन को कम करता है और इसे प्राथमिकता दी जानी चाहिए, लेकिन यह एकमात्र वैध डिज़ाइन नहीं है। एक्ज़ीक्यूशन इंजन, स्टेट मैनेजमेंट या परफ़ॉर्मेंस आवश्यकताओं के लिए दो कार्यान्वयनों की आवश्यकता हो सकती है। उस स्थिति में, कॉन्ट्रैक्ट और टेस्ट डेटा साझा करें, गोल्डन केसेस, सीमाओं और ऐतिहासिक-इवेंट रीप्ले के साथ समानता सत्यापित करें, और डाइवर्जेंस टेस्ट्स को रिलीज़ गेट्स बनाएं।

फॉलो-अप 3: देर से आने वाले इवेंट को ऑनलाइन विंडो फ़ीचर को कैसे सही करना चाहिए?

पहले अनुमत विलंब और विंडो-क्लोज़िंग नियमों को परिभाषित करें। उस अंतराल के भीतर एक इवेंट को डिडुप्लिकेट किया जा सकता है और प्रभावित विंडो को अपडेट किया जा सकता है, जबकि केवल एक नया फ़ीचर वर्जन ही ऑनलाइन मान को ओवरराइट कर सकता है। अंतराल के बाहर के इवेंट्स एक सुधार या बैकफ़िल जॉब में प्रवेश करते हैं। क्या पिछला ट्रेनिंग डेटा बदलता है यह डेटासेट मोड पर निर्भर करता है: as-known पिछली सर्विंग को पुनरुत्पादित करता है, जबकि corrected नवीनतम सत्य को दर्शाता है। उन्हें अलग से स्टोर करें।

फॉलो-अप 4: आप यह कैसे तय करते हैं कि किसी फ़ीचर को मटीरियलाइज़ करना है या मांग पर कैलकुलेट करना है?

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

फॉलो-अप 5: सर्विंग को बाधित किए बिना फ़ीचर परिभाषा कैसे बदल सकती है?

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

फॉलो-अप 6: क्या होगा यदि ऑफ़लाइन और ऑनलाइन फ़्लोटिंग-पॉइंट परिणाम समान नहीं हैं?

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

फॉलो-अप 7: ऑनलाइन फ़ीचर स्टोर अनुपलब्ध होने पर क्या सर्विंग विफल होनी चाहिए या डिग्रेड होनी चाहिए?

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

फॉलो-अप 8: आप कैसे साबित करते हैं कि नई पाइपलाइन ने ट्रेनिंग-सर्विंग स्क्यू को कम कर दिया है?

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