Text-to-SQL में "रिकॉर्ड्स" के खतरे
हर महीने नई घोषणाएँ आती हैं कि किसी और LLM ने SQL बेंचमार्क पर लगभग इंसानों की बराबरी कर ली है। लेकिन अगर ध्यान से देखें, तो इन आंकड़ों के पीछे बहुत अलग-अलग स्थितियाँ छिपी होती हैं: कोई डेटाबेस तक पहुँच के बिना एक साधारण प्रॉम्प्ट का उपयोग करता है, कोई मॉडल को पुनरावृत्तियों में क्वेरी चलाने की अनुमति देता है, और किसी ने तर्क को सीधे मॉडल के वज़न में ही डाल दिया है। ऐसे परिणामों की सीधे तुलना करना एक मैकेनिक वाली कार और एक सेल्फ-ड्राइविंग कार को एक साथ रखने जैसा है, जो चलते समय खुद की मरम्मत कर लेती है।
arXiv पर हालिया प्रीप्रिंट (2608.15389) के लेखकों ने ठीक इसी समस्या पर ध्यान आकर्षित किया है। वे सुझाव देते हैं कि लीडरबोर्ड में अमूर्त ऊँचाई से 'प्रगति' को मापना बंद कर देना चाहिए, बल्कि पहले ईमानदारी से यह दर्ज करना चाहिए कि SQL जनरेट करते समय सिस्टम के पास कितनी स्वायत्तता थी। इस तरह की स्पष्टता के बिना, विभिन्न कार्यों के बीच कोई भी तुलना अस्थिर हो जाती है: बेंचमार्क, बेस मॉडल या यहाँ तक कि इन्फ़रेंस प्रोटोकॉल में थोड़ा सा बदलाव निष्कर्षों को बदल सकता है।
स्वायत्तता की धुरी: प्रॉम्प्ट से लेकर आत्मनिर्भर एजेंटों तक
सभी आंकड़ों को एक तालिका में इकट्ठा करने के बजाय, शोधकर्ता Text-to-SQL के क्षेत्र को ही 'लीडरबोर्ड एग्रीगेशन' के रूप में फिर से परिभाषित करते हैं। वे उन मेट्रिक्स को इकट्ठा करते हैं जिन्हें सिस्टम के लेखक स्वयं रिपोर्ट करते हैं, और उन्हें इन्फ़रेंस की स्वायत्तता की धुरी के साथ व्यवस्थित करते हैं। इससे पाँच स्तर बनते हैं:
- Constrained generation — मॉडल केवल स्वीकार्य क्वेरीज़ के कड़ाई से सीमित स्थान से उत्तर चुनता है, अक्सर बाहरी सिंटैक्स जाँच के साथ।
- In-context generation — SQL उदाहरणों और स्कीमा विवरण के साथ संदर्भ के एक ही पास में बनाया जाता है।
- Iterative generation — सिस्टम कई प्रयास कर सकता है, निष्पादन के परिणामों या DBMS की प्रतिक्रिया के आधार पर क्वेरी को परिष्कृत करता है।
- Agentic generation — मॉडल एक एजेंट की तरह काम करता है: वह स्वयं डेटाबेस स्कीमा का पता लगाता है, क्वेरी चलाता है, त्रुटियों पर प्रतिक्रिया करता है और अगले चरणों की योजना बनाता है।
- Reasoning-internalized generation — 'तर्क' पहले से मॉडल में अंतर्निहित होता है, इसलिए इन्फ़रेंस पर यह बिना किसी बाहरी ऑर्केस्ट्रेशन या मध्यवर्ती चरणों के सीधे क्वेरी उत्पन्न करता है।
ऐसा पैमाना यह नहीं कहता कि एक स्तर दूसरे से 'बेहतर' है। यह केवल निष्पक्ष तुलना की शर्तों को दर्ज करता है: आंतरिक reasoning वाले सिस्टम की तुलना सीधे सिंगल-शॉट आउटपुट से नहीं की जा सकती, ठीक वैसे ही जैसे क्वेरी चलाने के अधिकार वाले एजेंटिक लूप की तुलना उस मॉडल से नहीं की जानी चाहिए जिसे यह अधिकार नहीं दिया गया था।
महत्वपूर्ण बात यह है कि ऐसे लीडरबोर्ड के प्रत्येक सेल के लिए मेट्रिक की उत्पत्ति का पता लगाया जा सकता है। इसका मतलब है कि पाठक हमेशा समझ सकता है कि किस विशेष कॉन्फ़िगरेशन ने परिणाम दिया, न कि प्रयोगात्मक अनुभाग के टुकड़ों से अनुमान लगाने की कोशिश करे।
Spider और उसके बाहर के प्रयोग ने क्या दिखाया
मेट्रिक एग्रीगेशन को वास्तविकता से जोड़ने के लिए, लेखकों ने Spider बेंचमार्क पर एक लक्षित अध्ययन किया। उन्होंने CoT-पर्यवेक्षण के साथ और बिना, खुले 8B-मॉडल की तुलना DeepSeek V3 और GLM-4 पर आधारित फ्यू-शॉट बेसलाइन से की। दिलचस्प बात यह है कि पूरी तरह से फाइन-ट्यून किए गए संस्करणों के बजाय फ्यू-शॉट प्रोटोकॉल का उपयोग किया गया था, इसलिए तुलना काफी स्वच्छ रही।
प्रयोग से चार पैटर्न सामने आते हैं जो व्यवसायियों के लिए महत्वपूर्ण हैं।
पहला, Spider पर प्राप्त सुधार BIRD और Spider 2.0 पर असमान रूप से स्थानांतरित होते हैं। एक मॉडल क्वेरीज़ के एक सेट पर अच्छी वृद्धि दिखा सकता है और दूसरे पर लगभग स्थिर रह सकता है। यह एक बार फिर पुष्टि करता है: एक लोकप्रिय बेंचमार्क पर एकल स्कोर का अंधा पीछा सामान्य प्रगति का भ्रम पैदा करता है।
दूसरा, स्वायत्तता स्थिरता जोड़ती है, लेकिन एक गैर-तुच्छ कीमत पर। एजेंटिक लूप वास्तव में बहु-चरणीय और अस्पष्ट कार्यों को बेहतर ढंग से संभालते हैं, हालाँकि टोकन और निष्पादन समय की लागत काफी बढ़ जाती है। यदि एक इंटरैक्टिव विश्लेषक के लिए यह कीमत उचित है, तो बैच प्रोसेसिंग के लिए यह कम त्रुटियों से होने वाले सभी लाभ को खा सकती है।
तीसरा, reasoning internalized मोड अप्रत्याशित रूप से मध्य स्थान लेता है। यह बिना तर्क के 'बिना सोचे' उत्तर डिकोडिंग और बाहरी रूप से ऑर्केस्ट्रेटेड एजेंटों के बीच आता है। कई कार्यों के लिए, यह मोड लगभग एजेंट-गुणवत्ता देता है, लेकिन टूल्स के साथ एक जटिल लूप बनाने की आवश्यकता के बिना। हालाँकि, कोई सार्वभौमिक 'फ्री लंच' नहीं मिलता: अंतर्निहित तर्क की भी अपनी सीमाएँ हैं।
चौथा, CoT-पर्यवेक्षण से लाभ Hard और Extra-Hard स्तर की क्वेरीज़ पर केंद्रित होते हैं। सरल प्रश्नों पर अंतर लगभग अदृश्य या नकारात्मक भी होता है — मॉडल को ज़ोर से तर्क करने की आवश्यकता क्यों है जब उत्तर तुरंत दिखाई देता है? लेकिन जटिल बहु-चरणीय कार्यों पर, चरणों को ज़ोर से बोलने की क्षमता एक उल्लेखनीय लाभ देती है। यह SQL-सहायक बनाने वालों के लिए एक महत्वपूर्ण संकेत है: अतिरिक्त कम्प्यूटेशनल शक्ति को उच्च जटिलता वाली क्वेरीज़ पर केंद्रित करना चाहिए, न कि सामान्य सरल मामलों पर बर्बाद करना चाहिए।
इस पैमाने का व्यवहार में उपयोग कैसे करें
काम का सबसे उपयोगी परिणाम — स्वयं वर्गीकरण भी नहीं, बल्कि सार्वजनिक Python हार्नेस है, जिसे लेखकों ने प्रीप्रिंट के साथ जारी किया है। हार्नेस स्वायत्तता की धुरी को पुन: पेश करता है और पूरे वातावरण को फिर से लिखे बिना लीडरबोर्ड में नए तरीकों को जोड़ने की अनुमति देता है। यदि आप एक और Text-to-SQL दृष्टिकोण विकसित कर रहे हैं, तो यह बताना पर्याप्त है कि यह स्वायत्तता के किस स्तर पर काम करता है — और समुदाय आपकी तुलना पिछली प्रणालियों से समान रूप से कर सकेगा।
यह स्पष्ट है कि स्व-रिपोर्ट किए गए मेट्रिक्स पर आधारित एग्रीगेशन पर अभी भी सावधानी से भरोसा किया जाना चाहिए। हर किसी के पास दूसरों के प्रयोगों को दोहराने का बजट नहीं है, लेकिन एक समान एनोटेशन पहले से ही एक बड़ा कदम आगे है। अभी के लिए, अगला 'state-of-the-art' पढ़ते समय एक सरल प्रश्न ध्यान में रखें: क्वेरी जनरेट करते समय मॉडल वास्तव में क्या कर सकता था? यदि इस प्रश्न का उत्तर अनुपस्थित है, तो पेपर का आंकड़ा केवल एक सुंदर संख्या है जिसका कोई ठोस आधार नहीं है।
