RAG vs Fine‑Tuning: la decisione che determina costi e rischio

Quando entro in un’azienda e mi chiedono “quale LLM scegliamo?”, spesso la risposta corretta è: non lo so ancora. Prima devo capire se stiamo costruendo un sistema che recupera conoscenza (RAG) o un sistema che cambia comportamento (fine‑tuning). Sono due prodotti diversi, con costi e rischi diversi.

RAG significa: la conoscenza resta in documenti/versioni che posso aggiornare e auditare. Fine‑tuning significa: trasformo una parte di conoscenza e comportamento in pesi del modello (o adapter). La scelta determina tutto: aggiornabilità, evidence pack, qualità, latenza, incidenti, budget.

1) Quando vince il RAG (e perché è spesso la prima mossa)

Uso RAG quando la “verità” cambia: policy, prezzi, contratti, procedure, knowledge base. Il punto non è solo la qualità: è la governance. Se devo dimostrare da dove viene una risposta, RAG è naturale.

In pratica, RAG è un progetto di knowledge supply chain: ingestion, chunking, embedding, retrieval, ranking, e osservabilità. Se fatto bene, riduce l’hallucination rate senza trasformare ogni update in un retrain.

Conoscenza aggiornata spesso: documenti e policy che cambiano ogni settimana.
Serve auditabilità: devo mostrare fonte, versione, e percorso decisionale.
Multi-dominio: tanti team, tanti vocabolari, una sola piattaforma.
Time‑to‑value rapido: posso partire con un perimetro piccolo e scalare.
Rischio controllabile: posso mettere guardrail e citazioni prima di “agire”.

Se vuoi una base concreta, la pagina Vector Databases & RAG spiega bene i mattoni. Poi la differenza la fa l’operazione: valutazioni, logging, runbook e ownership.

2) Quando vince il fine‑tuning (e quando è uno spreco)

Faccio fine‑tuning quando voglio cambiare come il modello risponde, non cosa sa oggi. È utile per stile, formati strutturati, lessico di dominio, e task ripetibili dove la conoscenza è relativamente stabile.

Lo spreco tipico è usare fine‑tuning per “caricare documenti”. Se il contenuto cambia, paghi il retrain come tassa. E spesso finisci con un modello che sembra competente ma è fragile fuori dal perimetro.

Stile e standard: tono, formati, checklist, output coerenti.
Riduzione prompt: meno istruzioni → meno costi e meno variabilità.
Task chiusi: classificazioni, estrazioni, routing con regole chiare.
Latenza: meno retrieval, più prevedibilità in p95.

Quando serve davvero, preferisco un approccio “leggero” (LoRA/adapter) e un set di eval che blocchi regressioni. Non è magia: è disciplina.

3) Costi: il conto reale non è “token”, è manutenzione

Il costo di RAG non è solo “vector DB”. È ingestion, re-indexing, qualità del retriever, e soprattutto osservabilità: capire dove il sistema fallisce (retrieval, ranking, prompt, modello). Il costo di fine‑tuning non è solo training: è data curation, versioning, e cicli di refresh.

Se vuoi evitare sorprese, pensa in termini di costo per decisione affidabile. Non per call. Non per token. Per decisione che un team usa senza paura.

RAG: ingestion + embedding + retrieval + reranking + storage + logging.
Fine‑tuning: dataset + labeling + training runs + eval harness + release management.
In comune: guardrail, policy, incident response, e ownership.
Break-even: dipende da frequenza update e da quanta “conoscenza” è davvero dinamica.
Shortcut: per il modello economico iniziale usa il TCO Calculator e poi aggiungi il costo umano (review, escalation).

4) Rischi: RAG e fine‑tuning falliscono in modi diversi

La scelta corretta riduce rischio. La scelta sbagliata lo sposta in un punto dove è più caro. RAG fallisce quando il retrieval è debole o il perimetro dati è poroso. Fine‑tuning fallisce quando il dataset “inquina” il comportamento o quando la manutenzione non è sostenibile.

Io separo sempre rischio in due categorie: errore operativo (decisioni sbagliate) e errore di governance (non riesco a dimostrare o controllare cosa succede).

