LoRA fine tuning: dagli adattatori al modello in produzione

Il LoRA fine tuning è un passo sensato quando errori ricorrenti di stile, formato o esecuzione del compito persistono anche con un prompt ben costruito. Per ogni matrice di pesi da adattare, addestra 2 piccole matrici e mantiene congelati i pesi originali; QLoRA conserva anche il modello di base congelato con una precisione di 4-bit. Il risultato che conta è un miglioramento misurato sul proprio compito, accompagnato da una modalità di messa in produzione che lo preservi.

Documentazione e vincoli di distribuzione verificati il 26 ottobre 2026. I meccanismi descritti derivano dai lavori originali su LoRA e QLoRA.

Per chi sviluppa un'applicazione, la decisione parte da un errore ricorrente. Un modello per l'assistenza clienti ha nel contesto la procedura corretta, ma continua a scegliere l'etichetta sbagliata per l'escalation. Un assistente di scrittura comprende il brief, ma ignora ripetutamente lo stile editoriale richiesto. Sono casi in cui vale la pena considerare il fine-tuning. Se invece al modello manca la politica sui rimborsi in vigore oggi, prima di addestrarlo bisogna dargli accesso a quella politica.

Come funziona il LoRA fine tuning?

LoRA modifica il comportamento di un modello apprendendo una piccola correzione per alcune matrici di pesi. Nell'addestramento LoRA ordinario, le matrici originali rimangono congelate. Una matrice di pesi è una tabella di valori numerici appresi che trasforma le informazioni all'interno del modello; un adattatore è l'insieme aggiuntivo di parametri appresi che modifica quella trasformazione.

Si può immaginare di aggiungere a un edificio un modulo d'ingresso su misura. La struttura resta la stessa, ma cambia il modo in cui le persone la attraversano. Il modulo è più piccolo dell'edificio, ma continua a dipendere da esso. Allo stesso modo, un adattatore LoRA non è un modello linguistico completo e non sostituisce il modello di base.

Il nome significa Low-Rank Adaptation, cioè adattamento a basso rango. Invece di apprendere un aggiornamento delle stesse dimensioni della matrice di pesi, LoRA lo rappresenta come il prodotto di matrici più piccole, solitamente chiamate A e B. In uno strato lineare, la trasformazione effettiva si può scrivere come W + sBA: i pesi congelati W più l'aggiornamento dell'adattatore moltiplicato per un fattore di scala. L'input attraversa sia il percorso di base sia quello dell'adattatore, e i rispettivi output vengono sommati. Formulazione originale di LoRA.

Ecco perché l'adattatore può apprendere un formato aziendale senza salvare una copia modificata di ogni peso del modello di base. È anche il motivo per cui quel modello deve già essere una base plausibile per il compito: la correzione deve funzionare con il modello scelto.

Un esempio sui parametri, non una promessa sulla memoria GPU

Consideriamo uno strato ipotetico con 4,096 × 4,096 pesi, ossia 16,777,216 parametri originali. Con rango 8, le matrici LoRA hanno rispettivamente 8 × 4,096 e 4,096 × 8 parametri. In totale sono 65,536 parametri addestrabili, circa lo 0.39% del numero di parametri della matrice originale.

È un nostro calcolo basato sulle dimensioni delle matrici descritte nel paper, non un benchmark né un rango consigliato. Riguarda una singola matrice adattata. I pesi congelati rimangono presenti e l'addestramento richiede comunque memoria di lavoro per i calcoli intermedi, i gradienti dell'adattatore e lo stato dell'ottimizzatore. Quest'ultimo contiene le informazioni usate per determinare il successivo aggiornamento durante l'addestramento.

La distinzione pratica è tra quanti parametri vengono aggiornati e quanta memoria serve all'intero processo. Un adattatore minuscolo non rende minuscolo il modello sottostante.

La distinzione tra i metodi segue i paper su LoRA e QLoRA. Nessuna di queste etichette garantisce un determinato risultato sui propri dati.

Rango, moduli di destinazione e scala: i parametri di LoRA

