Ontologia dei dati definita: il livello di contesto che manca ai tuoi agenti AI

Chiedi a cinque persone della stessa azienda cosa significa "fatturato" e c'è la possibilità che tu ottenga cinque risposte diverse, ognuna corretta nel proprio contesto e incompatibile con le altre. Finché un analista umano si è interposto tra questa ambiguità e il report finale, l'ambiguità è stata gestibile. È una conoscenza condivisa: il tipo di cosa che un buon analista sa e basta.

Gli agenti di AI non lo sanno. Ed è questo il problema.

Richard Tomlinson ha trascorso la sua carriera a riflettere sul livello di dati aziendali che non compare mai del tutto nello schema. In questa conversazione, spiega perché quel livello, l'ontologia, è improvvisamente diventato il pezzo di infrastruttura più importante che la maggior parte delle aziende non ha ancora costruito, perché l'ultima generazione di tentativi di crearlo si è in gran parte bloccata e cosa deve essere vero per un'ontologia affinché regga una volta che gli agenti iniziano a fare affidamento su di essa.

Perché gli agenti di AI hanno bisogno di un contesto aziendale che uno schema non può fornire?

Qual è l'assunto sui dati aziendali che gli agenti di AI stanno silenziosamente scardinando?

Richard Tomlinson: Per decenni, l'architettura dei dati aziendali ha operato su un assunto implicito: se organizzi i dati correttamente, un utente intelligente può capire cosa significano. Tabelle, schemi, cataloghi e dashboard forniscono la struttura, mentre gli esseri umani forniscono il contesto mancante. Un analista sa di quale delle cinque tabelle dei ricavi si fida il dipartimento Finance, cosa significa "cliente attivo" in questo trimestre o perché si dovrebbe usare un calcolo invece di un altro.

Gli agenti di AI scardinano questo assunto perché potrebbe non esserci alcun essere umano esperto tra i dati e la decisione. L'agente deve scoprire il significato da solo. Dare a un agente l'accesso a più dati non risolve il problema. Ha bisogno del contesto aziendale che gli esseri umani hanno storicamente custodito nella propria mente: definizioni, relazioni, calcoli, fonti autorevoli, competenze e autorizzazioni. Ecco perché il contesto aziendale sta diventando importante per l'architettura di AI tanto quanto i dati stessi.

Cos'è un'ontologia dei dati e in cosa differisce da uno schema?

Come definisci un'ontologia dei dati e cosa cattura che uno schema non potrebbe mai fare?

Richard Tomlinson: Uno schema descrive come sono strutturati i dati. Un'ontologia descrive cosa significano quei dati nel contesto aziendale. Collega asset tecnici come tabelle, metriche e query a concetti di business: definizioni, relazioni, calcoli, fonti di competenza e regole su come interpretare tali concetti.

Uno schema potrebbe dire a un agente che una tabella contiene net_rev, gross_rev e recog_rev. Un'ontologia può aiutarlo a capire quale definizione di ricavo si applica alla domanda, quale fonte il dipartimento Finance considera autorevole, come viene normalmente eseguito il calcolo e se la persona che lo chiede è persino autorizzata ad accedervi. Lo schema è la mappa dei dati. L'ontologia è più simile a una mappa di come l'organizzazione comprende e utilizza tali dati.

Perché i layer semantici e i knowledge graph hanno faticato a scalare?

I layer semantici e i knowledge graph aziendali promettevano "un'unica versione della verità" anni fa e sono diventati per lo più software inutilizzati. Cosa deve essere vero per un'ontologia affinché non subisca la stessa sorte?

Richard Tomlinson: Smorzerei leggermente questa premessa. I layer semantici e i knowledge graph hanno offerto un valore reale, in particolare per i concetti critici per il business. Il problema sorge quando le organizzazioni cercano di modellare manualmente l'intera azienda. La conoscenza aziendale cambia troppo rapidamente ed è diffusa in troppi luoghi. La logica importante può trovarsi in una dashboard, in una query SQL, in un notebook, in un ticket o semplicemente nel modo in cui un team lavora abitualmente. Nessun team centrale può documentare tutto questo e mantenerlo aggiornato.

