खाली JSON का सबक़: जब क्रिकेट कंटेंट पाइपलाइन की पहली मंज़िल ख़ाली लौटती है

एक स्पोर्ट्स डेस्क पर सबसे महँगी विफलता वह नहीं होती जो अलार्म बजाती है। सबसे महँगी विफलता वह है जो चुपचाप एक ऐसा आउटपुट सौंप देती है जो देखने में पूरा लगता है — फ़ील्ड मौजूद हैं, ब्रैकेट बंद हैं, JSON वैलिड है — और अंदर से पूरी तरह ख़ाली है। जिस पल कोई सिस्टम 'कुछ नहीं' कहने के बजाय 'N/A' कहकर आगे बढ़ जाता है, उसी पल से डेस्क पर यह भरोसा बन जाता है कि काम हो गया है। यह रिपोर्ट उसी एक घटना की तहक़ीक़ात है। मामला एक Stage-1 आउटपुट का है। Stage-1 का मतलब है किसी कच्चे पाठ को पढ़कर उसका ढाँचा तैयार करने वाला पहला चरण: शीर्षक क्या है, स्रोत क्या है, लेख किस क़िस्म का है, एक वाक्य में सार क्या है, लेखक का रुख क्या है, लेख का मक़सद क्या है, उसमें कौन-कौन से तथ्य हैं, कौन सी संस्थाएँ आती हैं, समय-संवेदनशीलता कितनी है, स्रोत की गुणवत्ता कैसी है। यही दस-ग्यारह फ़ील्ड आगे के हर काम की नींव होते हैं — चाहे सारांश बनाना हो, चाहे टैगिंग, चाहे सिफ़ारिश, चाहे संपादकीय निर्णय। इस मामले में वह ढाँचा लौटा, लेकिन ख़ाली। शीर्षक N/A। स्रोत N/A। लेख का प्रकार Unclassified। एक वाक्य का सार रिक्त। लेखक का रुख N/A। लेख का मक़सद N/A। सूचना-बिंदुओं की सूची ख़ाली। संस्थाओं वाले फ़ील्ड में असली नाम की जगह एक निर्देश लिखा था — 'identify from the information points above'। समय-संवेदनशीलता का मूल्यांकन हुआ ही नहीं। स्रोत की गुणवत्ता के सामने यह वाक्य था कि स्रोत-फ़ील्ड से अंदाज़ा लगा लिया जाए। यानी एक भी फ़ील्ड में वह चीज़ नहीं थी जिसे आगे इस्तेमाल किया जा सके। पूरे ढाँचे में एक ही फ़ील्ड भरी थी: Domain Label, और उसका मान था cricket_world। इस एक तथ्य से केवल इतना निकलता है कि लेख का विषय क्रिकेट की दुनिया से जुड़ा है। इतना नहीं निकलता कि वह मैच रिपोर्ट है, खिलाड़ी की ट्रांसफ़र ख़बर है, ICC के नियमों या वित्त पर टिप्पणी है, क्रिकेट सट्टेबाज़ी या व्यापारीकरण का मामला है, या फिर किसी घरेलू टूर्नामेंट का आँकड़ा-आधारित विश्लेषण है। ये पाँचों क़िस्में एक-दूसरे से बिल्कुल अलग तरह से पढ़ी जाती हैं, और इनमें से हर एक के लिए 'गहरा विश्लेषण' का रास्ता अलग है। यहीं से असली समस्या शुरू होती है। ख़ाली ढाँचा कोई तटस्थ स्थिति नहीं है; वह एक ऐसा इनपुट है जो आगे के हर मॉडल को मजबूर करता है कि वह अपने भीतर से कुछ भर ले। जब किसी भाषा-मॉडल को कहा जाए कि इन बिंदुओं के आधार पर विश्लेषण लिखो, और बिंदु ही मौजूद न हों, तो मॉडल के पास दो ही रास्ते बचते हैं: या तो वह साफ़ मना कर दे, या वह एक ऐसा ढाँचा गढ़ दे जो देखने में विश्लेषण जैसा हो पर असल में उस लेख से उसका कोई रिश्ता न हो। दूसरा रास्ता ज़्यादा आम है, क्योंकि वह सस्ता है और तुरंत 'पूरा' दिखता है। इसलिए ज़रूरी है कि हम यह पूछें कि ऐसा हुआ क्यों। इस ख़ाली ढाँचे की अपनी एक डायग्नोस्टिक वैल्यू है। तीन संभावित कारण हैं, और उन्हें प्रायिकता के क्रम में रखा जा सकता है। पहला और सबसे संभावित कारण है अपस्ट्रीम इनपुट का ख़ाली होना या क्रॉल का विफल होना। यह सबसे अधिक होता है और सबसे कम दिखता है। क्रिकेट की वेबसाइटें आजकल स्कोरकार्ड और लाइव ब्लॉग जैसे टेम्पलेट पर चलती हैं जिनका मुख्य हिस्सा जावास्क्रिप्ट से बनता है। पारंपरिक एक्सट्रैक्टर किसी पेज का HTML लेकर उसमें से चुने हुए CSS सेलेक्टर के ज़रिए पाठ निकालते हैं। अगर स्कोरकार्ड का डेटा पेज के सर्वर-साइड HTML में नहीं है बल्कि ब्राउज़र में बाद में भरा जाता है, तो एक्सट्रैक्टर को एक ऐसा पेज मिलता है जिसमें ढाँचा है पर सारा असली माल ग़ायब है। नतीजा: एक्सट्रैक्टर ख़ाली स्ट्रिंग लौटाता है। कोई एरर नहीं, कोई अपवाद नहीं, बस शून्य लंबाई का पाठ। दूसरा कारण है क्लासिफ़ायर का शॉर्ट-सर्किट। ढाँचे में लेख का प्रकार 'Unclassified' लिखा है। यह कोई वर्गीकरण परिणाम नहीं है; यह वर्गीकरण की विफलता का नाम है। अगर पाइपलाइन की बनावट ऐसी हो कि सारांश निकालना और लेखक का रुख पहचानना दोनों किसी प्रकार-आधारित शाखा के अंदर टँगे हों, तो प्रकार के 'Unclassified' होते ही वे दोनों शाखाएँ छूट जाती हैं। और अगर उस छूटने के बाद कोई सामान्य फ़ॉलबैक नहीं है, तो फ़ील्ड अपने डिफ़ॉल्ट मान पर रह जाती हैं। इस डिज़ाइन में ग़लती यह नहीं कि शाखाएँ हैं; ग़लती यह है कि शाखा न मिलने पर प्रक्रिया रुक जाती है, बजाय इसके कि वह एक सामान्य रास्ते से आगे बढ़े। तीसरा कारण सबसे ज़्यादा खुलासेवाला है, और वह है फ़ील्ड में निर्देश का लिखा जाना। संस्थाओं वाले फ़ील्ड में नाम की जगह जो वाक्य बैठा था — 'identify from the information points above' — वह किसी मॉडल का नतीजा नहीं, किसी टेम्पलेट का साँचा है। इसका मतलब साफ़ है: वह फ़ील्ड कभी असल में भरी ही नहीं गई। जब अपस्ट्रीम की सूचना-बिंदु ख़ाली थी, तब उस फ़ील्ड को भरने वाला चरण या तो चला ही नहीं, या चला और उसने टेम्पलेट का मूल वाक्य ही लौटा दिया। यह डेटा की कमी नहीं है; यह प्रक्रिया का बग है। डेटा की कमी में फ़ील्ड ख़ाली रहती है। प्रक्रिया के बग में फ़ील्ड में वह निर्देश बैठा रह जाता है जो किसी को दिया गया था। इन तीनों में फ़र्क़ करना ज़रूरी है, क्योंकि इलाज अलग-अलग हैं। अगर दिक़्क़त पहले कारण में है — यानी क्रॉलर को ख़ाली पाठ मिला — तो मॉडल का प्रॉम्प्ट सुधारने से कुछ नहीं होगा। आप एक ऐसे मज़दूर का औज़ार तेज़ कर रहे हैं जिसके हाथ में कच्चा माल ही नहीं पहुँचा। पहले यह जाँचना होगा कि उसी लेख को अलग से एक्सट्रैक्ट करने पर पाठ की लंबाई शून्य आती है या नहीं। अगर शून्य आती है, तो मरम्मत क्रॉलिंग की परत पर होनी चाहिए — हेडलेस ब्राउज़र से रेंडर कराना, या स्कोरकार्ड के लिए समर्पित API का इस्तेमाल करना, या टेम्पलेट-वार सेलेक्टर की जगह विषय-आधारित निष्कर्षण अपनाना। अगर पाठ ठीक आ रहा है, तो दूसरा कारण जाँचें: क्या वर्गीकरण के बाद की शाखाएँ वाक़ई चल रही हैं, और क्या 'Unclassified' की स्थिति में कोई फ़ॉलबैक मौजूद है। यहाँ सबसे आसान सुधार यह है कि क्लासिफ़ायर को तीन में से एक हालत में बाँटा जाए — पक्का प्रकार, संभावित प्रकार, और अज्ञात — और अज्ञात की हालत में भी सामान्य सारांश निकाला जाए। अज्ञात होना जानकारी का अभाव है, काम रोक देने का कारण नहीं। और अगर दोनों ठीक हैं, तो तीसरा कारण बचता है: टेम्पलेट स्ट्रिंग का नतीजे के रूप में लौट आना। इसका इलाज सीधा है — हर फ़ील्ड के लिए यह तय हो कि उसका मान किस चीज़ से बनेगा, और किसी भी ऐसे मान को अमान्य माना जाए जो किसी निर्देश जैसा दिखे। एक साधारण जाँच काफ़ी है: अगर किसी फ़ील्ड का मान 'identify', 'judge', 'extract' जैसे आदेशवाचक शब्दों से शुरू हो, तो उसे ख़ाली मानिए, भरा हुआ नहीं। अब सवाल यह है कि इससे स्पोर्ट्स न्यूज़रूम को क्या फ़र्क़ पड़ता है। फ़र्क़ यह पड़ता है कि क्रिकेट की ख़बरें समय के सबसे सख़्त दबाव में बनती हैं। एक मैच ख़त्म होता है और अगले कुछ घंटों में स्कोर, मोड़, हार-जीत का कारण, प्रतिक्रियाएँ — सब कुछ तैयार होना चाहिए। ऐसे में अगर पाइपलाइन की पहली मंज़िल ख़ाली लौटती है और कोई उसे पकड़ता नहीं, तो नुक़सान दो तरह का होता है। पहला, वह ख़बर जो आनी चाहिए थी वह देर से आती है या आती ही नहीं। दूसरा, और यह ज़्यादा भारी है, वह ख़बर आ जाती है लेकिन ग़लत ढाँचे में — क्योंकि नीचे का मॉडल ख़ाली इनपुट को अपने अंदाज़ से भर देता है। समय-संवेदनशीलता का मूल्यांकन न होना अपने आप में एक बड़ी चूक है। क्रिकेट में हर लेख समय के हिसाब से एक जैसा नहीं होता। मैच के दौरान की रिपोर्ट की उम्र घंटों में नापी जाती है; किसी खिलाड़ी के करियर पर टिप्पणी की उम्र हफ़्तों या महीनों में; और नियमों या प्रशासन पर बहस की उम्र तो और भी लंबी होती है। अगर सिस्टम यह बताने में नाकाम रहे कि लेख किस श्रेणी में है, तो प्रकाशन का फ़ैसला भी अंधेरे में होगा। एक पुरानी ख़बर को ताज़ा बताकर छापना, और एक ताज़ा ख़बर को पुराना समझकर अनदेखा कर देना — दोनों एक ही जड़ से निकलते हैं। स्रोत की गुणवत्ता का मूल्यांकन न होना भी उतना ही गंभीर है। ढाँचे में स्रोत से जुड़ी कोई जानकारी ही नहीं थी, इसलिए गुणवत्ता का अंदाज़ा लगाने का कोई आधार नहीं था। लेकिन असली दुनिया में यही सबसे ज़रूरी फ़ील्ड है। क्रिकेट की ख़बरें कहाँ से आ रही हैं — आधिकारिक बोर्ड की विज्ञप्ति से, अंतरराष्ट्रीय निकाय के दस्तावेज़ से, किसी अख़बार की रिपोर्ट से, किसी सोशल मीडिया पोस्ट से, या किसी अनाम कमेंट्री से — इन सबका भरोसा एक जैसा नहीं होता। जिस पाइपलाइन को यह पता ही नहीं कि स्रोत क्या है, वह आगे भरोसे का कोई फ़िल्टर नहीं लगा सकती। यहाँ एक बात साफ़ कर लेना ज़रूरी है। क्रिकेट की दुनिया में 'ट्रांसफ़र', 'नियम', 'वित्त', 'सट्टा', 'आँकड़े' और 'मैच' — ये अलग-अलग विषय हैं जिन्हें अलग-अलग तरह की जाँच चाहिए। एक ट्रांसफ़र की ख़बर में यह देखना होता है कि अनुबंध की स्थिति क्या है और दावा किसने किया। एक नियम की ख़बर में यह देखना होता है कि बदलाव लागू कब से होगा और किस निकाय ने मंज़ूर किया। एक आँकड़े की ख़बर में यह देखना होता है कि संख्या किस अवधि की है और उसकी गणना का तरीक़ा क्या है। अगर पहली मंज़िल यही तय नहीं कर पाती कि लेख इनमें से किस क़िस्म का है, तो आगे का हर निष्कर्ष एक ही साँचे में ढाल दिया जाएगा — और वह साँचा ग़लत होगा। इस पूरी घटना में एक व्यवस्थागत सबक़ छिपा है, और वह यह है कि सिस्टम की सबसे बड़ी कमज़ोरी उसके ग़लत जवाब नहीं, बल्कि उसका ख़ाली जवाब है। ग़लत जवाब पकड़ा जा सकता है, क्योंकि उसकी तुलना किसी चीज़ से हो सकती है। ख़ाली जवाब पकड़ा नहीं जाता, क्योंकि वह किसी नियम को तोड़ता नहीं — वह बस होता है। और जब एक पाइपलाइन के कई चरण हों, तो ख़ाली जवाब हर चरण में थोड़ा-थोड़ा भरता जाता है, और अंत में वह एक ऐसा लेख बन जाता है जिसमें हर वाक्य व्याकरण की दृष्टि से सही है और तथ्य की दृष्टि से ख़ाली है। इसीलिए ज़रूरी है कि पाइपलाइन के हर चरण पर यह नापा जाए कि वह कितना भरकर लौटा। सबसे सीधा उपाय है लंबाई का लॉग। क्रॉल किए गए पाठ की लंबाई, निकाले गए सूचना-बिंदुओं की संख्या, भरे गए फ़ील्ड का अनुपात — ये तीन आँकड़े अगर हर लेख के साथ दर्ज हों, तो ऐसी विफलता कभी चुपचाप आगे नहीं बढ़ेगी। दूसरा उपाय है अनुबंध-जाँच। पाइपलाइन के आउटपुट के साथ यह शर्त जोड़ी जाए कि कुछ न्यूनतम फ़ील्ड ख़ाली नहीं हो सकतीं, और उनका ख़ाली होना एक साफ़ विफलता है, न कि चेतावनी-रहित स्वीकृति। तीसरा उपाय, और शायद सबसे ज़रूरी, यह है कि N/A और ख़ाली सूची को एक ही चीज़ न माना जाए। इन दोनों का अर्थ अलग है। N/A का मतलब है कि सिस्टम ने देखा, समझा, और तय किया कि यह जानकारी मौजूद नहीं है या लागू नहीं होती। ख़ाली सूची का मतलब है कि सिस्टम ने खोजा ही नहीं, या खोजा और कुछ नहीं मिला, और उसने यह भी नहीं बताया कि कौन सा मामला है। जब कोड में इन दोनों को एक ही डिफ़ॉल्ट से भर दिया जाता है, तब 'जानकारी नहीं है' और 'जानकारी खोजी ही नहीं गई' में भेद मिट जाता है — और संपादकीय निर्णय के लिए यही भेद सबसे ज़रूरी होता है। इसके साथ एक मानवीय सुरक्षा-कवच भी चाहिए। किसी भी स्वचालित सारांश के सामने यह शर्त रखी जाए कि अगर उससे जुड़े सूचना-बिंदु तीन से कम हैं, तो उसे इंसानी नज़र से गुज़रना ही होगा। यह शर्त काम को धीमा नहीं करती; यह उस तरह की ग़लती को रोकती है जो बाद में सुधारने में कहीं ज़्यादा महँगी पड़ती है। और इसके साथ यह भी तय होना चाहिए कि जब किसी लेख के लिए Stage-1 ख़ाली लौटे, तो उस लेख का प्रकाशन रुके — 'N/A' के सहारे आगे न बढ़े। ज़िम्मेदारी का सवाल भी इसी से जुड़ा है। अगर किसी ख़बर में तथ्य की ग़लती स्वचालित पाइपलाइन से आई है, तो जवाबदेही उस व्यक्ति की होनी चाहिए जिसने उस पाइपलाइन को मंज़ूरी दी और जिसने उस आउटपुट को प्रकाशन के लिए स्वीकार किया। 'मशीन ने किया था' कोई स्पष्टीकरण नहीं है; वह समस्या का हिस्सा है। एक न्यूज़रूम में हर प्रकाशित वाक्य के पीछे कोई नाम होना चाहिए, चाहे वाक्य किसी भी औज़ार से बना हो। अब आगे क्या करना चाहिए, इसका क्रम इस प्रकार बनता है। पहला क़दम: उसी लेख को अलग से एक्सट्रैक्ट करके पाठ की लंबाई नापें। अगर शून्य आए, तो मरम्मत क्रॉलिंग की परत पर करें, मॉडल के प्रॉम्प्ट पर नहीं। दूसरा क़दम: अगर पाठ ठीक आए, तो वर्गीकरण के बाद की शाखाएँ जाँचें और 'Unclassified' के लिए एक सामान्य फ़ॉलबैक जोड़ें। तीसरा क़दम: हर फ़ील्ड के लिए यह तय करें कि उसका मान कहाँ से आता है, और निर्देश-जैसे मानों को अमान्य घोषित करें। चौथा क़दम: तीनों आँकड़े — पाठ की लंबाई, सूचना-बिंदुओं की संख्या, भरे फ़ील्ड का अनुपात — हर लेख के साथ लॉग करें। पाँचवाँ क़दम: ख़ाली Stage-1 पर प्रकाशन रोकने का नियम बनाएँ। इन सबका सार एक वाक्य में यह है कि एक स्पोर्ट्स पाइपलाइन की क़ीमत उसके सबसे अच्छे आउटपुट से नहीं, उसके सबसे ख़ाली आउटपुट से नापी जाती है। क्रिकेट की ख़बरें ऐसी जगह हैं जहाँ ग़लती की गुंजाइश सबसे कम है, क्योंकि वहाँ संख्या, नाम और समय — तीनों ठोस होते हैं और तीनों की जाँच पाठक तुरंत कर सकता है। ऐसे मैदान में एक ऐसा सिस्टम जो 'N/A' को जवाब मानकर आगे बढ़ जाए, वह ख़बर की नहीं, भरोसे की चोरी करता है। और इसलिए उस ख़ाली JSON को हल्के में नहीं लेना चाहिए। वह अपने आप में एक ख़बर है — इस बात की ख़बर कि हमारी मशीनें जब कुछ नहीं जानतीं, तब वे यह कहने के बजाय कि 'मुझे नहीं पता', एक ख़ाली ढाँचा सौंप देती हैं और हम उसे पूरा मान लेते हैं। उस ढाँचे को ठीक करना ज़रूरी है। उससे भी ज़्यादा ज़रूरी है उस आदत को ठीक करना जिसने उसे स्वीकार कर लिया।