Databricks Predictive AI Functions Levam a Previsão para o SQL, mas a Confiança é o Verdadeiro Teste

A Databricks lançou cinco Predictive AI Functions em beta, levando previsões e tarefas relacionadas de machine learning diretamente para SQL, dashboards e Genie. A empresa afirma que analistas agora podem responder a perguntas preditivas sem criar ou manter modelos separados. Essa promessa mira um gargalo persistente, mas também transfere responsabilidades dos cientistas de dados para a plataforma e seus usuários.

O lançamento inclui uma versão aprimorada da função ai_forecast e quatro novas funções. Elas abrangem análise de direcionadores, detecção de anomalias, previsão numérica e classificação. Assim, as Databricks Predictive AI Functions vão além das previsões de vendas e atendem a diversas perguntas recorrentes que equipes de negócios levam aos departamentos de dados.

O conflito importante não é entre a Databricks e um único data warehouse concorrente. Trata-se da previsão self-service contra o processo tradicional de desenvolvimento de modelos. Google BigQuery e Snowflake já aproximam o machine learning dos usuários de data warehouses, portanto a previsão baseada em SQL não é novidade. A Databricks aposta que um conjunto menor de funções gerenciadas pode tornar o processo acessível o suficiente para o trabalho analítico cotidiano.

Essa conveniência traz uma obrigação maior. Uma previsão pode ser executada com sucesso e ainda assim levar a uma decisão de negócios ruim. As equipes precisam entender qualidade dos dados, janelas de avaliação, incerteza e mudanças nas condições de mercado, mesmo quando a plataforma gerencia o modelo subjacente.

Databricks Predictive AI Functions Transformam Cinco Tarefas de ML em SQL

O lançamento substitui diversas solicitações de modelagem personalizada por cinco funções gerenciadas que analistas podem invocar onde já analisam dados.

A Databricks anunciou o beta em 14 de outubro de 2026. De acordo com seu anúncio sobre Predictive AI Functions, as funções trabalham em SQL, dashboards de AI/BI e Genie, a interface de análises conversacionais da plataforma.

As cinco funções abordam perguntas analíticas distintas. ai_forecast projeta uma série temporal para o futuro. ai_top_drivers identifica segmentos associados a uma mudança em uma métrica. ai_detect_anomalies encontra observações que ficam fora de uma faixa esperada.

As outras duas funções lidam com tarefas comuns de previsão. ai_predict_value estima um valor contínuo, como demanda ou tempo de entrega. ai_predict_class atribui uma categoria, como um resultado provável ou segmento de cliente.

A Databricks apresenta cada função como uma operação SQL nativa apoiada por modelos de machine learning mantidos centralmente. Analistas podem inserir a saída em consultas e pipelines, em vez de exportar dados para um ambiente de modelagem separado. Eles também podem expor resultados por meio de dashboards ou pedir ao Genie que invoque as funções com perguntas em linguagem natural.

Esse posicionamento importa porque muitas solicitações preditivas começam em relatórios de rotina. Um executivo vê um gráfico de receita e pergunta para onde ele irá em seguida. Um gerente de operações percebe um pico e pergunta se ele é incomum. Um líder de produto vê a conversão cair e pergunta qual segmento impulsionou a mudança.

Essas perguntas frequentemente se tornam tickets para uma equipe de ciência de dados. A equipe precisa definir o alvo, preparar os dados, selecionar um método, validá-lo e criar um processo de entrega. Uma solicitação que leva segundos para ser expressa pode exigir dias de trabalho técnico.

A Databricks quer condensar esse caminho em uma consulta. Seus exemplos usam o conjunto de dados de corridas de táxi da cidade de Nova York para prever o volume de viagens, identificar observações incomuns e responder a perguntas preditivas dentro de superfícies analíticas existentes.

A versão aprimorada de ai_forecast usa um modelo de base para séries temporais pré-treinado e baseado em transformers. Um modelo de base para séries temporais aprende padrões temporais recorrentes em muitos conjuntos de dados antes de receber a série específica de um cliente. A Databricks afirma que esse projeto possibilita previsões sem ajuste de modelo específico para cada tarefa.

