Le aziende stanno investendo miliardi di dollari in agenti e infrastrutture IA per trasformare i processi aziendali. Tuttavia, spesso vediamo un successo limitato nelle applicazioni del mondo reale perché gli agenti spesso non riescono a comprendere veramente dati, policy e processi aziendali.
Sebbene gestire bene le integrazioni con tecnologie come la gestione API, il protocollo di contesto del modello (MCP) e altre, garantire che gli agenti comprendano veramente il “significato” dei dati in uno specifico contesto aziendale è una storia diversa. I dati aziendali sono spesso archiviati in sistemi diversi in forme strutturate e non strutturate e devono essere analizzati attraverso una lente aziendale specifica del dominio.
Ad esempio, il termine “cliente” può riferirsi a un gruppo diverso di persone in un sistema CRM per le vendite rispetto a un sistema finanziario che potrebbe utilizzare questo tag per pagare i clienti. Un reparto può definire “prodotto” come uno SKU; un altro potrebbe rappresentarlo come: "prodotto" famiglia; un terzo come pacchetto di marketing.
I dati sulle “vendite di prodotti” variano quindi di significato senza relazioni e definizioni concordate. Prima che gli agenti possano combinare dati provenienti da più sistemi, devono comprendere rappresentazioni diverse. Gli agenti devono sapere cosa significano i dati nel contesto e come trovare i dati giusti per il processo giusto. Inoltre, i cambiamenti dello schema e i problemi di qualità dei dati nei sistemi durante la raccolta possono portare a una maggiore incertezza e agli agenti che non sanno come agire di fronte a tali situazioni.
Inoltre, la classificazione dei dati in categorie come PII (informazioni di identificazione personale) deve essere seguita rigorosamente per mantenere la conformità a standard come GDPR e CCPA. Ciò richiede che i dati siano etichettati correttamente e che gli agenti possano comprendere e rispettare tale classificazione. Vediamo quindi che è del tutto possibile creare una fantastica demo utilizzando gli agenti, ma metterla in produzione lavorando su dati aziendali reali è una storia completamente diversa.
Fonte della verità basata sull’ontologia
La creazione di soluzioni di agenzia efficaci richiede un’unica fonte di verità basata sull’ontologia. L’ontologia è la definizione operativa dei concetti, delle loro gerarchie e relazioni. Definisce i termini relativi ai domini aziendali, può aiutare a creare un’unica fonte di verità per i dati, acquisire nomi di dominio uniformi e applicare classificazioni ai domini.
Un’ontologia può essere specifica di un dominio (sanità o finanza) o specifica di un’organizzazione in base a strutture interne. Definire l’ontologia in anticipo richiede molto tempo, ma può aiutare a standardizzare i processi aziendali e creare una solida base per l’intelligenza artificiale delle agenzie.
L’ontologia può essere implementata utilizzando formati interrogabili comuni come il triple store. Regole aziendali più complesse con relazioni multi-hop possono utilizzare grafici di proprietà con tag come Neo4j. Questi grafici possono anche aiutare le aziende a scoprire nuove relazioni e rispondere a domande complesse. Ontologie come FIBO (Financial Industry Business Ontology) e UMLS (Unified Medical Language System) sono disponibili al pubblico e possono essere un ottimo punto di partenza. Ma questi spesso devono essere personalizzati per acquisire dettagli specifici di un’azienda.
Iniziare con l’ontologia
Una volta implementata, l’ontologia può rappresentare una forza trainante per gli intermediari istituzionali. Ora possiamo incoraggiare l’intelligenza artificiale a seguire l’ontologia e utilizzarla per esplorare dati e relazioni. Se necessario, possiamo avere uno strato intermedio che serve i dettagli di base dell’ontologia ed esplora i dati. In questa ontologia è possibile implementare regole e politiche aziendali affinché gli agenti possano rispettarle. Questo è un ottimo modo per radicare i tuoi rappresentanti e creare guardrail basati sul contesto aziendale reale.
Gli agenti progettati in questo modo e sintonizzati per seguire un’ontologia possono attenersi ai guardrail ed evitare le allucinazioni che possono essere causate dai grandi modelli linguistici (LLM) che li alimentano. Ad esempio, una policy aziendale potrebbe identificare se tutti i documenti associati a un prestito hanno flag di convalida non impostati come segue: "VERO," Lo stato del prestito dovrebbe essere mantenuto nello stato “in sospeso”. Gli agenti possono decifrare questa politica, determinare quali documenti sono richiesti e interrogare la knowledge base.
Ecco un esempio di applicazione:
(Forma originale dell’autore)
Come mostrato, abbiamo dati strutturati e non strutturati elaborati da un agente di document intelligence (DocIntel) che popola un database Neo4j basato sull’ontologia del dominio aziendale. Un agente di rilevamento dei dati in Neo4j trova i dati giusti, li interroga e li passa ad altri agenti che gestiscono l’esecuzione del processo aziendale. La comunicazione da agente ad agente avviene tramite un protocollo popolare come A2A (da agente ad agente). Un nuovo protocollo chiamato AG-UI (Agent User Interaction) può aiutare a creare schermate dell’interfaccia utente più generiche per acquisire il lavoro e le risposte di questi agenti.
Con questo metodo possiamo evitare allucinazioni costringendo gli agenti a seguire percorsi guidati dall’ontologia e a mantenere classificazioni e relazioni tra i dati. Inoltre, possiamo facilmente ampliare il sistema aggiungendo nuove entità, relazioni e politiche a cui gli agenti possono conformarsi automaticamente, e controllare le allucinazioni definendo regole per l’intero sistema piuttosto che per singole entità. Ad esempio, se un agente allucina un singolo “cliente”, possiamo facilmente rilevare questa anomalia e pianificare la sua eliminazione, poiché i dati collegati per il “cliente” allucinante non possono essere verificati nel data discovery. Ciò aiuta il sistema delegato a adattarsi al business e a gestirne la natura dinamica.
In effetti, un’architettura di riferimento come questa impone un certo onere al data discovery e ai database a grafo. Ma per una grande organizzazione, aggiunge i giusti guardrail e fornisce istruzioni agli agenti per gestire processi aziendali complessi.
Dattaraj Rao è un architetto di innovazione e ricerca e sviluppo. Sistemi persistenti.
Per saperne di più scrittori ospiti. Oppure considera di inviare il tuo! Dai un’occhiata al nostro istruzioni qui.
