Nell’articolo Knowledge Graphs e Large Language Models (LLMs) Insieme [parte 1] abbiamo esplorato come gli LLM possono essere utilizzati per generare e curare i Knowledge graphs (KG). Tuttavia non esiste solo questa interazione tra questi due strumenti. Infatti, in molti contesti si utilizzano i KG per migliorare le risposte degli LLM.
Ci sono diversi motivi per utilizzare un KG per alimentare e governare le pipeline e le applicazioni GenAI. Secondo Gartner, “fino al 2025, almeno il 30% dei progetti GenAI sarà abbandonato dopo il proof of concept (POC) a causa della scarsa qualità dei dati, dell’inadeguatezza dei controlli sui rischi, dell’aumento dei costi o della scarsa chiarezza del valore aziendale”. I KG possono aiutare a migliorare la qualità dei dati, a mitigare i rischi e a ridurre i costi.
Governance dei dati, controllo degli accessi e conformità normativa
Solo le persone e le applicazioni autorizzate devono avere accesso a determinati dati e per determinati scopi. In genere, le aziende desiderano che determinati tipi di persone (o applicazioni) possano chattare con determinati tipi di dati, in modo ben governato. Come si fa a sapere quali dati devono andare in quale pipeline GenAI? Come potete assicurarvi che le informazioni personali non finiscano nell’assistente digitale con cui volete che tutti i vostri dipendenti chattino? La risposta è la governance dei dati. Alcuni punti aggiuntivi:
Le politiche e le normative possono cambiare, soprattutto quando si tratta di IA. Anche se le vostre app di IA sono conformi ora, potrebbero non esserlo più in futuro. Una buona base di governance dei dati consente all’azienda di adattarsi a queste normative mutevoli.
A volte la risposta corretta a una domanda è “non lo so”, “non hai accesso alle informazioni necessarie per rispondere a questa domanda” o “è illegale o non etico per me rispondere a questa domanda”. La qualità delle risposte non è solo una questione di verità o accuratezza, ma anche di conformità normativa.
I principali attori che implementano o abilitano la governance dei dati tramite i KG (in ordine alfabetico): Società di KG semantici come Cambridge Semantics, data.world, PoolParty, metaphacts e TopQuadrant, ma anche cataloghi di dati come Alation, Collibra e Informatica (e molti altri).
Precisione e comprensione del contesto
I KG possono anche contribuire a migliorare la qualità complessiva dei dati: se i vostri documenti sono pieni di affermazioni contraddittorie e/o false, non sorprendetevi quando il vostro ChatBot vi dirà cose incoerenti e false. Se i vostri dati sono mal strutturati, immagazzinarli in un unico posto non vi aiuterà. È così che la promessa dei data lake è diventata il flagello delle paludi di dati. Allo stesso modo, se i dati sono mal strutturati, la vettorializzazione non risolverà i problemi, ma creerà solo un nuovo problema: una palude di dati vettorizzati. Se i dati sono ben strutturati, invece, i KG possono fornire ai LLM ulteriori risorse rilevanti per generare raccomandazioni più personalizzate e accurate in diversi modi. Esistono diversi modi di utilizzare i KG per migliorare l’accuratezza di un LLM, ma in genere rientrano nella categoria dell’interrogazione in linguaggio naturale (NLQ), ovvero l’utilizzo del linguaggio naturale per interagire con i database. Per quanto ne so, i modi in cui viene attualmente implementato l’NLQ sono il RAG, il prompt-to-query e il fine-tuning.
Retrieval-Augmented Generation (RAG)
RAG significa integrare un prompt con ulteriori informazioni rilevanti al di fuori dei dati di addestramento per generare una risposta più accurata. Sebbene i LLM siano stati addestrati su grandi quantità di dati, non sono stati addestrati sui vostri dati. Pensate all’esempio della lettera di presentazione di cui sopra. Potrei chiedere a un LLM di “scrivere una lettera di presentazione per Steve Hedden per un posto di lavoro nella gestione dei prodotti presso TopQuadrant” e mi risponderebbe, ma con delle allucinazioni. Un modo più intelligente di farlo sarebbe che il modello prendesse questa richiesta, recuperasse il profilo LinkedIn di Steve Hedden, recuperasse la descrizione del lavoro per la posizione aperta presso TopQuadrant e poi scrivesse la lettera di presentazione. Attualmente esistono due modi principali per effettuare questo recupero: vettorializzando il grafo o trasformando il prompt in una query del grafo (prompt-to-query).
- Recupero basato su vettori: Questo metodo di recupero richiede la vettorializzazione del KG e la sua memorizzazione in un archivio vettoriale. Se poi si vettorializza la richiesta in linguaggio naturale, si possono trovare nell’archivio vettoriale i vettori più simili alla richiesta. Poiché questi vettori corrispondono a entità del grafo, è possibile restituire le entità più “rilevanti” del grafo, date le richieste in linguaggio naturale. Si tratta dello stesso processo descritto in precedenza nella funzionalità di tagging: in sostanza, stiamo “etichettando” un prompt con i tag pertinenti del nostro KG.
- Recupero da prompt a domanda: In alternativa, si può usare un LLM per generare una query SPARQL o Cypher e usarla per ottenere i dati più rilevanti dal grafo. Nota: è possibile utilizzare il metodo prompt-to-query per interrogare direttamente il database, senza utilizzare i risultati per integrare una richiesta a un LLM. Questa non sarebbe un’applicazione di RAG, poiché non si sta “aumentando” nulla. Questo metodo è spiegato in dettaglio più avanti.
Alcuni ulteriori pro, contro e note sulla RAG e sui due metodi di reperimento.
Il RAG richiede, per definizione, una base di conoscenza. Un grafo della conoscenza è una base di conoscenza, e quindi i sostenitori dei KG saranno sostenitori del RAG alimentato da grafi (a volte chiamato GraphRAG). Ma la RAG può essere implementata anche senza un grafo della conoscenza.
RAG può integrare un prompt in base ai dati più rilevanti della vostra KG, basandosi sul contenuto del prompt, ma anche sui metadati del prompt. Ad esempio, possiamo personalizzare la risposta in base a chi ha posto la domanda, a ciò a cui ha accesso e a ulteriori informazioni demografiche su di lui.
Come descritto in precedenza, un vantaggio dell’utilizzo del metodo di recupero basato sui vettori è che se il KG è stato incorporato in un database vettoriale per l’etichettatura e la risoluzione delle entità, la parte difficile è già stata fatta. Trovare le entità più rilevanti relative a un prompt non è diverso dal taggare un pezzo di testo non strutturato con le entità di una KG.
RAG fornisce un certo livello di spiegabilità nella risposta. L’utente può ora vedere i dati supplementari che sono stati utilizzati per la sua richiesta e, potenzialmente, dove si trova la risposta alla sua domanda in quei dati.
Ho accennato in precedenza al fatto che l’IA sta influenzando il modo in cui costruiamo i KG, mentre ci si aspetta che costruiamo KG che facilitino l’IA. L’approccio prompt-to-query ne è un esempio perfetto. Lo schema del KG influisce sulla capacità di un LLM di interrogarlo. Se lo scopo della KG è quello di alimentare un’applicazione di IA, allora l’ontologia “migliore” non è più un riflesso della realtà, ma un riflesso del modo in cui l’IA vede la realtà.
In teoria, informazioni più rilevanti dovrebbero ridurre le allucinazioni, ma questo non significa che la RAG elimini le allucinazioni. Stiamo ancora usando un modello linguistico per generare una risposta, quindi c’è ancora molto spazio per l’incertezza e le allucinazioni. Anche con il mio curriculum e la mia descrizione del lavoro, un LLM potrebbe ancora esagerare la mia esperienza. Per quanto riguarda l’approccio text to query, stiamo usando l’LLM per generare la query KG e la risposta, quindi ci sono due posti per potenziali allucinazioni.
Allo stesso modo, la RAG offre un certo livello di spiegabilità, ma non del tutto. Ad esempio, se abbiamo utilizzato un reperimento basato su vettori, il modello può dirci quali entità ha incluso perché erano le più rilevanti, ma non può spiegare perché erano le più rilevanti. Se si utilizza una query KG generata automaticamente, la query generata automaticamente “spiega” perché determinati dati sono stati restituiti dal grafico, ma l’utente dovrà comprendere SPARQL o Cypher per capire appieno perché quei dati sono stati restituiti.
Questi due approcci non si escludono a vicenda e molte aziende li stanno perseguendo entrambi. Ad esempio, Neo4j offre tutorial sull’implementazione di RAG con recupero basato su vettori e sulla generazione di prompt-to-query. Aneddoticamente, sto scrivendo queste righe subito dopo aver partecipato a una conferenza incentrata sull’implementazione di KG e LLM nelle scienze biologiche, e molte delle aziende del settore che ho visto presentare stanno utilizzando una qualche combinazione di RAG basato su vettori e prompt-to-query.
I principali attori che implementano o abilitano soluzioni RAG (in ordine alfabetico) sono: data.world, Microsoft, Neo4j, Ontotext, PoolParty, SciBite, Stardog, TopQuadrant (e molti altri).
Prompt-to-query
Utilizzare un LLM per tradurre una query in linguaggio naturale in una query formale (come in SPARQL o Cypher) per il proprio KG. Si tratta dello stesso approccio di recupero prompt-to-query descritto in precedenza, con la differenza che non si inviano i dati a un LLM dopo che sono stati recuperati. L’idea è che, utilizzando l’LLM per generare la domanda e non per interpretare i dati, si riducono le allucinazioni. Tuttavia, come già detto, non importa cosa genera l’LLM, può contenere allucinazioni. L’argomentazione a favore di questo approccio è che per l’utente è più facile individuare le allucinazioni nella query autogenerata che nella risposta autogenerata. Sono un po’ scettico su questo punto, poiché, presumibilmente, molti utenti che usano un LLM per generare una query SPARQL non conoscono SPARQL abbastanza bene da individuare i problemi con la query generata automaticamente.
Chiunque implementi una soluzione RAG utilizzando il recupero prompt-to-query può anche implementare il prompt-to-query da solo. Questi includono: Neo4j, Ontotext e Stardog.
KG per la messa a punto degli LLM
Utilizzate il vostro KG per fornire un addestramento aggiuntivo a un LLM già pronto. Invece di fornire i dati del KG come parte del prompt al momento dell’interrogazione (RAG), potete usare il vostro KG per addestrare l’LLM stesso. Il vantaggio è che si possono mantenere tutti i dati a livello locale, senza dover inviare i prompt a OpenAI o ad altri. Lo svantaggio è che la prima L di LLM sta per large e quindi scaricare e mettere a punto uno di questi modelli richiede molte risorse. Inoltre, anche se un modello messo a punto sulla base dei dati aziendali o specifici del settore sarà più accurato, non eliminerà del tutto le allucinazioni. Alcune riflessioni aggiuntive su questo punto:
- Una volta che si utilizza il grafico per mettere a punto il modello, si perde anche la possibilità di utilizzare il grafico per il controllo degli accessi.
- Esistono LLM che sono già stati messi a punto per diversi settori, come MedLM per la sanità e SecLM per la sicurezza informatica.
- A seconda del caso d’uso, un LLM ottimizzato potrebbe non essere necessario. Ad esempio, se l’LLM viene utilizzato principalmente per riassumere articoli di cronaca, potrebbe non essere necessario un addestramento speciale.
- Piuttosto che perfezionare l’LLM con informazioni specifiche del settore, alcuni utilizzano LLM perfezionati per generare codice (come Code Llama) come parte della loro soluzione prompt-to-query.
- I principali attori che implementano o abilitano soluzioni incentrate sull’uso dei KG per la messa a punto degli LLM: Per quanto ne so, Voicebox di Stardog è l’unica soluzione che utilizza un KG per mettere a punto un LLM per il cliente.
Una nota sui diversi modi di integrare KG e LLM che ho elencato qui: Queste categorie (RAG, prompt-to-query e fine-tuning) non sono né complete né si escludono a vicenda. Ci sono altri modi di implementare KG e LLM e ce ne saranno altri in futuro. Inoltre, c’è una notevole sovrapposizione tra queste soluzioni ed è possibile combinarle. Ad esempio, è possibile eseguire una soluzione ibrida RAG basata su vettori e prompt-to-query su un modello fine-tuned.
Efficienza e scalabilità
Costruire molte applicazioni separate che non si collegano tra loro è inefficiente e ciò che Dave McComb definisce un deserto di software. Non importa che le app siano “alimentate dall’intelligenza artificiale”. Le app separate comportano la duplicazione di dati e codice e una generale ridondanza. I KG forniscono una base per eliminare queste ridondanze attraverso un flusso regolare di dati in tutta l’azienda.
Gartner sostiene che molti progetti GenAI saranno abbandonati a causa dell’aumento dei costi, ma non so se un KG possa ridurre significativamente tali costi. Non conosco studi o analisi costi-benefici condotti a sostegno di questa affermazione. Sviluppare un ChatBot alimentato da LLM per un’azienda è costoso, ma lo è anche sviluppare un KG.
