Repenser la modélisation des données sur le Lakehouse : présentation de Vibe Data Modeling

Les défis de la modélisation des données

Dans toute architecture analytique, la couche Silver est le point névralgique. La BI et les tableaux de bord lisent à partir de la couche Gold ; la couche Gold est construite à partir de la couche Silver. Le modèle de la couche Silver est la fondation dont dépendent chaque analyste, data scientist et outil de BI. Si la couche Silver est désordonnée, non gouvernée ou pleine de doublons, tout ce qui se trouve au-dessus devient plus difficile, plus lent et plus coûteux.

Y parvenir a toujours été le problème. La plupart des organisations passent de six mois à trois ans à concevoir manuellement un modèle Silver à partir de zéro, ou bien elles achètent un modèle sectoriel générique (ACORD pour l'assurance, FHIR pour la santé, ARTS pour le commerce de détail, TM Forum SID pour les télécoms) et passent ensuite neuf à douze mois à le nettoyer, le renommer et le réorganiser. Un modèle générique n'est que la moyenne d'un secteur entier : généralement, seuls 20 à 40 % sont pertinents, et il n'a été conçu pour aucune entreprise en particulier. Aucune de ces approches ne permet de suivre le rythme de livraison rapide requis par les produits de données modernes.

Aujourd'hui, nous annonçons Vibe Data Modeling

Vibe Data Modeling est un agent LLM multi-modèle qui transforme une description en anglais simple de votre entreprise en un modèle de données de couche Silver complet, gouverné et déployable. Il est livré sous la forme d'un seul notebook : quatre widgets, une seule exécution, et un modèle entièrement déployé dans Unity Catalog. Si le résultat ne vous convient pas, vous le « vibez » en anglais simple jusqu'à ce qu'il corresponde à vos besoins.

• Quelques heures, pas des mois : un modèle viable minimum déployé en moins de deux heures, un modèle à couverture étendue en une seule après-midi.
• 100 % pertinent pour vous : il utilise votre terminologie, vos divisions et vos domaines, et non une moyenne sectorielle.
• Fiable par conception : 251 règles applicables, deux examens d'architecte et une boucle d'agents qui valide le modèle avant sa livraison.
• Déploiement natif dans Unity Catalog : schémas, tables, clés étrangères, balises de classification, vues de métriques, une ontologie RDFS, un diagramme DBML et des exemples de données, le tout généré et versionné ensemble.

Les « vibes » de l'utilisateur font autorité

Un seul principe régit l'ensemble de l'agent : vos instructions sont prioritaires. Une consigne explicite dans un widget, dans model_vibes ou dans la description de votre entreprise l'emporte sur chaque heuristique, formule de score, barrière de validation et avis du LLM dans le pipeline. Si vous demandez « exactement 10 domaines », aucun classificateur de niveau ne pourra en ajouter un onzième.

Comment une « vibe » devient un modèle de données

Derrière les quatre widgets, l'agent exécute un pipeline en quatre étapes : il comprend votre saisie, conçoit le modèle de haut en bas, le connecte avec des relations et des métriques, puis le déploie. Chaque étape est validée avant que la suivante ne commence, de sorte que seule une étape sans erreur progresse. En arrière-plan, il s'agit d'un ensemble multi-modèle : un grand modèle de réflexion gère le raisonnement et les examens, un grand modèle d'exécution génère le volume élevé de produits et d'attributs, des modèles plus petits gèrent les domaines, le balisage et les exemples de données, et un juge évalue les propositions concurrentes selon une grille unique. La liste s'auto-génère et s'auto-guérit, rétrogradant un modèle défaillant et le rétablissant une fois qu'il est à nouveau opérationnel.

Comment le modèle est organisé

Chaque modèle suit la même structure, de haut en bas : organisation, divisions, domaines, sous-domaines, produits, attributs. Au sommet se trouvent les trois divisions que presque toutes les organisations partagent : Operations (ce qu'elles font), Business (qui elles servent) et Corporate (comment elles fonctionnent). Operations et Business constituent le cœur ; Corporate est la partie de soutien. Un domaine est un contexte délimité qui possède un ensemble distinct de concepts ; un produit est un concept métier réel qu'un expert du domaine reconnaîtrait (une facture, une commande), jamais de la tuyauterie technique ou de l'analytique ; et chaque attribut doit mériter sa place.

Une source unique de vérité et un graphe propre

Deux garanties structurelles maintiennent la cohérence du modèle, et toutes deux sont appliquées. La source unique de vérité signifie qu'un concept possède exactement un produit propriétaire ; un client est défini une seule fois dans customer.customer et tous les autres y font référence par clé étrangère. De plus, les relations forment un graphe orienté acyclique (DAG) : les clés étrangères pointent de l'enfant vers le parent, jamais en cycle, aucun produit n'est laissé isolé, et les colonnes redondantes sont éliminées par normalisation lorsqu'une clé est établie.

Les règles qui le rendent fiable

L'agent applique 251 règles réparties en 20 groupes. Les règles structurelles sont des barrières déterministes qui lisent le dictionnaire du modèle réel, de sorte qu'elles ne peuvent pas être influencées dans leur verdict. Elles s'exécutent lors de la construction du modèle et à nouveau lors de la barrière d'installation par rapport au modèle déployé. Le score de qualité signalé par l'exécution est calculé à partir du modèle lui-même, et non à partir de l'auto-évaluation du LLM.

La boucle d'agents : générer, valider, réessayer différemment

Un seul passage de LLM n'est jamais considéré comme définitif. La boucle génère une tentative concrète, la valide par rapport aux barrières déterministes et à l'analyse statique, et en cas d'échec, change de stratégie plutôt que de répéter la même action. Les exigences non satisfaites et les résidus structurels (clés dénormalisées, doublons inter-domaines, clés étrangères non liées ou cycliques) sont acheminés vers une étape de réparation isolée (sandbox) puis repassent par la validation. Une garde monotone annule tout passage qui dégrade le modèle, de sorte qu'il ne peut que s'améliorer ou se maintenir.

Comment une « vibe » est vérifiée

Lorsque vous effectuez des itérations, votre demande est analysée sous forme d'exigences de vérification structurées (VREQs), chacune étant une directive distincte et vérifiable. Chacune est appliquée par un mutateur isolé (sandbox) et vérifiée de manière indépendante, de façon déterministe lorsque cela est possible : la barrière lit le modèle réel et le Unity Catalog physique plutôt que de demander à un LLM si le changement a eu lieu. L'exécution signale un score d'adhérence, et tout élément non vérifié est remis en file d'attente plutôt que d'être discrètement abandonné.

Deux barrières d'architecte

Les règles détectent ce qui est mécaniquement incorrect ; les barrières d'architecte détectent ce qui est structurellement imprudent. L'Architecte de domaine examine chaque domaine de manière isolée ; l'Architecte global examine l'ensemble du modèle pour détecter les doublons inter-domaines, les violations de la source unique de vérité et l'intégrité structurelle. Les résultats sont appliqués automatiquement, suivis comme intégrés, régressés ou bloqués, et l'examen s'exécute à nouveau jusqu'à huit fois jusqu'à ce qu'il soit propre.

Ce que vous obtenez d'une seule exécution

• Un modèle logique (model.json) avec chaque domaine, produit, attribut, clé étrangère et balise de classification.
• Un déploiement physique dans Unity Catalog : schémas, tables, clés étrangères (informatives) et balises de classification.
• Des vues de métriques Unity Catalog : des définitions de KPI réutilisables sur les produits, prêtes pour les tableaux de bord AI/BI et Genie.
• Une ontologie RDFS pour les outils sémantiques et les agents d'IA, ainsi qu'un fichier DBML pour dbdiagram.io.
• Des exemples de données synthétiques générés par rapport au même modèle, plus un journal complet du pipeline et un fichier next_vibes de suggestions d'ajustements.

model.json : une source unique de vérité

Tout ce que l'agent produit provient d'un seul artefact, model.json. Le déploiement physique, l'ontologie, le diagramme DBML, les vues de métriques, les exemples de données, la documentation et les suggestions next_vibes en sont tous générés. Rien n'est rédigé deux fois, de sorte que le modèle logique et chaque artefact en aval ne peuvent jamais diverger.

Ce qui arrive dans Unity Catalog

Lorsque vous définissez un catalogue de déploiement, les domaines deviennent des schémas, les produits deviennent des tables Delta, les attributs deviennent des colonnes ; les clés étrangères sont appliquées comme des contraintes d'information ; les étiquettes de classification (PII, glossaire, provenance) sont appliquées au fur et à mesure de sa construction ; et les vues de métriques s'ajoutent par-dessus.

Deux portées : MVM et ECM

La plupart des équipes n'ont pas besoin de tous les domaines dès le premier jour, c'est pourquoi l'agent produit deux portées à partir du même moteur. Le Minimum Viable Model est le cœur épuré, construit en premier ; l'Expanded Coverage Model offre une couverture complète de l'ensemble de l'entreprise. Vous pouvez construire l'un ou l'autre, réduire un ECM en un MVM, ou agrandir un MVM en un ECM, et la réduction est guidée par LLM afin de protéger les produits de base.

Ajustez-le jusqu'à ce qu'il convienne

C'est lors de l'affinage que le Vibe Data Modeling prend tout son sens. La v1 est le modèle de base et elle évolue vers l'avant, jamais de côté : aucune version n'est écrasée, et chaque itération est auditable et réversible. Les modifications se font selon trois modes d'intention : chirurgical (corriger exactement ceci), holistique (appliquer partout) et génératif (créer quelque chose de nouveau), le tout soumis aux mêmes règles et examens.

Un agent, six opérations

Le même notebook fait plus que construire un premier modèle. Le widget d'opération permet de sélectionner l'une des six opérations, qui partagent toutes les mêmes règles, validations d'architecture et boucle d'agent.

Comment ajuster une version (VOV)

Pour ajuster une version existante, sélectionnez l'opération « vibe modeling of version », pointez-la vers la version sur laquelle vous souhaitez vous baser, et écrivez vos modifications en anglais simple (ou collez les suggestions de next_vibes.txt). L'agent les analyse sous forme de VREQ, réexécute le pipeline par-dessus cette version et écrit une nouvelle version numérotée ; celle dont vous êtes parti reste intacte.

Un modèle logique, plusieurs configurations physiques

Le modèle logique est un seul artefact ; la configuration physique est une décision distincte contrôlée par un seul widget. Le même modèle peut être représenté sous la forme d'un seul catalogue, d'un catalogue par division ou d'un catalogue par domaine. Si vos impératifs de gouvernance changent, vous redéployez vers une autre convention ; le modèle logique reste inchangé.

Les modèles sectoriels ne suffisent pas

L'argument en faveur d'un modèle générique a toujours été l'avance qu'il procure. La réalité, apprise à nos dépens, est que cette avance coûte neuf à douze mois d'ajustements et de renommages. Un modèle type est le modèle moyen d'un secteur ; par définition, il ne correspond à l'activité réelle de personne. Le Vibe Data Modeling produit un modèle utilisant votre terminologie, avec vos divisions et vos domaines, généré en quelques heures et validé par les mêmes règles que tous les autres modèles.

Exemples de modèles construits avec l'agent

Le même agent, indépendant du secteur, a produit des Expanded Coverage Models pour l'ensemble de l'entreprise dans des secteurs très différents, chacun faisant référence aux normes reconnues de son industrie. Les chiffres ci-dessous correspondent aux modèles de référence publiés dans le dépôt open source.

Disponible dès aujourd'hui

L'implémentation de référence est un simple notebook Databricks situé à l'adresse agent/dbx_vibe_modelling_agent.ipynb. Remplissez les quatre widgets principaux et lancez l'exécution ; tout le reste est défini par défaut selon votre secteur d'activité.

Un point de départ concret : voici le prompt que nous avons utilisé pour générer un modèle de fabrication, et le premier ajustement (vibe) en anglais simple que nous avons envoyé pour l'affiner.

• Dépôt de référence (github.com/databricks-industry-solutions/lakehouse-industry-data-models) : le notebook de l'agent, l'orchestrateur, un harnais de test, plus de 40 modèles de référence open source et des guides couvrant la conception, l'intégration, les barrières de qualité et le catalogue de règles.
• Le livre blanc sur le Vibe Data Modeling : le traitement technique complet de chaque étape du pipeline, le catalogue de règles complet, la méthodologie de révision par l'architecte et l'architecture d'ensemble.

Si votre équipe porte un projet de couche Silver depuis des mois sans le livrer, c'est le chemin le plus court que nous ayons trouvé pour y parvenir enfin. Décrivez votre activité en anglais simple, obtenez un modèle, effectuez des itérations jusqu'à ce qu'il convienne et mettez-le en production.

(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original