Le Predictive AI Functions di Databricks portano le previsioni in SQL, ma la vera prova è la fiducia

Databricks ha rilasciato in beta cinque Predictive AI Functions, portando la previsione e attività di machine learning correlate direttamente in SQL, dashboard e Genie. L’azienda afferma che gli analisti possono ora rispondere a domande predittive senza creare o mantenere modelli separati. Questa promessa punta a un collo di bottiglia persistente, ma sposta anche la responsabilità dai data scientist alla piattaforma e ai suoi utenti.

Il rilascio include una funzione ai_forecast aggiornata e quattro nuove funzioni. Coprono analisi dei fattori trainanti, rilevamento delle anomalie, predizione numerica e classificazione. Le Databricks Predictive AI Functions vanno quindi oltre le previsioni di vendita, affrontando diverse domande ricorrenti che i team aziendali pongono ai dipartimenti dati.

Il conflitto importante non è tra Databricks e un singolo data warehouse concorrente. È tra la predizione self-service e il tradizionale processo di sviluppo dei modelli. Google BigQuery e Snowflake avvicinano già il machine learning agli utenti dei data warehouse, quindi la predizione basata su SQL non è una novità. Databricks scommette che un insieme più ristretto di funzioni gestite possa rendere il processo sufficientemente accessibile per il lavoro analitico ordinario.

Questa comodità comporta un obbligo maggiore. Una previsione può essere eseguita correttamente e portare comunque a una cattiva decisione aziendale. I team devono comprendere qualità dei dati, finestre di valutazione, incertezza e condizioni di mercato in evoluzione, anche quando la piattaforma gestisce il modello sottostante.

Le Databricks Predictive AI Functions trasformano cinque attività ML in SQL

Il rilascio sostituisce diverse richieste di modellazione personalizzata con cinque funzioni gestite che gli analisti possono richiamare negli stessi contesti in cui già esaminano i dati.

Databricks ha annunciato la beta il 14 ottobre 2026. Secondo il suo annuncio sulle Predictive AI Functions, le funzioni operano in SQL, nelle dashboard AI/BI e in Genie, l’interfaccia di analytics conversazionale della piattaforma.

Le cinque funzioni affrontano domande analitiche distinte. ai_forecast proietta una serie temporale nel futuro. ai_top_drivers identifica segmenti associati a un cambiamento in una metrica. ai_detect_anomalies individua osservazioni che ricadono fuori da un intervallo previsto.

Le altre due funzioni gestiscono attività predittive comuni. ai_predict_value stima un valore continuo, come la domanda o il tempo di consegna. ai_predict_class assegna una categoria, come un probabile risultato o un segmento di clienti.

Databricks presenta ogni funzione come un’operazione SQL nativa supportata da modelli di machine learning gestiti centralmente. Gli analisti possono inserire l’output in query e pipeline, invece di esportare i dati in un ambiente di modellazione separato. Possono inoltre esporre i risultati tramite dashboard o chiedere a Genie di richiamare le funzioni attraverso domande in linguaggio naturale.

Questa collocazione è importante perché molte richieste predittive nascono nel reporting di routine. Un dirigente vede un grafico dei ricavi e chiede dove andrà in seguito. Un responsabile operativo nota un picco e domanda se sia insolito. Un product lead vede calare la conversione e chiede quale segmento abbia determinato il cambiamento.

Spesso queste domande diventano ticket per un team di data science. Il team deve definire l’obiettivo, preparare i dati, selezionare un metodo, convalidarlo e creare un processo di distribuzione. Una richiesta che richiede pochi secondi per essere formulata può richiedere giorni di lavoro tecnico.

Databricks vuole comprimere questo percorso in una query. I suoi esempi usano il dataset dei viaggi in taxi di New York City per prevedere il volume delle corse, identificare osservazioni insolite e rispondere a domande predittive nelle superfici analitiche esistenti.

La versione aggiornata di ai_forecast utilizza un modello fondazionale preaddestrato per serie temporali basato su transformer. Un modello fondazionale per serie temporali apprende schemi temporali ricorrenti su molti dataset prima di ricevere la serie specifica di un cliente. Databricks afferma che questo approccio consente previsioni senza il tuning di modelli specifici per attività.

La funzione accetta anche informazioni che possono modificare una previsione. Le impostazioni relative alle festività aiutano a rappresentare effetti ricorrenti del calendario. Le covariate esterne, ovvero variabili correlate note per influenzare il valore obiettivo, possono includere promozioni, prezzi o spesa di marketing.