A função também aceita informações que podem alterar uma previsão. Configurações de feriados ajudam a representar efeitos recorrentes de calendário. Covariáveis externas, ou seja, variáveis relacionadas conhecidas por influenciar o alvo, podem incluir promoções, preços ou gastos com marketing.

Essa combinação torna o lançamento mais amplo do que um assistente conversacional colocado acima de um dashboard. As funções executam operações analíticas sobre dados governados e retornam saídas estruturadas que outras etapas de SQL podem utilizar.

Ainda assim, o rótulo beta é importante. A Databricks está introduzindo uma camada de previsão gerenciada, não declarando o fim do desenvolvimento de modelos. A questão prática é em quais situações funções padronizadas funcionam bem o suficiente para substituir um projeto personalizado.

A Pressão Imediata Recai sobre Equipes de Analytics e Ciência de Dados

A Databricks está pressionando organizações a decidir quais solicitações preditivas merecem modelos personalizados e quais devem se tornar trabalho rotineiro de analistas.

Os cientistas de dados não estão desaparecendo desse fluxo de trabalho. Seu papel se desloca para avaliação, governança e casos difíceis. Se uma função gerenciada lida com previsões recorrentes, especialistas podem gastar menos tempo reconstruindo pipelines semelhantes para departamentos diferentes.

A mudança também pressiona os engenheiros de analytics. Eles podem se tornar responsáveis por consultas de produção que contêm saídas preditivas ao lado de transformações e lógica de negócios. Isso amplia a definição de um produto de dados confiável.

Verificações tradicionais de SQL determinam se os registros chegaram, se as colunas correspondem aos tipos esperados e se as transformações calculam corretamente. Funções preditivas exigem testes adicionais. As equipes precisam examinar erro de previsão, intervalos de previsão, alertas falsos, drift e desempenho entre segmentos de negócios.

Analistas de negócios enfrentam uma pressão diferente. Eles ganham acesso mais rápido à previsão, mas também precisam de melhor discernimento sobre o significado da saída de um modelo. Um resultado não é confiável apenas porque aparece ao lado de um gráfico familiar.

Considere uma previsão trimestral de vendas. Padrões históricos podem capturar a sazonalidade, mas uma saída planejada de um mercado pode tornar esses padrões irrelevantes. Uma promoção pode aumentar o volume enquanto reduz a margem. Uma previsão também pode não captar uma restrição repentina de oferta que não aparece nos dados de entrada.

Covariáveis externas ajudam apenas quando as equipes as selecionam e mantêm corretamente. Elas devem estar disponíveis tanto para o período histórico quanto para o horizonte de previsão. Uma variável altamente correlacionada com vendas passadas pode não estar disponível ou não ser conhecida no futuro.

A análise de direcionadores cria um desafio relacionado. Uma função pode identificar quais segmentos contribuíram mais para uma mudança em uma métrica. Isso não estabelece automaticamente que esses segmentos causaram a mudança. Contribuição e causalidade respondem a perguntas diferentes.

Classificação e previsão de valores exigem suas próprias salvaguardas. Rótulos de treinamento podem codificar regras de negócios antigas ou tratamento desigual. Previsões para valores ausentes podem parecer precisas enquanto ocultam evidências fracas para um grupo específico.

Portanto, o lançamento muda a fila, não os padrões subjacentes. Solicitações diretas podem migrar para o self-service, enquanto questões ambíguas ou de alto impacto ainda exigem revisão especializada.

Essa divisão deve depender das consequências. Uma previsão aproximada de pessoal usada para planejamento inicial apresenta um risco diferente de uma previsão que altera decisões de crédito, saúde ou emprego. A mesma facilidade de invocação não deve implicar o mesmo processo de aprovação.

As equipes também precisarão de regras de responsabilidade. Alguém deve decidir quais tabelas de origem são adequadas, como as saídas são monitoradas e quando um resultado precisa ser escalado. Sem essa estrutura, a previsão self-service pode multiplicar respostas inconsistentes em vez de eliminar gargalos.

Um modelo operacional útil separa exploração de uso operacional. Analistas podem explorar padrões rapidamente e, em seguida, promover consultas valiosas por meio de revisão e testes. Isso preserva a velocidade sem tratar toda previsão ad hoc como evidência de produção.

