Vanna.ai: SQL डेटाबेस से बातचीत करें

 (github.com/vanna-ai)
3 पॉइंट द्वारा GN⁺ 2024-01-15 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • RAG (Retrieval-Augmented Generation) लागू करने वाला एक open source प्रोजेक्ट, जो LLM के साथ सटीक Text-To-SQL जनरेट करता है

Vanna कैसे काम करता है

  • RAG "मॉडल" को ट्रेन करना: उपयोगकर्ता के डेटा पर RAG मॉडल को ट्रेन किया जाता है।
  • सवाल पूछना: ट्रेन किए गए मॉडल से सवाल पूछने पर यह ऐसा SQL query लौटाता है जिसे डेटाबेस पर अपने-आप चलाया जा सकता है।

यूज़र इंटरफ़ेस

  • Vanna का उपयोग करके बनाए गए कुछ यूज़र इंटरफ़ेस में Jupyter Notebook, vanna-ai/vanna-streamlit, vanna-ai/vanna-flask, vanna-ai/vanna-slack आदि शामिल हैं।

शुरुआत करना

  • इंस्टॉल: pip install vanna कमांड से Vanna इंस्टॉल किया जा सकता है।
  • इम्पोर्ट: import vanna as vn कोड के जरिए Vanna का उपयोग किया जा सकता है।

ट्रेनिंग

  • DDL statements से ट्रेनिंग: डेटाबेस के table name, column, data type, relationships आदि की जानकारी वाले DDL statements का उपयोग करके मॉडल को ट्रेन किया जा सकता है।
  • दस्तावेज़ों से ट्रेनिंग: business terms या definitions से जुड़े दस्तावेज़ जोड़कर मॉडल को ट्रेन किया जा सकता है।
  • SQL से ट्रेनिंग: मौजूदा SQL queries को training data के रूप में जोड़कर नया SQL जनरेट किया जा सकता है।

सवाल पूछना

  • vn.ask("질문") method का उपयोग करके सवाल पूछने पर संबंधित SQL query प्राप्त की जा सकती है।

RAG बनाम fine-tuning

  • RAG को अलग-अलग LLM पर आसानी से पोर्ट किया जा सकता है, training data को हटाना आसान होता है, इसकी लागत कम होती है और यह भविष्य के लिए अधिक अनुकूलनीय है।
  • fine-tuning तब उपयोगी है जब prompt के भीतर tokens को न्यूनतम रखना हो, लेकिन इसकी शुरुआत धीमी होती है और training व execution लागत अधिक होती है।

Vanna क्यों चुनें

  1. जटिल datasets पर उच्च सटीकता: Vanna की क्षमता training data पर निर्भर करती है।
  2. सुरक्षा और गोपनीयता: डेटाबेस की सामग्री LLM या vector database को नहीं भेजी जाती।
  3. स्व-शिक्षण: Jupyter के माध्यम से उपयोग करने पर सफलतापूर्वक चले queries से यह अपने-आप सीख सकता है।
  4. सभी SQL डेटाबेस का समर्थन: Python से कनेक्ट हो सकने वाले सभी SQL डेटाबेस से जुड़ सकता है।
  5. फ्रंटएंड विकल्प: Jupyter Notebook से शुरू करके Slackbot, web app, Streamlit app या custom frontend के रूप में उपयोगकर्ताओं को उपलब्ध कराया जा सकता है।

Vanna का विस्तार

  • Vanna को सभी डेटाबेस, LLM और vector database से कनेक्ट होने के लिए डिज़ाइन किया गया है।
  • VannaBase abstract base class बुनियादी कार्यक्षमता को परिभाषित करती है, और OpenAI व ChromaDB का उपयोग करने वाली implementation प्रदान करती है।

अतिरिक्त सामग्री

  • पूरी documentation, website और सहायता के लिए Discord group आदि उपलब्ध हैं।

GN⁺ की राय:

  • Vanna डेटाबेस प्रबंधन और SQL query जनरेशन को ऑटोमेट करने वाला एक शक्तिशाली टूल है, जो उपयोगकर्ताओं को जटिल datasets के लिए उच्च-सटीकता वाली SQL queries आसानी से बनाने में मदद करता है।
  • user-friendly interface और self-learning क्षमताओं के जरिए गैर-विशेषज्ञ भी डेटाबेस का प्रभावी ढंग से उपयोग कर सकते हैं, जिससे data-driven decision-making और तेज हो सकती है।
  • Vanna की scalability और future adaptability कंपनियों को तकनीकी बदलावों के प्रति लचीले ढंग से प्रतिक्रिया देने और अपने data management processes को लगातार बेहतर बनाने का अवसर देती है।

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

