TL;DR: per una PMI che vuole usare documenti, procedure e contenuti WordPress in un assistente AI, il RAG è quasi sempre il primo investimento sensato. Il fine-tuning serve quando il problema non è trovare informazioni aggiornate, ma ottenere un comportamento o un formato stabile. Se non hai eval e casi reali già raccolti, addestrare è prematuro.
Il criterio giusto: conoscenza o comportamento?
RAG e fine-tuning vengono spesso presentati come due modi equivalenti per “insegnare i dati aziendali” a un modello. Non lo sono. Il criterio di confronto utile è più semplice: devi aggiornare ciò che il sistema sa oppure il modo in cui risponde?
Con il Retrieval-Augmented Generation, il modello cerca prima i contenuti pertinenti in una base documentale e li usa come contesto per generare la risposta. La documentazione OpenAI sul Retrieval descrive una ricerca semantica basata su vector store: i file vengono suddivisi, trasformati in embedding e indicizzati. Il fine-tuning supervisionato, invece, usa coppie di input e output corretti per modificare il comportamento del modello. È adatto a classificazione, formati specifici e problemi ripetuti di instruction-following, non a tenere aggiornato un listino o un regolamento.
RAG: più controllo sui contenuti, più lavoro sulla pipeline
Il vantaggio principale del RAG è operativo. Se cambia una procedura, aggiorni il documento e ricostruisci l’indice; non devi riaddestrare il modello. Puoi inoltre conservare metadati come reparto, lingua, data, categoria e livello di accesso, filtrando le fonti prima della generazione. Questo rende più semplice mostrare da quale pagina o documento arriva una risposta.
Per un sito WordPress il flusso è naturale: il contenuto può essere letto tramite REST API, normalizzato, separato per post o sezione e sincronizzato quando cambia lo stato editoriale. Non indicizzerei però tutto alla cieca. Bozze, revisioni, allegati privati e pagine obsolete devono restare fuori. Anche l’HTML va ripulito, altrimenti menu, cookie banner e blocchi ripetuti contaminano il recupero.
I contro sono reali. Devi progettare chunk, metadati, permessi, aggiornamenti e test di retrieval. Una risposta può fallire perché il documento non è stato indicizzato, perché la query recupera il passaggio sbagliato o perché il contesto è troppo rumoroso. Il RAG non elimina le allucinazioni: migliora il grounding solo se la ricerca porta fonti pertinenti e l’applicazione obbliga il modello a usarle.
Fine-tuning: utile per la forma, fragile come archivio
Il fine-tuning ha senso quando possiedi esempi di qualità e un errore ricorrente misurabile. Può rendere più stabile una classificazione di ticket, un formato JSON, il tono di una risposta o l’applicazione di una tassonomia interna. In questi casi il valore non è “memorizzare il manuale”, ma ridurre la variabilità del comportamento.
La barriera vera non è avviare il training. È costruire dataset, holdout ed eval credibili. La guida OpenAI al supervised fine-tuning dice esplicitamente di impostare prima le valutazioni e segnala, nella versione corrente, che la piattaforma di fine-tuning è in fase di dismissione per i nuovi utenti. Per una nuova architettura PMI è un avviso concreto contro il lock-in: una decisione che richiede dataset e manutenzione non può dipendere da una funzione del fornitore senza un piano di uscita.
Come base di conoscenza, il fine-tuning è debole. Quando cambiano prezzi, policy o servizi non hai un record facilmente sostituibile: devi correggere esempi, rieseguire il processo e verificare che il nuovo modello non peggiori altri casi. Anche attribuire una risposta a una fonte precisa è più difficile.
Il confronto operativo per PMI e professionisti
Se le informazioni cambiano spesso, vince il RAG. Se serve una risposta tracciabile a un documento, vince ancora il RAG. Se l’errore riguarda invece struttura, stile o classificazione e compare su molti casi simili, il fine-tuning può essere utile, ma solo dopo prompt, output strutturato ed eval.
Sui costi non esiste una risposta universale. Il RAG sposta il lavoro su ingestione, storage, ricerca e osservabilità. Il fine-tuning aggiunge preparazione del dataset, training, versionamento e valutazione continua. Per una piccola organizzazione il costo nascosto più pericoloso è la manutenzione: una demo funziona con pochi file; un sistema affidabile deve sapere quali contenuti sono correnti, chi può leggerli e cosa fare quando non trova una fonte sufficiente.
WordPress e automazioni: una base pratica
Partirei da una pipeline RAG stretta. Solo contenuti pubblicati o documenti approvati, sincronizzazione su evento, checksum per evitare reindicizzazioni inutili, metadati per lingua e permessi, log della fonte recuperata. L’assistente deve rispondere “non trovato” quando il punteggio è debole. Se produce dati destinati a WordPress o a un CRM, l’output va validato in codice: il principio è lo stesso della validazione JSON prima di WordPress.
Attenzione alla sicurezza. Un documento recuperato è input esterno, non un’istruzione affidabile. OWASP chiarisce che RAG e fine-tuning non risolvono la prompt injection e descrive il rischio di istruzioni malevole inserite nei file. Le automazioni devono quindi applicare least privilege, separare il contenuto non fidato e richiedere un gate prima di inviare email, pubblicare pagine o modificare dati.
La mia take: RAG prima, fine-tuning dopo i log
Per PMI e professionisti sceglierei RAG come architettura iniziale, con un modello standard e una pipeline verificabile. Dopo alcune settimane, i log diranno se il problema è il recupero delle fonti, il prompt o un comportamento che resiste alle correzioni. Solo nell’ultimo caso valuterei il fine-tuning, su un provider e un modello con ciclo di vita compatibile con il progetto.
La regola è netta: la conoscenza aziendale deve restare aggiornabile e ispezionabile fuori dal modello. Il comportamento si può ottimizzare dopo. Invertire l’ordine significa trasformare documenti che cambiano in un debito di training.