Enterprise AI Governance

Come utilizzare e governare correttamente i nuovi strumenti messi a disposizione dall’intelligenza artificiale in contesti enterprise

Industries:

Finance & Insurance - Retail & GDO - Transportation - Energy & Utility - Life Science - Industrial

Solutions:

AI - Data Platform - Data Governance

Contesto

Con l’esplosione dell’Intelligenza Artificiale (AI) che si è avuta negli ultimi anni, dovuta anche grazie allo sviluppo dell’Intelligenza Artificiale generativa e alla pubblicazione sul mercato di applicazioni che sfruttano i Large Language Models (LLM), si è visto un incredibile aumento della percezione delle potenzialità di questi strumenti da parte di un pubblico sempre maggiore.

Sfruttare a pieno le funzionalità messe a disposizione dall’Intelligenza Artificiale in un contesto enterprise significa analizzare quali sono i casi d’uso implementabili, realizzando delle soluzioni che possano portare ad un miglioramento nell’efficienza e nell’efficacia di interi processi aziendali. Contestualmente è però necessario tenere conto di una serie di rischi e criticità correlate all’utilizzo di queste tecnologie.

L’approccio di AI Governance proposto si basa sull’esperienza pluriennale di Quantyca nell’ambito del Data & Metadata Management. A partire dalla sua fondazione nel 2009, spaziando dal mondo della Business Intelligence alla Data Integration, fino ad arrivare alla gestione di piattaforme Cloud, Quantyca ha sempre dedicato una particolare attenzione non solo all’implementazione delle progettualità, ma anche alla governance del dato e alla gestione dei metadati.

Siamo convinti che molte delle attenzioni e delle policy definite nella gestione dei dati strutturati vadano applicate anche nel contesto delle progettualità legate all’Intelligenza Artificiale, dove stanno assumendo sempre più valore anche le informazioni contenute all’interno di dati non strutturati o semi-strutturati (es: documenti di procedure aziendali, FAQ sito istituzionale, contenuti multimediali, etc).

In particolare, nella definizione e nello sviluppo di soluzioni che sfruttano l’Intelligenza Artificiale, Quantyca garantisce un’attenzione particolare ai seguenti principi:

Approccio data-centrico

I dati sono prodotti e vanno considerati a tutti gli effetti asset aziendali; come tali vanno dunque gestiti. Questo patrimonio aziendale deve essere valorizzato e condiviso, per essere sfruttato in svariati casi d’uso.

Platform thinking

La nostra visione ruota attorno ad una piattaforma unica, in cui convergono le integrazioni analitiche e dei servizi. L’interoperabilità degli elementi che la caratterizzano, in particolare dei data product, è per noi fondamentale.

Data Governance by design

La governance è parte integrante dei progetti a cui lavoriamo. La concepiamo come processo proattivo, sostenibile e misurabile.

Forti di questi principi, e dell’esperienza di consulenza strategica condotta negli anni, Quantyca supporta e guida le aziende nell’implementazione di una strategia AI basata sui seguenti aspetti:

Quantyca-AI-strategy

Punti critici

I principali aspetti da tenere in considerazione in un contesto enterprise quando si utilizzano le nuove tecnologie messe a disposizione dall’Intelligenza Artificiale sono le seguenti:

Gestione operativa

A causa delle diverse funzionalità per le quali è possibile sfruttare un Large Language Model, i contesti di utilizzo a livello enterprise sono molteplici. Tra i vari ipotizzabili i più interessanti sono sicuramente quelli che sfruttano la capacità dei Large Language Models di comprendere il contesto funzionale e di generare informazione strutturata (Named Entity Recognition) o di interagire con strumenti esterni (Tool Calling). In generale in questi contesti è possibile efficientare notevolmente attività che rientrano nella sfera del Data Management, come ad esempio eseguire ingestion automatica a partire da immagini/scansioni di documenti, oppure introdurre delle interfacce di utilizzo per sistemi esistenti che sfruttano il linguaggio naturale, come ad esempio chatbot o assistenti vocali.

Il numero di parametri che compongono un Large Language Model, e conseguentemente la capacità computazionale richiesta per addestrarlo, sono tali da impedire a chiunque di svolgere questa operazione. Sono pochi i player che possono permettersi, tecnologicamente ed economicamente, di realizzare modelli di questo tipo. La qualità del modello utilizzato è qualcosa di insito nel modello stesso, e dipende fortemente dal tipo di addestramento e di “instruction fine-tuning” che ha subito il modello e dai dati che sono stati utilizzati per l’addestramento stesso.

