Tempo di lettura: 5 minuti; Colonna sonora: Isolated System - Muse
La luce artificiale cadeva morbida dal soffitto bianco. Francesco lavorava in un open space moderno e sobrio: muri grigi, ampie vetrate, tocchi di verde pastello, odore di limone e ozono. Davanti a lui, il monitor curvo rifletteva il suo volto mentre digitava nel Copilot aziendale. Il codice suggerito da GPT sembrava corretto, elegante perfino, ma ignorava i contenuti della riunione avvenuta quel pomeriggio con l’ufficio legale e, se applicato senza correzioni, avrebbe compromesso la validità dei consensi privacy del CRM. Sarebbe bastato che la macchina avesse avuto accesso ai contenuti della riunione per cogliere l’errore, ma il GPT che aveva prodotto il codice non era collegato al LLM che ne aveva riassunto i punti chiave. I Copilot sono potenti, ma ingenui: non comprendono il contesto, pensò tra sé e sé Francesco, mentre correggeva il codice e committava il branch. Senza quell’intervento, l’errore sarebbe finito in produzione con conseguenze disastrose. Salvò il file, alzò lo sguardo verso il tramonto terso a ovest di Milano, consapevole di aver fatto ancora una volta la differenza rispetto alle macchine. Si concesse una sorsata di caffè tiepido, scrutò da lontano il Monte Rosa e riprese a lavorare.
Se anche voi siete come me – e, visto che mi leggete, probabilmente lo siete – non sarà passato giorno senza che abbiate aperto il vostro editor GPT e provato a far svolgere a un LLM un compito che ieri avreste ritenuto impossibile.
Magari, in giornate più tranquille, siete riusciti a strappare un’ora al ritmo serrato delle conference call, avete puntato il browser su N8N e provato a costruire una catena di prompt o programmare un agente che vi sollevasse da qualche attività ripetitiva, con fortune alterne.
Negli ultimi due anni ci siamo concentrati nel progettare prompt sempre più raffinati e nell’affidarci sempre di più agli LLM. Tuttavia, man mano che ci siamo addentrati nell’ingegneria del prompt, ci siamo accorti che le risposte dell’AI diventano progressivamente più inconsistenti con l’aumentare della complessità del compito. In genere conosciamo i limiti dei modelli e ci giriamo elegantemente attorno.
Il problema è che, di base, le macchine LLM non hanno molto contesto se non quello che possiamo fornirgli all’interno dei prompt e tramite dati di appoggio: fogli Excel, documenti di testo, fotografie. Altre volte sono dotate di “connettori” che le aiutano a recuperare informazioni online. Queste informazioni aggiuntive – note come RAG, Retrieval-Augmented Generation – servono a migliorare la consapevolezza della macchina su ciò che vogliamo ottenere. Funzionano, ma non sempre e non per tutto.
Tutti i dati che forniamo e quelli che la macchina recupera finiscono nella “memoria di contesto” dell’LLM: uno spazio vettoriale lasciato libero da associazioni di parole predefinite durante il training, che la macchina può utilizzare liberamente in fase di inferenza (cioè quando le poniamo domande). Questo spazio è fissato per ogni LLM: i modelli più recenti ne hanno di più, i più vecchi di meno. Non può essere modificato.
Quando la macchina non riesce ad andare oltre le informazioni disponibili, o quando la memoria di contesto si esaurisce, perde la capacità di interpretare correttamente l’intento e commette errori: allucina.
Il punto è che, superato un livello base di ingegneria del prompt, chiunque voglia usare gli LLM per aumentare la produttività in azienda deve fare i conti con questo limite. Soprattutto se comincia a concatenare più prompt per ottenere un risultato, o a sfruttare le capacità agentiche emerse negli ultimi mesi su Perplexity e OpenAI.
La manifestazione di una memoria di contesto “esaurita” mi è capitata regolarmente negli ultimi mesi. Alcuni esempi:
Il mese scorso ho chiesto a OpenAI GPT di tradurre un PowerPoint dall’italiano all’inglese mantenendo la grafica. La macchina ha tradotto il testo ma ha completamente spaginato le slide. Solo passando alla modalità agente e specificando che il file andava processato pagina per pagina il compito è stato eseguito correttamente. Posso immaginare che il prompt secco abbia esaurito subito la memoria di contesto, mentre l’esecuzione agentica abbia “spezzettato” il lavoro rendendolo gestibile.
La settimana scorsa dovevo verificare alcune regole di carrello su un sito che seguo. Ho preparato una matrice Excel con i risultati attesi come utente e ho chiesto a un agente OpenAI di navigare il sito, aggiungere i prodotti al carrello e verificare la corrispondenza con le aspettative. Task più complesso di una traduzione: dopo circa il ventesimo controllo su cinquanta, la macchina si è fermata dichiarando di aver esaurito la “context window”. È bastato rilanciare lo script e pagare qualche credito in più per completare il compito. Poco male, ma il problema resta.
C’è poi chi mi ha fatto notare che, anche quando la macchina riesce a contestualizzare il compito, fatica a contestualizzare il tempo impiegato per l’esecuzione.
Inoltre, ci sono i temi legati alla portabilità della memoria di contesto. Cosa succede se i tuoi programmatori usano Claude per lo sviluppo del codice, ma il GPT di Teams per fare le minute delle riunioni? Se i due sistemi non comunicano, come fa Claude a sapere che durante la riunione d’integrazione è emerso un problema, se quell’informazione resta “compartimentata” nel context model di Microsoft?
E ancora: cosa succede se nella vita quotidiana usi OpenAI (che storicizza i tuoi prompt nella sua memoria di contesto) e un giorno decidi di migrare a Perplexity? Perdi tutto? È un tema di migrabilità del dato che ricorda molto la causa persa da Microsoft, accusata di impedire agli utenti di installare altri browser o migrare facilmente i segnalibri da Internet Explorer. Possiamo aspettarci lotte per il diritto di possedere la propria memoria di contesto e migrarla liberamente?
Infine, di chi è la proprietà del “contesto” dei prompt che un lavoratore esegue dentro un GPT aziendale? Non parlo di copyright – già regolamentato – ma proprio del contesto, della memoria vettoriale, della capacità della macchina di ricordare informazioni rilevanti per un task. Quando un dipendente lascia l’azienda, la memoria di contesto si perde? Qual è il quadro privacy? È analogo a quello di una casella di posta elettronica?
Nota a margine: proprio ieri, nel tentativo di rispondere a queste domande, ho scoperto che il tema è già noto al punto che alcune aziende hanno creato prodotti SaaS per affrontarne almeno le pieghe tecniche – e guadagnarci nel frattempo – osservando le query inserite negli LLM, le risposte e salvandole su database vettoriali esterni: OpenMemory, BrainAPI, Pinecone, BasicMemory.
Come gestiscano il tema privacy, però, resta tutto da chiarire e personalmente comincio a immaginare che le aziende vorranno cominciare a spostare della potenza di elaborazione dedicata agli LLM e lo spazio di archiviazione della memoria di contesto dal cloud ai propri datacenter interni, per mantenere un maggior controllo del dato.
In ultima analisi, gli agenti LLM hanno aperto possibilità straordinarie, ma a questo punto il problema non mi sembra più essere la potenza del modello, ma la gestione del contesto: il suo utilizzo, la sua migrabilità e a chi appartiene.
Mi chiedo quindi, e apro la discussione con voi, rispetto a questi temi:
A chi dovrebbe appartenere la memoria di contesto? Deve essere un asset per la persona, l’azienda oppure il provider tecnologico?
Avete timore anche voi della frammentazione tra piattaforme LLM e la possibilità di rimanere prigionieri in ecosistemi non integrati?
Come pensate che cambieranno la Privacy e il diritto del lavoro quando il valore di un dipendente sarà legato anche al patrimonio di contesto che avrà costruito nei prompt?
Tutti parlano di potenza di calcolo, ma credo che converrebbe fin da subito aprire una discussione seria sulla sovranità del contesto.
In un sistema isolato l’entropia può solo aumentare, dopotutto. Voi cosa ne pensate?