खाली डेटासेट की ऑडिट रिपोर्ट: जब शतरंज का क्लासिफायर एक लेबल लेकर आया और बाकी सब N/A था

सोमवार की सुबह मैंने वह फ़ाइल खोली जो पिछले चार दिनों से डेस्कटॉप पर बैठी थी। फ़ाइल का नाम सामान्य था, टाइमस्टैम्प साफ़ था, और स्कीमा उसी टेम्पलेट से आया था जिसे मैं वर्षों से देखता आ रहा हूँ। मैंने पहला फ़ील्ड खोला: Article Title — N/A। दूसरा: Article Source — N/A। तीसरा: One-sentence Summary — खाली। चौथा: Information Points — शीर्षक के नीचे एक भी बुलेट नहीं। मैंने स्क्रॉल नीचे किया। पूरे दस्तावेज़ में एक ही फ़ील्ड भरी हुई थी, और वह शीर्षक नहीं था। वह थी Domain Label: chess।

यह वह क्षण है जब मुझे समझ आया कि मेरे सामने एक मैच की स्कोरशीट नहीं रखी है। मेरे सामने एक स्कोरशीट है जिसमें बोर्ड खाली हैं, खिलाड़ियों के नाम खाली हैं, और सिर्फ़ इतना लिखा है कि खेल शतरंज था। तीन दशकों में मैंने सैकड़ों डेटा रिपोर्ट्स रिकॉन्साइल की हैं — 2026 में द हिंदू के सब-एडिटर डेस्क से लेकर 2026 की उस SQLite फ़ाइल तक जिसमें मैंने 11,400 जूनियर गेम्स हाथ से टैग किए थे। और हर बार एक ही नियम लागू हुआ है: जिस पंक्ति में नाम नहीं, उस पंक्ति पर वोट नहीं।

वह फ़ाइल जिसने खुद को लेबल कर दिया

जब खेल का नाम ही एकमात्र गवाह बचता है

Stage-1 के इस आउटपुट में एक विशेषता है जिसे मैं कम आँकता था और अब ज़्यादा गंभीरता से देखता हूँ: यह झूठ नहीं बोलता, लेकिन यह सच भी नहीं बताता। यह एक ऐसा फ़ॉर्म है जिसे सही ढंग से भरा गया है और जिसमें भरने के लिए कुछ नहीं है। टेम्पलेट पूरा है — Article Title, Article Source, Article Type, One-sentence Summary, Author Stance, Article Purpose, Information Points, Domain Label — सब जगह हैं। लेकिन उन जगहों के अंदर वे मान नहीं हैं जो किसी लेख को लेख बनाते हैं।

मैंने इसे तीन बार पढ़ा। मुझे यह देखने की आदत है कि कौन सा फ़ील्ड सबसे पहले टूटता है। यहाँ जवाब साफ़ था: information_points। यह वह फ़ील्ड है जिस पर बाकी सब टिका है। Article Type उसी से तय होता है। Author Stance उसी से निकलता है। Source Quality का फ़ैसला उसी के आधार पर होता है। जब वह खाली है, तो बाकी सारे फ़ील्ड अपनी जगह पर खड़े रहते हैं, लेकिन उनके पैर ज़मीन पर नहीं होते।

चार नाम जो असल में एक ही सवाल हैं

Article Title, Article Source, Article Type और One-sentence Summary — इन चारों का N/A होना अलग-अलग विफलताएँ नहीं हैं। ये एक ही विफलता के चार चेहरे हैं। अगर स्टेज-1 को टेक्स्ट मिला ही नहीं, तो शीर्षक कहाँ से आता? अगर टेक्स्ट मिला लेकिन पार्स नहीं हो पाया, तो सारांश कहाँ से आता? अगर सारांश नहीं बना, तो Article Type की गणना का आधार क्या बचा?

