Les LLM au Service de la self BI : Construire un convertisseur de Langage Naturel en SQL
Introduction
Imaginez pouvoir interagir avec vos données comme avec un ami : poser des questions, récupérer des informations, les modifier, et obtenir des résultats instantanément. C'est ce que permettent des outils comme ChatGPT, Mistral AI, Llama, et bien d’autres. Aujourd'hui, ces solutions sont largement utilisées, notamment pour leur simplicité et leur efficacité. Cependant, peu de personnes comprennent les technologies sous-jacentes : l'intelligence artificielle (IA) et le machine learning (ML).
Dans cet article, nous allons explorer ce qu'est un modèle de langage de grande taille, ou Large Language Model (LLM) en anglais. Nous examinerons l'utilisation des requêtes en langage naturel dans le contexte de la Self-BI, et verrons comment implémenter un LLM avec des outils comme Vanna et Streamlit, et comment exploiter pleinement cette technologie pour aller encore plus loin. C’est parti !
Qu’est-ce que le LLM ?
Un LLM est un modèle d'IA qui utilise le deep learning pour comprendre et générer du texte en langage naturel. Les LLMs, comme GPT-3, sont entraînés sur de vastes quantités de données textuelles comme des livres, des articles et des conversations, ce qui leur permet de saisir le contexte et la subtilité du langage humain.
Ils sont composés de millions, voire de milliards de paramètres ajustés pour produire des réponses cohérentes et contextuellement appropriées. Pour ce faire, ils s'appuient sur une architecture de type transformers. Un Transformer est un modèle présenté en 2017 dans un article désormais très connu, intitulé « Attention is All You Need », par des équipes de Google et de l'Université de Toronto. Le Transformer repose sur des mécanismes d'attention ainsi que sur des réseaux de neurones entièrement connectés, permettant de traiter les données non plus de manière séquentielle, c'est-à-dire mot par mot, mais en accordant à chaque mot l'attention des autres mots. Cela rend le traitement plus rapide et efficace tout en comprenant les relations complexes au sein du texte.
Pourquoi utiliser les LLM ?
Dans le contexte de la Business Intelligence (BI), l’exploration et l’exploitation de la donnée ont toujours été un frein pour les utilisateurs métier non techniques qui devaient s’appuyer sur des Data Analysts ou des Analytics Engineers pour sortir le moindre indicateur ou information des données dont ils disposaient. Avec des solutions LLM, ces utilisateurs peuvent maintenant interagir avec des systèmes de données complexes en utilisant des phrases simples et courantes, sans avoir besoin de maîtriser des langages de programmation comme SQL ou des outils d'analyse de données complexes.
Ainsi, on remarque un gain de temps considérable pour les tâches d’activation de la donnée comme les rapports, les dashboards et l’utilisation de modèles d'IA. En effet, les processus qui nécessitaient auparavant l'intervention de spécialistes en data science ou en informatique peuvent désormais être exécutés directement par les utilisateurs métiers, ce qui simplifie et accélère la prise de décision.
Tutoriel: Création d’un module Text-to-SQL avec Vanna
Dans cette section, nous examinerons un cas d'utilisation basé sur un jeu de données de test disponible ici. Pour ce faire, nous utiliserons Vanna pour l'analyse des données et Streamlit pour l'interface utilisateur.
Vanna est un package Python utilisant la technique de Recherche-Augmentation-Generation (RAG) pour générer des requêtes SQL à partir de texte en langage naturel, grâce à des modèles de Langage de Grande Échelle (LLM). Dans notre cas, le LLM utilisé sera celui développé par OpenAI.
Streamlit est une librairie open source Python permettant de créer rapidement et facilement des applications web interactives. Cette librairie simplifie la visualisation des données en fournissant une interface utilisateur très simple d'utilisation.
Configuration du modèle
Tout d'abord, importons les bibliothèques Python nécessaires pour entraîner notre modèle :
import vannafrom vanna.remote
import VannaDefault
Ensuite, configurez Vanna en récupérant la clé API ainsi que le modèle contenant les métadonnées, qui, dans ce cas, est notre jeu de données test provenant du compte Vanna. Puis, connectons nous à la base de données Postgres:
api_key = vanna.get_api(‘email@gmail.com’)
vanna_model_name = ‘dummy_model_name’
vn = VannaDefault(model=vanna_model_name, api_key=api_key)
vn.connect_to_postgres(host=’localhost’, dbname=’dummy_db_name’, user=’dummy_user’, password=’*****’, port=’5432’)
Maintenant que le modèle et la base de données sont configurés, il nous reste à fournir au modèle le schéma des données stockées dans la base PostgreSQL pour procéder à la phase d'entraînement :
df_information_schema = vn.run_sql(“SELECT * FROM INFORMATION_SCHEMA.COLUMNS”)
plan = vn.get_training_plan_generic(df_information_schema)
vn.train(plan=plan)
Configuration de l’interface
Afin de mettre en place l'interface utilisateur il nous faut importer les packages Python ainsi que les modèles:
import streamlit as st
from vanna.remote import VannaDefault
api_key = st.secrets["general"]["api_key"]
model_name = st.secrets["general"]["model_name"]
vn = VannaDefault(model=model_name, api_key=api_key)
vn.connect_to_postgres(host='localhost', dbname='RetailSalesData', user='adamsohail', password='modeo', port='5432')
A noter que la récupération de la clé API et du nom pour le modèle se fait à travers un fichier .streamlit/secrets.toml structuré de la manière suivante:
[general]
api_key = "api_key"
model_name = "model_name"
Ce code permet de générer des requêtes SQL en fonction des questions saisies par l'utilisateur :
my_question = st.session_state.get("my_question", default=None)
if my_question is None:
my_question = st.text_input("Ask me a question that I can turn into SQL", key="my_question")
else:
st.title(my_question)
sql = vn.generate_sql(my_question)
st.code(sql, language='sql')
df = vn.run_sql(sql)
st.dataframe(df, use_container_width=True)
fig = vn.get_plotly_figure(plotly_code=vn.generate_plotly_code(question=my_question, sql=sql, df=df), df=df)
st.plotly_chart(fig, use_container_width=True)
st.button("Ask another question", on_click=lambda: st.session_state.clear())
Analyse des résultats
Conclusion: Le projet fonctionne bien pour des requêtes très simples mais présente plusieurs limitations pour:
- Les cas complexes, l'utilisateur doit bien connaître le modèle de données pour générer la requête correcte.
- Les jointures proposées ne sont pas toujours appropriées (JOIN vs LEFT JOIN).
- Les requêtes mal optimisées peuvent engendrer des coûts significatifs.
Bien que les résultats du Text-to-SQL présentent certaines limitations, il est possible de les surmonter par des ajustements techniques appropriés.
Comment aller plus loin ?
Afin de pallier les problèmes rencontrés précédemment, on pourrait utiliser une couche sémantique pour structurer et clarifier les données de manière plus efficace. Cette approche permettrait non seulement de définir précisément les termes et contextes, mais aussi de cartographier les relations entre les différentes sources de données. Enfin, intégrer des contrôles de sécurité robustes garantirait que les données sensibles sont protégées.
- Terminologie et contexte: La couche sémantique comprend les définitions des termes et du contexte permettant d'obtenir des résultats cohérents. Prenons l'exemple du terme « marge brute ». Ce terme est spécifié dans la couche sémantique, ainsi, lorsque les utilisateurs métiers recherchent des informations sur la « marge brute » dans leur outil de BI, le système est capable d'identifier quelles données extraire en se basant sur les sources de données disponibles.
- Relation entre les sources et les données: La couche sémantique relie les termes et concepts aux sources de données disponibles. Cela implique de préciser quelles tables et colonnes de la base de données correspondent à chaque terme. Cette cartographie permet aux outils de BI d'extraire les données les plus pertinentes.
- Données confidentielles: Au-delà de l'analyse de données, l'aspect sécurité ne doit pas être négligé. Les consommateurs de données doivent avoir des rôles définis qui leur permettent d'accéder uniquement aux informations autorisées. Une problématique potentielle serait l'accès à des résultats via des données intermédiaires qui, par défaut, ne devraient pas apparaître, car elles pourraient être sensibles ou non conformes au RGPD.
Que vous cherchiez à simplifier l'accès aux données ou à automatiser des requêtes complexes, nous avons l'expertise pour vous accompagner dans cette révolution digitale.
Contactez-nous pour découvrir comment nous pouvons adapter ces technologies à vos besoins spécifiques et accélérer votre prise de décision !