Come funziona realmente la decision intelligence: da una domanda in linguaggio naturale, attraverso lo strato semantico di metriche, fino a una risposta ancorata, con rilevamento delle anomalie e forecasting con incertezza dichiarata. Scritta per capire il motore prima di condividere un solo byte di dati con noi.
Per anni, ottenere una risposta dai propri dati richiedeva un data analyst, una coda di ticket e qualche giorno di botta e risposta. Gli strumenti sono cambiati abbastanza da rendere tutto questo non piu necessario. Cio che non e cambiato e la disciplina necessaria per rendere le risposte affidabili: non basta puntare un language model su un database grezzo e chiamarlo analytics. Questa guida illustra l'intero metodo.
La decision intelligence e la pratica di rendere i dati di business interrogabili in linguaggio naturale, con le risposte ancorate a definizioni concordate così che significhino la stessa cosa per chiunque faccia la domanda. E uno strato che si colloca sopra il tuo data warehouse e lo trasforma da un luogo dove i dati sono conservati a un luogo dove le decisioni vengono prese.
E utile separare tre cose che spesso vengono compresse in un unico pitch:
Ognuno di questi puo stare da solo, ma si moltiplicano. Un team che puo porre qualsiasi domanda, viene avvisato quando qualcosa si rompe e ha una previsione su cio che viene dopo opera in modo fondamentalmente diverso da uno che aspetta la review settimanale.
Ogni progetto inizia con un'analisi gratuita, perche e l'unico modo onesto di definire lo scope del lavoro. Condividi un campione dei tuoi dati e un elenco delle domande che il tuo team sta attualmente chiedendo a una persona di rispondere. Modelliamo le metriche, eseguiamo l'analisi e torniamo con risposte reali ancorate ai tuoi numeri, anomalie rilevate sulla tua storia e una previsione con la sua accuratezza misurata.
Tieni il risultato a prescindere da come procedi. Un'analisi misurata sui tuoi dati reali e un artefatto utile di per se, e pone fine alle congetture che uccidono la maggior parte dei progetti dati prima ancora di iniziare. Se i numeri reggono e le risposte sono genuinamente utili, definiamo lo scope della build completa da li.
L'interfaccia che la maggior parte delle persone vede per prima e il campo domanda. Scrivi "perche i ricavi sono calati a marzo?" in linguaggio naturale e arriva una risposta. Il meccanismo dietro e un language model che traduce la domanda in SQL, lo esegue sui tuoi dati e restituisce il risultato con un grafico.
E qui che la maggior parte delle demo si ferma e dove la maggior parte dei progetti fallisce. Un language model che traduce una domanda in forma libera in SQL su un database non documentato e non etichettato produce SQL che gira ma restituisce il numero sbagliato con alta confidenza. Unisce le tabelle sbagliate, applica il filtro di data sbagliato e perde la logica di business che fa si che "ricavi" significhi lordo o netto a seconda del contesto. L'output sembra plausibile. Non e affidabile.
La soluzione non e un modello piu intelligente. E uno strato semantico di metriche, di cui si parla nella sezione successiva.
Lo strato semantico di metriche e l'insieme di definizioni che si collocano tra le tue tabelle grezze e l'interfaccia delle domande. E qui che "ricavi" viene definito come orders.amount meno refunds.amount, filtrato agli ordini completati, con la regola che un rimborso applicato a un ordine di un periodo precedente aggiusta il periodo corrente anziche quello originale. Quella definizione viene codificata una volta, testata, e poi ogni query la utilizza.
Costruire questo strato costituisce la maggior parte del lavoro del progetto, ed e anche dove risiede la maggior parte del valore. Una volta che le metriche sono definite, un utente di business che chiede "quali erano i ricavi a marzo?" e un data analyst che scrive la stessa query otterranno lo stesso numero, perche entrambi girano sulla stessa definizione. Quella coerenza e cio che rende le risposte abbastanza affidabili da inserire in un report esecutivo o in una presentazione al board.
Lo strato porta anche la granularita (questa metrica e giornaliera, mensile, per regione, per prodotto?), le regole di accesso (chi puo vedere quali metriche?) e le mappature delle dimensioni (quando qualcuno dice "UK", a quali valori di colonna corrisponde?). Questi sono i dettagli che una query di un language model grezzo sbagliera, e lo strato e cio che rende ottenerli correttamente affidabile anziche fortunato.
Ancorare significa che ogni numero in una risposta puo essere ricondotto all'SQL che lo ha prodotto, e quell'SQL puo essere ricondotto alla definizione di metrica che lo ha informato. Un utente che mette in discussione un numero puo vedere esattamente come e stato calcolato, da quale colonna proviene e quale filtro e stato applicato. Questa e la differenza tra un risultato di cui ti fidi e un risultato che verifichi ogni volta.
Questo conta di piu ai margini: quando una previsione sembra sorprendente, quando scatta un alert di anomalia, quando un dirigente contesta un numero in un report. In ogni caso, la risposta a "come hai ottenuto questo?" e una catena pulita e verificabile dalla definizione alla query al risultato. Quella catena e cio che guadagna la fiducia organizzativa nel sistema nel tempo.
Il rilevamento delle anomalie e il sistema che monitora continuamente le tue metriche e avvisa quando un valore esce dall'intervallo atteso. L'alert include la metrica coinvolta, la dimensione che sta guidando la deviazione, l'entita della variazione e una descrizione in linguaggio naturale della causa probabile basata su pattern storici.
L'ingegneria dietro e concettualmente semplice: per ogni metrica, addestriamo un modello di comportamento normale sui tuoi dati storici, impostiamo soglie di alert basate sulla tua tolleranza ai falsi positivi e poi confrontiamo ogni nuova osservazione con quel modello. In pratica, il lavoro interessante e nell'analisi delle dimensioni: non solo "i ricavi sono in calo" ma "i ricavi sono in calo ed e interamente spiegato da un picco nel tasso di rimborso nel UK, che e successo tre volte in precedenza quando una specifica categoria di prodotto aveva un problema di qualita."
Il tasso di falsi positivi conta. Un sistema di alert che scatta a giorni alterni insegna alle persone a ignorarlo. Calibriamo le soglie durante la fase Build usando i tuoi dati storici e la tua tolleranza dichiarata, e le rivisitiamo durante Operate al variare del business.
Una previsione e un'affermazione sul futuro, e l'incertezza dichiarata e la cosa piu utile che una previsione puo contenere. Una previsione a punto singolo ("i ricavi del prossimo trimestre saranno EUR 2,4M") e meno utile di un intervallo ("il modello concentra l'80% della massa di probabilita tra EUR 2,1M e EUR 2,7M, sulla base di questo errore di backtest"). L'intervallo e cio su cui pianifichi.
Le nostre previsioni sono costruite su tre discipline:
Cio che cambia l'accuratezza di una previsione e la qualita dei dati di input e la stabilita del processo sottostante, non la sofisticatezza del modello. Un'azienda che cambia la sua strategia di pricing ogni trimestre avra piu difficolta a prevedere i ricavi rispetto a una con una struttura di pricing stabile. Lo diciamo chiaramente durante l'analisi anziche promettere un'accuratezza che non possiamo garantire.
Sul backtest. La cifra di backtest che ti mostriamo nell'analisi gratuita e il mean absolute percentage error (MAPE) del modello su periodi trattenuti dei tuoi dati storici. E il numero che dovresti usare per giudicare se la previsione e utile per il tuo orizzonte di pianificazione, non una cifra che abbiamo scelto per abbellire il pitch.
Una volta che lo strato di metriche e in funzione e le query girano, generare un report esecutivo settimanale o mensile e un passaggio di composizione. Il sistema estrae le metriche chiave, le confronta con il periodo precedente e la previsione, segnala le anomalie scattate e scrive una breve narrativa che descrive cosa e successo, cosa tenere d'occhio e cosa mostra la previsione. Viene inviato a cadenza o su richiesta.
Il report non e scrittura creativa. E un riassunto strutturato dei dati, scritto in linguaggio naturale, con i numeri ancorati alle stesse definizioni che rispondono alle query interattive. Un manager puo leggerlo in due minuti e entrare nella review della leadership conoscendo i numeri senza aver costruito una presentazione.
Il valore qui non e che la narrativa sia scritta in modo brillante. E che e pronta alle 07:00 del lunedi anziche alle 11:00 dopo che qualcuno ha passato la mattina a raccoglierla. Il tempo liberato e reale e si accumula per ogni settimana in cui il sistema gira.
Il sistema si colloca sopra il tuo data warehouse esistente anziche sostituirlo. Ci colleghiamo a BigQuery, Snowflake e Postgres come target principali, con Redshift e Databricks disponibili per i team che gia girano su quelle piattaforme. Lo strato semantico di metriche e l'artefatto portabile: puo essere definito una volta e interrogato dall'interfaccia in linguaggio naturale, da uno strumento BI come Looker o Metabase tramite la loro API, o direttamente via SQL per i team che vogliono combinare entrambi gli approcci.
| Strato | Cosa fa | Cosa tieni |
|---|---|---|
| Warehouse (tuo) | Conserva i dati grezzi e trasformati | Piena proprieta, nessuna migrazione |
| Strato semantico di metriche | Definisce metriche, granularita, accesso, dimensioni | Definizioni YAML o SQL portabili |
| Query engine | Traduce le domande in SQL, le esegue, restituisce i risultati | Accesso API per integrazione altrove |
| Servizio alert e previsioni | Monitora le metriche, scatta alert di anomalia, esegue previsioni | Regole e soglie di alert configurate |
| Generatore di report | Compone e distribuisce il report esecutivo a cadenza | Template di report che possiedi e modifichi |
Nulla in questo stack richiede di spostare i tuoi dati. Il livello di query si collega al tuo warehouse con credenziali di sola lettura. I dati rimangono dove sono.
Il controllo degli accessi non e un ripensamento in uno strato di metriche ben costruito, fa parte dello schema. Ogni metrica e taggata con i ruoli che hanno il permesso di vederla. Il livello di query controlla quei tag a runtime: un utente che chiede di compensi esecutivi o PII dei clienti senza avere il ruolo giusto riceve una risposta che dice che la metrica esiste ma non e disponibile per lui, anziche un errore o una perdita di dati.
Il modello di governance che raccomandiamo e semplice: inizia con l'accesso piu ampio che e sicuro, misura quali query vengono eseguite e da chi, e restringi dove i dati mostrano un utilizzo non previsto. Un accesso eccessivamente restrittivo fin dal primo giorno uccide l'adozione prima che il sistema abbia la possibilita di dimostrare il suo valore.
Per le aziende soggette al GDPR o ad altri obblighi di residenza dei dati, la connessione al warehouse di sola lettura e l'assenza di una copia dei dati nella nostra infrastruttura sono i fatti chiave. Documentiamo il flusso di dati nel progetto e possiamo fornire l'architettura tecnica per una revisione di conformita.
Un sistema che nessuno usa non e un successo, per quanto buona sia la tecnologia sottostante. Monitoriamo due categorie di metrica durante la fase Operate:
| Metrica | Cosa ti dice |
|---|---|
| Tempo all'insight | Quanto tempo da una domanda a una risposta, rispetto alla baseline pre-sistema |
| Volume di query per team | Se il sistema viene usato e da chi, come indicatore anticipatore di adozione |
| MAPE previsione per metrica | Come evolve l'accuratezza della previsione man mano che il modello viene riaddestrato su piu dati |
| Precisione degli alert | La quota di alert di anomalia che ha portato a un'indagine reale (veri positivi) |
| Tasso di apertura dei report | Se i report esecutivi vengono letti, come proxy di utilita |
La metrica di adozione conta tanto quanto la metrica di accuratezza. Un sistema tecnicamente eccellente che viene aggirato in favore di un foglio di calcolo non ha creato valore. Rivisitimo entrambe le categorie nel report mensile Operate e aggiustiamo la configurazione quando una delle due tende nella direzione sbagliata.
Un breve elenco di approcci che sembrano ragionevoli e falliscono nella pratica:
La forma del lavoro: un'analisi gratuita per dimostrare l'approccio sui tuoi dati reali, una Build a scope fisso che connette il warehouse e rilascia lo strato di metriche, l'interfaccia in linguaggio naturale, gli alert di anomalia e il primo report esecutivo, poi una fase Operate che mantiene metriche e previsioni affidabili al variare del business e dei dati. Hai un unico punto di contatto, software che gira sulla tua infrastruttura e la misurazione per dimostrare che funziona.
AI Analytics e il nostro secondo servizio AI. La stessa metodologia che rende Document AI affidabile, partire da un pilot gratuito, misurare prima di impegnarsi, rilasciare un flusso di lavoro reale, possedere il risultato, e cio che rende AI Analytics affidabile. I servizi si completano: Document AI trasforma i documenti in dati, AI Analytics trasforma i dati in decisioni. Inizia con un'analisi gratuita.
Questo e l'intero motore. Il passo successivo e un'analisi gratuita sui tuoi dati: risposte reali alle tue vere domande, le anomalie rilevate, le previsioni backtestati, senza impegno.
Un'analisi gratuita sui tuoi dati reali, le metriche modellate e backtestati, le anomalie rilevate. Poi costruiamo lo strato che rende ogni risposta immediata.
Richiedi un'analisi gratuita