Le impostazioni controllano dimensioni e posizione della correzione, non quanto diventa intelligente il modello. Il rango è la dimensione interna di A e B: aumentarlo aggiunge parametri addestrabili. I moduli di destinazione indicano quali parti del modello ricevono gli adattatori. Alpha regola la scala dell'aggiornamento, mentre il dropout può regolarizzare l'addestramento degli adattatori. La documentazione della configurazione LoRA definisce questi controlli.

Conviene partire da una procedura mantenuta e aggiornata per il proprio modello, poi modificare un'impostazione quando un risultato di validazione lo giustifica. Se il modello confonde due categorie di assistenza, vanno prima controllate le etichette contraddittorie e i casi limite mancanti. Aumentare il rango non può spiegare al modello quale, tra due esempi contraddittori, l'azienda considera corretto.

Occorre anche verificare quali parametri siano effettivamente addestrabili. Alcune configurazioni addestrano moduli aggiuntivi, come la testa di output, insieme agli adattatori. Chiamare un addestramento «LoRA» non dimostra che siano cambiate solo A e B: lo stabilisce la configurazione.

Che cosa aggiunge QLoRA e quali limiti restano?

QLoRA interviene sia sulla memoria occupata dal modello di base congelato sia sul numero di parametri addestrati. La configurazione fondamentale memorizza il modello di base in formato 4-bit e lo usa per addestrare adattatori LoRA a precisione maggiore. Il modello di base è congelato, ma partecipa comunque al calcolo necessario per apprendere l'adattatore. Paper su QLoRA.

Il paper combina NF4, una rappresentazione numerica progettata per pesi con distribuzione normale; la doppia quantizzazione, che comprime le costanti usate nella quantizzazione; e gli ottimizzatori paginati, che gestiscono i picchi di memoria. Per usare una procedura QLoRA mantenuta e aggiornata non è necessario implementare questi meccanismi da zero.

L'espressione «addestramento a 4-bit» si presta a equivoci. Non significa che ogni calcolo, attivazione e parametro dell'adattatore utilizzi quattro bit. Né significa che sia possibile addestrare un modello con la stessa memoria necessaria a caricarne semplicemente i pesi quantizzati. Esempi lunghi e batch più grandi continuano a consumare memoria di lavoro.

QLoRA ha senso quando l'ostacolo è la memoria occupata dal modello di base e lo stack di addestramento supporta il modello necessario. Se il LoRA ordinario rientra già nella memoria disponibile, è meglio confrontare i due metodi sui casi di validazione, senza presumere che la quantizzazione sia sempre preferibile. La compressione modifica la configurazione numerica: il suo effetto sul compito va valutato.

La nostra guida alla quantizzazione degli LLM affronta la distinta questione della distribuzione: quale rappresentazione compressa può eseguire il motore di inferenza. Addestrare un adattatore QLoRA non lo rende compatibile con ogni formato quantizzato usato in produzione.

Quando conviene il fine-tuning rispetto a prompting e RAG?

Il fine-tuning è indicato quando l'errore residuo riguarda un comportamento stabile che si può mostrare con esempi approvati. Il prompting basta se istruzioni chiare soddisfano già il requisito. La retrieval-augmented generation, o RAG, serve a fornire documenti pertinenti o dati dal database al momento della richiesta. Il percorso decisionale completo è nella guida RAG o fine-tuning.

Per lo stile editoriale, conviene prima inserire nel prompt una specifica concisa dello stile e alcuni esempi rappresentativi. L'addestramento diventa un'opzione quando il comportamento desiderato è definito e le stesse violazioni continuano a presentarsi con input diversi. Gli esempi devono insegnare scelte, come dare subito la risposta o evitare superlativi non supportati, invece di limitarsi a ripetere una formula.

Per il formato, bisogna distinguere la sintassi dal significato. Se il runtime supporta output strutturati vincolati, vanno provati prima di addestrare un modello soltanto per ottenere JSON valido. Una risposta può rispettare lo schema e scegliere comunque la categoria sbagliata. LoRA diventa più interessante quando il problema persistente riguarda quella decisione semantica. La validazione nell'applicazione va mantenuta anche dopo il miglioramento dell'adattatore.

