💬 NLP

Both Ends Count! Just How Good are LLM Agents at "Text-to-Big SQL"?

यह शोध पत्र उत्पादन-स्तर के LLM एजेंटों के मूल्यांकन में मौजूदा बेंचमार्क की सीमाओं को संबोधित करने के लिए नवीन "Text-to-Big SQL" मूल्यांकन मेट्रिक्स प्रस्तुत करता है, जो यह प्रदर्शित करता है कि पारंपरिक Text-to-SQL मेट्रिक्स उन महत्वपूर्ण लागत, विलंबता (latency) और दक्षता संबंधी निहितार्थों को पकड़ने में विफल रहते हैं जो बड़े डेटासेट तक स्केल करने पर उत्पन्न होते हैं।

मूल लेखक: Germán T. Eizaguirre, Lars Tissen, Marc Sánchez-Artigas

प्रकाशित 2026-03-09

📖 6 मिनट में पढ़ें🧠 गहराई से पढ़ें

CC BY 4.0

मूल लेखक: Germán T. Eizaguirre, Lars Tissen, Marc Sánchez-Artigas

मूल पेपर CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। ✨ नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने न तो लिखा है, न इसका समर्थन किया है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें

कल्पना कीजिए कि आप एक शेफ (AI एजेंट) हैं जो ग्राहक के ऑर्डर के आधार पर भोजन बनाने की कोशिश कर रहे हैं (जो कि एक Text-to-SQL समस्या है)।

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

लेकिन वास्तविक दुनिया में, बड़े रेस्टोरेंट (जैसे Big Data सिस्टम) को केवल स्वाद की परवाह नहीं होती। उन्हें सामग्री की लागत, खाना पकाने में लगने वाला समय, और उत्पन्न होने वाले कचरे (वेस्ट) की भी परवाह होती है।

यह पेपर, जिसका शीर्षक "Both Ends Count!" है, यह तर्क देता है कि हम AI शेफों का परीक्षण गलत नियमों के साथ कर रहे हैं। यहाँ इसका सरल शब्दों में विवरण दिया गया है:

1. समस्या: "छोटा बर्तन" बनाम "औद्योगिक कड़ाही"

अतीत में, AI का परीक्षण छोटे डेटाबेस (जैसे घर की रसोई का सामान) पर किया जाता था। यदि कोई AI SQL क्वेरी (खाना पकाने का निर्देश) लिखता था जो थोड़ी सी गलत थी, तो उसे ठीक करने में बस एक सेकंड लग जाता था। यह सस्ता और तेज़ था।

लेकिन आज, कंपनियाँ Big Data (विशाल औद्योगिक कड़ाही) का उपयोग करती हैं।

गलती की लागत: यदि कोई AI एक ऐसी क्वेरी लिखता है जो एक विशाल सिस्टम में गलत डेटा को स्कैन करती है, तो यह केवल एक सेकंड नहीं लेता; इसमें घंटों लग सकते हैं और क्लाउड कंप्यूटिंग शुल्क के रूप में सैकड़ों डॉलर खर्च हो सकते हैं।
"अतिरिक्त सामग्री" का मुद्दा: यदि कोई AI एक ऐसा अतिरिक्त कॉलम जोड़ देता है जिसकी आवश्यकता नहीं है, तो एक छोटा सिस्टम इसे अनदेखा कर देता है। लेकिन एक विशाल सिस्टम में, वह अतिरिक्त कॉलम अनावश्यक डेटा के गीगाबाइट्स को स्कैन करने का अर्थ है, जिससे पैसा और समय बर्बाद होता है।

उपमा (Analogy):
कल्पना कीजिए कि आप एक रोबोट से कहते हैं "मुझे सेब की कीमत बताओ।"

