Databricks ai_decide Porta i Dati Governati Dall'Analisi all'Azione

Databricks ha lanciato Databricks ai_decide il 30 settembre, aggiungendo una funzione SQL in beta che trasforma i dati governati in probabilità, scelte e punteggi. Il conflitto è immediato. Le aziende vogliono decisioni assistite dall'AI alla velocità dei dati, ma le scelte operative richiedono maggiore responsabilità rispetto alla normale generazione di testo.

La nuova funzione valuta record strutturati o testo rispetto a una griglia fornita dall'utente. Può stimare se un evento richiede attenzione, scegliere tra risultati nominati o attribuire un punteggio a un caso su una scala ordinata. Questi output possono quindi alimentare un'altra query SQL, un workflow o un'applicazione.

Questo rende l'annuncio più rilevante di un altro endpoint di modello. Databricks porta il giudizio basato sui modelli all'interno del workflow dei dati, dove i team controllano già tabelle, autorizzazioni, pipeline e logica di business. Google Cloud offre funzioni generative correlate in BigQuery, mentre le API di modelli generalisti consentono agli sviluppatori di costruire manualmente sistemi simili. La competizione riguarda ora chi riesce a rendere operative le decisioni probabilistiche senza nasconderne l'incertezza.

Databricks ai_decide Trasforma Una Chiamata SQL in Diverse Decisioni

Il cambiamento importante non è che Databricks possa chiamare un modello da SQL. È che una funzione governata possa restituire diverse valutazioni pronte per la decisione sullo stesso record.

Secondo il post di lancio dell'azienda, Databricks ai_decide è pensato per decisioni rapide sui dati aziendali governati. La funzione rientra nella più ampia famiglia di AI Functions specifiche per attività dell'azienda.

La sintassi è composta da tre parti: uno stato, una raccolta di domande e impostazioni di versione facoltative. Lo stato contiene le prove valutate. Può essere testo normale, un oggetto codificato in JSON, un array JSON o un VARIANT generato da un'altra AI Function.

Le domande vengono definite una volta per la chiamata e applicate a ogni riga di input. Ogni domanda include istruzioni e un tipo di risposta. Alcuni tipi richiedono anche criteri che descrivano i risultati disponibili.

Il riferimento della funzione documenta tre tipi di risposta:

• noul stima la probabilità che un'affermazione sia vera, restituendo un numero compreso tra 0 e 1.

• choice seleziona un'etichetta tra un massimo di 255 criteri nominati e restituisce le probabilità per ogni etichetta.

• score valuta l'input rispetto a una scala ordinata contenente da 2 a 10 criteri.

L'insolito termine noul identifica una valutazione probabilistica sì-o-no. Anziché imporre una risposta booleana, la funzione riporta una probabilità stimata. Questa distinzione conta quando i sistemi downstream necessitano di soglie anziché di affermazioni assolute.

Un'organizzazione di assistenza, ad esempio, potrebbe chiedere se un ticket necessita di un'escalation immediata. Potrebbe anche chiedere quale team debba gestire il caso e quanto urgente appaia la situazione. Tutte e tre le valutazioni possono usare lo stesso ticket come prova.

Il risultato è un VARIANT contenente una risposta, metadati e un campo di errore. Un VARIANT è un tipo di dati flessibile per valori semi-strutturati, come JSON annidato. Le chiamate riuscite identificano la versione della funzione, mentre quelle non riuscite possono restituire una descrizione dell'errore.

Per le domande di scelta, l'output include l'etichetta selezionata, le probabilità per ogni possibile etichetta e un valore di confidenza. Le domande con punteggio includono un punteggio numerico, le descrizioni originali della scala, le probabilità e la confidenza.

Questo design offre agli analisti più informazioni di una singola etichetta generata. Un workflow può accettare automaticamente le decisioni ad alta confidenza, indirizzare i casi incerti alle persone e registrare la distribuzione delle probabilità per una revisione successiva.

Databricks avverte inoltre che le risposte generate possono variare tra le chiamate. È un'affermazione facile da trascurare, ma definisce la principale sfida operativa. La sintassi SQL rende la funzione accessibile e componibile. Non rende deterministico il giudizio sottostante.

