NaturalSQL-7B - प्राकृतिक भाषा को SQL में बदलने वाला शक्तिशाली मॉडल

 (github.com/cfahlgren1)
15 पॉइंट द्वारा xguru 2024-02-07 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • SQL-Eval में 76.5% हासिल किया, और मॉडल आकार के आधार पर यह सर्वश्रेष्ठ प्रदर्शन दिखाता है
    • GPT-4(83%) से कम है, लेकिन GPT-3.5-Turbo(65%) / Claude-2(64.5%) से बेहतर है
    • sqlcoder-7b(71%) से ऊँचा और sqlcoder-15b(78%) के करीब
  • ChatDB विकसित किया गया, जो SQL लिखे बिना dashboard को no-code तरीके से बनाने वाला टूल है

उदाहरण

  • प्रश्न: पिछले महीने सबसे अधिक ऑर्डर राशि वाले ग्राहक की पहचान करें, और उनके द्वारा ऑर्डर किए गए सभी उत्पादों और उनकी मात्रा की सूची बनाएं.
  • आउटपुट: 
    WITH LastMonthOrders AS (  
  SELECT o.customerid, o.orderid, op.productid, op.quantity, p.productname, op.quantity * p.unitprice AS total_order_value  
  FROM orders o  
  JOIN order_details op ON o.orderid = op.orderid  
  JOIN products p ON op.productid = p.productid  
  WHERE o.orderdate >= date_trunc('month', CURRENT_DATE) - INTERVAL '1 month'  
  AND o.orderdate < date_trunc('month', CURRENT_DATE)  
),  
CustomerTotalOrderValue AS (  
  SELECT customerid, SUM(total_order_value) AS total_value  
  FROM LastMonthOrders  
  GROUP BY customerid  
  ORDER BY total_value DESC  
  LIMIT 1  
)  
SELECT c.customerid, c.companyname, lm.productid, lm.productname, lm.quantity  
FROM CustomerTotalOrderValue ctov  
JOIN LastMonthOrders lm ON ctov.customerid = lm.customerid  
JOIN customers c ON c.customerid = lm.customerid;
  • NaturalQuery ऊपर जैसे जटिल प्रश्नों, subquery, और ratio के मामलों में बहुत अच्छा प्रदर्शन करता है.

संबंधित पढ़ाई

1 टिप्पणियां

 
xguru 2024-02-07

