Tutti vogliono personalizzare l’IA. Pochi capiscono davvero le opzioni.

Hai documenti aziendali che il modello non ha mai visto, uno stile di scrittura specifico che ignora o conoscenze di dominio che continuano a finire in allucinazioni, e vuoi un’IA che funzioni davvero nel tuo contesto — invece di produrre risposte generiche che mancano il bersaglio.

Esistono tre strade: prompting, RAG e fine-tuning. Il settore le tratta come una scala in cui si sale dal semplice al sofisticato, ma questo modo di vederla porta a errori costosi, perché ogni approccio risolve problemi fondamentalmente diversi e scegliere in base alla complessità percepita, invece che alla reale aderenza al caso, spreca sia tempo sia denaro.

La scomoda verità sul fine-tuning

Partiamo dall’opzione che suona più impressionante.

Il fine-tuning cambia il modello stesso. Gli dai esempi di input e output desiderato, e il processo di addestramento regola i pesi interni del modello per produrre quel tipo di output con più costanza, in pratica insegnando al modello nuovi comportamenti tramite esposizione ripetuta ai tuoi schemi specifici.

Sembra potente. Lo è.

Ed è anche quasi mai ciò di cui hai bisogno.

Su Hacker News, intellectronica l’ha detta senza giri di parole: “Fine-tuning is super important and powerful…in reality for most use cases it offers little advantage for a lot of effort.” Quella valutazione continua a rivelarsi vera nelle implementazioni reali, dove i team passano mesi a preparare dati di addestramento solo per scoprire che dei buoni prompt avrebbero risolto il problema in un pomeriggio.

L’equivoco è profondo. Molti presumono che il fine-tuning insegni al modello nuovi fatti nello stesso modo in cui lo studio insegna agli esseri umani, ma dvt su Hacker News ha contestato l’idea in modo diretto: “It does not teach the model new knowledge.” Il fine-tuning cambia comportamento e stile, non la conoscenza di base a cui il modello può accedere, il che significa che se il tuo problema è che il modello non conosce i prodotti o le policy della tua azienda, il fine-tuning non lo risolverà.

Dove il fine-tuning brilla è nella costanza. Se ti serve un modello che produca JSON perfettamente formattato ogni singola volta, o che mantenga un tono identico su migliaia di interazioni, o che gestisca un compito ristretto con affidabilità quasi meccanica, il fine-tuning offre ciò che i prompt non possono garantire.

Il costo rende questa decisione seria. Le sessioni di addestramento vanno da qualche centinaio di dollari per modelli piccoli a decine di migliaia per qualsiasi cosa di sostanziale. La preparazione dei dati spesso raddoppia l’investimento totale, perché servono esempi di alta qualità esattamente nel formato che la pipeline di addestramento si aspetta. E quando cambiano i requisiti? Si addestra di nuovo.

Perché di solito vince il RAG

Ecco ciò di cui la maggior parte dei team ha davvero bisogno: un’IA che sappia le cose che contano per loro.

Il RAG funziona in modo diverso. Invece di cambiare il modello, costruisci un sistema di recupero che trova documenti rilevanti quando un utente fa una domanda, poi includi quei documenti nel prompt così il modello ha le informazioni necessarie per rispondere in modo accurato.

Il modello resta generico. La conoscenza resta esterna.

Questa distinzione conta enormemente. Quando cambia la documentazione del tuo prodotto, aggiorni i documenti e il RAG usa subito le nuove informazioni. Nessun riaddestramento. Nessun team di data science. Basta aggiornare i file.

Un professionista su Hacker News ha descritto così il compromesso: “RAG is focused more on capturing and using external resources on an ad hoc basis, where fine tuning looks to embed a specific ‘behaviour’ change in the model for a particular need.” Coglie perfettamente il punto. Il RAG gestisce il cosa. Il fine-tuning gestisce il come.

Anche l’argomento della trasparenza è forte. Quando il RAG fornisce una risposta, puoi risalire a documenti sorgente specifici, il che significa che puoi verificare le risposte, intercettare le allucinazioni e mostrare agli utenti esattamente da dove arrivano le informazioni. I modelli fine-tuned non offrono nulla di simile.

Anche i costi pendono nettamente a favore del RAG. Mettere in piedi un database vettoriale e una pipeline di embedding costa da $200 a $2.000 al mese nelle implementazioni tipiche. Fare fine-tuning di un modello di produzione in modo serio costa quella cifra già solo in calcolo di addestramento, prima ancora di contare la preparazione dei dati e la manutenzione continua.