Le Decisioni AI Governate Mettono Sotto Pressione i Team Dati

Databricks ai_decide spinge i team dati a trattare il giudizio del modello come logica di produzione, non come un output sperimentale copiato da un chatbot.

Molte decisioni aziendali iniziano già in un data warehouse o lakehouse. Ticket di assistenza, schede prodotto, documenti assicurativi, rapporti sugli incidenti, candidature e record di transazioni diventano infine righe elaborate dalle pipeline.

Il SQL tradizionale funziona bene quando la decisione può essere scritta come una regola esatta. Una transazione sopra un importo fisso può entrare in una coda di revisione. Un ticket che riporta un codice di errore noto può essere inviato a un team specifico.

I casi più difficili dipendono dal significato. Un cliente può descrivere un'interruzione del servizio senza usare il vocabolario ufficiale dell'azienda per gli incidenti. Una scheda prodotto può implicare l'idoneità senza corrispondere a una tassonomia controllata. Un caso può soddisfare contemporaneamente più priorità in competizione.

Le organizzazioni spesso gestiscono queste situazioni tramite code manuali o servizi di modelli esterni. La revisione manuale può essere lenta. I servizi esterni introducono codice aggiuntivo, spostamento dei dati, credenziali, monitoraggio e attività di governance.

Databricks ai_decide comprime questo percorso. Un team può esprimere una griglia qualitativa accanto ai dati e ricevere valutazioni strutturate all'interno di SQL. Queste valutazioni possono poi partecipare a filtri, join, dashboard, pipeline Lakeflow, Workflows o logica applicativa.

La più ampia panoramica delle AI Functions descrive funzioni integrate per il parsing dei documenti, l'estrazione, la classificazione, la preparazione per la ricerca e altre trasformazioni. Databricks ai_decide aggiunge un livello decisionale esplicito dopo tali fasi di preparazione.

Si consideri un workflow documentale. ai_parse_document può convertire un documento caricato in contenuto strutturato. ai_extract può identificare campi specificati. Databricks ai_decide può poi valutare il VARIANT risultante rispetto a una griglia di business.

Questa sequenza cambia chi può costruire il workflow. Un data engineer non deve più racchiudere ogni decisione in un servizio personalizzato. Un analista può esaminare stato, criteri, risposte, probabilità ed errori attraverso strumenti dati familiari.

Cambia anche chi diventa responsabile. Quando un punteggio generato dall'AI controlla l'instradamento o la prioritizzazione, il team dati possiede più della sola performance delle query. Deve contribuire a definire tassi di errore accettabili, soglie di escalation, regole di monitoraggio e comportamenti di fallback.

La governance diventa parte della progettazione del prodotto. Databricks afferma che i dati dei documenti rimangono all'interno del suo perimetro di sicurezza. L'azienda afferma di non archiviare i parametri passati alle chiamate di AI Function, anche se conserva metadati di esecuzione come la versione del runtime.

L'accesso non è automaticamente ristretto. La documentazione Databricks afferma che gli utenti ricevono per impostazione predefinita il permesso EXECUTE sullo schema system.ai quando è abilitata la relativa anteprima. Gli amministratori devono rimuovere tale autorizzazione a livello di schema prima di concedere l'accesso a funzioni o gruppi selezionati.

Questi controlli di accesso sono essi stessi in anteprima pubblica e richiedono l'abilitazione. Si applicano alle funzioni specifiche per attività sotto system.ai, ma non regolano la funzione generalista ai_query.

Questo confine è importante. Un'azienda non può presumere che l'abilitazione di un meccanismo di governance copra ogni percorso verso un modello. Gli amministratori necessitano di policy separate per AI Functions specifiche per attività e chiamate dirette a Model Serving.

Il lancio crea quindi pressione contemporaneamente sui responsabili della piattaforma, i team di sicurezza e i leader operativi. I responsabili della piattaforma devono rendere affidabile la funzione. I team di sicurezza devono configurare l'accesso in modo intenzionale. I leader aziendali devono definire dove l'automazione probabilistica sia accettabile.

