Reimaginando a Modelagem de Dados no Lakehouse: Apresentando o Vibe Data Modeling

Os desafios da Modelagem de Dados

Em cada pilha de análise, a camada Silver é onde tudo se decide. BI e dashboards leem da camada Gold; Gold é construído a partir da Silver. O modelo da camada Silver é a base da qual todo analista, cientista de dados e ferramenta de BI depende. Se a camada Silver estiver bagunçada, sem governança ou cheia de duplicatas, tudo acima dela se torna mais difícil, lento e caro.

Chegar lá sempre foi o problema. A maioria das organizações gasta de seis meses a três anos construindo manualmente um modelo Silver do zero, ou compra um modelo genérico da indústria (ACORD para seguros, FHIR para saúde, ARTS para varejo, TM Forum SID para telecomunicações) e depois gasta de nove a doze meses ajustando, renomeando e reconfigurando-o. Um modelo é a média de um setor inteiro: tipicamente 20 a 40 por cento é relevante, e foi construído para nenhum negócio específico. Nenhum dos caminhos acompanha a velocidade com que os produtos de dados modernos precisam ser entregues.

Hoje, estamos anunciando o Vibe Data Modeling

O Vibe Data Modeling é um agente LLM multimodelos que transforma uma descrição simples do seu negócio em um modelo de dados completo, governado e implantável na camada Silver. Ele é entregue como um único notebook: quatro widgets, uma execução, um modelo totalmente implantado no Unity Catalog. Se você não gostar do resultado, você o “vibra” em linguagem simples até que se ajuste.

• Horas, não meses: um Modelo Viável Mínimo implantado em menos de duas horas, um Modelo de Cobertura Expandida em uma única tarde.
• 100% relevante para você: ele usa sua terminologia, divisões e domínios, não uma média do setor.
• Confiável por construção: 251 regras aplicáveis, duas revisões de arquitetos e um loop agêntico que prova o modelo antes de ser entregue.
• Implantação nativa no Unity Catalog: esquemas, tabelas, chaves estrangeiras, tags de classificação, visualizações de métricas, uma ontologia RDFS, um diagrama DBML e dados de amostra, gerados e versionados em conjunto.

As "vibes" do usuário são a autoridade suprema

Um princípio governa todo o agente: o que você diz prevalece. Uma instrução explícita em um widget, em model_vibes, ou na descrição do seu negócio supera qualquer heurística, fórmula de pontuação, gate e opinião de LLM no pipeline. Se você disser “exatamente 10 domínios”, nenhum classificador de nível poderá adicionar um décimo primeiro.

Como uma "vibe" se torna um modelo de dados

Por trás dos quatro widgets, o agente executa um pipeline em quatro estágios: ele entende sua entrada, projeta o modelo de cima para baixo, conecta-o com relacionamentos e métricas e, em seguida, o implanta. Cada estágio valida antes que o próximo comece, então apenas um estágio limpo avança. Por baixo, é um conjunto multimodelos: um modelo "pensador" grande lida com o raciocínio e as revisões, um modelo "trabalhador" grande gera o alto volume de produtos e atributos, modelos menores lidam com domínios, marcação e dados de amostra, e um "juiz" pontua propostas concorrentes em uma única rubrica. A lista se auto-cura, rebaixando um modelo com falha e restaurando-o quando saudável.

Como o modelo é organizado

Todo modelo segue a mesma forma, de cima para baixo: organização, divisões, domínios, subdomínios, produtos, atributos. No topo estão as três divisões que quase toda organização compartilha: Operações (o que fazem), Negócios (quem atendem) e Corporativo (como trabalham). Operações e Negócios são o núcleo; Corporativo é a minoria de apoio. Um domínio é um contexto delimitado que possui um conjunto distinto de conceitos; um produto é um conceito de negócio real que um especialista de domínio reconheceria (uma fatura, um pedido), nunca infraestrutura ou análise; e cada atributo precisa conquistar seu lugar.

Uma única fonte de verdade e um grafo limpo