Ma il RAG ha dei limiti. Richiede che esistano documenti rilevanti. Il passaggio di recupero aggiunge latenza. I documenti lunghi mettono sotto pressione le finestre di contesto. E, cosa cruciale, il RAG non può cambiare il modo in cui il modello ragiona o scrive.

Il prompting non è l’opzione per principianti

Descrivere il prompting come il primo gradino di una scala sminuisce il suo vero potere.

La progettazione dei prompt significa scrivere istruzioni che guidano il comportamento del modello senza modificare nulla di esterno. Lavori interamente dentro la conversazione. Niente infrastruttura. Niente dati di addestramento. Niente database vettoriali.

Sembra semplice. È lì la trappola.

La progettazione dei prompt, fatta sul serio, include schemi di ragionamento strutturati, esempi few-shot che mostrano pattern esatti, scomposizioni del ragionamento per compiti complessi e una specifica accurata dei vincoli che modella gli output senza regole esplicite. I team che liquidano il prompting come “base” spesso non hanno esplorato cosa sia possibile ottenere quando ci investi davvero.

adamgordonbell ha condiviso un’esperienza rivelatrice: “When I first wanted to tackle a hard problem I thought to reach for fine-tuning with lots of input and output pairs, but it wasn’t needed.” Questo schema si ripete di continuo. Gli ingegneri danno per scontato che la complessità richieda soluzioni complesse, poi scoprono che dei buoni prompt risolvono il problema in modo più elegante.

La struttura dei costi rende il prompting un investimento che vale la pena prendere sul serio. Ore di iterazione sui prompt non costano nulla oltre ai costi di abbonamento. Se riesci a risolvere un problema solo con i prompt, eviti del tutto l’infrastruttura, il che significa cicli di iterazione più rapidi, manutenzione più semplice e meno rischio quando cambiano i requisiti.

Il limite però è reale. I prompt possono solo modellare il comportamento entro ciò che il modello sa già fare. Non puoi “spingere” un modello a capire concetti che non ha mai incontrato durante l’addestramento e non puoi ottenere accesso, tramite prompt, a informazioni che il modello non possiede.

La decisione che conta davvero

Smetti di chiederti quale sia il migliore. Chiediti qual è davvero il tuo problema.

Il modello fornisce informazioni sbagliate sulla tua azienda, sui prodotti o su eventi recenti. È un problema di conoscenza. Il RAG risolve i problemi di conoscenza dando al modello le informazioni che gli mancano al momento della richiesta.

Il modello conosce l’informazione giusta ma produce output in formati sbagliati, con stili sbagliati o con qualità incoerente tra un’interazione e l’altra. È un problema di comportamento. Il fine-tuning risolve i problemi di comportamento modificando il modo in cui il modello genera risposte.

Il modello potrebbe fare ciò che vuoi, ma non lo fa perché le istruzioni non sono abbastanza chiare. È un problema di istruzioni. La progettazione dei prompt risolve i problemi di istruzioni dando indicazioni migliori dentro la conversazione.

La maggior parte dei team confonde queste categorie. Ha un problema di conoscenza ma presume che il fine-tuning insegnerà nuova conoscenza. Ha un problema di istruzioni ma presume che il RAG fornirà istruzioni. Abbinare la soluzione al problema reale fa risparmiare mesi di sforzi buttati.

La pericolosa terra di mezzo

A volte il problema attraversa più categorie. Ti serve conoscenza aziendale E formattazione coerente E schemi di ragionamento specifici.

È qui che emergono architetture combinate. Il RAG fornisce informazioni aggiornate. Il fine-tuning assicura una struttura di output coerente. I prompt danno indicazioni specifiche per la richiesta. Tutti e tre insieme.

phillipcarter su Hacker News ha messo in guardia dalle false dicotomie: “Fine-tuning doesn’t eliminate the need for RAG, and RAG doesn’t obviate the need for fine-tuning either.”

Ma le combinazioni moltiplicano la complessità. Tre sistemi da mantenere. Tre potenziali punti di guasto. Tre voci di costo. Costruisci combinazioni solo quando gli approcci singoli falliscono in modo dimostrabile, non come copertura contro problemi ipotetici.

I team di IA più avanzati la trattano come logica di instradamento. Le richieste semplici vanno solo di prompt. Le richieste ad alta intensità di conoscenza attivano il RAG. Le operazioni ad alto valore, in cui il formato è critico, passano su modelli fine-tuned. È il sistema stesso a decidere quale strada prende ogni richiesta.

