Créer un agent NL2SQL avec Semantic Kernel 🚀

Passer du langage naturel au SQL (on parle d’agent NL2SQL) n’est pas une mince affaire. Pourtant, l’idée de pouvoir questionner une base de données en language naturel est terriblement séduisante, que ce soit pour aider des analystes non techniciens ou pour gagner du temps en développement. En tant que développeur et passionné d’IA, je me suis donc lancé un défi : concevoir moi-même un agent NL2SQL fiable en m’appuyant sur Semantic Kernel, tout en y intégrant des garde-fous pour éviter les dérapages.

Dans cet article, je vais vous raconter cette aventure, du constat des difficultés aux solutions mises en place (notamment un composant de Quality Assurance fait maison), avec du code et des exemples à l’appui. Attachez vos ceintures, on plonge dans le SQL assisté par IA ! 😉

Les défis de la génération de requêtes SQL en langage naturel

Traduire automatiquement une question en français en une requête SQL correcte est un défi technique de taille. Voici quelques difficultés majeures que j’ai rencontrées :

• Hallucinations de l’IA : Un LLM (modèle de langage) peut “inventer” des noms de tables ou de colonnes qui n’existent pas. Si le schéma de base de données n’est pas fourni explicitement dans le contexte, le modèle va deviner en s’appuyant sur sa connaissance générale… avec le risque de tomber à côté. Par exemple, demander « Donne-moi la liste des utilisateurs actifs » pourrait le pousser à générer une requête sur une table Users alors que votre base utilise Utilisateurs ou Accounts. Ces hallucinations donnent des requêtes SQL invalides ou inadaptées.
• Complexité des schémas : Les bases de données du monde réel ne sont pas de simples tables isolées. On a souvent des dizaines de tables reliées par des clés étrangères, avec des noms pas toujours évidents. Le modèle doit comprendre que « combien de commandes chaque client a passées » implique de joindre les tables Clients et Commandes, et peut-être LignesDeCommande selon la structure. Plus le schéma est large et technique, plus il est difficile pour l’IA de s’y retrouver. Fournir tout le schéma dans chaque requête n’est pas idéal (beaucoup de tokens, et confusion possible), il faut donc une stratégie pour que le modèle ait le contexte pertinent sans être noyé sous les détails.
• Requêtes SQL incorrectes ou incomplètes : Même si le LLM connaît bien le schéma, rien ne garantit qu’il va générer du premier coup une requête 100% correcte. Il peut oublier une condition (WHERE), mal utiliser une agrégation (GROUP BY), ou se tromper dans la syntaxe. Par exemple, j’ai vu des cas où l’IA propose une sous-requête là où un simple JOIN suffirait, ou tente un SELECT * inefficace sur une énorme table là où on attendait une sélection précise. En somme, le SQL produit est probable (selon le modèle) mais pas toujours exact. Il faut prévoir la possibilité que la requête nécessite des ajustements ou des vérifications.

En résumé, sans aide supplémentaire, l’IA générative seul n’est pas un expert SQL fiable. Lui donner la capacité de formuler des requêtes exploitables demande de lui fournir du contexte (schéma, exemples) et d’encadrer sa génération pour éviter les écarts. C’est exactement là où Semantic Kernel va entrer en jeu dans ma solution.

Risques à laisser une IA rédiger (et exécuter) du SQL 😨

Au-delà de la difficulté à obtenir une requête correcte, il y a une question cruciale : même si l’IA propose une requête SQL, peut-on l’exécuter en toute confiance sur la base de données ? Quelles sont les conséquences potentielles ? J’ai identifié plusieurs risques sérieux à mitiger avant de laisser mon agent NL2SQL branché sur une base de prod :

