Why Your Semantic Layer Matters More Than Your AI Agent
- Auteur
- Narendra Devarasetty
- Thème
- Data
- Mots-clés
- semantic layer, semantic model, SQL déterministe, analytics, metadata
- Ton
- opinion
Résumé
Narendra Devarasetty défend une thèse à contre-courant : le produit qui rend une IA analytique fiable, ce n'est pas l'agent, c'est le semantic layer. L'échec le plus silencieux de l'analytics n'est pas la requête qui plante, mais la requête qui réussit et renvoie le mauvais chiffre — un semantic model rend ce cas structurellement impossible. Le principe : l'IA interprète l'intention, mais un moteur déterministe génère le SQL (mêmes entrées, même sortie, sans LLM dans la génération). Le modèle est organisé en deux couches (physique et sémantique) et chaque métadonnée ajoutée répond à un échec précis observé.
💡 Pourquoi ça compte
C'est la démonstration concrète du principe « correctness over confidence » appliqué à la data : on ne fiabilise pas une IA analytique en améliorant l'agent, mais en construisant autour de lui une couche sémantique déterministe. Un pattern d'architecture clé pour tout produit data qui expose une interface en langage naturel.
Analyse approfondie
Le data warehouse sait quelles colonnes existent. Le semantic model sait ce qu'elles veulent dire. Cet article raconte comment l'auteur a construit la seconde couche par-dessus la première, et pourquoi il pense que c'est le modèle — et non l'agent IA — qui est le produit.
Le problème que de meilleurs prompts ne résolvent pas. Posez la question : où vit la définition de « revenue » ? Dans la requête SQL qu'un analyste a écrite le trimestre dernier ? Dans le pipeline de transformation qu'un data engineer maintient ? Dans un dashboard configuré il y a deux ans que personne ne veut toucher ? Dans un thread Slack où quelqu'un a expliqué au CFO que le « net revenue » n'inclut pas les remboursements mais que le « total revenue » les inclut ? Dans la plupart des organisations, la réponse est « tout ça à la fois ». Les définitions de métriques sont éparpillées entre requêtes, dashboards, documentation et savoir tribal. La même colonne est interprétée différemment par des équipes différentes. Donner à un LLM le schéma brut du warehouse ne résout rien : il héritera de la même ambiguïté.
L'approche : séparer ce qui change pour des raisons différentes. Le modèle est organisé en deux couches. La couche physique reflète le schéma du warehouse. La couche modèle définit la signification des données. Les deux évoluent indépendamment et sont possédées par des personnes différentes.
Comment le modèle résout les problèmes difficiles. L'IA interprète l'intention de l'utilisateur et la traduit en une requête sémantique. Puis un moteur déterministe génère le SQL. Mêmes entrées, même sortie, à chaque fois — aucun LLM n'intervient dans la génération de SQL. C'est ce qui rend l'échec silencieux impossible : la requête qui « réussit mais renvoie le mauvais chiffre » ne peut plus se produire, parce que la traduction intention → SQL est déterministe et gouvernée par le modèle.
La métadonnée comme infrastructure. Chaque élément de métadonnée fourni à l'IA — indices de désambiguïsation, types sémantiques, valeurs de filtre canoniques — a été ajouté pour corriger un échec spécifique et observé. Ce n'est pas de la documentation qu'on écrit « au cas où » : c'est de l'infrastructure qu'on construit en réponse à des défaillances réelles.
Le problème du démarrage à froid. Construire un semantic model est coûteux. Mais l'IA peut comprimer ce développement de plusieurs mois à quelques semaines, en générant des brouillons structurés qu'un humain revoit. Elle élimine le problème de la page blanche, sans pour autant devenir la source de vérité : c'est le modèle, revu par des humains, qui l'est.