Pourquoi votre outil d’IA choisit la mauvaise colonne

Un contexte de schéma insuffisant peut conduire un outil d’IA à choisir la mauvaise colonne : amount et net_amount ressemblent toutes deux à un chiffre d’affaires, created_at et paid_at à une date de commande. Le contexte du schéma, c’est-à-dire les descriptions des statuts, montants, dates et relations, apporte ce sens, et la lecture de la requête exécutée montre s’il a été appliqué. Ce guide indique quelles descriptions changent une réponse, comment les prioriser et comment retester après modification.

Pourquoi l’outil a-t-il choisi la mauvaise colonne ?

Une réponse erronée peut venir d’une question ambiguë, d’une description absente, d’une erreur du modèle, d’une jointure incorrecte ou de données anciennes. Examinez requête et source avant d’en déterminer la cause.

Si l’outil utilise amount à la place de net_amount, décrivez la différence. S’il choisit une ancienne table, identifiez celle du reporting actuel. Le contexte aide lorsqu’il apporte un sens absent des noms.

Exemple de description à préciser

Une table contient des commandes finalisées, en attente et annulées. Vous demandez les ventes finalisées d’août 2026. Sans filtre de statut, la requête inclurait les trois catégories :

SELECT SUM(total_eur)
FROM orders
WHERE ordered_at >= DATE '2026-08-01'
  AND ordered_at < DATE '2026-09-01';

Ajoutez : « Utiliser status = 'completed' pour les ventes finalisées ; total_eur représente la valeur avant remboursements. » Une requête adaptée ajouterait ce filtre. Une phrase ajoutée ne garantit pas la génération du même SQL.

Comparez la réponse suivante à un résultat connu. Si la description contredit la définition métier, corrigez-la.

Décrire les champs qui influencent le résultat

Champ ou table	Informations utiles
Statut	Sens des valeurs et valeurs à inclure
Montant	Devise, taxes, remises et remboursements
Date	Événement représenté et fuseau du reporting
Identifiant	Commande, client ou événement identifié
Relation	Champs de liaison et nombre de correspondances possibles
Table de reporting	Ce que représente une ligne et actualité de la table

Une description qui répète le nom apporte peu. « Identifiant client » ne dit pas si une personne peut avoir plusieurs identifiants. Commencez par les champs de votre premier rapport plutôt que par toute la base.

Structure du schéma et sens métier

La découverte du schéma fournit les noms, types, clés primaires et relations déclarées que la source expose. Ces informations indiquent à l’analyste quelles jointures sont possibles et quelles opérations conviennent à une colonne ; le générateur de requêtes part de la même structure, comme l’explique comment le text-to-SQL génère les requêtes. Elles ne précisent pas nécessairement quelle table fait référence pour le reporting ni ce qu’un montant comprend.

Le contexte métier apporte ces définitions. Une responsable commerciale peut expliquer quand une commande est considérée comme terminée ; l’analyste identifie le champ correspondant et la jointure qui conserve une ligne par commande. Une description utile réunit ces connaissances au lieu de reformuler le nom de la colonne.

Ambiguïté	Erreur possible	Contexte à vérifier
Deux colonnes de montant	Utiliser le brut pour un rapport après remboursements	Définir les deux montants, la devise et le traitement des remboursements
Tables similaires	Interroger une migration abandonnée	Nommer la table actuelle et la date de remplacement
Comptes de test	Inclure des achats internes dans les ventes	Préciser l’indicateur de test et l’exclusion attendue
Relation non déclarée	Joindre des noms similaires aux sens différents	Donner les deux clés et le nombre de correspondances attendu
Données pré-agrégées	Répéter les totaux journaliers après une jointure	Décrire ce que représente une ligne et ses dimensions
Plusieurs dates	Retenir la création au lieu de l’expédition	Nommer l’événement métier et le fuseau stocké

Ce sont des causes possibles à examiner. Le modèle peut encore choisir le mauvais champ alors que la description pertinente est présente.

