Discourse AI + Data Explorer ?

J’ai essayé cela. Les résultats sont partout. Une expérience intéressante consiste à fournir à GPT-3.5 un schéma minimal annoté de la base de données Discourse juste pour tester sa capacité SQL. Je réalise que c’est inefficace en termes de jetons, mais c’est lisible :

Schéma minimal
# == Informations sur le schéma
#
# Nom de la table : users
#
#  id                        :integer          not null, primary key
#  username                  :string(60)       not null
#  created_at                :datetime         not null
#
# Nom de la table : groups
#
#  id                                 :integer          not null, primary key
#  name                               :string           not null
#  created_at                         :datetime         not null
#
# Nom de la table : group_users
#
#  id                 :integer          not null, primary key
#  group_id           :integer          not null
#  user_id            :integer          not null
#
# Nom de la table : posts
#
#  id                      :integer          not null, primary key
#  user_id                 :integer
#  topic_id                :integer          not null
#  deleted_at              :datetime         (L'application "supprime logiquement" les posts. Lorsqu'un post est supprimé, sa propriété `deleted_at` est définie sur un :datetime. Sauf demande explicite de renvoyer les posts supprimés, assurez-vous que la colonne `deleted_at` est `NOT NULL` lors de la rédaction de requêtes demandant des données relatives aux posts.)
#
# Nom de la table : topics
#
#  id                        :integer          not null, primary key
#  title                     :string           not null
#  category_id               :integer
#  created_at                :datetime         not null
#  user_id                   :integer          (l'id de l'utilisateur qui a créé le topic)
#  deleted_at                :datetime         (L'application "supprime logiquement" les topics. Lorsqu'un topic est supprimé, sa propriété `deleted_at` est définie sur un :datetime. Sauf demande explicite de renvoyer les topics supprimés, assurez-vous que la colonne `deleted_at` est `NOT NULL` lors de la rédaction de requêtes demandant des données relatives aux topics.)
#
# Nom de la table : categories
#
#  id                                        :integer          not null, primary key
#  name                                      :string(50)       not null

Jusqu’à présent, les résultats que j’obtiens sont impressionnants. Cela me fait penser que le problème pourrait être résolu simplement en fournissant un schéma annoté dans l’invite.

Pour le plaisir, je lui ai demandé quels types de requêtes elle pourrait avoir du mal à gérer :

Limitations de GPT-3.5
  1. Requêtes hiérarchiques : Les requêtes impliquant des structures de données hiérarchiques comme des relations récursives peuvent être complexes. Par exemple, interroger les relations parent-enfant au sein d’une hiérarchie de catégories.
  2. Requêtes temporelles : Les requêtes impliquant des données basées sur le temps, telles que le calcul de tendances historiques ou l’analyse de données sur des intervalles de temps spécifiques, peuvent nécessiter des constructions SQL plus complexes.
  3. Fonctions de fenêtre : Bien que j’aie utilisé des fonctions de fenêtre dans des requêtes précédentes, des utilisations plus avancées de fonctions de fenêtre pour des tâches analytiques complexes pourraient être difficiles.
  4. Requêtes géospatiales : Les bases de données spatiales et les requêtes basées sur des données géographiques, comme la recherche d’emplacements à proximité ou de relations spatiales complexes, peuvent être complexes.
  5. Agrégations complexes : Les agrégations avancées impliquant plusieurs niveaux de regroupement et de calcul peuvent nécessiter des connaissances SQL plus complexes.
  6. Requêtes d’optimisation : La rédaction de requêtes hautement optimisées impliquant des index, l’ajustement des requêtes et l’amélioration des performances peut être complexe.
  7. Algorithmes personnalisés : L’implémentation d’algorithmes ou de logiques personnalisés dans une requête SQL peut être difficile en raison de la complexité de la logique impliquée.
  8. Jointures complexes : Des conditions de jointure complexes ou la combinaison de plusieurs jointures peuvent nécessiter une attention particulière et potentiellement des constructions SQL plus complexes.
  9. Sous-requêtes et sous-requêtes corrélées : Bien que je puisse gérer les sous-requêtes, des sous-requêtes extrêmement complexes ou profondément imbriquées peuvent être plus difficiles.
  10. Pivoter et dépivoter : La transformation de données entre des formats larges et étroits (pivoter et dépivoter) peut devenir complexe dans certains scénarios.

Là où je rencontre des problèmes, c’est en tentant de désambiguïser le schéma complet de la base de données. Par exemple, trouver un moyen d’annoter la table user_actions. Fournir simplement des définitions de ses codes action_type n’est pas suffisant. Elle commence à deviner sur user_id, target_user_id et acting_user_id.

Les requêtes les plus fréquemment demandées n’utilisent pas la plupart des tables et colonnes de la base de données. Si l’IA est ajoutée à l’Explorateur de données, il pourrait être intéressant d’avoir des modes “basique” et “avancé”. Le mode basique pourrait fournir une invite couvrant la plupart des cas d’utilisation. Le mode avancé permettrait aux utilisateurs de sélectionner les informations à définir dans l’invite.

Il pourrait être intéressant de travailler à rebours à partir de quelques demandes de requêtes sur meta, pour voir ce qui devrait être fourni à l’invite afin que GPT-3.5 crée la requête avec succès.

3 « J'aime »