Tips & Tricks : aidez Cortex à comprendre vos données

Introduction

Cortex Analysis révolutionne comment les analystes interagissent avec leurs données grâce à l’IA. Mais son efficacité dépend entièrement de la qualité de vos métadonnées et de la structure de vos données.

1. Comprendre comment fonctionnent les LLM en général

Le fonctionnement basique

Un modèle de langage (LLM) fonctionne selon ce principe : prédire le prochain token en se basant sur tous les tokens précédents. Ce processus se décompose en 3 étapes :

• Tokenization → Votre question est convertie en petits morceaux de texte
• Contexte → Le modèle identifie les tokens pertinents et crée une représentation numérique (embedding) de votre question
• Génération → Le modèle génère une réponse token par token, en s’appuyant sur le contexte complet

L’importance du contexte : le point critique

Un LLM n’est aussi bon que le contexte qu’on lui fournit.

« Quelles sont les ventes ? » → Réponse vague basée sur connaissances générales

« Analyse les ventes du département ‘Electronics’ avec les colonnes [product_id, product_name, category, price_usd, quantity_sold] de la table SALES » → Requête SQL précise

Les embeddings : le cœur du processus

Les LLM transforment du texte en vecteurs numériques. Deux textes similaires ont des embeddings proches. C’est pourquoi Cortex peut :

• Comprendre vos questions en langage naturel
• Les mettre en relation avec votre schéma de données
• Générer des requêtes SQL appropriées

Conclusion : Cortex doit avoir accès à des descriptions riches, précises et explicites de vos données.

2. Comment Cortex s’appuie sur les Semantic Views

Qu’est-ce qu’une Semantic View ?

Une Semantic View n’est pas une simple vue SQL. C’est une couche de métadonnées structurée contenant :

• Les tables et colonnes disponibles
• Les relations entre tables (clés étrangères, jointures logiques)
• Le contexte métier (descriptions, significations)
• Les mesures pré-configurées et les dimensions

Le flux d’interaction avec Cortex

Question en langage naturel

        ↓

Cortex analyse la question (embedding + tokenization)

        ↓

Consultation de la Semantic View

(Quelles tables ? Quelles colonnes ? Comment joindre ? Significations ?)

        ↓

Génération d’une requête SQL via RAG

(Retrieval-Augmented Generation)

        ↓

Exécution et résultats

RAG : Retrieval-Augmented Generation

Cortex utilise RAG en 3 étapes :

1. Retrieval : Cortex récupère les descriptions pertinentes de votre Semantic View

2. Augmented : Ces descriptions enrichissent le prompt envoyé au LLM

3. Generation : Le LLM génère une requête SQL basée sur ce contexte enrichi

Plus votre Semantic View est riche, meilleure sera la requête générée.

3. Les 6 Bonnes Pratiques Essentielles

Bonne Pratique 1 : Descriptions précises et détaillées des colonnes

C’est probablement la pratique la plus importante. Cortex utilise les descriptions pour comprendre ce que chaque colonne représente.

À ÉVITER :

CREATE OR REPLACE TABLE SALES (

     id NUMBER COMMENT ‘ID’,

     dt DATE COMMENT ‘Date’,

     amt DECIMAL COMMENT ‘Montant’,

     status VARCHAR COMMENT ‘Statut’

 );

À FAIRE :

CREATE OR REPLACE TABLE SALES (

     transaction_id NUMBER COMMENT ‘Identifiant unique de la vente. Clé primaire.’,

     transaction_date DATE COMMENT ‘Date de la vente (YYYY-MM-DD). Utilisé pour analyses temporelles.’,

     transaction_amount DECIMAL(10,2) COMMENT ‘Montant total en USD incluant taxes. Valeurs: 0.01 à 999999.99.’,

     order_status VARCHAR COMMENT ‘État: PENDING, PROCESSING, SHIPPED, DELIVERED, RETURNED. État initial: PENDING.’,

     customer_id NUMBER COMMENT ‘Clé étrangère vers CUSTOMERS table.’,

     product_id NUMBER COMMENT ‘Clé étrangère vers PRODUCTS table.’

 );

Ce que vous apportez :

• Format et type de données
• Signification métier
• Valeurs possibles
• Références aux autres tables
• Unités (USD, pourcentage, etc.)

Bonne Pratique 2 : Descriptions cohérentes et détaillées des tables

À ÉVITER :

CREATE OR REPLACE TABLE PRODUCTS COMMENT ‘Table des produits’;

À FAIRE :