Il modello più scalabile consiste nel "modellare la testa e apprendere la coda". Gli esseri umani dovrebbero definire e gestire esplicitamente il piccolo insieme di concetti che non possono essere errati, come ricavi, regole di conformità e KPI principali. L'ontologia più ampia dovrebbe apprendere continuamente la coda lunga dal modo in cui opera l'organizzazione, pur continuando a classificare la conoscenza in base all'autorevolezza e rispettando la governance. Se il mantenimento dell'ontologia diventa un progetto di modellazione dei dati aziendali a sé stante, finirà per rimanere indietro rispetto al business che dovrebbe descrivere.

Cosa succede quando un agente di AI non ha il contesto aziendale?

Puoi descrivere un momento in cui un agente ha fornito una risposta errata ma sicura perché privo di un reale contesto aziendale? Cosa l'ha resa così convincente che qualcuno si è quasi fidato?

Richard Tomlinson: Un esempio tratto dai nostri test interni è stato chiedere a diversi sistemi di AI di preparare un briefing per un imminente Product Advisory Board. Un assistente ha prodotto un report rifinito quasi immediatamente, affermando che stavano partecipando 24 clienti. Includeva il tipo di dettagli che ci si aspetterebbe in un brief esecutivo, quindi a prima vista la risposta sembrava credibile. Quando abbiamo chiesto al sistema di spiegare da dove provenisse il numero 24, ha ammesso di averlo inventato di sana pianta.

Questo è il pericoloso scenario di errore. La risposta non è palesemente assurda. È fluida, specifica e presentata insieme a informazioni legittime. Il problema è che il modello non sa quale fonte interna contenga la ground truth, quindi colma il divario con l'inferenza. Nell'AI aziendale, una risposta plausibile può essere più pericolosa di nessuna risposta.

Come capire se alla tua organizzazione manca un layer di contesto?

Se un responsabile dei dati volesse sapere se la propria organizzazione ha questo problema, cosa dovrebbe cercare? C'è un segnale rivelatore che indica la mancanza del layer di contesto?

Richard Tomlinson: Il segnale più chiaro è la frequenza con cui una semplice domanda di business richiede l'intervento di una persona esperta per tradurla prima che i dati possano fornire una risposta. Se qualcuno chiede: "A quanto ammontavano i ricavi lo scorso trimestre?" e l'analista risponde immediatamente con "Quali ricavi?" o "Per quale business unit?", quel passaggio di traduzione è il contesto aziendale. Lo stesso vale quando gli analisti sanno di quale dashboard fidarsi, quale tabella è deprecata o quale definizione usa un team rispetto a un altro.

Altri segnali: dashboard duplicate, definizioni di KPI contrastanti, analisti che rispondono ripetutamente alle stesse domande e utenti aziendali che diffidano del self-service perché strumenti diversi restituiscono risposte diverse. Spesso il problema di fondo non è la mancanza di dati da parte dell'azienda. È che la conoscenza necessaria per interpretare i dati risiede in una conoscenza condivisa, in artefatti scollegati e in singoli esperti, piuttosto che in un layer di contesto che l'AI possa utilizzare in modo affidabile.

Quanto costa oggi alle aziende la mancanza di contesto aziendale?

Quanto costa questo alle aziende oggi, ancor prima di aver distribuito gli agenti su larga scala? Decisioni più lente, lavoro duplicato degli analisti, fiducia compromessa nelle dashboard?

Richard Tomlinson: Tutto quanto sopra. Le organizzazioni pagano già una "tassa sul contesto". Gli analisti passano il tempo a riscoprire definizioni, individuare fonti autorevoli, riconciliare report contrastanti e spiegare la logica aziendale che esiste da qualche altra parte nell'organizzazione. Team diversi ricreano la stessa semantica all'interno di diversi strumenti di BI. Gli utenti aziendali aspettano gli analisti perché il self-service smette di funzionare non appena la domanda diventa complessa.

L'AI rende questo problema esistente più visibile. Senza contesto, gli agenti ripetono gran parte dello stesso processo di scoperta a livello computazionale: esplorano schemi, leggono documenti, provano query e riconsiderano ipotesi. Ciò crea ulteriore latenza, consumo di token e costi senza garantire la risposta corretta. Il costo maggiore, tuttavia, è la fiducia. Una volta che gli utenti scoprono che una dashboard o un assistente di AI può produrre con sicurezza un numero errato, tornano a chiedere a un essere umano.

