Pourquoi votre outil d’IA choisit la mauvaise colonne

Quand un outil d’IA filtre sur la mauvaise colonne, la cause habituelle est un contexte sémantique manquant, pas un modèle faible. La structure du schéma lui indique qu’une colonne nommée status existe et contient du texte. Elle ne dit pas que 'completed' signifie payé et expédié, que 'closed' était l’orthographe d’avant 2024 pour la même chose, ni que orders_v2 est la table active et orders une migration abandonnée. C’est cette couche manquante qui sépare un outil qui fonctionne sur vos données d’un outil qui écrit du SQL bien formé sur la mauvaise colonne.

Si vous avez déjà vu ça arriver

Toute personne qui a connecté un outil d’analytique en langage naturel, l’a vu répondre à une question avec assurance et de travers, et s’est demandé si le modèle était mauvais. En général, il ne l’est pas. Et aussi les ingénieurs analytics qui doivent décider quelle part de curation vaut la peine d’être faite avant de déployer un outil.

Les deux couches, et celle que vous contrôlez

Couche un : la structure, que vous obtenez gratuitement

L’introspection lit les noms de tables et de colonnes, les types de données, les clés primaires, les clés étrangères déclarées et la nullabilité, sans que personne ait à intervenir. Tous les outils de cette catégorie la lisent : ce n’est donc pas de là que viennent les différences de qualité entre outils.

Couche deux : le sens, que vous devez fournir

Les bases de données ne stockent généralement pas le sens. Il vit dans un wiki, dans un champ description: dbt que personne n’a rempli, ou dans la mémoire d’un analyste. Quand il est absent, le modèle fait ce que ferait n’importe quel inconnu compétent devant votre schéma : il devine à partir des noms.

Ce que coûte l’ambiguïté

Voici les formes d’échec qui reviennent :

Ambiguïté	Ce que fait le modèle sans contexte	Ce qu’une ligne de contexte corrige
Codes de statut	Filtre sur la valeur qui sonne juste, ou omet entièrement le filtre	status : cycle de vie de la commande — 'completed' signifie payé et expédié ; à utiliser pour le chiffre d’affaires
Plusieurs colonnes de montant	Choisit amount plutôt que net_amount parce que le nom est plus simple	amount : brut, avant remboursements. Utilisez net_amount pour le chiffre d’affaires publié
Tables obsolètes	Interroge la table au nom le plus propre	orders : remplacée en 2024-03 ; utilisez orders_v2
Lignes de test et internes	Les compte	customers : contient des comptes de test internes où is_internal = true — à exclure du reporting
Chemins de jointure non déclarés	Déduit une jointure de la convention de nommage ; parfois à tort	Déclarez la relation, ou corrigez celle qui a été déduite
Confusion de granularité	Somme une colonne qui est déjà un agrégat	daily_revenue : pré-agrégé par jour — ne pas sommer à l’intérieur d’une même journée
Horodatages à fuseaux mélangés	Compare des champs stockés dans des fuseaux différents	created_at : UTC. local_ordered_at : heure locale du magasin, non comparable

Aucun de ces cas n’est une défaillance du modèle. Chacun est une question à laquelle le schéma ne répond pas, tranchée par le modèle qui s’arrête sur une lecture.

Ce qu’une ligne de contexte change vraiment

Prenons la première ligne. La question est « quel a été le chiffre d’affaires le mois dernier ? », posée sur le schéma de démonstration d’un distributeur fictif où orders.status contient 'completed', 'pending' et 'cancelled'.

Sans description sur status, rien dans le schéma ne dit que les commandes annulées ne comptent pas dans le chiffre d’affaires, donc rien ne les filtre :

SELECT SUM(amount) AS revenue
FROM orders
WHERE ordered_at >= date_trunc('month', now() - interval '1 month')
  AND ordered_at <  date_trunc('month', now());