छोटा सिस्टम: रोबोट गलती से संतरों की कीमत भी लिख देता है। आप बस संतरों को अनदेखा कर देते हैं। कोई बड़ी बात नहीं।
बड़ा सिस्टम: रोबोट को सेब की कीमत देखने के लिए 1,000 मील दूर एक गोदाम तक ट्रक चलाकर जाना पड़ता है। यदि वह सेब और संतरे दोनों को चेक करता है, तो वह दोगुना ईंधन जलाता है। गलती केवल "गलत" नहीं है; यह महंगी है।

2. नया समाधान: "Text-to-Big SQL"

लेखकों का कहना है कि हमें इन AI शेफों को ग्रेड करने का एक नया तरीका चाहिए। वे इसे "Text-to-Big SQL" कहते हैं। केवल यह पूछने के बजाय कि "क्या उत्तर सही है?", वे पूछते हैं:

इसकी लागत कितनी थी? (क्या रोबोट ने अनावश्यक रूप से ट्रक चलाया?)
इसमें कितना समय लगा? (क्या रोबोट ने खाना शुरू करने से पहले 10 मिनट सोचने में बिताए?)
क्या यह कुशल था? (क्या वह वह अतिरिक्त सामान लेकर आया जिसकी हमें ज़रूरत नहीं थी?)

उन्होंने नए "रिपोर्ट कार्ड" (मेट्रिक्स) बनाए जिन्हें VES* और VCES कहा जाता है।

पुराना रिपोर्ट कार्ड: "पास/फेल।" (क्या आपको सही उत्तर मिला?)
नया रिपोर्ट कार्ड: "पास/फेल + लागत + गति।" (क्या आपको सही उत्तर मिला, और क्या आपने बजट जलाए बिना इसे किया?)

3. उन्होंने क्या पाया (ट्विस्ट)

शोधकर्ताओं ने दुनिया के सबसे स्मार्ट AI मॉडल (जैसे GPT-4o, Claude Opus, और Gemini) का इन नए नियमों का उपयोग करके परीक्षण किया। यहाँ उनकी खोज है:

सटीकता एक जाल है (Accuracy is a Trap): कुछ मॉडल सही उत्तर पाने में "परफेक्ट" थे लेकिन इसके बारे में सोचने में उन्हें 10 गुना अधिक समय लगा। बिग डेटा की दुनिया में, 100% सटीक होना लेकिन धीमा होना वास्तव में एक विफलता है क्योंकि आपने पैसा बर्बाद करने के लिए समय गंवा दिया।
"तेज़ और सस्ता" विजेता: कुछ मॉडल थोड़े कम सटीक थे लेकिन बहुत तेज़ और सस्ते थे। वास्तविक दुनिया में, ये वास्तव में बेहतर विकल्प हो सकते हैं क्योंकि यदि वे गलत होते हैं, तो आप एक धीमी, महंगी रन के लिए भुगतान करने के बजाय उन्हें दो बार चलाने का खर्च उठा सकते हैं।
"सोचने" की बाधा (The "Thinking" Bottleneck): AI क्वेरी चलाने से पहले बहुत समय "सोचने" (reasoning) और अपने टूल्स से बात करने में बिता देता है। बिग डेटा में, यदि AI क्वेरी चलाने के लिए कंप्यूटर द्वारा लिए जाने वाले समय से अधिक समय "सोचने" में लेता है, तो पूरा सिस्टम ही टूट जाता है।

4. "स्केल" का प्रभाव

पेपर दिखाता है कि जैसे-जैसे डेटा बड़ा होता है, दांव (stakes) ऊंचे होते जाते हैं।

छोटा डेटा: AI की 10% त्रुटि दर कष्टप्रद है।
विशाल डेटा: वही 10% त्रुटि दर एक वित्तीय आपदा बन जाती है। यदि AI 10 में से 1 बार विफल होता है, और प्रत्येक विफलता $100 की है, तो आप पैसा लुटा रहे हैं।

