Las funciones Predictive AI de Databricks llevan el pronóstico a SQL, pero la confianza es la verdadera prueba

Databricks lanzó en beta cinco funciones Predictive AI, que trasladan el pronóstico y tareas relacionadas de machine learning directamente a SQL, paneles y Genie. La empresa afirma que ahora los analistas pueden responder preguntas predictivas sin crear ni mantener modelos independientes. Esa promesa apunta a un cuello de botella persistente, pero también desplaza la responsabilidad de los científicos de datos a la plataforma y sus usuarios.

El lanzamiento incluye una función ai_forecast mejorada y cuatro funciones nuevas. Cubren análisis de factores impulsores, detección de anomalías, predicción numérica y clasificación. Por lo tanto, las funciones Predictive AI de Databricks van más allá del pronóstico de ventas y abordan varias preguntas recurrentes que los equipos de negocio plantean a los departamentos de datos.

El conflicto importante no enfrenta a Databricks con un almacén de datos competidor concreto. Se trata de la predicción de autoservicio frente al proceso tradicional de desarrollo de modelos. Google BigQuery y Snowflake ya acercan el machine learning a los usuarios de almacenes de datos, por lo que la predicción basada en SQL no es nueva. Databricks apuesta a que un conjunto más pequeño de funciones gestionadas puede hacer que el proceso sea lo bastante accesible para el trabajo analítico cotidiano.

Esa comodidad implica una obligación mayor. Un pronóstico puede ejecutarse correctamente y aun así conducir a una mala decisión de negocio. Los equipos deben comprender la calidad de los datos, las ventanas de evaluación, la incertidumbre y las condiciones cambiantes del mercado, incluso cuando la plataforma gestione el modelo subyacente.

Las funciones Predictive AI de Databricks convierten cinco tareas de ML en SQL

El lanzamiento sustituye varias solicitudes de modelado personalizado por cinco funciones gestionadas que los analistas pueden invocar donde ya examinan los datos.

Databricks anunció la beta el 14 de octubre de 2026. Según su anuncio de Predictive AI Functions, las funciones operan en SQL, paneles de AI/BI y Genie, la interfaz de analítica conversacional de la plataforma.

Las cinco funciones abordan preguntas analíticas distintas. ai_forecast proyecta una serie temporal hacia el futuro. ai_top_drivers identifica segmentos asociados con un cambio en una métrica. ai_detect_anomalies encuentra observaciones que quedan fuera de un rango esperado.

Las otras dos funciones abordan tareas comunes de predicción. ai_predict_value estima un valor continuo, como la demanda o el tiempo de entrega. ai_predict_class asigna una categoría, como un resultado probable o un segmento de clientes.

Databricks presenta cada función como una operación SQL nativa respaldada por modelos de machine learning mantenidos de forma centralizada. Los analistas pueden incluir el resultado en consultas y pipelines en lugar de exportar datos a un entorno de modelado independiente. También pueden mostrar los resultados mediante paneles o pedir a Genie que invoque las funciones con preguntas en lenguaje natural.

Esta ubicación importa porque muchas solicitudes predictivas comienzan dentro de los informes rutinarios. Un ejecutivo ve un gráfico de ingresos y pregunta hacia dónde se moverá después. Un gerente de operaciones detecta un pico y pregunta si es inusual. Un responsable de producto ve caer la conversión y pregunta qué segmento impulsó el cambio.

Esas preguntas suelen convertirse en tickets para un equipo de ciencia de datos. El equipo debe definir el objetivo, preparar los datos, seleccionar un método, validarlo y crear un proceso de entrega. Una solicitud que tarda segundos en expresarse puede requerir días de trabajo técnico.

Databricks quiere comprimir ese recorrido en una consulta. Sus ejemplos utilizan el conjunto de datos de viajes en taxi de la ciudad de Nueva York para pronosticar el volumen de trayectos, identificar observaciones inusuales y responder preguntas predictivas dentro de las superficies de análisis existentes.

La función ai_forecast mejorada utiliza un modelo fundacional de series temporales preentrenado y basado en transformadores. Un modelo fundacional de series temporales aprende patrones temporales recurrentes en muchos conjuntos de datos antes de recibir la serie específica de un cliente. Databricks afirma que este diseño permite realizar pronósticos sin ajuste de modelos específico para cada tarea.

