Un LLM qui lit une table appelée « txn » avec une colonne « amt » ne comprendra rien. Il va halluciner. Vous pouvez le blâmer, mais c'est vous qu'il faut blâmer - la modélisation est catastrophique.
Voilà le problème en production actuellement. On déploie des outils text-to-SQL sans faire le travail basique : expliquer clairement aux données ce qu'elles sont. C'est comme donner une requête SQL à un analyste en utilisant des noms de variables aléatoires. Mauvaise idée.
Chez Bomzai, on a vu les chiffres : quand la modélisation est bonne, la précision passe de 50% à 90% en 6-12 mois. Pas par magie. Par clarté.
Les noms, c'est 60% de la bataille
Première règle, stupidement simple mais ignorée partout : les colonnes doivent avoir des noms explicites. Pas des raccourcis. Pas de codes cryptiques.
« order_date » au lieu de « order_dt ». « customer_id » au lieu de « cust_id ». « order_revenue_usd » au lieu de « revenue ». Les chiffres sont clairs : avec des noms explicites, les LLM font 45% moins d'erreurs.
Pourquoi ? Parce qu'une colonne appelée « amount » pose des questions : c'est tous les montants ou seulement les ventes ? Avec « order_sales_amount », pas de doute.
Les préfixes aident. « is_ » pour les booléens (is_active, is_premium). « cnt_ » pour les comptages. « amt_ » pour les montants. C'est de la convention simple. Personne ne la suit. Presque tout le monde souffre.
Chaque colonne doit venir avec un mode d'emploi
Une table dans dbt c'est pas juste des colonnes. C'est une description, une granularité, une source, une fréquence de refresh. Chaque colonne : son type, sa logique métier, ses valeurs possibles, ses cas limites.
Exemple concret : « customer_region » n'est pas qu'une string. C'est une dimension avec les valeurs (EMEA, APAC, AMERICAS). « order_date » a un format (YYYY-MM-DD) et une granularité (jour). « total_revenue » doit avoir les règles explicites : inclure ou exclure quoi, filtrer comment.
Les relations entre tables doivent être explicites. Une commande a UN client, UN produit. Pas d'ambiguïté.
Quand un LLM a accès à ces métadata enrichies, il peut raisonner correctement. C'est exactement comme donner à un analyste humain le contexte nécessaire pour répondre sans erreurs.
Le Semantic Layer : la couche d'interface
En production, le Semantic Layer (dbt Semantic Layer, Cube.dev, AtScale) devient la vraie interface. Pas des tables brutes exposées. Des métriques et des dimensions avec des définitions rigides.
Un LLM qui construit sur un Semantic Layer génère automatiquement du bon SQL. Pourquoi ? Parce que le périmètre est clair. Pas d'ambiguïté sur « revenue » - il n'existe qu'une définition officielle.
C'est aussi le levier majeur pour la gouvernance. Quand la logique change (nouvelle définition de churn), c'est mis à jour une fois, utilisé partout. Pas 47 requêtes ad hoc à corriger.
Amélioration continue basée sur les erreurs
En production, on collecte les hallucinations. Quand le LLM génère une requête fausse, c'est un signal : qu'est-ce qui manque dans la modélisation ?
Colonne mal nommée ? La renommer. Métadata flou ? L'clarifier. Jointure compliquée ? La cacher sous une intermédiaire plus claire.
C'est du software engineering appliqué à la modélisation. Tests automatisés : « pour cette question, le LLM doit générer ce SQL exact ». Si le test échoue, c'est un signal pour remodéliser.
Les meilleures équipes que j'ai vues utilisent une boucle : question → LLM → SQL généré → validation → feedback → remodélisation. Ça prend 12 mois pour arriver à 90% de précision, mais ça arrive.
C'est pas de la technique, c'est de la clarté
La modélisation pour le text-to-insight n'est pas un sujet technique ésotérique. C'est hyper pragmatique.
Noms explicites. Documentation complète. Métadata enrichie. Sémantique cristalline. Quand une IA peut lire et comprendre les données directement, elle génère du bon SQL. 80% du succès du text-to-insight vient de là. Les 20% restants ? C'est le choix des outils.
Beaucoup font l'inverse : ils investissent dans les meilleurs LLM (Claude, GPT-4) et négligent la modélisation. Résultat : du bon LLM qui hallucine sur des données mal documentées. Gaspillage.
Commencez par le fondement. Les noms. La documentation. Le Semantic Layer. Puis ensuite, le LLM brille.
C'est pas rapide. C'est pas sexy. Mais c'est où les résultats mesurables arrivent.