O lançamento também eleva as expectativas para plataformas de dados. Se a previsão se tornar parte do SQL cotidiano, administradores precisarão governar acesso, custo, linhagem e reprodutibilidade junto com consultas convencionais.

Para os profissionais do conhecimento que consomem esses resultados, o contexto continua essencial. Uma previsão sem suas premissas, período de origem e histórico de avaliação é difícil de contestar. As equipes podem usar uma base de conhecimento pesquisável para manter essas decisões vinculadas à análise.

Previsão Gerenciada Desafia o Pipeline de Modelos Personalizados

A disputa central é entre respostas imediatas e padronizadas e modelos mais lentos, construídos em torno do problema exato de uma organização.

Um pipeline de previsão personalizado oferece controle. Cientistas de dados podem selecionar algoritmos, criar atributos, definir funções de perda e ajustar o modelo para um objetivo de negócios. Eles também podem criar tratamentos especializados para dados esparsos, lançamentos de produtos, rupturas estruturais ou calendários incomuns.

Essa flexibilidade tem um custo. Cada modelo adicional cria trabalho de desenvolvimento e manutenção. As equipes precisam gerenciar dependências, ambientes de computação, retreinamento programado, monitoramento e interfaces que entregam o resultado.

As Databricks Predictive AI Functions invertem essa troca. A plataforma escolhe e mantém a abordagem de modelagem. Os usuários fornecem dados e parâmetros e recebem um resultado por meio de uma interface analítica familiar.

Para solicitações comuns, a padronização pode ser valiosa. Vários departamentos podem usar a mesma implementação gerenciada em vez de encomendar versões separadas. Uma função chamada por um dashboard e a mesma função chamada pelo Genie devem seguir um caminho analítico compartilhado.

A manutenção centralizada também pode fornecer melhorias de modelo sem obrigar cada cliente a reconstruir seu pipeline. Esse benefício depende de a Databricks preservar um comportamento estável, documentar alterações e oferecer às equipes informações suficientes para avaliar novas versões.

A função de previsão ilustra o mecanismo. Um modelo pré-treinado começa com padrões aprendidos a partir de uma ampla coleção de séries temporais. Ele pode então gerar uma previsão a partir de uma nova série sem o treinamento convencional por conjunto de dados.

Essa técnica é frequentemente chamada de previsão zero-shot. “Zero-shot” significa que o modelo aplica aprendizado prévio à série-alvo sem ser treinado especificamente para aquela tarefa de previsão.

A Databricks afirma que a função aprimorada reconhece sazonalidade e tendências automaticamente. Ela também oferece suporte a efeitos de feriados e covariáveis, que abordam fatores específicos do negócio que um padrão histórico genérico poderia deixar de captar.

A empresa avaliou ai_forecast com fev-bench e relatou uma taxa de vitória por tarefa superior à de um importante data warehouse em nuvem e de sua função anterior. A biblioteca de avaliação fev oferece suporte a tarefas de previsão reproduzíveis, previsões probabilísticas, covariáveis e diversas métricas de erro.

A Databricks define a taxa de vitória reportada por meio da perda quantílica escalonada. A perda quantílica avalia previsões em diferentes níveis de probabilidade e penaliza previsões de acordo com sua distância dos resultados observados. O escalonamento ajuda nas comparações entre séries com unidades diferentes.

No entanto, a publicação de lançamento não fornece detalhes públicos suficientes para generalizar esse resultado para todas as cargas de trabalho. Os leitores precisam do conjunto exato de tarefas, da configuração dos concorrentes, das restrições de entrada, das versões dos modelos e da distribuição completa de erros. Uma taxa de vitória isolada não mostra a dimensão de cada vitória ou derrota.

A distinção importa porque a qualidade das previsões varia conforme o domínio. Um modelo pode ter bom desempenho em muitas tarefas de benchmark e ainda assim ter dificuldades com produtos de curta duração de um varejista ou com a demanda intermitente de um fabricante.

Pipelines personalizados mantêm uma vantagem quando o objetivo de negócio difere de uma métrica estatística genérica. Uma equipe de estoque pode se preocupar mais em evitar rupturas do que em minimizar o erro médio de previsão. Outra equipe pode atribuir um custo maior à superestimação da demanda.

