RAG vs fine-tuning: cosa serve davvero in azienda

Quasi tutti i progetti AI di cui parliamo con i clienti partono dalla stessa domanda: «Dovremmo fare il fine-tuning di un modello sui nostri dati?». A volte la risposta è sì. Più spesso l'esigenza reale è un'altra: un assistente che conosca i vostri documenti aggiornati, citi le proprie fonti e si possa aggiornare un martedì pomeriggio senza un ciclo di addestramento. Questo articolo spiega le opzioni principali in parole semplici, quando ciascuna è adatta e come decidere senza bruciare mesi sull'approccio sbagliato.

I quattro strumenti nella cassetta#

Quando si dice «insegniamo al modello come funziona la nostra azienda», di solito si intende una di quattro tecniche diverse. Risolvono problemi diversi e si possono combinare.

Retrieval-augmented generation (RAG)#

La RAG lascia il modello invariato. Quando arriva una domanda, il sistema cerca prima nei vostri contenuti (manuali, contratti, ticket o un catalogo prodotti) e passa al modello i passaggi più pertinenti insieme alla domanda. Il modello risponde quindi sulla base di quei passaggi.

Tre concetti contano qui:

• Retrieval: trovare i passaggi giusti. Di solito è una combinazione di ricerca semantica sugli embedding e di classica ricerca per parole chiave, spesso seguita da una fase di reranking.
• Grounding: istruire il modello a rispondere a partire dal materiale fornito, e a dirlo quando il materiale non contiene la risposta.
• Citazioni: indicare il documento, la pagina o il passaggio esatto da cui proviene una risposta, così che una persona possa verificarla.

La RAG dà il meglio quando la conoscenza cambia spesso, quando il corpus è ampio e quando le persone devono poter verificare le risposte.

Fine-tuning#

Il fine-tuning prosegue l'addestramento di un modello sui vostri esempi, in modo da modificarne il comportamento. È efficace per insegnare come rispondere: un tono coerente, un formato di output rigoroso, uno schema di classificazione specifico del dominio o un compito circoscritto eseguito migliaia di volte al giorno. È un pessimo modo per insegnare che cosa è vero in questo momento. I fatti appresi con il fine-tuning sono difficili da aggiornare, difficili da ricondurre a una fonte e possono essere mescolati o ricordati male.

Il fine-tuning permette inoltre di spostare un compito circoscritto su un modello più piccolo, più economico e più veloce, il che può contare molto sui grandi volumi.

Prompt a contesto lungo con prompt caching#

I modelli moderni di Anthropic, OpenAI e di diverse famiglie open source accettano input molto lunghi. Se la vostra knowledge base ha dimensioni contenute (ad esempio un manuale di prodotto, un insieme di policy o una raccolta di FAQ), spesso potete inserirla per intero direttamente nel prompt. Nessun indice, nessuna pipeline di retrieval, nessuna decisione sul chunking.

L'obiezione ovvia riguarda costi e latenza: inviare lo stesso documento voluminoso a ogni richiesta è uno spreco. Il prompt caching risolve il problema. I provider possono mettere in cache un prefisso stabile del prompt, così le richieste ripetute riutilizzano il contenuto già elaborato e vengono fatturate e servite in modo più efficiente. Per un corpo di conoscenza stabile e delimitato, il contesto lungo con caching è spesso la soluzione più semplice che funziona.

Structured outputs#

Molti progetti «AI» sono in realtà progetti di estrazione: leggere una fattura, un CV, un contratto o un'e-mail e produrre campi puliti. Qui la capacità chiave sono gli structured outputs: il modello è vincolato a restituire dati conformi a uno schema definito da voi, ad esempio un JSON con campi e tipi precisi. La conoscenza non c'entra affatto. C'entra l'affidabilità del formato, e di solito questo elimina la necessità del fine-tuning nei compiti di estrazione.

Quando è adatto ciascun approccio#

Un modo utile di ragionare: separare la conoscenza dal comportamento.