Duas garantias estruturais mantêm o modelo coerente, e ambas são aplicadas. Uma única fonte de verdade significa que um conceito tem exatamente um produto proprietário; um cliente é definido uma vez em customer.customer e todos os outros o referenciam por chave estrangeira. E os relacionamentos formam um grafo acíclico direcionado: chaves estrangeiras apontam do filho para o pai, nunca em um ciclo, nenhum produto é deixado isolado, e colunas redundantes são normalizadas quando uma chave é estabelecida.

As regras que o tornam confiável

O agente aplica 251 regras em 20 grupos. As regras estruturais são gates determinísticos que leem o dicionário de modelo real, então não podem ser persuadidas a mudar um veredito, e são executadas enquanto o modelo é construído e novamente no gate de instalação contra o modelo implantado. A pontuação de qualidade que a execução relata é calculada a partir do próprio modelo, não da autoavaliação do LLM.

O loop agêntico: gerar, validar, tentar de forma diferente

Uma única passagem de LLM nunca é considerada final. O loop gera uma tentativa concreta, valida-a contra os gates determinísticos e a análise estática e, em caso de falha, muda a estratégia em vez de repetir. Requisitos não satisfeitos e resíduos estruturais (chaves desnormalizadas, duplicatas entre domínios, chaves estrangeiras não vinculadas ou cíclicas) são encaminhados para uma etapa de reparo em sandbox e de volta à validação. Um guarda monotônico reverte qualquer passagem que piore o modelo, de modo que ele só pode melhorar ou manter-se.

Como uma "vibe" é verificada

Quando você itera, sua solicitação é analisada em requisitos de verificação estruturados (VREQs), cada um uma diretriz discreta e verificável. Cada um é aplicado por um mutador em sandbox e verificado independentemente, deterministicamente sempre que possível: o gate lê o modelo real e o Unity Catalog físico em vez de perguntar a um LLM se a mudança ocorreu. A execução relata uma pontuação de aderência, e qualquer coisa não verificada é reenfileirada em vez de ser silenciosamente descartada.

Dois gates de arquitetos

As regras detectam o que está mecanicamente errado; os gates de arquitetos detectam o que é estruturalmente imprudente. O Arquiteto de Domínio revisa cada domínio isoladamente; o Arquiteto Global revisa o modelo completo em busca de duplicatas entre domínios, violações de fonte única de verdade e integridade estrutural. As descobertas são aplicadas automaticamente, rastreadas como implementadas, regredidas ou bloqueadas, e a revisão é executada novamente em até oito passagens até estar limpa.

O que você obtém em uma execução

• Um modelo lógico (model.json) com cada domínio, produto, atributo, chave estrangeira e tag de classificação.
• Uma implantação física no Unity Catalog: esquemas, tabelas, chaves estrangeiras (informativas) e tags de classificação.
• Visualizações de métricas do Unity Catalog: definições de KPI reutilizáveis nos produtos, prontas para dashboards de IA/BI e Genie.
• Uma ontologia RDFS para ferramentas semânticas e agentes de IA, e um arquivo DBML para dbdiagram.io.
• Dados de amostra sintéticos gerados a partir do mesmo modelo, além de um log completo do pipeline e um arquivo next_vibes de refinamentos sugeridos.

model.json: uma única fonte de verdade

Tudo o que o agente produz deriva de um único artefato, model.json. A implantação física, a ontologia, o diagrama DBML, as visualizações de métricas, os dados de amostra, a documentação e as sugestões do next_vibes são todos gerados a partir dele. Nada é criado duas vezes, então o modelo lógico e cada artefato subsequente nunca podem se desalinhar.

O que chega ao Unity Catalog

Ao definir um catálogo de implantação, os domínios se tornam esquemas, os produtos se tornam tabelas Delta, os atributos se tornam colunas; chaves estrangeiras são aplicadas como restrições informativas; tags de classificação (PII, glossário, proveniência) são aplicadas conforme ele é construído; e as visualizações de métricas são adicionadas por cima.

