Compatibility of Missing Data Handling Methods across the Stages of Producing Clinical Prediction Models
यह शोध पत्र प्रदर्शित करता है कि नैदानिक भविष्यवाणी मॉडल जीवनचक्र के दौरान निष्पक्ष भविष्य कहनेवाला प्रदर्शन और अनुकूलता सुनिश्चित करने के लिए, शोधकर्ताओं को विकास और सत्यापन के दौरान अपनी लुप्त डेटा प्रबंधन रणनीतियों को मॉडल परिनियोजन की विशिष्ट बाधाओं के साथ संरेखित करना चाहिए, जैसे कि जब लुप्त डेटा को बाहर रखा जाता है तो मल्टीपल इम्प्यूटेशन (multiple imputation) का उपयोग करना या जब लुप्त डेटा की अनुमति होती है तो सुसंगत इम्प्यूटेशन विधियों को बनाए रखना।
मूल पेपर CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने न तो लिखा है, न इसका समर्थन किया है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें
कल्पना कीजिए कि आप एक शेफ हैं जो एक नए व्यंजन (एक क्लिनिकल प्रेडिक्शन मॉडल) के लिए एक आदर्श रेसिपी बनाने की कोशिश कर रहे हैं। आपका लक्ष्य यह अनुमान लगाना है कि ग्राहक उस व्यंजन के प्रति कैसी प्रतिक्रिया देगा। इसके लिए, आपको विशिष्ट सामग्रियों (जैसे आयु, रक्तचाप आदि जैसे प्रेडिक्टर्स) की आवश्यकता है। लेकिन कभी-कभी, जब आप खाना बना रहे होते हैं तो आपके पास सभी सामग्रियां नहीं होतीं, या हो सकता है कि आपके ग्राहकों ने अपनी आहार संबंधी प्राथमिकताओं के बारे में पूरी जानकारी न दी हो।
यह पेपर इस बारे में है कि आपके खाना पकाने की प्रक्रिया के तीन अलग-अलग चरणों में उन "लापता सामग्रियों" को कैसे संभाला जाए:
- डेवलपमेंट (विकास): अपनी टेस्ट किचन में रेसिपी बनाना।
- वैलिडेशन (सत्यापन): यह देखने के लिए कि क्या यह काम करता है, एक नए समूह के लोगों के साथ रेसिपी का स्वाद लेना।
- डिप्लॉयमेंट (तैनाती): वास्तविक जनता को व्यंजन परोसना।
लेखकों ने पाया है कि जिस तरह से आप अपनी टेस्ट किचन और अपने टेस्टिंग सेशन में लापता सामग्रियों को संभालते हैं, वह इस बात से मेल खाना चाहिए कि आप सार्वजनिक रूप से व्यंजन कैसे परोसने की योजना बना रहे हैं। यदि वे मेल नहीं खाते हैं, तो आपकी रेसिपी विफल हो जाएगी, या आपको लगेगा कि इसका स्वाद बहुत अच्छा है जबकि वास्तव में यह बहुत खराब होगा।
यहाँ उनके निष्कर्षों का सरल उपमाओं (analogies) का उपयोग करके विवरण दिया गया है:
खेल के दो मुख्य नियम
लेखक लापता डेटा को संभालने के लिए दो स्वर्णिम नियम प्रस्तावित करते हैं:
- "नो डिग्रेडेशन" (कोई गिरावट नहीं) का नियम: जब आप अपनी रेसिपी विकसित करते हैं, तो आपको अपनी सामग्री को इस तरह से संभालना चाहिए जिससे यह सुनिश्चित हो सके कि अंतिम व्यंजन उतना ही स्वादिष्ट हो जितना कि "परफेक्ट" संस्करण (जहाँ आपके पास सभी सामग्रियां थीं) का था।
- "ट्रुथ-टेलिंग" (सच्चाई बताने वाला) का नियम: जब आप अपने रेसिपी का वैलिडेशन (टेस्टिंग) करते हैं, तो आपको लापता सामग्रियों को इस तरह से संभालना चाहिए कि वह एक ईमानदार स्कोर दे। आप खुद को धोखा नहीं देना चाहते कि रेसिपी वास्तव में जितनी अच्छी या बुरी है, उससे बेहतर या बदतर है।
परिदृश्य A: "स्ट्रिक्ट" (कठोर) रेस्टोरेंट (कोई लापता डेटा नहीं)
एक शानदार रेस्टोरेंट की कल्पना करें जहाँ शेफ तब तक व्यंजन बनाने से मना कर देता है जब तक कि ग्राहक मेनू पर दी गई हर एक सामग्री प्रदान नहीं कर देता। यदि किसी ग्राहक के पास कोई सामग्री कम है, तो शेफ कहता है, "क्षमा करें, मैं आपके लिए खाना नहीं बना सकता।"
- पेपर की सलाह: यदि आपकी योजना इस सख्त शेफ होने की है, तो आपको अपनी रेसिपी विकसित और टेस्ट करने के लिए मल्टीपल इम्प्यूटेशन (MI) का उपयोग करना चाहिए।
- उपमा: मल्टीपल इम्प्यूटेशन को एक "जादुई गेसर" (magic guesser) के रूप में सोचें जो उन सामग्रियों को भर देता है जो गायब हैं, लेकिन यह ऐसा करता है जो अनिश्चितता को ध्यान में रखता है। महत्वपूर्ण बात यह है कि इस "जादुई गेसर" को यह जानने की आवश्यकता है कि अंतिम परिणाम क्या था (क्या ग्राहक को व्यंजन पसंद आया?) ताकि विकास चरण के दौरान अच्छे अनुमान लगाए जा सकें।
- जाल: यदि आप "मीन इम्प्यूटेशन" (सिर्फ औसत सामग्री का अनुमान लगाना) या "कम्प्लीट केस एनालिसिस" (किसी भी ग्राहक को हटा देना जिसकी कोई सामग्री गायब है) का उपयोग करके अपनी रेसिपी विकसित करते हैं, तो आपकी रेसिपी कमजोर होगी। जब आप अंततः सख्त जनता को इसे परोसने की कोशिश करेंगे, तो इसका स्वाद खराब होगा (मॉडल डिग्रेडेशन)।
परिदृश्य B: "फ्लेक्सिबल" (लचीला) फूड ट्रक (लापता डेटा की अनुमति है)
अब, एक फूड ट्रक की कल्पना करें जहाँ शेफ लापता सामग्रियों के साथ भी सहज है। यदि कोई ग्राहक भूल जाता है कि उसे नट्स (मेवे) से एलर्जी है, तो शेफ बस एक मानक "डिफ़ॉल्ट" नट लेवल या खाली जगह भरने के लिए एक विशिष्ट "अनुमान लगाने" की विधि का उपयोग करता है ताकि खाना बनाना जारी रह सके।
- पेपर की सलाह: यदि आपकी योजना इस लचीले फूड ट्रक की है, तो आपको विकास, परीक्षण और परोसने के दौरान लापता सामग्रियों को भरने के लिए ठीक उसी विधि का उपयोग करना चाहिए।
- उपमा: यदि आपने तय किया है कि आप "रिग्रेशन इम्प्यूटेशन" (अन्य सामग्रियों के आधार पर एक विशिष्ट प्रकार का स्मार्ट अनुमान) का उपयोग करेंगे, तो आपको रेसिपी बनाते समय और टेस्ट करते समय भी उसी "स्मार्ट गेस" विधि का उपयोग करना होगा।
- जाल: यदि आप "मीन इम्प्यूटेशन" (औसत) का उपयोग करके रेसिपी बनाते हैं, लेकिन फिर अपने ग्राहकों से कहते हैं, "चिंता न करें, हम आपकी गायब जानकारी को भरने के लिए एक 'स्मार्ट गेस' विधि का उपयोग करेंगे," तो आपकी रेसिपी टूट जाएगी। गणित मेल नहीं खाएगा। पेपर ने पाया कि तरीकों को मिलाना (जैसे एक विधि से विकसित करना और दूसरी से वैलिडेट करना) लगभग हमेशा एक पक्षपाती (biased) स्कोर की ओर ले जाता है—आपको लगता है कि आपका फूड ट्रक सफल है, लेकिन वास्तव में वह विफल हो रहा है।
"पैटर्न सब-मॉडल" (एक विशेष मामला)
पेपर ने पैटर्न सब-मॉडल्स नामक एक विधि पर भी गौर किया।
- उपमा: एक बड़ी रेसिपी के बजाय, आप चार अलग-अलग मिनी-रेसिपी लिखते हैं:
- उन ग्राहकों के लिए जिन्होंने पूरी जानकारी दी है।
- उन ग्राहकों के लिए जिनके पास सामग्री A गायब है।
- उन ग्राहकों के लिए जिनके पास सामग्री B गायब है।
- उन ग्राहकों के लिए जिनके पास दोनों गायब हैं।
- पेपर की सलाह: यदि आप फूड ट्रक पर इस "मिनी-रेसिपी" दृष्टिकोण का उपयोग करने की योजना बना रहे हैं, तो आपको ठीक इसी "मिनी-रेसिकी" दृष्टिकोण का उपयोग करके विकसित और टेस्ट करना होगा। आप मिनी-रेसिपी के साथ विकसित नहीं कर सकते और फिर सब कुछ औसत निकालकर टेस्ट नहीं कर सकते।
मुख्य निष्कर्ष (The Big Takeaway)
लेखकों ने अपने बिंदु को सिद्ध करने के लिए हजारों कंप्यूटर सिमुलेशन चलाए और वास्तविक दुनिया के सर्जरी डेटा की जांच की। उन्होंने पाया कि सामान्य प्रथाएं अक्सर गलत होती हैं।
- सामान्य गलती: कई शोधकर्ता एक विधि (जैसे मल्टीपल इम्प्यूटेशन) का उपयोग करके मॉडल विकसित करते हैं ताकि सर्वोत्तम सांख्यिकी प्राप्त हो सके, लेकिन फिर वे इसे एक सरल विधि (जैसे मीन इम्प्यूटेशन) का उपयोग करके तैनात करते हैं क्योंकि इसे ऐप में कोड करना आसान होता है।
- परिणाम: यह एक "झूठ बोलने वाले विरोधाभास" (liar's paradox) को जन्म देता है। मॉडल लैब में बहुत अच्छा दिखता है, लेकिन जब यह वास्तविक दुनिया में आता है, तो इसका प्रदर्शन खराब हो जाता है, या प्रदर्शन स्कोर पूरी तरह से गलत होते हैं।
एक वाक्य में सारांश
एक विश्वसनीय चिकित्सा भविष्यवाणी उपकरण बनाने के लिए, आपको पहले यह तय करना होगा कि वास्तविक दुनिया में उपकरण का उपयोग करते समय आप लापता डेटा को कैसे संभालेंगे, और फिर आपको उस ठीक उसी विधि का उपयोग करके उपकरण को बनाना और टेस्ट करना होगा; तरीकों को मिलाना और बदलना टूटे हुए मॉडल और झूठे आत्मविश्वास की ओर ले जाता है।
अपने क्षेत्र के पेपरों की भीड़ में उलझे हुए हैं?
आपके रिसर्च कीवर्ड से मेल खाने वाले सबसे नए और अलग सोच वाले पेपरों का रोज़ाना Digest पाएँ—तकनीकी सारांश के साथ, आपकी भाषा में।