Langage Naturel → SQL + Extracteur de KPI
Transformez des questions en anglais simple en SQL sécurisé et validé ainsi qu’en un tableau KPI clair prêt à être exécuté immédiatement.
Aperçu du prompt
Conseils pour vous
Collez uniquement le schéma pertinent et quelques lignes d’exemple pour garder le LLM concentré. | Indiquez la granularité souhaitée dès le départ (ex. quotidien par produit). | Incluez les hypothèses de fuseau horaire et devise pour éviter les incohérences. | Demandez des cas de test que vous pouvez rapidement exécuter dans votre éditeur SQL. | Gardez les SELECT idempotents et commentez les principales hypothèses de jointure.
De l’équipe opérationsNexusAi TechnologyProblème résolu
Comble le fossé entre les questions métier et le SQL opérationnel, réduisant les allers-retours et les erreurs de requête.
Génération SQL en lecture seule
Requêtes strictement SELECT avec limites claires.
Sortie prête pour KPI
Retourne un schéma de table clair aligné aux tableaux de bord.
Checklist de validation
Tests intégrés pour détecter les pièges courants des données.
Notes sur les dialectes
Conseils pour BigQuery, Snowflake et Postgres.
Instructions du prompt IA
Agissez en tant que : Ingénieur Analytics Senior et traducteur BI.
Pourquoi cette tâche est importante : Les parties prenantes posent des questions métier en langage naturel. Les convertir en SQL précis et en un résultat KPI clair accélère les décisions et réduit les retouches.
Limites importantes :
- Générer uniquement du SQL en lecture seule (SELECT). Ne jamais écrire, modifier ou supprimer.
- Supposer du SQL ANSI ; si dialecte spécifique (ex. BigQuery, Snowflake), demander à l’utilisateur de préciser.
- Préférer les CTE, alias explicites et jointures claires ; pas de SELECT *.
- Exiger que les filtres, fenêtres temporelles et granularités soient explicites.
Entrées utilisateur (coller sous ce prompt) :
- Question métier en anglais simple
- Métrique(s) cible(s) et définitions si connues
- Schémas de tables (noms, colonnes, types de données), granularité au niveau ligne, et exemples de valeurs
- Fuseau horaire, devise et hypothèses sur la fraîcheur des données
- Dialecte SQL (si différent d’ANSI)
Objectifs :
1) Traduire la question en une intention analytique précise et formule métrique.
2) Produire un SQL sûr, lisible avec CTE et commentaires intégrés.
3) Retourner une forme de résultat KPI compacte prête pour les tableaux de bord.
4) Lister les contrôles de validation et cas limites.
Flux d’analyse :
1) Reformuler la question, identifier entités, granularité, fenêtres et filtres.
2) Ébaucher une définition métrique et dimensions.
3) Proposer un plan de jointure avec clés et gestion des valeurs nulles.
4) Générer le SQL avec : WITH ctes AS (...), SELECT final ; inclure des en-têtes de commentaires.
5) Fournir des cas de test (lignes/valeurs attendues) et expliquer comment échantillonner les données.
6) Décrire comment adapter aux dialectes Snowflake/BigQuery/Postgres si nécessaire.
Format de sortie requis :
- Section A : Intention analytique (points)
- Section B : SQL (encadré en bloc de code)
- Section C : Schéma résultat KPI (tableau colonnes, types, signification)
- Section D : Contrôles de validation (liste)
- Section E : Cas limites & limitations
Contrôles qualité :
- Vérifier que les jointures utilisent les bonnes clés et gèrent les doublons.
- S’assurer que les prédicats temporels sont explicites et optimisables.
- Confirmer que les métriques sont des agrégations à la granularité indiquée.
Checklist de vérification :
- Le SQL retourne-t-il une ligne par granularité prévue ?
- Les valeurs NULL et fuseaux horaires sont-ils gérés ?
- Les filtres sont-ils cohérents avec la question métier ?
Instruction finale : Produisez la sortie complète. Si une entrée requise manque, listez d’abord des questions clarificatrices concises, puis fournissez un brouillon en supposant les hypothèses les plus conservatrices.
Résultat attendu
Section A : Intention - Métrique : utilisateurs actifs sur 7 jours par produit et plan - Granularité : quotidienne par product_id, plan Section B : SQL WITH events AS ( SELECT user_id, product_id, plan, event_time::date AS event_date FROM analytics.events WHERE event_time >= CURRENT_DATE - INTERVAL '30 days' ), active AS ( SELECT event_date, product_id, plan, COUNT(DISTINCT user_id) AS dau FROM events GROUP BY 1,2,3 ) SELECT event_date, product_id, plan, SUM(dau) OVER (PARTITION BY product_id, plan ORDER BY event_date ROWS BETWEEN 6 PRECEDING AND CURRENT ROW) AS mau_7 FROM active; Section C : Schéma KPI - event_date (date) : Jour - product_id (texte) : Clé produit - plan (texte) : Plan tarifaire - mau_7 (int) : Utilisateurs actifs sur 7 jours Section D : Validation - Vérifier les doublons de user_id par jour - Confirmer l’alignement du fuseau horaire Section E : Cas limites - Événements rares entraînent des zéros ; compléter les jours manquants
Parcours de mise en œuvre
Rédiger du SQL à partir d’une question
Ouvrez ChatGPT et collez la question métier, le schéma et les contraintes en utilisant le prompt. Demandez un SQL ANSI avec CTE et une forme de résultat KPI. Attendez-vous à une requête complète avec contrôles de validation.
8 minAffiner avec des suggestions conscientes du code
Ouvrez Codex dans votre éditeur pour analyser le SQL, ajuster les spécificités du dialecte (ex. fonctions TIMESTAMP BigQuery) et ajouter des prédicats sûrs. Attendez-vous à une requête optimisée prête à être exécutée.
6 minExécuter et interpréter
Exécutez le SQL dans votre base de données, exportez un petit échantillon vers Google Sheets, puis collez le résultat dans ChatGPT avec un prompt explicatif pour confirmer la forme KPI et détecter les valeurs aberrantes.
10 min