Il context caching vuole registri di riuso

Il caching è una scelta di workflow, non uno sconto

Il context caching viene spesso capito male perché sembra una semplice ottimizzazione tecnica. Il provider dice che i token ripetuti possono essere messi in cache. Lo sviluppatore vede meno latenza o meno costo su prompt ricorrenti. Il finance nota una riga più leggera. A quel punto il team rischia di smettere di fare domande.

La tesi operativa è più severa: il context caching vuole registri di riuso. Se un workflow LLM usa sempre lo stesso pacchetto di policy, documentazione prodotto, rubriche, cataloghi, storia cliente o esempi, il team non dovrebbe trattare la cache come uno sconto invisibile. Dovrebbe registrare perché quel contesto è riusabile, quando diventa vecchio, come si verifica il cache hit e cosa succede quando il riuso non è più sicuro.

La documentazione Google sul context caching nella Gemini API è un buon appiglio tecnico: parla di token di input ripetuti, caching implicito per i modelli Gemini 2.5 e successivi, pratiche sul prefisso del prompt per aumentare le probabilità di hit e metadati d’uso che riportano i token in cache. Sono informazioni utili, ma non bastano a governare un workflow. L’artefatto mancante è un piccolo registro posseduto dal team che gestisce quel workflow.

Questa decisione è diversa dal decidere quanto contesto debba portare un agente. Un budget di contesto serve a capire se l’agente sta portando troppo stato prima della release, come in Gli agenti locali vogliono budget di contesto. Un registro di riuso fa un’altra domanda: se questo blocco compare di continuo, dobbiamo metterlo in cache, aggiornarlo, accorciarlo o spostarlo fuori dal prompt?

Cosa contiene il registro di riuso di Marco?

Il registro deve essere volutamente noioso. Deve stare in uno spreadsheet, in un file YAML, in un registro operativo o nel repository del workflow. Se il team ha bisogno di un sistema complesso solo per rispondere a queste domande, il workflow è già troppo opaco.

Per ogni blocco di contesto ripetuto, registrerei sette campi.

Primo, il prefisso stabile. È la parte del prompt che deve rimanere strutturalmente coerente perché il riuso abbia senso. In pratica può includere l’istruzione di sistema, il ruolo assegnato al modello e il contenuto comune più grande messo all’inizio della richiesta. Se il prefisso cambia continuamente perché ogni persona modifica il prompt a modo suo, il caching non è una strategia di governance. È fortuna.

Secondo, il blocco di contesto riusabile. Bisogna nominare il materiale reale, non una categoria vaga. “Policy rimborsi supporto v14” è ispezionabile. “Knowledge aziendale” non lo è. Un product o ops lead deve poter aprire la fonte, vedere il blocco esatto e decidere se deve stare davvero nel prompt.

Terzo, la prova del cache hit. Il registro deve puntare ai log di run, ai metadati d’uso o al campo di dashboard che mostra che i token in cache sono stati conteggiati davvero. Gemini espone il reporting dei token in cache nei metadati d’uso, ma la regola più generale vale per qualsiasi provider: non chiamare cached un workflow se non puoi mostrarne la prova a livello di esecuzione.

Quarto, il proprietario della scadenza. Ogni blocco riusabile ha bisogno di una persona o di un team responsabile di sapere quando è scaduto. Legal possiede le policy legali. Support possiede le macro e il linguaggio operativo. Product possiede le regole di entitlement. Data possiede le descrizioni degli schemi. Se nessuno possiede la scadenza, il blocco non dovrebbe essere ottimizzato per il riuso.

Quinto, il trigger di invalidazione. Scrivi l’evento che rompe il riuso prima che accada. Esempi: cambio policy, cambio prezzi, migrazione di modello, regressione negli eval, revisione post incidente, rilascio documentazione, cambio dell’indice di retrieval o apertura a un nuovo segmento cliente. “Quando sembra vecchio” non è un trigger.

Sesto, il comportamento di fallback. Se la cache manca, viene invalidata o è sospetta, il workflow gira senza cache, recupera contesto fresco, chiede a un umano, degrada la risposta o si ferma? Questo punto conta perché il riuso economico abitua facilmente i team a ignorare il percorso non felice.

Settimo, la soglia decisionale. Il team deve dichiarare la regola che giustifica la cache invece di accorciare o spostare il contesto. Una regola semplice basta: mettere in cache solo quando il blocco è grande, ripetuto, posseduto, misurato e abbastanza stabile da rendere il rischio operativo inferiore al beneficio. Se uno di questi aggettivi non è vero, serve un’altra scelta.

Quando conviene mettere in cache il contesto?

