Ripensare la modellazione dei dati sul Lakehouse: presentiamo Vibe Data Modeling

Le sfide della modellazione dei dati

In ogni stack di analytics, il Silver layer è quello che fa la differenza. La BI e le dashboard leggono dal Gold layer; il Gold è costruito a partire dal Silver. Il modello del Silver layer è la base da cui dipende ogni analista, data scientist e strumento di BI. Se il Silver layer è disordinato, privo di governance o pieno di duplicati, tutto ciò che si trova sopra diventa più difficile, lento e costoso.

Raggiungere questo obiettivo è sempre stato il problema. La maggior parte delle organizzazioni trascorre da sei mesi a tre anni a costruire manualmente da zero un modello Silver, oppure acquista un template di settore generico (ACORD per le assicurazioni, FHIR per la sanità, ARTS per il retail, TM Forum SID per le telecomunicazioni) per poi passare da nove a dodici mesi a ridurlo, rinominarlo e riconfigurarlo. Un template rappresenta la media di un intero settore: in genere solo il 20-40% è pertinente, ed è stato creato senza un'azienda specifica in mente. Nessuno dei due percorsi tiene il passo con la velocità con cui devono essere rilasciati i moderni prodotti di dati.

Oggi annunciamo Vibe Data Modeling

Vibe Data Modeling è un agente LLM multi-modello che trasforma una descrizione in linguaggio naturale della tua attività in un modello di dati Silver-layer completo, governato e distribuito. Viene fornito come un singolo notebook: quattro widget, un'unica esecuzione e un modello completamente distribuito in Unity Catalog. Se il risultato non ti soddisfa, puoi fare il "vibe" in linguaggio naturale finché non si adatta alle tue esigenze.

• Ore, non mesi: un Minimum Viable Model distribuito in meno di due ore, un Expanded Coverage Model in un solo pomeriggio.
• Rilevante al 100% per te: utilizza la tua terminologia, le tue divisioni e i tuoi domini, non la media del settore.
• Affidabile per progettazione: 251 regole applicabili, due revisioni dell'architetto e un loop agentico che testa il modello prima della distribuzione.
• Distribuzione nativa in Unity Catalog: schemi, tabelle, chiavi esterne, tag di classificazione, viste metriche, un'ontologia RDFS, un diagramma DBML e dati di esempio, generati e versionati insieme.

I "vibe" dell'utente sono l'autorità suprema

Un unico principio governa l'intero agente: ciò che dici tu è legge. Un'istruzione esplicita in un widget, in model_vibes o nella descrizione della tua attività ha la priorità su ogni euristica, formula di punteggio, gate e opinione dell'LLM nella pipeline. Se dici "esattamente 10 domini", nessun classificatore di livello potrà aggiungerne un undicesimo.

Come un "vibe" diventa un modello di dati

Dietro i quattro widget, l'agente esegue una pipeline in quattro fasi: comprende l'input, progetta il modello dall'alto verso il basso, lo collega con relazioni e metriche, quindi lo distribuisce. Ogni fase viene convalidata prima dell'inizio di quella successiva, in modo che solo una fase priva di errori possa avanzare. Sotto il cofano, si tratta di un ensemble multi-modello: un modello "thinker" di grandi dimensioni gestisce il ragionamento e le revisioni, un modello "worker" di grandi dimensioni genera l'elevato volume di prodotti e attributi, modelli più piccoli gestiscono domini, tagging e dati di esempio, e un giudice valuta le proposte concorrenti in base a un'unica rubrica. Il roster si auto-ripara, declassando un modello che fallisce e ripristinandolo una volta tornato integro.

Come è organizzato il modello

Ogni modello segue la stessa struttura, dall'alto verso il basso: organizzazione, divisioni, domini, sottodomini, prodotti, attributi. In cima si trovano le tre divisioni che quasi tutte le organizzazioni condividono: Operations (cosa fanno), Business (chi servono) e Corporate (come lavorano). Operations e Business costituiscono il nucleo; Corporate è la parte di supporto minoritaria. Un dominio è un contesto delimitato (bounded context) che possiede un insieme distinto di concetti; un prodotto è un concetto di business reale che un esperto di dominio riconoscerebbe (una fattura, un ordine), mai elementi di infrastruttura o analytics; e ogni attributo deve meritarsi il suo posto.

Un'unica fonte di verità e un grafo pulito