• Conoscenza recente o che cambia, e risposte che le persone devono verificare: usate la RAG, oppure il contesto lungo se il materiale è abbastanza contenuto. Entrambi permettono di aggiornare la conoscenza aggiornando i documenti, ed entrambi supportano le citazioni.
• Conoscenza stabile e delimitata che sta nella finestra di contesto: partite dal contesto lungo con prompt caching. Passate alla RAG quando il materiale non ci sta più o quando vi serve un controllo degli accessi granulare per documento.
• Stile, tono o formato coerenti su molti output: provate prima con istruzioni chiare e qualche buon esempio nel prompt. Se ai vostri volumi non basta, il fine-tuning è un'opzione legittima.
• Classificazione o routing circoscritti su larga scala: fare il fine-tuning di un modello più piccolo, o semplicemente usare un modello generalista più piccolo con un prompt ben progettato, è spesso la strada più economica.
• Estrazione di campi dai documenti: structured outputs, eventualmente combinati con input documentali e citazioni, così che ogni valore estratto sia tracciabile.

Le opzioni non si escludono a vicenda. Un sistema maturo può usare la RAG per la conoscenza, gli structured outputs per il formato della risposta e un piccolo modello sottoposto a fine-tuning per instradare le richieste in arrivo.

Confronto a colpo d'occhio#

Una checklist pratica per decidere#

Prima di scegliere un'architettura, rispondete con onestà a queste domande:

1. Qual è, esattamente, il compito? Rispondere a domande, redigere testi, classificare o estrarre? Mettete per iscritto cinque esempi reali di input e di output ideale.
2. Con quale frequenza cambia la conoscenza di base? Cambiamenti giornalieri o settimanali sconsigliano decisamente il fine-tuning.
3. Gli utenti devono verificare le risposte? In ambito legale, finanziario, compliance, assistenza o sanità le citazioni sono di solito irrinunciabili.
4. Quanto è grande la knowledge base? Se sta comodamente in una finestra di contesto, provate prima il contesto lungo con caching.
5. Chi può vedere che cosa? Se utenti diversi hanno accesso a documenti diversi, vi serve un retrieval con filtro sui permessi, non un unico prompt condiviso né un modello addestrato su tutto.
6. Quali volumi e quale latenza vi aspettate? Volumi elevati su un compito circoscritto sono il terreno in cui i modelli più piccoli o sottoposti a fine-tuning ripagano l'investimento.
7. Avete esempi etichettati? Un fine-tuning senza un insieme consistente di buoni esempi raramente batte un prompt ben scritto.
8. Come misurerete il successo? Se non sapete rispondere, fermatevi e costruite prima un set di valutazione.

Se la maggior parte delle risposte indica «conoscenza che cambia, servono citazioni, volumi moderati», vi serve la RAG o il contesto lungo. Se indica «compito stabile, formato rigoroso, volumi molto elevati», prendete in considerazione il fine-tuning o un modello più piccolo.

Errori ricorrenti#

Sono i problemi che vediamo più spesso quando esaminiamo sistemi AI che «funzionano quasi».

• Chunking fatto male. Dividere i documenti in pezzi arbitrari di dimensione fissa taglia a metà le tabelle, separa i titoli dal loro contenuto e fa perdere il contesto. Suddividete seguendo la struttura del documento e conservate metadati utili come titolo, sezione e data.
• Nessuna valutazione. Senza un set di test ogni modifica è una scommessa. I team ritoccano i prompt, cambiano modello e dimensione dei chunk senza sapere se le cose sono migliorate o peggiorate.
• Indici non aggiornati. I documenti di origine sono stati aggiornati, l'indice no. L'assistente cita con sicurezza la policy dell'anno scorso. La reindicizzazione deve far parte del workflow dei contenuti, non essere un'operazione manuale a cui si pensa dopo.
• Allucinazioni senza citazioni. Se il sistema non mostra da dove proviene una risposta, gli utenti non possono distinguere una risposta fondata sulle fonti da una inventata. Esigete le citazioni e insegnate al modello a dire «non lo so» quando le fonti tacciono.
• Privacy e GDPR. I dati personali contenuti in documenti, prompt e log restano dati personali. Dovete sapere quale provider li tratta, in quale regione, in base a quale accordo sul trattamento dei dati e per quanto tempo vengono conservati i log. Il fine-tuning su dati personali merita una cautela in più, perché rimuoverli in seguito è difficile.
• Prompt injection dai documenti. Il contenuto recuperato è un input non attendibile. Un documento può contenere testo che cerca di dare istruzioni al modello, ad esempio di ignorare le proprie regole o di rivelare altri dati. Trattate il testo recuperato come dati, limitate ciò che il modello può fare con i tool e non lasciate mai che il contenuto di un documento conceda permessi.

