काल्पनिक बनाम अनामीकृत डेटा: फ़र्क़ का असली मतलब क्या है

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

यह लेख उन चार तरीक़ों को सामने रखता है जो लोग वाकई इस्तेमाल करते हैं, हर एक क्या गारंटी देता है और क्या नहीं, और यह कि फ़ील्डों को जोड़ देना वही ब्यौरा क्यों है जो हटाव की ज़्यादातर कोशिशों को चुपचाप हरा देता है।

चार तरीक़े, आमने-सामने

ज़्यादातर टेस्ट डेटासेट इन चार में से किसी एक तरीक़े से बनते हैं, और इन्हें अक्सर एक ही शब्द से पुकार लिया जाता है।

इनमें से केवल पहला शून्य से शुरू होता है। बाक़ी तीनों असली रिकॉर्ड से शुरू होते हैं, और इसीलिए हर एक वह ज़िम्मेदारी विरासत में लेता है जो पहले पर कभी नहीं थी।

नाम हटा देने से डेटासेट अनामीकृत क्यों नहीं हो जाता?

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

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

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

किसे असल में अनाम माना जाता है?

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

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

जहां कठिनाई ज़्यादा हो, वहां ईमानदार जवाब आम तौर पर यह होता है कि डेटा को अनाम कहना बंद कर दिया जाए। स्यूडोनिमाइज़ किया हुआ, सीमित, या केवल आंतरिक — ये सब टिकाऊ वर्णन हैं; अनाम वह दावा है जिसे कमाना पड़ता है।

टेस्ट एनवायरनमेंट को कौन सा तरीक़ा अपनाना चाहिए?

ज़्यादातर मामलों में काल्पनिक डेटा, क्योंकि वह ज़िम्मेदारी को संभालता नहीं, हटा देता है। नियमों और एक तय इनपुट से बने डेटासेट में कोई व्यक्ति होता ही नहीं, इसलिए न रखे जाने की कोई समय सीमा, न सहमति का सवाल, न हटाने का कोई अनुरोध पूरा करना, और लीक होने पर रिपोर्ट करने के लिए कुछ नहीं। इसे बेधड़क टेस्ट रिपॉज़िटरी में रखा जा सकता है, टीमों के बीच भेजा जा सकता है और टिकट में चिपकाया जा सकता है, बिना यह सोचे कि इसमें किसकी जानकारी है।

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

जो काम काल्पनिक रिकॉर्ड अपने आप नहीं करते, वह यह है कि वे असली डेटा का हर गुण दोबारा नहीं बना देते। अगर किसी टेस्ट को वितरण पर निर्भर होना है — किसी दुर्लभ सीमा मामले की आवृत्ति, दो फ़ील्डों के बीच का सहसंबंध, लंबी पूंछ का आकार — तो वह जानबूझकर मॉडल करना पड़ेगा, विरासत में नहीं मिलेगा। पहचान फ़ील्ड सुसंगतता इसका सीधा उदाहरण है: संबंधित फ़ील्डों को मेल में रखने के लिए जनरेटर को उसी तरह बनाया जाना पड़ता है, क्योंकि केवल रैंडम चयन से यह नहीं होगा।

बनाए गए डेटासेट को दोबारा बनने लायक कैसे रखें?

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

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

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

कैसे सिद्ध करें कि टेस्ट डेटासेट में कोई असली रिकॉर्ड नहीं है?

यह बता पाने से कि हर मान कहां से आया। यह स्रोत का सवाल है, और इसका जवाब बनाने के समय दिया जाता है, ऑडिट के समय नहीं। जो डेटासेट किसी ज्ञात सीड के साथ जनरेटर चलाकर बना हो, और वह जनरेटर प्रोडक्शन का कोई स्रोत पढ़ता ही न हो, उसका जवाब एक पंक्ति का होता है। जो डेटासेट प्रोडक्शन के किसी निर्यात को बदलकर बना हो, उसका जवाब इस बात पर टिका होता है कि वह बदलाव सही था, और यह साबित करने का बोझ कभी पूरा नहीं उतरता।

दो आदतें स्रोत को टिकाऊ बनाती हैं। डेटा को खुद चिह्नित कीजिए — कोई खान या शीर्षक जो पंक्तियों को काल्पनिक बताए — ताकि टिकट, स्प्रेडशीट या स्क्रीनशॉट तक पहुंची कोई प्रतिलिपि भी अपना परिचय देती रहे। और बनाने वाला चरण वर्ज़न नियंत्रण में रखिए, ताकि वही डेटासेट दोबारा बनाना मौखिक इतिहास न हो, एक कमांड हो।

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

डेवलपर्स के लिए: सीड, वितरण और ईमानदार दावे

जनरेटर इस तरह बनाइए कि हर रैंडम फ़ैसला सीड से एक ही दर्ज रास्ते से गुज़रे। जो दो जनरेटर सीड तो स्वीकार करते हैं पर रैंडम मान अलग क्रम में उठाते हैं, वे अलग पड़ेंगे, और वह फ़र्क़ टेस्ट की खामी जैसा दिखेगा, जनरेटर की नहीं।

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

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

अगले कदम

अपने टेस्ट एनवायरनमेंट में वह डेटासेट खोजिए जिसका स्रोत कोई नहीं बता पाता, और उसका पीछा कीजिए; वह जवाब आम तौर पर खुद डेटासेट से ज़्यादा दिलचस्प होता है। फिर उसकी जगह एक बनाया हुआ बैच रखिए और डेटा के साथ सीड दर्ज कीजिए, ताकि कोई भी उसे दोबारा बना सके। अगर आप विकल्पों को तौल रहे हैं, तो टेस्ट डेटा के लिए गोपनीयता नियम वाला लेख बताता है कि हर चुनाव आपके ऊपर बाद में क्या ज़िम्मेदारी डालता है, और सही डेटासेट चुनने के बाद पहचान जनरेटर से बनाया गया बैच संख्या का हिस्सा अकेले ही संभाल लेता है।