Ontologie aziendali portatili per agenti IA

Il termine «ontologia» è ormai di moda. Perché? Gli agenti, e gli LLM che li alimentano, hanno bisogno di un contesto aziendale pertinente.

Prima di acquistare un’ontologia, chiedete al fornitore: «Quando l’ontologia rappresenta in modo errato la nostra azienda, come possono correggerla i nostri dipendenti e da cosa dipenderemo ancora da voi?». La risposta vi dirà molto su quale modello dell’azienda state scegliendo. Indica anche la posta in gioco più ampia: la vostra capacità di migliorare quel modello man mano che l’azienda cambia e di mantenere utile tale investimento anche se cambiate piattaforma.

È utile distinguere un’ontologia da un grafo della conoscenza, anche se spesso i due concetti si sovrappongono.

Ontologia: quali tipi di cose esistono, cosa significano le relazioni e quali regole si applicano. Attrezzature, componenti, team, ruoli, processi. Per esempio, un’ontologia può definire un tipo «Attrezzatura» e una relazione «Contiene» con un «Componente». Un grafo della conoscenza può quindi affermare: «La pompa P-101 contiene la guarnizione S-7»: due entità specifiche e la relazione che le collega.

Immaginate di dire a un agente: «Calcola la crescita delle vendite a parità di punti vendita, ma mostrami un confronto affiancato: prima includendo tutti i negozi, poi escludendo quelli aperti da meno di 2 anni; quindi suddividi entrambe le parti in domestico, internazionale e combinato».

Questa richiesta dipende da dettagli che un agente non può indovinare:

• quali negozi esistono e quando hanno aperto
• dove si trovano
• la definizione interna di «vendite a parità di punti vendita»

Una policy potrebbe escludere i negozi finché non sono rimasti aperti per un anno; il gruppo richiesto dei due anni aggiunge un ulteriore filtro. Anche in quel caso, si confrontano i mesi di calendario non appena un negozio soddisfa il requisito oppure lo si include solo dopo un intero esercizio fiscale precedente?

L’ontologia deve collegare quei negozi alla policy che disciplina il calcolo. Trovare fatti correlati è utile; applicare la regola giusta è ciò che rende utile la risposta.

Prima di rispondere a una domanda, un agente può usare le relazioni del grafo per recuperare il contesto pertinente. E non c’è da stupirsi che siano utili, dato che i domini della conoscenza possono diventare facilmente molto complessi.

Figura 1: Grafo dei modelli SysML pubblici combinati: TMT Thirty Meter Telescope (Open-MBEE/JPL, Apache-2.0), CubeSat System Reference Model (© 2022 INCOSE SSWG & OMG SDTF, CC BY 4.0), Architecting Spacecraft with SysML (Friedenthal & Oster, BSD-2-Clause), oltre a contenuti fittizi della costellazione MDC e specifiche pubbliche (IS-GPS-200, IS-GPS-705, GSFC-STD-7000B). Visualizzato con Kamiwaza Kaizen.

Ma l’estrazione può anche codificare errori. I team possono usare nomi diversi per la stessa entità, creando duplicati. Le fonti possono essere in disaccordo o diventare obsolete. Anche una fonte affidabile può essere interpretata male da un LLM. Dare a questi errori un’apparenza autorevole non li rende meno pericolosi.

Questi rischi aumentano quando un modello dell’azienda diventa un sistema che agisce su di essa. Una relazione errata può quindi innescare un’azione sbagliata, non soltanto produrre una risposta sbagliata.

I rischi dei prodotti per le ontologie

Per prima cosa, diffidate dei modelli rigidi. Con il pretesto di offrire una soluzione «pronta all’uso», un fornitore potrebbe rendere le proprie entità elementi di prima classe, limitando al contempo le possibilità delle vostre. La personalizzazione non basta se i tipi personalizzati perdono funzionalità di ricerca, convalida o esecuzione di azioni.

In secondo luogo, cercate un percorso che porti dalla scoperta alla governance. Uno strumento dovrebbe consentirvi di avviare un grafo a partire da ciò che vede un LLM e poi convalidarlo rispetto a vincoli espliciti. Dovreste poter sottoporre le eccezioni all’attenzione di persone e conservare le conoscenze esplorative senza considerarle dati aziendali approvati.

Il rischio maggiore è vincolare i processi aziendali a una piattaforma da cui non potete andarvene. La vostra ontologia rappresenta la vostra azienda: le sue conoscenze, i suoi processi e le sue relazioni. L’investimento nella curatela e nella logica aziendale dovrebbe restare utile anche se cambiate strumenti. Perché un fornitore dovrebbe poterlo tenere sotto chiave?

Quando sono utili gli embedding dei grafi