Due garanzie strutturali mantengono il modello coerente, ed entrambe vengono applicate. "Un'unica fonte di verità" significa che un concetto ha esattamente un solo prodotto proprietario; un cliente viene definito una sola volta in customer.customer e tutti gli altri vi fanno riferimento tramite chiave esterna. Inoltre, le relazioni formano un grafo aciclico diretto (DAG): le chiavi esterne collegano il figlio al genitore, mai in ciclo, nessun prodotto viene lasciato isolato e le colonne ridondanti vengono normalizzate quando viene inserita una chiave.

Le regole che lo rendono affidabile

L'agente applica 251 regole suddivise in 20 gruppi. Quelle strutturali sono gate deterministici che leggono il dizionario del modello reale, quindi non possono essere influenzati nel loro verdetto, e vengono eseguiti durante la costruzione del modello e nuovamente al gate di installazione rispetto al modello distribuito. Il punteggio di qualità riportato dall'esecuzione è calcolato a partire dal modello stesso, non dall'autovalutazione dell'LLM.

Il loop agentico: genera, convalida, riprova in modo diverso

Un singolo passaggio dell'LLM non viene mai considerato definitivo. Il loop genera un tentativo concreto, lo convalida rispetto ai gate deterministici e all'analisi statica e, in caso di errore, cambia strategia anziché ripetere lo stesso tentativo. I requisiti non soddisfatti e i residui strutturali (chiavi denormalizzate, duplicati cross-dominio, chiavi esterne non collegate o cicliche) vengono indirizzati a una fase di ripristino in sandbox e nuovamente sottoposti a convalida. Una guardia monotonica annulla qualsiasi passaggio che peggiori il modello, in modo che questo possa solo migliorare o rimanere stabile.

Come viene verificato un "vibe"

Quando esegui un'iterazione, la tua richiesta viene analizzata in requisiti di verifica strutturati (VREQ), ciascuno dei quali è una direttiva discreta e verificabile. Ognuno viene applicato da un mutatore in sandbox e verificato in modo indipendente, ove possibile in modo deterministico: il gate legge il modello reale e l'istanza fisica di Unity Catalog anziché chiedere a un LLM se la modifica è avvenuta. L'esecuzione riporta un punteggio di aderenza e tutto ciò che non è verificato viene reinserito in coda anziché essere rimosso silenziosamente.

Due gate dell'architetto

Le regole individuano ciò che è meccanicamente errato; i gate dell'architetto individuano ciò che è strutturalmente sconsigliabile. Il Domain Architect esamina ogni dominio in isolamento; il Global Architect esamina l'intero modello per individuare duplicati cross-dominio, violazioni dell'unica fonte di verità e problemi di integrità strutturale. I risultati vengono applicati automaticamente, tracciati come applicati, regrediti o bloccati, e la revisione viene eseguita nuovamente fino a un massimo di otto passaggi finché non risulta pulita.

Cosa ottieni da una singola esecuzione

• Un modello logico (model.json) con ogni dominio, prodotto, attributo, chiave esterna e tag di classificazione.
• Una distribuzione fisica in Unity Catalog: schemi, tabelle, chiavi esterne (informative) e tag di classificazione.
• Viste metriche di Unity Catalog: definizioni di KPI riutilizzabili sui prodotti, pronte per le dashboard AI/BI e Genie.
• Un'ontologia RDFS per strumenti semantici e agenti IA, e un file DBML per dbdiagram.io.
• Dati di esempio sintetici generati a partire dallo stesso modello, oltre a un log completo della pipeline e a un file next_vibes con i perfezionamenti suggeriti.

model.json: un'unica fonte di verità

Tutto ciò che l'agente produce deriva da un singolo artefatto, model.json. La distribuzione fisica, l'ontologia, il diagramma DBML, le viste delle metriche, i dati di esempio, la documentazione e i suggerimenti di next_vibes sono tutti generati a partire da esso. Nulla viene creato due volte, quindi il modello logico e ogni artefatto a valle non possono mai disallinearsi.

Cosa viene inserito in Unity Catalog

Quando si imposta un catalogo di distribuzione, i domini diventano schemi, i prodotti diventano tabelle Delta, gli attributi diventano colonne; le chiavi esterne vengono applicate come vincoli informativi; i tag di classificazione (PII, glossario, provenienza) vengono applicati durante la creazione; e le viste delle metriche si posizionano al di sopra.