Per un compito circoscritto, occorre definire il confine tra le decisioni. Un ticket su un addebito non riconosciuto potrebbe richiedere la verifica dell'account, mentre un pagamento duplicato già confermato richiede un controllo della fatturazione. L'addestramento deve usare coppie input-output approvate che mostrino la differenza, inclusi i casi in cui servono chiarimenti. Il beneficio è una decisione ripetibile migliore, non una generica dimostrazione di maggiore intelligenza del modello.

Per le conoscenze che cambiano, il recupero delle informazioni resta il riferimento più appropriato. Un adattatore di stile non dovrebbe essere la fonte autorevole sulla disponibilità attuale di un prodotto. Recupero delle informazioni e fine-tuning possono essere combinati: si recupera la procedura più recente e si addestra il modello a usare le evidenze fornite e a restituire la risposta nella struttura richiesta. L'applicazione combinata va valutata usando lo stesso contesto recuperato per entrambi i termini del confronto.

Per chi sviluppa, significa misurare l'errore residuo prima di scegliere lo stack di addestramento. Per chi gestisce il servizio, significa assumersi la responsabilità degli esempi approvati e decidere quali errori contano. Per chi acquista, significa chiedere un confronto dei risultati prima e dopo e sapere esattamente quale artefatto sarà utilizzabile in produzione, senza accettare «modello personalizzato» come prova di miglioramento.

Se un modello insegnante più grande fornisce esempi di addestramento a un modello più piccolo, si tratta anche di un processo di distillazione del modello. LoRA descrive quali parametri aggiorna il modello studente; la distillazione descrive da dove arriva il segnale di addestramento. Si possono usare insieme, ma gli output di riferimento generati richiedono comunque una revisione.

API gestita o GPU propria: quale percorso scegliere?

Il servizio gestito è indicato quando i modelli supportati, il trattamento dei dati e le opzioni di distribuzione sono adatti all'applicazione. Una GPU propria è preferibile quando serve il controllo su checkpoint, procedura di addestramento e runtime, e si è in grado di gestire quello stack. La modalità di inferenza va scelta prima di avviare l'addestramento.

Together AI: addestramento LoRA esplicito ed esportazione

Together AI offre un'API di fine-tuning gestita la cui guida introduttiva avvia esplicitamente un addestramento LoRA. La chiamata Python client.fine_tuning.create() usa LoRA per impostazione predefinita e permette di specificare lora=True. Il flusso prevede la preparazione dei dati conversazionali, la loro validazione e il caricamento, l'addestramento e infine la distribuzione del risultato. Guida introduttiva di Together AI.

Il vincolo da verificare è la possibilità effettiva di distribuire il modello. Il supporto all'addestramento non equivale alla disponibilità serverless, e la guida attuale prevede l'inferenza dedicata per i modelli sottoposti a fine-tuning. Prima di impegnarsi su un modello di base, bisogna verificare che disponga di un'opzione di distribuzione dedicata supportata.

L'esportazione è una scelta separata. Together documenta checkpoint="adapter" per i soli pesi dell'adattatore e checkpoint="merged" per un checkpoint che unisce modello di base e adattatore. L'adattatore è adatto quando il runtime lo caricherà sul modello di base corrispondente; l'artefatto unificato serve quando occorre un modello autonomo. Distribuzione e tipi di checkpoint.

Fireworks AI: verificare separatamente addestramento e inferenza

Fireworks AI documenta LoRA nel proprio flusso gestito di fine-tuning supervisionato. Il supervised fine-tuning, o SFT, apprende da esempi della risposta desiderata. Per configurare esplicitamente l'addestramento di un adattatore, l'API REST usa loraRank; l'SDK Python usa lora_rank. Documentazione SFT di Fireworks.

La distinzione da controllare è tra Tunable e Supports Lora. Un modello di base può supportare in inferenza un adattatore addestrato altrove senza consentire l'addestramento su Fireworks. La guida all'addestramento accetta anche un evaluation_dataset separato: è quindi possibile fornire esempi di validazione invece di affidarsi alla suddivisione automatica.

