LLM, come istruirli a rispondere su nuovi documenti

In questi ultimi mesi, la maggior parte di noi ha avuto qualche esperienza di sperimentazione con chatbot come ChatGPT, o Bard, o Claude, esempi dei sistemi oggi noti come Large Language Model (LLM). Qualcuno ha poi provato a usare un chatbot non solo per osservarne e valutarne le reazioni, ma anche per cercare di imparare a usarlo in modo produttivo e ottenere risultati appropriati dai dialoghi che facciamo. Nel momento in cui ci stiamo abituando alle abilità di questi sistemi, un prossimo passo riguarda la capacità di intervenire su un chatbot per modificarne il comportamento, in accordo a propri scopi e utilizzando propri dati e documenti: sempre più spesso, questo è l’interesse applicativo prevalente di chi sta esplorando le possibilità di un uso sistematico dei chatbot nella propria organizzazione. Come si può dunque rendere un LLM capace di dialogare sul contenuto di documenti che non gli sono stati fatti leggere durante il suo addestramento? (per brevità li chiameremo d’ora in poi i “nuovi documenti”).

Rendere un LLM capace di dialogare sul contenuto di nuovi documenti

Si pensi, per esempio, al caso di un’azienda che voglia utilizzare un LLM in grado di sostenere una conversazione in cui si debba far riferimento a informazioni specifiche dell’azienda stessa, come quelle disponibili su clienti e fornitori, oppure a documentazione interna riguardante prodotti o servizi. Il sito stesso di OpenAI suggerisce che uno dei casi d’uso importanti per l’applicazione di LLM è di “inserire un’ampia quantità di dati personalizzati in un modello di linguaggio di grandi dimensioni”, cioè documenti, spesso riservati o proprietari, in qualche modo riferiti all’azienda o a un problema specifico, testi vari che fanno riferimento ad argomenti specifici, ecc., per fare poi richieste sul contenuto di questa documentazione.

Come si può far dialogare un LLM sul contenuto di documenti che non gli sono stati forniti durante il training? Ricordiamo che gli LLM che utilizziamo abitualmente sono pre-trained, ovvero sono stati prima addestrati in modo non supervisionato (in effetti: in modo auto-supervisionato) su un grandissimo numero di documenti, e tipicamente, in un secondo momento, sono stati sottoposti a un’attività di fine tuning, cioè a un addestramento in cui si è insegnato loro a svolgere alcune attività specifiche, e dunque, nel caso dei chatbot come ChatGPT, a dialogare in modo appropriato. Il passaggio successivo è quindi di sviluppare delle strategie per adattare il comportamento di un chatbot a compiti specifici basati sul contenuto dei nuovi documenti.

Numerosi articoli suggeriscono tecniche specifiche a questo scopo, ma non è facile trovare una presentazione sistematica delle opzioni attualmente disponibili: è quello che proponiamo qui, con l’attenzione di evitare dettagli troppo tecnici, in modo da rendere comprensibile quanto segue anche a lettori senza un’esperienza specifica di argomenti “di basso livello” come l’architettura dei transformer, gli algoritmi di addestramento mediante discesa lungo il gradiente di una funzione di errore, e simili (molti di questi argomenti sono relativamente nuovi, e sono stati proposti e sono discussi in testi in lingua inglese: per questo, l’uso di termini inglesi è in pratica inevitabile).

Quattro metodi per istruire un LLM su nuovi documenti

Al momento esistono strutturalmente quattro alternative per fornire a un LLM la possibilità di rispondere alle nostre domande su nuovi documenti, e dunque in riferimento anche a informazione che non era stata acquisita durante il suo addestramento:

1. modifica dei valori dei parametri dell’intero LLM tramite fine tuning;
2. modifica dei valori dei parametri di una matrice addizionale, di dimensione molto minore della matrice di base, mediante una tecnica di parameter-efficient fine tuning, per esempio Low Ranking Adaptation (LoRA);
3. preselezione delle parti rilevanti dei nuovi documenti, nel contesto di un’architettura di retrieval-augmented LLM, per esempio abilitata da un qualche genere di text embedding;
4. adattamento della richiesta da inviare all’LLM, un’attività chiamata di prompt engineering (o prompt design: non distinguiamo qui tra le due).

Questi quattro metodi condividono lo stesso obiettivo: la personalizzazione del comportamento di un LLM già addestrato (così che, ovviamente, con LLM più sofisticati sarà più facile ottenere un comportamento di buona qualità), per far sì che sia in grado di rispondere appropriatamente a richieste relative ai nuovi documenti, ma sono diversi in ciò che modificano dell’LLM, nel modo in cui realizzano questa modifica, e nei loro pro e contro.

