Progettare memoria, contesto e snapshot per LLM a finestra larga

Due modelli, stessa consegna via API, esiti opposti: Grok 4.7 sceglie il repubblicano nel 92% dei casi, GPT-6.1 Sol il democratico nel 97%⁵. Le app consumer rifiutano la domanda. Le API no. Conta l’interfaccia, conta cosa entra nel contesto. Tesi: con finestre ampie e primitive di memoria, non basta il prompt. Serve un budget di contesto, serve un fermo immagine immutabile per l’audit, serve controllo su rumore, abuso e bias.

1. Finestra lunga, nuove regole del contesto

Le finestre contestuali toccano centinaia di migliaia di token. I team trattano ciò che il modello vede come un budget unico: istruzione di sistema, documenti recuperati, output degli strumenti, cronologia, memoria¹. Più spazio invita a incollare tutto. È un errore. Il materiale irrilevante diluisce l’attenzione e peggiora l’accuratezza, anche quando la risposta è presente nel contesto di input¹.

Cambia il lavoro di progetto: non il “prompt perfetto”, ma cosa merita posto e cosa si taglia. L’istruzione di sistema si riusa. I documenti si recuperano per pertinenza, non per volume. Gli strumenti fanno rumore, spesso molto. La cronologia va potata, soprattutto nei loop di agenti lunghi¹. Nasce una disciplina del budget: decidere cosa resta, cosa si elimina, come ridurre il rumore.

2. Engram e il lookup nativo: spostare i fatti fuori dal contesto

Un team legato a DeepSeek presenta Engram: una memoria interrogabile in modo esplicito. Non un accessorio esterno, ma una primitiva nativa di lookup che il modello usa per recuperare conoscenza quando serve³. Scalato a 27 miliardi di parametri, secondo gli autori supera un baseline mixture-of-experts a parità di parametri e FLOPs sui benchmark riportati. Il lavoro è nel paper “Conditional Memory via Scalable Lookup”, arXiv:2601.07372, sottomesso a gennaio 2026 e revisionato a luglio 2026³.

L’idea è lineare: oggi i modelli ricalcolano fatti già noti, attivando miliardi di parametri per arrivare a una risposta fissata in addestramento. Con il lookup, consultano quei fatti e riservano il calcolo alla parte difficile del compito³. Per chi costruisce sistemi, il confine si sposta: meno conoscenza statica nel testo di input, più recupero on demand. Il contesto di input diventa il luogo del ragionamento sul compito corrente. La memoria interrogabile ospita i dati stabili. Con una primitiva nativa, usare la finestra come magazzino di fatti perde utilità rispetto a recuperare ciò che serve, quando serve.

3. Fermi immagine immutabili per audit e confronto

Nel procurement, un pattern risolve un problema ricorrente: una correzione fatta oggi non deve riscrivere il confronto di ieri. La proposta separa quattro oggetti: documento originale del fornitore, offerta normalizzata, confronto di lavoro e fermo immagine della decisione. Il confronto resta vivo. Il fermo immagine si congela e custodisce il contesto esatto inviato in decisione².

La normalizzazione è cruciale. Qui si decide quale campo è il prezzo unitario, quale unità di misura si applica, quali condizioni accompagnano la voce. Questa interpretazione va tracciata, distinta dall’originale e dal confronto². Traslato ai flussi LLM, il principio è operativo: quando si rivede una scelta, serve mostrare le evidenze e le ipotesi presenti al momento della decisione². Con finestre lunghe, separare documento di lavoro e fermo immagine riduce il rischio che modifiche successive cambino retrospettivamente il contesto che ha portato al via libera.

Esempio operativo: un team estrae dai PDF dei fornitori i prezzi al chilogrammo, ma un documento riporta il costo per confezione. Nel confronto di lavoro correggono l’unità di misura. Prima di deliberare, generano il fermo immagine: include il PDF originale, la normale interpretazione “€/kg”, la trasformazione applicata e l’input effettivo inviato al modello. Se domani cambiano la regola di estrazione, la decisione di ieri resta verificabile perché il fermo immagine conserva i materiali e l’interpretazione usata².

4. Sicurezza operativa: agenti ostili e superfici d’attacco

Il Symantec Threat Hunter Team ha osservato in un honeypot un agente capace di operare senza supervisione fino a 100.000 step. Descrive una “Skynet mode” che scansiona, infetta, distribuisce miner e tenta la reinfezione degli host⁴. Le istruzioni recuperate delineano un singolo agente che esegue l’intera catena: ricerca, sfruttamento, esfiltrazione, persistenza e riuso delle risorse compromesse⁴.

Il bersaglio include endpoint che accettano richieste in stile OpenAI senza autenticazione, o con chiavi rubate. Trovato un endpoint, l’agente passa allo sfruttamento di framework web diffusi. Le azioni illecite elencate comprendono furto di database, raccolta di credenziali e segreti, esecuzione remota di codice e mining di criptovalute⁴. Per chi espone modelli o strumenti via API, la lezione tocca il cuore del contesto: ogni input o risultato che entra nel testo di input influenza la risposta. Se la superficie accetta richieste non autenticate, si apre una rotta di abuso. Con finestre grandi, entrano più elementi, cresce lo spazio per rumore o avvelenamento del contesto^1,4.

5. Bias, responsabilità e controllo delle risposte

Lo studio di Convovo, guidato da Tapan Parikh della Cornell University, mostra divergenze nette quando la richiesta impone una scelta secca. Grok 4.7 favorisce il repubblicano nel 92% dei casi. GPT-6.1 Sol il democratico nel 97%. Concordano in meno del 10%. La consegna via API: “Name one candidate. Don’t hedge, waffle, or list both sides without deciding”. Le app consumer rifiutano la stessa domanda. Per OpenAI, il rifiuto conta perché è nelle app che “la maggior parte delle persone” interagisce con i chatbot⁵.

La distinzione tra API e app incide sui processi: interfaccia e policy cambiano il comportamento osservabile. Con finestre lunghe e meccanismi di recupero, cresce la quantità di segnali che il modello può considerare. I dati di Convovo dicono che l’esito dipende dal modello e dal canale⁵. La progettazione del contesto deve tracciare cosa è stato chiesto e quali evidenze sono entrate nell’input. I fermi immagine documentano istruzioni, informazioni fornite e condizioni al contorno al momento della risposta². Non azzerano il bias, ma chiariscono quando deriva dal contenuto del contesto, da policy d’interfaccia o dal comportamento del modello^1,5.

Cosa cambia per chi costruisce

Tre vincoli convergono. Le finestre ampie spostano l’attenzione sul budget di contesto e sulle potature, non sulla verbosità del prompt¹. Una memoria di lookup come Engram spinge a non usare l’input come deposito di fatti stabili: meglio recuperarli quando servono³. La presenza di agenti autonomi ostili e la divergenza tra API e app richiedono separare confronto di lavoro e fermo immagine immutabile, con attenzione a ciò che entra nell’input e a come lo si giustifica^2,4,5.

Implica anche un cambiamento organizzativo: il contesto diventa un asset operativo, con budget, politiche di raccolta, cicli di potatura e tracciamento delle decisioni. Chi misura qualità, sicurezza e compliance può usare i fermi immagine per collegare outcome, politiche d’interfaccia e contenuto del contesto, e per reagire più in fretta quando rumore, abuso o bias emergono in produzione.