Capitolo 2 — Streaming e il governo della cronologia
Due raffinamenti separano il tuo giocattolo del capitolo 1 da qualcosa di usabile.
Il primo è lo streaming. Di default l'API lavora così: il modello genera tutta la risposta, poi te la consegna in blocco. Per una risposta lunga significa fissare uno schermo vuoto per lunghi secondi. Lo streaming invece ti consegna la risposta mentre nasce, token dopo token — l'effetto macchina da scrivere delle chat commerciali, che ora sai essere la modalità naturale del modello: genera un token alla volta, e lo streaming te li passa man mano. Nel codice cambia poco (un ciclo sugli eventi invece di una singola risposta), nell'esperienza cambia tutto.
Il secondo è il governo della cronologia. Il tuo loop di chat rimanda tutta la conversazione a ogni turno, e la conversazione cresce. Prima o poi succedono due cose, entrambe spiacevoli: superi la finestra di contesto (errore), oppure ci stai dentro ma paghi sempre di più — perché ogni token della cronologia viene ri-processato e ri-pagato a ogni turno. La soluzione è avere una strategia: potare (butti i turni più vecchi, tenendo gli ultimi N), oppure riassumere (comprimi il vecchio in una sintesi e tieni quella). La potatura è semplice ma perde informazione; il riassunto conserva di più ma costa una chiamata in più ogni tanto.
Riconosci il tema? È il context engineering del Livello 1, diventato codice: decidere cosa il modello vede, turno dopo turno, con la differenza che ora la decisione la prende un algoritmo che scrivi tu. La versione da produzione di questo problema — cosa tenere, cosa comprimere, cosa recuperare al volo — ti accompagnerà fino al Livello 5.
L'esperimento del giorno. Aggiungi al tuo loop lo streaming e una potatura oltre i dieci turni. Poi stampa, a ogni turno, quanti token stai mandando (l'API te lo dice nella risposta): guardare quel numero crescere turno dopo turno vale più di qualsiasi spiegazione sul perché la cronologia va governata.