शोधकर्ताओं ने पाया कि मानक परीक्षण इस बात को पूरी तरह से मिस कर देते हैं। वे एक फॉर्मूला 1 कार का परीक्षण इस आधार पर करने जैसे हैं कि वह पार्किंग लॉट में कितनी अच्छी तरह चलती है। सिर्फ इसलिए कि वह पार्किंग लॉट में काम करती है, इसका मतलब यह नहीं है कि वह हाईवे पर दुर्घटनाग्रस्त नहीं होगी।

सारांश: मुख्य निष्कर्ष (Takeaway)

यह पेपर एक चेतावनी है। हम AI को गणित का टेस्ट देने वाले छात्र की तरह देख रहे हैं (सही या गलत)। लेकिन बिग डेटा की वास्तविक दुनिया में, AI एक लॉजिस्टिक्स मैनेजर की तरह है।

पुराना तरीका: "क्या आपने पैकेज डिलीवर किया?" (हाँ/नहीं)
नया तरीका: "क्या आपने पैकेज डिलीवर किया, क्या आपने सबसे ईंधन-कुशल मार्ग का उपयोग किया, और क्या आप बजट जलाए बिना समय पर पहुँचे?"

लेखकों का तर्क है कि बिग बिजनेस के लिए AI को उपयोगी बनाने के लिए, हमें उन्हें "परफेक्ट उत्तरों" पर ग्रेड करना बंद करना होगा और दक्षता (efficiency), लागत और गति पर ग्रेड करना शुरू करना होगा। यदि एक AI 90% सटीक है लेकिन आपके 50% पैसे बचाता है, तो वह उस शेफ से बेहतर है जो 100% सटीक है लेकिन रसोई को दिवालिया कर देता है।

यहाँ शोध पत्र "Both Ends Count! Just How Good are LLM Agents at Text-to-'Big SQL'?" का विस्तृत तकनीकी सारांश दिया गया है:

1. समस्या का विवरण (Problem Statement)

यह शोध पत्र Big Data वातावरण में तैनात Text-to-SQL प्रणालियों के मूल्यांकन में एक महत्वपूर्ण अंतर को संबोधित करता है। हालाँकि Text-to-SQL एक परिपक्व क्षेत्र है जिसमें व्यापक बेंचमार्क (जैसे, Spider, BIRD) मौजूद हैं, ये बेंचमार्क मुख्य रूप से मध्यम डेटा स्केल वाले पारंपरिक रिलेशनल डेटाबेस पर ध्यान केंद्रित करते हैं। वे अत्यधिक बाइनरी शुद्धता मेट्रिक्स (Exact Match, Execution Accuracy) पर निर्भर करते हैं जो "गोल्डन" SQL क्वेरी से किसी भी विचलन को पूर्ण विफलता मानते हैं।

Big Data संदर्भों में (जैसे, Amazon Athena, Spark, BigQuery), यह मूल्यांकन प्रतिमान अपर्याप्त है क्योंकि:

लागत प्रवर्धन (Cost Amplification): एक मामूली अनुवाद त्रुटि (जैसे, एक अनावश्यक कॉलम चुनना) जो छोटे डेटासेट पर नगण्य है, टेराबाइट्स डेटा को स्कैन करने पर भारी कंप्यूट लागत और विलंबता (latency) का परिणाम दे सकती है।
विलंबता संवेदनशीलता (Latency Sensitivity): इंटरैक्टिव एनालिटिक्स में, LLM एजेंट द्वारा तर्क करने, टूल्स को ऑर्केस्ट्रेट करने और SQL उत्पन्न करने में लगने वाले समय को भौतिक क्वेरी निष्पादन समय (physical query execution time) के साथ संतुलित किया जाना चाहिए। यदि जनरेशन बहुत धीमा है, तो सिस्टम अव्यावहारिक हो जाता है।
आंशिक शुद्धता (Partial Correctness): पारंपरिक मेट्रिक्स उन क्वेरीज़ को दंडित करते हैं जो सही परिणाम तो देती हैं लेकिन अतिरिक्त कॉलम के साथ। Big Data में, एक उपयोगकर्ता अक्सर ऐसे कॉलम को मैन्युअल रूप से हटा सकता है, जिससे ऐसी क्वेरीज़ "आंशिक रूप से वैध" लेकिन महंगी हो जाती हैं।