Quando i grafi della conoscenza diventano molto grandi, può valere la pena scegliere uno strumento o un fornitore che supporti gli embedding dei grafi. Sono strettamente imparentati con gli embedding semantici alla base di molte applicazioni RAG. Ci sono due vantaggi utili da considerare.

Per prima cosa, pochi passaggi in un grafo densamente connesso possono restituire troppe entità da elaborare. Apprendendo rappresentazioni numeriche di entità e relazioni, gli embedding offrono un altro modo per individuare le parti pertinenti del grafo. Per l’attività giusta, questo può essere più efficiente che percorrere il grafo.

In secondo luogo, i modelli di embedding possono classificare le relazioni mancanti candidate. Lo stesso apprendimento può rivelare schemi ricorrenti negli attributi e nelle relazioni tipici di un tipo di entità, contribuendo a costruire un grafo più completo.

Perché puntare a miglioramenti progressivi

Per decidere del vostro futuro, evitare il vincolo a un fornitore e modellare la vostra azienda reale anziché una sua caricatura dettata da un fornitore, da dove potete cominciare senza un esercito di ingegneri dedicati sul campo? È qui che, a mio avviso, l’IA moderna dà il meglio di sé, se gli strumenti consentono di passare dalla scoperta alla verifica.

Per prima cosa, usa strumenti automatizzati per individuare ed estrarre le informazioni. Dai documenti aziendali, dalle policy, dalle email o dai messaggi su Slack puoi ricavare una prima rappresentazione di un dominio. L’aspetto fondamentale è che non puoi considerarla attendibile finché non è stata verificata.

La verifica è il secondo passaggio. Gli strumenti devono offrire un percorso agevole dai dati candidati estratti ad affermazioni fondate sulle fonti e a conoscenze convalidate da una persona responsabile o da un sistema autorevole. Conserva la fonte di ogni affermazione.

Mantenere le informazioni aggiornate è un lavoro continuo. La procedura per gestire un ticket di assistenza, o la risposta alla domanda «quanti negozi ci sono nel New Jersey?», potrebbe non essere oggi la stessa di tre anni fa. Ma aggiornare le conoscenze attuali non deve cancellare la realtà di ieri. La data in cui un fatto è stato registrato può differire dal periodo in cui era valido; un’ontologia utile deve permettere di fornire sia risposte aggiornate sia una ricostruzione storica accurata. Qualcuno deve comunque mantenere aggiornate queste conoscenze.

L’ambito può essere vastissimo. Inizia con un corpus più piccolo, mappa un dominio utile e costruisci gradualmente un quadro completo, creando valore lungo il percorso.

L’assistenza clienti è un ambito utile da cui partire: chiamate in entrata, email, un sistema di gestione dei ticket, risoluzioni automatizzate, un team di assistenza in grado di rispondere ai clienti e una procedura per inoltrare i bug effettivi al reparto di ingegneria. Collega le conoscenze alle azioni e mette in luce gli stessi rischi e vantaggi in un ambito gestibile.

Il Common Service Data Model di ServiceNow illustra il vincolo. Nel suo white paper sul CSDM 5 si legge: «Senza questi dati nelle tabelle previste, potresti non ottenere tutto il valore della piattaforma ServiceNow AI». L’avvertimento impone di per sé un vincolo progettuale e operativo: adottare il modello del fornitore oppure accettare un rischio. E se questo significasse cercare di infilare un piolo rotondo nel loro foro quadrato?

Ora supponiamo che una piattaforma ontologica offra anche acquisizione dei dati, trasformazioni, azioni e regole aziendali. Potresti riuscire a esportare entità, attributi e relazioni. Ma puoi trasferire anche le trasformazioni e le pipeline di azioni che apportano modifiche ai tuoi database, chiamano webhook e producono altri effetti collaterali? Le integrazioni strettamente accoppiate possono lasciare l’azienda stessa vincolata al fornitore.

Perché la flessibilità è importante oggi

Il software sta conquistando il mondo e l’IA sta conquistando il software. Man mano che i team usano l’IA sia per creare software sia per alimentarlo, una quota crescente della logica aziendale può finire legata a queste piattaforme. Ogni automazione utile può diventare anche un’ulteriore dipendenza in caso di migrazione. Lasciare che un fornitore si frapponga tra te e la tua agilità è pericoloso.

Conclusioni

È un momento straordinario per essere vivi! Non c’è da stupirsi che si stiano esplorando le ontologie per fornire contesto agli agenti. Estendere quel contesto ai processi e alle integrazioni può creare valore concreto. Torniamo alla domanda iniziale. Le correzioni del tuo personale dovrebbero rendere il modello una rappresentazione più fedele della tua azienda. Questa comprensione accumulata è troppo preziosa per rischiare di perderla quando cambi piattaforma. Ed è anche un pessimo momento per ritrovarsi senza vie d’uscita.