La función también acepta información que puede modificar un pronóstico. La configuración de días festivos ayuda a representar efectos de calendario recurrentes. Las covariables externas, es decir, variables relacionadas que se sabe que influyen en el objetivo, pueden incluir promociones, precios o gasto en marketing.

Esta combinación hace que el lanzamiento sea más amplio que un asistente conversacional situado sobre un panel. Las funciones ejecutan operaciones analíticas contra datos gobernados y devuelven resultados estructurados que otros pasos de SQL pueden utilizar.

Aun así, la etiqueta beta es importante. Databricks está introduciendo una capa de predicción gestionada, no declarando el fin del desarrollo de modelos. La cuestión práctica es dónde las funciones estandarizadas funcionan lo bastante bien como para sustituir un proyecto personalizado.

La presión inmediata recae sobre los equipos de analítica y ciencia de datos

Databricks presiona a las organizaciones para decidir qué solicitudes predictivas merecen modelos personalizados y cuáles deberían convertirse en trabajo rutinario de analistas.

Los científicos de datos no desaparecen de este flujo de trabajo. Su función se orienta hacia la evaluación, la gobernanza y los casos difíciles. Si una función gestionada resuelve pronósticos recurrentes, los especialistas pueden dedicar menos tiempo a reconstruir pipelines similares para distintos departamentos.

El cambio también ejerce presión sobre los ingenieros de analítica. Podrían pasar a ser responsables de consultas de producción que contengan resultados predictivos junto con transformaciones y lógica de negocio. Eso amplía la definición de un producto de datos fiable.

Las comprobaciones tradicionales de SQL determinan si llegaron los registros, si las columnas coinciden con los tipos esperados y si las transformaciones calculan correctamente. Las funciones predictivas requieren pruebas adicionales. Los equipos deben examinar el error de pronóstico, los intervalos de predicción, las alertas falsas, la deriva y el rendimiento en distintos segmentos de negocio.

Los analistas de negocio enfrentan una presión diferente. Obtienen acceso más rápido a la predicción, pero también necesitan mejor criterio sobre lo que significa el resultado de un modelo. Un resultado no es fiable simplemente porque aparezca junto a un gráfico conocido.

Considere un pronóstico trimestral de ventas. Los patrones históricos pueden captar la estacionalidad, pero una salida planificada de un mercado puede volver irrelevantes esos patrones. Una promoción puede aumentar el volumen mientras reduce el margen. Un pronóstico también puede pasar por alto una restricción repentina de suministro que no aparece en los datos de entrada.

Las covariables externas ayudan solo cuando los equipos las seleccionan y mantienen correctamente. Deben estar disponibles tanto para el período histórico como para el horizonte de pronóstico. Una variable muy correlacionada con las ventas pasadas puede no estar disponible o no poder conocerse en el futuro.

El análisis de factores impulsores plantea un desafío relacionado. Una función puede identificar qué segmentos contribuyeron más a un cambio en una métrica. Eso no establece automáticamente que esos segmentos hayan causado el cambio. La contribución y la causalidad responden preguntas diferentes.

La clasificación y la predicción de valores requieren sus propias salvaguardas. Las etiquetas de entrenamiento pueden codificar reglas de negocio antiguas o un trato desigual. Las predicciones de valores ausentes pueden parecer precisas mientras ocultan evidencia débil para un grupo concreto.

Por lo tanto, el lanzamiento cambia la cola de solicitudes, no los estándares subyacentes. Las solicitudes sencillas pueden avanzar hacia el autoservicio, mientras que las preguntas ambiguas o de alto impacto siguen requiriendo revisión especializada.

Esta división debería depender de las consecuencias. Un pronóstico aproximado de personal utilizado para planificación temprana implica un riesgo distinto al de una predicción que modifica decisiones de crédito, salud o empleo. La misma facilidad de invocación no debería implicar el mismo proceso de aprobación.

Los equipos también necesitarán reglas de responsabilidad. Alguien debe decidir qué tablas fuente son adecuadas, cómo se supervisan los resultados y cuándo un resultado requiere escalamiento. Sin esa estructura, la predicción de autoservicio puede multiplicar respuestas incoherentes en lugar de eliminar cuellos de botella.

Un modelo operativo útil separa la exploración del uso operativo. Los analistas pueden explorar patrones con rapidez y luego promover consultas valiosas mediante revisión y pruebas. Eso preserva la velocidad sin tratar cada predicción ad hoc como evidencia de producción.