Questa combinazione rende il rilascio più ampio di un assistente conversazionale collocato sopra una dashboard. Le funzioni eseguono operazioni analitiche su dati governati e restituiscono output strutturati che altri passaggi SQL possono utilizzare.

Tuttavia, l’etichetta beta è importante. Databricks sta introducendo un livello di predizione gestita, non dichiarando la fine dello sviluppo dei modelli. La domanda pratica è in quali casi le funzioni standardizzate funzionino abbastanza bene da sostituire un progetto personalizzato.

La pressione immediata ricade sui team di analytics e data science

Databricks spinge le organizzazioni a decidere quali richieste predittive meritino modelli personalizzati e quali debbano diventare lavoro ordinario degli analisti.

I data scientist non stanno scomparendo da questo flusso di lavoro. Il loro ruolo si sposta verso valutazione, governance e casi difficili. Se una funzione gestita affronta previsioni ricorrenti, gli specialisti possono dedicare meno tempo a ricostruire pipeline simili per reparti diversi.

Il cambiamento mette sotto pressione anche gli analytics engineer. Potrebbero diventare responsabili di query in produzione che contengono output predittivi insieme a trasformazioni e logica aziendale. Questo amplia la definizione di un prodotto dati affidabile.

I controlli SQL tradizionali determinano se i record sono arrivati, se le colonne corrispondono ai tipi previsti e se le trasformazioni calcolano correttamente. Le funzioni predittive richiedono test aggiuntivi. I team devono esaminare l’errore di previsione, gli intervalli di predizione, i falsi allarmi, la deriva e le prestazioni nei diversi segmenti aziendali.

Gli analisti aziendali affrontano una pressione diversa. Ottengono un accesso più rapido alla predizione, ma hanno anche bisogno di un giudizio migliore su cosa significhi l’output di un modello. Un risultato non è affidabile solo perché appare accanto a un grafico familiare.

Si consideri una previsione trimestrale delle vendite. I modelli storici possono cogliere la stagionalità, ma un’uscita pianificata da un mercato può renderli irrilevanti. Una promozione può aumentare il volume riducendo al tempo stesso il margine. Una previsione può inoltre non cogliere un’improvvisa limitazione dell’offerta che non compare nei dati di input.

Le covariate esterne aiutano solo quando i team le selezionano e le mantengono correttamente. Devono essere disponibili sia per il periodo storico sia per l’orizzonte di previsione. Una variabile altamente correlata alle vendite passate potrebbe essere indisponibile o sconoscibile in futuro.

L’analisi dei fattori trainanti crea una sfida correlata. Una funzione può identificare quali segmenti hanno contribuito maggiormente a un cambiamento di metrica. Ciò non stabilisce automaticamente che quei segmenti abbiano causato il cambiamento. Contributo e causalità rispondono a domande diverse.

La classificazione e la predizione di valori richiedono le proprie salvaguardie. Le etichette di addestramento possono incorporare vecchie regole aziendali o trattamenti diseguali. Le predizioni per valori mancanti possono apparire precise, nascondendo al contempo prove deboli per un gruppo specifico.

Il rilascio cambia quindi la coda di lavoro, non gli standard sottostanti. Le richieste semplici possono avvicinarsi al self-service, mentre le domande ambigue o ad alto impatto richiedono ancora la revisione di specialisti.

Questa distinzione dovrebbe dipendere dalle conseguenze. Una previsione approssimativa del personale usata per la pianificazione iniziale comporta un rischio diverso rispetto a una predizione che modifica decisioni su credito, assistenza sanitaria o occupazione. La stessa facilità di utilizzo non dovrebbe implicare lo stesso processo di approvazione.

I team avranno bisogno anche di regole di responsabilità. Qualcuno deve decidere quali tabelle sorgente siano adatte, come vengano monitorati gli output e quando un risultato richieda escalation. Senza questa struttura, la predizione self-service può moltiplicare risposte incoerenti anziché eliminare i colli di bottiglia.

Un modello operativo utile separa l’esplorazione dall’uso operativo. Gli analisti possono esplorare rapidamente gli schemi, quindi promuovere query di valore attraverso revisione e test. Ciò preserva la velocità senza trattare ogni predizione ad hoc come prova pronta per la produzione.