Hacker News टिप्पणियाँ

  • SQL-Eval में परफ़ॉर्मेंस स्कोर 76.5% है, जो GPT-4 के 83% और sqlcoder-15b के 78% से थोड़ा पीछे है।

    • ऐसे AI data science इंटर्न किन applications में उपयोगी हो सकते हैं? 75% accuracy वाले AI से क्या बनाया जा सकता है?
    • एक ऐसे प्रोग्रामर के रूप में जो SQL काम करते समय अक्सर references देखता है, लगता है इस तरह के AI का उपयोग पहली query draft लिखने में किया जा सकता है।
    • बड़े models किसी एक case में बेहतर result दे सकते हैं, लेकिन 64GB m1 पर 15b model आसानी से चलाया जा सकता है।
    • enterprise environment में schema जानकारी को OpenAI के training data में leak नहीं करना चाहते, और कभी-कभी queries को offline चलाना भी चाहते हैं।
    • जब बहुत सारी queries चलानी हों, तब छोटा और local model उपयोगी है (cost बचत)।
    • यह बढ़िया होगा अगर non-technical लोग भी query कर सकें, लेकिन सवाल यह है कि query उन 25% 'गलत' मामलों में आती है या नहीं, यह कैसे पता चले।
    • शायद RAID जैसे consensus algorithm से, जहाँ कई AI एक-दूसरे के जवाब verify करें, कुल success rate बढ़ाई जा सकती है।
    • ये ज़्यादातर मेरे विचारों को व्यवस्थित करने की प्रक्रिया है, लेकिन शायद दूसरों के पास और ideas हों। OP को launch के लिए बधाई!

  • लगता है text-to-SQL models सही समस्या हल नहीं कर रहे हैं।

    • मुश्किल हिस्सा syntax या 'group by' query लिखना नहीं है, बल्कि data का meaning समझना है।
    • Snowflake की 50-column table देखकर सिर्फ column names से यह अंदाज़ा नहीं लगाया जा सकता कि वह क्या है।
    • उदाहरण के लिए, अगर किसी table में 10 columns हों जिनके नाम ...price पर खत्म होते हों, तो असली मतलब जानने के लिए wiki देखनी पड़ेगी या DBT definitions पढ़नी पड़ेंगी।
    • model द्वारा बनाई गई query पर भरोसा नहीं किया जा सकता, क्योंकि model data नहीं समझता, सिर्फ query syntax समझता है।

  • यह बताया गया कि यह open source नहीं है; usage-based restrictions हैं, इसलिए इसे 'source available' कहना ज़्यादा सही होगा।

  • यह दिलचस्प है और मेरी रुचि के क्षेत्र में आता है, लेकिन मुझे नहीं लगता कि यह कोई complex question है; यह एक basic analytics question है।

    • ज़्यादातर analysts इसे नींद में भी लिख सकते हैं।
    • SQL लिखने के लिए ChatGPT आज़माया, लेकिन नतीजा साधारण रहा; हालांकि यह निश्चित रूप से बेहतर होगा।

  • AI के कई use cases की तरह, खासकर range के हिसाब से grouping जैसी ideas सुझाने में, यह 'seed' के रूप में बहुत अच्छा है।

    • लेकिन लगभग हर database में असली समस्या details में होती है।
    • अलग-अलग products 'quantity' को अलग तरह से interpret करते हैं (जैसे box बनाम unit), coupons और discounts अजीब तरीकों से model किए जाते हैं, weight को pounds/kilograms मान लिया जाता है और बिना units बताए mix कर दिया जाता है, वगैरह।

  • जो लोग कहते हैं कि 75% accuracy होने से यह बेकार है, उन्हें दो बातें ध्यान में रखनी चाहिए:

    • यह पहला version है, और यह पहले से ही किसी भी कल्पनीय Airtable की तुलना में product owners और analysts के लिए हज़ार गुना ज़्यादा उपयोगी है।
    • हर चुनौती में सही होना अच्छा है, लेकिन हम पहले से ही 'good enough' economy में जी रहे हैं, और अगर यह काफ़ी करीब है, तो business के लिए काफ़ी अच्छा होगा।

  • जिज्ञासा है कि यह Bird जैसे ज़्यादा complex और realistic benchmark पर कैसा perform करता है।

  • data क्षेत्र में काम करने के अनुभव के आधार पर, बहुत से लोगों को executives से सवाल मिलते हैं, और उनसे उम्मीद होती है कि वे data warehouse को इतना समझें कि उन सवालों का जवाब देने वाली SQL लिख सकें, और कभी-कभी अच्छी तरह formatted जवाब भी दें।

    • कभी-कभी executives के follow-up questions पहले से भाँपने पड़ते हैं, जैसे "वह संख्या इतनी कम क्यों है? यह इतनी कम तो नहीं होनी चाहिए", इसलिए data engineer से bug check करने को कहना पड़ता है।
    • हर LLM की तरह, यह स्पष्ट नहीं है कि क्या यह उस ज़िम्मेदारी को बहुत आसान बना देगा या पूरी तरह खत्म कर देगा।

  • यह वास्तव में बहुत बढ़िया है, और license standard न होने के बावजूद open source जैसा दिखता है।

    • असली model यहाँ मिल सकता है: NaturalSQL-6.7B-v0
    • यह एक शानदार base model लगता है, लेकिन सोचता हूँ कि छोटे models के लिए text-to-sql अच्छा use case है या नहीं।
    • हम भी इस क्षेत्र में tools बना रहे हैं, और उम्मीद है कि हमें जवाब बेहतर पता होंगे, इसलिए gpt-4 का उपयोग करना चाहते हैं। यहाँ तक कि gpt 3.5 भी production के लिए काफ़ी नहीं है।

  • बहुत बढ़िया है, लेकिन सोच रहा हूँ कि क्या यह license Vanna के साथ इस्तेमाल किया जा सकता है: Vanna