Cosa cambia quando ci si può fidare degli agenti di AI per agire, e non solo per generare report?

Cosa cambia per un'azienda nel momento in cui ci si può fidare dei suoi agenti per agire, e non solo per generare report?

Richard Tomlinson: Il valore dell'AI cambia radicalmente. La reportistica fa risparmiare il tempo necessario per trovare una risposta. Un'azione fidata può eliminare interi passaggi da un flusso di lavoro. Un agente può calcolare i numeri più recenti, preparare la rassegna aziendale settimanale, esaminare un'anomalia, aggiornare un ticket, contattare le persone giuste e ripetere questo processo ogni lunedì senza che qualcuno debba coordinare manualmente ogni passaggio.

Questo cambia anche l'economia delle competenze. Un esperto di finanza, un product manager o un responsabile delle operazioni può codificare metodi critici una sola volta e combinarli con un agente che comprende il contesto aziendale più ampio. La loro esperienza può quindi essere applicata a molte più decisioni e flussi di lavoro di quanti il singolo individuo potrebbe supportare personalmente. Il requisito chiave è "fidata": l'autonomia diventa utile solo quando l'agente comprende l'azienda abbastanza bene, ed è governato in modo abbastanza rigoroso, da agire entro i limiti appropriati.

Qual è il modo giusto per iniziare a costruire un'ontologia dei dati?

Qual è il modo sbagliato di iniziare, l'istinto che porta a un'altra iniziativa destinata a rimanere inutilizzata, rispetto alla prima mossa corretta?

Richard Tomlinson: L'istinto sbagliato è: "Prima di poter usare l'AI, dobbiamo modellare l'intera azienda". Questo trasforma il contesto aziendale in un progetto di documentazione pluriennale. Quando ogni termine, relazione e regola è stato modellato, gran parte del modello è già obsoleta.

L'approccio migliore consiste nel partire dalle conoscenze già in vostro possesso. Gestite il piccolo numero di concetti che non possono assolutamente essere errati, come i KPI critici e le definizioni di business, quindi lasciate che il livello di contesto più ampio apprenda da dashboard, query, notebook, documenti e attività operative che i vostri team stanno già producendo. Non richiedete all'azienda di documentare tutto prima che l'AI possa diventare utile. Lasciate che l'utilizzo effettivo aiuti a costruire e a migliorare continuamente la comprensione del business utilizzata dagli agenti.

In che modo i data leader dovrebbero ripensare l'architettura dei dati per gli agenti AI?

In che modo un data leader dovrebbe pensare diversamente alla propria architettura dei dati ora che il contesto, e non solo la struttura, è l'elemento su cui vale la pena investire?

Richard Tomlinson: Per anni, l'architettura dei dati si è concentrata fortemente sul rendere i dati accessibili, affidabili e governati. Questi aspetti rimangono essenziali, ma l'AI aggiunge un altro requisito: l'architettura deve anche rendere accessibile il significato aziendale. Un agente deve sapere non solo dove risiedono i dati, ma anche come l'organizzazione li interpreta, quali relazioni contano, quali definizioni sono autorevoli e quali prove le supportano.

Ciò significa che gli asset che in precedenza erano visti principalmente come infrastruttura di governance o di analytics diventano asset strategici per l'AI. Definizioni delle metriche, documentazione, lineage, certificazioni, pattern di utilizzo e glossari aziendali insegnano collettivamente all'AI come funziona l'azienda. L'architettura emergente non è quindi solo un piano dati più un modello AI. Ha anche bisogno di un livello di contesto condiviso in grado di offrire la stessa comprensione del business a molti agenti e applicazioni.

L'ontologia dei dati migliora effettivamente l'accuratezza degli agenti?

Richard Tomlinson: Un'ontologia da sola non rende magicamente accurato un agente. Ciò che migliora l'accuratezza è fornire all'agente il contesto corretto e autorevole nel momento in cui elabora il ragionamento. Se l'ontologia è in grado di indicare all'agente quale definizione applicare, dove risiedono i dati attendibili e quali relazioni o calcoli sono importanti, l'agente dedicherà meno tempo a tirare a indovinare ed esplorare percorsi errati.

