Vanna.ai : dialoguer avec des bases de données SQL

• Un open source qui génère un Text-To-SQL précis avec un LLM appliquant le RAG (Retrieval-Augmented Generation)

Fonctionnement de Vanna

• Entraînement du « modèle » RAG : entraîne un modèle RAG sur les données de l’utilisateur.
• Poser des questions : en interrogeant le modèle entraîné, il renvoie des requêtes SQL pouvant être exécutées automatiquement sur la base de données.

Interface utilisateur

• Parmi les interfaces utilisateur construites avec Vanna, on trouve Jupyter Notebook, vanna-ai/vanna-streamlit, vanna-ai/vanna-flask et vanna-ai/vanna-slack.

Démarrage

• Installation : vous pouvez installer Vanna avec la commande pip install vanna.
• Import : vous pouvez utiliser Vanna via le code import vanna as vn.

Entraînement

• Entraînement avec des instructions DDL : il est possible d’entraîner le modèle à l’aide d’instructions DDL contenant des informations sur les noms de tables, colonnes, types de données et relations de la base.
• Entraînement avec de la documentation : il est possible d’entraîner le modèle en ajoutant de la documentation sur les termes métier ou leurs définitions.
• Entraînement avec du SQL : il est possible d’ajouter des requêtes SQL existantes comme données d’entraînement afin de générer de nouvelles requêtes SQL.

Poser des questions

• En utilisant la méthode vn.ask("질문"), vous pouvez poser une question et recevoir la requête SQL correspondante.

RAG vs fine-tuning

• Le RAG est portable entre différents LLM, permet de supprimer facilement les données d’entraînement, coûte moins cher et s’adapte mieux à l’avenir.
• Le fine-tuning est utile lorsqu’il faut minimiser les tokens dans le prompt, mais son démarrage est lent et ses coûts d’entraînement et d’exécution sont élevés.

Pourquoi choisir Vanna

1. Haute précision sur des jeux de données complexes : les capacités de Vanna dépendent des données d’entraînement.
2. Sécurité et protection de la vie privée : le contenu de la base de données n’est pas transmis au LLM ni à une base de données vectorielle.
3. Auto-apprentissage : utilisé via Jupyter, il peut apprendre automatiquement à partir des requêtes exécutées avec succès.
4. Prise en charge de toutes les bases SQL : il peut se connecter à toute base de données SQL accessible depuis Python.
5. Choix du front-end : vous pouvez commencer dans Jupyter Notebook, puis le proposer aux utilisateurs sous forme de Slackbot, d’application web, d’application Streamlit ou de front-end personnalisé.

Extension de Vanna

• Vanna est conçu pour se connecter à n’importe quelle base de données, n’importe quel LLM et n’importe quelle base de données vectorielle.
• La classe de base abstraite VannaBase définit les fonctionnalités essentielles et fournit une implémentation utilisant OpenAI et ChromaDB.

Ressources supplémentaires

• La documentation complète, le site web et un groupe Discord pour le support sont disponibles.

Avis de GN⁺ :

• Vanna est un outil puissant pour automatiser l’administration de bases de données et la génération de requêtes SQL, permettant aux utilisateurs de créer facilement des requêtes SQL très précises sur des jeux de données complexes.
• Grâce à son interface conviviale et à sa capacité d’auto-apprentissage, même des non-spécialistes peuvent exploiter efficacement une base de données, ce qui peut encore accélérer la prise de décision fondée sur les données.
• L’extensibilité de Vanna et sa capacité d’adaptation à l’avenir offrent aux entreprises l’opportunité de réagir avec souplesse aux évolutions technologiques et d’améliorer en continu leurs processus de gestion des données.

[GN⁺]

Avis Hacker News

• Expérience utilisateur pendant le développement du projet ChatDB.ai

  • En train de développer un projet similaire appelé ChatDB.ai.
  • L’expérience la plus concluante en combinant IA et SQL a consisté à renvoyer au LLM les erreurs du fournisseur SQL après chaque itération.
  • L’utilisation d’un wrapper de messages d’erreur formatés, recommandant fortement les requêtes sur les tables système, s’est révélée très efficace pour découvrir les informations de schéma.
  • Avec ces petits ajustements, le système est devenu étonnamment compétent pour trouver des requêtes nécessitant des jointures sur plus de quatre tables.

