कबड्डी विश्लेषण पाइपलाइन में Stage-1 आउटपुट खाली, मैच संबंधी निष्कर्ष रोकने पड़े

हुक: कबड्डी का लेबल बचा, कहानी गायब हो गई

किसी कबड्डी रिपोर्ट की शुरुआत स्कोरलाइन, रेड के समय या टैकल पॉइंट से होनी चाहिए। यहां शुरुआत में केवल एक शब्द बचा है—कबड्डी। Stage-1 विश्लेषण में Domain Label के रूप में कबड्डी दर्ज है, लेकिन लेख का शीर्षक, स्रोत, प्रकाशन समय, सारांश, सूचना बिंदु और खिलाड़ियों से जुड़ी सारी जगहें खाली हैं। ऐसे इनपुट से मैच का परिणाम निकालना वैसा ही है जैसे धूल भरे मैट पर केवल जर्सी का रंग देखकर विजेता घोषित कर देना।

मैंने कई रातों में मैच शीट और 2 बजे की tape rewatch के सहारे राय बनाई है, लेकिन इस मामले में tape ही उपलब्ध नहीं है। इसलिए किसी टीम, रेडर, डिफेंडर या टूर्नामेंट का नाम जोड़ना विश्लेषण नहीं, अनुमान होगा। “Unbeatable” जैसे शब्द तो बिल्कुल नहीं चल सकते; यहां यह भी पता नहीं कि कोई मैच हुआ था या केवल किसी पेज का टैग सिस्टम ने पढ़ा था।

संदर्भ: Stage-1 ने क्या पाया और क्या खो दिया

उपलब्ध विश्लेषण के अनुसार सिस्टम ने केवल Domain Label: kabaddi लौटाया। Article Title, Source और Type के लिए N/A दर्ज है। One-sentence Summary खाली है। Author Stance और Purpose भी उपलब्ध नहीं हैं। Information Points की सूची शून्य है। Entities, Time Sensitivity और Source Quality का मूल्यांकन नहीं हुआ।

यह सूचना की कमी से अलग समस्या है। यदि किसी खबर में केवल दो तथ्य हों, तो उनसे सीमित रिपोर्ट बनाई जा सकती है। यहां मूल पाठ ही सामने नहीं आया। संभव है कि ऊपर से मिला इनपुट खाली रहा हो, किसी वेबसाइट का JavaScript-rendered हिस्सा निकाला न जा सका हो, paywall या PDF ने extraction रोक दी हो, या parser ने को navigation और template text समझकर हटा दिया हो। एक दूसरी संभावना schema conversion की है—मॉडल ने अमान्य JSON लौटाया और सिस्टम ने उसे चुपचाप खाली default object से बदल दिया।

इस स्थिति में “कबड्डी से जुड़ी बड़ी खबर” लिखना पाठक को गलत दिशा देना होगा। न तारीख है, न प्रतियोगिता, न स्कोर, न स्रोत। Jakarta 2026 की कोई तुलना भी यहां काम नहीं आएगी, क्योंकि वह इस इनपुट से जुड़ा तथ्य नहीं है। तीन-peat शब्द भी तभी इस्तेमाल किया जा सकता है जब लगातार तीन खिताब का प्रमाण सामने हो।

मूल समस्या: खाली परिणाम को वैध डेटा मान लेना

डेटा पाइपलाइन की सबसे खतरनाक विफलता हमेशा crash नहीं होती। कई बार सिस्टम सफलतापूर्वक JSON बना देता है, लेकिन उसके भीतर वास्तविक सामग्री नहीं होती। यही यहां हुआ दिखता है। Domain classifier ने खेल की पहचान कर ली, जबकि extraction layer ने लेख की पहचान नहीं की। नीचे के चरणों ने पहले संकेत को पूरी खबर मान लिया तो गलती बढ़ती जाएगी।

एक उपयोगी validation नियम यहां अनिवार्य है: information_points.length > 0 और summary खाली न हो। यदि इनमें से कोई शर्त पूरी न हो, तो रिकॉर्ड को सामान्य article की तरह नहीं, extraction_failed के रूप में चिह्नित किया जाना चाहिए। साथ में मूल HTML, PDF, URL, timestamp और parser log का snapshot सुरक्षित रहना चाहिए। बिना snapshot के अगली जांच केवल अनुमान पर टिकेगी।

मेरे अनुभव में, मैच रिपोर्टिंग में एक छोटी scoreboard गलती भी पूरी कहानी का अर्थ बदल देती है। कबड्डी में तो एक raid का outcome, बोनस लाइन की स्थिति या सुपर टैकल का समय tactical narrative बदल सकता है। इसलिए खाली Stage-1 output से raid-success rate, tackle efficiency, do-or-die conversion या auction value जैसी कोई संख्या निकालना असंभव है। कोई भी ऐसी संख्या गढ़ी हुई मानी जाएगी।

