Token, finestra di contesto, attenzione

Ogni prompt ha un costo cognitivo e operativo. I token incidono su prezzo, latenza, quantità di informazione gestibile e qualità della risposta. La finestra di contesto non è un contenitore magico: anche quando è molto ampia, il modello può dare più peso ad alcune parti, perdere dettagli nel mezzo o essere distratto da materiale irrilevante.

Perché questa lezione conta

Lo sviluppatore che usa LLM tende a commettere due errori opposti: fornire troppo poco contesto o incollare tutto. Il primo produce risposte inventate; il secondo produce risposte costose, lente e spesso meno precise. Il lavoro corretto è selezionare, comprimere e ordinare il contesto.

Questa lezione insegna a trattare il contesto come una risorsa di progetto: non “più testo possibile”, ma “informazione necessaria nella forma più utile”.

Token: cosa cambia nella pratica

Un token è un pezzo di testo usato dal modello per leggere e generare. Non coincide sempre con una parola: codice, simboli, stringhe lunghe e testo con formattazione possono consumare più token di quanto sembri.

Per chi sviluppa, i token contano in quattro modi:

• costo: input e output lunghi costano di più;
• latenza: più testo da leggere e generare aumenta il tempo di risposta;
• attenzione: più materiale irrilevante rende più difficile isolare ciò che conta;
• debuggabilità: un prompt enorme è più difficile da correggere quando l’output non torna.

Un prompt breve non è automaticamente migliore. Un prompt lungo non è automaticamente più completo. Il criterio è: ogni blocco di contesto deve avere una funzione.

Finestra di contesto: limite dichiarato e limite utile

La finestra di contesto indica quanta informazione può entrare nella richiesta. Il limite utile però dipende dal task. Una code review su un diff piccolo può peggiorare se aggiungi file non coinvolti. Una diagnosi architetturale può richiedere README, struttura directory e decisioni precedenti, ma non ogni riga della repo.

Tre segnali indicano che il contesto è gestito male:

• il modello risponde su dettagli non rilevanti;
• ignora vincoli scritti in mezzo al prompt;
• propone soluzioni incompatibili con file o pattern che avevi incollato.

In questi casi non basta ripetere “leggi bene”. Devi ristrutturare il prompt.

Strategie di compressione

Selezione

Prima scegli cosa serve. Per un bug: sintomo, passi, log, file coinvolti, risultato atteso. Per un refactor: obiettivo, confini, test, pattern esistente. Per una decisione: vincoli, alternative, criteri.

Riassunto controllato

Se un file è lungo ma servono solo responsabilità e interfacce, riassumilo. Un buon riassunto per LLM non è narrativo: elenca funzioni, tipi, dipendenze, effetti collaterali e parti da non modificare.

Ordine

Metti prima istruzioni stabili e obiettivo, poi contesto, poi dati o file, poi formato di risposta. Evita di nascondere vincoli importanti tra grandi blocchi di codice.

Riferimenti invece di copia

Quando lavori con agenti che possono leggere file, non incollare tutto. Indica i file probabili e chiedi di esplorare con letture mirate. Il contesto recuperato al momento giusto è spesso migliore del contesto incollato a caso.

Esempio operativo

Prompt rumoroso:

Ti incollo tutto il progetto. Trova perché il form non salva.

Prompt selettivo:

Obiettivo: diagnosticare perché il form "Nuovo prestito" non salva.

Contesto minimo:
- il problema avviene solo dopo il refactor del caso d'uso registraPrestito;
- il salvataggio usa localStorage;
- non modificare la UI finché non hai isolato la causa.

File rilevanti:
- src/application/registraPrestito.ts
- src/infrastructure/prestitiLocalStorage.ts
- src/pages/prestiti.astro

Prima restituisci:
1. quali informazioni ti mancano;
2. quali file leggere in ordine;
3. tre ipotesi falsificabili;
4. il test o controllo manuale per ciascuna ipotesi.

Laboratorio guidato

Prendi tre prompt reali o realistici:

1. uno per debug;
2. uno per generazione codice;
3. uno per review o refactor.

Per ciascuno:

1. evidenzia testo necessario, utile, ridondante e pericoloso;
2. rimuovi almeno il 30% del contenuto senza perdere informazioni essenziali;
3. sposta i vincoli importanti in alto;
4. sostituisci blocchi lunghi con riassunti strutturati;
5. verifica se l’output resta uguale o migliora.

Output atteso

Una checklist per stimare a occhio il costo in token di un prompt e identificare contenuto eliminabile.

La checklist deve includere:

• cosa mettere sempre;
• cosa mettere solo se serve;
• cosa non incollare mai;
• quando usare riassunto invece di file completo;
• quando dividere il task in più prompt.

Checklist di verifica

• so spiegare perché più contesto può peggiorare una risposta;
• so distinguere contesto necessario, utile e rumoroso;
• so comprimere un file lungo in una scheda tecnica;
• so ordinare un prompt in modo che obiettivo e vincoli non vengano sepolti;
• ho riscritto almeno un prompt reale riducendo token e ambiguità.

Errori comuni

Incollare l’intera repo in chat. È costoso, difficile da leggere e spesso peggiora il focus.

Nascondere vincoli importanti dopo il codice. Se un vincolo è critico, deve stare vicino all’obiettivo e al formato di risposta.

Confondere riassunto con interpretazione. Un riassunto utile deve preservare interfacce, responsabilità e limiti, non sostituirli con opinioni.

Collegamenti

• Modulo: Fondamenti per sviluppatori — lezione 2 del corso.
• Lezione precedente: Modello mentale di un LLM per chi sviluppa.
• Prossima lezione: Determinismo, temperatura, parametri di sampling.