Reimaginando el modelado de datos en el Lakehouse: Presentamos Vibe Data Modeling

Los desafíos del modelado de datos

En cualquier pila de analítica, la capa Silver es donde se decide el éxito o el fracaso. BI y los dashboards leen de Gold; Gold se construye a partir de Silver. El modelo de la capa Silver es la base de la que dependen todos los analistas, científicos de datos y herramientas de BI. Si la capa Silver está desordenada, no está gobernada o está llena de duplicados, todo lo que está por encima se vuelve más difícil, lento y costoso.

Llegar ahí siempre ha sido el problema. La mayoría de las organizaciones pasan de seis meses a tres años construyendo manualmente un modelo Silver desde cero, o compran una plantilla genérica del sector (ACORD para seguros, FHIR para el sector salud, ARTS para comercio minorista, TM Forum SID para telecomunicaciones) y luego pasan de nueve a doce meses recortándola, renombrándola y adaptándola. Una plantilla es el promedio de todo un sector: normalmente solo del 20 al 40 por ciento es relevante, y no se creó para ningún negocio en específico. Ninguno de los dos caminos va al ritmo que exige el lanzamiento de los productos de datos modernos.

Hoy anunciamos Vibe Data Modeling

Vibe Data Modeling es un agente de LLM multimodelo que convierte una descripción en inglés sencillo de tu negocio en un modelo de datos de capa Silver completo, gobernado y listo para implementar. Se entrega como un solo notebook: cuatro widgets, una ejecución y un modelo completamente implementado en Unity Catalog. Si no te gusta el resultado, puedes ajustarlo con "vibes" en inglés sencillo hasta que se adapte a tus necesidades.

• Horas, no meses: un Modelo Mínimo Viable implementado en menos de dos horas, y un Modelo de Cobertura Ampliada en una sola tarde.
• 100 % relevante para ti: utiliza tu terminología, divisiones y dominios, no el promedio de un sector.
• Confiable por diseño: 251 reglas aplicables, dos revisiones de arquitectura y un bucle agéntico que pone a prueba el modelo antes de su lanzamiento.
• Implementación nativa en Unity Catalog: esquemas, tablas, claves foráneas, etiquetas de clasificación, vistas de métricas, una ontología RDFS, un diagrama DBML y datos de muestra, todo generado y versionado en conjunto.

Los "vibes" del usuario son la autoridad suprema

Un solo principio gobierna a todo el agente: lo que tú digas manda. Una instrucción explícita en un widget, en model_vibes, o en la descripción de tu negocio tiene prioridad sobre cualquier heurística, fórmula de puntuación, control u opinión del LLM en el pipeline. Si dices "exactamente 10 dominios", ningún clasificador de niveles podrá añadir un undécimo.

Cómo un "vibe" se convierte en un modelo de datos

Detrás de los cuatro widgets, el agente ejecuta un pipeline en cuatro etapas: comprende tu entrada, diseña el modelo de arriba hacia abajo, lo conecta con relaciones y métricas, y luego lo implementa. Cada etapa se valida antes de que comience la siguiente, por lo que solo avanzan las etapas limpias. Por debajo, es un ensamble multimodelo: un modelo pensador grande se encarga del razonamiento y las revisiones, un modelo trabajador grande genera el alto volumen de productos y atributos, modelos más pequeños manejan los dominios, el etiquetado y los datos de muestra, y un juez califica las propuestas de la competencia según una rúbrica. La lista se autorrepara, degradando temporalmente cualquier modelo que falle y restaurándolo una vez que se recupera.

Cómo se organiza el modelo

Cada modelo sigue la misma estructura, de arriba a abajo: organización, divisiones, dominios, subdominios, productos y atributos. En la parte superior se encuentran las tres divisiones que casi todas las organizaciones comparten: Operaciones (lo que hacen), Negocios (a quiénes sirven) y Corporativo (cómo trabajan). Operaciones y Negocios son el núcleo; Corporativo es la minoría de soporte. Un dominio es un contexto delimitado que posee un conjunto distinto de conceptos; un producto es un concepto de negocio real que un experto en el dominio reconocería (una factura, un pedido), nunca infraestructura técnica ni analítica; y cada atributo tiene que ganarse su lugar.