Ajoutez maintenant une ligne de contexte sur status : cycle de vie de la commande ; 'completed' signifie payé et expédié, à utiliser pour le chiffre d’affaires. La même question produit désormais :

SELECT SUM(amount) AS revenue
FROM orders
WHERE ordered_at >= date_trunc('month', now() - interval '1 month')
  AND ordered_at <  date_trunc('month', now())
  AND status = 'completed';

Les deux requêtes sont du SQL valide et s’exécutent toutes les deux sans erreur. La première inclut silencieusement les commandes annulées, elle annonce donc un chiffre plus élevé — et rien dans la réponse n’a l’air faux. C’est tout l’argument en faveur de la curation : le coût d’un contexte manquant n’est pas un échec, c’est un chiffre plausible.

Que décrire en premier : la curation par ordre de priorité

Vouloir tout décrire, c’est ainsi que les projets de curation s’enlisent. Classez plutôt :

1. Toute colonne sur laquelle vous filtreriez. Statut, type, catégorie, colonnes indicateurs — ce sont elles qui décident des lignes comptées.
2. Toute colonne qui a une jumelle. amount et net_amount, created_at et updated_at, user_id et account_id. L’ambiguïté entre colonnes presque identiques est la plus coûteuse.
3. Tables obsolètes ou doublonnées. Une ligne disant « ne pas utiliser » évite toute une classe de réponses fausses.
4. Chemins de jointure qui ne sont pas déclarés en clés étrangères. Surtout dans les entrepôts comme Snowflake, où les clés sont informatives et souvent jamais déclarées du tout — traité dans poser des questions à Snowflake en langage naturel.
5. Marquez vos tables clés. Tables de faits et dimensions principales. Quand un schéma est assez grand pour que le contexte doive être tronqué, les tables marquées survivent à la coupe : le modèle garde celles qui comptent.

Tout le reste peut attendre. Une description générée automatiquement est un brouillon de départ, pas un texte fini : là où elle ne fait que reformuler le nom de la colonne, elle n’ajoute rien que le modèle ne puisse déjà lire. La valeur vient de l’édition des colonnes de la liste ci-dessus.

La curation n’est pas un projet de couche sémantique

Une objection courante : « ce n’est qu’une couche sémantique avec des étapes en plus ». Une couche sémantique calcule des métriques — elle détient la définition du chiffre d’affaires et la produit de façon cohérente. Le contexte sémantique décrit ce qui existe déjà, pour qu’une requête puisse être écrite correctement dessus. Si vous avez une couche sémantique, gardez-la ; la meilleure configuration consiste à pointer l’outil conversationnel vers les marts que produit votre couche sémantique, pour que les questions héritent des définitions au lieu de les redériver. C’est le montage défendu dans construire une analytique en libre-service sans remplacer votre pile.

Si vous n’en avez pas, la curation n’est pas un substitut — mais elle coûte moins cher : décrire les colonnes sur lesquelles vous filtrez est une tâche par schéma, pas un projet de modélisation.

Gouvernance du contexte : le garder vrai

Les descriptions se périment plus vite que les schémas, et une description fausse mais assurée est pire que pas de description du tout : elle transforme un tirage à pile ou face en erreur fiable.

• Gardez une source de vérité relue. Les descriptions saisies dans un outil sont faciles à changer et faciles à oublier. Gardez la formulation canonique là où vos modèles sont relus — un description: dbt, un COMMENT ON, un fichier dans le dépôt — pour qu’un changement soit visible par l’équipe, et réappliquez-la quand le schéma bouge. Datarelix n’importe pas aujourd’hui les commentaires de base de données ni les descriptions dbt existantes ; les descriptions sont saisies au niveau de la connexion.
• Revérifiez à chaque changement de schéma. Une colonne renommée avec une description périmée est le pire cas.
• Guettez les contradictions. Quand une requête générée filtre sur quelque chose qui vous surprend, c’est en général la description qui est fausse.
• Attribuez une responsabilité par schéma. Sans propriétaire nommé, les descriptions cessent d’être mises à jour quand le schéma change.
• Vérifiez périodiquement contre des réponses connues. Posez des questions dont vous connaissez déjà les réponses ; l’intérêt d’une trace de preuves, c’est que la dérive se voit — la routine est décrite dans comment vérifier une réponse produite par l’IA.