Due ambiti: MVM e ECM

La maggior parte dei team non ha bisogno di tutti i domini fin dal primo giorno, quindi l'agente produce due ambiti dallo stesso motore. Il Minimum Viable Model è il nucleo essenziale, creato per primo; l'Expanded Coverage Model offre una copertura completa per l'intera azienda. È possibile creare entrambi, ridurre un ECM in un MVM o ampliare un MVM in un ECM; la riduzione è guidata da un LLM, in modo da proteggere i prodotti principali.

Perfezionalo finché non si adatta

Il perfezionamento è la fase in cui il Vibe Data Modeling dimostra il suo valore. La v1 è il modello di base ed evolve in avanti, mai lateralmente: nessuna versione viene sovrascritta e ogni iterazione è verificabile e reversibile. Le modifiche avvengono in tre modalità di intento: chirurgica (correggi esattamente questo), olistica (applica ovunque) e generativa (crea qualcosa di nuovo), tutte soggette alle stesse regole e revisioni.

Un solo agente, sei operazioni

Lo stesso notebook fa molto di più che creare un primo modello. Il widget delle operazioni consente di selezionare una delle sei operazioni, che condividono tutte le stesse regole, i gate dell'architetto e il loop agentico.

Come perfezionare una versione (VOV)

Per perfezionare una versione esistente, seleziona l'operazione “vibe modeling of version”, indirizzala verso la versione su cui basarti e scrivi le modifiche in linguaggio naturale (o incolla i suggerimenti da next_vibes.txt). L'agente le analizza in VREQs, esegue nuovamente la pipeline su quella versione e scrive una nuova versione numerata; quella da cui sei partito rimane intatta.

Un solo modello logico, molti layout fisici

Il modello logico è un singolo artefatto; il layout fisico è una decisione separata controllata da un singolo widget. Lo stesso modello può essere rappresentato come un unico catalogo, un catalogo per divisione o un catalogo per dominio. Se le tue esigenze di governance cambiano, puoi eseguire nuovamente la distribuzione secondo una convenzione diversa; il modello logico rimane invariato.

I modelli di settore non bastano

L'argomento a favore di un modello generico è sempre stato il vantaggio iniziale. La realtà, appresa a proprie spese, è che questo vantaggio iniziale costa da nove a dodici mesi di adattamento e ridenominazione. Un modello è la media di un settore; per sua natura non corrisponde all'attività reale di nessuno. Vibe Data Modeling produce un modello con la tua terminologia, le tue divisioni e i tuoi domini, generato in poche ore e convalidato dalle stesse regole di tutti gli altri modelli.

Esempi di modelli creati con l'agente

Lo stesso agente indipendente dal settore ha prodotto Expanded Coverage Models completi per settori molto diversi, ciascuno dei quali fa riferimento agli standard riconosciuti per il proprio ambito. I conteggi riportati di seguito rappresentano i modelli di riferimento pubblicati nel repository open source.

Disponibile oggi

L'implementazione di riferimento è un singolo notebook Databricks all'indirizzo agent/dbx_vibe_modelling_agent.ipynb. Compila i quattro widget principali ed esegui; tutto il resto utilizzerà i valori predefiniti per il tuo settore.

Un punto di partenza concreto: ecco il prompt che abbiamo utilizzato per generare un modello di produzione e la prima istruzione in linguaggio naturale che abbiamo inviato per perfezionarlo.

• Repository di riferimento (github.com/databricks-industry-solutions/lakehouse-industry-data-models): il notebook dell'agente, l'orchestratore, un test harness, oltre 40 modelli di riferimento open source e guide che coprono la progettazione, l'integrazione, i quality gate e il catalogo delle regole.
• Il whitepaper di Vibe Data Modeling: la trattazione tecnica completa di ogni fase della pipeline, il catalogo completo delle regole, la metodologia di revisione dell'architetto e l'architettura ensemble.

Se il tuo team porta avanti un progetto per il livello Silver da mesi senza rilasciarlo, questo è il percorso più breve che abbiamo trovato per implementarlo concretamente. Descrivi la tua attività in linguaggio naturale, ottieni un modello, esegui l'iterazione finché non si adatta e distribuiscilo in produzione.

(Questo post sul blog è stato tradotto utilizzando strumenti basati sull'intelligenza artificiale) Post originale