IA : laisser les utilisateurs générer des requêtes en langage naturel ?
Puisque que les entreprises doivent gérer des données de plus en plus complexes et qu’il devient nécessaire d’y accéder de manière rapide et simple, on a conduit plusieurs tests pour voir s’il était possible de laisser les utilisateurs faire des requêtes en langage naturel. On s’est dit que cela pouvait faire un super article !
Donc, dans cet article, nous montrons comment l’intégration de l’API d’OpenAI permet vraiment d’ouvrir l’accès aux données aux utilisateurs non-experts.
Note : Nous utilisons le modèle GPT4 de OpenAI mais d’autres modèles capables de générer du code sont disponibles tel que Mistral.
1. La data encore la data
L’accès à des données précises et pertinentes permet de prendre des décisions ou d’optimiser des processus. Pourtant, l’accès et l’interrogation des bases de données restent souvent complexes. Les requêtes SQL peuvent être difficiles à maîtriser parce qu’elles nécessitent des compétences techniques.
Les utilisateurs finaux, souvent non familiers avec les langages de requête et les structures de bases de données, peuvent peiner à interpréter les résultats. Alors, pour surmonter ces défis, les entreprises investissent dans des solutions de BI qui simplifient l’accès aux données et automatisent l’analyse.
Les outils de visualisation de données permettent aux décideurs de tous niveaux de comprendre et d’exploiter les informations sans nécessiter une expertise technique approfondie. Mais il y a encore des limites, par exemple, on ne peut évidemment manipuler que les données qui sont intégrées et y connecter de nouveaux outils n’est pas forcément simple. La personnalisation des requêtes peut être complexe (sans parler du coût de ces outils).
Bref, on peut encore faire des progrès ! Et, une bonne piste est l’IA…
2. L’API d’OpenAI pourrait bien être une révolution dans l’accès aux données
L’API d’OpenAI représente une avancée majeure dans le domaine du traitement du langage naturel (NLP), offrant des capacités impressionnantes pour comprendre et générer du texte en langage humain. Cette API permet aux utilisateurs de poser des questions et de recevoir des réponses dans un langage clair et naturel, rendant les interactions avec les systèmes beaucoup plus simples.
L’API peut même transformer la manière dont les utilisateurs interagissent avec les bases de données en permettant de convertir des questions en langage naturel en instructions SQL.
Prenons un exemple complexe : un utilisateur pourrait vouloir obtenir des informations sur les tendances de vente et de retour de produits dans une entreprise. En langage naturel, l’utilisateur pourrait demander : « Quels sont les cinq produits les plus vendus et les plus retournés au cours des six derniers mois, et quelle est la différence moyenne de revenus entre les ventes et les retours pour ces produits ? ». Si, on lui a préalablement donné le modèle de données, l’API ChatGPT est capable de traduire cette demande en une série de requêtes SQL :
WITH TopProducts AS (
SELECT product_id,
SUM(quantity_sold) AS total_sales,
SUM(quantity_returned) AS total_returns
FROM sales
WHERE sale_date >= DATE_SUB(CURDATE(), INTERVAL 6 MONTH)
GROUP BY product_id
ORDER BY total_sales DESC
LIMIT 5
)
SELECT p.product_name, tp.total_sales, tp.total_returns,
(tp.total_sales * p.sale_price - tp.total_returns * p.return_price) / 6 AS average_revenue_difference
FROM TopProducts tp
JOIN products p ON tp.product_id = p.product_id;Bon, c’est pas mal mais comment l’intégrer dans mon application ?
3. “Call Me”
Non, ce n’est pas pour parler de Blondie (oui, j’ai des réfs de vieux) mais OpenAi vient de développer un mode “function calling” particulièrement intéressant.
Le « function calling » permet au LLM (Large Language Model) modèle d’identifier quand une tâche requiert une exécution de fonction et d’appeler directement une fonction définie dans l’application de l’utilisateur. Cette fonctionnalité permet de donner la possibilité au modèle d’exécuter des actions que nous allons définir comme envoyer un e-mail, d’interroger des bases de données, de récupérer des informations, et bien plus encore…
Donc, on peut développer une solution qui marcherait selon le principe suivant :
Pas mal non ? L’avantage est que l’on donne pas ses données à OpenAi.
4. Enjeux de sécurité
Il y a deux risques avec ce type de développement. Le premier est que si quelqu’un réussit à tromper OpenAi, il pourrait faire une requête INSERT ou DELETE (voire DROP) au lieu d’une requête SELECT. L’autre serait de réussir à sortir de son « domaine » (la liste des données que l’on a le droit de lire).
Donc, l’approche est bonne si l’on est administrateur et qu’on a le droit de tout voir, mais si l’on n’a le droit de voir qu’une partie des données, il est très difficile de garantir que la requête générée ne retournera pas des données confidentielles.
Dans ces conditions, il faudrait mettre en place un parseur de requêtes qui ajoute des filtres à la volée. Cela n’est pas trivial, mais c’est possible.
D’autres modèles que OpenAi peuvent aussi répondre au problème de sécurité des données. Des modèles comme Mistral peuvent tourner en local et sont plutôt bons pour la génération de code.
Une autre solution (proposée par nos équipes à Lyon) serait d’avoir une base de données répliquée et étanche. Dans ce cas là, plus de problème pour la manipulation des données (mais il reste quand même le second risque sur la confidentialité de certaines données).
Bref, à défaut d’avoir une connexion directe avec la BDD, l’API d’OpenAi peut quand même aider pour rédiger/corriger une requête SQL ce qui peut déjà faire gagner beaucoup de temps !
Conclusion
On ne va pas se mentir, la question de laisser l’IA accéder aux données peut vous rendre frileux, on le comprend. Mais on pense quand même que c’est une opportunité sans précédent pour transformer la manière dont les entreprises interagissent avec leurs données. En simplifiant l’accès aux données et en rendant les requêtes plus intuitives, cette manière d’exploiter l’IA est un vrai use case de l’IA (pour une fois ?).