Ma è quindi impossibile modificare il comportamento di un LLM? Devo utilizzarlo così come viene messo a disposizione da un vendor o come lo trovo nel momento in cui viene reso disponibile pubblicamente?

In realtà sono due gli aspetti fondamentali per settare o modificare il comportamento di un LLM: l’ingegnerizzazione del prompt ed il fine-tuning.

La gestione operativa in un contesto enterprise di tali modelli deve dunque concentrarsi sui seguenti punti:

• Come gestisco al meglio i prompt generati dai miei utenti?
• Come posso raccogliere i dati necessari per svolgere al meglio l’attività di fine-tuning di un modello?

Governance

Esattamente come avviene nel contesto del Data Management, anche per quanto riguarda l’utilizzo dei Large Language Models sono presenti importanti aspetti legati alla Governance.

I rischi a cui ci si può esporre nell’impiego di questi strumenti possono essere molteplici:

Data Ownership

Quando utilizzo un Large Language Model di un provider terzo sto in realtà utilizzando delle API, oppure un’applicazione costruita per permettere agli utenti di utilizzare il modello stesso. Un esempio noto è l’applicazione ChatGPT, che permette di interagire con i modelli GPT-x. Il tema della Data Ownership riguarda le modalità di impiego dei dati sottoposti dagli utenti al provider del servizio, e in questo caso specifico, dunque, come vengono utilizzate le conversazioni che gli utenti hanno con il chatbot.

Per migliorare la qualità dei modelli è infatti essenziale fornire sempre più informazione testuale di qualità durante il training. Le conversazioni, essendo già strutturate ed implicitamente “validate” dagli utenti finali, ne costituiscono un ottimo esempio. A questo si aggiunge solitamente la possibilità di dare un riscontro alla risposta generata dal modello, anche solo indicando se risulta positiva o negativa.

Nel momento in cui utilizzo questi sistemi in contesti a basso rischio o in una modalità “ludica” non corro particolari rischi. In un contesto enterprise devo però tenere a mente una serie di aspetti.

Poniamo l’esempio di un utilizzo non regolamentato di un Large Language Model, utilizzato per il semplice scopo di riassumere un documento aziendale molto verboso. Per fare questo l’utente sottomette parti del documento al servizio che sta utilizzando, e chiede semplicemente al modello di riassumerne il contenuto. Se nel documento sono inserite informazioni rilevanti e con livello di distribuzione limitata, potrei incorrere nel rischio di rendere tali informazioni pubbliche. Il provider del Large Language Model potrebbe infatti utilizzare la conversazione dell’utente per futuri cicli di training del modello, andando ad inserire le informazioni sensibili all’interno del proprio training set, e dunque potenzialmente utilizzandole per fornire risposte in futuro ad altri utenti.

BIAS

Come già detto in precedenza, la qualità dei Large Language Model dipende fortemente dai dati e dalle informazioni utilizzate per eseguirne l’addestramento. La mole dei dati testuali necessari per addestrare i modelli sta rapidamente diventando il vero collo di bottiglia: i dataset utilizzati sono direttamente presi da tutto il testo disponibile pubblicamente su internet e sono composti da miliardi di sample.

Ma non tutto il testo pubblico presente su internet può essere considerato di qualità. Senza contare che si potrebbero considerare delle fonti che presentano una qualche sorta di bias cognitivo.

Poniamo l’esempio di un addestramento di modello condotto utilizzando mille documenti testuali con un sentiment neutrale rispetto ad un determinato tema politico, ed un solo documento che si esprime a favore di una certa tesi rispetto a quel tema. Dato che i modelli hanno una natura prettamente statistica nella generazione del testo, quell’unico documento non inciderà e non porterà alcun bias nelle risposte fornite. Diverso è il caso in cui la percentuale di documenti che presentano tali bias diventa maggiore.

Poiché i training-set e le modalità di addestramento sono una delle proprietà intellettuali dei vendor che mettono a disposizione questi modelli, e solo in pochi casi lodevoli ne viene fatta disclosure al pubblico, un utente deve fidarsi del fatto che il testo utilizzato per l’addestramento sia di qualità e non contenga tali bias cognitivi. Il rischio che questo avvenga rimane però presente e studi condotti stanno dimostrando che in alcuni casi è possibile determinare una preferenza dei modelli verso la generazione di risposte con una certa propensione politica, di genere, di religione, …

Se si utilizzano queste soluzioni per generare testo reso poi visibile agli utenti finali bisogna dunque tenere ben presente la necessità di assicurarsi che questo testo non contenga informazioni discriminatorie, stereotipate o che presentino bias cognitivi di qualche tipologia.