यह वही तर्क है जो मैं ट्रांसफ़र मार्केट की रिपोर्ट्स पर लगाता हूँ जब कोई क्लब "interest" की खबर देता है पर फ़ीस, क्लॉज़ और तारीख़ तीनों गायब होते हैं। मैं उस खबर को झूठ नहीं कहता। मैं उसे अधूरी नहीं कहता। मैं कहता हूँ: यह एक शीर्षक है जिसमें संख्या नहीं है, और संख्या के बिना शीर्षक क्लिक है, सौदा नहीं।

N/A और खाली के बीच का फ़र्क़

एक तकनीकी बारीकी है जिसे मैं मीडिया से आने वाले लोग अक्सर नज़रअंदाज़ करते हैं। N/A का मतलब है — यह फ़ील्ड इस दस्तावेज़ पर लागू नहीं है। और खाली का मतलब है — यह फ़ील्ड लागू है, लेकिन मान नहीं भरा गया। ये दोनों एक नहीं हैं, और इनका इलाज भी एक नहीं है। अगर Article Source इसलिए N/A है क्योंकि डेटा किसी अख़बार से नहीं आया था, तो वह सही व्यवहार है। लेकिन अगर वह इसलिए N/A है क्योंकि स्टेज-1 खुद क्रैश हुआ और टेम्पलेट ने डिफ़ॉल्ट वैल्यू डाल दी, तो वह एक व्यवहार्य त्रुटि नहीं, एक छिपी हुई विफलता है।

एक बिंदु पर टिका हुआ पूरा ढाँचा

်ု်ြ်း की विफलता और फेल-फास्ट का अभाव

Stage-1 के Additional Notes में दो पंक्तियाँ हैं जो मुझे सबसे ज़्यादा परेशान करती हैं:

- Entities Involved: identify from the information points above - Source Quality: judge from the source fields of the information points

इन दोनों को मैंने तीन बार पढ़ा। ये निर्देश हैं, निष्कर्ष नहीं। और ये उस "information points above" की ओर इशारा करते हैं जो मौजूद ही नहीं है। यह एक ऐसा निर्देश है जिसे निष्पादित नहीं किया जा सकता, क्योंकि उसका इनपुट ही गायब है। मुझे यह उस फ़ाइल की याद दिलाता है जिसे मैंने 2026 में FIDE Online Olympiad के लिए बनाया था — एक फ़ेयर-प्ले स्क्रीनिंग लेयर। मेरे मॉडल ने एक 15 वर्षीय लड़की की पंद्रह-चाल की जीत को इंजन-मैच आउटलायर के रूप में फ़्लैग किया था। मैंने साइन ऑफ़ करने से इनकार कर दिया, गेम दोबारा चलाया, एक ज्ञात ओपनिंग ट्रैप मिला, और एक false positive दर्ज किया। उस स्क्रीन का पाठ यही था: जब मॉडल कहे कि उसने कुछ देखा है, तो पहले पूछो कि उसने कहाँ देखा।

डेटा मॉन्क की रस्सी बनाम टेम्पलेट की जंज़ीर

डेटा मॉन्क की मेरी परिभाषा बहुत साधारण है: संरचना का मालिक डेटा होता है, टेम्पलेट नहीं। मैं तीन दशकों से शतरंज की रिपोर्टिंग में यही करता आया हूँ। 2026 में जब मैंने 2026–2026 के भारतीय आयु-वर्ग राष्ट्रीय Games को स्क्रैप किया, तो मैंने पहले 11,400 गेम्स को हाथ से टैग किया, हर पोज़ीशन को एंडगेम टाइप से कोड किया, और उसके बाद क्वेरी चलाई। क्वेरी ने एक आउटलायर निकाला — चेन्नई का एक 11 वर्षीय बच्चा, R. Praggnanandhaa, जो आयु-वर्ग साथियों के ख़िलाफ़ रूक-एंड-पॉन एंडगेम्स का 81 प्रतिशत कन्वर्ट कर रहा था, जबकि फ़ील्ड का बेसलाइन 46 प्रतिशत था। मैंने वह टेबल ChessBase India के Sagar Shah को भेजी। क्लिप 400,000 व्यूज़ से ऊपर गया, और वह चैनल मेरा स्थायी डिस्ट्रिब्यूशन पार्टनर बन गया।

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