Il rilascio alza inoltre le aspettative nei confronti delle piattaforme dati. Se la predizione diventa parte del normale SQL, gli amministratori devono governare accesso, costo, lineage e riproducibilità insieme alle query convenzionali.

Per i knowledge worker che utilizzano questi risultati, il contesto resta essenziale. Una predizione priva di ipotesi, periodo sorgente e cronologia della valutazione è difficile da contestare. I team possono usare una knowledge base ricercabile per mantenere queste decisioni collegate all’analisi.

La predizione gestita sfida la pipeline di modelli personalizzati

La competizione centrale è tra risposte immediate e standardizzate e modelli più lenti costruiti attorno al problema specifico di un’organizzazione.

Una pipeline di previsione personalizzata offre controllo. I data scientist possono selezionare algoritmi, progettare feature, definire funzioni di perdita e ottimizzare il modello per un obiettivo aziendale. Possono inoltre creare trattamenti specializzati per dati scarsi, lanci di prodotti, rotture strutturali o calendari insoliti.

Questa flessibilità ha un costo. Ogni modello aggiuntivo crea lavoro di sviluppo e manutenzione. I team devono gestire dipendenze, ambienti di calcolo, riaddestramento programmato, monitoraggio e interfacce che distribuiscono il risultato.

Le Databricks Predictive AI Functions invertono questo compromesso. La piattaforma sceglie e mantiene l’approccio di modellazione. Gli utenti forniscono dati e parametri, quindi ricevono un risultato tramite un’interfaccia analitica familiare.

Per le richieste comuni, la standardizzazione può essere preziosa. Più reparti possono usare la stessa implementazione gestita invece di commissionare versioni separate. Una funzione richiamata da una dashboard e la stessa funzione richiamata tramite Genie dovrebbero seguire un percorso analitico condiviso.

La manutenzione centralizzata può anche offrire miglioramenti dei modelli senza costringere ogni cliente a ricostruire la propria pipeline. Questo beneficio dipende dalla capacità di Databricks di preservare un comportamento stabile, documentare le modifiche e fornire ai team informazioni sufficienti per valutare le nuove versioni.

La funzione di previsione illustra il meccanismo. Un modello preaddestrato parte da schemi appresi su un’ampia raccolta di serie temporali. Può quindi generare una previsione da una nuova serie senza l’addestramento convenzionale per singolo dataset.

Questa tecnica viene spesso chiamata previsione zero-shot. “Zero-shot” significa che il modello applica l’apprendimento precedente alla serie target senza essere addestrato specificamente per quell’attività di previsione.

Databricks afferma che la funzione aggiornata riconosce automaticamente stagionalità e tendenze. Supporta inoltre gli effetti delle festività e le covariate, che affrontano fattori specifici dell’attività che un generico schema storico potrebbe non cogliere.

L’azienda ha valutato ai_forecast con fev-bench e ha riportato un tasso di vittoria sulle attività superiore rispetto a un importante cloud data warehouse e alla propria funzione precedente. La libreria di valutazione fev supporta attività di previsione riproducibili, predizioni probabilistiche, covariate e diverse metriche di errore.

Databricks definisce il tasso di vittoria riportato tramite la perdita quantile scalata. La perdita quantile valuta le previsioni a diversi livelli di probabilità e penalizza le predizioni in base alla loro distanza dai risultati osservati. La scalatura aiuta i confronti tra serie con unità diverse.

Tuttavia, il post di lancio non fornisce sufficienti dettagli pubblici per generalizzare tale risultato a ogni carico di lavoro. I lettori hanno bisogno dell’esatto insieme di attività, della configurazione dei concorrenti, dei vincoli di input, delle versioni dei modelli e della distribuzione completa degli errori. Un tasso di vittoria da solo non mostra l’entità di ogni vittoria o sconfitta.

La distinzione è importante perché la qualità delle previsioni varia in base al dominio. Un modello può ottenere buoni risultati in molti benchmark e continuare comunque a faticare con i prodotti a breve ciclo di vita di un retailer o con la domanda intermittente di un produttore.

Le pipeline personalizzate mantengono un vantaggio quando l'obiettivo aziendale differisce da una metrica statistica generica. Un team di gestione delle scorte può preoccuparsi più di evitare le rotture di stock che di ridurre al minimo l'errore medio di previsione. Un altro team può attribuire un costo maggiore alla sovrastima della domanda.