Le Griglie Strutturate Sono il Vero Meccanismo

Il meccanismo centrale è un passaggio dai prompt aperti a griglie esplicite con incertezza strutturata.

Un prompt per un modello generalista può chiedere: “Cosa dovremmo fare con questo caso?” La risposta può essere articolata, ma un altro sistema deve analizzarla. Il modello potrebbe anche inventare una categoria, cambiare formato o spiegare una decisione senza produrre un campo affidabile.

Databricks ai_decide restringe l'interazione. Lo sviluppatore definisce domande nominate, istruzioni e criteri consentiti. La funzione restituisce una forma di risposta prevedibile che il SQL downstream può utilizzare.

Questo vincolo riduce il lavoro di integrazione. Espone inoltre il contratto decisionale ai revisori. Uno specialista della compliance può esaminare la definizione dell'escalation. Un responsabile operativo può ispezionare le descrizioni delle categorie. Un data engineer può verificare come le probabilità diventino azioni nel workflow.

Il tipo choice illustra l'approccio. Supponiamo che un'organizzazione di assistenza definisca spedizioni, fatturazione e supporto tecnico come le uniche etichette di instradamento. La funzione deve selezionare tra questi nomi e restituire una probabilità per ciascuno.

L'etichetta selezionata è utile, ma la distribuzione può essere più informativa. Un risultato ripartito in modo simile tra fatturazione e supporto tecnico segnala ambiguità. Un workflow può inviare quel caso a una coda generale anziché fingere che l'etichetta principale sia certa.

Il tipo score utilizza criteri ordinati anziché un numero in formato libero. Un team potrebbe definire tre livelli di urgenza, da una richiesta di routine a un blocco critico. Il punteggio restituito è una media ponderata per probabilità degli indici dei criteri.

Questo metodo conserva informazioni sulle valutazioni in competizione. Se il modello assegna probabilità a più livelli, il risultato può essere frazionario. L'output conserva anche la legenda e le probabilità alla base del punteggio.

Più domande possono condividere uno stato. Ciò riduce la necessità di far passare le stesse prove attraverso prompt separati per categoria, urgenza, escalation e altri giudizi. Mantiene inoltre insieme le risposte correlate.

Tuttavia, condividere l'input non garantisce che ogni domanda rappresenti una valutazione indipendente. I team dovrebbero verificare se le istruzioni interagiscono in modi inattesi. Dovrebbero inoltre verificare se combinare le domande modifica qualità, latenza o costo per il loro carico di lavoro.

Databricks afferma che il modello sottostante può cambiare se un altro modello offre prestazioni migliori nei suoi benchmark interni. La documentazione attuale associa i possibili modelli alla licenza Apache 2.0 e indirizza i clienti ai termini applicabili ai modelli.

Una scelta di modello gestita riduce la configurazione. Significa però anche che il comportamento della funzione può evolvere sotto un'interfaccia SQL stabile. I metadati di versione aiutano a identificare il contratto della funzione, ma i team necessitano comunque di test di regressione basati su dati rappresentativi.

È qui che il meccanismo diventa importante dal punto di vista operativo. Una stored procedure costruita su condizioni deterministiche può essere testata rispetto a output attesi esatti. Una funzione probabilistica richiede controlli delle distribuzioni, delle soglie e valutazioni ripetute.

I team dovrebbero mantenere set di valutazione etichettati per ogni griglia importante. Questi set dovrebbero includere esempi comuni, casi limite, prove mancanti, prove in conflitto e input che dovrebbero sempre raggiungere una persona.

Dovrebbero inoltre separare la raccomandazione dall'esecuzione. Una funzione decisionale può prioritizzare una coda di assistenza con conseguenze limitate. La stessa confidenza non dovrebbe autorizzare automaticamente un rimborso, respingere un candidato, sospendere un account o avviare una risposta di sicurezza.

L'interfaccia SQL rende semplice la composizione. Una buona progettazione dei sistemi deve mantenere deliberatamente difficili le azioni conseguenziali.