Una única fuente de verdad y un gráfico limpio

Dos garantías estructurales mantienen la coherencia del modelo, y ambas se aplican estrictamente. Una única fuente de verdad significa que un concepto pertenece exactamente a un producto; un cliente se define una sola vez en customer.customer y todos los demás lo referencian mediante una clave foránea. Además, las relaciones forman un gráfico acíclico dirigido (DAG): las claves foráneas apuntan del hijo al padre, nunca en ciclo, ningún producto queda aislado y las columnas redundantes se eliminan mediante normalización cuando se establece una clave.

Las reglas que lo hacen confiable

El agente aplica 251 reglas en 20 grupos. Las estructurales son controles deterministas que leen el diccionario del modelo real, por lo que no se les puede persuadir para cambiar un veredicto, y se ejecutan a medida que se construye el modelo y nuevamente en el control de instalación contra el modelo implementado. La puntuación de calidad que reporta la ejecución se calcula a partir del propio modelo, no de la autoevaluación del LLM.

El bucle agéntico: generar, validar, reintentar de otra manera

Nunca se confía en una sola pasada de LLM como definitiva. El bucle genera un intento concreto, lo valida frente a los controles deterministas y el análisis estático, y en caso de fallo cambia de estrategia en lugar de repetir. Los requisitos no satisfechos y los residuos estructurales (claves desnormalizadas, duplicados entre dominios, claves foráneas desvinculadas o cíclicas) se dirigen a un paso de reparación aislado (sandbox) y vuelven a pasar por la validación. Una protección monotónica revierte cualquier pasada que empeore el modelo, por lo que este solo puede mejorar o mantenerse.

Cómo se verifica un "vibe"

Cuando realizas iteraciones, tu solicitud se analiza en requisitos de verificación estructurados (VREQ), cada uno de los cuales es una directiva discreta y comprobable. Cada uno se aplica mediante un mutador aislado (sandbox) y se verifica de forma independiente, determinista cuando es posible: el control lee el modelo real y el Unity Catalog físico en lugar de preguntar a un LLM si se realizó el cambio. La ejecución reporta una puntuación de adherencia, y cualquier elemento no verificado se vuelve a poner en cola en lugar de descartarse silenciosamente.

Dos controles de arquitectura

Las reglas detectan lo que está mecánicamente mal; los controles de arquitectura detectan lo que no es estructuralmente recomendable. El Arquitecto de Dominio revisa cada dominio de forma aislada; el Arquitecto Global revisa todo el modelo en busca de duplicados entre dominios, violaciones de la única fuente de verdad e integridad estructural. Los hallazgos se aplican automáticamente, se les hace un seguimiento como implementados, revertidos o bloqueados, y la revisión se vuelve a ejecutar hasta ocho veces hasta que quede limpia.

Lo que obtienes con una sola ejecución

• Un modelo lógico (model.json) con cada dominio, producto, atributo, clave foránea y etiqueta de clasificación.
• Una implementación física en Unity Catalog: esquemas, tablas, claves foráneas (informativas) y etiquetas de clasificación.
• Vistas de métricas de Unity Catalog: definiciones de KPI reutilizables en los productos, listas para dashboards de AI/BI y Genie.
• Una ontología RDFS para herramientas semánticas y agentes de IA, y un archivo DBML para dbdiagram.io.
• Datos de muestra sintéticos generados a partir del mismo modelo, además de un registro completo del pipeline y un archivo next_vibes con sugerencias de perfeccionamiento.

model.json: una única fuente de verdad

Todo lo que produce el agente deriva de un único artefacto: model.json. El despliegue físico, la ontología, el diagrama DBML, las vistas de métricas, los datos de muestra, la documentación y las sugerencias de next_vibes se generan a partir de él. Nada se crea por duplicado, por lo que el modelo lógico y cada artefacto derivado nunca pueden desalinearse.

Qué se almacena en Unity Catalog

Al configurar un catálogo de despliegue, los dominios se convierten en esquemas, los productos en tablas Delta y los atributos en columnas; las claves foráneas se aplican como restricciones informativas; las etiquetas de clasificación (PII, glosario, procedencia) se aplican a medida que se compila; y las vistas de métricas se colocan encima.