El lanzamiento también eleva las expectativas sobre las plataformas de datos. Si la predicción pasa a formar parte del SQL cotidiano, los administradores deben gobernar el acceso, el costo, el linaje y la reproducibilidad junto con las consultas convencionales.

Para los trabajadores del conocimiento que consumen estos resultados, el contexto sigue siendo esencial. Una predicción sin sus supuestos, período fuente e historial de evaluación es difícil de cuestionar. Los equipos pueden utilizar una base de conocimiento con capacidad de búsqueda para mantener esas decisiones vinculadas al análisis.

La predicción gestionada desafía al pipeline de modelos personalizados

La competencia central se da entre respuestas inmediatas y estandarizadas, y modelos más lentos diseñados en torno al problema exacto de una organización.

Un pipeline de pronóstico personalizado ofrece control. Los científicos de datos pueden seleccionar algoritmos, diseñar variables, definir funciones de pérdida y ajustar el modelo a un objetivo de negocio. También pueden crear tratamientos especializados para datos escasos, lanzamientos de productos, rupturas estructurales o calendarios inusuales.

Esa flexibilidad tiene un costo. Cada modelo adicional genera trabajo de desarrollo y mantenimiento. Los equipos deben gestionar dependencias, entornos de cómputo, reentrenamiento programado, supervisión e interfaces que entreguen el resultado.

Las funciones Predictive AI de Databricks invierten ese equilibrio. La plataforma elige y mantiene el enfoque de modelado. Los usuarios proporcionan datos y parámetros, y luego reciben un resultado a través de una interfaz analítica familiar.

Para solicitudes comunes, la estandarización puede ser valiosa. Varios departamentos pueden usar la misma implementación gestionada en lugar de encargar versiones independientes. Una función invocada desde un panel y la misma función invocada mediante Genie deberían seguir una ruta analítica compartida.

El mantenimiento centralizado también puede ofrecer mejoras de modelo sin obligar a cada cliente a reconstruir su pipeline. Ese beneficio depende de que Databricks preserve un comportamiento estable, documente los cambios y proporcione a los equipos suficiente información para evaluar nuevas versiones.

La función de pronóstico ilustra el mecanismo. Un modelo preentrenado comienza con patrones aprendidos de una amplia colección de series temporales. Después puede generar un pronóstico a partir de una nueva serie sin entrenamiento convencional por conjunto de datos.

Esta técnica suele llamarse pronóstico zero-shot. “Zero-shot” significa que el modelo aplica aprendizaje previo a la serie objetivo sin haber sido entrenado específicamente para esa tarea de pronóstico.

Databricks afirma que la función mejorada reconoce automáticamente la estacionalidad y las tendencias. También admite efectos de días festivos y covariables, que abordan factores específicos del negocio que un patrón histórico genérico podría pasar por alto.

La empresa evaluó ai_forecast con fev-bench e informó una mayor tasa de victorias en tareas que un importante almacén de datos en la nube y su función anterior. La biblioteca de evaluación fev admite tareas de pronóstico reproducibles, predicciones probabilísticas, covariables y varias métricas de error.

Databricks define la tasa de victorias reportada mediante pérdida cuantílica escalada. La pérdida cuantílica evalúa los pronósticos en distintos niveles de probabilidad y penaliza las predicciones según su distancia respecto de los resultados observados. El escalado facilita las comparaciones entre series con unidades diferentes.

Sin embargo, la publicación del lanzamiento no proporciona suficientes detalles públicos para generalizar ese resultado a todas las cargas de trabajo. Los lectores necesitan el conjunto exacto de tareas, la configuración de los competidores, las restricciones de entrada, las versiones de los modelos y la distribución completa de errores. Una tasa de victorias por sí sola no muestra la magnitud de cada victoria o derrota.

La distinción importa porque la calidad de las previsiones varía según el ámbito. Un modelo puede rendir bien en muchas tareas de referencia y, aun así, tener dificultades con los productos de vida corta de un minorista o la demanda intermitente de un fabricante.

Los pipelines personalizados conservan una ventaja cuando el objetivo de negocio difiere de una métrica estadística genérica. Un equipo de inventario puede preocuparse más por evitar faltantes de stock que por minimizar el error medio de previsión. Otro equipo puede asignar un coste mayor a sobreestimar la demanda.