Allucinazioni

Per allucinazioni, nel contesto dei Large Language Model, si intende la generazione di testo coerente con la domanda posta dall’utente, ma che non ha in alcun modo un riscontro nella realtà. In questi casi il modello genera informazioni che non si basano sui dati su cui è stato addestrato e che non seguono alcun pattern appreso. Questo porta a risultati imprecisi o privi di senso.

Un esempio può essere la richiesta al modello di fornirmi dei titoli di paper scientifici che dimostrano che la terra è piatta. Anche se il modello non ha mai ricevuto in input durante il training dei documenti simili, può tuttavia conoscere il “come” è solitamente strutturato il titolo di un paper scientifico, e in base alla richiesta potrebbe dunque inventare dei titoli coerenti e formalmente validi sul tema. Ovviamente questa informazione sarebbe del tutto errata.

In generale, nell’utilizzo di un LLM, va sempre tenuta in considerazione la natura statistica che ne sta alla base. L’intelligenza che dimostrano tali strumenti è in realtà soltanto simulata e deriva da un unico task molto semplice: stimare qual è la parola della frase successiva più probabile data la frase passata in input. Un Large Language Model può essere più o meno bravo a svolgere questo task, ma a prescindere da questo, proprio per la modalità con la quale i modelli sono costruiti, il rischio di allucinazione rimane sempre presente.

Soluzione

Per facilitare il più possibile l’operatività verso le nuove soluzioni di Intelligenza Artificiale e governare e controllare come tali strumenti vengono utilizzati, l’aspetto fondamentale da tenere in considerazione è la gestione dei metadati.

L’aspetto in comune che caratterizza l’esperienza fatta nel campo del Data Management, con l’avvento delle pratiche di DevOps prima, ed MLOps successivamente, è appunto la raccolta sistematica dei metadati e degli artefatti prodotti dagli sviluppatori per abilitare l’automazione dei deployment e facilitare nuovi sviluppi.

Prendiamo come esempio le pratiche di MLOps: tutto ciò che può essere considerato un fattore di scelta all’interno di una progettualità in ambito data science viene raccolto e gestito da una suite di servizi. A partire dai dati utilizzati per il training, da come sono state create le feature da utilizzare nel modello, quale scelta di modello è stata fatta, quali configurazioni iniziali e quali risultati il modello ha ottenuto, fino ad arrivare alla messa in produzione del modello, alla raccolta ed utilizzo degli output per abilitare nuovi processi operativi o fornire KPI per processi già esistenti, al monitoraggio delle performance nel tempo e all’eventuale degrado di prestazioni.

La gestione di tali informazioni abilita da un lato una migliore esperienza da parte degli sviluppatori, mettendo a fattor comune ciò che è stato prodotto in altri scenari, dall’altro un’integrazione facilitata ed un miglior controllo sui modelli una volta passati in contesti produttivi.

Lo stesso tipo di discorso può e deve essere fatto nell’impiego dei Large Language Models. Abbiamo detto che da un punto di vista operativo sono due le possibilità per modificare e personalizzare il comportamento di un LLM: l’ingegnerizzazione del prompt ed il fine tuning.

Vanno dunque raccolti dati e metadati per gestire al meglio queste attività.

Prompt Lifecycle Management

Con questo termine ci si riferisce a tutte quelle procedure necessarie a creare, mantenere e gestire i prompt che sono utilizzati per istruire un Large Language Models.

Esattamente come avviene per il feature store nel contesto del Machine Learning, anche in questo caso risulta essenziale andare a salvare in uno store dedicato tutti i prompt che vengono utilizzati dagli utenti. Un esempio di metadati da raccogliere relativi ai prompt potrebbe essere:

• Categoria
Prompt “certificato” ed utilizzato in applicazioni a livello entreprise oppure prompt utilizzato in uno specifico contesto

• Ambito di utilizzo
Impiego per istruire un chatbot, una determinata strategia di RAG, un agente con finalità di tool calling, …

• Strategia di prompting
La strategia adottata nel prompt, ad esempio zero-shot, few-shot, chain of thought

• Descrizione contesto
Una descrizione in linguaggio naturale di ciò per cui il prompt viene utilizzato, in modo da abilitare ricerche di tipo semantico

• Parametri del prompt
Nel caso di prompt che accettano in input dei parametri, una classificazione e descrizione di come tali parametri vengono utilizzati all’interno del prompt

