खाली तालिका भी एक निष्कर्ष है: क्रिकेट डेटा पाइपलाइन की ऑडिट रिपोर्ट

मंगलवार की सुबह, दिल्ली डेस्क। स्क्रीन पर एक फ़ाइल खुली — Stage-1 का आउटपुट। बारह फ़ील्ड, ग्यारह में N/A, और बारहवें में सिर्फ़ एक शब्द: cricket_asia। न शीर्षक, न स्रोत, न प्रकाशन-तिथि, न एक भी सूचना-बिंदु। Information Points के आगे खाली सूची है, और उसी खाली सूची से Entities निकालने का निर्देश बग़ल में लिखा है। डेस्क पर बैठा कोई भी पत्रकार इस क्षण में कुछ भरना चाहता है। दिमाग़ कहानी गढ़ने लगता है — "एशिया कप की तैयारी", "रोटेशन की राजनीति", "सीनियर का वर्कलोड मैनेजमेंट"। मैंने कीबोर्ड से हाथ हटा दिया।

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

सिस्टम चार चरणों में चलता है। पहला, फ़ेचिंग — सर्वर से पेज लाना। दूसरा, पार्सिंग — लेख के मुख्य भाग को नेविगेशन, विज्ञापन और कमेंट-सेक्शन से अलग करना। तीसरा, क्लासिफ़िकेशन — लेख का प्रकार तय करना। चौथा, एक्सट्रैक्शन — तथ्य, एंटिटी और समय-संवेदनशीलता निकालना। जब चौथा चरण खाली लौटता है, तो ऊपर के तीन में से कोई एक चरण पहले ही टूट चुका होता है। सवाल यह नहीं है कि लेख में क्या लिखा था; सवाल यह है कि लेख मशीन तक पहुँचा ही था या नहीं।

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

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

पेडवॉल या जावास्क्रिप्ट-रेंडरिंग। स्टैटिक अनुरोध के जवाब में सर्वर ने खोल-पन्ना भेजा; असली लेख ब्राउज़र में जाकर बनता है। यहाँ दूसरी जगह से भी भरपाई नहीं होती, क्योंकि पेज का पाठ सार्वजनिक सर्वर के पास है ही नहीं।

क्लासिफ़ायर का जल्दी लौट जाना। आउटपुट में Article Type = Unclassified पड़ा है। यह संकेत है कि प्रकार-निर्धारण पहले ही फ़ेल हुआ, और उसके बाद के एक्सट्रैक्टर तक बात पहुँची ही नहीं। पाइपलाइन ने काम नहीं किया, वह बीच में रुकी।

एन्कोडिंग। ग़ैर-यूनिकोड पेज को UTF-8 मान लिया गया, और डिकोडिंग में सारा पाठ खाली स्ट्रिंग बन गया। पाठ आया था, पढ़ा नहीं जा सका।

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

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

CricSultan के प्लेयर-डेप्थ इंडेक्स जैसे सार्वजनिक सूचकांक इस फ़र्क़ को तेज़ी से सामने लाते हैं, क्योंकि वहाँ हर संख्या के साथ उसका दायरा भी दर्ज रहता है। जिस कॉलम में गेंदबाज़ी-चरण का औसत लिखा हो, वहीं अगर यह भी लिखा हो कि आधार कितनी गेंदों का है, तो पाठक ख़ुद फ़ैसला कर सकता है कि नतीजा माने या टाल दे। 2026 चैंपियंस ट्रॉफ़ी फ़ाइनल के बाद मैंने भारत की 158 रन की पारी को बारह आउट-सीक्वेंस में काटा था, और मोहम्मद आमिर के 3/16 को ओवर, गेंदबाज़ी-प्रकार और फ़ील्ड-प्रतिबंध के हिसाब से टैग किया था। तब मैंने यह सीखा था कि हर नतीजे के साथ उसकी नाप लिखनी पड़ती है, वरना अगली बार वही नतीजा किसी और मैच में बिना जाँच के उठा लिया जाता है।

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

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

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