Databricks ai_decide compete con le chiamate a modelli generici e con l'AI nei data warehouse

La principale competizione è tra una funzione gestita specifica per il compito e la flessibilità di costruire una logica decisionale attorno a un endpoint di modello generico.

Databricks offre già ai_query, una funzione generica che richiama un endpoint Model Serving. Gli sviluppatori possono scegliere un modello supportato, scrivere prompt personalizzati e controllare parametri e tipi di ritorno.

La documentazione di ai_query raccomanda ai team di iniziare con una AI Function specifica per il compito quando questa corrisponde al loro obiettivo. Riserva ai_query ai casi che richiedono maggiore controllo sul modello, sul prompt, sui parametri o sull'output.

Questa distinzione crea un chiaro compromesso.

Una funzione specifica per il compito riduce la configurazione e impone un contratto strutturato. Databricks gestisce il sistema alla base dell'operazione e può migliorarne l'implementazione. I team possono concentrarsi sulle proprie evidenze, domande e criteri.

Una chiamata a un modello generico offre flessibilità. Gli sviluppatori possono usare un modello personalizzato, regolare le impostazioni di decodifica, definire uno schema diverso, implementare endpoint di fallback o mantenere una versione fissa del modello. Si assumono però anche più lavoro di ingegneria e valutazione.

Databricks ai_decide è più efficace quando una decisione rientra nelle sue tre forme disponibili. Probabilità, scelta nominata e punteggio ordinato coprono molte attività di instradamento e definizione delle priorità. Non coprono però ogni struttura decisionale.

Un'azienda potrebbe aver bisogno di classificazione multietichetta, stime numeriche vincolate, citazioni delle evidenze, esclusioni basate su regole o una catena di domande dipendenti. Per questi casi, gli sviluppatori potrebbero comunque aver bisogno di ai_query, funzioni personalizzate o un'applicazione esterna.

Il panorama competitivo si estende anche oltre Databricks. Google Cloud documenta una funzione AI.GENERATE_BOOL per BigQuery che restituisce un risultato booleano, dettagli della risposta e informazioni sullo stato. Può elaborare testo e contenuti non strutturati referenziati tramite Gemini.

La funzione booleana di Google supporta parametri del modello e della richiesta. La sua documentazione avverte inoltre che la progettazione del prompt influisce sui risultati e che la pianificazione delle query può far sì che l'inferenza del modello elabori più righe del previsto.

Google offre separatamente AI.IF, che la sua documentazione descrive come dotata di supporto per l'ottimizzazione dei prompt e di una modalità ottimizzata. Questa modalità può addestrare un modello distillato per ridurre costi e latenza su larga scala.

Databricks adotta un approccio più ampio, orientato alle rubriche, in una sola chiamata. Databricks ai_decide può rispondere a più domande e restituire probabilità per scelte nominate o punteggi ordinati. La funzione booleana documentata da Google si concentra sulla generazione vero-o-falso, sebbene BigQuery offra ulteriori funzioni scalari e generative.

Nessuno dei due approcci elimina la necessità di progettare l'applicazione. L'AI nativa del warehouse riduce la distanza tra dati e inferenza, ma i team devono comunque scegliere soglie, materializzare input, controllare autorizzazioni e valutare gli output.

La competizione dipenderà quindi da evidenze operative, non solo dalla sintassi. Gli acquirenti devono sapere come le funzioni si comportano sui loro record, nelle loro regioni, in base ai loro requisiti di conformità e ai volumi di produzione.

Una funzione che fa risparmiare lavoro di integrazione ma crea costi imprevedibili avrà difficoltà. Lo stesso vale per un endpoint flessibile che richiede un team specializzato per ogni attività ordinaria di classificazione.

Databricks scommette sul fatto che molte decisioni aziendali condividano una struttura sufficiente da meritare una primitiva gestita. L'esito dipende dal fatto che tali primitive restino comprensibili quando le organizzazioni le collegano ad azioni concrete.

Le decisioni rapide richiedono comunque una validazione lenta