Valutare prima di ottimizzare#

Il passo più prezioso di qualsiasi progetto AI è anche il meno appariscente: costruire un set di valutazione prima di scegliere un'architettura.

Un buon set di partenza è semplicemente composto da qualche decina o qualche centinaio di domande o input reali, ciascuno con la risposta attesa o con i documenti che dovrebbero essere citati. Poi misurate:

• Qualità del retrieval: il sistema ha trovato i passaggi giusti?
• Qualità della risposta: la risposta è corretta, completa e fondata sulle fonti?
• Accuratezza delle citazioni: i passaggi citati sostengono davvero l'affermazione?
• Comportamento di rifiuto: dice «non lo so» quando dovrebbe?
• Conformità del formato: nell'estrazione, ogni output rispetta lo schema?

Con queste basi i confronti diventano oggettivi. Potete mettere alla prova il contesto lungo contro la RAG, un modello contro un altro, o un modello sottoposto a fine-tuning contro uno guidato dal solo prompt, sui vostri dati anziché su benchmark generici. Scoprirete spesso che la correzione più economica è un retrieval migliore o un prompt più chiaro, non un modello più grande né un ciclo di addestramento.

La valutazione automatica affidata a un modello può accelerare il lavoro, ma va controllata a campione da revisori umani, soprattutto all'inizio.

Come le nostre demo illustrano questi pattern#

Cerchiamo di mettere in pratica ciò che consigliamo, e due demo su questo sito mostrano i pattern in azione.

Il sigmacode Assistant risponde a domande sui nostri servizi e sul nostro approccio. La sua knowledge base è piccola e volutamente congelata, quindi al posto di una pipeline di retrieval usa un prompt a contesto lungo con prompt caching: l'intera knowledge base sta in un prefisso del prompt messo in cache, e il modello ha l'istruzione di rispondere solo a partire da quello. Per un corpo di conoscenza delimitato è più semplice da realizzare e più facile da mantenere corretto rispetto a un indice vettoriale.

La demo Q&A su documenti con citazioni mostra l'altro lato. Fornite un documento, fate domande, e ogni risposta arriva con citazioni che rimandano ai passaggi su cui si è basata. È la promessa centrale di un'AI fondata sulle fonti: ogni affermazione si può verificare sulla propria fonte.

Nessuna delle due demo ha richiesto il fine-tuning. È tipico. Per la maggior parte dei problemi di conoscenza aziendale, grounding e una buona valutazione contano più di un addestramento su misura.

In breve#

• Usate la RAG quando la conoscenza è ampia, cambia spesso, richiede un controllo degli accessi o deve essere citata.
• Usate il contesto lungo con prompt caching quando la conoscenza è stabile e sta nella finestra.
• Usate il fine-tuning o modelli più piccoli per un comportamento coerente o per compiti circoscritti ad alto volume, non per i fatti.
• Usate gli structured outputs per l'estrazione e per qualsiasi output che un sistema debba analizzare.
• Prima valutate, poi ottimizzate ciò che i numeri vi indicano.

Se state soppesando queste opzioni per un progetto reale, il nostro team AI & automazione, guidato da un tech lead con oltre 20 anni di esperienza, può aiutarvi a definirne il perimetro, a costruire un set di valutazione e a rilasciare una prima versione che potrete davvero misurare. Contattateci e raccontateci che cosa state cercando di risolvere: rispondiamo entro 24 ore nei giorni lavorativi.