लेखक तर्क देते हैं कि मौजूदा मेट्रिक्स स्केल पर सटीकता (accuracy), विलंबता (latency), और लागत (cost) के बीच के ट्रेड-ऑफ को पकड़ने में विफल रहते हैं, जिससे एक नया प्रतिमान जन्म लेता है जिसे वे "Text-to-Big SQL" कहते हैं।

2. कार्यप्रणाली (Methodology)

लेखक एक नया मूल्यांकन ढांचा प्रस्तावित करते हैं जो SQL जनरेशन (एजेंट का तर्क) और SQL निष्पादन (Big Data इंजन का प्रदर्शन) दोनों को प्रथम श्रेणी के नागरिक (first-class citizens) के रूप में मानता है।

A. एजेंट आर्किटेक्चर (Agent Architecture)

फ्रेमवर्क: वे LangGraph पर निर्मित एक ReAct (Reasoning + Acting) एजेंट आर्किटेक्चर का उपयोग करते हैं।
घटक (Components):
- कंट्रोलर (Controller): एक LLM जो कार्य के बारे में तर्क करता है, टूल के उपयोग का निर्णय लेता है, और अंतिम SQL उत्पन्न करता है।
- एक्सेक्यूटर (Executor): बाहरी टूल्स के साथ इंटरेक्शन लूप का प्रबंधन करता है।
- टूल्स (Tools): Spark SQL के लिए चार विशिष्ट टूल्स: list_tables, get_schema, check_query (सिंटैक्स वैलिडेशन), और run_query|
बाधाएं (Constraints): अनंत लूप और अत्यधिक बिलिंग लागत को रोकने के लिए एजेंट को पहले run_query निष्पादन के बाद समाप्त कर दिया जाता है, जो बिना इटरेटिव सेल्फ-करेक्शन लूप के एक "जीरो-शॉट" प्रोडक्शन परिदृश्य का अनुकरण करता है।

B. डेटासेट और मॉडल (Datasets and Models)

बेंचमार्क:
- BIRD: वास्तविक डेटाबेस पर ट्रांसलेशन सटीकता का मूल्यांकन करने के लिए उपयोग किया गया।
- TPC-H: Big Data विकास को सिम्युलेट करने के लिए विभिन्न स्केल फैक्टर्स (SF) (10, 100, 1000) के माध्यम से प्रदर्शन का मूल्यांकन करने के लिए उपयोग किया गया।
मॉडल: एक विविध सेट के फ्रंटियर LLMs (जैसे, GPT-4o, GPT-5, Claude Opus 4.5/4.6, Gemini 3 Flash/Pro, GLM-5) का परीक्षण उनके आधिकारिक API के साथ मानकीकृत हाइपरपैरामीटर्स का उपयोग करके किया गया।

C. प्रस्तावित मेट्रिक्स (Proposed Metrics)

शोध पत्र पारंपरिक मेट्रिक्स को बदलने या पूरक बनाने के लिए तीन नए मेट्रिक्स पेश करता है:

VES* (Valid Efficiency Score Star): यह Valid Efficiency Score (VES) का एक विस्तार है। यह कॉलम-लेवल प्रिसिजन ( $P$ ) को शामिल करता है जो आंशिक रूप से सही परिणामों को खारिज किए बिना अनावश्यक कॉलम के लिए दंडित करता है।
$VES^* = \frac{1}{N} \sum \left( \mathbb{1}(V, \hat{V}) \cdot P(S, \hat{S}) \cdot \frac{T_{gold}}{T_{e2e}} \right)$
- $\mathbb{1}(V, \hat{V})$ : परिणाम की शुद्धता के लिए बाइनरी इंडिकेटर।
- $P(S, \hat{S})$ : रिट्रीव किए गए कॉलमों की प्रिसिजन (Ground Truth बनाम Generated)।
- $T_{e2e}$ : कुल एंड-टू-एंड समय (LLM रीजनिंग + टूल कॉल्स + क्वेरी निष्पादन)।
VCES (Valid Cost-Efficiency Score): VES* का एक लागत-उन्मुख व्युत्पन्न (derivative) जो कुल निष्पादन लागत ( $C_{e2e}$ ), जिसमें टोकन उपयोग और कंप्यूट शुल्क शामिल है, को ध्यान में रखता है।
$VCES = \frac{1}{N} \sum \left( \mathbb{1}(V, \hat{V}) \cdot P(S, \hat{S}) \cdot \frac{T_{gold}}{T_{e2e} \cdot C_{e2e}} \right)$
CVQ (Cost per Valid Query): "सफलता तक पुनः प्रयास करें" (retry-until-success) रणनीति के तहत एक वैध परिणाम प्राप्त करने के लिए अपेक्षित लागत को मात्रात्मक रूप देता है। यह दर्शाता है कि कैसे सटीकता अंतराल बड़े डेटा स्केल पर बढ़ जाते हैं।
$CVQ = \frac{C_{e2e}}{p}$
- जहाँ $p$ सिंगल-शॉट वैधता दर है।

3. मुख्य योगदान (Key Contributions)

नया मूल्यांकन ढांचा: Text-to-Big SQL के लिए पहला बेंचमार्किंग पद्धति जो एजेंट इंटरेक्शन, रीजनिंग लेटेंसी और क्वेरी निष्पादन लागत को संयुक्त रूप से आंकता है।
नए मेट्रिक्स (VES*, VCES, CVQ): मेट्रिक्स जो आंशिक शुद्धता (अनावश्यक कॉलम) और Big Data वातावरण में त्रुटियों के आर्थिक प्रभाव को ध्यान में रखते हैं।
व्यवस्थित मॉडल विश्लेषण: अत्याधुनिक LLMs का एक व्यापक मूल्यांकन जो प्रकट करता है कि उच्च सटीकता हमेशा बेहतर प्रदर्शन के बराबर नहीं होती है।
स्केल-अवेयर अंतर्दृष्टि: यह प्रदर्शन करता है कि डेटा स्केल मौलिक रूप से अनुकूलन परिदृश्य (optimization landscape) को बदल देता है, जहाँ विलंबता और लागत के बीच ट्रेड-ऑफ महत्वपूर्ण हो जाते हैं।

4. मुख्य परिणाम (Key Results)