Una función gestionada puede seguir respaldando a esos equipos como referencia inicial. Ofrece un resultado inmediato con el que los especialistas pueden comparar métodos personalizados. Si un modelo a medida no puede superar la referencia gestionada lo suficiente como para justificar su carga de mantenimiento, la estandarización se vuelve atractiva.

Esta es la interpretación más sólida del lanzamiento. Databricks no está sustituyendo toda la modelización predictiva. Está elevando la capacidad mínima disponible dentro del almacén de datos y obligando a los proyectos personalizados a demostrar su valor añadido.

BigQuery y Snowflake demuestran que esta es una carrera de plataformas

Databricks se suma a una competencia más amplia por hacer que el aprendizaje automático se sienta como una operación de datos nativa, en lugar de un proyecto de software independiente.

Google ya ha incorporado el entrenamiento y la inferencia de modelos en BigQuery mediante SQL. Su plataforma abarca previsión, detección de anomalías, regresión, clasificación, análisis de contribución y otras tareas de aprendizaje automático.

BigQuery también ofrece una función de previsión gestionada basada en TimesFM. La documentación de TimesFM integrado de Google describe previsiones univariadas y multivariadas sin exigir a los usuarios crear un modelo independiente.

La función de BigQuery admite identificadores para múltiples series temporales, intervalos de predicción, controles de ventana de contexto y covariables futuras. Google también mantiene rutas convencionales de creación de modelos para equipos que necesitan mayor control.

Snowflake proporciona funciones de previsión y detección de anomalías dentro de su plataforma. Sus modelos de anomalías GBM documentados comparan los valores observados con una previsión y utilizan una máquina de potenciación por gradiente para identificar valores atípicos.

Estos enfoques competidores comparten una dirección importante. Las plataformas de datos en la nube quieren que los clientes analicen, predigan y actúen sin trasladar datos gobernados a un stack independiente.

Las diferencias surgirán en la calidad del modelo, la facilidad de uso, los requisitos de carga de trabajo, la integración y la transparencia. Los equipos deberían probar las mismas series de negocio en distintas plataformas, en lugar de inferir superioridad a partir de la referencia de un proveedor.

Databricks tiene una ventaja de integración para los clientes que ya usan sus almacenes SQL, dashboards y Genie. La misma función puede conectar preguntas conversacionales con SQL repetible y resultados visibles en dashboards.

Google puede señalar la gama madura de flujos de creación de modelos de BigQuery ML. Esos flujos permiten a quienes trabajan con SQL entrenar y evaluar varios tipos de modelos, al tiempo que conservan más control del que ofrece una sola función gestionada.

Snowflake también ha integrado funciones de aprendizaje automático en su entorno de datos. Su flujo de detección de anomalías muestra cómo las plataformas de almacén de datos pueden ocultar gran parte del proceso de desarrollo de modelos sin dejar de exponer resultados analíticos.

El resultado no es una simple lista de funcionalidades. Una función llamada “forecast” puede diferir en los datos aceptados, los límites de contexto, el tratamiento de valores ausentes, las salidas de incertidumbre y el soporte para variables explicativas.

Las superficies de gobernanza también importan. Un comprador empresarial debe preguntarse si los administradores pueden restringir el acceso, rastrear cada resultado hasta sus datos y reproducir una predicción después de que el servicio cambie.

El acceso en lenguaje natural añade otra dimensión. Genie puede poner las funciones a disposición de personas que no escriben SQL. Eso amplía la adopción, pero también puede ocultar detalles importantes de la consulta a la persona que toma una decisión.

Por tanto, una interfaz conversacional debería mostrar la consulta generada, las columnas seleccionadas, los filtros, el horizonte temporal y la incertidumbre. De lo contrario, los usuarios podrían evaluar una explicación fluida en lugar del procedimiento analítico real.

Databricks sostiene que los métodos predictivos especializados permiten a Genie responder preguntas que un modelo de lenguaje de propósito general no puede manejar de forma fiable. Esa distinción es sólida en principio. Los modelos de lenguaje generan texto, mientras que la previsión requiere métodos numéricos vinculados a observaciones ordenadas y métricas de evaluación.

La interfaz aún puede malinterpretar la solicitud antes de llamar al método correcto. Un usuario que pregunta por qué cambiaron los ingresos puede referirse a la contribución regional, la descomposición precio-volumen o el impacto causal. No son análisis intercambiables.

