Quello che ognuno fa realmente
RAG (Retrieval-Augmented Generation) lascia inalterato il modello. Al momento della query si cercano i propri dati, di solito un database vettoriale di blocchi di documenti incorporati, tirare indietro i pochi passaggi più rilevanti per la domanda dell'utente e incollarli nel prompt come contesto. Il modello risponde quindi utilizzando quel testo iniettato. La tua conoscenza vive esterno il modello e viene aggiornato ad ogni chiamata.
Sintonia fine cambia il modello stesso. Prendi un modello di base e continui a formarlo sui tuoi esempi in modo che la conoscenza, il tono o il comportamento diventino al forno ai pesi. Dopodiché, il modello produce il tuo stile o risponde alle tue domande sul dominio senza che tu debba fornire ogni volta il materiale di riferimento, ma solo "sa" su cosa è stato addestrato fino a quel momento.
Un modo breve per ricordarlo: lo STRACCIO fornisce al modello un libro aperto da cui leggere al momento della risposta; la messa a punto fa studiare il modello fino a quando il materiale non viene memorizzato.
La struttura dei costi è completamente diversa
È qui che i due approcci divergono maggiormente e perché una domanda ingenua "che è più economica" non ha un'unica risposta.
RAG — per lo più in corso, costo per query
- Costo di incorporamento: ogni documento è incorporato una volta (a buon mercato), ma molte configurazioni incorporano anche ogni query in entrata, un piccolo addebito ricorrente per richiesta.
- Prompt di input più grandi: si inviano i pezzi recuperati su ogni call, so your input-token count is inflated on each request. Since you pay per token, this is the biggest ongoing driver.
- Vector database: a hosted vector store or the infrastructure to self-host it — a monthly fixed cost that grows with corpus size.
- Near-zero upfront: no training run, so you can ship in days.
Fine-tuning — upfront cost, leaner per call
- Training cost: a one-time (or periodic) charge to run the fine-tune, priced by tokens in your training set and the number of epochs.
- Hosting / inference: a fine-tuned model often costs more per token to serve than the shared base model, and some providers add a hosting fee to keep your custom model available.
- Smaller prompts: because behaviour and knowledge are baked in, you send far fewer instruction and context tokens per call — the recurring saving that pays back the training cost.
- Re-training on change: when your data shifts, you pay to fine-tune again.
When RAG wins vs when fine-tuning wins
| Choose RAG when… | Choose fine-tuning when… |
|---|---|
| Knowledge changes often (docs, prices, policies) | Style, format, or behaviour is fixed and repeatable |
| Corpus is large and still growing | The task is narrow and stable |
| You need citations / "where did this come from" | You want short prompts and lower latency per call |
| Volume is low to medium | Volume is very high, so smaller prompts amortise training |
| You need to add or remove facts instantly | You need consistent tone the model can't be prompted into |
The two are not mutually exclusive. A common mature setup fine-tunes for behaviour and format while using RAG for current facts — the model reliably answers in your voice and cites live data.
Worked comparison: low volume vs high volume
Illustrative round numbers to show the shape of the trade-off — always confirm with current provider rates. Assume a mid-tier model, RAG adding ~1,500 extra input tokens of retrieved context per call, and a fine-tune that removes ~1,200 tokens of instructions/examples per call for a one-time training cost of about $300 plus a small monthly hosting fee.
| Scenario | STRACCIO | Sintonia fine | Vincitore |
|---|---|---|---|
| Upfront cost | ~$0 (build vector DB) | ~$300 training | STRACCIO |
| 10,000 calls / month | lower total — extra tokens are cheap at this scale, no training to recoup | higher — $300 spread over few calls dominates | STRACCIO |
| 2,000,000 calls / month | higher — 1,500 extra tokens × 2M adds up every month, forever | lower — training cost is trivial per call, prompts are lean | Sintonia fine |
| Facts change weekly | update the index, no re-train | re-train repeatedly — cost and lag pile up | STRACCIO |
The pattern: at low volume RAG almost always wins because there's no training cost to recover. At very high volume, the per-call token saving from fine-tuning eventually outweighs the fixed training cost — the "break-even" is a volume threshold, not a fixed rule. Model the two side by side before committing.
Fine-tune vs prompting calculator →The honest answer: try the cheap thing first
Fine-tuning feels like the "serious" option, but for most teams it's the wrong first move. Better prompting and RAG solve the majority of "the model doesn't know our stuff" problems faster, cheaper, and with far less to maintain. Fine-tuning adds a training pipeline, versioning, evaluation, and re-training whenever your data drifts — real operational weight.
A sensible order: (1) improve the prompt and add examples; (2) if it needs your data, add RAG; (3) fine-tune only when the numbers clearly favour it — very high volume where lean prompts pay back training — or when you need behaviour that no prompt can reliably produce. Reach for fine-tuning when the evidence says so, not by default. If you do fine-tune, a lightweight LoRA/QLoRA run is usually far cheaper than a full fine-tune — compare a managed per-token rate against renting the GPU yourself with the LoRA vs GPU rental calculator. For broader ways to trim spend, see the guida al taglio dei costi.
LoRA vs GPU rental calculator →Taglia la tua bolletta LLM →Altre guide di apprendimento →Continua ad imparare
Come scegliere un LLM →Come tagliare la fattura LLM →Come funzionano i prezzi dell'API LLM →Domande frequenti
Is RAG cheaper than fine-tuning?
It depends on volume. RAG has near-zero upfront cost but adds ongoing per-query cost from embeddings, a vector database, and larger input prompts. Fine-tuning has a fixed upfront training cost and usually smaller prompts, so it only becomes cheaper per request at very high volume where the training cost is spread across many calls.
When should I fine-tune instead of using RAG?
Fine-tune when you need a fixed style, tone, format, or behaviour baked in, when your task is stable rather than changing daily, when latency matters and you want short prompts, or when your request volume is high enough that smaller prompts save more than the training cost. For knowledge that changes often, RAG is usually the better fit.
Can I use RAG and fine-tuning together?
Yes, and it is common. Fine-tuning teaches the model your format and behaviour while RAG supplies current facts at query time. Most teams should still start with prompting or RAG first and only add fine-tuning once the numbers or behaviour clearly justify the extra cost and complexity.
Solo riferimento didattico: i prezzi sono stime; confermare le tariffe attuali sulla pagina dei prezzi di ciascun fornitore.