Choisir les descriptions utiles au prochain rapport

Commencez par les colonnes de filtre : statut, catégorie, type de compte et indicateurs. Examinez ensuite les noms proches, comme created_at et paid_at, ou amount et net_amount. Documentez la distinction qui modifie le résultat.

Pour une table obsolète, nommez sa remplaçante et précisez si les données historiques nécessitent encore l’ancienne source. Pour les relations, indiquez les deux clés et la granularité attendue. Une clé étrangère déduite reste une proposition à vérifier, surtout lorsque la base ne contrôle pas les relations.

Marquez les tables de reporting importantes pour aider à prioriser le contexte pertinent. Ce choix ne donne pas de droits supplémentaires et ne garantit pas qu’un schéma de taille quelconque tienne dans une demande au modèle. Limitez le périmètre de la connexion aux données nécessaires et examinez les sources réellement utilisées.

Descriptions et couche sémantique ont des rôles différents

Une description explique un champ ou une règle. Une couche sémantique peut centraliser les définitions de métriques et leur exécution. Écrire « les ventes excluent les remboursements » ne crée pas une métrique imposée et ne réconcilie pas deux tables qui traitent les remboursements différemment.

Si vous disposez de vues de reporting approuvées ou de métriques centralisées, utilisez leurs sorties lorsque le connecteur peut les interroger. Vérifiez que le SQL conserve la granularité prévue. Le guide d’analytique en libre-service explique comment intégrer ce travail au reporting existant.

Avec une base opérationnelle sans couche sémantique, vous pouvez déjà documenter les sources d’un premier rapport. Définissez la mesure, les filtres et la date à utiliser ; posez une question connue et rapprochez le résultat. Une vue de reporting maintenue devient utile lorsque la même logique métier doit être appliquée de façon cohérente à plusieurs analyses.

Vérifier les changements avec quelques questions connues

Gardez des exemples qui sollicitent les définitions : une commande annulée, un remboursement le mois suivant, deux clients homonymes ou une date proche de minuit dans le fuseau du rapport. L’analyste peut préparer le SQL de référence ; l’utilisateur métier confirme les enregistrements à compter.

Après une modification de description, reposez les questions concernées et comparez sources, filtres et totaux. Notez l’évolution de la définition et celle du résultat. Un chiffre différent peut venir du contexte corrigé, de données modifiées ou d’une erreur du modèle ; examinez la requête avant d’attribuer l’amélioration à la description.

Conservez les formulations relues dans un espace maintenu par l’équipe : documentation de la base, description dbt ou fichier versionné. Reportez les changements pertinents dans les descriptions de connexion Datarelix. Désignez une personne pour les revoir quand les statuts, dates ou définitions de reporting changent.

Modifier le contexte dans Datarelix

À la connexion, Datarelix lit la structure. L’analyse IA du schéma, facultative, propose descriptions et relations à partir de cette structure. Vous pouvez modifier les descriptions, vérifier les relations déduites, ajuster les clés, marquer les tables importantes et exclure des colonnes du contexte. Ces modifications ne changent pas la base source.

L’analyse IA du schéma a une allocation mensuelle ; consultez les tarifs. Les propositions doivent être relues. Datarelix n’importe pas automatiquement les descriptions dbt ou les commentaires existants de la base dans cet éditeur.

Maintenir le contexte

Confiez la relecture des descriptions à une personne responsable du jeu de données lorsque les champs changent. Si les indicateurs sont documentés ailleurs, conservez des définitions cohérentes et reportez les modifications utiles dans Datarelix. Une description ancienne peut orienter la requête vers le mauvais champ.

Les descriptions sont des entrées du modèle : n’y placez jamais de mots de passe ni de secrets de connexion. La présentation sécurité précise ce qui parvient au modèle et ce qui est conservé.

Le contexte ne réconcilie pas des tables contradictoires et ne garantit pas l’exactitude. Après modification, reposez une question connue avec la méthode de vérification. Le guide des questions présente la sélection des tables et la formulation des demandes.