L'etichetta beta è l'avvertimento più chiaro: Databricks ha semplificato l'implementazione, ma non ha eliminato incertezza, limiti regionali o responsabilità umana.

Databricks ai_decide è disponibile come funzionalità beta. Gli amministratori del workspace controllano l'accesso tramite la pagina Previews e la funzione è disponibile soltanto nelle regioni supportate.

Non funziona su Databricks SQL Classic. La documentazione richiede Databricks Runtime 15.4 LTS o versioni successive e raccomanda Runtime 18.2 o successivo per funzionalità e prestazioni correnti.

Questi prerequisiti limitano l'adozione immediata. Le organizzazioni con runtime meno recenti, warehouse Classic, regioni non supportate o rigide policy sulle anteprime devono modificare l'infrastruttura o attendere.

Il livello del modello introduce un'altra incertezza. Databricks afferma che potrebbe cambiare il modello sottostante quando i suoi benchmark interni identificano un'opzione migliore. Questa evoluzione gestita può migliorare i risultati, ma crea anche deriva del modello dal punto di vista del cliente.

Una pipeline decisionale non può fare affidamento esclusivamente sulla stabilità del nome della funzione. I team necessitano di valutazioni di riferimento, controlli sulle release, soglie monitorate e della capacità di confrontare i risultati dopo modifiche alla piattaforma.

Anche la rubrica stessa può fallire. Le istruzioni potrebbero omettere un'eccezione significativa. Le categorie potrebbero sovrapporsi. Una scala ordinata potrebbe suggerire una precisione che le evidenze non supportano.

La confidenza richiede un'interpretazione accurata. Un campo di confidenza elevato indica quanto bene lo stato supporti la valutazione secondo il processo della funzione. Non stabilisce che la risposta sia fattualmente corretta o equa.

Gli output di probabilità comportano un rischio simile. Un valore di 0,9 appare preciso, ma gli utenti non dovrebbero presumere che il 90 percento delle previsioni comparabili sarà corretto senza evidenze di calibrazione. La calibrazione deve essere testata sui casi etichettati dell'organizzazione stessa.

La qualità dei dati resta decisiva. Se lo stato contiene record obsoleti, incompleti o fuorvianti, una rubrica ben strutturata può comunque produrre una decisione scadente. I controlli di governance stabiliscono chi può usare i dati; non garantiscono che ogni input sia appropriato.

Anche esempi e criteri possono introdurre bias. La descrizione di una categoria può codificare la prassi storica di un team, inclusi i suoi punti ciechi. Un punteggio può riprodurre giudizi umani incoerenti provenienti da un set di valutazione.

Gli usi ad alto impatto richiedono salvaguardie più forti. Le decisioni su occupazione, credito, sanità, assicurazioni, ambito legale e sicurezza comportano obblighi che vanno oltre l'output di un modello. Le organizzazioni dovrebbero coinvolgere team di dominio, legali, sicurezza e rischio prima di automatizzare le azioni.

Anche i flussi di lavoro a minor rischio necessitano di una gestione dei fallimenti. La funzione può restituire una risposta nulla e un messaggio di errore. Le pipeline devono decidere se ritentare, sospendere, usare una logica di fallback deterministica o indirizzare il caso a una persona.

Secondo la documentazione, le risposte generate possono variare tra chiamate. Valutazioni ripetute potrebbero quindi produrre etichette o punteggi diversi per record al limite. I team necessitano di policy di idempotenza quando le azioni a valle dovrebbero verificarsi una sola volta.

I costi meritano un'attenzione analoga. Ogni valutazione supportata dal modello consuma risorse di inferenza. Eseguire diverse domande su ogni riga di una tabella di grandi dimensioni può trasformare una query pratica in un'operazione costosa.

Gli sviluppatori dovrebbero isolare le righe rilevanti prima di invocare la funzione. Dovrebbero materializzare set di input stabili, impedire rivalutazioni accidentali dell'intera tabella e memorizzare gli output quando inferenze ripetute non aggiungono valore.

