Il problema che nessuno ti dice subito
Hai un caso d'uso specifico: classificare i ticket di assistenza, generare schede prodotto nel tono del tuo brand, estrarre dati da documenti in formato non standard. Apri la documentazione di OpenAI o Anthropic e trovi due strade: ottimizzare il prompt oppure fare fine-tuning del modello. Entrambe sembrano valide. Entrambe costano tempo e denaro. La scelta sbagliata ti porta a sprecare settimane.
Questo articolo non è una panoramica teorica. È un criterio decisionale che uso con i clienti di DD Agency quando dobbiamo decidere dove mettere le risorse prima ancora di scrivere una riga di codice.
Cosa significa davvero ciascun approccio
Il prompt engineering avanzato consiste nel costruire istruzioni strutturate, esempi contestuali (few-shot), catene di ragionamento (chain-of-thought) e sistemi di controllo dell'output per guidare un modello base verso il risultato che ti serve. Non modifichi il modello: lo istruisci ogni volta che lo chiami.
Il fine-tuning consiste invece nell'addestrare ulteriormente un modello pre-esistente su un dataset specifico tuo. Il modello cambia i propri pesi interni e incorpora pattern, stili, regole o conoscenze che non aveva prima. Dopo il training, il comportamento desiderato è già nel modello e non serve ripeterlo nel prompt.
La distinzione tecnica è chiara. Quella pratica lo è meno, ed è lì che si prendono le decisioni sbagliate.
Quando il prompt engineering avanzato è sufficiente
La maggior parte dei casi d'uso che vedo nelle PMI si risolve con un buon prompt engineering, senza toccare i pesi del modello. Questo vale soprattutto quando:
- Il comportamento che vuoi ottenere è descrivibile con istruzioni precise e pochi esempi
- Il volume di chiamate API non è ancora abbastanza alto da giustificare un costo fisso di training
- Il caso d'uso evolve spesso (il prompt si aggiorna in minuti, il dataset di fine-tuning no)
- Non hai ancora un dataset di esempi di qualità sufficiente
Un prompt ben costruito con 5-10 esempi contestuali riesce a ottenere risultati sorprendentemente vicini a quelli di un modello fine-tuned, su molti task di classificazione, riformulazione e generazione strutturata. Il costo marginale è quasi zero se stai già pagando l'API.
Attenzione però a un errore frequente: pensare che un prompt lungo e dettagliato sia automaticamente un buon prompt. La qualità delle istruzioni conta più della quantità. Un prompt di 200 token ben strutturato batte quasi sempre uno di 2.000 token disorganizzato.
Quando il fine-tuning vale l'investimento
Ci sono situazioni in cui il prompt engineering, per quanto raffinato, non arriva dove serve. Questi sono i segnali che indicano che il fine-tuning ha senso:
1. Il comportamento è difficile da descrivere a parole ma hai esempi. Se sai riconoscere l'output corretto ma fatichi a spiegare perché è corretto, il fine-tuning impara dai tuoi esempi meglio di quanto tu possa spiegare con le istruzioni.
2. Hai bisogno di un tono o stile molto specifico e coerente. Il brand voice di un'azienda con una voce forte e riconoscibile non si trasferisce bene solo con istruzioni. Si trasferisce con esempi reali.
3. Il prompt è diventato troppo lungo e costoso. Se stai inserendo decine di esempi nel contesto a ogni chiamata per ottenere consistenza, il costo per token si accumula. Un modello fine-tuned riduce il prompt necessario e abbassa il costo per chiamata.
4. Hai bisogno di velocità di risposta più alta. Un modello fine-tuned più piccolo (es. GPT-4o mini fine-tuned) può superare le performance di un modello grande con prompt complesso, a latenza e costo inferiori.
5. Il task richiede conoscenze molto specifiche di dominio. Terminologia tecnica, sigle aziendali, processi interni: se il modello base non li conosce e non riesci a metterli tutti nel contesto, il fine-tuning li incorpora.
I criteri decisionali in pratica
Quando un cliente mi pone questa domanda, parto da tre variabili concrete.
Volume e frequenza. Se hai meno di qualche migliaio di chiamate al mese, il fine-tuning non si ripaga quasi mai in termini di risparmio sui costi API. Il break-even dipende dal modello e dal provider, ma di solito serve un volume significativo prima che il risparmio per chiamata compensi il costo del training e della manutenzione del dataset.
Qualità e quantità del dataset. Il fine-tuning richiede esempi input-output di qualità alta. OpenAI indica come soglia minima alcune centinaia di esempi per task semplici, ma nella pratica per ottenere un miglioramento robusto ne servono spesso di più, e soprattutto devono essere corretti e rappresentativi. Se non hai questo dataset già disponibile (o non hai le risorse per crearlo), il fine-tuning diventa un progetto a sé, con costi e tempi propri.
Stabilità del task. Se il task cambia ogni mese (nuovi prodotti, nuove categorie, nuove regole di business), aggiornare un modello fine-tuned è più oneroso che aggiornare un prompt. Il prompt engineering vince per flessibilità.
Una regola empirica che uso: se riesci a risolvere il problema con un prompt e 10 esempi contestuali con un tasso di successo accettabile, stai lì e ottimizza. Se dopo iterazioni serie il prompt non converge, hai esempi abbondanti e il volume giustifica l'investimento, allora considera il fine-tuning.
Il costo nascosto che devi mettere in preventivo
Chiunque ti dica che il fine-tuning è semplice sta semplificando troppo. Ci sono costi che non appaiono nelle pricing page dei provider.
Il primo è la creazione e cura del dataset. Raccogliere, pulire, annotare e validare centinaia o migliaia di esempi richiede tempo umano qualificato. Questo è spesso il costo più alto dell'intero progetto.
Il secondo è la valutazione continua. Un modello fine-tuned può degradare nel tempo se il dominio evolve. Serve un sistema di monitoraggio e un processo per aggiornare il training quando necessario.
Il terzo è la dipendenza dal provider. Se fine-tuned un modello su OpenAI e domani vuoi migrare su Anthropic o su un modello open-source, il tuo investimento non è portabile. Con il prompt engineering la migrazione è molto più semplice.
Non sto dicendo che il fine-tuning non valga. Sto dicendo che il confronto onesto non è tra il costo del training e il costo dei token risparmiati. È tra il costo totale del progetto di fine-tuning e il costo totale di un buon lavoro di prompt engineering con eventuale caching e ottimizzazione delle chiamate.
La mossa concreta per domani mattina
Prendi il tuo caso d'uso più urgente, scrivi 20 esempi input-output che consideri corretti e costruisci un prompt con quei 5-6 esempi migliori come few-shot. Misura il tasso di successo su un campione reale. Se superi la soglia di qualità che ti serve, hai la tua risposta: il prompt engineering è sufficiente e puoi scalare da lì. Se dopo due o tre iterazioni serie il risultato non arriva, hai già la base del tuo dataset di fine-tuning e sai con certezza che ne vale la pena.