CREATE OR REPLACE TABLE PRODUCTS COMMENT ‘Table maître du catalogue de produits. Une ligne par produit. Inclut: identifiant unique (product_id), nom, catégorie, prix, stock. Mise à jour quotidiennement. Utilisée pour jointures avec SALES et INVENTORY.’;

Bonne Pratique 3 : Nommer explicitement colonnes et tables

À ÉVITER :

CREATE OR REPLACE TABLE S (

     id NUMBER, dt DATE, u_id NUMBER, amt DECIMAL, st VARCHAR );

À FAIRE :

CREATE OR REPLACE TABLE SALES_TRANSACTIONS (

     transaction_id NUMBER,

     transaction_date DATE,

     customer_id NUMBER,

     transaction_amount DECIMAL,

     order_status VARCHAR

 );

Conventions recommandées :

• Noms complets, pas d’abréviations (sauf acronymes métier)
• snake_case en minuscules
• Suffixes ou préfixes explicites (_id, _date, _amount, _percentage, etc.)
• Cohérence dans toute la base
• Règle de nommage précise et partagée par l’ensemble de l’équipe Data

Bonne Pratique 4 : Structurer les Semantic Views avec mesures et dimensions

L’importance : Une Semantic View bien structurée aide Cortex à générer des requêtes d’agrégation correctes.

CREATE OR REPLACE SEMANTIC MODEL SALES_ANALYSIS USING (

     SELECT

t.transaction_id,

t.transaction_date,

      t.amount,

      c.customer_region,

      p.product_category,

      t.order_status

     FROM SALES_TRANSACTIONS t

     JOIN CUSTOMERS c ON t.customer_id = c.customer_id

     JOIN PRODUCTS p ON t.product_id = p.product_id

 ) AS sales_view

  DIMENSIONS (

     sales_view.transaction_date AS transaction_date,

     sales_view.customer_region AS customer_region,

     sales_view.product_category AS product_category,

     sales_view.order_status AS order_status

 )

  MEASURES (

     SUM(sales_view.transaction_amount) AS total_sales_revenue,

     COUNT(DISTINCT sales_view.transaction_id) AS number_of_transactions,

     AVG(sales_view.transaction_amount) AS average_order_value

 );

Quand Cortex voit « Revenu par région », il sait instantanément : utiliser la mesure « total_sales_revenue » et grouper par dimension « customer_region »

Bonne Pratique 5 : Documenter les transformations et règles métier

CREATE OR REPLACE TABLE SALES_ENRICHED AS SELECT

     transaction_id,

     transaction_date,

     CASE

         WHEN transaction_amount > 1000 THEN ‘High Value’

         WHEN transaction_amount > 100 THEN ‘Medium Value’

         ELSE ‘Low Value’

     END AS customer_segment,

     transaction_amount * 1.1 AS revenue_including_expected_returns         COMMENT ‘Montant ajusté +10% pour retours (taux 9.8% observé sur 12 mois)’ FROM SALES_TRANSACTIONS;

  COMMENT ON TABLE SALES_ENRICHED IS ‘Table enrichie des transactions avec segments clients et ajustements retours. Utilisée pour profitabilité réelle. MAJ quotidiennement.’;

Bonne Pratique 6 : Maintenir schéma et documentation à jour

Un schéma obsolète induira Cortex en erreur.

Checklist de maintenance :

• Après ajout de colonne → mettre à jour commentaires
• Après refonte métier → mettre à jour descriptions
• Trimestriellement → vérifier descriptions reflètent réalité
• Documenter colonnes dépréciées

ALTER TABLE SALES_TRANSACTIONS  MODIFY COLUMN legacy_amount COMMENT ‘DÉPRÉCIÉ. Utiliser transaction_amount (DECIMAL) à la place.’;

4. Exemple complet : Schéma optimisé pour Cortex

