Show HN: Natural-SQL-7B, एक मजबूत टेक्स्ट-टू-SQL मॉडल

मूल लेख ↗ Hacker News चर्चा ↗

एक नया 7B-parameter text-to-SQL मॉडल, Natural-SQL-7B, गैर-तकनीकी उपयोगकर्ताओं को plain language में databases query करने देने का लक्ष्य रखता है, और local चलकर GPT‑4-आधारित समाधानों से सस्ती तथा अधिक निजी analytics की उम्मीद जगाता है। टिप्पणीकार इसके custom “source available” license, वर्तमान PostgreSQL फोकस, और क्या लगभग 75% accuracy production use के लिए पर्याप्त है, इस पर सवाल उठाते हैं—खासकर जहाँ business logic और KPIs सूक्ष्म या domain-specific हों। कई लोग ऐसे मॉडल को drafting tool के रूप में या semantic layers, RAG, और मजबूत data governance के साथ मिलाकर उपयोगी मानते हैं, न कि skilled analysts के standalone replacement के रूप में।

मॉडल की क्षमताएँ और दायरा

  • 7B टेक्स्ट-टू-SQL मॉडल, जिसे SQL श्रेणियों और प्रश्न प्रकारों में लगभग 20k सिंथेटिक PostgreSQL टेक्स्ट→SQL जोड़ों पर fine-tune किया गया है।
  • SQL-Eval पर लगभग 76.5% पर मूल्यांकित, GPT‑4 और sqlcoder‑15B से थोड़ा नीचे।
  • फिलहाल Postgres-केंद्रित; व्यापक dialect समर्थन (MySQL, DuckDB, MSSQL, BigQuery, Trino) वांछित है और आंशिक रूप से योजना में है।
  • multi-join, aggregation, और subquery वाले ऐसे प्रश्नों को संभालता है जो गैर-तकनीकी उपयोगकर्ताओं के लिए “कठिन” होते हैं, लेकिन बहुत जटिल schemas या business-heavy queries पर इसकी गारंटी नहीं है।

लाइसेंसिंग और “ओपन सोर्स” बहस

  • लाइसेंस में base model से विरासत में मिली उपयोग-आधारित पाबंदियाँ शामिल हैं (जैसे, सैन्य उपयोग नहीं)।
  • कई टिप्पणीकारों का तर्क है कि यह “open source” नहीं बल्कि “source/weights available” है।
  • चिंता है कि nonstandard licenses के कारण familiar MIT/Apache/GPL की बजाय legal review करनी पड़ती है।
  • कुछ यह भी नोट करते हैं कि केवल model weights दिए गए हैं, training code/data नहीं।

उपयोग के मामले, सटीकता, और विश्वसनीयता

  • उपयोगी माना गया है:
    • डेवलपर्स/analysts के लिए SQL का draft बनाना, जो उसे review और fix कर सकते हैं।
    • local/cli tools को power देना, जहाँ schemas को cloud LLMs को नहीं भेजना चाहिए।
  • संदेहवादी प्रश्न उठाते हैं कि ~75% correctness के साथ आप सुरक्षित रूप से क्या automate कर सकते हैं, खासकर business-critical analytics और KPIs के लिए।
  • अन्य लोग कहते हैं कि humans भी गलतियाँ करते हैं; मूल्य “simple” कदमों को तेज़ करने में है, जबकि humans परिणामों की पुष्टि करते हैं।
  • उठाए गए विचार: ensembles/consensus, मजबूत DB constraints से validation, और इसे मुख्यतः वहाँ उपयोग करना जहाँ correctness जाँचना आसान हो।

Schema, context length, और semantics

  • 4k context कई वास्तविक schemas के लिए बहुत छोटा है; लोग DDL पर RAG के उपयोग या 32k+ context की इच्छा पर चर्चा करते हैं।
  • सामान्य तरीका: prompt के रूप में CREATE TABLE DDL (comments के साथ) देना; कुछ लोग documentation/wiki/dbt पर RAG का उपयोग करके semantics सिखाते हैं।
  • कई लोगों का तर्क है कि असली समस्या SQL syntax नहीं, बल्कि data meaning को समझना है (“इस ‘price’ या ‘active’ field का वास्तव में क्या मतलब है?”)।
  • semantic layers / knowledge graphs / ORMs के लिए मजबूत समर्थन है, जो business logic को encode करते हैं, और जहाँ SQL LLMs से सीधे बनाने की बजाय उस layer से deterministically generate की जाती है।

Cloud बनाम local, privacy, और trust

  • कुछ लोग OpenAI को schemas या data भेजने से इनकार करते हैं, terms बदलने, regulatory concerns, या संभावित सरकारी access का हवाला देते हुए।
  • Azure OpenAI कुछ लोगों को अधिक सुरक्षित लगता है, लेकिन features/models में पीछे माना जाता है।
  • इस model का local, weights-available setup privacy या governance constraints वाले लोगों के लिए आकर्षक है।

SQL और tooling पर व्यापक विचार

  • SQL सीखने बनाम ORMs या LLMs पर निर्भर रहने की बहस; कई लोग SQL के स्थायी मूल्य और performance benefits पर ज़ोर देते हैं।
  • अन्य लोग SQL की ergonomics समस्याओं को उजागर करते हैं और abstractions को प्राथमिकता देते हैं।
  • कई लोग नोट करते हैं कि LLMs पहले से ही complex SQL समझाने, errors debug करने, और tricky window/percentile queries बनाने में उपयोगी हैं।