Immagina di aver integrato un assistente AI nel tuo processo di supporto clienti. Funziona bene per le prime tre o quattro domande. Poi il cliente chiede qualcosa che dipende da quello che ha detto due minuti prima, e l'assistente risponde come se non avesse sentito nulla. Il cliente si irrita. Il tuo team di supporto interviene. Hai speso soldi per uno strumento che dimentica.
Questo non è un problema di intelligenza del modello. È un problema di architettura della memoria. E per chi gestisce un'azienda senza un team AI dedicato, capire questa distinzione vale tanto quanto scegliere il modello giusto.
Le tre architetture di memoria che esistono oggi
Nel 2024 e 2025, chi costruisce sistemi LLM aziendali lavora essenzialmente con tre approcci. Non sono mutuamente esclusivi, ma hanno costi, complessità e casi d'uso molto diversi.
Il primo è il contesto breve (context window): tutto ciò che il modello «vede» in una singola chiamata. GPT-4o gestisce fino a 128.000 token, Claude 3.5 Sonnet arriva a 200.000. Sembra tanto, ma un documento da 500 pagine in italiano supera già i 100.000 token. Il contesto breve è volatile: ogni nuova conversazione riparte da zero.
Il secondo è il RAG (Retrieval-Augmented Generation, ovvero generazione aumentata dal recupero di informazioni): il sistema recupera documenti rilevanti da una base di conoscenza esterna e li inietta nel contesto prima di rispondere. Non è vera memoria persistente, è recupero intelligente di informazioni strutturate.
Il terzo è la long-term memory persistente: il sistema scrive e legge stati, fatti, preferenze utente su un database esterno, spesso vettoriale. Ogni sessione può accedere a ciò che è stato appreso nelle sessioni precedenti. È la più potente e la più costosa da implementare correttamente.
Quando il contesto breve basta davvero
La risposta onesta è: più spesso di quanto pensi, se il tuo caso d'uso è delimitato.
Se stai costruendo un assistente per analizzare contratti, rispondere a domande su un singolo documento PDF, o supportare una sessione di brainstorming, il contesto breve fa esattamente quello che serve. Non hai bisogno di persistenza tra sessioni diverse. Vuoi velocità, semplicità, costi prevedibili.
Il costo di inference con context window lunghe scala linearmente con i token passati al modello. Se passi 50.000 token a ogni chiamata, paghi 50.000 token. Su GPT-4o, al momento in cui scrivo, i token in input costano circa 2,50 dollari per milione. Su volumi alti, questo diventa una voce significativa.
La regola pratica: usa il contesto breve quando la conversazione è atomica, ovvero quando ogni sessione ha senso da sola e non dipende da sessioni precedenti.
Quando serve il RAG (e come non sbagliarlo)
Il RAG è l'architettura più diffusa nelle PMI che integrano AI oggi. Funziona bene per casi specifici:
- Il tuo assistente deve rispondere su documenti aziendali (manuali, policy, listini, FAQ)
- La base di conoscenza è relativamente stabile o aggiornata in modo controllato
- Non ti interessa che il sistema «ricordi» l'utente tra sessioni diverse, ma che conosca la tua azienda
Dove il RAG fallisce è sulla qualità del recupero. Se i tuoi documenti sono mal strutturati, se i chunk sono troppo grandi o troppo piccoli, se non hai curato i metadati, il retrieval porta contesto irrilevante e il modello risponde male. Non è colpa dell'AI: è un problema di ingegneria dei dati.
Un errore comune è caricare tutto nel RAG aspettandosi magia. Il RAG funziona quando la domanda dell'utente e il documento rilevante condividono abbastanza sovrapposizione semantica. Su domande vaghe o su knowledge base mal organizzate, il sistema recupera i chunk sbagliati e il modello alucina con più sicurezza del solito, perché ha «una fonte» da citare.
Costo aggiuntivo del RAG: devi mantenere un database vettoriale (Pinecone, Weaviate, pgvector su Postgres, ecc.), pagare gli embedding a ogni aggiornamento dei documenti, e gestire la pipeline di chunking. Non è proibitivo, ma non è gratuito.
Long-term memory: quando è davvero necessaria
La long-term memory persistente è la soluzione più sofisticata e quella di cui la maggior parte delle PMI non ha bisogno oggi, almeno non nella forma completa.
Ha senso considerarla in tre scenari precisi:
1. Assistenti personalizzati per utenti ricorrenti: il sistema deve ricordare preferenze, storico decisioni, tono preferito, contesto professionale di ogni utente nel tempo.
2. Agenti autonomi con cicli lunghi: un agente che lavora su un progetto per settimane deve ricordare lo stato intermedio tra una sessione e l'altra.
3. CRM aumentato: vuoi che l'AI ricordi ogni interazione con un cliente specifico e adatti le risposte di conseguenza.
L'implementazione corretta della long-term memory richiede di rispondere a domande non banali: cosa vale la pena memorizzare? Con quale granularità? Per quanto tempo? Come gestisci la privacy e il GDPR? Come eviti che la memoria accumuli errori nel tempo?
Framework come MemGPT (ora Letta) o le funzionalità memory di sistemi come LangGraph cercano di rispondere a queste domande. Anthropic ha documentato approcci alla memoria esterna nei suoi lavori sull'architettura degli agenti. Ma richiedono tempo di implementazione e manutenzione continua.
Se non hai un team tecnico interno, valuta prima se un RAG ben fatto risolve il 90% del problema. Spesso è così.
L'impatto sui costi che nessuno ti dice
C'è una variabile che quasi nessun fornitore AI ti spiega chiaramente: la memoria lunga aumenta i costi di inference in modo non lineare.
Se usi la long-term memory per iniettare nel contesto tutte le informazioni rilevanti sull'utente a ogni chiamata, puoi trovarti a passare 20.000 token di «memoria» prima ancora di includere il messaggio dell'utente. Moltiplicato per migliaia di chiamate giornaliere, il conto sale.
Alcune strategie per contenere i costi:
- Usa modelli più economici per il retrieval e la sintesi della memoria, e modelli più capaci solo per la risposta finale
- Comprime la memoria periodicamente: invece di accumulare trascrizioni grezze, riassumi in fatti strutturati
- Separa la memoria «fredda» (raramente acceduta) da quella «calda» (usata spesso), e inietta solo quella calda nel contesto
Senza questa ottimizzazione, un sistema con long-term memory può costare cinque o dieci volte di più rispetto a uno con solo context window, a parità di conversazioni gestite.
La mossa concreta per domani mattina
Prima di scegliere l'architettura, rispondi a questa domanda per il tuo caso d'uso specifico: la qualità della risposta dipende da informazioni prodotte in sessioni precedenti, oppure dipende da documenti e dati aziendali esistenti?
Se la risposta è «sessioni precedenti», valuta la long-term memory. Se è «documenti aziendali», costruisci un RAG pulito con chunking curato. Se la risposta è «nessuna delle due», stai probabilmente sovra-ingegnerizzando: parti con il contesto breve, misura i limiti reali, e poi aggiungi complessità solo dove i numeri lo giustificano.