N/A का जाल: जब क्रिकेट एनालिसिस पाइपलाइन खाली डेटा को भी नतीजा बना देती है

स्क्रीन पर वह पंक्ति पूरी थी। नौ ख़ाने थे — Article Title, Source, Type, One-sentence Summary, Author Stance, Purpose, Information Points, Entities Involved, Time Sensitivity, Source Quality। इनमें से आठ में साफ़-साफ़ लिखा था N/A, एक में Unclassified, और Information Points के आगे खाली ब्रैकेट — एक ऐसा जोड़ा जिसमें कुछ भी नहीं रखा गया था। सिस्टम ने इसे त्रुटि नहीं कहा। उसने इसे आउटपुट कहा, और आउटपुट अगली मंज़िल पर चला गया, जहाँ उससे गहराई वाली समझ बनाने को कहा गया था। जिस इकलौते ख़ाने में असली टेक्स्ट था, वह था Domain Label: cricket_asia।

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

कोई स्कोरकार्ड गेंदबाज़ों के नाम के बिना स्कोरकार्ड नहीं होता

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

Information Points वही गेंद-दर-गेंद रिकॉर्ड हैं। हर प्रविष्टि में तीन चीज़ें चाहिए — दावा (claim), स्रोत (source), और समय (timestamp)। दावा बताता है क्या कहा गया। स्रोत बताता है किसने कहा — कोई मीडिया संस्थान, कोई बोर्ड का बयान, कोई आँकड़ा-आधार। समय बताता है कब कहा गया, क्योंकि खेल में एक ही वाक्य दो तारीख़ों पर दो अलग चीज़ें होता है। "टीम का गेंदबाज़ी आक्रमण कमज़ोर है" — यह वाक्य टॉस से पहले एक भविष्यवाणी है, दसवें ओवर में एक अवलोकन है, और मैच के बाद एक बहाना है। टाइमस्टैम्प के बिना तीनों एक जैसे दिखते हैं।

Entities वही प्लेइंग इलेवन है — कौन-कौन शामिल है: खिलाड़ी, टीम, टूर्नामेंट, संस्था, जगह। Time Sensitivity वह ओवर नंबर है जिस पर यह सारा हिसाब टिका है — घटना कब हुई और पाठ कब छपा, इन दोनों के बीच का फ़ासला। Article Type वह प्रारूप है, क्योंकि एक ही आँकड़ा अलग-अलग प्रारूपों में अलग बोलता है: समाचार में तथ्य की ज़रूरत होती है, प्रीव्यू में संभावना की, विश्लेषण में कारण की, और राय में वक्ता की। और Domain Label — cricket_asia — वह स्थल है, वह मैदान जहाँ खेल हुआ।

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

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

तीन जगहें जहाँ ज़ंजीर टूटी

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

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

तीसरी जगह सबसे शर्मनाक है। Source Quality को उसी क्षण आँका जाना था जब स्रोत का ख़ाना ही मौजूद नहीं था। सही व्यवहार साफ़ है: जहाँ स्रोत नहीं, वहाँ गुणवत्ता "अनिर्धारित" है — न अच्छी, न बुरी, बस खाली। जो सिस्टम कुछ न होने पर भी "आँका गया" लौटाता है, वह उस सिस्टम से ज़्यादा ख़तरनाक है जो कुछ भी नहीं लौटाता। मुझे यह बात किसी सिद्धांत से नहीं, एक बहुत ठोस अनुभव से पता है। जब मार्च 2026 में खेल रुका, मेरे पास 1,300 मैचों का बैक-टेस्ट था और घरेलू मैदान की बढ़त के लिए +4.2 प्रतिशत अंक का एक कोएफिशिएंट। आईपीएल यूएई में शिफ़्ट हुआ, मुंबई इंडियंस ने जीता, और वह कोएफिशिएंट शून्य पर आ गया। उसने कभी N/A नहीं कहा। उसने हर बार एक नंबर दिया, और वह नंबर ही ग़लती था।

खाली ख़ाना शून्य नहीं होता

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

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

इसलिए मुझे लगता है कि इस पूरी समस्या का समाधान ज़्यादा ख़ाने जोड़ने में नहीं है। समाधान एक पंक्ति में है — वह जाँच जो खाली सूची देखकर सीधे रोक देती है और कारण लौटा देती है, न कि N/A से सजा हुआ पूरा स्कीमा। एक पंक्ति। बाक़ी सब उसके बाद आता है। जिस पाइपलाइन में यह जाँच नहीं है, वह तेज़ है और वह भरोसेमंद नहीं है — और खेल-पत्रकारिता में तेज़ और ग़लत का जोड़ा हमेशा से घातक रहा है, क्योंकि ग़लत वहाँ भी पहुँच जाता है जहाँ सही की गुंजाइश नहीं थी।

एक भरी हुई पंक्ति, सही तरीक़े से

यह समझने के लिए कि अच्छा Stage-1 कैसा दिखता है, अपने ही लेजर की एक प्रविष्टि उठा लीजिए जो पूरी है। इक्कीस मई 2026, हैदराबाद, आईपीएल फ़ाइनल। दावा: पारी के ब्रेक पर डेथ-ओवर विकेट-प्रायिकता मॉडल ने मुंबई इंडियंस को 58% दिया, जो 129 का बचाव कर रही थी; डेस्क का अनुमान 44% था। स्रोत: आंतरिक मॉडल आउटपुट, डेस्क पर उपलब्ध। समय: 21 मई 2026, पारी-अंतराल। एंटिटीज़: मुंबई इंडियंस, राइज़िंग पुणे सुपरजायंट, आईपीएल फ़ाइनल 2026, राजीव गांधी अंतर्राष्ट्रीय स्टेडियम। प्रकार: मैच-रिपोर्ट का इनपुट। परिणाम: मुंबई एक रन से जीती।

इस प्रविष्टि की ख़ूबी यह नहीं है कि नतीजा मॉडल के पक्ष में आया। ख़ूबी यह है कि अगर नतीजा उलटा आता, तो भी मैं बता सकती थी कि मॉडल कहाँ ग़लत था — क्योंकि हर हिस्सा दर्ज है। मैंने ग्यारह साल लेजर रखा; फ़ाइनल एक रन पर आकर टिका। उस एक रन ने मॉडल को सही साबित नहीं किया। उसने सिर्फ़ यह साबित किया कि 58% का मतलब 100% नहीं होता, और जिस दिन कोई 58% को 100% समझने लगे, उस दिन लेजर बेकार हो जाता है।

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

असली ख़तरा खाली पंक्ति नहीं है

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

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

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

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

एक पंक्ति की ज़िद

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

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

अगला ओवर

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

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