नल पेलोड का संकट: जब क्रिकेट डेटा की खाली शेल को कहानी पढ़ लिया जाता है

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

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

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

2026 में जब मैं राइज़िंग पुणे सुपरजायंट के साथ था, तब हैदराबाद वाले फाइनल के हर डेथ ओवर को मैंने दोबारा टैग किया था। तीन हफ्ते लगे। मॉडल ने बताया कि आखिरी पाँच ओवरों में RPS ने मुंबई की डेथ जोड़ी के खिलाफ 41/2 बनाए थे, जबकि लीग डेटा का प्रोजेक्शन 49 था। आठ रन का फर्क। मैंने उसे मॉडल की गलती नहीं, एग्ज़ीक्यूशन का गैप लिखा — लेकिन उसी हफ्ते एक नियम बना: हर पोस्ट-मैच पीस के ऊपर एक छोटा मेथड्स नोट जाएगा। सैंपल साइज़, फेज़ स्प्लिट, मॉडल एरर। उस नोट का मकसद सिर्फ पारदर्शिता नहीं था। वह एक गेट था। अगर नोट में सैंपल साइज़ नहीं भरा जा सकता, तो पीस लिखा ही नहीं जाएगा।

2026 में UAE में हुए IPL के दौरान मैंने दिल्ली कैपिटल्स के लिए पुणे से रिमोट काम किया। 2026 से 2026 तक के होम स्प्लिट्स पर बैक-टेस्टिंग में पता चला कि होम टीम का रन-रेट फायदा 60 मैचों में +0.28 से गिरकर +0.04 रह गया था। मैंने प्लेऑफ से पहले न्यूट्रल-वेन्यू एडजस्टमेंट बनाया। DC फाइनल तक पहुँची और मुंबई इंडियंस से हारी। मैंने 14 पन्नों का "पैनडेमिक सैंपल" मेमो रखा और उस सीज़न को कभी नॉर्मल बेसलाइन नहीं माना।

इन तीनों किस्सों में एक चीज़ कॉमन है: मैंने हर बार पहले यह तय किया कि मेरे पास क्या है, और उसके बाद यह कि उससे क्या कहा जा सकता है। जिस दिन यह क्रम उलट जाता है — पहले निष्कर्ष, बाद में सबूत — उस दिन एनालिसिस खत्म हो जाता है।

अब उस खाली फाइल पर लौटते हैं, क्योंकि वह अपने आप में एक केस स्टडी है।

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

दूसरी विफलता एंटिटी की है। फाइल में एक जगह साफ लिखा था कि एंटिटी "ऊपर दिए गए सूचना बिंदुओं से" निकाली जाए। लेकिन सूचना बिंदुओं की सूची खाली थी। यह टेक्निकल नहीं, डिज़ाइन की विफलता है। पाइपलाइन ने एरर नहीं उठाया — उसने चुपचाप एक निर्देश लौटा दिया। किसी भी ऑडिट में यह सबसे बुरी तरह की विफलता होती है: वह जो शोर नहीं करती। टूटा हुआ फीड शोर करता है, आप उसे तुरंत पकड़ लेते हैं। खाली फील्ड चुप रहती है, और चुप्पी को डेटा समझ लिया जाता है।

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

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

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

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

उसी तरह, एक खाली डेटा सेल कोई कमी नहीं है, वह उस कहानी का नाम है जो एक पाइपलाइन खुद को सुना रही है — "सब ठीक है।"

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

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

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

पहली अनुपस्थिति डिज़ाइन से होती है। बारिश आई, DLS लगा, ओवर कट गए — तो कुछ मेट्रिक्स का न होना बिल्कुल सही है। दूसरी अनुपस्थिति विफलता से होती है। फीड टूटा, पार्सिंग अधूरी रही, फील्ड खाली छूट गई। पहली को आप लेजर में "N/A — बारिश" लिखकर छोड़ देते हैं और आगे बढ़ जाते हैं। दूसरी पर आप लेजर रोक देते हैं। दोनों को एक जैसा दिखाना — यही असली खतरा है।

मेरे अनुभव में एक और चीज़ बार-बार दोहराई गई है। 2026 के T20 विश्व कप में बारबाडोस के फाइनल से पहले मैंने डेथ-ओवर प्रेशर इंडेक्स बनाया था, जो रिक्वायर्ड रेट, विकेट प्रोबेबिलिटी और बाउंड्री डिफिकल्टी को जोड़ता है। इनिंग्स ब्रेक पर उसने भारत को सिर्फ 58% जीत की संभावना दी। जब दक्षिण अफ्रीका को छह विकेट हाथ में रखते हुए 30 गेंदों पर 30 रन चाहिए थे, तब भी इंडेक्स SA के पक्ष में था। भारत सात रन से जीता, जसप्रीत बुमराह ने 2/18 लिए। मैंने जीत की कहानी नहीं लिखी — कैलिब्रेशन नोट लिखा। मॉडल गलत था, और वह गलती दर्ज होनी चाहिए थी, क्योंकि अगली बार वही मॉडल किसी और मैच पर इस्तेमाल होगा।

यही मेरा असली मतभेद है उस स्कूल से जो कहता है कि ज़्यादा डेटा बेहतर विश्लेषण देता है। ज़्यादा डेटा बेहतर विश्लेषण नहीं देता। बेहतर गेट देता है। और गेट वह होता है जो बताए कि कब रुकना है।

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

खाली रो भी बोलती है। बस उसकी आवाज़ को शोर समझने की गलती नहीं करनी चाहिए।