C'è una corsa agli strati semantici, agli strati di contesto e ai grafici della conoscenza per l'IA aziendale. Oggi, sembra che ogni grande fornitore di infrastrutture dati stia fornendo strumenti per questo scopo, tutti progettati per far sì che l'IA comprenda la tua attività e crei una mappa vivente di ciò che la tua azienda conosce. Questo è un lavoro importante e i progressi sono stati notevoli. Chiunque lavori a questo problema oggi sta costruendo su ciò che questi fornitori hanno già fatto. Ma nessuno di questi strumenti sta colmando la lacuna più grande, e questa è la più importante.
Dove vive realmente il contesto aziendale?
Il contesto vive nei data warehouse, nei database, nei document store, nei fogli di calcolo, nelle pagine di Confluence, nelle cartelle di SharePoint e nei sistemi legacy che sono dispersi in tutta l'organizzazione. Gli strumenti possono scansionare tutto ciò, ma il contesto più prezioso, più sfumato e più critico per le decisioni vive in un luogo che non possono raggiungere. Vive nelle menti degli esperti del settore della tua azienda.
Queste sono le persone che sanno perché il riconoscimento dei ricavi funziona diversamente per quella particolare linea di prodotti rispetto a un'altra. Il responsabile delle operazioni che comprende i modelli stagionali che rompono le aggregazioni ingenue, l'ufficiale di conformità che può dirti quali campi di dati portano vincoli normativi che non sono scritti da nessuna parte, e l'architetto dei dati che comprende intimamente che due tabelle con schemi quasi identici servono scopi aziendali completamente diversi a causa di una decisione di migrazione presa quattro anni fa.
Conoscenza di dominio tribale
In questi esempi, e in molti altri che esistono in ogni attività, questo non è metadata o documentazione. È conoscenza di dominio tribale, ed è l'input più importante per qualsiasi strato semantico che afferma di rappresentare la verità aziendale.
Uno strato semantico fornisce definizioni, consegnando una definizione governata a ogni strumento BI e agente AI, con risposte coerenti al momento della query. Ma queste definizioni non sono scritte dallo strato semantico. Di solito provengono dal team dati che scrive YAML, o sono importate dagli strumenti BI esistenti. In ogni caso, lo strato può essere buono solo quanto il contesto aziendale di chi lo ha autorizzato.
La parte difficile non è il codice
L'industria ha risposto implementando approcci centrati sullo sviluppatore che si basano su assistenti di codifica e copiloti per aiutare gli ingegneri dei dati a scrivere meglio YAML, SQL e logica di trasformazione. Questi approcci sono preziosi, ma presuppongono che la parte difficile sia scrivere il codice, quando in realtà è catturare ciò che l'azienda intende realmente con ogni numero prima che qualcuno scriva una riga di codice.
Un ingegnere dei dati può scrivere un modello dbt (data build tool) perfetto, ma se il vero significato dietro di esso non è stato catturato correttamente, se il grano della tabella dei fatti è stato assunto invece di essere validato, se la definizione della metrica è stata presa in prestito da un dashboard costruito su un malinteso, allora quel modello è precisamente sbagliato. Il codice è pulito e la logica è solida, ma la risposta aziendale è errata.
Per fare le cose per bene, è necessaria l'esperienza in tutti i settori. Dal lato tecnico, questo include architetti dei dati, team di sicurezza e responsabili delle politiche IT, tutti i quali comprendono i controlli di accesso, la sensibilità dei dati e le decisioni architettoniche che plasmano ciò che un modello può rappresentare. Dal lato aziendale ci sono i tuoi responsabili di dipartimento, proprietari di processi e specialisti di dominio che sanno cosa accade nella realtà operativa quando un ordine viene segnalato, un pagamento viene annullato o un cliente finisce in un segmento specifico. Non ciò che dice il nome della colonna. Non ciò che afferma la documentazione. Entrambi i gruppi devono partecipare. Questi sono i tuoi esperti, ma oggi gli strumenti chiedono a entrambi i gruppi di mettere ciò che sanno in YAML o SQL. Le politiche di sicurezza della tua azienda e le regole aziendali non dovrebbero dipendere dal fatto che qualcuno le traduca in codice.
Costruire in avanti partendo da ciò che gli esperti sanno
La maggior parte degli strumenti per strati semantici funziona all'indietro, estraendo significato da dashboard, cronologia delle query e progetti dbt che esistono già. Questo può essere utile se stai cercando di documentare ciò che hai, ma non ti dà ciò di cui hai bisogno ora.
Quando un'unità aziendale ha un nuovo requisito di reporting, un cambiamento normativo richiede nuove metriche o un'iniziativa strategica richiede un prodotto dati che non esiste ancora, non c'è alcuna cronologia di query e alcun dashboard da cui partire.
L'approccio giusto è l'ingegneria inversa. Qui, il processo inizia con i requisiti aziendali come definiti dagli esperti umani e poi costruisce in avanti verso la produzione. Con questo modello, l'IA intervista l'esperto, cattura ciò che sa, lo riconcilia con i dati effettivi e lo traduce in logica aziendale, codice di trasformazione e regole di validazione. L'output è un codice governato che il tuo strato semantico esistente può servire. L'esperto non scrive una riga di YAML.
Con questo modello di ingegneria inversa, gli esperti umani guidano il significato mentre l'IA gestisce la velocità, la scala e la traduzione meccanica nell'infrastruttura.
Lo strato di contesto per l'IA aziendale non è un problema tecnologico. È un problema di cattura della conoscenza. La conoscenza vive nei documenti, nei database, nei processi e nelle persone. Abbiamo costruito strumenti eccellenti per tutti loro, ma solo per le persone che possono scrivere codice. La maggior parte delle persone che detengono la conoscenza non può.