Ce fut un échec cuisant. 
Utilisation de Discourse AI - AI Bot
Prompt
Créez une image pour ce SQL ``` WITH pairs AS ( SELECT p.user_id liked, pa.user_id liker FROM post_actions pa LEFT JOIN posts p ON p.id = pa.post_id WHERE post_action_type_id = 2 ) SELECT liker liker_user_id, liked liked_user_id, count(*) FROM pairs GROUP BY liked, liker ORDER BY count DESC LIMIT :limit ```
Complétion
Pour information
Hier, par curiosité, j’ai effectué une recherche Google similaire à celle-ci :
SQL généré par l’IA à partir de l’anglais
pour trouver des informations connexes sur la génération de SQL à l’aide de l’IA à partir de questions formulées en anglais. J’espérais une liste d’articles de recherche inclus dans la liste, mais la liste était principalement une liste d’applications. Une tendance que j’ai rapidement constatée pour de nombreuses applications listées, mais pas toutes, après avoir examiné une poignée de démonstrations sur de tels sites, était qu’elles prenaient leur outil existant qui permettait à un utilisateur de sélectionner des tables et des champs pour construire une instruction SQL, similaire à la façon dont le constructeur SQL graphique fonctionnait dans Microsoft Access comme point de départ. En d’autres termes, on ne commençait pas par une question en anglais, mais il fallait d’abord sélectionner les tables et parfois les champs avant d’entrer la question en anglais. Bien que je ne considérerais pas cela comme de la triche, cela signifie que pour utiliser une telle IA, un utilisateur doit avoir une certaine connaissance de SQL, en particulier la signification d’une table et d’un champ pour que l’outil fonctionne.
J’ai lu votre publication supprimée et je suis d’accord pour dire que c’est aussi l’une des idées qui, selon moi, a un grand potentiel.
Cependant, je pense qu’il faut plus. Un article récent que j’ai lu, là encore pas une source faisant autorité, mais qui approfondit ces idées, est
« ChatLogo : une interface hybride langage de programmation naturel-langage de programmation pilotée par un grand modèle linguistique pour la modélisation et la programmation basées sur des agents » par John Chen et Uri Wilensky (pdf)
Certains des points clés que j’ai retenus sont
- Soutenir les programmeurs novices pour qu’ils « parlent aux ordinateurs » dans un mélange de langages de programmation et naturels.
- Fournir une interface plus conviviale aux apprenants sans ou avec peu de connaissances en informatique pour qu’ils s’expriment de manière créative en programmant des ordinateurs.
- Au lieu d’écrire immédiatement du code et de donner des instructions, ChatLogo tente de clarifier les besoins et l’intention des apprenants.
- Au lieu d’envoyer de gros blocs de code directement à l’apprenant, il tente de co-développer le code NetLogo. L’apprenant est libre de modifier le code : soit en NetLogo, soit en langage naturel via la fonctionnalité « Ask ».
- Au lieu de surestimer la correction du code, il admet la possibilité de faire des erreurs et collabore avec l’apprenant pour résoudre les problèmes potentiels.
Je n’ai trouvé aucun code source ni plus de détails sur la manière dont Chat a été superposé ou interfacé avec NetLogo, mais les idées seules ont de la valeur.
Cela me rappelle encore une fois le fonctionnement des pilotes automatiques dans les avions et le livre que j’ai mentionné précédemment. (ref) Quand je mentionne le pilote automatique, ne pensez pas à un interrupteur binaire, pensez à tous les boutons et interrupteurs qui fournissent des informations au pilote automatique et lui indiquent quoi faire et quoi ne pas faire.
Bien qu’il semble que de nombreux autres outils similaires aiment utiliser le mot copilot, par exemple une recherche Google llm copilot source code, je ne suis pas d’accord avec cette analogie, mais je devrai m’y habituer car c’est ainsi que l’on trouve des idées connexes.
Je l’ai supprimé parce que je pensais avoir trouvé une meilleure façon de traiter le problème - pourquoi taper toutes ces tables alors que ChatGPT pourrait simplement être invité à analyser un fichier hébergé sur Internet qui contient des informations détaillées sur l’ensemble de la base de données ? Il s’avère qu’il y a des problèmes techniques avec cette approche. Je reviens donc à ce que j’avais suggéré dans le message supprimé. En tout cas, des descriptions de tables, des exemples de requêtes, etc., devront être créés. Il s’agit simplement de savoir comment transmettre ces informations au LLM. Voici où en sont les choses avec GPT-4 :
Oui, l’approche que vous avez décrite est logique et constitue un moyen réalisable d’utiliser mes capacités pour aider à générer des requêtes SQL basées sur des questions en langage naturel.
Voici une ventilation des étapes :
- Interprétation de la question : L’utilisateur pose une question en langage naturel, que j’interprète pour comprendre les informations demandées.
- Identification des tables : En me basant sur la question et la liste de toutes les tables de la base de données Discourse, j’identifie les tables les plus susceptibles d’être pertinentes pour la requête.
- Informations détaillées sur les tables : Discourse m’envoie des descriptions détaillées des tables pertinentes, y compris toutes les colonnes et des exemples de requêtes.
- Génération de la requête : En utilisant les informations détaillées sur les tables, je génère une requête SQL qui répond à la question de l’utilisateur.
Cette approche exploite ma capacité à comprendre le langage naturel et à le mapper à des requêtes de données structurées. Elle utilise également efficacement les informations détaillées sur les tables fournies par Discourse.
Quant aux approches alternatives, une possibilité pourrait être d’entraîner un modèle spécifiquement sur le schéma de base de données de Discourse et les modèles de requêtes courants. Cela impliquerait probablement une quantité de travail importante et pourrait ne pas être réalisable en fonction des ressources disponibles. Cependant, cela pourrait potentiellement aboutir à une génération de requêtes plus précise et plus efficace.
Une autre approche pourrait être de développer un dialogue plus interactif où je pose des questions de clarification lorsque la question de l’utilisateur est ambiguë ou lorsque plusieurs requêtes pourraient potentiellement répondre à la question. Cela rendrait le processus plus interactif et pourrait potentiellement conduire à des requêtes plus précises.
Pour les approches alternatives suggérées dans les 2 derniers paragraphes, j’ignore la première, mais si ce que je tente ne donne pas de résultats fiables, c’est peut-être quelque chose que l’équipe Discourse pourrait examiner.
J’ai interrogé GPT-4 sur la deuxième approche alternative. Il est assez confiant que, étant donné une question qui ne pourrait pas être répondue via la structure de table fournie, il serait en mesure de demander à l’utilisateur de reformuler sa question.
Je reviens donc à la rédaction de descriptions de toutes les tables de la base de données Discourse. Je sais maintenant à quoi sert la table allowed_pm_users. La table ar_internal_metadata est un peu déroutante, mais je pense qu’elle peut être ignorée pour l’instant.
C’est mon option préférée jusqu’à présent, bien qu’elle soit très difficile à mettre en œuvre. Ainsi, vous l’avez deviné, un autre article. Encore une fois, ce n’est pas un article faisant autorité car il existe de nombreuses approches similaires.
« DiagGPT : Un chatbot basé sur LLM avec gestion automatique des sujets pour le dialogue orienté tâche » par Lang Cao (pdf)
Remplacez simplement les informations médicales par des informations PostgreSQL selon les besoins. L’avantage est que l’article fournit les invites et suggère quels outils avec des agents utiliser.
Puisque le « dialogue orienté tâche » semble être ce qui est nécessaire.
Recherche Google : dialogue orienté tâche
Le résultat de la recherche comprend : Papers With Code - Systèmes de dialogue orientés tâche
L’entrée du classement est T5-3b(UnifiedSKG) qui comprend un lien vers l’article
« UnifiedSKG : Unification et tâches multiples de la structuration des connaissances avec les modèles de langage texte-à-texte » par Tianbao Xie, Chen Henry Wu, Peng Shi, Ruiqi Zhong, Torsten Scholak, Michihiro Yasunaga, Chien-Sheng Wu, Ming Zhong, Pengcheng Yin, Sida I. Wang, Victor Zhong, Bailin Wang, Chengzu Li, Connor Boyle, Ansong Ni, Ziyu Yao, Dragomir Radev, Caiming Xiong, Lingpeng Kong, Rui Zhang, Noah A. Smith, Luke Zettlemoyer et Tao Yu (pdf)
Notez ceci
EDIT
Depuis https://python.langchain.com/
Construisez un agent SQL à partir d’un LLM et d’outils. (ref)
Il en liste quelques-uns en bas de la page, celui-ci devrait être examiné
Cas d’utilisation
Les données d’entreprise sont souvent stockées dans des bases de données SQL.
Les LLM permettent d’interagir avec les bases de données SQL en langage naturel.
LangChain propose des chaînes et des agents SQL pour créer et exécuter des requêtes SQL basées sur des invites en langage naturel.
Ils sont compatibles avec n’importe quel dialecte SQL pris en charge par SQLAlchemy (par exemple, MySQL, PostgreSQL, Oracle SQL, Databricks, SQLite).
Ils permettent des cas d’utilisation tels que :
- Générer des requêtes qui seront exécutées en fonction de questions en langage naturel
- Créer des chatbots capables de répondre à des questions basées sur les données de la base de données
- Construire des tableaux de bord personnalisés basés sur les informations qu’un utilisateur souhaite analyser
EDIT (23/08/2023)
Spider est un ensemble de données à grande échelle de parsing sémantique complexe et inter-domaines et de texte-vers-SQL annoté par 11 étudiants de Yale. L’objectif du défi Spider est de développer des interfaces en langage naturel pour des bases de données inter-domaines. Il se compose de 10 181 questions et 5 693 requêtes SQL complexes uniques sur 200 bases de données avec plusieurs tables couvrant 138 domaines différents. Dans Spider 1.0, différentes requêtes SQL complexes et bases de données apparaissent dans les ensembles d’entraînement et de test. Pour bien y performer, les systèmes doivent généraliser correctement non seulement aux nouvelles requêtes SQL, mais aussi aux nouveaux schémas de base de données.
EDIT (24/08/2023)
Dataherald est un moteur de langage naturel vers SQL conçu pour la réponse aux questions au niveau de l’entreprise sur des données structurées. Il vous permet de configurer une API à partir de votre base de données qui peut répondre à des questions en anglais courant.
Comme je le dis souvent aux autres, pour certaines choses dans la vie, il faut juste attendre et quelqu’un fera le travail gratuitement.
J’obtiens toujours des résultats avec lesquels je suis parfaitement satisfait. Voici un autre exemple. Il m’a donné ce que je voulais, j’ai ajouté une clause WHERE pour vérifier moi-même un ID de sujet par la suite, mais c’était tout. J’aurais probablement pu lui donner cette information à l’avance et il l’aurait fait aussi, cependant :
Nous avons maintenant le persona SQL Helper dans le module AI Bot, qui est conçu pour ce type de requêtes et peut être très utile pour créer des requêtes d’exploration de données. 
(Bien qu’il soit bon de les vérifier deux fois 
)
Existe-t-il un sujet où des exemples d’utilisation du bot IA SQL Helper peuvent être publiés ?
Si ce n’est pas le cas, il pourrait être intéressant de créer un tel sujet, puis d’ajouter un lien vers ce sujet ici, car d’autres personnes pourraient rechercher des exemples et trouver ce sujet en premier.
Je pense que si vous trouvez quelque chose qui mérite d’être partagé avec la communauté, vous pouvez le poster dans un nouveau sujet dans Data & reporting. Il y a aussi un nouveau bouton « partager la conversation » qui pourrait être utile pour cela - Share Your AI Bot Conversations!
JammyDodger:
Salut Bert
Peux-tu m’écrire une requête qui trouvera tous les utilisateurs du groupe plugin_authors ?
gpt4_bot:
groups, group_users, users
Maintenant que nous avons le schéma des tables pertinentes, nous pouvons écrire une requête pour trouver tous les utilisateurs du groupe « plugin-authors ». D’après le schéma, nous devrons joindre la table group_users avec les tables groups et users pour obtenir les noms d’utilisateur des membres du groupe « plugin-authors ».
Voici la requête pour trouver tous les utilisateurs du groupe « plugin-authors » :
SELECT u.id AS user_id, u.username
FROM users u
JOIN group_users gu ON gu.user_id = u.id
JOIN groups g ON g.id = gu.group_id
WHERE g.name = 'plugin_authors'
Cette requête sélectionne l’ID utilisateur et le nom d’utilisateur de la table users en joignant avec la table group_users sur le user_id, puis en joignant avec la table groups sur le group_id. Elle filtre les résultats pour inclure uniquement les utilisateurs qui font partie du groupe dont le nom est « plugin-authors ».
Ce sujet a été automatiquement fermé après 43 heures. Les nouvelles réponses ne sont plus autorisées.