1 टिप्पणियां

 
GN⁺ 2024-01-15
Hacker News राय

  • ChatDB.ai प्रोजेक्ट विकसित कर रहे एक उपयोगकर्ता का अनुभव

    • ChatDB.ai नाम का एक समान प्रोजेक्ट विकसित कर रहे हैं.
    • AI और SQL को मिलाकर सबसे सफल अनुभव यह रहा कि हर iteration के बाद SQL provider की errors को LLM को feedback के रूप में दिया गया.
    • formatted error message wrapper का उपयोग करके system table queries को मज़बूती से सुझाने के कारण, schema जानकारी खोजने में यह बहुत प्रभावी रहा.
    • इन छोटे adjustments के साथ, 4 या उससे अधिक tables के join की आवश्यकता वाली queries खोजने में यह आश्चर्यजनक रूप से सक्षम हो गया.

  • GPT-4 के उपयोग का व्यक्तिगत अनुभव

    • GPT-4 का उपयोग करके पहले से ही ऐसा ही काम किया है.
    • MySQL CLI के SHOW TABLE कमांड से table structure की जाँच की, और उन tables के आधार पर cart abandonment rate जैसे business metrics दिखाने वाली queries बनाई.
    • अनुभव रहा कि यह तरीका काफ़ी अच्छी तरह काम करता है.

  • natural language को SQL में अनुवाद करने वाली systems पर संदेहपूर्ण दृष्टिकोण

    • natural language को SQL में translate करने वाली systems के development efforts को स्वीकार करते हुए भी, natural language और models की मूल प्रकृति अनुमानाधारित और कम precision वाली होने के कारण संदेह है.
    • SQL databases ज़्यादातर मामलों में सही और सटीक information processing के लिए डिज़ाइन किए गए हैं, और एक अनुमानाधारित layer जोड़ना समस्या को और बिगाड़ सकता है.
    • यह सवाल उठाया गया कि क्या ऐसे प्रयास वास्तव में real-world requirements को प्रभावी ढंग से हल करने में productive हैं.

  • YC द्वारा समर्थित startups सहित समान products में रुचि

    • Minds DB (YC W20), Buster (YC W24), DB Pilot जैसे कुछ समान products को track कर रहे हैं, और इस क्षेत्र में काफ़ी रुचि है.
    • ख़ुद भी ऐसे solutions की तलाश में हैं.

  • duckdb-आधारित reporting service पर अनुभव

    • कुल मिलाकर अच्छी तरह काम करता है, लेकिन कुछ समस्याओं का सामना हुआ:
      • low temperature setting के बावजूद GPT-4 कभी-कभी examples या schema से भटक जाता है.
      • service सामान्य data host करती है, लेकिन customers अपनी domain language में reports बनवाने का अनुरोध करते हैं.
      • LLM prompt debugging मुश्किल है. customers model को आसानी से confuse कर सकते हैं.
      • generated queries के लिए ग्राहकों को "explanation" दिया जाता है ताकि report बनाने में क्या उपयोग हुआ, यह transparent रहे.

  • RAG के काम करने के तरीके पर चिंता और स्पष्टीकरण

    • "train" शब्द के उपयोग को लेकर चिंता व्यक्त की गई.
    • यह समझाने में काफ़ी समय लगाया गया कि RAG को training या fine-tuning के बिना सिर्फ data preparation, chunking, और vectorization की ज़रूरत होती है.

  • LLM hallucination समस्या को लेकर जिज्ञासा

    • यह जिज्ञासा है कि LLM "कल" जैसे time concepts को कैसे interpret करता है, और यह समस्या कि generated SQL syntactically valid होने पर भी intent से अलग हो सकता है.
    • ख़ासकर MAX, COUNT जैसी aggregate queries में गलत numbers देने का जोखिम है, और इसे verify करने के लिए SQL को सीधे पढ़ना पड़ता है, जो पूरे उद्देश्य के ख़िलाफ़ है.

  • अपने dataset और technology का उपयोग करने के अनुभव साझा करना

    • internal employees को structured datasets के साथ बातचीत करने देने वाला bot बनाने में समान technology का उपयोग किया गया.
    • वास्तव में यह कुछ हद तक काम करता है, लेकिन कुछ challenges हैं:
      • बहुत से ऐसे specific work-related enums और data types हैं जो existing models में नहीं हैं, इसलिए उन्हें manually define करके prompt में context के रूप में जोड़ना पड़ता है.
      • time-related questions को handle करना कठिन है.
      • क्योंकि users कुछ भी पूछ सकते हैं, इसलिए एक single table के लिए भी बहुत से example SQL queries की ज़रूरत होती है.
      • अलग-अलग tables तक scale करना मुश्किल है, और यह जिज्ञासा है कि क्या कोई अधिक efficient तरीका है.
      • Llama2 70B Gen model का उपयोग किया गया, लेकिन यह जिज्ञासा है कि क्या कोई दूसरा model SQL query generation में बेहतर performance दिखाता है.

  • bit.io में अनुभव और customers की प्रतिक्रिया

    • bit.io में ऐसा ही काम किया था, और लोगों को यह पसंद आया.
    • काम के दौरान मिली जानकारियों पर कई articles हैं, और अब यह Databricks द्वारा अधिग्रहित होने के बाद service बंद कर चुका है.
    • जहाँ तक संभव हो, questions के जवाब देने के लिए तैयार हैं.