Per l'inferenza, Fireworks documenta il live merge, che incorpora un adattatore al momento della distribuzione, e il multi-LoRA, che applica l'adattatore selezionato a un modello di base condiviso. La guida attuale alla distribuzione indica che gli adattatori LoRA addestrati richiedono istanze dedicate on-demand; la distribuzione serverless non è supportata. Specifica inoltre che le configurazioni di distribuzione FP8 e FP4 non supportano componenti aggiuntivi LoRA. Un'opzione di distribuzione compressa non è quindi automaticamente compatibile con gli adattatori. Guida alla distribuzione di Fireworks.

Fine-tuning con LoRA: meglio PEFT o Unsloth?

Hugging Face PEFT è la libreria aperta dedicata ai metodi di fine-tuning che limitano il numero di parametri addestrati, tra cui LoRA. È adatta quando serve un controllo esplicito sul modello, sulla configurazione della quantizzazione e sui moduli degli adattatori. La sua guida alla quantizzazione documenta come caricare un modello di base quantizzato, prepararlo per l'addestramento e poi aggiungere l'adattatore.

Il percorso QLoRA documentato usa BitsAndBytesConfig con load_in_4bit=True, NF4 e doppia quantizzazione; prepare_model_for_kbit_training() prepara il modello prima che get_peft_model() lo integri con l'adattatore. Per applicare gli adattatori agli strati lineari secondo l'approccio QLoRA, la guida usa target_modules="all-linear". È uno schema di configurazione supportato, non la prova che ogni architettura o runtime a valle accetti qualsiasi adattatore.

Il limite di PEFT riguarda tutto il resto del sistema di addestramento: non sceglie gli esempi, non corregge il template della chat e non fornisce la metrica con cui misurare il successo del prodotto.

Unsloth è un toolkit aperto per l'addestramento, con guide e notebook per il fine-tuning mantenuti e aggiornati. La sua guida documenta LoRA, QLoRA e il fine-tuning completo, incluso load_in_4bit=True per il percorso quantizzato. È una scelta adatta quando un notebook aggiornato corrisponde al modello e all'hardware previsti: quel notebook diventa la procedura di partenza. Guida al fine-tuning di Unsloth.

Il limite di Unsloth è la compatibilità della procedura. Un notebook che porta a termine l'addestramento non dimostra che il modello esportato manterrà lo stesso comportamento altrove. Tokenizer, template della chat e impostazioni di generazione devono restare coerenti; va poi valutato l'artefatto effettivamente usato per l'inferenza. Il template della chat è la formattazione che indica al modello i ruoli dei messaggi, come utente e assistente.

Hugging Face TRL mette a disposizione SFTTrainer, un ciclo di addestramento supervisionato che si integra con PEFT. Supporta dataset di addestramento e valutazione e, con template della chat compatibili, assistant_only_loss=True, per apprendere dalle risposte dell'assistente invece che da ogni token della conversazione. Il vincolo è che il template deve supportare la maschera necessaria a identificare i token dell'assistente: occorre ispezionare gli esempi di addestramento dopo l'applicazione del template. SFTTrainer di TRL.

Per un esperimento su GPU propria, la sequenza è concreta: scegliere un modello di base e una procedura supportati, applicare il template a una conversazione di esempio, controllare quali token contribuiscono alla funzione di perdita, aggiungere l'adattatore, fornire i dati di addestramento e validazione e salvare i checkpoint. Un checkpoint è una versione salvata che si può valutare o ripristinare. La nostra guida più ampia su come eseguire il fine-tuning di un LLM affronta le altre decisioni del progetto.

Come distribuire gli adattatori e passare da uno all'altro

Un adattatore deve essere accompagnato dall'identità e dalla configurazione del modello di base. In PEFT, save_pretrained() salva i pesi dell'adattatore e adapter_config.json; questi file non sostituiscono i pesi di base. Insieme all'adattatore vanno conservati la revisione esatta del modello di base, il tokenizer, il template della chat e la configurazione di addestramento. Formato dei checkpoint PEFT.

