खाली डेटा से नहीं बनता मैच फ्लैश: एक स्कोरर की नज़र में स्टेज-1 फेलियर का ऑडिट

13 मार्च 2026 की रात ईडन गार्डन्स के स्कोरर बॉक्स में मैंने हर गेंद को हाथ से कोड किया था। इंडिया 251 का पीछा कर रहा था, 34.1 ओवर में 120 पर 8 विकेट गिर चुके थे, बोतलें मैदान पर आ चुकी थीं, और क्लाइव लॉयड ने मैच श्रीलंका को दे दिया था। मेरी शीट में एक भी गेंद गलत दर्ज नहीं थी। फिर भी उस शीट ने कुछ भी समझाया नहीं। उस रात के बाद मैंने तय किया कि जिस स्कोरलाइन के साथ प्रेशर-स्टेट नहीं जुड़ा, वह रिपोर्ट मैं नहीं भेजूंगा। यही नियम अब मेरे सामने रखे इस केस पर लागू होता है: स्टेज-1 का आउटपुट पूरी तरह खाली है, और मुझे उस खालीपन की रिपोर्ट लिखनी है, न कि उस पर काल्पनिक विश्लेषण थोपना है।

संदर्भ: जब पाइपलाइन की पहली सीढ़ी ही गिर जाए

जिस दस्तावेज़ की समीक्षा मांगी गई, उसमें केवल एक फ़ील्ड ज़िंदा है — Domain Label: cricket_world। बाकी सब कुछ खाली है। लेख का शीर्षक नहीं, स्रोत नहीं, URL नहीं, प्रकाशन तिथि नहीं, विधा (न्यूज़/कमेंट्री/विश्लेषण/मैच रिपोर्ट) नहीं, तीन से आठ तक कोई कोर व्यूअरपॉइंट नहीं, सूचना-बिंदुओं की सूची खाली, और इकाइयों (खिलाड़ी, टीम, संस्था) की पहचान भी अपस्ट्रीम सूचना-बिंदुओं पर निर्भर है, यानी नीचे की हर सीढ़ी अनिवार्यतः खाली ही रहेगी। समय-संवेदनशीलता का मूल्यांकन भी नहीं हुआ है।

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

कोर: खाली आउटपुट के तीन संभावित कारण, और हर एक का अलग इलाज

ऑटोमेटेड पाइपलाइन में स्टेज-1 का खाली आउटपुट तीन में से किसी एक स्थिति का संकेत होता है, और तीनों का इलाज अलग है।

पहला — क्रॉल परत विफल रही। एंटी-स्क्रेपिंग दीवार, पे-वॉल, या जावास्क्रिप्ट-रेंडर्ड कंटेंट। यहां एक्सट्रैक्टर दोषी नहीं है; उसके हाथ में HTML ही नहीं पहुंचा। जांच का तरीका सीधा है: रॉ रिस्पॉन्स का स्टेटस कोड और बॉडी-लंबाई देखें। अगर बॉडी में लेख का टेक्स्ट मौजूद ही नहीं, तो स्टेज-1 दोबारा चलाने से कुछ नहीं बदलेगा।

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

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

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

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

प्रति-कोण: "डेटा नहीं है तो राय दे दो" — यह सबसे महंगी आदत है

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

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

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

टेकअवे: अगली बार स्टेज-1 चलाने से पहले तीन चीज़ें तय करें

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