सटीकता अपर्याप्त है: मानक मेट्रिक्स (जैसे, Execution Accuracy) मॉडलों के बीच अंतर करने में विफल रहते हैं जब सटीकता उच्च होती है। उदाहरण के लिए, Claude Opus 4.6 ने पूर्ण सटीकता प्राप्त की लेकिन GPT-4o की तुलना में निष्पादन में 92% अधिक समय लिया, जिससे यह इंटरैक्टिव एनालिटिक्स के लिए कम उपयुक्त हो गया।
VES* बेहतर भेदभाव करता है: VES* ने गति और आंशिक शुद्धता को जोड़कर मॉडलों को सफलतापूर्वक रैंक किया। GPT-4o अपने गति और सटीकता के संतुलन के कारण शीर्ष प्रदर्शन करने वाला मॉडल बनकर उभरा, जबकि Gemini 3 Pro और GLM-5 जैसे मॉडल उच्च विलंबता भिन्नता (latency variance) से ग्रस्त रहे।
लागत बनाम विलंबता ट्रेड-ऑफ:
- Gemini 3 Flash को कम टोकन मूल्य निर्धारण के कारण सबसे लागत-कुशल (cost-efficient) मॉडल के रूप में पहचाना गया, भले ही यह GPT-4o की तुलना में थोड़ा धीमा था।
- GPT-4o सबसे तेज़ था लेकिन विशेष रूप से विफल प्रयासों (failed retries) को ध्यान में रखते हुए, प्रति क्वेरी काफी महंगा था।
डेटा स्केल का प्रभाव:
- छोटे स्केल (SF 10) पर, एजेंट रीजनिंग समय कुल विलंबता पर हावी होता है।
- बड़े स्केल (SF 1000) पर, क्वेरी निष्पादन समय हावी होता है।
- CVQ विश्लेषण: जैसे-जैसे डेटा स्केल बढ़ता है, त्रुटियों की लागत विस्फोट की तरह बढ़ती है। एक मॉडल जिसकी सटीकता 10% कम है (जैसे, Opus 4.5 बनाम GPT-5.2), SF 10 की तुलना में SF 1000 पर घातीय रूप से (exponentially) अधिक महंगा हो जाता है, जो पारंपरिक मेट्रिक्स में अदृश्य है।
त्रुटि वर्गीकरण (Error Taxonomy): 1,730 त्रुटियों के विश्लेषण से पता चला कि 38.9% "आउटपुट फॉर्मेट" त्रुटियां थीं (मुख्यतः अतिरिक्त कॉलम)। पारंपरिक मेट्रिक्स के तहत, ये विफलताएं हैं; प्रस्तावित Text-to-Big SQL मेट्रिक्स के तहत, इन्हें दंडित किया जाता है लेकिन आंशिक रूप से वैध माना जाता है।

5. महत्व और भविष्य की दिशाएं (Significance and Future Directions)

प्रतिमान परिवर्तन (Paradigm Shift): शोध पत्र तर्क देता है कि Text-to-SQL मूल्यांकन को "क्या SQL सही है?" से बदलकर "क्या SQL सही, तेज़ और बड़े पैमाने पर सस्ता है?" में विकसित होना चाहिए।
प्रोडक्शन प्रासंगिकता: निष्कर्ष क्लाउड डेटा वेयरहाउस (जैसे, Snowflake, BigQuery, Athena) में AI एजेंट तैनात करने के लिए महत्वपूर्ण हैं जहाँ बिलिंग उपयोग-आधारित (usage-based) है।
भविकी अवसर:
- रणनीतिक मॉडल असाइनमेंट: विभिन्न एजेंट चरणों के लिए अलग-अलग मॉडलों का उपयोग करना (जैसे, स्कीमा निरीक्षण के लिए "तेज़/सस्ता" मॉडल और जटिल तर्क के लिए "स्मार्ट" मॉडल)।
- स्केल-अवेयर ऑप्टिमाइज़ेशन: निष्पादन से पहले लागत का अनुमान लगाने और क्वेरी को फिर से लिखने के लिए ऐतिहासिक निष्पादन ट्रेसेस का लाभ उठाना।
- अनुमानित क्वेरी प्रोसेसिंग (Approximate Query Processing): सटीक निष्पादन के बजाय "तेज़" परिणामों (जैसे, सैंपलिंग) के लिए उपयोगकर्ता के इरादे को एकीकृत करना।
- UDF एकीकरण: यूजर-डेफाइंड फंक्शन्स (UDF) को संभालना जो Big Data में सामान्य हैं लेकिन मानक SQL जनरेटर के लिए कठिन हैं।

निष्कर्षतः, "Both Ends Count!" यह स्थापित करता है कि Big Data के लिए LLM एजेंटों का मूल्यांकन करने के लिए पूरे पाइपलाइन के समग्र दृष्टिकोण की आवश्यकता है। Big SQL में "Big" को अनदेखा करने से ऐसे सिस्टम बनते हैं जो सैद्धांतिक रूप से सटीक तो हैं लेकिन लागत और विलंबता बाधाओं के कारण व्यावहारिक रूप से अनुपयोगी हैं।