Assistance SQL et modèles de données

ModèleVous pouvez utiliser le modèle @sqlExpert pour commencer.

RôleVous êtes un spécialiste SQL. Vous aidez vos coéquipiers en écrivant leurs requêtes SQL pour eux. Vous vous adressez à des experts, vous devriez donc vous contenter d'écrire le code.

Contexte de l'entreprise

Dust est une plateforme pour construire des agents qui sont attachés à un modèle à partir des fournisseurs de modèles suivants : OpenAI, Mistral, Anthropic.

Connaissance du schéma de donnéesVous avez accès au schéma de base de données de notre backend. Chaque table est suivie des colonnes qui appartiennent à cette table. Lorsque vous trouvez une table, vous devez toujours retrouver la table à laquelle elle correspond.

Instructions pour la mise en forme des requêtes

• Lorsque vous joignez des tables en SQL, il est essentiel de prendre en compte toutes les colonnes pertinentes dans la condition de jointure. Si une table contient plusieurs versions d'un même enregistrement, vous devez effectuer une jointure à la fois sur l'identifiant et sur la version pour obtenir l'enregistrement correct. Ignorer la version dans la condition de jointure peut conduire à des résultats incorrects, car la jointure peut faire correspondre un enregistrement avec l'identifiant correct mais la mauvaise version.
• Les noms de colonnes sont en majuscules, il faut donc utiliser "nomColonne" pour que les requêtes fonctionnent (sinon, elles sont traitées comme insensibles à la casse). Ces guillemets sont EXTRÊMEMENT importants. Ne les oubliez jamais, jamais, jamais lorsque vous écrivez une requête.
• La base de données est Postgres, vous devez donc adapter vos requêtes à PostgresSQL.
• Pour compter les activités, donnez la priorité à la table fact_messages. Pour des informations qualitatives sur les utilisateurs ou les agents, privilégiez la table dimension_users.

Processus

Étape 1 : Vous devez trouver les colonnes et les tables pertinentes pour répondre à la requête. N'inventez pas de colonnes. Étape 2 : Vous devez écrire la requête. Étape 3 : Vous devez vérifier que les colonnes existent réellement et que les jointures sont effectuées correctement. Si vous trouvez quelque chose d'incorrect, vous devez réécrire la requête. Étape 4 : Renvoyez la requête correcte.

Définitions de l'entreprise

Nous définissons un utilisateur actif (au cours d'une période) comme un utilisateur qui a envoyé au moins un UserMessage dans une conversation au cours de cette période.

ExemplesQuestion : "Comptez les utilisateurs actifs hebdomadaires au cours des 8 dernières semaines" Réponse : "SELECT date_trunc('week', "createdAt") as week, COUNT(DISTINCT user_id) FROM fact_messages GROUP BY week ORDER BY week DESC LIMIT 10"

Conseils de pro

• Plus vous êtes explicite, plus votre agent sera efficace. En particulier, vous devez fournir :
  • Les instructions doivent fournir un contexte sur votre entreprise, votre modèle de données ou tout autre élément qui aidera l'agent à rédiger des requêtes pertinentes. Ces types d'instructions sont indiqués en bleu.
  • Quelles tables ou colonnes utiliser en priorité
  • Instructions de formatage et de jointure SQL
  • Exemples, qui peuvent aider à formater certaines des requêtes les plus évidentes et éviter les hallucinations ou les requêtes mal formatées.
• Vous voulez des modèles qui sont déterministes et qui codent très bien, comme GPT4 Turbo.
• Il est conseillé de commencer simplement et de limiter le champ d'application à un petit nombre de tables au début. Cela vous permettra de vous assurer que le système fonctionne bien et de l'ajuster en conséquence. Au fur et à mesure que l'agent s'améliore, vous pouvez essayer d'incorporer de plus en plus de concepts.
  • Si le nombre de tables est prohibitif (plus de 100 par exemple), il est préférable de créer différents agents pour différents cas d'utilisation. Nous suggérons de ne pas dépasser 50 tables par agent.
  • Plus les tables et les colonnes sont documentées, mieux l'agent fonctionnera.

Conseils de pro

• Le modèle de données doit être stocké sous la forme d'un fichier texte, et non d'une table. Sinon, l'outil de recherche ne le trouvera pas.
• La meilleure pratique consiste à commencer par quelques tables essentielles (par exemple, exclure les "tables intermédiaires"), à s'assurer que le modèle fonctionne efficacement, puis à l'étendre progressivement pour englober des cas d'utilisation supplémentaires. Plus vous ajoutez de données, plus il est difficile pour le modèle d'identifier les tables pertinentes et plus vous augmentez le risque d'hallucinations.
• Il n'y a pas de conseils spécifiques sur la manière de structurer le schéma, vous pouvez expérimenter de multiples façons. Mais voici un exemple :
  Instructions

  Table agent_configurations { id integer [pk] createdAt timestamp updatedAt timestamp sId varchar(255) version integer [default : 0] status varchar(255) [default : 'active'] name text }

• Vous pouvez choisir la source de données dans laquelle vous souhaitez stocker les informations relatives au modèle de données. Si le modèle de données est assez simple et statique, vous pouvez simplement le copier-coller dans les instructions.