खाली शीट, भरा हुआ फ़ॉर्म: क्रिकेट डेटा पाइपलाइन की वह गलती जो सबसे महंगी पड़ती है

बारह फ़रवरी 2026 की रात मेरे लैपटॉप पर एक टेबल खुली थी। चौदह फ़ील्ड, चौदह पंक्तियाँ, और लगभग हर सेल में एक ही जवाब — N/A। आर्टिकल टाइटल N/A, सोर्स N/A, आर्टिकल टाइप “Unclassified”, चारों कोर व्यूअरपॉइंट (रुख़, मक़सद, सारांश, आर्ग्युमेंट स्ट्रक्चर) खाली, इन्फॉर्मेशन पॉइंट्स की लिस्ट खाली, एंटिटीज़ वहीं अटक गईं क्योंकि उन्हें “ऊपर के इन्फॉर्मेशन पॉइंट्स से” निकाला जाना था, और टाइम-सेंसिटिविटी कभी आँकी ही नहीं गई।

मैंने पहले इसे हाथ से चार्ट किया, क्योंकि स्कोरकार्ड चीज़ों का क्रम छिपा देता है। 2026-18 रणजी ट्रॉफ़ी में वांखेड़े की ग्यारह घरेलू पारियों में मैंने 1,284 गेंदें एक-एक करके लिखीं — चौदह कॉलम, 63 फ़ॉल्स शॉट, 21 एज। उस शीट में हर सेल भरा हुआ था, इसलिए उस पर बहस हो सकती थी, उसे री-रन किया जा सकता था। जो शीट बारह फ़रवरी को मेरे सामने थी, वह भी चौदह फ़ील्ड की थी। फ़र्क़ सिर्फ़ इतना था कि उसमें बहस के लिए कुछ भी नहीं था — और वह एक लाल झंडे की तरह नहीं, एक पूरी रिपोर्ट की तरह दिख रही थी।

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

इसलिए जब कोई आउटपुट पूरा दिखे और अंदर से खाली हो, तो सवाल “डेटा कहाँ गया” नहीं होता। सवाल यह होता है कि इतने दिनों तक इस शीट पर किसने भरोसा किया, और उस भरोसे पर कितनी कहानियाँ छपीं।

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

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

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

2026 के इंग्लैंड दौरे पर मैंने 1,043 ओवर और 6,214 गेंदें ब्रॉडकास्ट फुटेज से कोड कीं। कोहली के 593 रन (59.30) और बाकी टॉप-सिक्स के 23.8 के औसत के बीच का फ़ासला उस शीट से निकला जिसमें हर गेंद की अपनी पंक्ति थी। अगर उस शीट में टैगिंग वाला कॉलम खाली रह जाता और सिस्टम उसे “कोई फ़ॉल्स शॉट नहीं” पढ़ लेता, तो पूरी सीरीज़ का नतीजा उलट जाता। इसीलिए Stage-1 में एक हार्ड गेट ज़रूरी है: इन्फॉर्मेशन पॉइंट्स खाली हों या तय थ्रेशोल्ड से कम हों, तो आउटपुट EXTRACTION_FAILED के साथ रुकना चाहिए, आगे नहीं बढ़ना चाहिए। जो शीट सब फ़ील्ड भरे होने का दिखावा करती है और अंदर से खाली है, वह सबसे महंगी श्रेणी है — क्योंकि Stage-2 उस पर चलता है, कुछ लिखता है, और वह लिखा हुआ भरोसेमंद दिखता है।

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

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

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