Introduzione alla personalizzazione degli LLM
Negli ultimi anni, i rapidi progressi nell'intelligenza artificiale hanno portato allo sviluppo di grandi modelli linguistici (LLMs), rivoluzionando il campo dell'elaborazione del linguaggio naturale (NLP). Questi potenti modelli, come ChatGPT, Llama, Mistral, Zephyr e altri, hanno dimostrato capacità superiori nella comprensione e nella generazione di linguaggio simile a quello umano.
Tuttavia, questi LLM hanno dei limiti. Sono addestrati su una grande quantità di dati con una specifica data limite, il che significa che, se li usiamo per generare risposte che richiedono conoscenze più recenti dei loro dati di addestramento, corriamo il rischio di ottenere risposte imprecise. Pertanto, è essenziale adattare questi modelli ai nostri compiti e domini specifici per sbloccarne tutto il potenziale. È qui che entra in gioco la personalizzazione degli LLM.
In un recente Zilliz Unstructured Data Meetup a Seattle, il CEO di OSS4AI e precedente Senior Developer Advocate di Zilliz, Yujian Tang, ha discusso diverse opzioni per personalizzare gli LLM al fine di migliorarne le prestazioni su compiti specifici. Prima di discutere le diverse opzioni di personalizzazione per un LLM, esploriamo brevemente la storia degli LLM.
Guarda la registrazione dell'intervento di Yujian
Breve storia degli LLM
La ricerca che ha portato alla nascita degli LLM ha fatto molta strada, a partire dall'architettura di base delle reti neurali. Uno strato di rete neurale di base consiste in uno strato di input, uno o più strati nascosti e uno strato di output, come mostrato nel grafico sottostante.
Architettura della rete neurale
L'architettura di base delle reti neurali si è dimostrata molto potente per i compiti di classificazione e può gestire dati non strutturati come testi e immagini. Tuttavia, è inefficace per compiti che richiedono dipendenze a lungo termine o elaborazione sequenziale, essenziali per i compiti di linguaggio naturale. Nelle reti neurali di base, ogni input viene elaborato in modo indipendente e l'output viene generato esclusivamente in base all'input corrente. Ciò significa che le reti neurali non considerano l'ordine o il contesto dell'input rispetto all'intera sequenza.
Senza la capacità di gestire dipendenze a lungo termine, una rete neurale non può inferire il significato semantico di un'intera sequenza di input o di un testo: la nascita delle reti neurali ricorrenti (RNNs) mirava a risolvere questo problema.
Le RNN affrontano il problema introducendo uno stato nascosto, che agisce come una memoria che cattura informazioni da ciò che la rete ha visto in precedenza. Questo stato nascosto viene passato da un passo temporale al successivo, consentendo alla rete di mantenere una rappresentazione della sequenza. L'aggiunta di uno stato nascosto consente alle RNN di ricordare o dimenticare selettivamente informazioni dalla sequenza di input, rendendole più efficaci per le dipendenze delle sequenze di input rispetto alle reti neurali di base.
Architettura RNN
Tuttavia, anche le RNN presentano diverse limitazioni, come:
Problema del gradiente evanescente: le RNN soffrono del problema del gradiente evanescente, in cui i gradienti usati per aggiornare i parametri del modello durante l'addestramento diventano più piccoli man mano che vengono retropropagati nel tempo. Questo problema rende difficile per le RNN apprendere dipendenze a lungo termine nelle sequenze.
Elaborazione sequenziale: le RNN elaborano le sequenze in modo sequenziale, limitando la loro capacità di parallelizzare il calcolo e rendendole meno efficienti dal punto di vista computazionale.
Queste limitazioni delle RNN hanno portato allo sviluppo del Transformer, che utilizza un meccanismo di self-attention per elaborare le sequenze di input in parallelo ed evitare il problema del gradiente evanescente.
Architettura Transformer
L’architettura Transformer è composta da diversi blocchi encoder e decoder. Ogni blocco encoder e decoder contiene un livello speciale chiamato livello di attenzione. Questo livello svolge un ruolo cruciale nel determinare il significato semantico dietro ogni token rispetto all’intera sequenza di input. Ad esempio, considera le seguenti tre frasi:
Apple ha realizzato un utile di $97 miliardi nel 2023
Mi piace mangiare la torta di mele per profit nel 2023
Il risultato finale di Apple è aumentato di numeri record nel 2023
Se utilizziamo solo un approccio tradizionale, come un approccio basato su parole chiave, le prime due frasi saranno la coppia più simile. Abbiamo trovato tre parole chiave simili in queste due frasi: Apple, 2023 e profit.
Tuttavia, sappiamo che la prima e la terza frase sono la coppia semanticamente più simile. Il livello di attenzione all’interno dell’architettura Transformer può catturare questo contesto e restituire la prima e la terza come la coppia semanticamente più simile.
Le potenti prestazioni e la versatilità dei modelli Transformer hanno portato a rapidi progressi nell’IA in diversi campi, dalla Computer Vision all’NLP e ai compiti multimodali.
Uno dei modelli introdotti dopo il grande successo dei Transformer è il modello Generative Pretrained Transformers (GPT). Questo modello utilizza la parte decoder dell’architettura Transformer per prevedere il token successivo in una sequenza di input ed è usato come spina dorsale di molti LLM che conosciamo finora, come ChatGPT e Llama.
Architettura GPT
Questi LLM sono molto potenti nel generare risposte simili a quelle umane, poiché sono stati addestrati su enormi quantità di dati. Tuttavia, come potresti già sapere, i dati di addestramento hanno una data limite, il che significa che non otterremo una risposta accurata dai nostri LLM se chiediamo informazioni più recenti dei loro dati di addestramento. È qui che dobbiamo personalizzare i nostri LLM.
Generazione aumentata tramite recupero (RAG)
Il primo modo in cui possiamo personalizzare il nostro LLM è tramite RAG, e il suo concetto è piuttosto semplice. Forniamo agli LLM sia la query sia i contesti rilevanti come input, consentendo loro di generare risposte contestuali e accurate sfruttando i contesti forniti.
Architettura RAG
Per sfruttare gli LLM per RAG, abbiamo bisogno di due componenti essenziali:
Modello di embedding vettoriale: Un modello che trasforma la nostra query e i contesti in embedding vettoriali.
Database vettoriale: Un database per archiviare tutti gli embedding dei contesti ed eseguire la ricerca vettoriale per fornire ai nostri LLM i contesti più rilevanti e semanticamente simili in base alla query.
Diversi modelli possono essere utilizzati per generare embedding vettoriali, inclusi modelli di deep learning di OpenAI o sentence transformers. In alternativa, possono essere impiegati anche modelli tradizionali basati su bag-of-words come TF-IDF o BM25.
Milvus è un popolare database vettoriale open-source. Memorizza i dati necessari, costituiti da due tipi: embedding vettoriali generati dal modello e i relativi metadati. Ad esempio, considera un frammento di testo da un articolo pubblicato da Towards Data Science il primo giorno di giugno 2023. I dati memorizzati nel database vettoriale Milvus potrebbero apparire così:
Esempio di dati di embedding vettoriale e dei relativi metadati
I metadati sono utili per eseguire vari filtri durante le operazioni di ricerca vettoriale, al fine di fornire ai nostri LLM contesti più precisi. Ad esempio, potresti voler recuperare contesti da una pubblicazione specifica o quelli pubblicati dopo una certa data (ad es., 2020).
Una volta che abbiamo la query e sappiamo quali metadati specifici vogliamo filtrare, un database vettoriale come Milvus farà il suo lavoro. Eseguirà una ricerca vettoriale per trovare i contesti semanticamente più simili alla nostra query che soddisfano le condizioni di filtraggio dei metadati.
Fine-Tuning
Un altro approccio alla personalizzazione degli LLM è il fine-tuning. Il concetto è semplice: addestriamo un LLM pre-addestrato sui nostri dati, ottenendo modelli con nuovi pesi adattati per svolgere attività specifiche del nostro dominio di dati.
Esistono diversi modi per effettuare il fine-tuning degli LLM:
Full Fine-Tuning: Questo approccio modifica i pesi di tutti i parametri all'interno dell'LLM originale. Tuttavia, comporta un processo di calcolo costoso.
LORA: Questo approccio introduce adattatori a basso rango all'interno dell'architettura dell'LLM. I pesi originali vengono congelati durante il fine-tuning e vengono aggiornati solo i pesi degli adattatori.
QLORA: Questo approccio introduce la quantizzazione nel metodo LORA originale, riducendo i costi computazionali e le risorse preservando al contempo prestazioni ragionevoli.
Full fine-tuning vs LORA
Ora che conosciamo i diversi metodi di fine-tuning, discutiamo le diverse tecniche di fine-tuning:
Supervised Fine-Tuning: In questo metodo, forniamo ai nostri LLM i nostri dati di addestramento e le etichette corrispondenti. Quindi addestriamo i nostri LLM come qualsiasi modello di machine learning supervisionato.
Reinforcement Learning from Human Feedback (RLHF): Questo metodo incorpora la teoria dell'apprendimento per rinforzo. Raccogliamo varie risposte dall'LLM in base a una query e poi valutiamo la qualità di ciascuna risposta. Nel tempo, i nostri LLM producono risposte che si allineano alle nostre preferenze.
Supervised fine-tuning vs. Reinforcement Learning from Human Feedback
Poiché il fine-tuning supervisionato è semplice, discutiamo RLHF più nel dettaglio. Uno svantaggio dell'RLHF nativo è la necessità che gli esseri umani valutino la qualità delle risposte generate dagli LLM. Questo approccio è costoso e richiede tempo.
I data scientist hanno introdotto Proximal Policy Optimization (PPO) per alleviare questo problema.PPO introduce un modello di ricompensa per sostituire la valutazione umana. Tuttavia, questo modello di ricompensa deve essere addestrato separatamente, rendendo l'applicazione di PPO complessa. Inoltre, il modello di ricompensa deve essere riaddestrato ogni volta che vengono aggiunti nuovi dati.
Per affrontare questi problemi, è stata introdotta Direct Preference Optimization (DPO). DPO ottimizza la policy dell'LLM utilizzando la funzione di perdita negative log-likelihood sui dati delle preferenze umane. Il dataset per il fine-tuning con DPO è composto da prompt, risposte preferite e risposte non preferite:
Esempio del formato dei dati utilizzato per effettuare il fine-tuning degli LLM con DPO
Tuttavia, DPO tende ad andare rapidamente in overfitting sul dataset delle preferenze. Per mitigare questo problema, è stata sviluppata Identity Preference Optimization (IPO).
IPO introduce un termine di regolarizzazione nella funzione di perdita DPO per evitare l'overfitting. Utilizza anche un termine di rapporto delle probabilità logaritmiche aggiunto alla funzione di perdita di log-verosimiglianza negativa (NLL), consentendo di affinare l'LLM allo stile desiderato penalizzando al contempo le risposte non preferite.
Conclusione
Yujian Tang ha discusso vari modi per personalizzare gli LLM per un uso ottimale nei nostri casi d'uso specifici nel suo intervento. La presentazione è iniziata fornendo una breve storia dei progressi dell'AI che hanno portato allo sviluppo degli LLM. Questo argomento è stato seguito da una spiegazione di due metodi per personalizzare gli LLM: RAG e fine-tuning.
RAG migliora la qualità delle risposte generate dagli LLM inserendo contesti pertinenti insieme alla query come input. Database vettoriali come Milvus memorizzano gli embedding di contesto ed eseguono ricerche vettoriali per implementare RAG. Gli LLM utilizzano quindi questi contesti per generare risposte appropriate.
Il secondo approccio è il fine-tuning, e ci sono due metodi di fine-tuning:
Fine-Tuning Supervisionato: Questo metodo consiste nel fornire ai nostri LLM i nostri dati di addestramento e le relative etichette, per poi addestrarli come qualsiasi modello di machine learning supervisionato.
Reinforcement Learning from Human Feedback (RLHF): Questo metodo incorpora la teoria del reinforcement learning, in cui raccogliamo varie risposte dall'LLM basate su una query e valutiamo la qualità di ciascuna risposta. Nel tempo, i nostri LLM producono risposte allineate alle nostre preferenze.
Per maggiori dettagli sulla personalizzazione degli LLM, guarda il replay dell'intervento di Yujian.
Continua a leggere
Why I’m Against Claude Code’s Grep-Only Retrieval? It Just Burns Too Many Tokens
Learn how vector-based code retrieval cuts Claude Code token consumption by 40%. Open-source solution with easy MCP integration. Try claude-context today.
Milvus/Zilliz + Surveillance: How Vector Databases Transform Multi-Camera Tracking
See how Milvus vector database enhances multi-camera tracking with similarity-based matching for better surveillance in retail, warehouses and transport hubs.
Cosmos World Foundation Model Platform for Physical AI
NVIDIA's Cosmos platform enables safe, digital twin training of GenAI models for physical applications, overcoming data scarcity and safety challenges.