• Des requêtes dangereuses ou imprévues : Un LLM n’a pas de conscience du bien ou mal technique. Si on lui demande « Supprime tous les utilisateurs », il pourrait très bien sortir un DROP TABLE Users; ou un DELETE FROM destructeur. 😱 Évidemment, on ne veut jamais qu’une IA exécute ce genre de commande sans contrôle humain ! Même sans aller jusque-là, le modèle pourrait, par maladresse, générer une modification non voulue (par ex., confondre « liste des ventes » et « efface les ventes »). Interdire les opérations d’écriture (INSERT/UPDATE/DELETE…) est un prérequis de sécurité de base pour notre agent NL2SQL. On le limitera aux requêtes de lecture (SELECT) sur un ensemble autorisé de tables/vues.
• Performances et charge : Une requête mal fichue peut faire très mal à votre SGBD. Imaginons que l’agent génère un SELECT * sur une table de millions de lignes, ou une jointure cartésienne géante par oubli d’une condition de jointure… On risque de saturer le serveur, de lock des tables, bref d’affecter les performances pour tous les utilisateurs. Il faut donc contrôler la taille et la complexité des requêtes. Par exemple, éviter les requêtes sans clause WHERE sur des tables volumineuses, ou les agrégations sans filtre sur des milliards de données. Idéalement, l’agent devrait être capable de refuser ou d’ajuster une requête potentiellement trop lourde.
• Confidentialité des données : L’accès aux données doit être restreint à ce qui est légitime. Si l’agent NL2SQL est mis à disposition d’utilisateurs, il ne doit pas leur permettre d’extraire des données sensibles non autorisées. Par exemple, un employé lambda ne devrait pas pouvoir demander « Montre-moi les salaires de tous les employés » si ce n’est pas dans ses droits. Dans mon cas, j’ai conçu l’agent pour un usage en interne, mais il faut garder à l’esprit la nécessité d’intégrer l’agent dans le système d’authentification et de permissions existant. Aussi, sur un plan plus technique, envoyer le schéma complet ou des données brutes au modèle (surtout s’il est hébergé dans le cloud) peut poser des problèmes de conformité ou de fuite de données. Il convient de ne partager avec l’IA que le minimum requis (par ex., descriptions de schéma, et seulement pour les éléments nécessaires à la requête).
• Résultats incorrects ou inappropriés : Si l’agent comprend mal la question, il peut très bien fournir une réponse parfaitement formulée… mais fausse ou hors sujet 😕. Le danger est qu’un utilisateur non averti prenne la réponse pour argent comptant. Imaginons que l’agent, suite à une confusion, réponde avec des chiffres qui ne correspondent pas vraiment à la question posée. Cela peut induire de mauvaises décisions. On touche ici à la confiance dans le système : il faut idéalement que l’agent exprime aussi son niveau de certitude, ou s’abstienne de répondre quand il n’est pas sûr de lui. Mieux vaut aucune réponse qu’une réponse erronée en business intelligence !

En somme, brancher un agent LLM sur une base de données sans filet de sécurité, c’est s’exposer à des soucis de sécurité, de performance et de fiabilité. Conscient de ces risques, j’ai orienté le développement de mon agent NL2SQL autour d’un principe fondamental : jamais de requête non maîtrisée. Chaque requête candidate doit passer par des filtres de qualité avant d’être exécutée pour de vrai. Heureusement, j’ai pu m’appuyer sur Semantic Kernel pour mettre en place ces garde-fous.

Conception de l’agent NL2SQL avec Semantic Kernel

La bonne nouvelle, c’est qu’il existe maintenant des outils pour orchestrer des LLMs et du code natif de façon fluide. Comme je l’avais évoqué dans un précédent billet, des orchestrateurs comme Semantic Kernel de Microsoft permettent de combiner le meilleur des deux mondes : la compréhension du langage par l’IA, et l’exécution fiable de logique métier (ici du SQL) par du code classique. C’est exactement l’approche que j’ai suivie pour construire mon agent NL2SQL.

Architecture générale de l’agent

Mon agent “DatabaseAgent” se compose de plusieurs briques qui collaborent pour transformer une question en langage naturel en une réponse basée sur les données :