Dos alcances: MVM y ECM

La mayoría de los equipos no necesitan todos los dominios desde el primer día, por lo que el agente produce dos alcances desde el mismo motor. El Modelo Mínimo Viable es el núcleo optimizado que se compila primero; el Modelo de Cobertura Ampliada ofrece una cobertura completa de todo el negocio. Puedes compilar cualquiera de los dos, reducir un ECM a un MVM o ampliar un MVM a un ECM. Además, la reducción está guiada por LLM, por lo que protege los productos principales.

Ajústalo hasta que encaje

El refinamiento es donde el Modelado de datos Vibe hace honor a su nombre. La v1 es el modelo base y evoluciona hacia adelante, nunca hacia los lados: ninguna versión se sobrescribe y cada iteración es auditable y reversible. Los cambios se presentan en tres modos de intención: quirúrgico (corregir exactamente esto), holístico (aplicar en todas partes) y generativo (crear algo nuevo), todo bajo las mismas reglas y revisiones.

Un agente, seis operaciones

El mismo notebook hace más que compilar un primer modelo. El widget de operación selecciona una de las seis operaciones, y todas comparten las mismas reglas, filtros de arquitectura y bucle agéntico.

Cómo ajustar una versión (VOV)

Para ajustar una versión existente, selecciona la operación “vibe modeling of version”, apúntala a la versión sobre la que deseas compilar y escribe tus cambios en inglés sencillo (o pega las sugerencias de next_vibes.txt). El agente los analiza en VREQs, vuelve a ejecutar el pipeline sobre esa versión y escribe una nueva versión numerada; la versión de la que partiste permanece intacta.

Un modelo lógico, múltiples diseños físicos

El modelo lógico es un único artefacto; el diseño físico es una decisión independiente controlada por un solo widget. El mismo modelo se puede representar como un único catálogo, un catálogo por división o un catálogo por dominio. Si tu realidad de gobernanza cambia, vuelves a realizar el despliegue con una convención diferente; el modelo lógico no cambia.

Las plantillas del sector no son suficientes

El argumento a favor de una plantilla genérica siempre fue la ventaja inicial. La realidad, aprendida por las malas, es que esa ventaja inicial cuesta de nueve a doce meses de adaptación y cambio de nombres. Una plantilla es el modelo promedio de un sector; por definición, no representa el negocio real de nadie. El Modelado de datos Vibe produce un modelo con tu terminología, tus divisiones y tus dominios, generado en cuestión de horas y validado por las mismas reglas que cualquier otro modelo.

Ejemplos de modelos creados con el agente

El mismo agente, independiente del sector, ha producido Modelos de Cobertura Ampliada para todo el negocio en sectores muy diferentes, cada uno de ellos haciendo referencia a los estándares reconocidos de su industria. Los recuentos a continuación corresponden a los modelos de referencia publicados en el repositorio de código abierto.

Disponible hoy mismo

La implementación de referencia es un único notebook de Databricks en agent/dbx_vibe_modelling_agent.ipynb. Completa los cuatro widgets principales y ejecútalo; todo lo demás se predetermina según tu sector.

Un punto de partida concreto: aquí está el prompt que utilizamos para generar un modelo de fabricación y el primer ajuste en inglés sencillo que enviamos para refinarlo.

• Repositorio de referencia (github.com/databricks-industry-solutions/lakehouse-industry-data-models): el notebook del agente, el orquestador, un banco de pruebas, más de 40 modelos de referencia de código abierto y guías que cubren el diseño, la integración, los filtros de calidad y el catálogo de reglas.
• El whitepaper de Modelado de datos Vibe: el tratamiento técnico completo de cada etapa del pipeline, el catálogo de reglas completo, la metodología de revisión de arquitectura y la arquitectura de ensamble.

Si tu equipo lleva meses con un proyecto de capa Silver sin lograr lanzarlo, este es el camino más corto que hemos encontrado para hacerlo realidad. Describe tu negocio en inglés sencillo, obtén un modelo, itera hasta que encaje y ponlo en producción.

(Esta entrada del blog ha sido traducida utilizando herramientas basadas en inteligencia artificial) Publicación original