• Expérience personnelle avec GPT-4

  • A déjà réalisé un travail similaire avec GPT-4.
  • A vérifié la structure des tables avec la commande SHOW TABLE du CLI MySQL, puis a généré des requêtes montrant des indicateurs métier comme le taux d’abandon de panier à partir de ces tables.
  • A constaté que cette méthode fonctionne plutôt bien.

• Point de vue sceptique sur les systèmes qui traduisent le langage naturel en SQL

  • Tout en reconnaissant les efforts de développement de systèmes traduisant le langage naturel en SQL, reste sceptique en raison de la nature fondamentalement approximative et peu précise du langage naturel et des modèles.
  • Les bases de données SQL sont généralement conçues pour un traitement exact et précis de l’information, et l’introduction d’une couche approximative peut aggraver le problème.
  • Met en doute le caractère réellement productif de ces tentatives pour répondre efficacement aux besoins du monde réel.

• Intérêt pour des produits similaires, y compris des startups financées par YC

  • Suit plusieurs produits similaires comme Minds DB (YC W20), Buster (YC W24) et DB Pilot, et s’intéresse beaucoup à ce domaine.
  • Cherche également ce type de solution.

• Expérience avec un service de reporting basé sur duckdb

  • Dans l’ensemble, cela fonctionne bien, mais quelques problèmes apparaissent :
    • GPT-4 s’écarte parfois des exemples ou du schéma malgré un réglage de température faible.
    • Le service héberge des données génériques, mais les clients demandent la génération de rapports dans leur propre langage métier.
    • Le débogage des prompts LLM est délicat. Les clients peuvent facilement désorienter le modèle.
    • Fournit aux clients une « explication » de la requête générée afin de rendre transparent ce qui a été utilisé pour rédiger le rapport.

• Préoccupations et explication sur le fonctionnement du RAG

  • Exprime des réserves sur l’emploi du terme « train ».
  • Passe beaucoup de temps à expliquer que le RAG ne nécessite ni entraînement ni fine-tuning, mais seulement la préparation des données, leur découpage en chunks et leur vectorisation.

• Questions sur le problème des hallucinations des LLM

  • S’interroge sur la manière dont les LLM interprètent des notions temporelles comme « hier », ainsi que sur le fait que le SQL généré peut être syntaxiquement valide tout en ne correspondant pas à l’intention.
  • Il existe notamment un risque de produire de mauvais chiffres dans les requêtes d’agrégation comme MAX ou COUNT, et il faut alors lire soi-même le SQL pour le vérifier, ce qui va à l’encontre de l’objectif initial.

• Partage d’expérience avec un dataset et une technologie internes

  • A utilisé une technologie similaire pour développer un bot permettant aux employés internes de dialoguer avec des datasets structurés.
  • En pratique, cela fonctionne dans une certaine mesure, mais il y a plusieurs défis :
    • Il existe de nombreuses énumérations et de nombreux types de données spécifiques au métier qui ne figurent pas dans les modèles existants ; il faut donc les définir manuellement et les ajouter au prompt comme contexte.
    • Le traitement des questions liées au temps est difficile.
    • Comme les utilisateurs peuvent poser n’importe quelle question, il faut beaucoup d’exemples de requêtes SQL pour une seule table.
    • Il est difficile d’étendre cela à plusieurs tables, et on se demande s’il existe une méthode plus efficace.
    • A utilisé le modèle Llama2 70B Gen, mais se demande si d’autres modèles offrent de meilleures performances pour la génération de requêtes SQL.

• Expérience chez bit.io et réaction des clients

  • A fait un travail similaire chez bit.io, et les gens ont apprécié.
  • Plusieurs articles ont été publiés sur ce qui a été découvert au cours de ce travail ; l’entreprise a depuis été acquise par Databricks et le service a été arrêté.
  • Est prêt à répondre aux questions dans la mesure du possible.