1. Mémoire du schéma : Dès l’initialisation de l’agent, j’utilise le Kernel Memory de Semantic Kernel pour stocker une représentation du schéma de la base de données. Concrètement, je parcours les tables, colonnes et relations (par exemple les clés étrangères) et j’enregistre ces informations dans une mémoire sémantique. Ainsi, l’agent a en quelque sorte une connaissance de la structure de la base, qu’il peut retrouver au besoin via des similarités sémantiques. Plutôt que de fournir tout le schéma à chaque question, l’agent peut récupérer juste les éléments pertinents (tables, champs concernés) en fonction de la question posée, un peu à la manière d’une recherche documentaire (Retrieval Augmented Generation). Cette étape réduit les risques d’hallucination (puisque l’IA a accès aux vrais noms) et allège la charge cognitive du modèle.
2. Interprétation de la question & génération du SQL : Lorsqu’une question utilisateur est posée, l’agent construit un prompt qui combine la question en langage naturel et les informations de schéma pertinentes retrouvées en mémoire (noms de tables, descriptions, etc. liés aux termes de la question). Il envoie ensuite ce contexte au modèle de langage (par exemple GPT-4) en lui demandant de formuler la requête SQL correspondante. C’est une fonction sémantique typique de Semantic Kernel : on fournit un template de prompt et le kernel le remplit avec les données (question + schéma) avant d’appeler l’IA. Le résultat attendu de cette fonction est du texte SQL. À ce stade, on obtient une proposition de requête, par ex. « SELECT … FROM … JOIN … WHERE … ».
3. Vérifications de la requête (Quality Assurance) : Avant exécution, la requête SQL générée passe par une série de filtres de qualité (j’y reviens dans la section suivante). C’est une étape cruciale où l’agent va évaluer si la requête est sûre et pertinente. S’il y a le moindre doute (requête non pertinente, potentiellement dangereuse ou trop coûteuse), l’agent peut soit ajuster sa requête, soit refuser de l’exécuter tel quel. Cette logique de vérification est implémentée sous forme de composants injectables (grâce à la configuration de Semantic Kernel en C#) pour garder la solution modulaire.
4. Exécution en base de données : Si la requête passe les filtres de QA, on la considère suffisamment fiable pour être exécutée. L’agent utilise alors un plugin natif (en l’occurrence, un appel à la base de données via une connexion .NET classique) pour exécuter le SQL et récupérer les résultats. C’est ici que la séparation des responsabilités est précieuse : l’IA a produit la requête, mais c’est le moteur SQL réel qui fait le calcul sur les données, garantissant un résultat exact et à jour. Semantic Kernel permet d’enchaîner cela proprement : après la fonction sémantique de génération SQL, on appelle une fonction native (C#) d’exécution SQL. Tout ça s’orchestre de façon transparente via l’agent.
5. Réponse à l’utilisateur : Enfin, l’agent formule une réponse à l’intention de l’utilisateur. Selon le cas, ça peut être brute (par ex. afficher un tableau de résultats ou un nombre), ou réintégré dans une phrase en français. Par exemple « 42 commandes ont été passées en 2021. ». Cette dernière étape peut être réalisée soit par du code (formatage des données) soit par le LLM lui-même (en lui demandant de présenter le résultat dans une phrase), ou un mélange des deux. Dans la première version de mon agent, je me suis concentré sur le bon fonctionnement du triptyque question->SQL->résultat, la mise en jolis mots de la réponse pourra être affinée plus tard si besoin.

L’IA apporte la souplesse du langage naturel, et le code apporte la fiabilité de l’exécution. 🍒

Aperçu du code de l’agent

Pour les plus curieux, voici à quoi ressemble l’initialisation de l’agent NL2SQL en C# avec Semantic Kernel :

// 1. Configuration du Kernel et de la mémoire
var memory = new KernelMemoryBuilder()
    .Build(); // on configure ici le stockage de la mémoire sémantique (ex: Azure Cognitive Search, VolatileMemory, etc.)

var kernelBuilder = Kernel.Builder;
kernelBuilder.WithCompletionService(myCompletionConfig);  // config du modèle LLM (OpenAI/Azure OpenAI...)
kernelBuilder.WithEmbeddingGenerationService(myEmbeddingsConfig);  // service d'embeddings pour la mémoire
// On injecte la connexion DB dans la dépendance du kernel, pour que l'agent l'utilise
kernelBuilder.Services.AddSingleton<DbConnection>(sp => new SqliteConnection(connectionString));

IKernel kernel = kernelBuilder.Build();

// 2. Création de l'agent base de données
var agent = await DBMSAgentFactory.CreateAgentAsync(kernel, memory);

// 3. Préparation de la question utilisateur
var question = "Quelle est la croissance du nombre de clients par année ?";
var chatHistory = new ChatHistory(question, AuthorRole.User);

// 4. Invocation de l'agent (génération du SQL, exécution et récupération de la réponse)
var responses = await agent.InvokeAsync(chatHistory);

// 5. Récupération de la réponse formulée par l'agent
Console.WriteLine(responses[0].Message);

Quelques explications sur ce bout de code : on construit d’abord un Kernel Semantic Kernel avec un service de complétion (le LLM, par ex. GPT-4) et un service d’embeddings (pour la similarité sémantique en mémoire). On ajoute également un DbConnection (ici une base SQLite pour l’exemple) dans les services, ce qui va permettre à l’agent d’exécuter physiquement les requêtes. Ensuite on crée l’agent avec DBMSAgentFactory.CreateAgentAsync(kernel, memory) – cette méthode instancie toute la machinerie NL2SQL en utilisant le kernel et la mémoire de schéma fournie.

Puis on envoie une question sous forme de ChatHistory (c’est l’objet que l’agent utilise pour garder le contexte de conversation, ici on a juste un utilisateur qui pose une question). L’appel agent.InvokeAsync(chatHistory) déclenche toute la séquence : le prompt est élaboré, le LLM génère le SQL, le filtre de qualité vérifie, la requête est exécutée en base, et la réponse finale est produite. On obtient une liste de messages de réponse (dans responses), le premier étant typiquement la réponse de l’assistant. Un petit Console.WriteLine et hop, on voit ce que l’agent répond.

À ce stade, si tout se passe bien, on a un agent capable de comprendre une question en français et de retourner une réponse issue des données, le tout sans intervention manuelle. Mais attendons – ai-je vraiment envie qu’il exécute n’importe quelle requête que le LLM propose ? Certainement pas ! C’est ici qu’intervient la partie Quality Assurance que j’ai intégrée.

Quality Assurance : le garde-fou intégré à l’agent SQL 🤖🛡️

Pour rendre l’agent utilisable en conditions réelles, j’ai développé un composant de Quality Assurance (QA) spécifique à la génération de SQL. Son but : assurer la sûreté et la pertinence des requêtes avant exécution. Ce composant s’insère naturellement dans l’architecture Semantic Kernel grâce à la configuration des services (DI) du kernel.

Concrètement, qu’a fait mon agent lors de l’étape de vérification de la requête SQL ? Voici les principaux contrôles mis en place dans cette première version :

• Filtrage de pertinence de la requête (Query Relevancy Filter) : C’est le premier filtre QA que j’ai activé, et probablement le plus original. L’idée est de vérifier que la requête SQL générée correspond bien à l’intention de la question utilisateur, pour détecter les cas où le modèle partirait hors sujet. Comment vérifier cela automatiquement ? J’utilise en fait le LLM une seconde fois : l’agent demande au modèle de générer une description textuelle de la requête SQL qu’il s’apprête à exécuter, puis il compare cette description à la question initiale de l’utilisateur via une similarité cosinus sur des embeddings. Si la description de la requête s’écarte trop de la question (en dessous d’un certain seuil de similarité, par exemple 0.8), l’agent considère que la requête n’est pas pertinente et la rejette. En clair, si le LLM hallucine une requête qui fait autre chose que répondre à la question posée, on le détecte et on évite de l’exécuter. Cette approche est très utile pour attraper les délires du modèle du genre : Question: « Combien de clients actifs ? » -> Requête halluciné: « SELECT * FROM LogsServeur… » (rien à voir avec les clients actifs). Avec le filtre de pertinence, ce genre de dérive serait bloqué net. Bien entendu, on peut ajuster le seuil de similarité pour être plus ou moins strict.
• Restrictions sur le SQL : En plus de la pertinence, le composant QA peut appliquer des règles métiers sur la requête. Par exemple, dans mon implémentation j’ai prévu de filtrer tout ce qui n’est pas une requête de sélection simple. L’agent n’a aucune raison d’exécuter un DELETE, UPDATE ou DROP dans le cadre des questions utilisateurs classiques, donc autant le bannir explicitement. De même, je peux limiter l’accès à certaines tables sensibles, ou exiger la présence de certaines clauses (par exemple un WHERE quand on s’attend à un filtrage par date). Pour l’instant, ces règles sont rudimentaires, mais l’infrastructure est en place pour en rajouter facilement.
• Contrôle de performance (à envisager) : Une amélioration en cours de réflexion est d’analyser le plan d’exécution estimé de la requête (par exemple via un EXPLAIN) avant de la lancer pour de bon. L’agent pourrait ainsi détecter qu’une requête va probablement scanner 10 millions de lignes et décider de ne pas l’exécuter tel quel. Ce n’est pas encore implémenté dans la version actuelle, mais l’architecture modulaire du filtre QA le permettrait. On pourrait imaginer un filtre qui compte le nombre de jointures, détecte les SELECT * sans limite, etc., et qui renvoie un avertissement ou optimise la requête en ajoutant un TOP 100 par exemple.

L’ensemble de ces contrôles de Quality Assurance vit dans un sous-module dédié de l’agent. J’ai publié le code source complet sur GitHub (voir le repo SemanticKernel.Agents.DatabaseAgent et son package QualityAssurance). L’activation du filtre de pertinence est très simple via la configuration du Kernel, comme illustré ci-dessous :

// Activation des filtres de Quality Assurance pour l'agent DB
kernelBuilder.Services.UseDatabaseAgentQualityAssurance(options =>
{
    options.EnableQueryRelevancyFilter = true;
    options.QueryRelevancyThreshold = 0.8f;
    // On pourrait activer/configurer d'autres filtres ici à l'avenir
});

Ici, j’enregistre dans les services du kernel un composant de QA qui va automatiquement intercepter les tentatives d’exécution de requête de l’agent. Le fait de définir EnableQueryRelevancyFilter = true suffit à brancher le fameux filtre de pertinence décrit plus haut. On fixe aussi le seuil de similarité à 0.8 (valeur empirique qui pourra être ajustée selon les retours). À chaque requête, juste avant l’exécution sur la base, ce filtre va faire son boulot et éventuellement bloquer l’exécution en levant une exception ou en renvoyant une réponse d’erreur contrôlée de l’agent.

L’architecture est prévue pour être extensible. On peut créer ses propres filtres QA en implémentant l’interface IQueryExecutionFilter. Par exemple, si je veux empêcher les requêtes retournant plus de 1000 lignes, je pourrais coder un filtre personnalisé qui, une fois la requête générée, ajoute LIMIT 1000 à la fin ou refuse la requête si pas de LIMIT. Il suffirait ensuite de l’enregistrer ainsi :

kernelBuilder.Services.AddTransient<IQueryExecutionFilter, CustomQueryExecutionFilter>();

(où CustomQueryExecutionFilter est ma classe maison qui vérifie/altère le SQL dans sa méthode OnQueryExecutionAsync).

Grâce à ce système de filtres chaînés, je peux donc renforcer progressivement la robustesse de l’agent sans toucher au cœur de la génération. Chaque filtre agit comme une couche de validation indépendante. Pour le moment, le filtre de pertinence a déjà grandement sécurisé les choses dans mes tests, en évitant les exécutions hors-sujet. À l’avenir, j’en ajouterai d’autres pour couvrir les aspects performance et sécurité de façon encore plus pointue.

Illustration : l’agent NL2SQL en action 🎬

Il est temps de voir concrètement ce que donne notre agent NL2SQL. Prenons un scénario simple : j’ai une base de données de commerce avec des clients et des commandes, et je veux savoir quels sont les 3 clients qui ont dépensé le plus chez nous. Autrement dit, pour chaque client on fait la somme du montant de ses commandes, puis on classe par montant décroissant et on prend le top 3.

En langage naturel, je pose la question : « Quels sont les 3 clients qui ont dépensé le plus ? ». Voici comment l’agent va traiter cela :

1. Compréhension de la question : L’agent détecte qu’on parle de « clients » et de « dépenses ». Il interroge sa mémoire de schéma et trouve que la base contient une table Clients et une table Commandes liées (chaque commande a un client). Il remarque aussi la notion de top 3, donc qu’on attend un tri décroissant sur un montant.
2. Génération de la requête SQL : Fort de ces infos, le LLM propose une requête SQL du genre : SELECT c.Nom, SUM(o.Total) AS MontantTotal FROM Clients c JOIN Commandes o ON o.ClientId = c.Id GROUP BY c.Nom ORDER BY MontantTotal DESC LIMIT 3; Ici, on suppose que les tables s’appellent Clients et Commandes avec Total étant le montant de la commande, et que ClientId est la clé étrangère. La requête SQL agrège les montants par client, trie par le total décroissant et limite aux 3 premiers – cela correspond bien à la question.
3. Vérification QA : Avant d’exécuter, l’agent QA prend la requête ci-dessus et demande au LLM une description : « sélectionne le nom des clients avec la somme de leurs commandes, trié par le montant total décroissant, et limite aux 3 plus gros ». Il compare avec la question initiale « 3 clients qui ont dépensé le plus » et obtient une forte similarité – logique, ça correspond. Le filtre de pertinence donne son feu vert 👍. La requête n’a pas l’air dangereuse (c’est un SELECT agrégé sur un volume raisonnable), donc aucun autre filtre ne la bloque non plus.
4. Exécution SQL : L’agent envoie alors la requête à la base de données. Le SGBD exécute le calcul et renvoie un petit tableau de résultats, par exemple : Nom du client MontantTotal Alice 12 340 € Bob 9 870 € Eve 8 150 €
5. Réponse formulée : L’agent compile la réponse à retourner à l’utilisateur. Ça peut être sous forme de phrase : « Les 3 clients ayant le plus dépensé sont Alice (12 340 €), Bob (9 870 €) et Eve (8 150 €). » Parfait, exactement ce qu’on voulait savoir !

Dans cet exemple, tout s’est bien passé du premier coup. Imaginons maintenant un cas où le LLM se trompe de colonne, par exemple en essayant de sommer une colonne qui n’existe pas. Le filtre de pertinence pourrait ne pas le voir (puisque la description resterait dans le sujet de la question), mais l’exécution SQL elle-même lèverait une erreur (colonne inconnue). Mon agent est capable d’attraper cette exception et pourrait alors soit la remonter telle quelle, soit tenter une stratégie de secours (par exemple, reformuler la question différemment ou demander plus de contexte). Pour l’instant, j’ai opté pour la solution simple : en cas d’erreur SQL, l’agent renvoie un message d’échec au user du genre « Désolé, je n’ai pas réussi à interpréter la question. » afin de ne pas laisser l’utilisateur avec une stacktrace technique. Libre à nous ensuite d’analyser l’erreur côté dev pour améliorer l’agent.

Autre situation intéressante : si l’utilisateur posait une question très floue ou ambiguë, le LLM pourrait générer une requête à côté de la plaque. Dans ce cas, le filtre de pertinence détecterait une faible correspondance entre la question et la requête. Par exemple « clients les plus fidèles » pourrait être mal compris et donner une requête sur la mauvaise métrique – le filtre pourrait la bloquer. L’agent pourrait alors répondre « Je ne suis pas certain de comprendre, pouvez-vous préciser votre question ? ». Ce genre de rebond n’est pas encore totalement implémenté, mais c’est envisagé : faire de l’affinement de requête en redemandant des précisions à l’utilisateur quand on n’est pas sûr de nous.

Conclusion et perspectives d’évolution

Développer cet agent NL2SQL m’a permis de mesurer à quel point comprendre une question humaine et la traduire en requête SQL est un défi passionnant, mêlant NLP et ingénierie logicielle. Grâce à Semantic Kernel, j’ai pu assembler une solution où ChatGPT et la base de données travaillent main dans la main : l’un pour le langage naturel, l’autre pour les données. Le tout agrémenté d’une couche de Quality Assurance indispensable pour éviter les mauvaises surprises.

Les premiers résultats sont encourageants : sur des cas simples, l’agent fournit la bonne réponse avec un SQL propre, et sur des cas tordus, les garde-fous évitent de faire n’importe quoi. Bien sûr, tout n’est pas parfait et il reste pas mal de boulot pour rendre l’agent infaillible et généraliste. Parmi les perspectives d’évolution :

• Élargir la palette des filtres QA : comme évoqué, ajouter des filtres de performance (détection de requêtes trop lourdes) et de sécurité (blocage de certains patterns ou termes sensibles) rendra l’agent encore plus robuste. On pourrait aussi intégrer un système de quota ou de monitoring pour éviter les abus.
• Gestion des permissions/utilisateurs : à terme, imaginer que l’agent s’intègre à un environnement avec des utilisateurs authentifiés, et qu’il sache limiter les données qu’il retourne en fonction des droits de chacun. Cela nécessiterait de croiser l’agent NL2SQL avec la couche sécurité de la base (par exemple, ne permettre que des vues pré-autorisées).
• Amélioration du prompt et du modèle : peaufiner les instructions données au LLM pour orienter la génération SQL (par ex., l’encourager à utiliser tel indice ou telle convention sémantique). Peut-être tester d’autres modèles spécialisés en génération de code SQL, ou fine-tuner un modèle sur des exemples de notre schéma pour gagner en fiabilité.
• Expérience utilisateur : travailler la façon dont l’agent répond. Actuellement, il renvoie le résultat brut ou une phrase sommaire. On pourrait le rendre plus conversationnel, qu’il explique comment il a trouvé la réponse, ou même qu’il affiche un joli tableau formaté dans une interface web. L’intégration dans un chatbot avec mémoire contextuelle ouvrirait aussi la porte à des requêtes de suivi (enchaîner des questions : « Montre-moi le top 3 clients. Maintenant pour chacun, détaille leurs 5 dernières commandes. » etc.).

En partageant cet outil en open-source, j’espère aussi recueillir des feedbacks et contributions de la communauté. 👉 Le code complet de l’agent NL2SQL avec sa Quality Assurance est disponible sur GitHub (kbeaugrand/SemanticKernel.Agents.DatabaseAgent). N’hésitez pas à l’essayer, à l’adapter à vos bases de données, et à proposer des améliorations !

En conclusion, doter ChatGPT (ou un autre LLM) de solides compétences en SQL est à notre portée, à condition de l’entourer de garde-fous et de l’inscrire dans une architecture hybride IA + code. Les hallucinations et les erreurs de l’IA ne sont pas une fatalité dès lors qu’on les canalise avec des approches comme le RAG, des filtres de pertinence, et une exécution contrôlée. Mon agent NL2SQL n’en est qu’à ses débuts, mais il montre déjà qu’un assistant IA peut collaborer avec une base de données de manière sûre et productive. J’ai commencé cette aventure avec l’envie de rendre ChatGPT fort en SQL ; je la poursuis avec la conviction que ce genre d’outil a un énorme potentiel pour faciliter l’accès à l’information dans nos systèmes. 🚀

Et vous, prêt à poser vos prochaines questions SQL en toute sérénité à votre nouvel assistant base de données ? 😉