छियासी हज़ार एक सौ चौहत्तर, और फिर शून्य: एक खाली निष्कर्षण की फ़ॉरेंसिक रिपोर्ट

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

खाली लेजर मेरे पास पहले भी आए हैं, पर वे आम तौर पर आधे भरे होते हैं — शीर्षक आ जाता है, बॉडी नहीं; बॉडी आ जाती है, तारीख़ नहीं। सात में छह खाली और सातवाँ भी संदिग्ध, यह कोई मुँहबोला नतीजा नहीं है। यह एक ऐसी घटना है जिसकी जाँच हो सकती है — बशर्ते हम उसे “कुछ नहीं” कहकर आगे न बढ़ जाएँ।

स्टेज-1 का काम क्रिकेट की भाषा में समझें तो वह स्कोरिंग है, कमेंट्री नहीं। वह पेज लाता है, मुख्य बॉडी अलग करता है, शीर्षक और बायलाइन निकालता है, संस्थाओं को पहचानता है — कौन-सा खिलाड़ी, कौन-सी टीम, कौन-सा टूर्नामेंट — तारीख़ पढ़ता है, और फिर दो फ़ैसले लेता है: ख़बर कितनी समय-संवेदी है, और स्रोत कितना भरोसेमंद है। इनमें से हर फ़ील्ड का जन्मस्थान अलग है, और यही बात खालीपन को पढ़ने का तरीका देती है।

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

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

यहीं उस पुरानी आदत का इस्तेमाल होता है जो 2026 में बनी थी। 18 जून 2026, द ओवल, चैंपियंस ट्रॉफ़ी फ़ाइनल: पाकिस्तान 338/4, फखर ज़मान के 114; भारत 158 ऑल आउट, 30.3 ओवर में, मोहम्मद आमिर 6-2-16-3। उस रात मैंने भारत की पारी की सभी 183 गेंदें दोबारा लॉग कीं और पाया कि शीर्ष तीन ने 34 गेंदों में 26 रन बनाए थे। सुबह जो चार्ट छपा, वह नतीजे से पीछे की ओर नहीं लिखा गया था। तब से मेरा एक ही नियम है: जो नतीजा पहले से ज्ञात है, उससे शुरुआत मत करो। खाली इनपुट पर यही नियम उल्टी दिशा में लागू होता है।

अनुशासन का एक दूसरा हिस्सा भी यहाँ काम आ रहा है। जून-जुलाई 2026 में मेरे मॉडल ब्रॉडकास्ट क्लाइंट के पास गए थे; इंग्लैंड के 12 गोल में से 9 सेट-पीस से आए थे, और ओपन प्ले में प्रति शॉट 0.08 xG बन रहा था, जबकि टूर्नामेंट का माध्य 0.11 था। एक प्रोड्यूसर ने मुझे ऑन एयर “स्टैट्स गर्ल” कहकर पेश किया; मैंने जवाब में PPDA मैप खोला और छह मिनट बात की। उस दिन के बाद मैंने एक नियम और जोड़ा: जिस मॉडल के इनपुट मैं नहीं बता सकती, उसका आउटपुट मैं नहीं छापूँगी। आज वही नियम इस खाली निष्कर्षण पर लग रहा है।

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

दूसरी बात टैग की है। cricket_asia एक अवलोकन नहीं, एक दावा है। क्रिकेट कवरेज में यह ख़तरा पुराना है: किसी भी साइट के /cricket/ पथ के नीचे स्कोर, शोक-संदेश, प्रायोजक-विज्ञापन, फ़ोटो गैलरी और सिंडिकेटेड प्रेस रिलीज़, सब पड़े रहते हैं। पथ देखकर लगाया गया टैग इन सबको एक ही छाती में डाल देता है। इसलिए इस टैग को तथ्य मान लेना और उस पर डेढ़ हज़ार शब्द लिख देना — दोनों एक ही ग़लती की दो गहराइयाँ हैं। पहली में आप जानकारी खो देते हैं; दूसरी में आप पाठक को एक ऐसी चीज़ दे देते हैं जिसे वह जाँच नहीं सकता, और जिसे आप ख़ुद भी जाँच नहीं सके।

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

इस पूरी जाँच का केंद्रीय निष्कर्ष यह है: खाली फ़ील्ड बताती है कि पाइपलाइन कहाँ रुकी; भरी हुई दिखने वाली पर स्रोत-रहित फ़ील्ड बताती है कि पाइपलाइन कहाँ झूठ बोल रही है। पहली ख़राबी मरम्मत योग्य है। दूसरी संक्रामक है, क्योंकि वह अगले हर चरण में फैलती जाती है और हर चरण में अधिक भरोसेमंद दिखती जाती है।

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

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

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

आगे का संकेत यह है कि स्टेज-2 शुरू करने से पहले निष्कर्षण परत को मरम्मत चाहिए, और मरम्मत की शुरुआत एक छोटे बदलाव से होती है: खालीपन को शून्य नहीं, एक टाइप्ड त्रुटि की तरह लौटाओ। FETCH_EMPTY, DOM_MISS, ENCODING_MISMATCH, TAG_ONLY — चार अलग कोड, और साथ में वह URL जिससे टैग अनुमानित हुआ। इससे अगली बार यह बहस ख़त्म हो जाएगी कि ख़राबी कहाँ थी; कोड बता देगा। जब तक यह नहीं होता, हर “गहन विश्लेषण” जो इस खाली ढाँचे पर बनेगा, वह क्रिकेट के बारे में नहीं, हमारे सिस्टम के अंदाज़ों के बारे में होगा — और वह लेख पढ़ने में उतना ही भरोसेमंद लगेगा जितना कोई भी दूसरा।

सवाल यह नहीं है कि उस दिन लेजर खाली क्यों लौटा। सवाल यह है: अगर हमारा सिस्टम खालीपन को “कुछ नहीं” कहकर आगे बढ़ जाता है, तो अगली बार वह किस चीज़ को “कुछ” कहकर छाप देगा?