Costi, latenza, qualità: i tre vincoli reali

Un prompt non vive nel vuoto. Ogni richiesta a un modello ha costo, tempo di risposta e livello di qualità atteso. In un prototipo puoi ignorarli per qualche minuto; in un workflow ripetuto o in una feature di prodotto diventano vincoli di architettura.

Perché questa lezione conta

Il prompt engineering povero ottimizza solo la risposta visibile: “è più completa?”, “sembra più intelligente?”. Il prompt engineering per sviluppatori guarda anche se quella risposta arriva in tempo, costa quanto previsto, scala con il numero di utenti e resta abbastanza buona usando un modello più piccolo o una strategia di fallback.

Questa lezione ti allena a non chiedere “qual è il prompt migliore?”, ma “qual è il prompt migliore dentro questi vincoli?”.

Il trilemma operativo

Qualità

Qualità significa aderenza al task, correttezza, formato rispettato, copertura dei casi limite e utilità per chi deve agire sul risultato. Non sempre coincide con lunghezza o livello di dettaglio.

Una code review utile può contenere tre finding precisi invece di venti osservazioni generiche. Un riassunto utile può essere breve se conserva decisioni, rischi e prossime azioni.

Latenza

La latenza non è solo tempo tecnico. È tempo percepito nel workflow:

• una chat può tollerare qualche secondo in più;
• un autocomplete deve essere quasi immediato;
• una pipeline asincrona può aspettare, se notifica il risultato;
• una UI interattiva deve prevedere streaming, stato di caricamento o fallback.

Prompt lunghi, output prolissi e modelli più grandi tendono ad aumentare latenza. A volte il miglior prompt è quello che chiede meno.

Costo

Il costo dipende da token di input, token di output, modello, frequenza d’uso, retry, cache e fallimenti. Un prompt che funziona una volta può diventare costoso se viene chiamato su ogni richiesta utente o su ogni commit.

La domanda corretta non è “quanto costa una chiamata?”, ma “quanto costa questo workflow in un mese realistico?”.

Strategie per ridurre sprechi

Ridurre input irrilevante

Taglia contesto non necessario, sostituisci file lunghi con riassunti tecnici e chiedi all’agente di leggere solo ciò che serve.

Ridurre output inutile

Specificare formato e lunghezza è una forma di controllo costi. Se vuoi una tabella decisionale, non chiedere una spiegazione narrativa completa.

Usare modelli diversi per fasi diverse

Non tutti i passaggi richiedono il modello più costoso. Un modello piccolo può classificare, filtrare o preparare contesto; un modello più capace può intervenire solo sui casi difficili.

Cache e batching

Prompt con prefissi stabili, richieste ripetute e dati poco variabili possono beneficiare di cache o batching. Non è sempre una scelta di prompt: spesso è una scelta di architettura.

Esempio operativo

Scenario: vuoi una review automatica su ogni pull request.

Versione ingenua:

Leggi tutta la PR e fai una review completa.

Versione progettata:

Obiettivo: review automatica preliminare su diff Git.

Vincoli:
- segnala solo finding con impatto su correttezza, sicurezza o regressioni;
- ignora stile, naming e preferenze non bloccanti;
- massimo 8 finding;
- ogni finding deve avere file, riga, severità, motivo e fix suggerito;
- se il diff supera la soglia, chiedi suddivisione invece di procedere.

Budget:
- preferisci risposta breve;
- non ripetere codice non modificato;
- se mancano file di contesto, elenca solo quelli necessari.

Questa versione riduce output, limita rumore e rende più prevedibile il costo.

Laboratorio guidato

Scegli un workflow ricorrente:

• review PR;
• generazione test;
• riassunto issue;
• classificazione ticket;
• supporto al debug.

Stima:

1. quante volte viene eseguito al giorno o al mese;
2. quanti token medi entrano;
3. quanti token medi escono;
4. quali richieste falliscono o richiedono retry;
5. quali parti possono essere asincrone, cacheate o gestite da un modello più piccolo.

Poi progetta tre varianti:

Variante	Qualità attesa	Latenza	Costo	Quando usarla
Economica
Bilanciata
Alta qualità

Output atteso

Un foglio decisionale che associa task, modello, parametri, formato di output e budget mensile previsto.

Deve contenere almeno:

• frequenza d’uso stimata;
• soglia di costo accettabile;
• soglia di latenza accettabile;
• modello o classe di modello consigliata;
• fallback in caso di costo, timeout o qualità insufficiente.

Checklist di verifica

• so spiegare il trade-off tra qualità, costo e latenza;
• ho ridotto input e output non necessari;
• so quando usare un modello più piccolo;
• ho previsto fallback e soglie;
• ho trasformato un prompt ricorrente in una decisione operativa.

Errori comuni

Ottimizzare solo la qualità apparente. Una risposta lunga può sembrare migliore ma essere troppo lenta o costosa.

Usare sempre il modello più grande. È una scelta semplice, non sempre una scelta professionale.

Non contare retry e fallimenti. Il costo reale include anche richieste ripetute, output non parsabili e interventi umani.

Collegamenti

• Modulo: Fondamenti per sviluppatori — lezione 4 del corso.
• Lezione precedente: Determinismo, temperatura, parametri di sampling.
• Prossima lezione: Cosa l’LLM non sa: aggiornamento, dominio, repo.