Mantenere separati gli adattatori è utile quando più varianti del compito devono condividere un modello di base o quando conta poter passare da una variante all'altra. In PEFT, load_adapter() carica un altro adattatore identificato da un nome e set_adapter() lo seleziona. Caricamento e attivazione sono operazioni diverse. Il gestore di contesto disable_adapter() permette di eseguire l'inferenza con il comportamento del modello di base. API dei modelli PEFT.

La distinzione è utile per la valutazione, ma in un'applicazione condivisa la selezione degli adattatori deve anche gestire correttamente le richieste concorrenti. Non si può cambiare l'adattatore attivo di un unico modello globale mentre sono in corso richieste indipendenti e presumere che ognuna riceva il comportamento previsto. Serve un runtime di inferenza che definisca esplicitamente come instradare ogni singola richiesta.

vLLM è un motore di inferenza che supporta LoRA nelle implementazioni dei modelli compatibili. Il server usa --enable-lora e --lora-modules per registrare gli adattatori; le richieste ne selezionano uno tramite il campo model. Vanno verificati il supporto LoRA del modello, il rango massimo degli adattatori e la capacità configurata per usarli contemporaneamente. Sono vincoli dell'inferenza, non impostazioni di addestramento. Documentazione LoRA di vLLM.

Sono documentati anche il caricamento e la rimozione a runtime, ma vLLM sconsiglia questa funzione in produzione, a meno che l'ambiente non sia isolato e completamente fidato. Per una distribuzione ordinaria, registrare gli adattatori noti all'avvio è una scelta operativa più semplice.

Incorporare l'adattatore nel modello di base è indicato quando serve un modello autonomo e non occorre poter cambiare adattatore in quell'artefatto. La funzione merge_and_unload() di PEFT integra l'aggiornamento nei pesi di base e restituisce un modello privo delle funzionalità degli adattatori PEFT. Alcune configurazioni di quantizzazione non supportano questa fusione. Per poter riprendere in seguito il flusso con adattatori separati, bisogna conservare separatamente l'adattatore originale e il modello di base. Limiti della fusione in PEFT.

La portabilità ha un'ultima insidia: il modello di base corrispondente deve avere esattamente gli stessi pesi, non soltanto un nome di famiglia riconoscibile. Fireworks avverte esplicitamente che il checkpoint del fornitore usato per l'addestramento può differire dai pesi pubblici. Questa dipendenza va verificata prima di portare un adattatore fuori dalla piattaforma. Indicazioni per l'esportazione degli adattatori.

Fine-tuning con LoRA: come valutare il prima e il dopo

Si passa in produzione solo quando l'adattatore scelto migliora il comportamento desiderato su esempi che non hanno influito sulla sua selezione. Una funzione di perdita in calo durante l'addestramento indica che il modello si adatta meglio agli esempi usati per addestrarlo; non è un criterio di rilascio.

Il seguente protocollo di valutazione si applica all'esempio dello smistamento delle richieste di assistenza. È una procedura consigliata, non il resoconto di un esperimento di addestramento.

1. 1

   Scrivere i criteri di accettazione prima dell'addestramento

   Definire le etichette ammesse, i campi obbligatori dell'output e il comportamento previsto per l'escalation. Stabilire quali errori bloccano il rilascio. Per lo stile editoriale, formulare regole osservabili come «dare la risposta prima del contesto» e «non aggiungere affermazioni prive di riscontro». Un'indicazione vaga come scrivere meglio non permette un confronto affidabile.

2. 2

   Separare i casi di addestramento, validazione e test finale

   I casi di addestramento aggiornano l'adattatore. Quelli di validazione servono a scegliere la procedura e il checkpoint. Il test finale resta chiuso finché queste scelte non sono definitive. Ticket correlati, parafrasi dello stesso documento ed esempi quasi duplicati devono restare nello stesso sottoinsieme. Altrimenti il test rischia di premiare la familiarità anziché la generalizzazione.

3. 3

   Registrare un solido riferimento di partenza

   Eseguire il modello di base non adattato con il miglior prompt concretamente utilizzabile e con gli eventuali controlli sull'output strutturato che si intende mantenere. Per un'applicazione con recupero delle informazioni, registrare anche le evidenze recuperate. Salvare revisione del modello, prompt, template, impostazioni di generazione, output e versione del valutatore. L'adattatore deve superare un'alternativa praticabile, non un prompt deliberatamente debole.