Una funzione gestita può comunque offrire supporto a questi team come riferimento di base. Fornisce un risultato immediato rispetto al quale gli specialisti possono confrontare metodi personalizzati. Se un modello su misura non riesce a superare il riferimento gestito abbastanza da giustificare l'onere della sua manutenzione, la standardizzazione diventa allettante.

Questa è l'interpretazione più forte del rilascio. Databricks non sta sostituendo tutta la modellazione predittiva. Sta innalzando la capacità minima disponibile all'interno del data warehouse e costringendo i progetti personalizzati a dimostrare il proprio valore aggiunto.

BigQuery e Snowflake mostrano che è una corsa tra piattaforme

Databricks si unisce a una competizione più ampia per far percepire il machine learning come un'operazione nativa sui dati, anziché come un progetto software separato.

Google ha già portato l'addestramento e l'inferenza dei modelli in BigQuery attraverso SQL. La sua piattaforma copre forecasting, rilevamento delle anomalie, regressione, classificazione, analisi del contributo e altre attività di machine learning.

BigQuery offre anche una funzione di previsione gestita basata su TimesFM. La documentazione di Google su TimesFM integrato descrive previsioni univariate e multivariate senza richiedere agli utenti di creare un modello separato.

La funzione BigQuery supporta identificatori per più serie temporali, intervalli di previsione, controlli della finestra di contesto e covariate future. Google mantiene inoltre percorsi convenzionali di creazione dei modelli per i team che necessitano di maggiore controllo.

Snowflake offre funzioni di forecasting e rilevamento delle anomalie all'interno della propria piattaforma. I suoi modelli di anomalie GBM documentati confrontano i valori osservati con una previsione e utilizzano una gradient boosting machine per identificare gli outlier.

Questi approcci concorrenti condividono una direzione importante. Le piattaforme cloud per i dati vogliono che i clienti analizzino, prevedano e agiscano senza spostare dati governati in uno stack separato.

Le differenze emergeranno nella qualità dei modelli, nell'usabilità, nei requisiti dei carichi di lavoro, nell'integrazione e nella trasparenza. I team dovrebbero testare le stesse serie aziendali su più piattaforme anziché dedurre una superiorità dal benchmark di un solo fornitore.

Databricks dispone di un vantaggio di integrazione per i clienti che già utilizzano i suoi warehouse SQL, dashboard e Genie. La stessa funzione può collegare domande conversazionali a SQL ripetibile e a output visibili nelle dashboard.

Google può indicare la gamma matura di workflow per la creazione di modelli di BigQuery ML. Questi workflow consentono a chi pratica SQL di addestrare e valutare diversi tipi di modelli, mantenendo al contempo un controllo maggiore di quello offerto da una singola funzione gestita.

Anche Snowflake ha integrato funzioni di machine learning nel proprio ambiente dati. Il suo workflow di rilevamento delle anomalie mostra come le piattaforme warehouse possano nascondere gran parte del processo di sviluppo del modello pur continuando a esporre output analitici.

Il risultato non è una semplice checklist di funzionalità. Una funzione chiamata “forecast” può differire per i dati accettati, i limiti di contesto, il trattamento dei valori mancanti, gli output di incertezza e il supporto per le variabili esplicative.

Anche le superfici di governance contano. Un acquirente enterprise deve chiedersi se gli amministratori possano limitare gli accessi, tracciare ogni risultato ai suoi dati e riprodurre una previsione dopo una modifica del servizio.

L'accesso in linguaggio naturale aggiunge un'altra dimensione. Genie può rendere le funzioni disponibili a persone che non scrivono SQL. Questo amplia l'adozione, ma può anche nascondere dettagli importanti della query alla persona che prende una decisione.

Un'interfaccia conversazionale dovrebbe quindi mostrare la query generata, le colonne selezionate, i filtri, l'orizzonte temporale e l'incertezza. Altrimenti, gli utenti potrebbero valutare una spiegazione fluente anziché la procedura analitica effettiva.

Databricks sostiene che metodi predittivi specializzati permettono a Genie di rispondere a domande che un modello linguistico generalista non può gestire in modo affidabile. Questa distinzione è valida in linea di principio. I modelli linguistici generano testo, mentre il forecasting richiede metodi numerici legati a osservazioni ordinate e metriche di valutazione.

L'interfaccia può comunque interpretare male la richiesta prima di chiamare il metodo corretto. Un utente che chiede perché il fatturato è cambiato potrebbe intendere il contributo regionale, la scomposizione prezzo-volume o l'impatto causale. Non sono analisi intercambiabili.