In particolare, il primo metodo altera la memoria a lungo termine dell’LLM e il quarto agisce sulla memoria a breve termine, mentre parameter-efficient fine tuning e text embedding sono basati su strutture di dati introdotte ad hoc e, in un certo senso, intermedie tra la memoria a lungo termine e quella a breve termine.

I quattro metodi

Presentiamo questi quattro metodi, nuovamente sottolineando che quanto segue propone la nostra interpretazione di uno scenario complesso e comunque in evoluzione.

Fine tuning

Il fine tuning è un metodo attraverso cui si prosegue l’addestramento di un LLM pre-addestrato, aggiornandone i valori dei parametri utilizzando un insieme di dati a cui l’LLM non era stato ancora esposto, di solito più piccolo e specifico di quello impiegato per l’addestramento iniziale. Poiché il fine tuning è tipicamente basato su un addestramento supervisionato, occorre prima di tutto preparare i nuovi dati, per esempio strutturandoli nella forma [domanda: risposta attesa], e quindi riprendendo l’addestramento dell’LLM per aggiornarne i valori dei parametri tramite il solito algoritmo di minimizzazione di una funzione di errore. Questo processo è dunque, di principio, molto semplice, tanto che per esempio OpenAI mette a disposizione gli strumenti per fare fine tuning con propri dati direttamente da linea di comando, dunque senza dover scrivere nemmeno una linea di codice. D’altra parte, fare fine tuning corrisponde a cercare di far sì che un chatbot che è già stato addestrato, tipicamente con un’enorme quantità di dati, sia in grado di gestire con una particolare attenzione proprio i nostri nuovi documenti, e questo senza strumenti specifici per poter evidenziare che l’LLM dovrebbe trattare questi ultimi dati in via preferenziale rispetto ai tanti altri con cui era stato addestrato.

Dunque, questo metodo non solo può rivelarsi lungo, nella preparazione dei nuovi documenti e nella realizzazione del fine tuning stesso, e costoso, poiché richiede le risorse computazionali, spesso rilevanti, per poter intervenire sull’intera matrice dell’LLM, ma è anche a rischio di limitata efficacia nei suoi risultati. Inoltre, ogni nuova versione fine tuned di un LLM ha una matrice delle stesse dimensioni del modello iniziale, tipicamente dell’ordine almeno dei GByte, rendendo così quantomeno scomoda la gestione di versioni molteplici. Il fine tuning non è dunque generalmente un metodo appropriato per gli scopi che stiamo discutendo qui.

Parameter-efficient fine tuning (ad esempio mediante Low Rank Adaptation  – LoRA)

Un metodo più veloce ed efficiente per adattare il comportamento di un LLM pre-addestrato a nuovi documenti si basa sull’osservazione che l’algoritmo di back-propagation interviene sui parametri del modello per aggiornarne i valori in modo additivo (in pratica: nuovo valore = valore attuale – derivata della funzione di errore rispetto al parametro). Ciò significa che durante il fine tuning si potrebbe operare su una matrice di parametri addizionale, “parallela” a quella dell’LLM, e dunque senza modificare quest’ultima, combinando poi le risposte prodotte dalle due durante il funzionamento. Su questo principio è stata proposta in particolare la tecnica Low Rank Adaptation (LoRA), in cui la matrice addizionale, chiamata adapter, è strutturata in modo da poter avere una dimensione molto inferiore a quella della matrice dell’LLM. Poiché l’adapter ha solo lo scopo di gestire i nuovi documenti, il fatto che il numero dei suoi parametri sia molto più piccolo di quello della matrice dell’LLM non solo non è un problema, ma anzi consente di fare un fine tuning più efficiente e di produrre senza problemi versioni multiple della matrice addizionale, ognuna relativa a un diverso insieme di nuovi documenti.

In effetti, la dimensione dell’adapter è una variabile strategica di questo metodo: se troppo piccola, l’LLM non sarà in grado di gestire appropriatamente i nuovi documenti, e quindi si otterranno risposte di qualità non sufficiente; se troppo grande, il fine tuning diventerà inutilmente costoso.

Benché ancora relativamente recente, la tecnica LoRA è ormai così diffusa che è possibile applicarla anche senza scrivere codice, per esempio con un sistema interattivo come text-generation-webui.

Retrieval-augmented LLM (ad esempio mediante text embedding)

A differenza dei due precedenti, questo metodo non interviene sulla matrice dei parametri dell’LLM, né direttamente, come nel fine tuning (metodo 1), né indirettamente, come in LoRA (metodo 2). Si concentra invece sulla costruzione di una richiesta appropriata, che contenga non solo la domanda da porre ma anche l’informazione rilevante per poter rispondere appropriatamente, recuperata dai nuovi documenti. Di principio, il problema sembra facilmente risolvibile, costruendo, manualmente o via codice, una richiesta del tipo “data l’informazione XYZ, rispondi alla domanda ABC”, dove XYZ è il contenuto dei nuovi documenti, e dunque operando esclusivamente con la memoria a breve termine dell’LLM.