Uma função gerenciada ainda pode servir de base para essas equipes. Ela fornece um resultado imediato com o qual especialistas podem comparar métodos personalizados. Se um modelo sob medida não conseguir superar a base gerenciada o suficiente para justificar sua carga de manutenção, a padronização se torna atraente.

Esta é a interpretação mais forte do lançamento. Databricks não está substituindo toda a modelagem preditiva. Está elevando a capacidade mínima disponível dentro do warehouse e obrigando projetos personalizados a provar seu valor adicional.

BigQuery e Snowflake Mostram que Esta É uma Corrida de Plataformas

Databricks entra em uma disputa mais ampla para fazer o machine learning parecer uma operação nativa de dados, e não um projeto de software separado.

O Google já incorporou treinamento e inferência de modelos ao BigQuery por meio de SQL. Sua plataforma abrange previsão, detecção de anomalias, regressão, classificação, análise de contribuição e outras tarefas de machine learning.

O BigQuery também oferece uma função de previsão gerenciada baseada em TimesFM. A documentação do Google sobre TimesFM integrado descreve previsões univariadas e multivariadas sem exigir que os usuários criem um modelo separado.

A função do BigQuery oferece suporte a identificadores para múltiplas séries temporais, intervalos de previsão, controles de janela de contexto e covariáveis futuras. O Google também mantém caminhos convencionais de criação de modelos para equipes que precisam de mais controle.

O Snowflake oferece funções de previsão e detecção de anomalias dentro de sua plataforma. Seus modelos de anomalia GBM documentados comparam valores observados a uma previsão e usam uma máquina de gradient boosting para identificar valores atípicos.

Essas abordagens concorrentes compartilham uma direção importante. As plataformas de dados em nuvem querem que os clientes analisem, prevejam e ajam sem mover dados governados para uma stack separada.

As diferenças surgirão na qualidade dos modelos, usabilidade, requisitos de carga de trabalho, integração e transparência. As equipes devem testar as mesmas séries de negócio em diferentes plataformas, em vez de inferir superioridade a partir do benchmark de um fornecedor.

Databricks tem uma vantagem de integração para clientes que já usam seus SQL warehouses, dashboards e Genie. A mesma função pode conectar perguntas conversacionais a SQL repetível e resultados visíveis em dashboards.

O Google pode destacar a gama madura de fluxos de criação de modelos do BigQuery ML. Esses fluxos permitem que profissionais de SQL treinem e avaliem diversos tipos de modelo, mantendo mais controle do que uma única função gerenciada oferece.

O Snowflake também integrou funções de machine learning ao seu ambiente de dados. Seu fluxo de detecção de anomalias mostra como plataformas de warehouse podem ocultar grande parte do processo de desenvolvimento de modelos, ao mesmo tempo em que expõem resultados analíticos.

O resultado não é uma simples lista de recursos. Uma função chamada “forecast” pode diferir nos dados aceitos, limites de contexto, tratamento de valores ausentes, saídas de incerteza e suporte a variáveis explicativas.

As superfícies de governança também importam. Um comprador corporativo precisa perguntar se administradores podem restringir o acesso, rastrear cada resultado até seus dados e reproduzir uma previsão após mudanças no serviço.

O acesso por linguagem natural adiciona outra dimensão. Genie pode disponibilizar funções a pessoas que não escrevem SQL. Isso amplia a adoção, mas também pode ocultar detalhes importantes da consulta de quem toma uma decisão.

Uma interface conversacional deve, portanto, expor a consulta gerada, as colunas selecionadas, os filtros, o horizonte temporal e a incerteza. Caso contrário, os usuários podem avaliar uma explicação fluente em vez do procedimento analítico real.

Databricks argumenta que métodos preditivos especializados permitem que Genie responda a perguntas que um modelo de linguagem de propósito geral não consegue tratar com confiabilidade. Essa distinção faz sentido em princípio. Modelos de linguagem geram texto, enquanto previsões exigem métodos numéricos vinculados a observações ordenadas e métricas de avaliação.