एक फ़ील्ड जो पूरी कहानी बताता है

Domain Label: chess। यह साफ़ है, यह सुसंगत है, यह एक वैध मान है। और यह इस दस्तावेज़ की एकमात्र जानकारी है। समस्या यह है कि यह इतनी कम जानकारी है कि इससे लगभग कुछ भी निकाला नहीं जा सकता। यह नहीं बताता कि लेख ओपनिंग थ्योरी पर था या एंडगेम टेक्नीक पर, यह नहीं बताता कि यह एक टूर्नामेंट रिपोर्ट थी या AI गेमिंग का विश्लेषण, यह नहीं बताता कि यह कोई कोचिंग मैनुअल था या किसी खिलाड़ी का प्रोफ़ाइल।

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

जब ऑडिट टोन ही एक ट्रैप बन जाए

तीन दशकों की मेरी सबसे बड़ी चूक

मुझे यह लिखते हुए एक बात साफ़ करनी है, क्योंकि मैं हर लेख में अपनी error rate पहले पब्लिश करता हूँ। मेरी सबसे बड़ी पेशेवर चूक denominator paralysis है — हर दावे को इतना क्वालिफ़ाई कर देना कि अंत में लेख कुछ भी दावा न करे। मैंने इसे अपने करियर में कई बार किया है। "Promising youngster" लिखने से पहले मैं सैंपल साइज़, प्रतिद्वंद्वियों की रेटिंग, और बेसलाइन माँगता हूँ, और अक्सर वह लेख उस बिंदु पर पहुँचकर रुक जाता है जहाँ से आगे बढ़ना चाहिए था।

लेकिन यहाँ एक फ़र्क़ है जिसे मैं रेखांकित करना चाहता हूँ। Denominator paralysis तब होती है जब डेटा मौजूद होता है और हम उसे ज़रूरत से ज़्यादा क्वालिफ़ाई कर देते हैं। यहाँ डेटा मौजूद ही नहीं है। यह अलग बीमारी है। इसे मैं "empty-frame syndrome" कहता हूँ — जब पाइपलाइन एक ऐसा दस्तावेज़ पैदा करती है जो प्रक्रियात्मक रूप से पूरा है और सामग्री के स्तर पर शून्य है, तो उसे पढ़ने वाले को यह नहीं पता चलता कि उसे कहाँ रुकना चाहिए। वह उस खालीपन को भरने लगता है। और भरने वाला हमेशा खुद लेखक होता है।

सबसे अच्छी रिपोर्ट वह है जो कहे: मैं नहीं जानती

मेरे पास एक नियम है जो मैंने 2026 के false positive के बाद लिखा था और तब से हर मॉडल रिपोर्ट पर लगाता हूँ: "Screen flagged, review cleared" — स्क्रीन ने फ़्लैग किया, समीक्षा ने साफ़ किया। इसका विस्तार यह है: जब टेम्पलेट भरा नहीं जा सकता, तो टेम्पलेट को भरा हुआ नहीं दिखना चाहिए। उसे यह कहना चाहिए — status: extraction_failed। यह कोई शर्म की बात नहीं है। यह एक ईमानदार स्थिति है। मैंने दो बार ऐसी कहानियाँ मार दी हैं जो मैं लिखना चाहता था, क्योंकि false-positive काउंट सिग्नल से बड़ा निकला। यही अनुशासन यहाँ चाहिए।

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

फ़ेल-फास्ट क्यों ज़रूरी है — और क्यों कोई इसे नहीं लगाता

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