Por tanto, la carrera de plataformas dependerá de algo más que hacer que las funciones puedan invocarse. Los productos ganadores deberán ayudar a los usuarios a plantear la pregunta correcta, inspeccionar el cálculo y reconocer cuándo el resultado no respalda una conclusión.

Los límites de la beta hacen de la validación parte del producto

La mayor incertidumbre es si los usuarios de autoservicio validarán las predicciones con el mismo rigor que los especialistas aplican a los modelos personalizados.

Al menos una función ya tiene restricciones concretas de beta. La documentación de Databricks indica que ai_detect_anomalies requiere un almacén SQL Pro o Serverless y la inscripción en la vista previa de Predictive AI Functions.

La función examina el historial anterior a cada valor, estima un rango esperado y asigna una puntuación de anomalía. Los usuarios pueden ajustar un umbral que controla cuándo una fila recibe una marca de anomalía.

Sus actuales límites de detección de anomalías incluyen un máximo de 8.192 filas de entrada por serie temporal. Cada serie también necesita marcas de tiempo únicas, y una invocación solo puede analizar una columna de valores.

Las primeras ocho filas proporcionan contexto histórico y no reciben salidas ordinarias de anomalías. Los equipos que utilizan series cortas deben comprender cómo afecta esto a la cobertura.

La función también ofrece suavizado, que puede unir alertas cercanas en un único episodio anómalo. El suavizado puede facilitar la lectura de incidentes, pero puede marcar valores normales dentro de una brecha corta.

Estos detalles muestran por qué “ningún modelo que gestionar” no significa “ninguna decisión analítica”. Los umbrales, las columnas de agrupación, las covariables, los días festivos y las ventanas de puntuación afectan al resultado.

Los falsos positivos generan costes operativos. Un sistema de alertas que marque variaciones rutinarias puede agotar a sus usuarios. Los falsos negativos crean un riesgo distinto, porque un cambio relevante puede pasar sin revisión.

Las previsiones requieren pruebas retrospectivas, que evalúan las predicciones frente a periodos históricos ocultos al modelo. Los equipos deberían probar varios horizontes porque la precisión a siete días no garantiza precisión a un trimestre.

También deberían comparar el modelo gestionado con referencias simples. Los valores del periodo anterior, los promedios estacionales y los métodos estadísticos establecidos suelen ofrecer puntos de referencia útiles. Un modelo sofisticado debería ganarse la confianza al mejorar resultados relevantes.

Los intervalos de predicción merecen atención. Una previsión puntual ofrece un valor esperado, mientras que un intervalo comunica un rango plausible. Las decisiones basadas solo en el punto medio pueden crear una falsa certeza.

La evaluación a nivel de segmento es igual de importante. Una previsión global puede parecer precisa porque los productos de alto volumen dominan la métrica. El rendimiento puede seguir siendo deficiente para regiones más pequeñas o productos recién lanzados.

La fuga de datos plantea otro peligro. La fuga ocurre cuando un modelo recibe información que no habría estado disponible en el momento de la predicción. Una covariable puede parecer válida en los datos históricos y, al mismo tiempo, facilitar de forma irreal la evaluación futura.

El análisis de impulsores requiere un lenguaje disciplinado. Un segmento clasificado puede explicar la contribución aritmética a un cambio sin demostrar por qué cambió el comportamiento de los clientes. Los equipos deberían reservar las afirmaciones causales para diseños que identifiquen efectos causales.

Las salidas de clasificación también pueden amplificar problemas históricos. Si las etiquetas reflejan decisiones humanas inconsistentes, automatizarlas puede reproducir esa inconsistencia a mayor escala.

Las actualizaciones de modelos introducen cuestiones de reproducibilidad. Los modelos mantenidos de forma centralizada pueden mejorar automáticamente, pero la misma consulta puede acabar produciendo un resultado distinto. Las empresas necesitan registros de versiones y avisos de cambios para decisiones importantes.

El periodo beta debería revelar si Databricks proporciona suficientes herramientas de evaluación en torno a las funciones. Entre las adiciones útiles estarían las pruebas retrospectivas integradas, las comparaciones con referencias, los resúmenes de rendimiento y las alertas sobre deterioro de la precisión.