A interface ainda pode interpretar mal a solicitação antes de chamar o método correto. Um usuário que pergunta por que a receita mudou pode estar se referindo à contribuição regional, à decomposição preço-volume ou ao impacto causal. Essas análises não são intercambiáveis.

A corrida entre plataformas dependerá, portanto, de mais do que tornar funções chamáveis. Os produtos vencedores devem ajudar os usuários a formular a pergunta certa, inspecionar o cálculo e reconhecer quando o resultado não sustenta uma conclusão.

Limites da Beta Tornam a Validação Parte do Produto

A maior incerteza é se usuários de autoatendimento validarão previsões com o mesmo cuidado que especialistas aplicam a modelos personalizados.

Pelo menos uma função já tem restrições concretas de beta. A documentação da Databricks afirma que ai_detect_anomalies exige um warehouse SQL Pro ou Serverless e inscrição na prévia de Predictive AI Functions.

A função examina o histórico anterior a cada valor, estima uma faixa esperada e atribui uma pontuação de anomalia. Os usuários podem ajustar um limite que controla quando uma linha recebe uma sinalização de anomalia.

Seus atuais limites de detecção de anomalias incluem um máximo de 8.192 linhas de entrada por série temporal. Cada série também precisa ter timestamps únicos, e uma invocação pode analisar apenas uma coluna de valores.

As primeiras oito linhas fornecem contexto histórico e não recebem saídas comuns de anomalia. Equipes que usam séries curtas precisam entender como isso afeta a cobertura.

A função também oferece suavização, que pode unir alertas próximos em um único episódio anômalo. A suavização pode tornar incidentes mais fáceis de interpretar, mas pode marcar valores normais dentro de um curto intervalo.

Esses detalhes mostram por que “nenhum modelo para gerenciar” não significa “nenhuma escolha analítica”. Limites, colunas de agrupamento, covariáveis, feriados e janelas de pontuação afetam o resultado.

Falsos positivos criam custos operacionais. Um sistema de alertas que sinaliza variações rotineiras pode esgotar seus usuários. Falsos negativos criam um risco diferente, porque uma mudança relevante pode passar sem revisão.

Previsões exigem backtesting, que avalia predições em relação a períodos históricos ocultados do modelo. As equipes devem testar vários horizontes, pois a precisão em sete dias não garante precisão em um trimestre.

Elas também devem comparar o modelo gerenciado com bases simples. Valores do período anterior, médias sazonais e métodos estatísticos consolidados frequentemente fornecem pontos de referência úteis. Um modelo sofisticado deve conquistar confiança ao melhorar resultados relevantes.

Os intervalos de previsão merecem atenção. Uma previsão pontual fornece um valor esperado, enquanto um intervalo comunica uma faixa plausível. Decisões baseadas apenas no ponto médio podem criar uma falsa certeza.

A avaliação no nível de segmento é igualmente importante. Uma previsão geral pode parecer precisa porque produtos de alto volume dominam a métrica. O desempenho pode continuar ruim para regiões menores ou produtos lançados recentemente.

O vazamento de dados apresenta outro perigo. O vazamento ocorre quando um modelo recebe informações que não estariam disponíveis no momento da previsão. Uma covariável pode parecer válida nos dados históricos enquanto torna a avaliação futura irrealisticamente fácil.

A análise de fatores exige linguagem disciplinada. Um segmento classificado pode explicar sua contribuição aritmética para uma mudança sem provar por que o comportamento do cliente mudou. As equipes devem reservar alegações causais para desenhos que identifiquem efeitos causais.

Saídas de classificação também podem amplificar problemas históricos. Se os rótulos refletirem decisões humanas inconsistentes, automatizá-los pode reproduzir a inconsistência em maior escala.

Atualizações de modelo introduzem questões de reprodutibilidade. Modelos mantidos centralmente podem melhorar automaticamente, mas a mesma consulta pode acabar produzindo um resultado diferente. Empresas precisam de registros de versão e avisos de mudança para decisões importantes.

O período beta deve revelar se Databricks oferece ferramentas de avaliação suficientes em torno das funções. Adições úteis incluiriam backtests integrados, comparações com bases, resumos de desempenho e alertas para deterioração da precisão.