Nessuna di queste preoccupazioni invalida la direzione del prodotto. Spiegano perché le decisioni AI governate richiedano uno standard diverso dai riepiloghi generati. Un riepilogo debole causa un inconveniente al lettore. Una decisione debole di instradamento o prioritizzazione cambia ciò che accade dopo.

Tre segnali mostreranno se la scommessa funziona

Il prossimo test è capire se Databricks riuscirà a trasformare una promettente astrazione SQL in una capacità di produzione misurabile e governabile.

Il primo segnale è rappresentato dalle prestazioni di valutazione documentate. Databricks non ha presentato benchmark indipendenti che stabiliscano accuratezza, calibrazione, latenza o costi su attività decisionali rappresentative. I clienti necessitano di evidenze specifiche per i carichi di lavoro, anziché di una promessa generica di velocità.

Una validazione utile confronterebbe Databricks ai_decide con ai_query, regole deterministiche e revisione umana consolidata. Dovrebbe misurare accuratezza delle etichette, calibrazione delle probabilità, stabilità tra chiamate ripetute, tempi di elaborazione e numero di casi che richiedono escalation.

Se i team riescono a pubblicare miglioramenti ripetibili con tassi di errore controllati, l'approccio specifico per il compito acquista credibilità. Se devono avvolgere ogni chiamata in un'ampia logica correttiva, l'astrazione risparmia meno lavoro di quanto suggerisca la sintassi.

Il secondo segnale è una più ampia disponibilità in produzione. La funzionalità porta attualmente l'etichetta beta, richiede l'abilitazione dell'anteprima, esclude i warehouse SQL Classic e supporta soltanto determinate regioni.

Un passaggio verso una disponibilità più ampia indicherebbe che Databricks è fiduciosa nell'affidabilità del servizio, nella copertura di governance e nel supporto operativo. Restrizioni di anteprima persistenti limiterebbero la funzione a esperimenti e flussi di lavoro a basso rischio.

La maturità della governance rientra nello stesso segnale. Gli amministratori hanno bisogno di controlli chiari per autorizzazioni di esecuzione, accesso ai modelli, tracce di audit, elaborazione regionale e modifiche ai modelli sottostanti. Questi controlli devono funzionare in modo coerente tra piattaforme cloud e configurazioni dei workspace.

Il terzo segnale è l'uso da parte dei clienti oltre le dimostrazioni. La categorizzazione dei prodotti e l'instradamento dei ticket di supporto sono esempi comprensibili. Le prove più forti proverranno da flussi di lavoro di produzione con soglie di revisione pubblicate e risultati aziendali misurabili.

Osservate i casi in cui le probabilità modificano il flusso di lavoro, non si limitano a decorare una dashboard. Un'azienda potrebbe automatizzare le decisioni chiare, inviare i record ambigui a specialisti e usare le correzioni risultanti per testare la propria rubrica.

Osservate anche i concorrenti. Google Cloud espone già funzioni generative native del warehouse e altre piattaforme dati continuano ad aggiungere accesso ai modelli vicino ai dati governati. Una funzione concorrente con calibrazione più chiara, supporto di input più ampio o minori costi operativi indebolirebbe il vantaggio di Databricks.

Databricks ai_decide coglie un cambiamento importante. Le aziende non sono più soddisfatte di modelli che si limitano a descrivere le informazioni. Vogliono sistemi che aiutino a scegliere, classificare, instradare ed escalare, restando all'interno dei controlli sui dati già stabiliti.

Il passo successivo prudente non è collegare direttamente la funzione a un'azione rilevante. Selezionate una coda circoscritta, definite una rubrica esplicita e costruite un set di valutazione etichettato. Confrontate gli output della funzione con le decisioni attuali, quindi scegliete soglie per l'automazione e la revisione umana. Monitorate separatamente errori, incertezza, latenza e deriva.

Quale decisione nella vostra organizzazione è abbastanza ripetitiva da poter essere valutata, ma anche abbastanza reversibile da poter essere testata in sicurezza? È questo il giusto punto di partenza per Databricks ai_decide. Il valore duraturo del prodotto deriverà da una disciplina operativa trasparente, non dal trattare un output probabilistico come una certezza.