खाली फ़ील्ड का मामला: क्रिकेट डेटा-डेस्क की उस रात की ऑडिट रिपोर्ट, जब Stage-1 ने कुछ भी नहीं लौटाया

रात के तीन बजे हैं। डेस्क पर स्क्रीन खुली है और सामने एक JSON फ़ाइल पड़ी है। title खाली है, source खाली है, type में 'Unclassified' लिखा है, one-sentence summary खाली है, author stance N/A है, और information_points की लिस्ट बिल्कुल खाली है। पूरे ढाँचे में एक ही फ़ील्ड में कुछ लिखा है — Domain Label: cricket_asia। बस इतना। मैंने इसे चालीस बार रिवाइंड किया, तब समझ आया कि मैं क्या देख रहा हूँ। यह कोई रहस्यमय खोज नहीं थी, यह एक खाली लेजर था। और उस वक़्त डेस्क पर सबसे आसान काम यह था कि मैं 'cricket_asia' वाले लेबल को पकड़ लूँ, उसके इर्द-गिर्द एशियाई क्रिकेट की एक चमकदार कहानी बुन दूँ, और सुबह होने से पहले फाइल अपलोड कर दूँ। मैंने वह नहीं किया। यह रिपोर्ट उसी फैसले का हिसाब है — और यह भी बताती है कि उस रात असल में क्या-क्या गायब था, क्यों गायब था, और उसे ठीक करने का सबसे छोटा रास्ता कौन-सा है। यह कोई खेल की खबर नहीं है। यह उस पाइपलाइन की ऑडिट रिपोर्ट है जिससे आज के दौर में खेल की खबरें गुज़रती हैं। पिछले कुछ सालों में क्रिकेट कवरेज का जो हिस्सा सबसे तेज़ी से बदला है, वह मैदान पर नहीं, डेस्क पर बदला है। पहले एक रिपोर्टर मैच देखता था, नोट्स बनाता था, और शाम को फाइल करता था। अब बीच में कई परतें आ गई हैं — क्रॉलर, क्लीनर, चंकर, एक्सट्रैक्शन मॉडल, फिर एनालिसिस मॉडल। हर परत एक फ़िल्टर है, और हर फ़िल्टर का एक किराया है। किराया यह है कि अगर ऊपर की कोई परत चुपचाप फेल हो जाए, तो नीचे की परत को पता ही नहीं चलता कि उसे जो सामग्री मिली है, वह सामग्री है ही नहीं। खालीपन भी एक इनपुट की तरह दिखता है। और यही इस पूरी रिपोर्ट का केंद्रीय तथ्य है। इस मामले में जो सामने आया, उसे मैं दो चरणों में बाँटकर देखता हूँ। Stage-1 वह चरण है जहाँ किसी बाहरी स्रोत से लेख उठाया जाता है और उसकी मूल संरचना निकाली जाती है — शीर्षक, स्रोत, प्रकार, सार, लेखक का रुख, सूचना-बिंदु, समय-संवेदनशीलता, स्रोत की गुणवत्ता। Stage-2 वह चरण है जहाँ उस संरचना पर गहरा विश्लेषण खड़ा किया जाता है। इस बार Stage-1 का आउटपुट पूरी तरह खाली आया। Stage-2 के पास बैठकर लिखने के लिए कुछ भी नहीं था। और यहीं एक पुरानी आदत सिर उठाती है — जब इनपुट खाली हो और डेडलाइन पास हो, तो इंसान खुद से सामग्री भरने लगता है। मुझे यह आदत पहचाननी आती है, क्योंकि एक ज़माने में मैंने खुद 52 मैचों की फ्रेम-दर-फ्रेम लॉगिंग की थी और उनमें से किसी भी इंसिडेंट शीट पर किसी ने मुझसे सवाल नहीं पूछा था। जब कोई सवाल नहीं पूछता, तो लिखने का दबाव बढ़ जाता है। यह दबाव ही वह जगह है जहाँ कवरेज खराब होती है। अब उस खाली तालिका को एक-एक करके पढ़िए, क्योंकि खालीपन भी जानकारी देता है — बस उसे पढ़ने का तरीका अलग होता है। पहला, Article Title और Source दोनों N/A हैं। इसका सीधा मतलब यह है कि स्रोत की प्रामाणिकता का कोई आधार ही नहीं बचा। एक खेल पत्रकार के तौर पर मेरा पहला सवाल हमेशा यह होता है — यह जानकारी किसने पहले छापी, कब छापी, और उसका ट्रैक रिकॉर्ड क्या है। शीर्षक और स्रोत के बिना यह तीनों सवाल हवा में लटक जाते हैं। क्रॉस-वेरिफिकेशन की बात तो तब होती है जब पहला स्रोत ही मौजूद हो। यहाँ पहला स्रोत ही नहीं है। दूसरा, Article Type 'Unclassified' है। यह सबसे ज़्यादा नुकसान करने वाली खाली फ़ील्ड है, और ज़्यादातर लोग इसे हल्के में लेते हैं। खेल पत्रकारिता में चार अलग-अलग तरह की चीज़ें रोज़ छपती हैं — समाचार, कमेंट्री, डेटा-रिपोर्ट और भविष्यवाणी। इन चारों को एक ही ढाँचे से नहीं पढ़ा जा सकता। समाचार में सवाल यह है कि क्या हुआ। कमेंट्री में सवाल यह है कि लेखक क्या मानता है और क्यों। डेटा-रिपोर्ट में सवाल यह है कि संख्याएँ किस विंडो से निकली हैं और नमूना कितना बड़ा है। भविष्यवाणी में सवाल यह है कि दाँव क्या है और असफलता की शर्त क्या है। अगर प्रकार तय नहीं है, तो आप किसी भी टुकड़े को गलत ढाँचे में रखकर उसका मतलब बदल सकते हैं। यह वैसा ही है जैसे मैदान पर किसी घटना को देखकर आप तय न कर पाएँ कि यह फुटबॉल का नियम है या क्रिकेट का — और फिर दोनों किताबों से एक-एक पन्ना उठाकर फैसला सुना दें। तीसरा, One-sentence Summary खाली है। इसका मतलब है कि विश्लेषण का कोई विषय ही नहीं है। चौथा, Author Stance N/A है — यानी लेखक का झुकाव किस दिशा में है, यह पता लगाने का कोई ज़रिया नहीं। पांचवां, Information Points की लिस्ट खाली है, और यह सबसे भारी कमी है। सूचना-बिंदु ही वे ईंटें हैं जिनसे एंटिटी एक्सट्रैक्शन, टाइमलाइन और कारण-श्रृंखला खड़ी होती है। ईंटें नहीं हैं तो दीवार नहीं है। छठा, Time Sensitivity का आकलन ही नहीं हुआ — यानी यह तय करने का कोई तरीका नहीं कि खबर अभी भी खबर है या कल की बासी रिपोर्ट। सातवां, Source Quality का कोई ग्रेड नहीं है, क्योंकि ग्रेड देने के लिए स्रोत चाहिए और स्रोत मौजूद नहीं है। इन सात खाली फ़ील्डों में एक बात साझा है: इनमें से कोई भी अकेले 'थोड़ी-सी' गड़बड़ नहीं है। यह एक पूरी तरह से खाली लेजर है, आधा-अधूरा नहीं। और यही बात इसे आसान बनाती है — अगर आधा डेटा आया होता, तो बहस होती कि कौन-सा हिस्सा भरोसे लायक है। पूरा खाली आने पर बहस खत्म हो जाती है। समस्या यह है कि बहुत सी डेस्कों पर बहस खत्म नहीं होती; वहाँ खालीपन को 'सामग्री की कमी' नहीं, 'मॉडल का रचनात्मक स्वतंत्रता' मान लिया जाता है। यहाँ एक ही गैर-खाली संकेत बचा है — Domain Label: cricket_asia। और यह संकेत दो बिल्कुल अलग-अलग दुनियाओं की ओर इशारा कर सकता है। पहली दुनिया: मूल लेख सचमुच एशियाई क्रिकेट से जुड़ा था — किसी टूर्नामेंट, किसी बोर्ड, किसी सदस्य संघ या किसी फ्रैंचाइज़ी लीग से — और सिर्फ़ एक्सट्रैक्शन चरण फेल हुआ। दूसरी दुनिया: यह लेबल अपस्ट्रीम का डिफ़ॉल्ट मान है या गलत टैग है, और मूल सामग्री से इसका कोई रिश्ता नहीं। इन दोनों स्थितियों में इलाज पूरी तरह अलग है। पहली स्थिति में आप कहते हैं कि पाइपलाइन की एक परत मरम्मत मांग रही है। दूसरी स्थिति में आप कहते हैं कि टैगिंग का नियम ही टूटा है। और अगर आप बिना फर्क किए इस लेबल को पकड़कर 'एशियाई क्रिकेट का भूगोल' जैसा लेख लिख देते हैं, तो आपने समस्या का इलाज नहीं किया — आपने समस्या को एक नए, ज़्यादा महँगे रूप में आगे भेज दिया है। मेरे पास इस लेबल के अलावा कुछ नहीं है, इसलिए मैं इससे आगे कुछ नहीं कहूँगा। अब वह सवाल जो असल में पूछा जाना चाहिए: कहाँ टूटा? मैं चार चेकपॉइंट्स के क्रम में देखता हूँ, और यह क्रम महत्वपूर्ण है क्योंकि सबसे सस्ता चेक पहले आता है। पहला चेकपॉइंट — क्या क्रॉलर ने खाली बॉडी लौटाई? यह सबसे आम वजह है और सबसे कम रोमांचक भी। एंटी-स्क्रैपिंग दीवारें, पेडवॉल, और जावास्क्रिप्ट से बने पेज ऐसा करते हैं। सर्वर 200 लौटाता है, हेडर सही दिखते हैं, लेकिन बॉडी में लेख नहीं होता। अगर सिस्टम सिर्फ़ स्टेटस कोड देखकर आगे बढ़ता है, तो वह खाली बॉडी को सफल कॉल मान लेता है। दूसरा चेकपॉइंट — क्या सफाई और चंकिंग चरण ने पूरा लेख ही फ़िल्टर कर दिया? यह उससे ज़्यादा आम है जितना लोग मानते हैं। बहुत सारे क्लीनर नेविगेशन, विज्ञापन और फुटर हटाने के चक्कर में मुख्य पाठ को भी 'बॉयलरप्लेट' मानकर काट देते हैं। नतीजा यह होता है कि पाइपलाइन में सामग्री आई थी, और सामग्री गई भी थी — बस बीच में किसी एक नियम ने उसे बाहर कर दिया। इस स्थिति में लॉग देखने पर पता चलता है कि टोकन काउंट अचानक शून्य हो गया, जबकि कच्चा HTML भरा हुआ था। तीसरा चेकपॉइंट — क्या मॉडल का आउटपुट कटा या पार्स फेल हुआ? यह सबसे धोखेबाज़ चेकपॉइंट है, क्योंकि यहाँ सिस्टम 'काम कर रहा' दिखता है। मॉडल ने जवाब दिया, लेकिन जवाब टोकन सीमा पर कट गया, या JSON का ढाँचा टूटा और पार्सर ने खाली ऑब्जेक्ट लौटा दिया। ऐसे में हर फ़ील्ड null दिखती है — ठीक वैसे ही जैसे इस मामले में दिख रही है। फर्क सिर्फ़ इतना है कि कटे हुए आउटपुट में अक्सर कहीं-न-कहीं आधा वाक्य बचा रह जाता है। यहाँ कुछ भी नहीं बचा, जिससे संभावना थोड़ी कम होती है, लेकिन खारिज नहीं होती। चौथा चेकपॉइंट — क्या इनपुट ही टेक्स्ट नहीं था? अगर स्रोत एक तस्वीर, स्कैन की हुई PDF या स्क्रीनशॉट था और उसे OCR के बिना सीधे टेक्स्ट मान लिया गया, तो एक्सट्रैक्शन के पास पढ़ने के लिए कुछ भी नहीं पहुँचा। यह वह गलती है जो सबसे ज़्यादा शर्मिंदा करती है, क्योंकि इसे ठीक करने में सबसे कम समय लगता है। इन चारों में से कौन-सा हुआ, यह मैं बिना लॉग देखे नहीं कह सकता — और यही इस पूरी रिपोर्ट का सबसे ईमानदार वाक्य है। लेकिन एक बात मैं पूरे भरोसे से कह सकता हूँ: चारों में से किसी भी स्थिति में जवाब 'मॉडल को और डेटा दो' नहीं है। जवाब हमेशा 'पहले यह पक्का करो कि डेटा पहुँचा' है। यहीं पर मैं अपनी उस पुरानी आदत की ओर लौटता हूँ जिसे मैंने रिव्यू लॉगिंग के दिनों में सीखा था। 2026 में जब मैं भारत में हुए अंडर-17 विश्व कप की होस्ट ब्रॉडकास्ट पर रिप्ले लॉगर की कुर्सी पर बैठा था, तो हमारे पास एक सख्त नियम था — किसी भी घटना को 'दर्ज' तभी किया जाता था जब उसका टाइमस्टैम्प और क्लिप नंबर दोनों मौजूद हों। अगर क्लिप नंबर नहीं मिला, तो घटना घटी हो सकती थी, लेकिन वह शीट पर नहीं जाती थी। यह नियम क्रूर लगता है, और यह क्रूर ही है। लेकिन यही नियम तय करता है कि शीट पर जो लिखा है, उस पर दूसरी बार देखने पर भी भरोसा किया जा सके। जब 2026 में रूस विश्व कप के दौरान मैंने 29 पेनल्टी की ट्रैकिंग की और हर ओवरटर्न पर आठ मिनट के अंदर नियम-उद्धरण के साथ अपडेट भेजा, तो वह गति संभव थी क्योंकि नियम पहले से तय था — फैसला, नियम, मिसाल, परिणाम। और 2026 में जब मैंने एक IPL टीम के एनालिटिक्स यूनिट के लिए DRS समीक्षा का मॉडल बनाया, तो सबसे मुश्किल हिस्सा मॉडल नहीं था; सबसे मुश्किल हिस्सा यह तय करना था कि मॉडल को कब 'ना' कहना चाहिए। 44 खिलाड़ी-समीक्षाओं में से सिर्फ़ 14 सही साबित हुईं, और सुधार उस चेकलिस्ट से आया जो समीक्षा से पहले भरी जाती थी — बाद में नहीं। यही सबक इस पाइपलाइन पर लागू होता है। Stage-1 के दरवाज़े पर एक चेकलिस्ट होनी चाहिए, और वह चेकलिस्ट दो सवालों से शुरू होनी चाहिए: title मौजूद है या नहीं, और information_points खाली है या नहीं। अगर इनमें से किसी का भी जवाब 'नहीं' है, तो आउटपुट पर मुहर लगनी चाहिए — extraction_failed। यह मुहर लगते ही वह आइटम डाउनस्ट्रीम नहीं जाना चाहिए। यह कोई तकनीकी शौक नहीं है। यह वही काम है जो एक रेफरी मैदान पर करता है जब वह तय करता है कि गेंद डेड है या नहीं — खेल आगे बढ़ाने से पहले उसे स्थिति साफ़ करनी होती है। अगर आप खाली आउटपुट को आगे भेज देते हैं, तो नीचे की हर परत उस खालीपन को अपनी कल्पना से भर देती है, और आखिर में जो लेख छपता है, वह किसी स्रोत का लेख नहीं होता — वह पाइपलाइन का आत्म-चित्र होता है। यहाँ वह बात आती है जिस पर मैं सबसे ज़्यादा लिखता हूँ, और जो इस मामले में भी लागू होती है: जवाबदेही की असमानता। जब कोई खिलाड़ी गलत शॉट खेलता है, तो उसे हम फ्रेम-दर-फ्रेम तोड़कर दिखाते हैं। जब कोई अंपायर गलत फैसला देता है, तो उसकी धीमी गति की क्लिप चारों तरफ़ घूमती है। लेकिन जब कोई डेटा-पाइपलाइन चुपचाप खाली आउटपुट लौटाती है, तो कोई स्लो-मोशन नहीं बनता। कोई टाइमस्टैम्प नहीं जुटाता। और सबसे बड़ी विडंबना यह है कि जो डेस्क उस आउटपुट पर मुहर लगाता है, वही डेस्क बाद में उसी आउटपुट के आधार पर लिखी गई खबर की गुणवत्ता पर सवाल उठाता है। मैंने यह पैटर्न बहुत बार देखा है — नीचे के आदमी की गलती दिखती है, ऊपर के सिस्टम की गलती नहीं। इस मामले में सबसे आसान आरोप यह लगाया जा सकता है कि मॉडल ने धोखा दिया। मैं इस आरोप को पूरी तरह खारिज करता हूँ, और मेरे पास इसके लिए एक ठोस कारण है। मॉडल ने कुछ भी गलत नहीं लिखा। उसने कुछ भी नहीं लिखा। खाली आउटपुट कोई झूठ नहीं है — यह एक साफ़ इनकार है। असली गलती उस इंसान या उस नियम की है जिसने इस साफ़ इनकार को पढ़ा और उसे 'सामग्री की कमी' के बजाय 'आगे बढ़ने का संकेत' मान लिया। एक खाली लेजर एक ईमानदार दस्तावेज़ है। उसे अनदेखा करना बेईमानी है। अब वह पलटकर देखने वाली बात, जिस पर मुझे सबसे कम भरोसा था और जो सबसे ज़्यादा सही निकली। जब मैंने पहली बार यह तालिका देखी, तो मेरा पहला विचार यह था कि यह एक बड़ी विफलता है। दूसरी बार देखने पर लगा कि यह एक छोटी विफलता है। तीसरी बार देखने पर समझ आया कि यह विफलता नहीं है — यह एक सफलता है जिसे गलत जगह पर सफलता मान लिया गया। सिस्टम ने वही किया जो उसे करना चाहिए था: उसने कोई झूठी सामग्री नहीं गढ़ी, कोई नकली शीर्षक नहीं बनाया, कोई काल्पनिक सूचना-बिंदु नहीं भरा। उसने खाली हाथ लौटकर ईमानदारी दिखाई। समस्या यह है कि पाइपलाइन में ऐसी कोई जगह नहीं है जहाँ यह ईमानदारी दर्ज हो सके। खाली आउटपुट के लिए कोई अलर्ट नहीं है, कोई लाल झंडा नहीं है, कोई लॉग-लाइन नहीं है जो कहे कि 'यहाँ कुछ नहीं मिला।' इसलिए ईमानदारी चुपचाप गुज़र जाती है और उसकी जगह अगली परत की कल्पना ले लेती है। इस पूरे मामले में सबसे ज़्यादा चौंकाने वाली बात यह नहीं है कि डेटा खाली आया। सबसे ज़्यादा चौंकाने वाली बात यह है कि एक पूरी प्रणाली ऐसी हालत में चल रही है जहाँ खाली डेटा और भरे हुए डेटा में फर्क करने का कोई अनिवार्य दरवाज़ा नहीं है। यह वैसा ही है जैसे कोई टूर्नामेंट ऐसे DRS से चले जिसमें 'अनिर्णीत' का कोई विकल्प ही न हो — हर समीक्षा को या तो out होना पड़े या not out, और अगर रिप्ले ही न मिले तो अंपायर को अपनी भावना से फैसला सुनाना पड़े। कोई भी क्रिकेट फॉलोअर बता सकता है कि वह व्यवस्था कितनी जल्दी बिगड़ती है। मैं यहाँ एक तयशुदा फैसला देना चाहता हूँ, क्योंकि सबूत जुटाने के बाद झिझकना मेरे तरीके के खिलाफ़ है। फैसला यह है: इस Stage-1 आउटपुट पर कोई विश्लेषण नहीं बनाया जा सकता, और जो भी इसे बनाएगा, वह क्रिकेट के बारे में नहीं लिख रहा होगा — वह अपने अनुमानों के बारे में लिख रहा होगा। cricket_asia लेबल एक संकेत है, सबूत नहीं। संकेत से शुरुआत की जा सकती है, फैसला नहीं सुनाया जा सकता। अब आगे का रास्ता, प्राथमिकता के क्रम में। सबसे छोटा रास्ता यह है कि मूल लेख का पाठ वापस लाया जाए — पूरा बॉडी टेक्स्ट, या URL के साथ बॉडी। जैसे ही वह आता है, Stage-1 दोबारा चलाया जा सकता है और उसके बाद Stage-2 खड़ा किया जा सकता है। यह सबसे तेज़ रास्ता है और इसमें कोई शॉर्टकट नहीं है। अगर मूल लेख उपलब्ध नहीं है, तो अगला काम यह तय करना है कि कौन-सी कड़ी टूटी — और उसके लिए ऊपर बताए चार चेकपॉइंट्स क्रम से देखने होंगे। और अगर यह एक बड़ी बैच प्रक्रिया है, तो सबसे ज़रूरी सुधार तकनीकी नहीं, प्रक्रियात्मक है: Stage-1 के निकास पर एक अनिवार्य जाँच लगाइए जो खाली title या खाली information_points को देखकर आइटम को extraction_failed के रूप में चिह्नित कर दे और उसे डाउनस्ट्रीम जाने से रोक दे। यह एक लाइन का नियम है, और यह पूरे डाउनस्ट्रीम विश्लेषण को दूषित होने से बचा सकता है। जब मूल सामग्री आ जाएगी, तो जो आउटपुट मैं दूँगा, उसका ढाँचा पहले से तय है। सूचना-बिंदुओं को चार हिस्सों में अलग किया जाएगा — तथ्य, उद्धरण, आंकड़े और राय। इन्हें एक-दूसरे में मिलाया नहीं जाएगा, क्योंकि मिलाने से ही सबसे ज़्यादा गलतियाँ होती हैं। इसके बाद एंटिटी और संबंध निकाले जाएंगे — संस्थाएँ, लोग, प्रतियोगिताएँ, और टाइमलाइन। फिर लेखक की स्थिति और उसके तर्क का ढाँचा देखा जाएगा: वह क्या दावा कर रहा है, कौन-सा सबूत दे रहा है, और कौन-सी धारणा वह बिना कहे मान रहा है। अंत में स्रोत की गुणवत्ता और समय-संवेदनशीलता का ग्रेड तय होगा, और उन दावों की सूची बनेगी जिन्हें क्रॉस-वेरिफिकेशन चाहिए। जो लोग सोचते हैं कि यह रिपोर्ट एक तकनीकी खराबी की कहानी है, वे इसे गलत ढाँचे में पढ़ रहे हैं। यह उस पल की कहानी है जब एक डेस्क के पास लिखने के लिए कुछ नहीं था और उसने फिर भी न लिखने का फैसला किया। खेल पत्रकारिता में यह फैसला उतना ही ज़रूरी है जितना कोई बड़ा स्कूप, और उतना ही कम दिखता है। स्टेडियम खाली हो जाता है, सीटी बंद हो जाती है, और फुटेज चलता रहता है — लेकिन अगर फुटेज में कुछ न हो, तो सबसे बहादुर काम यह कहना है कि मैंने कुछ नहीं देखा। आगे के लिए एक सवाल छोड़ता हूँ, और यह सवाल उन लोगों के लिए है जो खेल कवरेज की गुणवत्ता पर निगरानी रखते हैं: अगली बार जब कोई खबर बिना स्रोत के छपे और बाद में सुधार माँगे, तो क्या हम उस रिपोर्टर से पूछेंगे, या उस पाइपलाइन से पूछेंगे जिसने खाली लेजर को हरी झंडी दिखाई? जब तक इस सवाल का जवाब नहीं मिलता, हम वही करते रहेंगे जो हम हमेशा करते हैं — नीचे के आदमी को धीमी गति में देखते रहेंगे, और ऊपर का सिस्टम चुपचाप चलता रहेगा।