— TABLE DIMENSION : CLIENTS CREATE OR REPLACE TABLE CUSTOMERS (

     customer_id NUMBER PRIMARY KEY

          COMMENT ‘Identifiant unique client. Clé primaire.’,

     customer_name VARCHAR

          COMMENT ‘Nom complet (prénom + nom).’,

     customer_region VARCHAR

          COMMENT ‘Région : North America, Europe, Asia, South America, Africa, Oceania.’,

     customer_segment VARCHAR

          COMMENT ‘Segment: Premium, Standard, Occasional. Recalculé mensuellement.’,

     customer_lifetime_value DECIMAL(12,2)

          COMMENT ‘Valeur totale en USD dépensée depuis inscription. MAJ quotidiennement.’

 ) COMMENT ‘Table maître des clients. Une ligne par client unique. Source: CRM. MAJ quotidienne. Utilisée pour jointures avec SALES.’;

  — TABLE DIMENSION : PRODUITS CREATE OR REPLACE TABLE PRODUCTS (

     product_id NUMBER PRIMARY KEY

          COMMENT ‘Identifiant unique produit. Clé primaire.’,

     product_name VARCHAR

          COMMENT ‘Nom commercial. Doit être unique.’,

     product_category VARCHAR

          COMMENT ‘Catégorie: Electronics, Clothing, Home & Garden, Sports, Books, Other.’,

     product_price_usd DECIMAL(8,2)

          COMMENT ‘Prix vente unitaire en USD. MAJ mensuelle. Jamais NULL ou négatif.’

 ) COMMENT ‘Catalogue maître. Une ligne par produit. 15000+ références. MAJ hebdomadaire. Source: inventaire central.’;

— TABLE FAIT : VENTES CREATE OR REPLACE TABLE SALES_TRANSACTIONS (

     transaction_id NUMBER PRIMARY KEY

          COMMENT ‘Identifiant unique transaction. Clé primaire.’,

     transaction_date DATE

          COMMENT ‘Date transaction (YYYY-MM-DD). Utilisée pour analyses temporelles.’,

     customer_id NUMBER

          COMMENT ‘Clé étrangère vers CUSTOMERS.’,

     product_id NUMBER

          COMMENT ‘Clé étrangère vers PRODUCTS.’,

     quantity_sold NUMBER

          COMMENT ‘Nombre unités vendues. Entier positif. Min: 1.’,

     transaction_amount DECIMAL(10,2)

          COMMENT ‘Montant total = qty * prix. En USD. Jamais NULL.’,

     order_status VARCHAR

          COMMENT ‘État: PENDING, PROCESSING, SHIPPED, DELIVERED, RETURNED. Init: PENDING.’

 ) COMMENT ‘Table faits ventes. Une ligne par transaction. Source: POS. Partitionnée par date. MAJ quasi-temps-réel. 2M+ lignes. KPI ventes et analyses.’;

— SEMANTIC VIEW CREATE OR REPLACE SEMANTIC MODEL SALES_ANALYSIS USING (

     SELECT

         t.transaction_id, t.transaction_date, t.customer_id, t.product_id,

         c.customer_name, c.customer_region, c.customer_segment,

         p.product_name, p.product_category, p.product_price_usd,

         t.quantity_sold, t.transaction_amount, t.order_status

     FROM SALES_TRANSACTIONS t

     JOIN CUSTOMERS c ON t.customer_id = c.customer_id

     JOIN PRODUCTS p ON t.product_id = p.product_id

 ) AS sales_view

  DIMENSIONS (

     sales_view.transaction_date AS transaction_date,

     sales_view.customer_region AS customer_region,

     sales_view.customer_segment AS customer_segment,

     sales_view.product_category AS product_category,

     sales_view.order_status AS order_status

 )

  MEASURES (

     SUM(sales_view.transaction_amount) AS total_sales_revenue,

     SUM(sales_view.quantity_sold) AS total_quantity_sold,

     COUNT(DISTINCT sales_view.transaction_id) AS number_of_transactions,

     COUNT(DISTINCT sales_view.customer_id) AS number_of_customers,

     AVG(sales_view.transaction_amount) AS average_order_value

 )

  COMMENT ‘Modèle sémantique pour analyse ventes. Combine données de ventes, clients et produits. Utilisé par Cortex pour KPI et segmentations.’;

5. Checklist d’implémentation

Avant mise en production :

• Noms : Explicites et clairs (tables et colonnes)
• Descriptions colonnes : Détaillées (min. 15 mots)
• Descriptions tables : Exprimant objectif métier
•  Types de données : Appropriés et cohérents
• Clés étrangères : Documentées dans commentaires
• Semantic View : Créée avec dimensions, mesures, commentaires
• Tests : Validés avec Cortex Analysis
• Gouvernance : Processus de mise à jour défini
• Documentation : Dictionnaire de données créé

6. Conclusion

Aider Cortex à comprendre vos données revient à créer une structure claire, bien nommée et richement documentée. C’est un investissement initial qui paie énormément :

• Requêtes SQL générées automatiquement et justes
• Réduction du temps d’analyse
• Moins de code SQL à maintenir
• Analyse accessible à tous (non-SQL)

Rappelez-vous : Un LLM ne peut être précis que si le contexte fourni l’est.

Investissez dans votre gouvernance des données et Cortex fera le reste.

Envie d’échanger sur le sujet ?