Prompt per modelli piccoli

Chi arriva ai modelli locali dopo aver usato quelli di frontiera fa quasi sempre lo stesso errore: riusa gli stessi prompt e conclude che il modello piccolo “non funziona”. Il problema è che un modello da 8 miliardi di parametri non è la versione ridotta di uno da 400: ha limiti di natura diversa.

Capacità	Modello grande	Modello piccolo (8B)
Istruzioni complesse	eccellente	limitata
Contesto lungo	usa bene 128k	in pratica molto meno di quanto dichiara
Ragionamento a più passi	buono	perde il filo dopo tre o quattro passaggi
Tenere il formato	affidabile	tende a dimenticarlo strada facendo
Ambiguità	chiede chiarimenti	tira a indovinare

La ragione di fondo: un modello grande ha parametri a sufficienza per codificare insieme la conoscenza e le regole di comportamento. Uno piccolo deve scegliere. Se lo carichi di istruzioni, spende attenzione a seguirle e gliene resta meno per il contenuto.

Da qui la regola d’oro: con un modello piccolo, ogni parola del prompt deve guadagnarsi il posto.

Le regole che fanno la differenza

Frasi corte e dirette. Le costruzioni cortesi e articolate sono rumore.

Male:  Vorrei che analizzassi il seguente codice Python fornendomi un elenco
       dettagliato di tutti i potenziali problemi che potresti identificare...

Bene:  Trova i bug in questo codice Python. Focus: errori e sicurezza.
       Elenca: riga, problema, correzione.

Un compito per volta. Se ti servono quattro cose, fai quattro chiamate. È più veloce che litigare con una risposta che ne fa due bene e due male.

Il formato va mostrato, non descritto. Un esempio di output vale tre paragrafi di istruzioni, e con i modelli piccoli il divario è ancora più ampio.

Le istruzioni importanti vanno ripetute alla fine. I modelli piccoli danno molto peso alla parte finale del prompt: una riga di promemoria appena prima della risposta recupera molti errori di formato.

Poche regole nel system prompt. Tre o quattro, non venti. Quello che sui modelli grandi è una guida dettagliata, qui diventa un carico che soffoca il contenuto.

Aspettative realistiche

I modelli piccoli sono ottimi su compiti circoscritti: riformulare, classificare, estrarre, tradurre, riassumere testi brevi, rispondere su un contesto già fornito. Vanno in difficoltà su ragionamenti lunghi, vincoli multipli simultanei e conoscenze molto specifiche.

La strategia che paga è spezzare: dove un modello grande gestisce un compito complesso in una chiamata, con uno piccolo se ne fanno quattro semplici. Il risultato finale è spesso paragonabile, e gira su una macchina che hai in casa.

La soluzione strutturale al problema del formato

Buona parte dei consigli qui sopra serve a ottenere il formato giusto: mostra l’esempio, ripeti in fondo, accorcia. Sono tutti modi di convincere il modello.

Ne esiste uno che non convince: costringe. La generazione vincolata azzera, a ogni passo, la probabilità dei token che romperebbero la struttura richiesta.

Senza vincolo:  chiedi un JSON, ottieni un JSON  ~ 8 volte su 10
                (le altre 2: virgole di troppo, testo prima, campi mancanti)

Con vincolo:    JSON valido  10 volte su 10
                perché le alternative non sono disponibili

È particolarmente prezioso proprio sui modelli piccoli, dove il rispetto del formato è il punto debole numero uno: un modello da 8 miliardi con output vincolato è più affidabile, sul formato, di uno molto più grande lasciato libero.

Due avvertenze che valgono doppio qui: il vincolo garantisce la forma, non il contenuto; e schemi troppo ricchi peggiorano il risultato, perché il modello spende attenzione a incastrare i campi invece che a ragionare. Pochi campi, nomi ovvi, niente annidamenti.

Aspettative realistiche

Vale la pena essere espliciti su cosa chiedere e cosa no.

Vanno bene	Vanno in difficoltà
Riformulare, tradurre, riassumere testi brevi	Ragionamenti lunghi a più vincoli
Classificare ed estrarre dati	Conoscenze molto specifiche
Rispondere su un contesto già fornito	Tenere il filo su documenti lunghi
Compiti ripetitivi ben definiti	Ambiguità che richiederebbe una domanda

La strategia che paga è spezzare: dove un modello grande gestisce un compito complesso in una chiamata, con uno piccolo se ne fanno quattro semplici. Il risultato finale è spesso paragonabile, e gira su una macchina che hai in casa.

Prima e dopo: lo stesso compito riscritto

La differenza si vede meglio su un caso concreto. Compito: estrarre dati da una recensione.

# Scritto per un modello grande — su un 8B produce risultati incostanti

Vorrei che analizzassi attentamente la seguente recensione di un prodotto e che
mi fornissi un'analisi strutturata del sentimento espresso, identificando anche
gli aspetti specifici menzionati dall'utente sia in positivo che in negativo,
tenendo conto delle sfumature e dell'eventuale sarcasmo, e restituendo il tutto
in un formato che sia facilmente elaborabile da un programma.

# Riscritto per un modello piccolo

Estrai i dati dalla recensione fra i marcatori.

Rispondi SOLO con questo JSON:
{"sentimento": "positivo|negativo|misto", "pro": [], "contro": []}

<<<RECENSIONE
...
RECENSIONE>>>

Rispondi solo con il JSON.

Cosa è cambiato, punto per punto: una richiesta sola invece di quattro accorpate; il formato mostrato invece che descritto; i valori ammessi elencati, così non se li inventa; i dati delimitati, così non li confonde con le istruzioni; l’istruzione chiave ripetuta in fondo, dove il modello pesa di più. E le sfumature e il sarcasmo sono spariti: a un modello piccolo si chiede una cosa che sa fare, non la cosa che vorresti.

Se il JSON deve essere valido sempre, l’ultimo passo è l’output vincolato: a quel punto la forma non dipende più dalla buona volontà del modello.

Quando è il modello a essere sbagliato, non il prompt

C’è un limite oltre il quale riscrivere il prompt non serve, e riconoscerlo evita ore perse.

Sintomo	Interpretazione
Sbaglia il formato ogni tanto	Prompt migliorabile, o output vincolato
Sbaglia il formato quasi sempre	Modello troppo piccolo per quel formato
Perde il filo dopo tre passaggi	Limite strutturale: scomponi in più chiamate
Inventa dati che non ci sono	Manca il contesto, non il prompt
Va bene in inglese e male in italiano	Il modello è addestrato male sulla lingua: cambialo

L’ultima riga capita più spesso di quanto si creda, ed è invisibile finché non provi lo stesso prompt nelle due lingue.

In sintesi

Regola	Perché
Frasi corte	Ogni parola in più sottrae attenzione al contenuto
Un compito per chiamata	I compiti multipli si degradano a vicenda
Mostra il formato	Un esempio batte tre paragrafi di descrizione
Ripeti in fondo	La parte finale del prompt pesa di più
Poche regole di sistema	Tre o quattro, non venti
Output vincolato	Sui modelli piccoli non è un’ottimizzazione, è la scelta di base
Strategia	Quattro chiamate semplici battono una complessa
Riscrivere	Una richiesta, formato mostrato, valori ammessi, dati delimitati, ripetizione finale
Quando cambiare modello	Formato sempre sbagliato, o resa molto peggiore in italiano