4. 4

   Scegliere sulla validazione, poi confrontare sul test riservato

   Usare i risultati di validazione per scegliere il checkpoint e rendere definitiva la scelta. Eseguire quell'adattatore e il modello di riferimento sugli stessi input del test finale, con impostazioni equivalenti. Se l'applicazione prevista usa un prompt più breve dopo l'addestramento, misurare questo cambiamento separatamente dal confronto controllato dell'adattatore, così da mantenere chiara l'origine del miglioramento.

5. 5

   Valutare l'artefatto che verrà usato in produzione

   Dopo la fusione, la quantizzazione o il cambio di motore di inferenza, ripetere le verifiche di accettazione sull'artefatto distribuito. Includere input lunghi, richieste ambigue e casi in cui il comportamento di base deve restare invariato. Rilasciare solo se il miglioramento desiderato si mantiene dopo la distribuzione e i controlli di regressione restano accettabili.

Sintassi, correttezza sul compito e stile devono avere punteggi separati. Per il modello di assistenza, un oggetto JSON impeccabile con una decisione di escalation sbagliata resta un errore. Per il modello di scrittura, una risposta più curata che inventa un'affermazione sul prodotto è una regressione.

Vanno riportati i denominatori e i risultati per categoria, non soltanto una percentuale complessiva di successo. La precisione misura quanto spesso una categoria prevista è corretta; il richiamo misura quanti casi effettivi di quella categoria il modello riesce a individuare. Se la maggior parte degli esempi riguarda domande ordinarie sulla fatturazione, la media complessiva può nascondere errori in una classe di escalation piccola ma importante. Bisogna includere sia i successi diventati errori sia gli errori diventati successi.

Per la valutazione soggettiva dello stile, va nascosta l'origine degli output e variato l'ordine di presentazione. Un valutatore basato su un modello può aiutare a organizzare la revisione, ma le sue decisioni vanno confrontate con i giudizi umani prima di usare il suo punteggio come criterio di rilascio. A determinarne l'utilità è la griglia di valutazione, non la fluidità con cui il valutatore spiega il proprio giudizio.

Il test finale non deve diventare un secondo insieme di validazione. Una volta esaminati i suoi errori e usati per modificare la procedura, quei casi hanno influito sullo sviluppo. Vanno conservati come casi di regressione, riservando esempi nuovi e mai utilizzati al confronto finale successivo. Non esiste una regola universale sulla dimensione del dataset: ciò che conta è che la valutazione rappresenti le decisioni che l'applicazione dovrà affrontare.

Infine, bisogna confrontare latenza e consumo di risorse del sistema distribuito con il carico di lavoro previsto. Il risparmio di parametri di LoRA non dimostra una maggiore velocità di inferenza. Va conservata la versione di modello di base e adattatore che ha superato i controlli, mantenuta una versione a cui tornare in caso di problemi e monitorate le stesse categorie di errore dopo il rilascio.

Quali promesse su LoRA sono esagerate?

«Fine-tuning economico» descrive un'ottimizzazione più circoscritta di «personalizzazione economica». Servono comunque esempi approvati, valutazione, infrastruttura di inferenza e manutenzione. Né un checkpoint più piccolo né un log di addestramento concluso con successo dimostrano che l'applicazione sia migliorata.

Pesi congelati non significa comportamento congelato. L'adattatore modifica deliberatamente gli output del modello: capacità generali, comportamento di rifiuto e qualità delle risposte richiedono quindi controlli di regressione. Rimuovere l'adattatore può ripristinare il percorso di base; lasciarlo attivo non garantisce risposte invariate negli altri casi.

Non è garantito che LoRA eguagli il fine-tuning completo. Il paper originale riporta risultati solidi sui compiti valutati. È una prova a favore del metodo, non un teorema di equivalenza universale. Se un adattatore valutato con cura continua a non soddisfare il requisito, vanno esaminati dati, modello di base e compito prima di presumere che basti un addestramento più esteso.