Abbiamo prova di questo effetto con Genie Ontology, il livello di contesto automatico alla base di Genie One e Genie Agents di Databricks. In un benchmark interno di Databricks che ha utilizzato 28 domande reali di analisi dei dati aziendali, Genie con Ontology ha risposto correttamente all'84,5% delle domande al primo tentativo. Il più forte agente di codifica generico nella stessa valutazione ha ottenuto un punteggio del 52,4%. Genie è stato anche circa due volte più veloce di quell'agente. Si tratta di un benchmark interno piuttosto che di una garanzia di accuratezza universale, ma illustra il principio fondamentale: un migliore contesto aziendale può contare tanto quanto, o più di, dare semplicemente al modello più tempo per ragionare.

È necessario creare un'ontologia formale da zero?

Richard Tomlinson: No, e richiederlo ricreerebbe il problema di scalabilità che stiamo cercando di risolvere. La maggior parte delle aziende ha già creato una grande quantità di comprensione del business. Esiste nelle definizioni delle metriche, nei dati certificati, nelle dashboard, nelle query, nei notebook, nella documentazione e nei modi ricorrenti in cui i team utilizzano tali asset.

L'obiettivo dovrebbe essere quello di preservare il controllo umano sui concetti più importanti, apprendendo automaticamente gran parte della "coda lunga". Con Genie Ontology, ciò significa modellare esplicitamente i KPI critici e i termini di business, mentre il livello dedotto apprende definizioni, regole, relazioni e fonti autorevoli aggiuntive dal lavoro esistente. Si ottiene valore dalle conoscenze che l'organizzazione già possiede, invece di aspettare il completamento di un progetto di ontologia separato.

Quale ruolo svolge la governance in un agente AI basato su ontologia?

In che modo la governance si inserisce in un agente basato su ontologia?

Richard Tomlinson: La governance ha due compiti. Quello ovvio riguarda l'accesso: l'ontologia non dovrebbe mai diventare una porta sul retro per aggirare le autorizzazioni esistenti. Se un utente non può accedere alle informazioni di origine, l'agente non dovrebbe essere in grado di recuperare il contesto derivato da esse. Con Genie Ontology, le autorizzazioni vengono applicate durante il recupero, utilizzando la governance delle fonti sottostanti, incluso Unity Catalog. Due dipendenti possono quindi porre la stessa domanda e ricevere risposte diverse in base a ciò che ciascuno è autorizzato a vedere.

Il secondo compito è altrettanto importante: la governance aiuta l'AI a capire di cosa fidarsi. Certificazione, definizioni autorevoli, lineage, utilizzo, competenza e provenienza delle fonti diventano segnali che aiutano a distinguere la definizione ufficiale dei ricavi da un calcolo estemporaneo creato da qualcuno sei mesi fa. Nell'era dell'AI, la governance non riguarda più solo il controllo dei dati. Fa sempre più parte del meccanismo che insegna all'AI quale conoscenza aziendale merita autorevolezza.

Perché l'ontologia dei dati sta diventando un'infrastruttura AI?

La parola "ontologia" un tempo apparteneva ai team di modellazione semantica e ai dibattiti sulla tassonomia. Sta rapidamente diventando qualcosa di più simile a un'infrastruttura: il livello che decide se la risposta di un agente riflette il modo in cui l'azienda funziona realmente o se è solo un'ipotesi plausibile travestita da tale. Le organizzazioni che trattano il contesto come qualcosa da governare e apprendere continuamente, e non da documentare una volta sola per poi lasciarlo invecchiare, saranno quelle i cui agenti potranno essere considerati affidabili per agire, non solo per riferire.

Scoprite in che modo l'ontologia Genie ancora le risposte dell'AI al reale significato del vostro business. Esplorate Genie.

Leggi anche:

• Presentazione di OfficeQA: un benchmark per il grounded reasoning end-to-end
• Presentazione di OfficeQA Pro V2: un nuovo benchmark per l'enterprise grounded reasoning
• Pagina del prodotto Genie One
• Panoramica di Genie Ontology

(Questo post sul blog è stato tradotto utilizzando strumenti basati sull'intelligenza artificiale) Post originale