Hasta entonces, los equipos deberían adjuntar una ficha de modelo compacta a los usos operativos. Debería indicar el objetivo, la ventana de datos, el horizonte de previsión, las variables de entrada, las limitaciones conocidas, el método de validación y el responsable asignado.

Esa documentación no tiene por qué ralentizar la experimentación. Se vuelve necesaria cuando una salida entra en la planificación, las acciones automatizadas o los informes ejecutivos.

Un flujo de trabajo de IA conciso también puede preservar los supuestos y las decisiones posteriores. El objetivo es evitar que una predicción temporal se convierta en un hecho organizacional sin documentar.

Tres señales mostrarán si la apuesta funciona

La próxima prueba no es si los analistas pueden invocar las funciones, sino si las organizaciones confían repetidamente en sus resultados y los ponen en funcionamiento.

La primera señal son las pruebas procedentes de cargas de trabajo de clientes. Databricks ha mostrado ejemplos con datos públicos de taxis y ha comunicado comparaciones de referencia. Ahora los compradores necesitan resultados publicados de entornos operativos de comercio minorista, finanzas, fabricación, software y otros sectores.

La evidencia más sólida incluirá horizontes de previsión, modelos de referencia, calibración de incertidumbre y cambios en el error tras el despliegue. También debería mostrar dónde fallan las funciones gestionadas.

Una amplia evidencia de clientes reforzaría el argumento de que una capa de modelos mantenida puede atender diversas preguntas de negocio. Los ejemplos limitados o muy seleccionados debilitarían esa afirmación.

La segunda señal es un soporte más profundo para evaluación y gobernanza. Habrá que observar si aparecen pruebas retrospectivas nativas, visibilidad de versiones de modelos, linaje, monitorización y controles de aprobación en torno a las consultas operativas.

Estas capacidades demostrarían que Databricks trata la predicción como algo más que otra expresión SQL. También reducirían la brecha entre el análisis rápido y un proceso de producción gobernado.

La falta de herramientas de evaluación devolvería más trabajo a los clientes. Ese resultado preservaría parte del cuello de botella original, incluso si el entrenamiento de modelos se vuelve más sencillo.

La tercera señal es la respuesta de BigQuery, Snowflake y otras plataformas analíticas. Los proveedores competidores pueden responder con nuevas funciones, referencias más sólidas, mejor integración conversacional o controles más claros.

Una respuesta competitiva rápida confirmaría que el SQL predictivo gestionado se ha convertido en una categoría central de plataformas de datos. Una adopción débil entre proveedores sugeriría que las herramientas personalizadas aún atienden la mayoría de las necesidades serias de previsión.

Los equipos no necesitan esperar a que el mercado se estabilice. Pueden empezar con un caso de uso acotado en el que las decisiones sean reversibles y los resultados lleguen rápidamente.

Una previsión semanal de demanda es más fácil de evaluar que una proyección estratégica a varios años. Una alerta de anomalía revisada por una persona es más segura que una alerta que cambia automáticamente el acceso de los clientes.

Empiece por dejar por escrito la decisión que respaldará la salida. Luego defina una referencia, un periodo de evaluación, una tolerancia al error y una regla de escalamiento antes de comparar resultados.

Ejecute la función gestionada con ventanas históricas y registre el rendimiento por segmento. Incluya intervalos de predicción y examine los mayores fallos, no solo la puntuación media.

Si la función funciona bien, colócala dentro de un dashboard existente con sus supuestos visibles. Mantén un paso de revisión por especialistas hasta que el equipo comprenda cómo se comporta el resultado ante cambios estacionales y eventos inusuales.

Databricks Predictive AI Functions facilitan la solicitud y el despliegue de análisis avanzados. Su valor duradero dependerá de si los equipos hacen que la evaluación sea igual de accesible.

El lanzamiento ofrece a los analistas un camino más corto desde los datos hasta el pronóstico. También elimina parte de la fricción que antes obligaba a las organizaciones a detenerse antes de operacionalizar un modelo. Eso hace que una revisión rigurosa sea más importante, no menos.

¿Qué pregunta recurrente consume hoy el tiempo de tu equipo de datos? Elige una, prueba el resultado gestionado frente a una línea base sencilla y documenta dónde tiene éxito o falla. Esa comparación revelará si Databricks ha eliminado un cuello de botella real o simplemente lo ha trasladado a una etapa posterior.