El uso de habilidades reutilizables, patrones de medallón y definiciones compartidas permite entregar pipelines consistentes y listos para producción más rápido.
por Trent Lezer y James VanGordon
Daikin Applied Americas (DAA) fabrica y ofrece servicios para sistemas de HVAC comerciales en toda Norteamérica. Eso significa gestionar grandes volúmenes de datos operativos, de fabricación y de servicio en todos los sistemas, desde la telemetría de los equipos y los datos de la cadena de suministro hasta los registros de servicio de campo.
El equipo de datos brinda soporte a casos de uso de analítica y AI en ingeniería, operaciones y servicio al cliente, todos los cuales dependen de pipelines confiables y bien estructurados.
A medida que crecieron esas demandas, también lo hizo la presión sobre el equipo de datos, lo que incluyó más pipelines, más casos de uso y más coordinación entre los equipos. Para abordar esto, el equipo definió un modelo operativo más estructurado para el diseño, la construcción y el gobierno de los pipelines, y utilizó Databricks Genie Code para acelerar la ejecución dentro de ese modelo.
El equipo aprovechó Genie Code como un enfoque asistido por AI para la ingeniería de datos. Trabajar directamente con datos gobernados en Unity Catalog puede ayudar a planificar y generar pipelines de varios pasos en todo el flujo de trabajo. Esto permite a los ingenieros pasar de una idea a un pipeline en funcionamiento mucho más rápido, sin cambiar de herramienta ni unir componentes manualmente.
Esa velocidad cambió fundamentalmente la forma de trabajar del equipo. Los pipelines que antes tardaban días en prototiparse ahora podían generarse en minutos. Los ciclos de iteración se acortaron y los ingenieros dedicaron menos tiempo a escribir código repetitivo y más tiempo a perfeccionar la lógica y los resultados.
Al mismo tiempo, operar en un entorno de datos grande y compartido requiere consistencia. Los pipelines deben seguir patrones de arquitectura comunes, utilizar definiciones compartidas y comportarse de manera predecible entre los equipos.
Los modelos de lenguaje grande introducen un desafío estructural en este contexto. Cuando los equipos dependen de prompts variados o instrucciones vagamente definidas, la misma solicitud puede producir resultados inconsistentes y provocar una desviación arquitectónica con el tiempo.
Para abordar esto, el equipo de DAA se enfocó en definir cómo debe operar la AI dentro de un entorno empresarial gobernado, en lugar de depender únicamente de la ingeniería de prompts.
Como dice Trent Lezer, Sr. Director de Data & Analytics en Daikin Applied Americas: “Genie Code funciona mejor cuando se le trata como a un ingeniero junior que trabaja rápido pero debe respetar las mismas restricciones arquitectónicas que todos los demás, sin excepciones especiales ‘porque es AI’”.
El uso inicial de Genie Code siguió un patrón familiar: prompts largos que intentaban codificar reglas de arquitectura, estándares de nomenclatura, lógica de transformación y requisitos de documentación en un solo bloque de texto.
Este enfoque no era escalable. Las instrucciones variaban entre los equipos, los prompts se volvieron difíciles de mantener y las tareas similares producían resultados inconsistentes.
Para abordar esto, el equipo introdujo un marco de habilidades MECE (Mutually Exclusive, Collectively Exhaustive). Como explica Trent: “Implementamos un marco de habilidades MECE; cada habilidad define una competencia coherente, las habilidades no se superponen y el conjunto completo cubre todo el ciclo de vida del trabajo de ingeniería de datos”.
Cada habilidad define una capacidad específica en el ciclo de vida de la ingeniería de datos. Juntas, las habilidades no se superponen y cubren todo el flujo de trabajo. Estas habilidades incluyen el diseño de arquitectura de medallón, la preparación de fuentes y definición de grano, patrones de transformación, alineación canónica y estándares de gobierno.
En lugar de incrustar reglas dentro de los prompts, el equipo estructuró el entorno para que Genie Code cargue las habilidades adecuadas en tiempo de ejecución y las aplique durante la planificación y la ejecución. Esto cambia el comportamiento de interpretar instrucciones ad hoc a operar dentro de un modelo de ejecución definido.
Desde una perspectiva de gobierno, esto también cambia la forma en que se aplican los estándares. Como señala James VanGordon, Solutions Architect en Databricks: “El patrón que sigo viendo con Genie Code es bastante simple: los prompts te ayudan a comenzar, pero son un mal lugar para aplicar los estándares del equipo. Si la misma regla importa más de una vez, debería residir en el espacio de trabajo como una habilidad, donde Genie Code realmente pueda usarla”.
Él también enfatiza la incorporación de estándares directamente en el entorno de ejecución: “Eso es lo que hace que esto sea real en lugar de una ilusión. Las habilidades, el contexto de Unity Catalog y Genie Code funcionan en el mismo lugar. La guía se encuentra donde se crea el trabajo, no a un lado en un proceso de revisión que alguien tiene que recordar más tarde”.
El equipo también fortaleció el rol de la arquitectura de medallón como un marco tanto de gobierno como de razonamiento. Las capas Bronze, Silver y Gold ya existían, pero el cambio consistió en convertirlas en límites de decisión explícitos durante la generación de pipelines, no solo en niveles de almacenamiento.
Bronze representa la verdad de la fuente de origen. Silver representa datos limpios y conformados. Gold representa analítica lista para el negocio.
Para operacionalizar esta estructura, el equipo introdujo puntos de control entre las capas. Antes de que los datos avancen, se deben cumplir requisitos como la definición del grano de origen, la validación de uniones y las comprobaciones de estabilidad de los datos.
Estos puntos de control se aplican dentro del propio flujo de trabajo de desarrollo, no como pasos de revisión posteriores. Genie Code opera dentro de estas restricciones a medida que se generan y modifican los pipelines.
Esto garantiza la consistencia entre los equipos al tiempo que reduce el riesgo de atajos arquitectónicos durante el desarrollo rápido.
Un desafío recurrente en la ingeniería de datos empresarial es alinear los modelos técnicos con el lenguaje de negocio.
En DAA, las partes interesadas piensan en términos de equipos, clientes, eventos de servicio y contratos, no en tablas, uniones o transformaciones.
Para abordar esto, el equipo ancló el diseño de los pipelines en entidades de negocio estables. En lugar de comenzar con estructuras técnicas, los ingenieros empiezan por identificar qué representan los datos y cómo se comportan a lo largo del tiempo.
Este cambio mejora los esfuerzos posteriores y reduce la ambigüedad cuando los conjuntos de datos se reutilizan en diferentes dominios.
Con el tiempo, los modelos de la capa Silver y los conjuntos de datos Gold se vuelven más consistentes porque se basan en conceptos de negocio compartidos en lugar de decisiones técnicas aisladas.
Con este modelo operativo implementado y la AI integrada, el equipo vio un cambio claro en cómo se ejecutaba el trabajo.
El desarrollo de pipelines se aceleró, particularmente durante la exploración e iteración iniciales. Los ingenieros dedicaron menos tiempo a escribir código repetitivo y más tiempo a perfeccionar la lógica de negocio.
Los resultados también se volvieron más consistentes entre los equipos. Casos de uso similares siguieron patrones estructurales similares, lo que mejoró la mantenibilidad y la reutilización.
Es importante destacar que aumentó la confianza en los resultados generados. Los ingenieros dedicaron menos tiempo a validar la corrección estructural y pudieron iterar más rápidamente.
Para hacer que estas mejoras sean repetibles, el equipo estandarizó decisiones clave dentro del proceso de desarrollo.
En lugar de depender del conocimiento implícito, las definiciones se hicieron explícitas, incluyendo qué califica como datos Bronze, Silver y Gold, cómo se define el grano de origen, qué patrones de transformación son reutilizables y cómo se representan las entidades de negocio. Esta estructura fue fundamental para la escala. Garantiza que la AI opere dentro de un marco consistente entre los equipos, incluso a medida que evolucionan los casos de uso.
El resultado de este modelo operativo no fue solo pipelines más rápidos. Fue la capacidad de escalar la ingeniería de datos en un entorno empresarial gobernado.
Los ingenieros dedican menos tiempo a corregir pipelines estructuralmente incorrectos y más tiempo a perfeccionar la lógica y los resultados de negocio.
La aplicación consistente de habilidades y puntos de control de gobierno evita la divergencia entre los equipos que trabajan en desafíos de datos similares.
Basar los pipelines en conceptos de negocio mejora la claridad y reduce el retrabajo posterior.
Las medidas de protección se integran directamente en el sistema, lo que reduce la dependencia de la aplicación manual.
Debido a que las habilidades y los puntos de control definidos limitan los resultados, la AI opera de manera confiable dentro de los flujos de trabajo de producción.
Como resume Trent: “El objetivo no es hacer que la AI siga más reglas. Es hacer que las reglas correctas sean imposibles de ignorar”.
En Daikin Applied Americas, la combinación de un modelo operativo estructurado con el desarrollo asistido por AI permitió al equipo de datos escalar más rápido mientras mantenía la consistencia, la claridad y el control.
Al definir cómo deben construirse los pipelines e incorporar esas reglas directamente en el entorno de desarrollo, el equipo creó un sistema en el que la velocidad y el gobierno se refuerzan mutuamente en lugar de competir.
Obtenga más información sobre Genie Code.
(Esta entrada del blog ha sido traducida utilizando herramientas basadas en inteligencia artificial) Publicación original
Suscríbete a nuestro blog y recibe las últimas publicaciones directamente en tu bandeja de entrada.