Il punto è che gli LLM hanno una memoria a breve termine, chiamata anche context window, di dimensioni relativamente ridotte, tipicamente capace di contenere solo qualche migliaio di parole (o, al momento, qualche decina di migliaia di parole negli LLM più sofisticati): se i nuovi documenti non sono abbastanza brevi, la context window non è grande a sufficienza per contenerli, insieme con la domanda. Quello che però si può fare è di organizzare il contenuto dei nuovi documenti in un qualche genere di database, dotato di una funzione per selezionare le parti del suo contenuto rilevanti per rispondere alla specifica domanda posta. In questo modo, l’LLM così “aumentato” funziona secondo questa procedura:

– riceve la domanda ABC;

– consulta il database e seleziona i dati XYZ rilevanti per rispondere alla domanda;

– costruisce una richiesta del tipo “data l’informazione XYZ, rispondi alla domanda ABC”;

– esegue la richiesta.

La qualità dei risultati che si ottengono in questo modo dipende, evidentemente, dalla qualità del processo di selezione nel database. Questo può essere realizzato in modo sintattico, se i nuovi documenti sono etichettati con metadati e la selezione può essere effettuata su di essi, ma si può anche usare un sistema di selezione semantica, che dunque confronta la domanda con il contenuto dei nuovi documenti, impiegando un sistema di text embedding. In pratica, le singole parole o le frasi di ognuno dei nuovi documenti vengono trasformate in vettori di numeri, esattamente come accade nella prima fase del funzionamento di un LLM con ogni richiesta, in modo che ogni documento, o ogni frammento (chunk) di documento, possa essere memorizzato nel database come una lista di questi vettori. Questi vettori sono prodotti da una rete neurale (generalmente con pochi strati nascosti, e quindi non “deep”), che era stata addestrata in modo da associare numeri simili a parole o frasi semanticamente simili (è appunto questo il concetto di embedding nel contesto del natural language processing). Ricevendo una domanda, l’LLM “aumentato” la trasforma a sua volta in una lista di vettori, e la selezione consiste dunque nella ricerca delle parti del database più simili, numericamente, alla domanda, in modo da includerle, secondo un qualche criterio di priorità, nella richiesta, che finalmente sarà gestita come abitualmente.

La qualità dei risultati che si ottengono con questo metodo è dunque criticamente dipendente sia dalle dimensioni della context window (anche considerando che nel caso di uso di LLM proprietari via API il costo è anche funzione del numero di token nella richiesta), sia dalla qualità dell’algoritmo di similarità semantica.

A dispetto della sua complessità procedurale, questo metodo è oggi reso utilizzabile sia in modo relativamente semplice da “agenti”, attivabili via codice per esempio nel framework LangChain, sia anche, interattivamente, da alcuni plugin di ChatGPT.

Prompt engineering

Quest’ultimo metodo prevede di operare solo sulla costruzione della richiesta da inviare all’LLM, assumendo dunque che la richiesta abbia la struttura “data l’informazione XYZ, rispondi alla domanda ABC”, dove XYZ è il contenuto dei nuovi documenti, se la context window è grande a sufficienza da contenerli, oppure una sua sintesi fatta a priori. Ogni volta che si inizia un dialogo è perciò necessario includere nella prima richiesta l’informazione rilevante, cosa che rende il metodo assai semplice da implementare, ma anche destinato a produrre alti costi variabili, e comunque non utilizzabile nel caso di nuovi documenti di dimensione sufficientemente grande. La gestione della context window degli LLM è oggetto di un’intensa attività di ricerca, volta in particolare ad aumentarne la dimensione mantenendo una buona qualità di “attenzione”, ma al momento resta una limitazione rilevante alla possibilità di utilizzare questo metodo.

Conclusioni

A nostra conoscenza, questi quattro metodi sono quelli al momento disponibili per ottenere quella che potremmo descrivere come verticalizzazione applicativa nel comportamento degli LLM. Si tratta di metodi non alternativi, che possono essere applicati in modo sequenziale, per esempio facendo text embedding con un LLM che è stato fine tuned con nuovi documenti, e anzi potrebbe essere un’ottima idea provare a ibridare tra metodi. Nonostante in questi mesi siano stati pubblicati numerosi articoli al proposito, si tratta di un argomento così nuovo che non esistono ancora vere e proprie linee guida consolidate: è ancora il tempo della sperimentazione.