La curation du contexte dans Datarelix

Quand vous connectez une base de données, Datarelix en lit directement la structure — tables, colonnes, types, clés primaires, clés étrangères déclarées, nullabilité. Une analyse IA du schéma facultative (comptabilisée par mois — voir la page tarifs) propose ensuite des descriptions et déduit des relations à partir des conventions de nommage là où aucune clé étrangère n’a jamais été déclarée. Elle travaille uniquement à partir de la structure du schéma ; aucun échantillon de lignes ne lui est montré.

Tout ce qu’elle propose est modifiable, ce qui compte parce que l’inférence se trompe parfois. Sur la page de schéma, vous pouvez réécrire les descriptions, marquer des tables comme tables clés, corriger ou écarter les relations déduites, redéfinir les clés primaires et exclure entièrement des colonnes du contexte. Les très grands schémas n’entrent pas dans une seule requête : le contexte est donc rogné — les tables que vous marquez comme tables clés sont conservées.

Le contexte obtenu est ce qui accompagne chaque question, à côté de la question elle-même. Les lignes n’en font pas partie, avec une exception assumée : une valeur de réponse sur une seule ligne peut être reprise dans le contexte des questions suivantes, pour qu’un « et par rapport à l’an dernier ? » ait du sens. Les tables de résultats, non. « Jamais vos données » serait donc une exagération, et c’est pourquoi ce guide ne l’écrit pas. L’ensemble du pipeline est décrit dans text-to-SQL expliqué, et le volet identifiants dans comment les identifiants restent hors du modèle.

Ce que la curation ne peut pas corriger

La curation relève le plancher ; elle ne rend pas l’interprétation déterministe. Une question ambiguë sur un schéma parfaitement décrit reste ambiguë — « meilleurs clients » peut toujours signifier chiffre d’affaires ou nombre de commandes — et c’est pourquoi la requête est affichée avec chaque réponse plutôt que masquée derrière un vocabulaire de confiance.

Les descriptions ne réparent pas un modèle réellement cassé. Si deux tables ne s’accordent pas sur ce qu’est un client, aucune quantité de prose ne les réconcilie ; c’est une correction de modélisation. Les très grands schémas seront tronqués, aussi bien décrits soient-ils : restreindre une connexion au schéma qui compte vaut mieux que tout décrire. Et les relations déduites sont des hypothèses — vérifiez les jointures dans les premières réponses avant de faire confiance à un chiffre, surtout sur des schémas que vous n’avez pas modélisés vous-même.

Notes sur les exemples

Les affirmations produit décrivent Datarelix tel que livré en août 2026 — y compris la divulgation délibérée que des scalaires sur une seule ligne peuvent entrer dans le contexte des questions suivantes, indiquée ici parce que l’absolu inverse serait faux. La page sécurité énonce les limites d’exécution de façon canonique. Les descriptions d’exemple utilisent le schéma d’un distributeur fictif et sont illustratives. Le tableau des ambiguïtés vient de motifs récurrents dans des schémas de production, pas d’une étude publiée ; il est proposé comme une liste de contrôle, pas comme un classement mesuré.

Décrivez dix colonnes et reposez vos questions

Prenez votre schéma le plus sollicité et décrivez les dix colonnes sur lesquelles vous filtrez le plus. Suivez ensuite le démarrage rapide, posez cinq questions dont vous connaissez les réponses, et lisez les clauses WHERE. Vos 14 premiers jours s’exécutent aux limites Pro, sans carte bancaire.