I giganti del cloud e i principali editori di software stanno attivamente sviluppando e promuovendo servizi volti a facilitare la progettazione e l'implementazione di applicazioni alimentate da grandi modelli linguistici (LLM). Questa spinta tecnologica promette di rivoluzionare il modo in cui le aziende interagiscono con i dati e automatizzano i processi. Tuttavia, sorgono domande fondamentali: quali sono gli elementi costitutivi essenziali per realizzare tali applicazioni in modo efficace e, soprattutto, come è possibile implementare questi modelli quando non è fattibile ricorrere agli LLM disponibili tramite un cloud pubblico?
Innanzitutto, sebbene i modelli di generazione di linguaggio naturale (NLG) siano in grado di produrre testo, sono ormai noti per le loro "allucinazioni". Queste imprecisioni e invenzioni impediscono un loro utilizzo diretto e incondizionato in contesti aziendali, dove l'accuratezza e l'affidabilità dei dati sono paramount. Queste problematiche derivano in parte dal modo in cui questi modelli funzionano. Basandosi sui loro dati di addestramento e su un input – un prompt – il loro ruolo è prevedere la parola successiva o precedente in una frase, un meccanismo che, seppur potente, non garantisce intrinsecamente la veridicità.
Per ancorare le loro uscite o produzioni alla realtà e prevenire effetti di "tossicità" o imprecisioni, è necessario ricorrere a tecniche avanzate, in particolare alla ricerca vettoriale. «Gli LLM sono generalmente scatole nere. Se li usate in una fase di brainstorming, i risultati possono essere interessanti, ma se avete bisogno di fatti vi serve un modo per farli interagire con una base di conoscenza», ricorda Shray Anand, data scientist presso Red Hat.
L'arte di nutrire il modello di IA generativa con dati contestuali
Durante l'Open Source Summit 2023 a Dublino, Shray Anand e il suo collega Surya Prakash Pathak hanno presentato un'architettura tipo per un sistema di domanda-risposta alimentato da un grande modello linguistico. Questa architettura è progettata per integrare dati contestuali, un passaggio cruciale per migliorare l'affidabilità e la pertinenza delle risposte generate dagli LLM.
La messa in contesto dei dati richiede l'utilizzo o l'implementazione di pipeline di dati. Il processo inizia con l'instradamento di documenti verso un modello incaricato di dividere i testi in "token", che sono poi rappresentati utilizzando numeri in virgola mobile chiamati vettori o embedding. «Gli embedding racchiudono informazioni sull'oggetto in input», spiega Shray Anand. «Si tratta di collocare le parole in uno spazio vettoriale dove i termini con significati simili sono vicini tra loro. Ad esempio, i vettori equivalenti a un cane e un gatto saranno più adiacenti di quello che rappresenta un'automobile», illustra. Questa rappresentazione numerica permette di quantificare le relazioni semantiche tra le parole e i concetti.
Nel caso di un sistema di domanda-risposta, come un agente conversazionale che gestisce una sezione di domande frequenti (FAQ), è necessario codificare coppie di domande-risposte in vettori con un certo numero di dimensioni, continua il data scientist. Più alto è il numero di dimensioni, maggiore è la capacità di catturare sfumature e relazioni complesse tra le parole. In termini più semplici, se una richiesta richiede un risultato semplice, è improbabile che si utilizzi un modello di embedding in grado di interpretare centinaia di migliaia di dimensioni. Generalmente, gli LLM gestiscono vettori da un centinaio a poco più di un migliaio di dimensioni, trovando un equilibrio tra la capacità di rappresentazione e l'efficienza computazionale.
Questi vettori, una volta generati, vengono immagazzinati e indicizzati in una base di dati vettoriale.
Un'interfaccia utente consente all'utente di sottomettere una query, un'istruzione o una domanda. Questa viene instradata alla base di dati vettoriale per avviare una ricerca di similarità tra i termini della query e la semantica "intrappolata" nella dimensione di un vettore. Questa somiglianza viene calcolata utilizzando il punteggio di similarità del coseno, una metrica comune che misura l'angolo tra due vettori, indicando quanto siano simili nella direzione, indipendentemente dalla loro grandezza.
Nel caso dell'applicazione distribuita dal data scientist di Red Hat, il meccanismo di ricerca seleziona i tre candidati più vicini alla query. Successivamente, il testo corrispondente a questi candidati viene inviato al modello insieme al prompt tramite un orchestratore, al fine di generare la risposta finale. «La query e i candidati vanno a un gestore di prompt, o a uno strumento in grado di generare un prompt che può comunicare con l'interfaccia API che interagisce con il vostro LLM», descrive il data scientist. «Il modello crea quindi la risposta finale, poi la restituisce all'API, anch'essa interfacciata con l'applicazione front-end».
Questa descrizione dettagliata del processo è l'essenza di un'applicazione di generazione aumentata del recupero (Retrieval Augmented Generation, o RAG). L'architettura RAG combina la capacità di comprensione del linguaggio di un LLM con la capacità di recuperare informazioni da una vasta base di conoscenza, riducendo significativamente il rischio di allucinazioni e migliorando l'accuratezza delle risposte.
Un'architettura estensibile per ogni esigenza
La tecnica Retrieval Augmented Generation (RAG) è estremamente versatile e può essere utilizzata per alimentare un chatbot interno o esterno, ma anche per contestualizzare riassunti, supportare attività di classificazione o innescare una serie di altre applicazioni intelligenti. La sua flessibilità la rende una scelta potente per molteplici scenari aziendali.
Lo scorso giugno, Andreessen Horowitz aveva presentato un'architettura emergente significativamente più complessa rispetto a quella descritta. Tuttavia, secondo Shray Anand, è più pratico e consigliabile iniziare con un'architettura più semplice, ma che sia intrinsecamente estensibile. «È uno scheletro che potete migliorare in molti modi. Potete aggiungere la ricerca lessicale o per parola chiave alla ricerca vettoriale, potete installare un sistema di coda, di caching o anche di pianificazione delle attività», spiega. Questa modularità consente alle aziende di evolvere la propria soluzione in base alle esigenze crescenti, senza dover riprogettare l'intero sistema da zero.
La barriera d'ingresso per implementare una tale architettura è talmente bassa che è possibile distribuire un modello e un'applicazione in locale (on-premise) o nel cloud, a scopi di test e prototipazione. Ciò democratizza l'accesso alla tecnologia, permettendo anche a piccole realtà di sperimentare e innovare. Si tratta, quindi, di assemblare componenti open source e/o proprietari, a seconda delle specifiche esigenze e delle politiche aziendali, secondo il data scientist. Ma quali componenti?
Componenti chiave: dal database vettoriale al gestore di prompt
Per quanto riguarda la base di dati vettoriale, esistono più di cinquanta soluzioni che supportano gli embedding. Questa vasta scelta offre flessibilità ma richiede un'attenta valutazione. «Gli attori open source più importanti sono Qdrant, Milvus, Weaviate o ancora Pgvector», indica Shray Anand. Pgvector, in particolare, è un'estensione di PostgreSQL, un database relazionale molto diffuso, ed è stata selezionata da Google Cloud per arricchire la sua DbaaS AlloyDB con il supporto per i vettori. Anche piattaforme come Elasticsearch o OpenSearch supportano agevolmente queste rappresentazioni numeriche, offrendo opzioni per chi già utilizza tali ecosistemi.
«Nel quadro della nostra dimostrazione, abbiamo scelto Qdrant, perché può essere distribuita su Kubernetes ed eseguita in memoria localmente», indica il data scientist. Questa scelta evidenzia l'importanza della compatibilità con l'infrastruttura esistente e la possibilità di eseguire il software in ambienti distribuiti e performanti. Shray Anand aggiunge che, secondo la sua esperienza, i SGBD specializzati ottengono risultati migliori, e rimanda ai benchmark effettuati dal team dietro Qdrant, suggerendo che le soluzioni ottimizzate specificamente per i vettori possono superare le soluzioni più generaliste.
Il gestore di prompt, in questo contesto, non è altro che LangChain, uno dei framework più popolari in materia. LangChain fornisce un set di strumenti per la creazione di applicazioni basate su LLM, facilitando l'orchestrazione delle interazioni. Si possono anche citare LlamaIndex o Auto-GPT come alternative valide, ciascuno con le proprie peculiarità e punti di forza per la costruzione di catene di prompt e agenti autonomi.
Scegliere attentamente il modello di IA generativa
Per quanto riguarda il modello di IA generativa vero e proprio, il team di Red Hat ha inizialmente utilizzato l'API di GPT 3.5. Sebbene il modello di OpenAI non sia open source, è riconosciuto per le sue prestazioni elevate. I modelli proprietari come GPT-4 di OpenAI e Claude 2 di Anthropic sono considerati dei riferimenti nel settore per la loro potenza e capacità.
Tra le famiglie di modelli open source, i ricercatori elencano una varietà di opzioni che offrono flessibilità e controllo, fondamentali per le imprese che desiderano mantenere una maggiore sovranità sui propri dati e modelli. Questi includono: GPT-X, Gopher, Falcon, Pythia, Flan o ancora Bloom. A questi si possono aggiungere modelli più recenti e promettenti come Mistral 7B di Mistral AI e Alfred di LightOn. È importante ricordare che Llama 2 non è open source nel senso più stretto del termine, ma dispone di una licenza proprietaria permissiva, a condizione che l'applicazione sviluppata non superi i 700 milioni di utenti, rendendolo accessibile a un'ampia gamma di applicazioni aziendali.
«La scelta dei modelli dipende dal vostro budget, dalle vostre esigenze in termini di licenza e dalle sue prestazioni», riassume Surya Prakash Pathak. È una decisione che implica un compromesso tra costi, restrizioni d'uso e la qualità dei risultati attesi. Un fattore cruciale è anche il fabbisogno di risorse: più il numero di parametri è importante, più un LLM richiederà risorse IT, principalmente potenti GPU, che possono rappresentare un costo significativo sia in termini di hardware che di energia.
Inoltre, è fondamentale comprendere che ogni LLM ha i suoi punti di forza e le sue debolezze specifiche. Spesso si rivela necessario utilizzare un modello diverso per ogni tipo di caso d'uso, a seconda che debbano alimentare un sistema di domanda-risposta, di generazione di riassunti, di codice, e così via. Questa specializzazione permette di ottimizzare le prestazioni e l'accuratezza per compiti specifici.
Migliorare le risposte con il prompt engineering e l'apprendimento supervisionato
Se il meccanismo di ricerca documentale basato su RAG non dovesse essere sufficiente per ottenere risposte soddisfacenti, esistono ulteriori tecniche per raffinare le prestazioni dei modelli. È possibile ricorrere al prompt engineering, che consiste nell'ottimizzare la formulazione delle domande e delle istruzioni date al modello per guidarlo verso risposte più precise e pertinenti. Oltre a ciò, una fase di apprendimento supervisionato, nota anche come fine-tuning, può essere determinante.
Per stabilire una FAQ dedicata a Red Hat OpenShift for AWS (ROSA), i ricercatori hanno effettuato il fine-tuning supervisionato del modello pre-addestrato Flan. Questo è stato realizzato utilizzando coppie di domande-risposte specificamente legate al caso d'uso di ROSA, permettendo al modello di imparare le sfumature e la terminologia del dominio. Esistono anche giochi di dati open source come Falcon-Instruct e Dolly v2 che possono essere utilizzati per completare o arricchire questo set di dati specifico, fornendo un ulteriore contesto e migliorando la robustezza del modello.
Se l'applicazione in questione fosse stata uno strumento di revisione del codice, un caso d'uso attualmente in fase di sviluppo presso Red Hat, le coppie di richieste-istruzioni avrebbero riguardato l'identificazione di errori in un linguaggio di programmazione specifico, come ad esempio Java. In sintesi, questo principio di addestramento specifico e contestualizzato può essere applicato a una vasta gamma di applicazioni, dimostrando la flessibilità e la potenza dell'IA generativa quando supportata da un'architettura robusta e da un'attenta calibrazione del modello.