Nem todo problema de IA enterprise precisa de agente. TimesFM 3.0 traz a previsão para dentro do BigQuery

O lançamento de IA mais útil da semana para um planejador de demanda não tem agente, nem prompt, nem janela de chat. É uma função SQL.

Em 7 de outubro, o Google Cloud adicionou o TimesFM 3.0 à função AI.FORECAST do BigQuery, em preview. O TimesFM é um modelo de fundação de previsão do Google Research, lançado como open source, e o BigQuery agora o roda como um modelo nativo. A nova versão adiciona previsão multivariada: previsões para muitas séries temporais de uma vez, usando o histórico delas mais variáveis adicionais, chamadas covariáveis, que ajudam a explicá-las.

No papel, é um lançamento modesto. Também é uma correção útil para um hábito que vem se formando na IA enterprise, em que todo problema analítico é tido como algo que precisa de um agente.

O que a função faz

Uma previsão no BigQuery agora se parece com uma query. Os tutoriais do Google usam uma única tabela de entrada em que as linhas históricas trazem as datas, os valores a prever e as covariáveis do passado, enquanto as linhas futuras trazem as datas e as covariáveis já conhecidas para o futuro, como um calendário de promoções ou uma previsão do tempo. Os exemplos do Google preveem vendas tendo promoções e clima como entradas.

Duas funções relacionadas vêm junto: AI.EVALUATE, que mede a acurácia da previsão, e AI.DETECT_ANOMALIES, que sinaliza pontos incomuns. Ambas estão documentadas para série temporal única, um detalhe que importa mais adiante.

A versão com agente do mesmo problema

Imagine a alternativa que muitos times estão construindo agora. Um agente recebe uma pergunta sobre a demanda do próximo trimestre, consulta o data warehouse, puxa os dados para um notebook ou um sandbox, escreve Python para ajustar um modelo, roda tudo e reporta um número.

Cada passo dessa cadeia é um lugar para falhar. O dado sai da plataforma onde vivem as suas permissões e a sua trilha de auditoria. O código é gerado do zero a cada vez, então duas execuções da mesma pergunta podem usar dois métodos diferentes. O custo inclui o raciocínio de um modelo de fronteira para o que, no fundo, é uma tarefa estatística bem conhecida. E, como observamos quando os agentes começaram a colocar nova carga no caminho do dado, mover o dado até o modelo costuma ser mais lento do que parece.

A versão dentro do banco de dados tem menos partes. O dado fica onde é governado. O método é o mesmo em toda execução. O modelo não precisa do seu próprio pipeline de treinamento. Não é uma diferença pequena para uma previsão que alimenta estoque, escala de pessoal ou planejamento de caixa.

Onde os agentes ainda têm lugar

Nada disso torna os agentes inúteis para previsão. Eles são bons nas partes ao redor do número: perguntar quais covariáveis importam, explicar uma previsão para um planejador, montar um relatório. O formato certo é um agente que chama a função de previsão como ferramenta, não um que a reinventa. É a mesma lógica de portfólio que defendemos no nosso framework para um portfólio de modelos enterprise, em que os modelos preditivos que uma empresa já tem mantêm o seu papel ao lado dos generativos.

O que checar antes de confiar nele

É um preview. Capacidade, regiões e comportamento podem mudar antes da disponibilidade geral (GA).

A avaliação tem de vir de você. As funções nativas de avaliação e de anomalia estão documentadas para série única. Para previsões multivariadas, faça backtest contra um histórico separado e compare com os modelos em que o time de planejamento já confia. Muitos já rodam previsões estatísticas no mesmo data warehouse.

Covariáveis são dados de negócio. Uma previsão que usa o calendário de promoções é tão boa quanto esse calendário. O dono de cada covariável passa a fazer parte do processo de previsão, quer alguém registre isso ou não.

Antes de desenhar um agente para um problema de previsão, faça uma pergunta mais simples primeiro: a resposta é uma chamada de função? Cada vez mais, é.