Non esistono un rango magico, un numero di esempi o una stima di ore GPU validi per tutti. Architettura del modello, lunghezza delle sequenze, moduli di destinazione e compito effettivo cambiano l'esperimento. Conviene partire da una procedura documentata e lasciare che sia la validazione a giustificare la modifica successiva.

Domande frequenti sul fine-tuning con LoRA

Che cos'è il fine-tuning con LoRA?

Consiste nell'addestrare matrici aggiuntive a basso rango mantenendo congelati i pesi originali del modello di base. L'adattatore appreso modifica il calcolo di base e, per l'inferenza, ha bisogno di quel modello, a meno che i pesi non vengano uniti.

È stato dimostrato che il fine-tuning non funziona?

Un esperimento fallito o un benchmark non permettono un verdetto generale. Per la propria applicazione, bisogna confrontare, su casi tenuti da parte, il modello di riferimento dotato del miglior prompt concretamente utilizzabile con il modello addestrato. Se il comportamento richiesto non migliora, il modello non va messo in produzione.

Quanto costa il fine-tuning?

Dipende dal modello, dai dati elaborati, dalla procedura di addestramento e dall'infrastruttura scelta per l'inferenza. LoRA riduce i parametri addestrabili, ma non elimina preparazione dei dati, valutazione e hosting. Prima di consultare le tariffe pubblicate in vigore, va scelto un percorso supportato per addestramento e inferenza: un prezzo universale per un addestramento non sarebbe utile.

Qual è un esempio concreto di fine-tuning?

L'addestramento su messaggi di assistenza approvati, abbinati alla categoria corretta, all'azione di escalation e al formato di risposta. Gli esempi insegnano uno schema decisionale ricorrente; i dati aggiornati del cliente devono comunque essere forniti al momento della richiesta.

Il fine-tuning si usa ancora?

Sì. Together AI, Fireworks AI, Hugging Face PEFT e Unsloth documentano percorsi di addestramento attuali. La scelta dipende dall'errore che rimane dopo il prompting e, quando necessario, il recupero delle informazioni.

Come si esegue il fine-tuning?

Si definisce una metrica per il compito, si stabilisce un riferimento di partenza, si preparano dati separati per addestramento e valutazione e si scelgono un modello e una procedura supportati. Poi si addestra, si seleziona tramite validazione e, prima della distribuzione, si esegue il confronto su un test riservato. Va verificato anche l'artefatto effettivamente distribuito.

Che cosa sono PEFT e LoRA?

PEFT significa parameter-efficient fine-tuning: una famiglia di metodi che addestra un insieme limitato di parametri. Hugging Face PEFT è anche una libreria che implementa questi metodi. LoRA è uno dei metodi appartenenti a questa famiglia.

Quali modelli consentono il fine-tuning?

Bisogna consultare l'elenco esatto dei modelli supportati dal servizio gestito o dallo stack aperto di addestramento scelto, insieme alla licenza del modello. Supporto all'addestramento, supporto agli adattatori in inferenza e disponibilità dei pesi di base sono verifiche separate. Il solo nome della famiglia non basta.

Come si può chiamare il fine-tuning in italiano?

In questo contesto, adattamento a un compito o prosecuzione dell'addestramento su esempi mirati. Il prompt engineering modifica le istruzioni fornite durante l'inferenza; il fine-tuning modifica i parametri appresi.

Il prossimo passo per il proprio progetto

La prossima settimana, conviene partire da un errore ricorrente nell'applicazione che si gestisce già e trasformarlo in un test di accettazione esplicito. Raccogliere esempi approvati, individuare i casi correlati e tenerli insieme prima di suddividere i dati, quindi misurare il modello di riferimento con il miglior prompt. Se quel riferimento fallisce su un comportamento stabile, scegliere un percorso LoRA documentato il cui risultato sia utilizzabile in produzione. L'addestramento comincia solo quando queste decisioni sono chiare.

Per guide pratiche allo sviluppo e alla valutazione dei sistemi di AI, iscriviti alla newsletter.