Até lá, as equipes devem anexar um model card compacto aos usos operacionais. Ele deve indicar o alvo, a janela de dados, o horizonte de previsão, as variáveis de entrada, as limitações conhecidas, o método de validação e o responsável.

Essa documentação não precisa desacelerar a experimentação. Ela se torna necessária quando uma saída entra em planejamento, ações automatizadas ou relatórios executivos.

Um fluxo de trabalho de IA conciso também pode preservar premissas e decisões de acompanhamento. O objetivo é impedir que uma previsão temporária se transforme em um fato organizacional não documentado.

Três Sinais Mostrarão se a Aposta Funciona

O próximo teste não é se analistas conseguem chamar as funções, mas se as organizações passam a confiar repetidamente em suas saídas e a operacionalizá-las.

O primeiro sinal é a evidência proveniente das cargas de trabalho dos clientes. Databricks mostrou exemplos com dados públicos de táxis e relatou comparações de benchmark. Agora, compradores precisam de resultados publicados de varejo, finanças, manufatura, software e outros ambientes operacionais.

A evidência mais forte incluirá horizontes de previsão, modelos de base, calibração de incerteza e mudanças no erro após a implantação. Ela também deve mostrar onde as funções gerenciadas falham.

Evidências amplas de clientes fortaleceriam o argumento de que uma camada de modelos mantida pode atender a diversas questões de negócio. Exemplos restritos ou fortemente selecionados enfraqueceriam essa afirmação.

O segundo sinal é um suporte mais profundo à avaliação e à governança. Observe a presença de backtesting nativo, visibilidade da versão do modelo, linhagem, monitoramento e controles de aprovação em torno de consultas operacionais.

Essas capacidades mostrariam que Databricks trata a previsão como mais do que outra expressão SQL. Também reduziriam a lacuna entre análise rápida e um processo de produção governado.

A ausência de ferramentas de avaliação devolveria mais trabalho aos clientes. Esse resultado preservaria parte do gargalo original, mesmo que o treinamento de modelos se torne mais fácil.

O terceiro sinal é a resposta de BigQuery, Snowflake e outras plataformas analíticas. Fornecedores concorrentes podem responder com novas funções, benchmarks mais fortes, melhor integração conversacional ou controles mais claros.

Uma resposta competitiva rápida confirmaria que SQL preditivo gerenciado se tornou uma categoria central de plataformas de dados. A baixa adoção entre fornecedores sugeriria que ferramentas personalizadas ainda atendem à maioria das necessidades sérias de previsão.

As equipes não precisam esperar que o mercado se estabilize. Elas podem começar com um caso de uso delimitado, em que as decisões sejam reversíveis e os resultados cheguem rapidamente.

Uma previsão semanal de demanda é mais fácil de avaliar do que uma projeção estratégica de vários anos. Um alerta de anomalia revisado por um humano é mais seguro do que um alerta que altera automaticamente o acesso de clientes.

Comece registrando a decisão que a saída apoiará. Depois, defina uma base, período de avaliação, tolerância de erro e regra de escalonamento antes de comparar os resultados.

Execute a função gerenciada em janelas históricas e registre o desempenho por segmento. Inclua intervalos de previsão e examine as maiores falhas, não apenas a pontuação média.

Se a função tiver um bom desempenho, integre-a a um dashboard existente, com suas premissas visíveis. Mantenha uma etapa de revisão especializada até que a equipe entenda como o resultado se comporta diante de mudanças sazonais e eventos incomuns.

As Funções de IA Preditiva da Databricks tornam análises avançadas mais fáceis de solicitar e implementar. Seu valor duradouro dependerá de as equipes tornarem a avaliação igualmente acessível.

O lançamento oferece aos analistas um caminho mais curto dos dados à previsão. Também elimina parte do atrito que antes obrigava as organizações a pausar antes de operacionalizar um modelo. Isso torna a revisão rigorosa mais importante, e não menos.

Qual pergunta recorrente está consumindo hoje o tempo da sua equipe de dados? Escolha uma, teste o resultado gerenciado em comparação com uma referência simples e documente onde ele tem sucesso ou falha. Essa comparação revelará se a Databricks eliminou um gargalo real ou apenas o deslocou para etapas posteriores.