I giganti del cloud e gli editori di software stanno tutti spingendo servizi per la progettazione di applicazioni alimentate da grandi modelli di linguaggio (LLM). Tuttavia, sorgono domande fondamentali: quali sono i componenti essenziali per realizzare tali applicazioni? E come si possono implementare questi modelli quando non è possibile ricorrere agli LLM disponibili tramite un cloud pubblico?

Innanzitutto, sebbene i modelli NLG (Generazione di Linguaggio Naturale) siano capaci di produrre testo, sono ormai noti per le loro "allucinazioni". Questi errori impediscono il loro utilizzo diretto in contesti aziendali. Tali imprecisioni sono in parte dovute al modo in cui questi modelli funzionano: basandosi sui dati di addestramento e su un input (un prompt), il loro ruolo è prevedere la parola successiva o precedente di una frase.

Per ancorare le loro output nella realtà ed evitare effetti di tossicità o imprecisioni, è necessario ricorrere alla ricerca vettoriale. «Gli LLM sono generalmente delle 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.

Lo stato dell'arte: alimentare 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 l'architettura tipo di un sistema di domanda-risposta alimentato da un grande modello di linguaggio. Questa contestualizzazione dei dati richiede l'utilizzo o l'implementazione di pipeline di dati. È necessario convogliare i documenti verso un modello incaricato di dividere i testi in token, quindi di rappresentarli utilizzando numeri a virgola mobile, chiamati vettori o embedding. «Gli embedding imprigionano informazioni relative all'oggetto in input», spiega Shray Anand. «Si tratta di posizionare 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 rispetto a quello che rappresenta un'auto», illustra.

Nel caso di un sistema di domanda-risposta, tipicamente un agente conversazionale che gestisce una sezione di domande frequenti (FAQ), è opportuno codificare coppie di domande-risposte in vettori di un certo numero di dimensioni, prosegue la data scientist. Maggiore è il numero di dimensioni, maggiore è la possibilità di catturare sfumature e relazioni complesse tra le parole. Chiaramente, se una richiesta richiede un risultato semplice, è improbabile che si utilizzi un modello di embedding capace di interpretare centinaia di migliaia di dimensioni. Generalmente, gli LLM gestiscono vettori da un centinaio a poco più di un migliaio di dimensioni.

Questi vettori vengono archiviati e indicizzati in un database vettoriale. Un'interfaccia utente consente di inviare una query, un'istruzione o una domanda. Questa viene instradata al database vettoriale per attivare una ricerca di similarità tra i termini della query e la semantica "imprigionata" nella dimensione di un vettore. Questa somiglianza viene calcolata utilizzando il punteggio di similarità del coseno.

Nel caso dell'applicazione implementata dalla data scientist di Red Hat, il meccanismo di ricerca seleziona i tre candidati più vicini. Successivamente, il testo corrispondente viene inviato al modello con il prompt tramite un orchestratore, al fine di generare la risposta. «La query e i candidati vanno a un gestore di prompt, o uno strumento in grado di generare un prompt che possa comunicare con l'interfaccia API che interagisce con il vostro LLM», descrive la data scientist. «Il modello crea quindi la risposta finale, poi la restituisce all'API, anch'essa interfacciata con l'applicazione front-end». Questa è la descrizione di un'applicazione di Retrieval Augmented Generation (RAG).

Un'architettura estensibile

La tecnica Retrieval Augmented Generation può essere utilizzata per alimentare un chatbot interno o esterno, ma anche per contestualizzare riassunti o attività di classificazione. Lo scorso giugno, Andreessen Horowitz aveva presentato un'architettura emergente ben più complessa di quest'ultima. Secondo Shray Anand, è più semplice iniziare con un'architettura semplice ma 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 code, di caching o anche di pianificazione delle attività», spiega.

La barriera d'ingresso è così bassa che è possibile implementare un modello e un'applicazione on-premise o nel cloud, a scopo di test. Si tratta quindi di assemblare componenti open source e/o proprietari, a seconda del data scientist. Sì, ma quali?

Scelta del database vettoriale

Per quanto riguarda il database vettoriale, esistono più di cinquanta soluzioni che supportano gli embedding. «Gli attori open source più importanti sono Qdrant, Milvus, Weaviate o anche Pgvector», indica Shray Anand. Pgvector corrisponde più particolarmente a un'estensione di PostgreSQL selezionata da Google Cloud per arricchire la sua DbaaS AlloyDB con il supporto dei vettori. Elasticsearch o OpenSearch supportano agevolmente queste rappresentazioni numeriche.

«Nell'ambito della nostra dimostrazione, abbiamo scelto Qdrant, perché può essere distribuita su Kubernetes ed eseguita in memoria localmente», indica il data scientist. Shray Anand aggiunge che, secondo la sua esperienza, i SGBD specializzati ottengono risultati migliori, e rimanda ai benchmark effettuati dal team dietro Qdrant.

Il gestore di prompt

Il gestore di prompt, in questo contesto, non è altro che LangChain, uno dei framework più popolari in materia. Si possono citare anche LlamaIndex o Auto-GPT.

Come scegliere il proprio modello di IA generativa

Per quanto riguarda il modello, il team di Red Hat ha inizialmente utilizzato l'API di GPT 3.5. Il modello di OpenAI non è open source, ma piuttosto performante. I modelli proprietari, GPT-4 e Claude 2 di Anthropic, sono dei riferimenti.

Tra le famiglie di modelli open source, i ricercatori elencano:

GPT-X
Gopher
Falcon
Pythia
Flan
Bloom

Si possono aggiungere Mistral 7B di Mistral AI e Alfred di LightOn. È importante ricordare che Llama 2 non è open source, ma dispone di una licenza proprietaria permissiva, a condizione che l'applicazione sviluppata non superi i 700 milioni di utenti.

«La scelta dei modelli dipende dal vostro budget, dai vostri requisiti di licenza e dalle sue prestazioni», riassume Surya Prakash Pathak. Maggiore è il numero di parametri, più un LLM richiede risorse IT, principalmente potenti GPU.

Inoltre, bisogna comprendere che ogni LLM ha i suoi punti di forza e di debolezza e che spesso è necessario utilizzare un modello per tipo di caso d'uso, a seconda che servano per alimentare un sistema di domanda-risposta, di generazione di riassunti, di codice, ecc.

Se il meccanismo di ricerca documentale non è sufficiente per ottenere risposte soddisfacenti, è possibile ricorrere al prompt engineering e poi a una fase di apprendimento supervisionato. Per creare una FAQ dedicata a Red Hat OpenShift for AWS (ROSA), i ricercatori hanno effettuato il fine-tuning supervisionato del modello preaddestrato Flan, utilizzando coppie di domande-risposte legate al suo caso d'uso. Esistono anche set di dati open source come Falcon-Instruct e Dolly v2 per completare questo data set.

Se l'applicazione riguardasse uno strumento di revisione del codice, un caso d'uso in fase di sviluppo presso Red Hat, le coppie di query-istruzioni avrebbero riguardato l'identificazione di errori in un linguaggio di programmazione, ad esempio Java. In sintesi, questo principio può essere applicato a una grande varietà di contesti.