लेकिन शतरंज ने मुझे एक चीज़ सिखाई है जो किसी और खेल ने नहीं सिखाई। एक ऐसी पोज़ीशन जहाँ आपके पास कोई अच्छी चाल नहीं है, वहाँ सबसे अच्छी चाल यह स्वीकार करना है कि आपके पास कोई अच्छी चाल नहीं है। मैंने 2026 के Tata Steel Chess India रैपिड में हर गेम लॉग करते हुए एक Conversion Index बनाया था — यह मापने के लिए कि plus-1.20 इंजन एडवांटेज रैपिड टाइम कंट्रोल में कितनी बार असल में जीत बनता है। जवाब था 58 प्रतिशत। यह संख्या मुझे इसलिए पसंद है क्योंकि यह ईमानदार है। यह नहीं कहती कि हर बढ़त जीत बनती है। यह कहती है कि दो में से एक बार नहीं बनती। उसी तरह, Stage-1 को यह कहना चाहिए: मैंने आपको एक लेबल दिया, और बाकी कुछ नहीं दिया, क्योंकि मेरे पास बाकी कुछ नहीं था।

न्यूनतम इनपुट की सूची और अगला क़दम

चार चीज़ें जो इस फ़ाइल को ज़िंदा कर सकती हैं

अगर इस विश्लेषण को आगे बढ़ाना है, तो मुझे चार चीज़ें चाहिए, और मैं उन्हें प्राथमिकता के क्रम में रख रहा हूँ। पहली और सबसे महत्वपूर्ण — मूल पाठ या उसका सारांश। इसके बिना बाकी सब दूसरे हाथ की जानकारी है, और दूसरे हाथ की जानकारी पर मैं कभी भरोसा नहीं करता। दूसरी — Article Source और प्रकाशन तिथि। यह विश्वसनीयता और समयसीमा दोनों तय करती है, और तिथि के बिना कोई भी दावा "हाल ही में" की श्रेणी में गिर जाता है, जो एक ऐसी श्रेणी है जिसे मैं अपनी रिपोर्टिंग में इस्तेमाल नहीं करता।

तीसरी — Information Points की असली प्रविष्टियाँ, कम से कम पाँच से दस, हर एक में स्रोत के साथ। यह वह ईंटें हैं जिनसे इमारत बनती है। चौथी — Domain Label का कॉन्फ़िडेंस स्कोर, और यह जानकारी कि chess मुख्य लेबल है या एकमात्र। अगर यह एकमात्र है और उसका कॉन्फ़िडेंस कम है, तो बहुत संभव है कि यह मिसक्लासिफिकेशन हो — शायद मूल पाठ गणित या शतरंज-जैसे पहेली-आधारित सामग्री थी, और क्लासिफायर ने उसे शतरंज समझ लिया।

जब सामग्री आ जाए, तो मैं क्या करूँगा

इन चार इनपुट्स के आने के बाद मैं एक सुस्थापित ढाँचे पर काम करूँगा: मूल थीसिस → तर्क-श्रृंखला और साक्ष्य की ताक़त → छिपी हुई धारणाएँ और अनकहे पक्षपात → क्षेत्र की मुख्यधारा की राय से मतभेद के बिंदु → झूठे साबित होने की क्षमता और प्रति-उदाहरण → निष्कर्ष की प्रयोज्यता की सीमाएँ। यह वही ढाँचा है जिस पर मैंने 2026 से हर स्काउटिंग रिपोर्ट बनाई है, और यह वही है जिसने मुझे यह विश्वास दिलाया कि एक ऐसा वाक्य लिखना बेहतर है जो उबाऊ हो पर सच हो, बजाय उस वाक्य के जो उत्तेजक हो पर असत्यापनीय हो।

खाली स्कोरशीट पर टिप्पणी नहीं लिखी जाती

मैं यहाँ एक बात साफ़ कर देना चाहता हूँ, क्योंकि यह मेरी पेशेवर नैतिकता का हिस्सा है। इस फ़ाइल पर मैं कोई अनुमानित विश्लेषण नहीं लिखूँगा। मैं यह नहीं कहूँगा कि "हो सकता है यह लेख किसी भारतीय ग्रैंडमास्टर के उभरने के बारे में था" — क्योंकि वह मेरा लेख होगा, उस अज्ञात मूल पाठ का नहीं। मैं यह भी नहीं कहूँगा कि "शतरंज में डेटा विश्लेषण का दौर आ रहा है" — क्योंकि वह मेरी राय है, विश्लेषण नहीं।

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

अगली कड़ी का संकेत

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