Fine-tuning vs prompt engineering: scegliere con ROI in mente

Il problema che vediamo ogni settimana

Un'azienda scopre che GPT-4 sbaglia sistematicamente nel classificare i ticket di supporto nel loro dominio verticale. La prima reazione del team tecnico: «dobbiamo fare fine-tuning». Sei settimane dopo, 40.000 esempi annotati, 3.000 € di compute e i risultati sono peggiori di un prompt ben scritto.

Abbiamo visto questa sequenza almeno dieci volte negli ultimi dodici mesi. Il fine-tuning non è sbagliato — è la scelta prematura ad esserlo.

---

Cosa distingue davvero le due strade

Prompt engineering significa istruire un modello base a runtime, includendo nel contesto esempi, istruzioni, vincoli di formato e catene di ragionamento. Non modifica i pesi del modello.

Fine-tuning significa aggiornare i pesi del modello su un dataset specifico. Il modello «impara» pattern che non dovrà più ricevere via prompt.

La distinzione operativa è questa:

| Dimensione | Prompt Engineering | Fine-tuning | |---|---|---| | Costo iniziale | Basso (ore/giorni) | Alto (dataset, annotazione, compute) | | Costo a regime | Alto (token input lunghi) | Basso (prompt corti) | | Latenza | Dipende dai token | Generalmente inferiore | | Aggiornabilità | Immediata | Richiede re-training | | Dati necessari | Zero | Minimo 500-1000 esempi |

---

Quando il prompt engineering è sufficiente (e spesso lo è)

Se il comportamento desiderato può essere descritto in linguaggio naturale con esempi nel contesto, il fine-tuning è overengineering.

Esempio concreto: estrazione strutturata di dati da fatture PDF. Un prompt con 5-10 esempi in formato few-shot raggiunge facilmente 90-95% di accuracy su fatture standard italiane. Il fine-tuning potrebbe portarlo a 97%, ma il delta non giustifica i costi se il volume è sotto i 50.000 documenti/mese.

# Esempio few-shot prompt
ESTRAI i seguenti campi dalla fattura in formato JSON:
- numero_fattura
- data_emissione
- importo_totale
- partita_iva_fornitore

Esempio 1:
Input: "Fattura n. 2024/001 del 15/01/2024 – Totale € 1.220,00 – P.IVA 12345678901"
Output: {"numero_fattura": "2024/001", "data_emissione": "2024-01-15", "importo_totale": 1220.00, "partita_iva_fornitore": "12345678901"}

[aggiungere 4-9 esempi simili con variazioni di formato]

Ora estrai dalla fattura seguente:
{{input}}

Questo approccio richiede un pomeriggio, non un mese.

---

Quando il fine-tuning cambia davvero i numeri

Ci sono tre scenari in cui il fine-tuning ha senso economico:

1. Volume di token elevato e stabile

Se usi GPT-4o con prompt da 2.000 token su 500.000 chiamate al mese, stai pagando circa 5.000 €/mese solo di input token. Un modello fine-tunato con prompt da 200 token riduce quel costo del 70-80%. Il break-even sul costo di training si raggiunge in 2-3 mesi.

Formula rapida:

break_even_mesi = costo_finetuning / (risparmio_token_mensile)

# Esempio:
# costo_finetuning = 8.000 €
# risparmio_token_mensile = 3.500 €
# break_even = 8.000 / 3.500 ≈ 2,3 mesi

2. Stile o formato non descrivibile via prompt

Un modello che deve generare documentazione tecnica nello stile interno aziendale — con convenzioni di naming specifiche, struttura di paragrafo proprietaria, tono legale preciso — non può essere istruito solo con istruzioni testuali. Servono esempi nel dataset di training.

3. Latenza critica con contesto lungo

Se la tua applicazione richiede risposte sotto i 500ms e il contesto necessario è di 3.000+ token, il fine-tuning ti permette di eliminare gran parte di quel contesto. Con modelli più piccoli (Mistral 7B, Llama 3 8B) fine-tunati, la latenza p95 può scendere da 2-3 secondi a 300-400ms.

---

Il percorso decisionale operativo

Prima di aprire un progetto di fine-tuning, rispondi a queste domande:

1. Hai almeno 500 esempi di alta qualità annotati? Se no, fermati. Il fine-tuning con meno dati peggiora quasi sempre il modello base.
2. Il comportamento target è descrivibile via istruzioni? Se sì, testa prima un prompt ben strutturato con chain-of-thought.
3. Il volume mensile supera le 100.000 chiamate? Sotto quella soglia, i risparmi sui token raramente compensano i costi fissi.
4. Il dominio cambia frequentemente? Se le regole di business cambiano ogni settimana, un modello fine-tunato diventa obsoleto prima che sia rentable.

if dati_annotati < 500:
    return "prompt engineering"
elif volume_mensile < 100_000 and stile_descrivibile:
    return "prompt engineering"
elif latenza_critica or volume_mensile > 500_000:
    return "valuta fine-tuning"
else:
    return "benchmark entrambi, poi decidi"

---

Un approccio ibrido sottovalutato: RAG + prompt engineering

Molti casi che sembrano richiedere fine-tuning si risolvono con Retrieval-Augmented Generation: si recupera il contesto rilevante da un knowledge base vettoriale e lo si inietta nel prompt dinamicamente. Costi di setup comparabili al fine-tuning, aggiornabilità immediata, nessun re-training.

Quando il problema è «il modello non conosce il nostro dominio», quasi sempre la risposta è RAG. Quando il problema è «il modello non si comporta come vogliamo», la risposta potrebbe essere fine-tuning.

---

Take-away operativo

• Inizia sempre dal prompt engineering. È reversibile, veloce, misurabile.
• Considera il fine-tuning solo dopo aver quantificato il ROI con numeri reali: costo dataset, costo training, risparmio token atteso, orizzonte temporale.
• Calcola il break-even prima di iniziare il progetto, non dopo.
• RAG è spesso la terza via ignorata: valutala prima di investire in training.
• I modelli open-source (Llama 3, Mistral, Phi-3) abbassano drasticamente il costo del fine-tuning: 8B parametri su GPU A100 costano circa 2-4 € l'ora su cloud.

---

Se stai valutando quale strada percorrere per un progetto AI interno o per un cliente, il team di Evviva Group può fare un'analisi di fattibilità rapida prima che il budget venga allocato.