• Qualità del prompt
Un parametro che esprime il livello dei risultati ottenuti utilizzando il prompt, possibilmente aggiornato in modo automatico a valle dei riscontri ricevuti dagli utenti

Raccogliere queste informazioni in modo strutturato consente agli utenti di non partire da un foglio bianco, ma di poter invece ricercare all’interno di un Prompt Repository se è disponibile una qualche versione da cui poter partire, ed eventualmente filtrare rispetto ai prompt che hanno ottenuto risultati migliori entro certi ambiti di utilizzo.

Logging

Un altro aspetto fondamentale nell’utilizzo dei Large Language Models riguarda il logging.

Per eseguire correttamente il fine-tuning di un modello è necessario sottomettere una serie di conversazioni, dunque di coppie di richieste fatte al modello e risposte ottenute, in modo che il Large Language Models sia in grado di riconoscere alcuni pattern specifici di un determinato contesto e riproporli nelle risposte fornite. Più informazioni di qualità vengono utilizzato nella fase di fine-tuning e migliori saranno i risultati.

Per questo motivo risulta essenziale, nel momento in cui viene messo in produzione un qualsiasi applicativo che sfrutta i Large Language Models, salvare in maniera puntuale ciascuna richiesta fatta al modello dagli utenti, così come ciascuna risposta fornita dal modello. Oltre a questo, è necessario predisporre delle modalità di raccolta dei riscontri degli utenti, per valutare se una risposta è considerata corretta o anche solo attendibile, rispetto ad una sbagliata o imprecisa.

Per fare ciò è possibile utilizzare i servizi di logging messi a disposizione dai cloud provider, così come i diversi framework open source che stanno sempre più emergendo nel contesto dei Large Language Models (es: LangChain).

Oltre al vantaggio della personalizzazione di un modello in base ai riscontri forniti dagli utenti, e dunque una maggiore qualità nelle risposte fornite, un ulteriore aspetto positivo dato dall’operazione di fine-tuning è quello della riduzione dei costi. È infatti possibile utilizzare un modello meno potente, e spesso dunque a minor costo, ma che grazie al fine-tuning riesce a raggiungere le performance di un modello più potente.

Guardrails

Prendendo in considerazione gli aspetti legati alla governance dei dati e ai rischi nell’utilizzo dei modelli descritti precedentemente, una soluzione di mediazione di tali rischi è l’impiego dei guardrails.

Con il termine guardrail si intende un componente applicativo che svolge l’operazione di filtro sia nella fase di richiesta, sia in quella di risposta nell’utilizzo di un Large Language Model. È ovviamente possibile utilizzare più di un componente per governare aspetti differenti, ma in generale la pipeline da costruire è la seguente:

I guardrails permettono di eseguire una serie di controlli specifici sia sulle richieste che sulle risposte, come ad esempio il controllare se nell’interazione con il modello sono state inserite informazioni sensibili, oppure verificare una certa struttura formale richiesta in output al modello stesso.

In generale la logica applicativa inserita all’interno dei guardrails può essere di due tipologie: può essere una logica formale deterministica, nel quale i controlli sono puntuali e quantitativi, oppure può essere a sua volta una logica ottenuta con l’utilizzo dell’intelligenza artificiale, come ad esempio il controllo qualitativo sulla presenza nel testo di argomenti con impatti etici particolari. In questo secondo scenario si cerca solitamente di utilizzare il modello migliore a disposizione, in modo da avere i risultati di miglior qualità possibile, ma sarebbe comunque un errore considerare tale processo privo di errori.

I guardrail costituiscono dunque un importante elemento di controllo e di verifica delle informazioni fornite dagli utenti, così come di quelle generate dai modelli.

Il percorso completo

1 Definizione strategia operativa

nell’utilizzo degli LLM

2 Gestione dei servizi

necessari al prompt lifecycle management

3 Attivazione dei log

per qualsiasi richiesta/risposta generata nell’interazione con un LLM

4 Utilizzo del framework Guardrail

per un migliore controllo dei LLM

Vantaggi

Avere una corretta governance degli strumenti di AI sfruttando le soluzioni descritte porta ad avere alcuni importanti vantaggi:

Gestione operativa semplificata

Gli sviluppatori possono concentrarsi nel portare valore rispetto alle soluzioni sviluppate, non dovendo gestire gli aspetti di piattaforma e la raccolta automatica dei metadati necessari a futuri.

Maggiore controllo

Introduzione di metodologie e componenti architetturali dedicati al controllo delle informazioni sottomesse ai modelli e generate da essi. Riduzione del rischio di possibile danno di immagine causato dall’utilizzo dell’AI generativa.