यहां एक और blind spot है। Classifier का “kabaddi” लेबल confidence score के बिना दिया गया है। इसलिए यह भी नहीं कहा जा सकता कि स्रोत मैच रिपोर्ट था, खिलाड़ी की खबर थी, नियमों पर लेख था, महिला कबड्डी पर फीचर था या केवल वेबसाइट का category page। एक खेल का नाम विषय की दिशा बताता है, लेख का तथ्य नहीं।

सुधार का रास्ता: पहले extraction, फिर opinion

सबसे पहले मूल या raw input को दोबारा प्राप्त करना होगा। यदि पेज JavaScript पर निर्भर है, तो rendered HTML capture करना पड़ेगा। यदि सामग्री PDF में है, तो text layer और OCR दोनों की जांच जरूरी होगी। Paywall की स्थिति में उपलब्ध metadata को मूल लेख के विकल्प के रूप में स्पष्ट रूप से अलग रखना चाहिए।

इसके बाद schema validation होनी चाहिए। Title, source, publication date और summary जैसे अनिवार्य fields को खाली रहने पर pipeline को success status नहीं देना चाहिए। Information points की संख्या शून्य हो तो downstream summarizer और opinion generator को रोकना चाहिए। खिलाड़ियों और टीमों के नाम तभी entities में जाएं जब वे मूल पाठ में मिलें। अनुमानित नामों को entity list में डालना विशेष रूप से जोखिमपूर्ण है।

Source quality और time sensitivity भी extraction के बाद ही तय हो सकते हैं। बिना URL, प्रकाशक और तारीख के यह बताना संभव नहीं कि सूचना आधिकारिक है, स्वतंत्र रिपोर्ट है या सोशल मीडिया पोस्ट। कबड्डी के tournament cycle में समय की भूमिका बड़ी होती है—एक दिन पुरानी चोट की खबर lineup बदल सकती है, जबकि पुराना auction data वर्तमान valuation को गलत दिखा सकता है। यहां time sensitivity को “unassessed” रखना ही ईमानदार विकल्प है।

contrarian कोण: खाली रिपोर्ट छोटी समस्या नहीं

किसी संपादकीय डेस्क पर खाली आउटपुट को केवल तकनीकी glitch मानकर आगे बढ़ जाना आसान है। असली जोखिम यह है कि ऐसा रिकॉर्ड बाद में polished भाषा में बदलकर प्रकाशित हो सकता है। तब पाठक को लगेगा कि रिपोर्ट में कोई निष्कर्ष था, जबकि मूल स्रोत कभी पढ़ा ही नहीं गया। यही वह जगह है जहां “guaranteed” शब्द सबसे ज्यादा नुकसान करता है—सिस्टम की सफलता guaranteed मान लेना।

फिर भी एक सावधानी जरूरी है। हर खाली output extraction failure नहीं होता। कभी-कभी स्रोत सचमुच खाली, हटाया हुआ या केवल image-based हो सकता है। इसलिए pipeline को failure label के साथ कारणों की श्रेणी भी दर्ज करनी चाहिए: input_empty, extraction_blocked, schema_loss या unsupported_format। इससे engineering टीम समस्या को दोहरा सकेगी और संपादकीय टीम पाठक को सही सीमा बता सकेगी।

मैंने वर्षों की match watching में सीखा है कि एक दृश्य कभी पूरे खेल का substitute नहीं होता। एक शानदार ankle hold से defender को महान और एक असफल dubki से raider को obsolete घोषित करना गलत है। उसी तरह एक domain label से पूरी खबर बनाना भी गलत है। Tape, match sheet और source—तीनों के बिना फैसला अधूरा है।

निष्कर्ष: अगला कदम एक ही है

इस रिकॉर्ड से पुष्टि योग्य तथ्य केवल इतना है कि किसी upstream system ने इसे कबड्डी domain से जोड़ा और Stage-1 ने बाकी fields खाली लौटाए। कोई मैच, खिलाड़ी, टीम, तारीख या परिणाम प्रमाणित नहीं है। मूल लेख, Stage-1 raw JSON या extraction logs मिलने के बाद ही वास्तविक रिपोर्ट लिखी जा सकती है। तब तक सही headline जीत या हार की नहीं, डेटा की ईमानदारी की होगी: पहले स्रोत वापस लाएं, फिर कबड्डी पर फैसला दें।