RAG — Prompt injection: documenti o input che spingono il modello a bypassare policy.
RAG — Wrong recall: contesto mancante → risposta “sicura” ma incompleta.
RAG — Leakage: retrieval senza ACL/tenant isolation → dati nel posto sbagliato.
Fine‑tuning — Data poisoning: esempi sbagliati → modello sbaglia “con sicurezza”.
Fine‑tuning — Drift: cambiano policy/processi e il modello resta indietro.
Fine‑tuning — Irreversibilità: rollback e debugging più difficili rispetto a cambiare documenti.

5) Governance: cosa firmi e cosa puoi provare

Se l’AI entra in un processo reale, prima o poi qualcuno chiede: “posso firmare questa scelta?”. Qui RAG e fine‑tuning si separano. Con RAG puoi costruire un evidence trail più diretto: documento → chunk → retrieval → output.

Con fine‑tuning serve un pacchetto più “ML”: dataset versionato, training logs, eval comparativi, criteri di rollout/rollback. È fattibile, ma devi volerlo fare.

Versioning: sapere esattamente quale fonte o modello ha prodotto l’output.
Eval gate: nessun deploy senza test set + soglie minime.
Access control: chi può vedere cosa (docstore/vectorstore) e perché.
Logging con redaction: audit trail senza PII in chiaro.
Runbook: cosa fai quando degrada (p95, quality, leakage).
Ownership: un owner che risponde di qualità, costi e rischio.

6) Regola pratica: scegli in base al tipo di conoscenza

La scorciatoia migliore che ho trovato è classificare la conoscenza. Non tutta la conoscenza va nel modello. E non tutta sta bene nei documenti.

Conoscenza “dinamica”: va in RAG (policy, prezzi, procedure, stato).
Conoscenza “comportamentale”: va in fine‑tuning (stile, formati, routing).
Conoscenza “ibrida”: spesso serve RAG + adapter leggero (dominio + stile).
Se serve citazione: RAG prima, sempre.
Se serve latenza rigida: riduci retrieval e investi in prompt design/fine‑tuning.

7) Piano 30/60 giorni: partire bene senza incastrarsi

Se vuoi muoverti veloce senza creare debito, io uso questo percorso. Ti dà qualità misurabile, governance e una decisione chiara su RAG vs fine‑tuning.

Giorni 1–7: definisci 1 workflow, 1 owner, 1 test set (“golden”).
Giorni 8–14: implementa RAG minimale + logging + guardrail (policy, PII, rate limit).
Giorni 15–30: pilot misurato: qualità, p95, cost/decisione, incidenti.
Giorni 31–45: se serve, prova adapter/fine‑tuning su comportamento (non sui documenti).
Giorni 46–60: stabilizza release + rollback, integra procurement/evidence pack.

Se vuoi accelerare, parti dalla mia Reference Architecture: riduci discussioni infinite e porti subito a terra confini, logging e SLO.

8) KPI che uso per decidere (e per evitare religioni)

Non decido “a gusto”. Decido con misure che tengono insieme qualità, costo e rischio. Questi KPI bastano per 90% dei casi.

Quality: accuracy su test set + hallucination rate.
Citation coverage (RAG): % risposte con fonte corretta.
Retrieval health: recall@k e hit rate per dominio.
Latency: p95 end-to-end + TTFT.
Cost: costo per decisione/ticket risolto (non per token).
Risk: incidenti (PII, leakage, policy bypass) per 1k richieste.

Takeaway (da portare in board)

RAG gestisce conoscenza dinamica e auditabilità; fine‑tuning gestisce comportamento e standard.
Il costo reale è manutenzione + qualità: misura per decisione affidabile, non per token.
La governance non è un extra: è ciò che rende la scelta “firmabile”.
Parti con un pilot misurato e poi decidi: non invertire l’ordine.

Conclusione: scegli l’architettura che ti permette di cambiare

La scelta “RAG vs fine‑tuning” non è accademica: è una scelta di governance, costo e rischio. Se scegli bene, puoi aggiornare senza panico e scalare senza perdere fiducia. Se scegli male, paghi in retrain, workaround e incidenti.

Se vuoi, posso aiutarti con un Assessment Strategico rapido: mappiamo il tuo tipo di conoscenza, definiamo KPI e evidence pack, e disegniamo la soluzione più semplice che regge produzione. Scrivimi qui.