La corsa tra piattaforme dipenderà quindi da più fattori della semplice possibilità di chiamare le funzioni. I prodotti vincenti dovranno aiutare gli utenti a formulare la domanda giusta, ispezionare il calcolo e riconoscere quando il risultato non supporta una conclusione.

I limiti della beta rendono la validazione parte del prodotto

La maggiore incertezza è se gli utenti self-service valideranno le previsioni con la stessa cura che gli specialisti applicano ai modelli personalizzati.

Almeno una funzione presenta già vincoli concreti della beta. La documentazione Databricks afferma che ai_detect_anomalies richiede un warehouse SQL Pro o Serverless e l'iscrizione all'anteprima Predictive AI Functions.

La funzione esamina lo storico precedente a ciascun valore, stima un intervallo atteso e assegna un punteggio di anomalia. Gli utenti possono regolare una soglia che controlla quando una riga riceve un indicatore di anomalia.

I suoi attuali limiti di rilevamento delle anomalie includono un massimo di 8.192 righe di input per serie temporale. Ogni serie necessita inoltre di timestamp univoci e una singola invocazione può analizzare una sola colonna di valori.

Le prime otto righe forniscono contesto storico e non ricevono output ordinari sulle anomalie. I team che usano serie brevi devono comprendere in che modo questo influisca sulla copertura.

La funzione offre anche lo smoothing, che può unire avvisi vicini in un unico episodio anomalo. Lo smoothing può rendere gli incidenti più facili da leggere, ma può contrassegnare valori normali all'interno di un breve intervallo.

Questi dettagli mostrano perché “nessun modello da gestire” non significa “nessuna scelta analitica”. Soglie, colonne di raggruppamento, covariate, festività e finestre di scoring influiscono tutte sul risultato.

I falsi positivi generano costi operativi. Un sistema di allerta che segnala variazioni di routine può esaurire i suoi utenti. I falsi negativi creano un rischio diverso perché un cambiamento rilevante può passare senza revisione.

Le previsioni richiedono backtesting, che valuta le predizioni rispetto a periodi storici nascosti al modello. I team dovrebbero testare diversi orizzonti perché l'accuratezza a sette giorni non garantisce l'accuratezza a un trimestre.

Dovrebbero inoltre confrontare il modello gestito con semplici baseline. I valori dell'ultimo periodo, le medie stagionali e i metodi statistici consolidati offrono spesso riferimenti utili. Un modello sofisticato dovrebbe guadagnarsi fiducia migliorando gli esiti rilevanti.

Gli intervalli di previsione meritano attenzione. Una previsione puntuale fornisce un singolo valore atteso, mentre un intervallo comunica un intervallo plausibile. Decisioni basate solo sul valore centrale possono creare una falsa certezza.

La valutazione a livello di segmento è altrettanto importante. Una previsione complessiva può apparire accurata perché i prodotti ad alto volume dominano la metrica. Le prestazioni possono restare scarse per regioni minori o prodotti appena lanciati.

La fuga di dati presenta un altro pericolo. Si verifica quando un modello riceve informazioni che non sarebbero state disponibili al momento della previsione. Una covariata può apparire valida nei dati storici rendendo al contempo la valutazione futura irrealisticamente facile.

L'analisi dei driver richiede un linguaggio disciplinato. Un segmento classificato ai primi posti può spiegare il contributo aritmetico a un cambiamento senza dimostrare perché sia cambiato il comportamento dei clienti. I team dovrebbero riservare le affermazioni causali a disegni che identificano effetti causali.

Anche gli output di classificazione possono amplificare problemi storici. Se le etichette riflettono decisioni umane incoerenti, l'automazione di tali etichette può riprodurre l'incoerenza su scala maggiore.

Gli aggiornamenti dei modelli introducono questioni di riproducibilità. I modelli gestiti centralmente possono migliorare automaticamente, ma la stessa query potrebbe alla fine produrre un risultato diverso. Le imprese hanno bisogno di registri delle versioni e avvisi di modifica per le decisioni importanti.

Il periodo beta dovrebbe rivelare se Databricks fornisce strumenti di valutazione sufficienti attorno alle funzioni. Aggiunte utili includerebbero backtest integrati, confronti con baseline, riepiloghi delle prestazioni e avvisi di deterioramento dell'accuratezza.

Fino ad allora, i team dovrebbero allegare una model card sintetica agli utilizzi operativi. Dovrebbe indicare il target, la finestra dati, l'orizzonte di previsione, le variabili di input, i limiti noti, il metodo di validazione e il responsabile.