Conviene mettere in cache il contesto ripetuto quando il riuso è frequente, il prefisso è stabile e il rischio di contesto vecchio ha un owner attivo. Non basta che il blocco sia lungo.

Un pacchetto di documentazione prodotto usato in ogni triage del supporto può essere un buon candidato. Una nota compliance che cambia ogni settimana forse no, anche se è lunga. Una storia cliente specifica può dover stare fuori dal prefisso riusabile se è volatile o sensibile. Un gruppo di esempi per formattare un report interno può essere sicuro da mettere in cache se cambia raramente e gli errori sono facili da intercettare.

La regola decisionale che uso con i team è questa: il contesto ripetuto ha quattro destinazioni possibili.

Mettilo in cache quando è stabile, grande, spesso riusato e misurabile con prove di cache hit. Aggiornalo quando è prezioso ma ha un ritmo di scadenza noto. Accorcialo quando esiste solo perché nessuno ha ripulito il prompt dopo il prototipo. Esternalizzalo quando il modello non dovrebbe portare quel materiale nel prompt, per esempio perché la risposta deve dipendere da retrieval, lookup su database, servizio policy o tool call.

Qui il caching tocca la governance più ampia dei workflow AI. Se il workflow ha già corsie di escalation, stati di fallback e owner, la cache può renderlo più efficiente. Se il workflow è solo un prompt in produzione, la cache rende il disordine più economico. Non è progresso. È la stessa lezione di I workflow AI vogliono corsie di escalation: il percorso del modello è solo una corsia del sistema operativo.

Un cache hit non è un segnale di qualità

Un cache hit dimostra riuso, non correttezza. Dice che il workflow ha beneficiato di token di input ripetuti. Non dice che quel contesto sia aggiornato, sufficiente, sicuro o ben delimitato.

Questo è il rischio avversario. Il caching può rendere più economico e veloce un contesto sbagliato. Una regola di rimborso scaduta diventa più scalabile. Un prompt gonfio diventa più sopportabile. Un’istruzione fragile diventa più facile da mantenere. L’ottimizzazione può rimandare la conversazione difficile: questo contesto deve ancora stare qui?

Per questo il registro di riuso deve stare accanto agli eval, non sostituirli. Il lavoro di Hamel Husain sugli eval per prodotti AI è utile perché tratta sistemi di valutazione robusti, ispezione delle trace e test ricorrenti come parti centrali del miglioramento dei prodotti LLM. Il registro risponde alla domanda: il riuso del contesto è controllato? Gli eval rispondono alla domanda: il comportamento del workflow è accettabile? Servono entrambi.

La review può essere leggera. Una volta per ciclo di release, prendi i workflow ricorrenti con più volume o più spesa in token. Per ciascuno, guarda il registro e fai cinque domande. Il prefisso è ancora stabile? Il blocco riusabile è ancora quello giusto? I log mostrano prova di cache hit? È scattato qualche trigger di invalidazione? Eval o incidenti hanno mostrato failure legate al contesto ripetuto?

Se una risposta non è chiara, non limitarti a spegnere la cache. Decidi se aggiornare, accorciare o esternalizzare. L’obiettivo non è punire l’ottimizzazione. È renderla ispezionabile.

L’artefatto operativo conta più della feature

Le feature dei provider cambieranno. Soglie minime di token, famiglie di modelli, campi d’uso e comportamento della cache evolveranno. La pratica stabile non è una specifica impostazione API. È la disciplina di registrare il riuso come decisione di prodotto.

Un buon registro di riuso facilita tre conversazioni. Engineering vede se il workflow sta beneficiando tecnicamente della cache. Product vede se il contesto ripetuto rappresenta ancora il comportamento desiderato. Operations vede chi possiede la scadenza e cosa accade quando il percorso sicuro si rompe.

Il registro non ha bisogno di cerimonia. Ha bisogno di struttura sufficiente perché una persona esperta possa sfidare la decisione. Se una riga dice “mettere in cache il pacchetto policy” ma non ha owner, trigger di invalidazione e prova di hit, la decisione non è pronta. Se la riga mostra prefisso stabile, blocco nominato, prova di token in cache, owner, trigger, fallback e soglia, il team può mettere in cache con gli occhi aperti.

Il confine pratico è questo: non lasciare mai che il context caching sia solo un modo per ridurre la bolletta. Trattalo come una scelta di design del workflow. Metti in cache i blocchi che meritano riuso, aggiorna quelli che invecchiano con ritmo prevedibile, accorcia quelli sopravvissuti dal prototipo ed esternalizza quelli che appartengono a retrieval o tool. Il registro è piccolo, ma costringe a fare la domanda giusta prima che lo sconto nasconda il rischio.