Previsão de séries temporais em uma chamada SQL: o ai_forecast() do Databricks

Existe um pedido que todo time de dados já ouviu: "me dá uma previsão de vendas para o próximo trimestre". Ele soa trivial, mas costuma virar um miniprojeto — notebook, escolha de biblioteca, comparação de modelos, backtest, registro no MLflow, agendamento do job. Duas ou três semanas depois, você entrega um número que o negócio precisava para ontem.

O ai_forecast() do Databricks foi feito para encurtar exatamente esse caminho. É uma função SQL que retorna tabela (table-valued function): você aponta para a sua série temporal, define o horizonte da previsão e recebe de volta os valores projetados já com intervalos de confiança — sem treinar modelo, sem infraestrutura de ML.

Este artigo mostra como usar, o que a função devolve, e — igualmente importante — quando não usá-la.

O problema que ele resolve

A maioria das previsões dentro de uma empresa não é um problema de pesquisa; é um problema operacional. Alguém precisa de um número razoável, rápido, para planejar estoque, dimensionar equipe ou fechar um orçamento. Nesses casos, montar um pipeline de machine learning completo é desproporcional ao valor da pergunta.

Ao mesmo tempo, a alternativa "rápida" tradicional — exportar para uma planilha e traçar uma linha de tendência — quebra a governança: os dados saem do ambiente controlado, ninguém audita o cálculo e cada área usa um método diferente.

O ai_forecast() fica no meio-termo: rápido como uma consulta SQL, mas rodando dentro do Unity Catalog, com linhagem e permissões preservadas.

A sintaxe

A forma mínima precisa de quatro coisas: a tabela observada, o horizonte, a coluna de tempo e a coluna de valor.

-- previsão até o fim do ano
SELECT * FROM ai_forecast(
  observed  => TABLE(daily_sales),
  horizon   => '2026-12-31',
  time_col  => 'ds',
  value_col => 'sales'
);

Os parâmetros principais:

• observed — a entrada de treino, passada como TABLE(...). Pode ser uma tabela, uma view ou uma subconsulta.
• horizon — o fim (exclusivo) da previsão, como DATE, TIMESTAMP ou string. A função projeta da última observação até esse ponto.
• time_col — a coluna de tempo (DATE ou TIMESTAMP).
• value_col — a coluna a prever (precisa ser convertível para DOUBLE). Aceita também um array de colunas para prever várias séries de uma vez.

E os opcionais que mais rendem no dia a dia:

• group_col — uma ou mais colunas de agrupamento. Com ela, você gera uma previsão independente por grupo (loja, SKU, região) numa única chamada, sem loop em Python.
• prediction_interval_width — largura do intervalo de confiança (padrão 0.95).
• frequency — granularidade da série (padrão auto).
• seed — semente para resultados reproduzíveis.

Previsão por grupo

O group_col é o que transforma a função de "brinquedo" em ferramenta de produção. Imagine prever vendas para 500 lojas:

SELECT * FROM ai_forecast(
  observed  => TABLE(SELECT ds, sales, store_id FROM daily_sales),
  horizon   => '2026-12-31',
  time_col  => 'ds',
  value_col => 'sales',
  group_col => 'store_id'
);

Cada store_id recebe seu próprio modelo e sua própria previsão, particionados automaticamente. O resultado sai empilhado, pronto para materializar em uma tabela Delta ou alimentar um dashboard.

O que a função devolve

A saída é uma tabela com a coluna de tempo, o valor previsto e as bordas do intervalo — algo como:

 ds           sales_forecast   sales_upper   sales_lower
 2026-10-01   1.240,5          1.410,2       1.070,8
 2026-10-02   1.255,9          1.428,7       1.083,1

Como é SQL, você encadeia direto: materializa com CREATE TABLE ... AS SELECT, junta com os valores reais para monitorar o erro, ou expõe numa view para o BI. Nada sai do lakehouse.

Por que isso importa

Três ganhos concretos:

1. Zero pipeline de ML. A seleção do modelo é automática. Você não escolhe entre ARIMA, Prophet ou gradient boosting — o serviço decide e ajusta. Isso derruba a barreira de entrada para quem é forte em SQL mas não vive de modelagem.

2. Escala por grupo sem código extra. Uma chamada cobre centenas ou milhares de séries. O que antes era um for sobre grupos com paralelização manual vira uma linha de group_col.

3. Governança preservada. Por rodar como função nativa sobre dados do Unity Catalog, valem as mesmas permissões, a mesma linhagem e a mesma auditoria do resto do seu ambiente. A previsão deixa de ser um script solto na máquina de alguém.

Quando NÃO usar

Ser honesto sobre os limites é parte do valor:

• Quando o problema exige features externas. Se a previsão depende fortemente de preço, promoções, clima ou eventos, um modelo dedicado que ingere essas variáveis vai superar uma função automática que só olha o histórico da própria série.
• Quando você precisa de explicabilidade fina. Para um número que vai sustentar uma decisão regulatória ou financeira sensível, você provavelmente quer controlar e documentar o método.
• Séries muito curtas ou muito ruidosas. Sem histórico suficiente, qualquer método — automático ou não — vai chutar. A função não faz mágica com dados ausentes.

Para o resto — a enorme maioria dos pedidos de "preciso de um número para planejar" — ai_forecast() entrega em minutos o que antes custava uma sprint.

Como começar

1. Garanta uma tabela com uma coluna de tempo (DATE/TIMESTAMP) e uma de valor numérica, no Unity Catalog.
2. Rode a versão mínima da consulta com um horizonte curto para validar o formato da saída.
3. Adicione group_col e ajuste prediction_interval_width conforme a necessidade.
4. Materialize o resultado numa tabela Delta e agende um refresh — ou deixe como view para consultas sob demanda.

É o tipo de recurso que muda o custo de responder a uma pergunta: de "abre um projeto" para "escreve uma query".