Questa documentazione non deve rallentare la sperimentazione. Diventa necessaria quando un output entra nella pianificazione, nelle azioni automatizzate o nella reportistica per i dirigenti.

Un conciso workflow AI può anche preservare ipotesi e decisioni successive. L'obiettivo è impedire che una previsione temporanea diventi un fatto organizzativo non documentato.

Tre segnali mostreranno se la scommessa funziona

Il prossimo test non è se gli analisti possono chiamare le funzioni, ma se le organizzazioni si fidano ripetutamente dei loro output e li rendono operativi.

Il primo segnale è l'evidenza proveniente dai carichi di lavoro dei clienti. Databricks ha mostrato esempi che utilizzano dati pubblici sui taxi e ha riportato confronti benchmark. Ora gli acquirenti hanno bisogno di risultati pubblicati da ambienti operativi nel retail, nella finanza, nella produzione, nel software e in altri settori.

Le evidenze più solide includeranno orizzonti di previsione, modelli baseline, calibrazione dell'incertezza e cambiamenti nell'errore dopo il deployment. Dovrebbero inoltre mostrare dove le funzioni gestite falliscono.

Un'ampia evidenza sui clienti rafforzerebbe l'argomento secondo cui un unico livello di modelli gestiti può servire domande aziendali diverse. Esempi ristretti o fortemente curati indebolirebbero questa affermazione.

Il secondo segnale è un supporto più profondo per valutazione e governance. Occorre osservare backtesting nativo, visibilità delle versioni dei modelli, lineage, monitoraggio e controlli di approvazione attorno alle query operative.

Queste capacità mostrerebbero che Databricks considera la previsione come qualcosa di più di un'altra espressione SQL. Ridurrebbero anche il divario tra analisi rapida e un processo di produzione governato.

La mancanza di strumenti di valutazione riporterebbe più lavoro sui clienti. Questo esito manterrebbe parte del collo di bottiglia originario, anche se l'addestramento dei modelli diventasse più semplice.

Il terzo segnale è la risposta di BigQuery, Snowflake e di altre piattaforme analitiche. I fornitori concorrenti possono rispondere con nuove funzioni, benchmark più solidi, una migliore integrazione conversazionale o controlli più chiari.

Una risposta competitiva rapida confermerebbe che il SQL predittivo gestito è diventato una categoria centrale delle piattaforme dati. Una debole adozione presso i vari fornitori suggerirebbe che gli strumenti personalizzati servono ancora alla maggior parte delle esigenze serie di forecasting.

I team non devono aspettare che il mercato si stabilizzi. Possono iniziare con un caso d'uso circoscritto, in cui le decisioni sono reversibili e i risultati arrivano rapidamente.

Una previsione settimanale della domanda è più facile da valutare di una proiezione strategica pluriennale. Un avviso di anomalia esaminato da un essere umano è più sicuro di un avviso che modifica automaticamente l'accesso dei clienti.

Iniziate annotando la decisione che l'output dovrà supportare. Poi definite una baseline, un periodo di valutazione, una tolleranza all'errore e una regola di escalation prima di confrontare i risultati.

Eseguite la funzione gestita su finestre storiche e registrate le prestazioni per segmento. Includete gli intervalli di previsione ed esaminate gli errori più grandi, non soltanto il punteggio medio.

Se la funzione offre buoni risultati, inseriscila in una dashboard esistente rendendo esplicite le sue ipotesi. Mantieni una fase di revisione da parte di specialisti finché il team non avrà compreso come il risultato si comporta al variare delle stagioni e durante eventi insoliti.

Le Predictive AI Functions di Databricks rendono più semplice richiedere e distribuire analisi avanzate. Il loro valore duraturo dipenderà dal fatto che i team rendano altrettanto accessibile la valutazione.

Il rilascio offre agli analisti un percorso più breve dai dati alla previsione. Elimina inoltre alcuni ostacoli che in precedenza costringevano le organizzazioni a fermarsi prima di rendere operativo un modello. Questo rende una revisione rigorosa più importante, non meno.

Quale domanda ricorrente sta assorbendo oggi il tempo del tuo team di dati? Scegline una, confronta il risultato gestito con una semplice baseline e documenta dove funziona o fallisce. Questo confronto rivelerà se Databricks ha eliminato un vero collo di bottiglia o lo ha semplicemente spostato più a valle.