Cosa mettere nel contesto, e come
Un modello non sa niente di te finché non glielo scrivi. Tutte le tecniche di questa pagina — prompt, RAG, CAG, cache, batch, memoria — servono a una cosa sola: decidere quali token entrano nella finestra, in che ordine, e quante volte li paghi.
Un assistente interno attraversa tutto il diagramma. Ogni riquadro con la riga rossa racconta cosa gli succede in quello stadio.
«quanti giorni di permesso mi restano?»
4.000 documenti HR: contratti, circolari, accordi firmati e scansionati.
La finestra di contesto è una scrivania, non una memoria
È grande, ma è finita, si paga a peso, e viene sgombrata a ogni chiamata. Il modello non ricorda la richiesta precedente: gliela rimandi tu, per intero, ogni volta.
Un consulente bravissimo e senza memoria, che ogni mattina entra in ufficio senza ricordare nulla di ieri. Quello che gli lasci sulla scrivania è tutto ciò che sa del tuo caso. Tutta l'ingegneria che segue è la disciplina di preparare quella scrivania.
Tutti i modelli peggiorano man mano che il contesto si allunga, anche su compiti facili: è il «context rot», ripreso allo stadio 11. In pratica la finestra affidabile è una frazione di quella dichiarata. Che ci stia non basta: bisogna chiedersi se serve.
Anatomia di un prompt
Per il modello è un unico flusso di token: la divisione in blocchi serve a te. Ma l'ordine conta davvero — sia per la qualità della risposta, sia per il costo, come si vedrà allo stadio 09.
Il fascicolo che passi a un collega esterno: prima chi è e cosa deve fare, poi due lavori già fatti come esempio, poi il materiale, e in fondo la domanda. Nessuno consegnerebbe il materiale prima di aver detto a cosa serve.
Prompting: poche mosse che funzionano
Delle decine di tecniche pubblicate ne restano quattro che pagano in produzione. Le altre sono varianti, o rimedi a difetti che i modelli recenti non hanno più.
Un briefing a un professionista competente ma nuovo. Non gli spieghi il mestiere: gli dai il contesto, gli mostri un lavoro fatto bene, gli dici in che formato lo vuoi e gli lasci il tempo di ragionare. Le stesse cose funzionano qui, per lo stesso motivo.
Mostra, non descrivere
Due o tre esempi completi valgono più di mezza pagina di istruzioni, soprattutto per il formato. Includi anche un caso limite gestito bene.
Lascia spazio prima della risposta
Chiedere di ragionare per passi prima di concludere migliora i compiti a più passaggi. Sui modelli di ragionamento è già incorporato: si regola il budget, non si supplica.
Marca dove finisce il dato
Tag espliciti attorno ai documenti separano ciò che è materiale da ciò che è istruzione e riducono, senza eliminarlo, il rischio che il modello esegua istruzioni nascoste nei documenti.
Chiedi uno schema
JSON con schema imposto invece di prosa da interpretare: elimina una classe intera di errori a valle e rende testabile la risposta.
«Rispondi solo con quanto scritto nei documenti, altrimenti dichiara che non risulta» funziona meglio di «non inventare». Un'istruzione negativa lascia aperto tutto il resto.
Il testo recuperato è input non fidato, esattamente come l'input di un utente. Un documento può contenere istruzioni. Delimitalo, dichiaralo come dato, e non far dipendere azioni con effetti da ciò che ci trovi dentro.
Come far arrivare al modello ciò che non sa
Cinque strade. Le prime quattro si scelgono in base a quanto materiale c'è e quanto spesso cambia; la quinta, in base a quanto è complicata la domanda.
Un nuovo assunto davanti all'archivio aziendale. Puoi dargli i tre fogli che servono oggi, fargli leggere tutto l'archivio ogni mattina, lasciarglielo già letto e memorizzato, mandarlo a un corso di sei mesi, o dargli le chiavi dell'archivio e lasciarlo cercare da solo. Costano cose diverse e si aggiornano a velocità diverse.
Incollalo e basta
Finché il materiale ci sta nella finestra, questa è la soluzione giusta. Nessuna infrastruttura, nessun errore di recupero.
Fino a: qualche decina di documenti.
Cerca, poi rispondi
Si indicizza tutto una volta e a ogni domanda si recuperano solo i pezzi pertinenti. Scala a milioni di documenti e si aggiorna in tempo reale.
Costo: se il recupero sbaglia, il modello risponde bene alla domanda sbagliata.
Precaricato una volta sola
Tutto il corpus nel contesto, elaborato una volta e tenuto in cache. Nessuna ricerca, nessun pezzo mancante.
Vincolo: deve starci nella finestra. Stadio 08.
Riaddestrare il modello
Insegna comportamenti, stile, formati e gerghi. Non è il modo di insegnare fatti: quelli invecchiano e non si citano.
Errore comune: usarlo al posto del recupero.
Lascia cercare il modello
Invece di una pipeline fissa che recupera venti pezzi e li passa al modello, gli si danno strumenti di ricerca: testo, database, lettura di un file. Il modello decide cosa cercare, legge, e se non basta cerca di nuovo. Il RAG classico diventa uno degli strumenti, non la strada.
Costo: più chiamate e più latenza. In cambio regge domande a più passi e fonti eterogenee (stadio 06).
RAG: due tempi, e il primo non usa il modello
Un tempo offline che prepara l'indice, un tempo online che risponde. La qualità di un sistema RAG si decide quasi tutta nel primo, ma i problemi si vedono solo nel secondo.
Il bibliotecario e lo studioso. Il bibliotecario ha schedato tutto in anticipo e sa andare a colpo sicuro; lo studioso legge solo i tre volumi che gli arrivano sul tavolo e scrive la risposta. Se il bibliotecario porta il volume sbagliato, lo studioso non se ne accorge: risponderà benissimo, e a un'altra domanda.
una volta
ogni domanda
Il solo vettoriale sbaglia su codici, sigle e nomi propri: cerca significato, non stringhe. Si affianca sempre una ricerca testuale classica (BM25) e si fondono le due classifiche, di solito con la reciprocal rank fusion. È il singolo miglioramento con il miglior rapporto fra guadagno e fatica. Una via di mezzo è la late interaction (ColBERT): un vettore per ogni token invece che per chunk, più precisa e più pesante, lo stesso meccanismo della variante ColPali dello stadio 07.
Un secondo modello, più lento e più preciso, legge domanda e chunk insieme e riordina i primi venti. Costa decine o centinaia di millisecondi e recupera gran parte degli errori del primo passaggio.
Dove il RAG si rompe davvero
Nessuno di questi problemi riguarda il modello. Sono tutti a monte, e sono la ragione per cui un prototipo che funziona in un pomeriggio non regge il primo mese di uso vero.
Fotocopiare un manuale tagliando le pagine a metà. Ogni foglio è leggibile, ma la frase che ti serve è spezzata fra due fogli e nessuno dei due, preso da solo, dice a quale capitolo apparteneva.
Segui la struttura, non i caratteri
Taglia per sezione, articolo, paragrafo — non ogni 500 caratteri. Sovrapponi un poco i pezzi. Una tabella o un blocco di codice non si spezzano mai.
«Il presente articolo» — quale?
Un chunk isolato perde titolo, capitolo e data. Si rimedia anteponendo a ogni pezzo una o due frasi che lo collocano nel documento, scritte da un modello che legge il documento intero: è il «contextual retrieval». Nei test pubblicati dimezza circa i recuperi falliti, e con il reranker li riduce di due terzi. Con la cache sul documento costa poco.
Filtrare prima di cercare
Data, versione, permessi, tipo di documento. Servono a restringere il campo e, nel caso dei permessi, a non mostrare a qualcuno ciò che non deve vedere. Il controllo accessi va nel recupero, non nel prompt.
«Quante volte…», «riassumi tutto»
Il recupero dei primi k pezzi non risponde a domande aggregate né comparative. Vanno riconosciute e indirizzate altrove: una query sul database, una lettura completa in batch, oppure un indice a grafo (GraphRAG) che in fase di indicizzazione estrae entità e relazioni e prepara riassunti per gruppi di documenti. Costa molto costruirlo, ma risponde a «riassumi tutto».
Servono due misure separate: il recupero (il pezzo giusto era fra quelli passati al modello?) e la risposta (era corretta e fondata su quei pezzi?). Tenerle distinte dice subito quale metà sistemare. Bastano un centinaio di domande reali con la risposta attesa, raccolte una volta e rigiocate a ogni modifica.
Pixel RAG: indicizzare la pagina, non il testo
Il RAG classico comincia con l'estrazione del testo dai PDF, ed è lì che perde tabelle, grafici, moduli e timbri. Il pixel RAG salta quel passaggio: incorpora direttamente l'immagine della pagina con un modello che vede.
Trascrivere uno spartito a parole per poterlo archiviare, contro fotografarlo. La trascrizione perde tutto ciò che stava nella disposizione — e in un bilancio, in un modulo o in un organigramma la disposizione è l'informazione.
→ estrazione testo / OCR
→ chunk
→ embedding di testo
→ indice
Fragile su scansioni, colonne multiple, tabelle. Ogni errore di estrazione resta nell'indice per sempre.
→ immagine di ogni pagina
→ (nessun chunk)
→ embedding visivi della pagina
→ indice
La pagina resta intera. Al modello si passa l'immagine stessa, che la legge come la leggeresti tu.
Due varianti. La più precisa (ColPali, «late interaction») trasforma la pagina in centinaia di vettori, uno per zona, e la domanda in un vettore per parola: il punteggio confronta ogni parola con la zona che le somiglia di più. Recupero fine, indice pesante. La più leggera dà un solo vettore per pagina, come un embedding di testo. In letteratura si chiama visual RAG o visual document retrieval.
Sì: scansioni, moduli, bilanci, cataloghi, slide, tutto ciò che è nato per essere guardato. No: testo digitale pulito — lì il RAG testuale costa dieci volte meno e non perde nulla.
CAG: togliere del tutto la ricerca
Cache-augmented generation: se il corpus ci sta nella finestra, mettilo tutto dentro una volta, congela lo stato interno del modello e riusalo a ogni domanda. Niente indice, niente chunk, niente recupero da sbagliare.
Invece di mandare l'assistente in archivio a ogni domanda, glielo fai leggere tutto una volta il primo giorno — e lo assumi già preparato. Funziona benissimo finché l'archivio è una libreria, non un capannone.
| RAG | CAG | |
|---|---|---|
| Dimensione del corpus | illimitata | deve stare nella finestra |
| Errori di recupero | il rischio principale | nessuno esterno, ma il modello può trascurare il passaggio giusto se il corpus è lungo |
| Aggiornamento | immediato, per documento | si rifà la cache |
| Latenza per domanda | ricerca + generazione | solo generazione |
| Costo per domanda | basso, poche migliaia di token | lettura della cache: ridotta ma sull'intero corpus |
| Infrastruttura | indice, embedding, reranker | quasi nessuna |
Prompt caching: non ripagare ciò che non cambia
Il modello elabora il prompt dall'inizio alla fine. Se l'inizio è identico a quello di poco fa, il lavoro già fatto si può riusare — e allora quei token si pagano una frazione, e non si aspetta di rielaborarli.
Un segnalibro. Il consulente ha già letto le prime cento pagine del fascicolo: se il fascicolo comincia esattamente come prima, riparte dal segnalibro. Basta cambiare una virgola nella prima pagina e deve rileggere tutto — la cache vale solo per un prefisso identico, carattere per carattere.
Statico in cima, variabile in fondo
System, strumenti, esempi, corpus fisso: prima e sempre nello stesso ordine. Documenti recuperati e domanda: dopo. Una data o un nome utente messi in cima annullano la cache per tutti.
Scrivere costa un po' di più, leggere molto meno
La prima chiamata che riempie la cache costa qualcosa in più del normale; ogni successiva legge quei token a un decimo o meno. Conviene già dalla seconda o terza chiamata.
Da minuti a ore
Secondo il fornitore la cache dura da 5 minuti a qualche decina di minuti di inattività, e si rinfresca a ogni uso. Durate di un'ora o di un giorno si possono richiedere, pagando di più la scrittura o la conservazione. Conviene sul traffico continuo, non sulle chiamate isolate.
La latenza crolla
Non è solo risparmio: rileggere 100.000 token in cache è molto più rapido che elaborarli da capo. Su prompt lunghi il tempo alla prima parola si riduce in modo netto.
Batch: due cose diverse con lo stesso nome
Una è una modalità di consegna asincrona che costa circa la metà. L'altra è mettere più compiti in un singolo prompt. Si confondono spesso, e solo la prima è quasi sempre una buona idea.
La posta ordinaria contro l'espresso: stessa lettera, metà prezzo, arriva quando arriva. Diverso è infilare venti lettere nella stessa busta — risparmi la busta, ma se il destinatario ne salta una te ne accorgi tardi.
Mandi 50.000 richieste e torni domani
Si consegna un file di richieste indipendenti, si ritirano i risultati entro le ore successive. Circa metà prezzo, nessun limite di traffico da gestire.
Per: classificazioni di massa, arricchimento di archivi, valutazioni, indicizzazione. Mai per: qualcosa che un utente sta aspettando.
Venti domande in una chiamata
Risparmia sulle istruzioni ripetute, ma la qualità cala verso il fondo della lista, un errore di formato ne compromette venti e diventa difficile capire quale è andata storta.
Ha senso quando i compiti sono brevi, omogenei e si giudicano insieme. Con la cache attiva il vantaggio economico si assottiglia.
Cache, batch e recupero mirato agiscono su cose diverse e si sommano: la cache toglie il costo del prefisso ripetuto, il batch dimezza quello che resta sui lavori non urgenti, il recupero riduce quanti token entrano in gioco. Un carico di lavoro che le usa tutte e tre costa un ordine di grandezza meno dello stesso carico scritto in modo ingenuo.
Memoria: una finzione ben costruita
Nessun modello ricorda niente fra una chiamata e l'altra. Quello che i prodotti chiamano memoria è testo che qualcuno ha salvato altrove e reinserisce nel prompt al momento giusto. Decidere cosa tenere, cosa riassumere e cosa buttare è la disciplina che oggi si chiama context engineering.
Il consulente smemorato con un quaderno. Ogni sera qualcuno annota le cose importanti della giornata; ogni mattina gli mette il quaderno sulla scrivania. Sembra continuità, ed è archiviazione — con tutte le domande che ne derivano: chi decide cosa vale la pena annotare, e chi può cancellare.
Rimandare tutto
Ogni turno reinvia l'intera cronologia. Semplice e fedele, ma cresce senza limite: il costo per messaggio aumenta a ogni battuta.
Riassumere il vecchio
Quando la finestra si riempie, i turni lontani diventano un riassunto e gli ultimi restano per esteso. Oggi le API lo fanno da sole, lato server, e tolgono anche i risultati vecchi degli strumenti, spesso la parte più voluminosa. Ciò che deve sopravvivere al riassunto il modello lo scrive in un file di memoria.
Fatti estratti e archiviati
Preferenze e dati stabili estratti dalle conversazioni, salvati fuori e recuperati quando servono. A volte è RAG applicato all'utente invece che ai documenti; più spesso è un breve profilo sempre presente nel prompt, o un archivio che il modello consulta da sé con uno strumento quando gli serve.
Riempire la finestra non è gratis in qualità. Tutti i modelli peggiorano man mano che il contesto cresce («context rot», stadio 01), e peggio ancora se il contesto contiene passaggi simili ma sbagliati, come una circolare abrogata. La vecchia regola «il centro è la zona più trascurata» oggi pesa meno della lunghezza in sé. Mille token pertinenti battono centomila token generici.
Una memoria persistente è un archivio di dati personali: va mostrata, modificabile e cancellabile dall'utente. Nel caso HR, con dati di salute o disciplinari, questa non è una raffinatezza ma un requisito.
Cosa si paga, e quando si aspetta
Tre voci: i token in ingresso, quelli in ingresso già visti, quelli in uscita. Prezzi molto diversi fra loro, ed è da questo che discende quasi ogni scelta architetturale della pagina.
Leggere costa poco, rileggere ciò che si ricorda costa quasi niente, scrivere costa caro — e scrivere è anche l'unica delle tre che si fa una parola per volta, quindi è lì che sta l'attesa.
Il tempo alla prima parola dipende dalla lunghezza del prompt — e la cache lo abbatte. Il resto dipende da quante parole scrive. Per la percezione dell'utente conta soprattutto il primo, motivo per cui si trasmette in streaming.
Prima riordina il prompt per la cache, poi manda in batch tutto ciò che nessuno aspetta, poi riduci il materiale recuperato, e solo alla fine valuta un modello più piccolo. Le prime tre non costano qualità.
Come si sceglie, in pratica
| Se hai… | Usa | Aggiungi | Non serve |
|---|---|---|---|
| Pochi documenti, stabili | Tutto nel prompt | Prompt caching | Indice vettoriale |
| Un corpus che sta comodo in finestra | CAG | RAG per la coda lunga | Chunking |
| Migliaia di documenti che cambiano | RAG ibrido | Reranker, filtri per data e permessi | Fine-tuning per i fatti |
| Domande a più passi, fonti eterogenee | Ricerca agentica | RAG ibrido e query sul database come strumenti | Una pipeline fissa per ogni caso |
| Scansioni, moduli, tabelle | Pixel RAG su quelli | Indice testuale per il resto | OCR come unica strada |
| Un prefisso lungo e ripetuto | Prompt caching | Statico in cima, sempre | Accorciare le istruzioni |
| Un lavoro che nessuno aspetta | Batch asincrono | — | Chiamate sincrone in ciclo |
| Conversazioni lunghe | Compattazione a soglia | Fatti persistenti, visibili all'utente | Rimandare tutto per sempre |
| Uno stile o un formato da imporre | Esempi nel prompt | Fine-tuning se non basta | Istruzioni sempre più lunghe |
Tutto è un problema di cosa entra nella finestra.
RAG, CAG, pixel RAG, ricerca agentica, cache, batch e memoria non sono sette tecnologie diverse: sono sette risposte alla stessa domanda — quali token servono davvero adesso, e come evitare di pagarli due volte.