Quell’architettura richiede un’ingegneria significativa. Alla maggior parte dei team non serve. Alla maggior parte dei team serve scegliere un approccio ed eseguirlo bene.

Cosa ha imparato il mercato sulla propria pelle

Le prime implementazioni di IA nelle aziende tendevano a partire dal fine-tuning perché sembrava più sostanziale, più “difendibile” nelle presentazioni ai dirigenti, più chiaramente diverso dal semplice uso di ChatGPT. Spesso però quelle implementazioni si bloccavano nella fase di preparazione dei dati, che si allungava per mesi.

solidasparagus ha riassunto la realtà pratica: “collecting data and then fine-tuning models is orders of magnitude more complex than just throwing in RAG.”

La complessità non è solo tecnica. Il fine-tuning richiede dataset curati che rappresentino con precisione il tuo caso d’uso, il che significa capire come deve essere un buon output, raccogliere abbastanza esempi, formattarli correttamente e verificare che il set di addestramento non contenga errori che si propagheranno nel modello. Il RAG richiede caricare documenti che probabilmente hai già.

Questo non vuol dire che il fine-tuning non sia mai la scelta giusta. Le aziende che gestiscono milioni di richieste simili ogni giorno possono fare fine-tuning su modelli più piccoli che girano più veloci e costano meno dei grandi modelli generalisti. I domini specializzati con terminologia e schemi di ragionamento unici a volte richiedono cambiamenti di comportamento che i prompt non riescono a ottenere. Le applicazioni sensibili alla latenza beneficiano di modelli piccoli fine-tuned rispetto a modelli più grandi guidati da prompt.

Ma la soglia è alta. Serve volume per giustificare l’investimento. Servono requisiti comportamentali chiari che non cambino spesso. Servono dati di addestramento di qualità, o il budget per crearli. E serve pazienza per un ciclo di iterazione misurato in settimane invece che in ore.

L’opzione sottovalutata

Per molte applicazioni aziendali, la risposta è più semplice di tutte queste.

Usa il modello così com’è con prompt decenti. Accetta un po’ di imperfezione. Spedisci qualcosa.

La ricerca della personalizzazione perfetta dell’IA ritarda il valore reale. I team passano mesi su architetture RAG quando un modello di prompt e una revisione manuale servirebbero meglio gli utenti reali nel breve periodo.

Questo non significa accontentarsi per sempre. Significa mettere le cose nel giusto ordine: dimostrare prima che il concetto funziona con approcci semplici, individuare i gap specifici attraverso l’uso reale, poi investire nella personalizzazione che affronta quei gap.

Partire dal fine-tuning prima di validare il caso d’uso è come ottimizzare codice prima di sapere se è il codice giusto. Lo sforzo potrebbe essere sprecato su un problema che non esiste, o che cambia mentre impari di più sui bisogni reali degli utenti.

Punti di partenza pratici

Se il tuo problema è la conoscenza, inizia dal RAG. Porta i documenti in un archivio vettoriale, integra il recupero nei prompt e vedi se il modello produce risposte corrette quando ha a disposizione le informazioni giuste.

Se il tuo problema è la costanza, inizia con prompt dettagliati e con esempi. Mostra al modello esattamente cosa vuoi con campioni annotati. La maggior parte dei problemi di costanza cede al few-shot prompting prima di richiedere fine-tuning.

Se il tuo problema è la capacità, cioè il modello non riesce proprio a svolgere il compito, chiediti se l’IA sia la soluzione giusta. Il fine-tuning può estendere le capacità ai margini, ma non può trasformare un modello linguistico in qualcosa per cui non è stato progettato.

Se non sei sicuro di quale sia il tuo problema, quello è il problema. Dedica tempo a caratterizzare i fallimenti prima di investire in soluzioni. Parla con gli utenti. Guarda gli output sbagliati. Capisci nello specifico cosa è andato storto e perché, prima di decidere come sistemarlo.

I team che riescono con la personalizzazione dell’IA condividono un tratto: definiscono il problema con precisione prima di scegliere la soluzione, poi validano la scelta con un investimento minimo prima di scalare l’approccio in tutta l’organizzazione.

I team che fanno fatica saltano a soluzioni che suonano sofisticate senza capire abbastanza il problema da sapere se quella sofisticazione sia davvero necessaria.

Inizia semplice. Aggiungi complessità solo quando il semplice fallisce, in modo dimostrabile.

Non è un consiglio entusiasmante. Ma è il consiglio che funziona.