खाली Stage-1 आउटपुट: जब स्पोर्ट्स न्यूज़ पाइपलाइन ‘सफल’ दिखती है, पर कुछ नहीं देती

सोमवार सुबह एक स्पोर्ट्स-न्यूज़ ऑटोमेशन पाइपलाइन ने टेनिस डोमेन का एक आर्टिकल प्रोसेस किया। सिस्टम ने हर चरण पर हरा टिक दिखाया। आउटपुट फ़ाइल बनी, वह मान्य JSON थी, स्कीमा सही था, और डाउनस्ट्रीम सर्विस ने उसे बिना शिकायत स्वीकार कर लिया। परेशानी यह थी कि उस फ़ाइल के अंदर जानकारी कुछ भी नहीं थी। Stage-1 का हर ज़रूरी फ़ील्ड — शीर्षक, स्रोत, आर्टिकल का प्रकार, एक-वाक्य सारांश, लेखक का रुख, लेख का उद्देश्य, सूचना-बिंदु और एंटिटीज़ — खाली या N/A था। जिस आर्टिकल में किसी मैच, किसी खिलाड़ी, किसी टूर्नामेंट का ज़िक्र तक नहीं पढ़ा जा सकता, वह आर्टिकल पाइपलाइन से ‘सफल’ होकर बाहर निकल गया। तालिका की जाँच करने पर तस्वीर साफ़ हुई। उसमें सिर्फ़ दो तरह की प्रविष्टियाँ थीं — N/A और खाली सूचियाँ। शीर्षक, स्रोत और आर्टिकल का प्रकार, तीनों N/A। इसका सीधा अर्थ यह है कि सिस्टम यह भी नहीं बता सका कि यह रिपोर्ट किस मीडिया संस्थान की है, क्या यह हार्ड न्यूज़ है, ओपिनियन पीस है या डेटा-आधारित विश्लेषण। इन तीनों के बिना आगे की कोई भी गुणवत्ता-जाँच नहीं हो सकती — न संस्थान की विश्वसनीयता, न उसका पूर्वाग्रह, और न ही इस बात की पुष्टि कि दावे किस श्रेणी के हैं। एक-वाक्य सारांश खाली होने का मतलब है कि तर्क का कोई केंद्र ही नहीं मिला जिसे तोड़कर देखा जा सके। लेखक का रुख और लेख का उद्देश्य N/A होने पर मंशा और फ़्रेमिंग का विश्लेषण असंभव हो जाता है। सबसे गंभीर बात — सूचना-बिंदुओं की सूची पूरी तरह खाली थी। सूचना-बिंदु वह ईंटें हैं जिनसे हर गहरा विश्लेषण बनता है: तथ्य, आँकड़े, हवाले, उद्धरण। इनके बिना तथ्य-जाँच का कोई आधार नहीं और तर्क-श्रृंखला की कोई पहली कड़ी नहीं। एंटिटीज़ भी इसी वजह से खाली रह गईं, क्योंकि निर्देश साफ़ था — ‘ऊपर के सूचना-बिंदुओं से पहचानें’ — और ऊपर कुछ था ही नहीं। समय-संवेदनशीलता और स्रोत-गुणवत्ता का मूल्यांकन भी नहीं हुआ। एकमात्र काम का संकेत Domain Label = tennis था: बस इतना पता था कि आर्टिकल टेनिस क्षेत्र का है। सिर्फ़ एक टैग के आधार पर गहरा विश्लेषण लिखना संभव नहीं है; जो ऐसा करेगा, वह विश्लेषण नहीं, अनुमान परोसेगा। इस पूरे घटनाक्रम में असली ख़तरा खाली आउटपुट नहीं है — असली ख़तरा यह है कि वह खाली आउटपुट मान्य दिखता है। एक शून्य-लंबाई की फ़ाइल या एक क्रैश तुरंत पकड़ में आ जाता है। लेकिन सही स्कीमा वाला खोखला JSON पूरी तरह ‘पास’ हो जाता है। डाउनस्ट्रीम मॉडल या रिपोर्ट जनरेटर उसे देखकर मान लेता है कि स्टेज-1 ठीक चला और अब बारी है विश्लेषण की। नतीजा यह होता है कि किसी ख़ाली इनपुट पर एक पूरी कहानी गढ़ दी जाती है। समय-संवेदनशीलता का आकलन न होना अपने आप में एक अलग समस्या है। खेल पत्रकारिता में समय ही सब कुछ है — चोट की ख़बर, टूर्नामेंट से नाम वापसी, रैंकिंग में बदलाव, ये सब कुछ घंटों में पुराने हो जाते हैं। अगर स्टेज-1 यह तय नहीं कर पाता कि सामग्री कितनी ताज़ा है, तो डाउनस्ट्रीम किसी पुरानी ख़बर को आज की घटना मानकर छाप सकता है। स्रोत-गुणवत्ता का मूल्यांकन न होना दूसरी बड़ी चूक है। एक आधिकारिक टूर्नामेंट प्रेस रिलीज़, एक बड़े अख़बार की रिपोर्ट, एक फ़्रीलांस ब्लॉग और एक सोशल मीडिया पोस्ट — इन सबका वज़न बराबर नहीं होता। सिस्टम इनमें फ़र्क़ नहीं कर पाया, क्योंकि स्रोत फ़ील्ड ही N/A था। स्पोर्ट्स जर्नलिज़्म में यह ग़लती महँगी पड़ती है — टेनिस में स्कोर, सीडिंग, चोट की स्थिति, कोर्ट की सतह, मौसम और मैच के आँकड़े सब ठोस तथ्य होते हैं। अगर सूचना-बिंदु ही नहीं हैं, तो हर वाक्य जोखिम है। कल्पना कीजिए कि इसी खोखले आउटपुट पर एक रिपोर्ट तैयार हो जाती है। उसमें कोई टेनिस खिलाड़ी का नाम आ जाता है, कोई स्कोर आ जाता है, कोई हवाला आ जाता है — और वह सब ग़लत होता है। ऐसी ग़लती सुधारी जा सकती है, पर उससे उठा शोर और भरोसे का नुकसान सुधारा नहीं जा सकता। इसीलिए ‘कुछ न होने’ को साफ़-साफ़ ‘कुछ नहीं मिला’ कहना ज़रूरी है। इस स्थिति में सबसे छोटा रास्ता यह है कि नीचे दिए तीन में से कोई एक इनपुट दिया जाए। पहला और सबसे बेहतर विकल्प — आर्टिकल का मूल पाठ। इससे स्टेज-1 को दरकिनार करके सीधे खुद ही विश्लेषण किया जा सकता है। दूसरा विकल्प — स्टेज-1 की सूचना-बिंदु सूची, भले ही पाँच से दस बिंदु हों; उनके आधार पर रुख, तर्क-श्रृंखला, तथ्य-जाँच और समय-संवेदनशीलता का आकलन संभव है। तीसरा विकल्प — URL। लेकिन यहाँ साफ़ चेतावनी ज़रूरी है: URL से सामग्री मिलने की गारंटी नहीं है। पे-वॉल, लॉगिन दीवार, जावास्क्रिप्ट रेंडरिंग और एंटी-स्क्रेपिंग व्यवस्थाएँ अक्सर खाली नतीजा देती हैं। अगर यह किसी पाइपलाइन की डिबगिंग है, तो यह समझना ज़रूरी है कि स्टेज-1 का पूरा N/A लौटाना ‘आर्टिकल में कोई विचार नहीं है’ का सबूत नहीं है। यह एक्सट्रैक्शन चरण की विफलता का लक्षण है। संभावना के क्रम में छह जाँचें की जानी चाहिए। पहली — इनपुट खाली है। हो सकता है कि अपस्ट्रीम ने एक्सट्रैक्टर को खाली टेक्स्ट या सिर्फ़ HTML का ढाँचा भेज दिया हो। दूसरी — पेज रेंडर ही नहीं हुआ। सिंगल-पेज ऐप्स और लेज़ी-लोडिंग वाले पेजों पर अक्सर सिर्फ़ एक खाली div पकड़ में आता है; ऐसे में हेडलेस रेंडरिंग या API/RSS का रास्ता अपनाना पड़ता है। तीसरी — पे-वॉल या लॉगिन दीवार। ऐसे में आर्टिकल का नोड मौजूद रहता है, पर उसके अंदर प्लेसहोल्डर टेक्स्ट होता है। चौथी — सिलेक्टर या प्रॉम्प्ट का मेल न खाना। हो सकता है कि नेविगेशन बार, कुकी सूचना या कमेंट सेक्शन पकड़ लिया गया हो, आर्टिकल का मुख्य भाग नहीं; या एक्सट्रैक्शन प्रॉम्प्ट JSON माँगता हो और मॉडल ने खाली ऑब्जेक्ट लौटा दिया हो। पाँचवीं — लंबाई में कटौती। आर्टिकल शून्य टोकन तक कट गया हो, यानी ऑफ़सेट ग़लत सेट था। छठी — चुपचाप अपवाद निगल लेना। कई एक्सट्रैक्शन फ़ंक्शन एरर को पकड़कर डिफ़ॉल्ट खाली ढाँचा लौटा देते हैं। इसी वजह से विफलता अदृश्य रह जाती है और नीचे की पूरी श्रृंखला उसे सफलता समझ बैठती है। इसका इलाज एक छोटी-सी चीज़ से शुरू होता है: स्टेज-1 में एक स्पष्ट शर्त जोड़ी जाए — जैसे ही information_points खाली मिले, प्रक्रिया ज़ोर से विफल हो, और लॉग में मूल इनपुट की लंबाई तथा पहले दो सौ अक्षर दर्ज हों। इससे दो फ़ायदे होंगे। पहला, खोखला परिणाम आगे नहीं बढ़ेगा। दूसरा, डिबगिंग के लिए ठोस सुराग हाथ में आएगा — पता चलेगा कि इनपुट खाली था, कटा हुआ था, या ग़लत नोड से आया था। एक मज़बूत पाइपलाइन में तीन स्तर के द्वार होने चाहिए। पहला द्वार इनपुट पर — खाली या बहुत छोटा टेक्स्ट सीधे अस्वीकार। दूसरा द्वार एक्सट्रैक्शन के बाद — न्यूनतम संख्या में सूचना-बिंदु और कम से कम एक एंटिटी का होना अनिवार्य। तीसरा द्वार आउटपुट से पहले — हर दावे के पीछे कोई स्रोत-बिंदु होना चाहिए, वरना वह वाक्य हटे। इन तीनों के बाद ही ‘सफल’ शब्द का कोई अर्थ बनता है। टेनिस जैसे खेल में तथ्यों की कीमत सबसे ज़्यादा होती है, क्योंकि वहाँ हर दावा आँकड़ों से टकराया जा सकता है। सर्विस प्रतिशत, ब्रेक पॉइंट, पहली सर्विस पर जीते गए अंक, कोर्ट की सतह के हिसाब से बदलती रणनीति — ये सब ऐसी चीज़ें हैं जिन्हें पाठक तुरंत जाँच सकता है। ऐसे में एक ऐसी पाइपलाइन जो बिना तथ्य के ‘विश्लेषण’ आगे बढ़ा देती है, वह सिर्फ़ तकनीकी नहीं, संपादकीय विफलता भी है। इसलिए इस रिपोर्ट का निष्कर्ष सीधा है: खाली स्टेज-1 आउटपुट को विश्लेषण की ज़मीन नहीं माना जा सकता। जो सामग्री उपलब्ध है, वह सिर्फ़ एक डोमेन टैग है — टेनिस। उसके आधार पर किसी खिलाड़ी, किसी मैच या किसी नतीजे के बारे में लिखना तथ्य-विहीन अनुमान होगा। सही रास्ता यह है कि मूल पाठ या सूचना-बिंदु उपलब्ध कराए जाएँ; उसके बाद ही विश्लेषण, रुख-परख और तथ्य-जाँच शुरू हो सकती है। तब तक पाइपलाइन का हरा टिक सिर्फ़ यह बताता है कि प्रक्रिया चली — यह नहीं कि उसने कुछ हासिल भी किया।