Dois escopos: MVM e ECM

A maioria das equipes não precisa de todos os domínios no primeiro dia, então o agente produz dois escopos a partir do mesmo motor. O Modelo Viável Mínimo (MVM) é o núcleo enxuto, construído primeiro; o Modelo de Cobertura Expandida (ECM) oferece cobertura total para todo o negócio. Você pode construir qualquer um, reduzir um ECM para um MVM, ou expandir um MVM para um ECM, e a redução é guiada por LLM para proteger os produtos essenciais.

Ajuste-o até que se encaixe

O refinamento é onde o Vibe Data Modeling ganha seu nome. A v1 é o modelo base e evolui para frente, nunca para os lados: nenhuma versão é sobrescrita, e cada iteração é auditável e reversível. As mudanças vêm em três modos de intenção: cirúrgico (corrigir exatamente isso), holístico (aplicar em todos os lugares) e generativo (criar algo novo), todos sob as mesmas regras e revisões.

Um agente, seis operações

O mesmo notebook faz mais do que construir um primeiro modelo. O widget de operação seleciona uma das seis operações, todas compartilhando as mesmas regras, portões de arquitetura e loop agêntico.

Como ajustar uma versão (VOV)

Para ajustar uma versão existente, selecione a operação “modelagem de ajuste de versão”, aponte-a para a versão na qual deseja construir e escreva suas alterações em inglês simples (ou cole as sugestões de next_vibes.txt). O agente os analisa em VREQs, executa novamente o pipeline sobre essa versão e escreve uma nova versão numerada; a versão da qual você começou permanece intocada.

Um modelo lógico, muitos layouts físicos

O modelo lógico é um artefato; o layout físico é uma decisão separada controlada por um único widget. O mesmo modelo pode ser renderizado como um catálogo, um catálogo por divisão ou um catálogo por domínio. Se a sua realidade de governança mudar, você reimplantará para uma convenção diferente; o modelo lógico permanece inalterado.

Modelos de indústria não são suficientes

O argumento para um modelo genérico sempre foi a vantagem inicial. A realidade, aprendida da maneira mais difícil, é que essa vantagem inicial custa de nove a doze meses de ajuste e renomeação. Um modelo é o modelo médio para um setor; por construção, não é o negócio real de ninguém. O Vibe Data Modeling produz um modelo na sua terminologia, com suas divisões e domínios, gerado em horas e validado pelas mesmas regras que todos os outros modelos.

Modelos de exemplo construídos com o agente

O mesmo agente agnóstico da indústria produziu Modelos de Cobertura Expandida de negócios completos em setores muito diferentes, cada um referenciando os padrões reconhecidos para sua indústria. As contagens abaixo são os modelos de referência publicados no repositório de código aberto.

Disponível hoje

A implementação de referência é um único notebook Databricks em agent/dbx_vibe_modelling_agent.ipynb. Preencha os quatro widgets principais e execute; todo o resto será padronizado de acordo com sua indústria.

Um ponto de partida concreto: aqui está o prompt que usamos para gerar um modelo de fabricação, e o primeiro ajuste em inglês simples que enviamos para refiná-lo.

• Repositório de referência (github.com/databricks-industry-solutions/lakehouse-industry-data-models): o notebook do agente, o orquestrador, um conjunto de testes, mais de 40 modelos de referência de código aberto e guias cobrindo design, integração, portões de qualidade e o catálogo de regras.
• O whitepaper Vibe Data Modeling: o tratamento técnico completo de cada estágio do pipeline, o catálogo de regras completo, a metodologia de revisão do arquiteto e a arquitetura de ensemble.

Se sua equipe tem levado um projeto de camada Silver por meses sem entregá-lo, este é o caminho mais curto que encontramos para realmente entregá-lo. Descreva seu negócio em inglês simples, obtenha um modelo, itere até que se encaixe e coloque-o em produção.

(Esta publicação no blog foi traduzida utilizando ferramentas baseadas em inteligência artificial) Publicação original