- Gemini-आधारित Text-to-SQL फीचर का उपयोग Google Cloud में डेवलपर्स और गैर-तकनीकी उपयोगकर्ताओं की उत्पादकता बढ़ाने के लिए किया जा रहा है
- वास्तविक वातावरण में बिज़नेस संदर्भ की कमी, उपयोगकर्ता की मंशा समझने में कठिनाई, SQL dialect के अंतर के कारण सटीक SQL बनाना मुश्किल होता है
- Google इसे हल करने के लिए इंटेलिजेंट डेटा retrieval, context-based learning, semantic layering जैसी तकनीकों को अपना रहा है
- मॉडल की अपनी सीमाएँ multi-generation के बाद optimal selection (self-consistency), validation के बाद re-prompting, और SQL dialect-विशिष्ट training से दूर की जाती हैं
- मूल्यांकन और सुधार मापन में इन-हाउस benchmark और LLM-as-a-judge जैसी तकनीकें शामिल हैं, ताकि इन्हें वास्तविक वातावरण में अधिक प्रभावी ढंग से लागू किया जा सके
Techniques for improving text-to-SQL
टेक्स्ट से SQL में रूपांतरण: Google Cloud की वर्तमान स्थिति
- संगठन तेज़ और सटीक data insights के लिए SQL का उपयोग करते हैं
- Gemini प्राकृतिक भाषा से सीधे SQL बनाने वाला text-to-SQL फीचर देता है
- यह फीचर सिर्फ डेवलपर्स ही नहीं, बल्कि गैर-तकनीकी उपयोगकर्ताओं के लिए भी उपयोगी है
- यह फीचर फिलहाल BigQuery Studio, Cloud SQL Studio, AlloyDB Studio, Vertex AI आदि में उपलब्ध है
Text-to-SQL तकनीक की प्रमुख चुनौतियाँ
1. बिज़नेस संदर्भ उपलब्ध कराने में कठिनाई
- सटीक SQL लिखने के लिए LLM को database structure, column meanings, और वास्तविक data content जैसे पर्याप्त context देना ज़रूरी है
- Context में explicit जानकारी (schema, column info आदि) और implicit जानकारी (विशिष्ट data का business meaning आदि) दोनों शामिल होती हैं
- database structure, dataset variation, या schema changes के अनुसार LLM को लगातार train (fine-tuning) करते रहना व्यावहारिक रूप से महंगा पड़ता है
- business knowledge या semantic जानकारी अक्सर ठीक से व्यवस्थित नहीं होती, और उसे training data में बदलना भी कठिन होता है
- उदाहरण: अगर DBA को
pcat_extension टेबल में cat_id2 = 'Footwear' का मतलब नहीं पता, तो वह जूते की बिक्री देखने वाला SQL भी नहीं लिख पाएगा — LLM के साथ भी context की कमी होने पर गलत query बनने का जोखिम रहता है
2. उपयोगकर्ता की मंशा समझने की समस्या
- प्राकृतिक भाषा के प्रश्नों में SQL की तुलना में स्पष्टता की कमी होना आम बात है
- वास्तविक data analysts या engineers सवाल अस्पष्ट होने पर follow-up questions के जरिए उसे स्पष्ट कर सकते हैं, लेकिन LLM दिए गए प्रश्न का तुरंत उत्तर बनाने की प्रवृत्ति रखता है, जिससे गलत जानकारी (hallucination) का जोखिम रहता है
- “सबसे ज़्यादा बिकने वाले जूते कौन से हैं?” जैसे प्रश्न में ‘सबसे ज़्यादा बिकने’ का आधार (order count, revenue आदि) या परिणामों की संख्या जैसी शर्तें अस्पष्ट होती हैं
- तकनीकी क्षमता वाले उपयोगकर्ता लगभग-सही SQL को शुरुआती बिंदु की तरह इस्तेमाल कर सकते हैं, लेकिन गैर-विशेषज्ञों के लिए सही तरीके से काम करने वाला SQL अधिक महत्वपूर्ण है
- प्रभावी ढंग से काम करने के लिए LLM को follow-up questions, reasoning explanation, और user guidance जैसी क्षमताओं का समर्थन करना चाहिए, ताकि वह उपयोगकर्ता की मंशा को स्पष्ट रूप से समझ सके
3. LLM की generation सीमाएँ
- LLM document summarization, information extraction जैसे कामों में मज़बूत हैं, लेकिन सटीक SQL syntax या कम इस्तेमाल होने वाले SQL features के मामले में इनकी कमज़ोरियाँ सामने आती हैं
- SQL dialect के अनुसार syntax बदलता है, और छोटे अंतर भी बहुत उच्च सटीकता की मांग करते हैं
- उदाहरण: BigQuery में
EXTRACT(MONTH FROM timestamp_column) का उपयोग होता है, जबकि MySQL में MONTH(timestamp_column) लिखना पड़ता है
- जटिल specifications का लगातार पालन करते हुए SQL बनाना LLM के लिए आसान काम नहीं है
Google Cloud की Text-to-SQL सुधार तकनीकें
समस्या: schema और business context
- semantic-based search और ranking
- in-context learning
- data sampling और linking
- semantic layers का निर्माण
- usage patterns और history analysis
समस्या: उपयोगकर्ता की मंशा समझना
- LLM के माध्यम से clarification
- entities की पहचान, संबंधित जानकारी की पुष्टि, और उचित follow-up questions की ओर मार्गदर्शन
समस्या: LLM की सीमाओं पर काबू पाना
- Self-consistency के जरिए कई queries बनाकर सबसे उपयुक्त का चयन
- validation और re-prompting
- SQL dialect उदाहरणों सहित context learning
- model fine-tuning
प्रमुख तकनीकी अनुप्रयोगों के उदाहरण
SQL-aware मॉडल
- Gemini उच्च-गुणवत्ता SQL generation के लिए fine-tuned versions का उपयोग करता है
- SQL dialect-विशिष्ट सटीकता सुनिश्चित करने के लिए model version mixing और custom tuning किया जाता है
उपयोगकर्ता प्रश्न स्पष्ट करना (Disambiguation)
- प्रश्न अस्पष्ट होने पर clarification questions बनाए जाते हैं
- उदाहरण: "सबसे ज़्यादा बिकने वाले जूते?" → “क्या आधार order count है, या revenue?”
semantic-based search और context निर्माण
- multi-stage semantic matching आधारित vector search से संबंधित tables और columns की पहचान की जाती है
- prompt में user query history, business rule examples आदि को शामिल किया जाता है
- long context window support से बड़े schema को संभालना संभव होता है
validation और पुनर्जनन
- LLM द्वारा बनाई गई queries में parsing, Dry-run आदि से स्पष्ट errors का पता लगाया जाता है
- error मिलने पर re-prompting के जरिए सुधार कराया जाता है
Self-consistency
- एक query के बजाय अलग-अलग तरीकों से कई queries generate की जाती हैं
- यदि कई models एक ही query सुझाते हैं, तो accuracy बेहतर होती है
मूल्यांकन और प्रदर्शन मापन
- मौजूदा benchmarks (BIRD-bench आदि) उपयोगी हैं, लेकिन वास्तविक schema को पूरी तरह दर्शाने में उनकी सीमाएँ हैं
- Google ने अपना synthetic benchmark सेट तैयार किया है
मूल्यांकन रणनीति
- SQL dialect और engine-विशिष्ट फीचर्स का व्यापक कवरेज: query के अलावा DDL, DML, और administration tasks भी शामिल
- evaluation metrics: user response, offline metrics, LLM-as-a-judge
- continuous evaluation: नए models और prompt techniques की प्रभावशीलता को तेज़ी से परखा जा सकता है
समापन
1 टिप्पणियां
Hacker News राय
टेक्स्ट से SQL में रूपांतरण के अंतिम लक्ष्य को लेकर सवाल है: क्या उद्देश्य डेटा विश्लेषक का सहायक बनाना है, या विश्लेषक के बिना सीधे business insights पाना? अगर दूसरा लक्ष्य है, तो सिस्टम कितना भी उन्नत हो जाए, non-expert के लिए SQL की सटीकता और पर्याप्तता को परखना मूलतः असंभव समस्या है। "कल e-commerce transactions 80% पर ही क्यों रहे?", "customer acquisition cost क्यों बढ़ रहा है?", "New York campaign, San Francisco की तुलना में खराब क्यों रहा?" जैसे सवाल text2sql की श्रेणी से बाहर हैं
वास्तव में मुझे लगता है कि उद्देश्य दूसरे के अधिक करीब है, लेकिन नतीजे उम्मीद तक नहीं पहुँचते। business में लोग आख़िरी समय पर reports बदलना चाहते हैं, लेकिन analysts की कमी के कारण वे समय पर मनचाही जानकारी नहीं पा पाते। इसे "अनंत गति" से हल करना चाहा जाता है, जबकि असली समस्या यह है कि metrics पर पर्याप्त सोच ही नहीं की जाती। data जटिल है, business knowledge बाहर implicit रूप में जमा है, और data infrastructure कमज़ोर है, इसलिए analysis में बहुत समय लगता है। समझदार analytics leaders AI लहर का उपयोग बुनियादी infrastructure में निवेश करने के लिए कर रहे हैं
मेरे हिसाब से ऊपर वाले सवाल शुरू से ही SQL से हल होने वाले सवाल नहीं हैं। SQL मुख्यतः "क्या(what)" का जवाब देता है, "क्यों(why)" का नहीं। text2sql का लक्ष्य analyst का समय बचाना है ताकि वह "क्या" को जल्दी निपटाकर "क्यों" पर ध्यान दे सके
यह सही है, लेकिन मेरे विचार में natural language text, LLM systems के लिए सार्वभौमिक input बन सकता है। text2sql, अधिक जटिल सवालों के जवाब बनाने वाली information retrieval की बुनियाद की तरह काम कर सकता है। अल्पकाल में यह work-assist फीचर है, लेकिन दीर्घकाल में लक्ष्य automation, result comparison, और बड़े workflows में integration की नींव रखना है। असली बात ऐसे सवालों का जवाब देने की बुनियाद बनाना है। अभी बहुत काम बाकी है
कोई भी algorithm जिसे इंसान कर सकता है, बनाया और test किया जा सकता है। अगर 10 analysts हों, तो database और business की समझ, और skill, सबकी अलग होगी। automation कम-से-कम एक न्यूनतम skill और knowledge standard दे सकता है। नया analyst भी तुरंत बेहतर परिणाम दे सकता है। experts के साथ मिलकर system को विकसित करते हुए test करना, और AI को trade-offs, bugs, और expected results की तुलना में interpret करना सिखाना, उपयोगी लक्ष्य है। insight या ‘taste’ को automate करना कठिन है, लेकिन domain expert अगर अच्छी तरह डिज़ाइन किए गए automation और उचित results की समझ के साथ काम करे, तो बहुत दूर तक जा सकता है। यह परफेक्ट नहीं है, लेकिन यही मेरा लक्ष्य है
OpenAI 4o model के इस्तेमाल का अनुभव साझा किया: prompt में business guidelines, industry terminology, tables और foreign keys का विवरण साथ दिया जाता है। तब यह complex join queries भी बना देता है और results भी लौटाता है। उद्देश्य SQL न जानने वाले users के लिए output देना था, लेकिन reference के लिए SQL भी साथ दिखाया जाता है
AI को परफेक्ट SQL बनाने की ज़रूरत नहीं है। मेरे मामले में, भले output को code से verify किया जा सके, फिर भी subtle semantic differences के जोखिम के कारण मैं उसे copy-paste करके इस्तेमाल नहीं करता। इसके बजाय AI अगर approach सुझा दे, तो मैं उसे देखकर SQL खुद शुरू से लिखता हूँ
Google AI Studio के latest Gemini के उपयोग का अनुभव: यह सचमुच चौंका देने वाला, प्रभावशाली और groundbreaking है। Claude और ChatGPT का coding output अब ऐसे लगता है जैसे किसी दूसरी सदी से आया हो। सिर्फ़ एक महीना पहले तक Claude मुझे शानदार लगता था, लेकिन अब समझ नहीं आता कि Google Gemini के बिना coding कैसे जारी रखूँ। Gemini AI Studio programming में एक बहुत बड़ी छलांग है
यह देखकर हैरानी होती है कि अभी भी बहुत से लोगों ने इस बदलाव को पहचाना नहीं है। Claude छोटे tasks ठीक से कर लेता है, लेकिन जैसे ही बात complex problems तक जाती है, Gemini बहुत आगे निकल जाता है। context handling क्षमता विशेष रूप से प्रभावशाली है। मैं इसे सिर्फ coding agent की तरह नहीं, बल्कि 85,000 शब्दों की manuscript की beta reading के लिए भी इस्तेमाल कर रहा हूँ, और लगभग real time में expert-level feedback reports मिल रही हैं
इस हफ़्ते ऐसा लगा कि free Gemini Pro में reasoning mode disable कर दिया गया है। अगर उसे code लिखने से ठीक पहले रोका जाए या ज़रूरत से ज़्यादा generalize न करने दिया जाए, तो यह काफ़ी उपयोगी है। हालांकि Gemini में code ज़रूरत से ज़्यादा लिखने की प्रवृत्ति है। मेरा मुख्य उपयोग यह है कि code implementation में उलझने के बजाय Gemini को design exploration के लिए इस्तेमाल करूँ। उदाहरण के लिए, Stripe से subscription service बनाने के case में, अपने tech stack और use case के अनुरूप existing data को context में पाकर मैं एक भी line code लिखने से पहले design direction बदल सका
जवाब है “semantic layer का उपयोग”। सही context देने का यह सबसे प्रभावी तरीका है और यही वह सर्वोत्तम बिंदु है जहाँ इंसान सीधे हस्तक्षेप कर सकता है। अगर इंसान सभी core metrics को स्पष्ट रूप से define कर दे, तो LLM उन्हें कभी भी उपयोग कर सकता है। उदाहरण के लिए, अगर MAU define है, तो LLM उसी definition के आधार पर query बनाएगा। SQL की जगह JSON में query लिखी जाए, तो LLM कहीं अधिक consistent results देता है। हम cube का उपयोग करते हैं, जो सबसे अच्छा open source semantic layer है। Naver पर closed-source options भी हैं। मेरी पुरानी कंपनी ने इस विषय पर blog भी लिखा था, लेकिन अब मालिक कंपनी ने उसकी hosting बंद कर दी है
वास्तविक काम में AI से SQL बनवाना जोखिम भरा है। SQL न जानने वाला व्यक्ति गलत query चलाकर server पर गंभीर असर डाल सकता है। हमारी टीम में database, ज़्यादातर developers के मानक से बड़ा है, लेकिन सचमुच बहुत विशाल नहीं है। कभी-कभी optimized query को और बेहतर बनाने के लिए AI से कहा जाता है, लेकिन AI ने कभी बेहतर जवाब नहीं दिया। कई बार AI बकवास करता है या ऐसे सुझाव देता है जिनका असल में कोई उपयोग नहीं। यह किसी मूर्ख तोते जैसा लगता है जो पहले सुनी हुई बातें दोहरा रहा हो
अगर AI में text-to-regex conversion की सुविधा हो, तो वह सचमुच बहुत सुविधाजनक होगी
मैंने जितने भी AI tools इस्तेमाल किए हैं, उनमें सबसे निराशाजनक BigQuery में built-in Gemini रहा है। column names भी स्पष्ट थे, descriptions भी अच्छे से लिखी थीं, फिर भी वह समस्या हल करने के क़रीब भी नहीं पहुँच पाया
अब तक मैंने सबसे ज़्यादा queries SQL में ही लिखी हैं। AI से query लिखवाने पर, उसे खुद लिखने की तुलना में result को ठीक करने में कहीं ज़्यादा समय लगता है। साथ ही, काश कोई एक फीचर होता जो SQL को बहुत तेज़ी से लिखने में मदद करता। हमारी कंपनी के DSL में foreign keys के आधार पर auto-join करने वाला operator है, और वह बेहद सुविधाजनक है। SQL लिखते समय सबसे परेशान करने वाली चीज़ 10, 20 या उससे अधिक joins को हाथ से लिखना है। बाकी चीज़ें उसके मुकाबले उतनी कठिन नहीं हैं
मेरे अनुभव में, अगर constraints साफ़ हों और foreign keys सही तरह से सेट हों, तो लगभग सब कुछ हल हो जाता है। हर table में स्पष्ट constraints होने चाहिए, ताकि AI सभी connection structures को सही तरह समझ सके। SQL एक बहुत सटीक specification है, लेकिन अगर constraints और foreign keys सही तरह define न हों, तो AI से सही जवाब की उम्मीद नहीं की जा सकती
सभी foundation models में यह अब काफ़ी सरल हो गया है। अगर table schema पर comments अच्छे से लिखे हों, तो query generation request आसान हो जाती है
smolagents library से model के आसपास scaffolding बना दी जाए, तो यह काफ़ी सुविधाजनक होता है। text2sql demo में भले सरल दिखे, लेकिन इसे वास्तविक जटिल cases में लागू करना बहुत कठिन है—इस पर लेख भी हैं
Step 1: schema में हज़ारों tables हैं और comments लगभग नहीं के बराबर हैं, Step 2...
मैं भी सचमुच यही मानता हूँ। अब इसमें ज़्यादा जादू नहीं बचा है। table creation DDL दरअसल table का सटीक विवरण ही होता है, इसलिए अक्सर उससे अधिक की ज़रूरत नहीं पड़ती। बस आवश्यक query को विस्तार से समझा दिया जाए, तो अधिकांश LLM आसानी से query बना लेते हैं
"Show HN: We open sourced our entire text-to-SQL product" (2024) पोस्ट में बताए गए resources में awesome-Text2SQL और Awesome-code-llm > Benchmarks > Text to SQL जैसे बेहतरीन references शामिल हैं