Introduction
Lors d’un échange avec l’un de nos clients, la question de l’automatisation des requêtes SQL est rapidement devenue un sujet de discussion. Notre client nous a fait part du gain de temps potentiel en adoptant une approche où les requêtes SQL pourraient être générées à partir de questions formulées en langage naturel. Intrigués par cette perspective, nous avons décidé d’explorer cette piste.
Afin d’utiliser des LLM (Grand modèle de langage) tout en ayant une structure modulaire et évolutive, notre choix s’est naturellement porté sur le framework Langchain qui semble être l’étoile montante des frameworks IA.
Langchain est une bibliothèque qui utilise le traitement du langage naturel (NLP) qui permet en partie de convertir des phrases en requêtes SQL. Cette approche promet de simplifier l’accès aux données pour les utilisateurs non techniques, tout en améliorant l’efficacité des processus d’analyse de données.
Chez The Coding Machine, nous avons exploré différentes options afin d’automatiser et simplifier nos workflows liés à la gestion des données, notamment dans le cas de multiples statistiques sur une base de données client. Après avoir examiné les avantages potentiels de Langchain, nous avons décidé de mettre ce framework à l’épreuve en utilisant la base de données open source Chinook. Cet article a pour ambition de vous guider à travers notre expérience, en détaillant comment nous avons configuré notre environnement de travail avec Google Colab et Jupyter Notebook.
Notre objectif est de partager cette expérience afin que d’autres puissent tirer parti de ces outils pour améliorer leurs propres processus d’analyse et de gestion des données. Que vous soyez analyste de données, ingénieur ou simplement curieux des nouvelles technologies, cet article vous fournira des outils pratiques pour optimiser votre utilisation des bases de données.
Pourquoi utiliser LangChain ?
Pour répondre à cette question, je vous invite à aller lire l’article d’introduction qui traite de la génération de requêtes depuis un modèle d’intelligence artificielle.
Présentation de la Base de Données Chinook
1. Qu’est-ce que Chinook_DB ?
Chinook_DB est une base de données open source largement utilisée dans l’enseignement et les exemples pratiques de gestion de bases de données relationnelles. Initialement conçue pour représenter un magasin de musique en ligne, Chinook_DB offre une structure de données réaliste et plus ou moins complexe, idéale pour simuler des scénarios réels d’interrogation et d’analyse de données.
Cette base de données comprend plusieurs tables interconnectées représentant divers aspects d’une entreprise de vente de musique. Voici quelques-unes des principales tables et leurs relations :
- Albums : Contient des informations sur les albums disponibles à la vente.
- Artistes : Liste des artistes associés à chaque album.
- Clients : Informations sur les clients qui ont acheté des albums.
- Commandes : Détails de chaque commande effectuée par les clients.
- Pistes audio : Liste des pistes audio disponibles à la vente, avec des informations telles que le nom, la durée et l’album auquel elles appartiennent.
- Employés : Détails sur les employés de l’entreprise.
Chinook_DB est structurée de manière à refléter les relations typiques entre les entités dans une plateforme e-commerce de musique.
2. Utilité de Chinook_DB
Chinook_DB est particulièrement utile pour les démonstrations et les apprentissages pratiques dans le domaine de la gestion de bases de données relationnelles. En raison de sa structure bien définie et de ses données réalistes, Chinook_DB permet aux utilisateurs d’explorer des requêtes SQL et de simuler divers scénarios d’analyse de données. Dans le cadre de notre exploration de Langchain et la génération de requêtes SQL, Chinook_DB offre un environnement idéal pour illustrer l’efficacité et la précision de Langchain dans la transformation des questions en langage naturel en requêtes SQL fonctionnelles.
3. Modèle de données
Environnement de développement
La mise en place d’un environnement de développement est important afin d’explorer efficacement les capacités de Langchain dans la génération de requêtes SQL à partir de langage naturel. Dans cette partie, nous détaillerons les étapes pour configurer votre environnement de travail avec Google Colab et Jupyter Notebook, deux plateformes populaires pour le développement interactif en Python.
1. Choix de l’environnement
Google Colab (cloud) : Google Colab est un service de notebook Jupyter hébergé par Google qui permet d’écrire et d’exécuter du code Python dans le cloud, sans nécessiter de configuration locale. Il offre un accès gratuit à des processeurs et de la RAM pour des calculs intensifs, ce qui peut être avantageux pour le traitement de données volumineuses.
Jupyter Notebook (local) : Jupyter Notebook est une application web open source qui vous permet de créer et de partager des documents contenant du code, des équations, des visualisations et du texte explicatif. Il est idéal pour le développement interactif et l’analyse de données.
En optant pour Google Colab et Jupyter Notebook, nous avons choisi des outils qui non seulement facilitent le développement et le débogage, mais qui améliorent aussi la documentation, la collaboration. Ces plateformes offrent des avantages significatifs par rapport à l’utilisation de fichiers Python séparés, rendant le processus de test et de mise en œuvre de Langchain plus efficace et plus convivial.
2. Installation des outils
Pour commencer, assurez-vous d’avoir un compte Google pour utiliser Google Colab et d’avoir installé Python sur votre machine pour Jupyter Notebook. Voici les étapes générales pour configurer votre environnement :
Google Colab
1. Ouvrez un navigateur web et accédez à Google Colab
2. Créez un nouveau notebook ou importez un notebook existant depuis Google Drive ou GitHub
Avantages :
- Python est complètement disponible en dernière version et il est très simple d’installer des librairies (“pip install langchain” par exemple)
- Pas besoin d’un environnement local
- Partage et collaboration optimale
Jupyter Notebook
1. Installez Jupyter Notebook en utilisant pip si ce n’est pas déjà fait (Les frameworks populaire tel que JetBrains ou Visual Studio ont des modules pour Jupyter)
2. Jupyter pourra alors être complètement intégré à votre IDE
Avantages :
- Pas de dépendance au cloud
- Moins de déconnexion intempestive
- Un environnement local plus souple et maîtrisable
Pratique : Mise en place technique
Dans cette partie, nous allons voir comment utiliser Langchain concrètement étape par étape. L’objectif de cet article est d’arriver à un résultat où nous pourrons poser une question naturelle et le modèle devra nous répondre une requête SQL fonctionnelle puis l’exécuter directement afin d’avoir le résultat.
Notez que nous allons aborder une infime partie de ce que propose Langchain cependant nous ne pouvons pas couvrir la totalité dans cet article, si ce framework vous intéresse, rendez-vous sur la documentation officielle.
⚠️ Attention ⚠️
Comme le précise Langchain, connecter une base de données de production à un LLM n’est pas sans risque, des instructions DML pourraient sans doute être exécutées par une personne malveillante. Il est donc très important de mettre en place une stratégie de sécurité :
– Dupliquer la base de données avec une lecture seule (Master / slave par exemple)
– Anonymiser les informations critiques tels que les users (Données personnelles, mots de passes, etc.) ou les API key
Avant d’aller plus loin, voici les éléments que nous allons aborder :
1. L’utilisation du Toolkit SQL Database
Un toolkit est un ensemble de tools qui permettent d’exécuter un groupe de fonction mis à disposition. Dans notre exemple, le Toolkit SQL Database va nous permettre d’avoir un ensemble de fonctions pré paramétré et notamment avec des prompts déjà mis en place.
2. L’utilisation d’un agent
L’agent, dans notre contexte, est un module proposé par Langchain qui agit comme un intermédiaire entre l’utilisateur et la base de données. Il est capable de comprendre des requêtes en langage naturel, de les traduire en requêtes SQL en suivant les fonctions mise à disposition par le Toolkit.
3. L’utilisation de LangSmith
LangSmith va nous permettre d’avoir une visibilité sur l’utilisation de Langchain, nombres de tokens par requête, coûts, organisation des fonctions, input, output, etc.
Cela permet de déboguer plus facilement du code.
Pour la suite de cet article nous allons utiliser Google Colab, ce qui permettra de vous partager le Notebook de cet article
Installation des paquets
Cette ligne installera tous les paquets nécessaires au code que nous allons utiliser.
!pip install langchain langchain-openai langchain_experimentalNote : Le
!devant pip dans Google Colab est utilisé pour exécuter des commandes de shell directement depuis une cellule du notebook. En mettant!pip, vous dites à Google Colab d’exécuter la commande pip
Variable d’environnement
Google Colab met à disposition un gestionnaire de clés, vous pouvez donc renseigner de façon sécurisée vos secrets et les appeler directement dans le code.
# Getting env variables from Google Colab secrets
from google.colab import userdata
import os
# OpenAI key
os.environ["OPENAI_API_KEY"] = userdata.get('OPENAI_API_KEY')
# LangSmith
os.environ["LANGCHAIN_TRACING_V2"] = "true"
os.environ["LANGCHAIN_API_KEY"] = userdata.get('LANGCHAIN_API_KEY')Initialisation de la base de données
Nous allons vérifier que la base de données existe car Colab supprime très régulièrement les données. Si vous souhaitez persister vos données, regardez l’intégration Colab de Google Drive.
from langchain.sql_database import SQLDatabase
db_path = "[path]/chinook_data.db"
if not os.path.exists(db_path):
raise FileNotFoundError("Database file not found.")
db = SQLDatabase.from_uri(f"sqlite:///{db_path}")Nous allons maintenant instancier notre classe Chat model afin de traiter la demande de l’utilisateur. LangChain va maintenant nous permettre de créer un agent, celui-ci pourra appeler à de multiples reprises le chat model ainsi que la base de données.
from langchain_openai import ChatOpenAI
from langchain_community.agent_toolkits import create_sql_agent
# Instanciate the class ChatOpenAI
chat_model = ChatOpenAI(model_name='gpt-4o', temperature=0.5)
# Create a new sql agent
agent_executor = create_sql_agent(model, db=db, agent_type="openai-tools", verbose=True)
# Run the user query
agent_executor.invoke("How much artists are in the db ?")Nous sommes maintenant prêts à réaliser quelques tests. Le paramètre “verbose” va nous permettre de consulter le chemin parcouru par notre Toolkit pour arriver à un résultat. Notez qu’il est également possible (et recommandé) de consulter ce parcours sur LangSmith.
Nous allons prendre pour exemple un cas simple pour l’instant, nous voulons savoir combien d’artistes sont présents dans la base de données.
Notre question sera donc : How many artists are in the db ?
Note : Les tests semblent montrer que les requêtes peuvent être écrites en Français mais nous le ferons en anglais dans cet article
La question est simple, si nous reprenons notre modèle de données, il n’y aucune relation, voici donc la requête :
SELECT COUNT(*) FROM artists;Lançons maintenant le script :
> Entering new SQL Agent Executor chain...
Invoking: `sql_db_list_tables` with `{}`
albums, artists, customers, employees, genres, invoice_items, invoices, media_types, playlist_track, playlists, tracks
Invoking: `sql_db_schema` with `{'table_names': 'artists'}`
CREATE TABLE artists (
"ArtistId" INTEGER NOT NULL,
"Name" NVARCHAR(120),
PRIMARY KEY ("ArtistId")
)
/*
3 rows from artists table:
ArtistId Name
1 AC/DC
2 Accept
3 Aerosmith
*/
Invoking: `sql_db_query_checker` with `{'query': 'SELECT COUNT(*) as artist_count FROM artists;'}`
```sql
SELECT COUNT(*) as artist_count FROM artists;
```
Invoking: `sql_db_query` with `{'query': 'SELECT COUNT(*) as artist_count FROM artists;'}`
[(275,)]There are 275 artists in the database.
> Finished chain.
{
'input': 'How much artists are in the db ?',
'output': 'There are 275 artists in the database.'
}Le résultat est cohérent et celui attendu. Nous pouvons voir les différentes fonctions utilisées par notre toolkit. Pour aller plus loin, allons jeter un oeil sur LangSmith.
Sans rentrer dans les détails, cela fera peut être l’objet d’un article sur ce sujet, mais nous pouvons constater que 4 différentes fonctions avec des tâches bien précises sont appelées.
1. sql_db_query
Cette fonction a pour objectif de recevoir une requête SQL correcte (syntaxiquement parlant) et de l’exécuter. Dès lors que l’exécution de celle-ci renvoie une erreur, le prompt précise qu’il doit essayer de réécrire la requête.
Si un problème de “Unknown column” est présent, alors il faut rappeler la fonction “sql_db_schema” afin de vérifier le schéma.
Dans le cas où l’exécution de la requête est un problème de syntaxe SQL, alors il rappelle “sql_db_query_checker” et tente de réécrire la requête.
2. sql_db_schema
Cette fonction a pour objectif de recevoir en entrée une liste de tables séparées par des virgules. La sortie est le schéma et les lignes d’exemples des tables de l’entrée.
Une vérification peut être faite afin de vérifier que les tables existent en appelant “sql_db_list_tables”
3. sql_db_list_tables
Renvoie toutes les tables de la base de données.
4. sql_db_query_checker
Cette fonction est appelée avant l’exécution de la requête SQL afin de vérifier sa syntaxe.
Note : Il faut bien comprendre ici que les Tools (ou fonctions) sont appelées par le LLM. Il est capable de comprendre une question et/ou un problème et donc d’appeler un tool en fonction du problème rencontré.
Allons un peu plus loin maintenant, si nous analysons notre modèle de données, l’idéal serait d’avoir une demande qui recherche dans plus de trois tables différentes pour ajouter un peu de complexité.
Imaginons que nous souhaitions connaître les clients les plus éclectiques, cherchons ceux qui ont acheté des pistes dans plus de 9 genres musicaux différents et calculons combien ils ont dépensé au total. Idéalement, nous souhaiterions avoir les clients avec le plus de genres affichés en premier.
Voici le prompt : Identify customers who purchased tracks from more than nine different genres, calculate the total amount spent by these customers and sort the result by highest number of genre
Voici l’output de l’agent :
> Entering new SQL Agent Executor chain...
Invoking: `sql_db_list_tables` with `{}`
albums, artists, customers, employees, genres, invoice_items, invoices, media_types, playlist_track, playlists, tracks
Invoking: `sql_db_schema` with `{'table_names': 'customers, genres, invoice_items, invoices, tracks'}`
CREATE TABLE customers (
"CustomerId" INTEGER NOT NULL,
"FirstName" NVARCHAR(40) NOT NULL,
"LastName" NVARCHAR(20) NOT NULL,
"Company" NVARCHAR(80),
"Address" NVARCHAR(70),
"City" NVARCHAR(40),
"State" NVARCHAR(40),
"Country" NVARCHAR(40),
"PostalCode" NVARCHAR(10),
"Phone" NVARCHAR(24),
"Fax" NVARCHAR(24),
"Email" NVARCHAR(60) NOT NULL,
"SupportRepId" INTEGER,
PRIMARY KEY ("CustomerId"),
FOREIGN KEY("SupportRepId") REFERENCES employees ("EmployeeId")
)
/*
3 rows from customers table:
CustomerId FirstName LastName Company Address City State Country PostalCode Phone Fax Email SupportRepId
1 Luís Gonçalves Embraer - Empresa Brasileira de Aeronáutica S.A. Av. Brigadeiro Faria Lima, 2170 São José dos Campos SP Brazil 12227-000 +55 (12) 3923-5555 +55 (12) 3923-5566 luisg@embraer.com.br 3
2 Leonie Köhler None Theodor-Heuss-Straße 34 Stuttgart None Germany 70174 +49 0711 2842222 None leonekohler@surfeu.de 5
3 François Tremblay None 1498 rue Bélanger Montréal QC Canada H2G 1A7 +1 (514) 721-4711 None ftremblay@gmail.com 3
*/
CREATE TABLE genres (
"GenreId" INTEGER NOT NULL,
"Name" NVARCHAR(120),
PRIMARY KEY ("GenreId")
)
/*
3 rows from genres table:
GenreId Name
1 Rock
2 Jazz
3 Metal
*/
CREATE TABLE invoice_items (
"InvoiceLineId" INTEGER NOT NULL,
"InvoiceId" INTEGER NOT NULL,
"TrackId" INTEGER NOT NULL,
"UnitPrice" NUMERIC(10, 2) NOT NULL,
"Quantity" INTEGER NOT NULL,
PRIMARY KEY ("InvoiceLineId"),
FOREIGN KEY("TrackId") REFERENCES tracks ("TrackId"),
FOREIGN KEY("InvoiceId") REFERENCES invoices ("InvoiceId")
)
/*
3 rows from invoice_items table:
InvoiceLineId InvoiceId TrackId UnitPrice Quantity
1 1 2 0.99 1
2 1 4 0.99 1
3 2 6 0.99 1
*/
CREATE TABLE invoices (
"InvoiceId" INTEGER NOT NULL,
"CustomerId" INTEGER NOT NULL,
"InvoiceDate" DATETIME NOT NULL,
"BillingAddress" NVARCHAR(70),
"BillingCity" NVARCHAR(40),
"BillingState" NVARCHAR(40),
"BillingCountry" NVARCHAR(40),
"BillingPostalCode" NVARCHAR(10),
"Total" NUMERIC(10, 2) NOT NULL,
PRIMARY KEY ("InvoiceId"),
FOREIGN KEY("CustomerId") REFERENCES customers ("CustomerId")
)
/*
3 rows from invoices table:
InvoiceId CustomerId InvoiceDate BillingAddress BillingCity BillingState BillingCountry BillingPostalCode Total
1 2 2009-01-01 00:00:00 Theodor-Heuss-Straße 34 Stuttgart None Germany 70174 1.98
2 4 2009-01-02 00:00:00 Ullevålsveien 14 Oslo None Norway 0171 3.96
3 8 2009-01-03 00:00:00 Grétrystraat 63 Brussels None Belgium 1000 5.94
*/
CREATE TABLE tracks (
"TrackId" INTEGER NOT NULL,
"Name" NVARCHAR(200) NOT NULL,
"AlbumId" INTEGER,
"MediaTypeId" INTEGER NOT NULL,
"GenreId" INTEGER,
"Composer" NVARCHAR(220),
"Milliseconds" INTEGER NOT NULL,
"Bytes" INTEGER,
"UnitPrice" NUMERIC(10, 2) NOT NULL,
PRIMARY KEY ("TrackId"),
FOREIGN KEY("MediaTypeId") REFERENCES media_types ("MediaTypeId"),
FOREIGN KEY("GenreId") REFERENCES genres ("GenreId"),
FOREIGN KEY("AlbumId") REFERENCES albums ("AlbumId")
)
/*
3 rows from tracks table:
TrackId Name AlbumId MediaTypeId GenreId Composer Milliseconds Bytes UnitPrice
1 For Those About To Rock (We Salute You) 1 1 1 Angus Young, Malcolm Young, Brian Johnson 343719 11170334 0.99
2 Balls to the Wall 2 2 1 None 342562 5510424 0.99
3 Fast As a Shark 3 2 1 F. Baltes, S. Kaufman, U. Dirkscneider & W. Hoffman 230619 3990994 0.99
*/
Invoking: `sql_db_query_checker` with `{'query': 'SELECT c.CustomerId, c.FirstName, c.LastName, COUNT(DISTINCT t.GenreId) AS GenreCount, SUM(i.Total) AS TotalSpent\nFROM customers c\nJOIN invoices i ON c.CustomerId = i.CustomerId\nJOIN invoice_items ii ON i.InvoiceId = ii.InvoiceId\nJOIN tracks t ON ii.TrackId = t.TrackId\nGROUP BY c.CustomerId, c.FirstName, c.LastName\nHAVING GenreCount > 9\nORDER BY GenreCount DESC\nLIMIT 10;'}`
responded: To identify customers who purchased tracks from more than nine different genres and calculate the total amount spent by these customers, I need to join several tables and perform the necessary aggregations.
Here's the plan:
1. Join the `customers`, `invoices`, `invoice_items`, and `tracks` tables to get the necessary data.
2. Group by `CustomerId` and count the distinct `GenreId` for each customer.
3. Filter out customers who purchased from more than nine different genres.
4. Calculate the total amount spent by these customers.
5. Sort the results by the highest number of genres.
Let's write and check the query.
```sql
SELECT c.CustomerId, c.FirstName, c.LastName, COUNT(DISTINCT t.GenreId) AS GenreCount, SUM(i.Total) AS TotalSpent
FROM customers c
JOIN invoices i ON c.CustomerId = i.CustomerId
JOIN invoice_items ii ON i.InvoiceId = ii.InvoiceId
JOIN tracks t ON ii.TrackId = t.TrackId
GROUP BY c.CustomerId, c.FirstName, c.LastName
HAVING GenreCount > 9
ORDER BY GenreCount DESC
LIMIT 10;
```
Invoking: `sql_db_query` with `{'query': 'SELECT c.CustomerId, c.FirstName, c.LastName, COUNT(DISTINCT t.GenreId) AS GenreCount, SUM(i.Total) AS TotalSpent\nFROM customers c\nJOIN invoices i ON c.CustomerId = i.CustomerId\nJOIN invoice_items ii ON i.InvoiceId = ii.InvoiceId\nJOIN tracks t ON ii.TrackId = t.TrackId\nGROUP BY c.CustomerId, c.FirstName, c.LastName\nHAVING GenreCount > 9\nORDER BY GenreCount DESC\nLIMIT 10;'}`
[(57, 'Luis', 'Rojas', 12, 415.6200000000001), (45, 'Ladislav', 'Kovács', 11, 446.6200000000003), (3, 'François', 'Tremblay', 10, 338.62000000000006), (14, 'Mark', 'Philips', 10, 334.6200000000001), (17, 'Jack', 'Smith', 10, 352.62000000000035), (24, 'Frank', 'Ralston', 10, 378.6200000000001), (34, 'João', 'Fernandes', 10, 352.62000000000035), (37, 'Fynn', 'Zimmermann', 10, 388.6200000000001)]Here are the customers who purchased tracks from more than nine different genres, along with the total amount they spent, sorted by the highest number of genres:
1. **Luis Rojas** - Purchased from 12 genres, Total Spent: $415.62
2. **Ladislav Kovács** - Purchased from 11 genres, Total Spent: $446.62
3. **François Tremblay** - Purchased from 10 genres, Total Spent: $338.62
4. **Mark Philips** - Purchased from 10 genres, Total Spent: $334.62
5. **Jack Smith** - Purchased from 10 genres, Total Spent: $352.62
6. **Frank Ralston** - Purchased from 10 genres, Total Spent: $378.62
7. **João Fernandes** - Purchased from 10 genres, Total Spent: $352.62
8. **Fynn Zimmermann** - Purchased from 10 genres, Total Spent: $388.62Ce cas est très intéressant, car la réponse n’est pas bonne.
Notez qu’il y a une subtilité, dans cette base de données les informations financières sont gérées dans deux tables différentes, invoices et invoice_items.
Invoice_items correspond à l’achat d’une piste. Si un client achète 2 pistes, nous aurons alors 2 lignes liées à invoices.
Pour illustrer cet exemple, prenons un cas concret de la base de données, la facture id 1 a deux lignes rattachées donc un client a acheté 2 pistes pour un prix unitaire de 0,99 €. Nous avons donc 1,98 € dans la colonne du total de la ligne invoices.
Lorsque nous réalisons une requête, si nous ne regroupons pas les résultats (GROUP BY), nous aurons alors les lignes invoices dupliquées autant de fois qu’il y a de ligne invoice_items rattachées. Utiliser alors la fonction SUM ne donnera pas le bon résultat, ce qui est notre problème actuellement.
Si j’exécute cette requête nous pouvons constater ce résultat
SELECT i.* FROM invoices i
LEFT JOIN invoice_items ii ON i.InvoiceId=ii.InvoiceId
WHERE i.InvoiceId=1
Faire un SUM sur Total n’est pas absolument pas la bonne solution.
Si nous reprenons le résultat de notre requête SQL nous pouvons constater que Luis Rojas a dépensé 415,62 €. Ce montant provient de cette fonction SUM(i.Total) AS TotalSpent
Le fait d’avoir écrit the total amount spent by, le LLM se base donc sur la colonne total.
Nous ne pouvons pas maîtriser parfaitement l’interprétation du LLM et c’est d’ailleurs tout son intérêt, nous avons donc trouvé une solution afin de corriger ce petit problème.
L’agent utilisé est “create_sql_agent » et il prend en paramètre un suffixe. Nous pouvons donc créer un prompt complémentaire qui ajoute des instructions spécifiques.
Nous pouvons ajouter le code suivant :
[...]
suffix = """
Here is some additionnal information about the database,
there are two tables that deal with the subject of financial amount.
The 'Invoices' table and the 'Invoice_items' table. You must always
rely on the 'quantity' and 'UnitPrice' columns in order to make
calculations relating to a financial aspect. You should NEVER
use the 'Total' column of the 'Invoices' table. Use this information
only when necessary.
"""
agent_executor = create_sql_agent(model, db=db, agent_type="openai-tools", verbose=True, suffix=suffix)
[...]Nous précisons au LLM la subtilité de cette base en ce qui concerne l’aspect financier de la demande. A présent, dès lors que nous demanderons au LLM une information financière, il utilisera cette fonction SUM(ii.UnitPrice * ii.Quantity)
Après avoir relancé le même prompt avec ce changement, voici notre résultat, qui lui est correct !
1. **Luis Rojas** - Purchased from 12 genres, Total Amount Spent: $46.62
2. **Ladislav Kovács** - Purchased from 11 genres, Total Amount Spent: $45.62
3. **François Tremblay** - Purchased from 10 genres, Total Amount Spent: $39.62
4. **Mark Philips** - Purchased from 10 genres, Total Amount Spent: $37.62
5. **Jack Smith** - Purchased from 10 genres, Total Amount Spent: $39.62
6. **Frank Ralston** - Purchased from 10 genres, Total Amount Spent: $43.62
7. **João Fernandes** - Purchased from 10 genres, Total Amount Spent: $39.62
8. **Fynn Zimmermann** - Purchased from 10 genres, Total Amount Spent: $43.62Conclusion
Les résultats sont plutôt bons, les requêtes sont construites de manière cohérente. Cependant, il faut prendre en compte le nom des tables ainsi que des colonnes de la base de données.
En effet, le modèle de langage interprète les demandes et recherche des cohérences dans le nom des tables et des colonnes. Si les tables sont mal nommées, cela ne fonctionnera pas.
Modifier ces éléments dans une base de données existante peut se révéler assez complexe. Comme vu précédemment, il est donc possible d’ajouter du contexte au LLM afin de créer une logique entre les tables et les colonnes.
Il devient donc très intéressant de travailler par itération sur une base de données existante et les résultats pourront être satisfaisants.
Merci d’avoir suivi cet article, afin de tester par vos propres moyens, vous trouverez le lien ci-dessous afin de tester par vous même.
