Quante informazioni può davvero utilizzare un LLM mentre ti risponde
IN BREVE
La context window delimita la quantità di informazioni che un modello linguistico può utilizzare durante una determinata elaborazione.
Non coincide con ciò che il modello ha appreso nel training, con la memoria del sistema o con un archivio RAG: sono livelli differenti, anche quando interagiscono.
Una finestra di contesto più ampia consente di rendere disponibili più informazioni, ma non assicura che siano selezionate, comprese o utilizzate correttamente.
Quando conversiamo con un sistema di intelligenza artificiale per molto tempo, può nascere un’impressione intuitiva: sembra che il modello abbia davanti a sé tutto quello che gli abbiamo detto, tutti i documenti che abbiamo caricato e magari anche tutto ciò che ha imparato durante il suo addestramento.
In realtà sono cose diverse.
Per capire come lavora un LLM dobbiamo introdurre un nuovo concetto: la context window, che possiamo tradurre, senza perdere troppo del significato tecnico, come finestra di contesto.
La finestra di contesto delimita la quantità di informazioni che il modello può utilizzare come contesto durante una determinata elaborazione. Una pubblicazione del Joint Research Centre della Commissione europea la descrive proprio come la quantità di testo che il modello può considerare quando genera una risposta. Pubblicazioni JRC
- Informazioni disponibiliIstruzioni, domanda, conversazione e documenti possono contribuire al contesto.
- SelezioneSolo il materiale effettivamente inserito entra nell’elaborazione corrente.
- Finestra di contestoLa capacità è limitata e non coincide con tutta la conoscenza del modello.
- RisultatoLa presenza di un’informazione non garantisce il suo uso corretto.
Contesto, parametri, memoria e archivio RAG sono concetti distinti.
Questo ci permette subito di correggere un equivoco:
CONTEXT WINDOW ≠ TUTTA LA CONOSCENZA DEL MODELLO
La finestra di contesto riguarda ciò che il modello può utilizzare in quella elaborazione. Non coincide con tutto ciò che è stato appreso durante il training.
Immaginiamo la scrivania di un avvocato
Pensiamo a un avvocato che deve predisporre un parere.
Nello studio possiede una biblioteca enorme. Ha codici, manuali, banche dati, fascicoli e documenti accumulati nel tempo. Ma, mentre sta lavorando, sulla sua scrivania può tenere contemporaneamente soltanto una certa quantità di materiale.
Può avere davanti il quesito del cliente, il contratto, alcune sentenze, gli appunti e la bozza che sta scrivendo.
La biblioteca e la scrivania non sono la stessa cosa.
Questa metafora ci aiuta:
TRAINING → ciò che ha contribuito a formare il modello
CONTEXT WINDOW → ciò che il modello può avere “sulla scrivania” durante l’elaborazione
Naturalmente la metafora ha dei limiti: un LLM non legge e non comprende come un avvocato. Ma è utile per distinguere due concetti che altrimenti rischiano di essere confusi.
Torniamo ai token
Abbiamo già visto che un LLM non riceve necessariamente il linguaggio come una sequenza di parole intere. Il testo viene trasformato in token.
Per questo anche la capacità della finestra di contesto viene normalmente espressa in token.
Possiamo quindi collegare due nodi del nostro percorso:
TESTO → TOKENIZZAZIONE → TOKEN → CONTEXT WINDOW → ELABORAZIONE
Questo significa anche che non esiste una conversione universale del tipo:
1 TOKEN = 1 PAROLA
Una parola può corrispondere a uno o più token e la relazione varia in funzione del testo e della tokenizzazione utilizzata.
Per questo evitiamo volutamente di dire che una determinata finestra di contesto equivale sempre a un certo numero di pagine. Sarebbe una semplificazione potenzialmente ingannevole.
Che cosa entra nella context window?
Questo è il passaggio più importante.
In una normale interazione con un LLM, il contesto disponibile al modello può comprendere più elementi: le istruzioni che governano il sistema, la richiesta dell'utente, parti della conversazione precedente, documenti o contenuti forniti al sistema e, nelle architetture che abbiamo appena studiato, informazioni recuperate mediante RAG.
La configurazione concreta dipende naturalmente dal sistema utilizzato.
Concettualmente possiamo però rappresentarla così:
ISTRUZIONI + DOMANDA + CONVERSAZIONE + CONTENUTI DISPONIBILI → CONTESTO → LLM → RISPOSTA
Ed è qui che la context window diventa fondamentale per comprendere il RAG.
Che cosa c’entra il RAG?
Nel precedente articolo abbiamo visto che un sistema RAG può cercare informazioni in una raccolta esterna e mettere a disposizione dell'LLM i contenuti ritenuti pertinenti prima della generazione.
Una pubblicazione del JRC descrive sistemi RAG nei quali le informazioni provenienti da documenti o basi di conoscenza dell'organizzazione vengono rese disponibili all'LLM per orientarne le risposte; nello stesso quadro, il documento distingue sistemi conversazionali che ricevono informazioni nella context window da configurazioni RAG che recuperano conoscenza esterna. Pubblicazioni JRC
Possiamo ora comprendere meglio il processo:
DOMANDA → RECUPERO DELLE INFORMAZIONI → CONTENUTI SELEZIONATI → CONTESTO DELL'LLM → GENERAZIONE
Il RAG, quindi, non deve necessariamente trasformare tutta una gigantesca banca documentale nel contesto dell'LLM.
Può invece servire a individuare quali informazioni recuperare affinché siano utilizzabili nella fase di generazione.
Per il nostro avvocato immaginario:
ARCHIVIO DELLO STUDIO ≠ TUTTO SULLA SCRIVANIA
Il sistema cerca nell'archivio e porta sulla “scrivania” ciò che ritiene pertinente.
Context window e RAG non sono la stessa cosa
Questa distinzione merita di essere fissata:
CONTEXT WINDOW ≠ RAG
La context window riguarda il contesto utilizzabile dall'LLM durante l'elaborazione.
Il RAG è invece un'architettura che permette di recuperare informazioni esterne pertinenti da rendere disponibili al processo generativo.
Possiamo avere un LLM con una context window senza avere un sistema RAG.
E possiamo utilizzare il RAG proprio perché non vogliamo trattare un archivio enorme come se tutto il suo contenuto dovesse essere inserito indiscriminatamente nel contesto.
Una finestra più grande risolve tutti i problemi?
No.
È intuitivo pensare:
PIÙ CONTESTO = RISPOSTA SEMPRE MIGLIORE
ma questa equivalenza non è corretta.
Una finestra più ampia permette, in linea di principio, di rendere disponibile una maggiore quantità di informazioni. Questo può essere molto utile per conversazioni lunghe, documenti estesi e attività che richiedono di mettere in relazione contenuti distanti. Anche il JRC ha osservato come finestre più ampie consentano al modello di considerare più informazioni nella generazione. Pubblicazioni JRC
Ma capacità disponibile e qualità dell'utilizzo di quella capacità sono problemi differenti.
Se inseriamo materiale irrilevante, duplicato, ambiguo o contraddittorio, il semplice fatto che il modello possa riceverne di più non garantisce una risposta migliore.
La distinzione corretta è:
PIÙ SPAZIO DISPONIBILE ≠ MIGLIORE INFORMAZIONE
e soprattutto:
INFORMAZIONE PRESENTE NEL CONTESTO ≠ INFORMAZIONE NECESSARIAMENTE UTILIZZATA CORRETTAMENTE
È lo stesso principio che abbiamo incontrato parlando di RAG.
Un esempio nello studio legale
Immaginiamo di avere un fascicolo composto da centinaia di documenti.
Una strategia potrebbe essere tentare di fornire al sistema una quantità enorme di materiale e chiedere:
«Analizza tutto e dimmi chi ha ragione».
Ma la disponibilità tecnica di una finestra sufficientemente ampia non rende automaticamente buona la metodologia.
Potrebbe essere preferibile strutturare il lavoro: identificare la questione, distinguere i documenti, recuperare quelli pertinenti, verificare date e provenienza, formulare domande precise e controllare successivamente le conclusioni prodotte.
Il problema non è soltanto:
QUANTO TESTO POSSO INSERIRE?
ma anche:
QUALE TESTO È RILEVANTE PER IL COMPITO?
Per un professionista questa seconda domanda è spesso molto più importante della prima.
E quando una conversazione diventa molto lunga?
Qui dobbiamo evitare un'altra semplificazione.
Non è corretto immaginare necessariamente che ogni sistema conservi e riproponga all'LLM, parola per parola e per sempre, tutto ciò che è accaduto dall'inizio della conversazione.
Il comportamento dipende dall'architettura del servizio. Quando il materiale supera ciò che il sistema può o decide di rendere disponibile nel contesto, possono essere utilizzate differenti strategie tecniche: selezione, compressione, riassunto, recupero di informazioni precedenti o esclusione di parti del materiale.
Perciò:
CRONOLOGIA DELLA CHAT ≠ NECESSARIAMENTE CONTESTO EFFETTIVAMENTE UTILIZZATO DAL MODELLO
Questo è particolarmente importante nel lavoro professionale.
Il fatto di avere comunicato un'informazione molte pagine prima non autorizza sempre a presumere che quella informazione sia necessariamente disponibile e correttamente valorizzata in ogni successiva generazione.
Context window non significa memoria
Un'altra distinzione fondamentale:
CONTEXT WINDOW ≠ MEMORIA
La finestra di contesto riguarda le informazioni rese disponibili per una determinata elaborazione.
La parola “memoria”, invece, può essere utilizzata nei sistemi di IA per descrivere meccanismi differenti con cui determinate informazioni vengono conservate, recuperate o riutilizzate tra interazioni.
Sono quindi concetti che possono interagire, ma non devono essere sovrapposti.
Per ora è sufficiente ricordare:
CONTESTO → ciò che è disponibile all'elaborazione
MEMORIA → meccanismi attraverso i quali determinate informazioni possono essere conservate e successivamente recuperate
La memoria costituisce un tema distinto, da non sovrapporre alla context window.
E i parametri del modello?
Qui possiamo finalmente collegare tre concetti già incontrati.
Quando abbiamo studiato i parametri e i pesi, abbiamo visto che il training modifica i parametri del modello. Quando oggi forniamo un contratto all'LLM durante una conversazione, normalmente non stiamo per questo riscrivendo quei parametri.
Stiamo fornendo informazione nel contesto dell'elaborazione.
Se invece un sistema RAG recupera una sentenza da una raccolta documentale, quella sentenza può essere resa disponibile al modello come ulteriore contesto.
Abbiamo quindi tre livelli differenti:
PARAMETRI DEL MODELLO
ciò che deriva dal processo di addestramento del modello
CONTESTO
ciò che viene reso disponibile durante l'elaborazione
CONTENUTI RECUPERATI DAL RAG
informazioni esterne selezionate che possono essere inserite nel contesto
Questa è probabilmente la distinzione più importante dell'intero articolo:
PARAMETRI ≠ CONTEXT WINDOW ≠ ARCHIVIO RAG
Una precisazione importante per l’avvocato
Una grande context window non modifica le regole professionali.
Se un sistema permette tecnicamente di elaborare un fascicolo molto grande, questo non significa automaticamente che sia opportuno caricarlo integralmente.
Prima vengono le domande giuridiche e organizzative: quali dati contiene? Quale servizio stiamo utilizzando? Chi tratta quelle informazioni? Quali condizioni si applicano? Il caricamento è compatibile con riservatezza, segreto professionale, protezione dei dati e policy dello studio?
La capacità tecnica risponde alla domanda:
“QUANTO PUÒ ELABORARE IL SISTEMA?”
La governance deve invece rispondere anche a:
“CHE COSA POSSO E DEVO AFFIDARGLI?”
Sono problemi diversi.
Perché questo concetto ci servirà quando parleremo di prompting
A questo punto possiamo comprendere che un prompt non vive nel vuoto.
Le istruzioni che forniamo interagiscono con il contesto disponibile al modello. La qualità della richiesta, la presenza dei documenti necessari, le informazioni recuperate e la struttura del contesto possono incidere sul risultato.
Per questo il prossimo passaggio non sarà imparare qualche presunta “formula magica” per parlare con l'IA.
Dovremo capire che cos'è realmente un prompt, quali informazioni fornisce al modello e perché formulare bene una richiesta è un problema di organizzazione del compito prima ancora che di stile linguistico.
Da ricordare
CONTEXT WINDOW = SPAZIO DI CONTESTO DISPONIBILE ALL'ELABORAZIONE
ma:
CONTEXT WINDOW ≠ CONOSCENZA COMPLESSIVA DEL MODELLO
CONTEXT WINDOW ≠ MEMORIA
CONTEXT WINDOW ≠ RAG
PARAMETRI ≠ CONTESTO
ARCHIVIO RAG ≠ CONTENUTI EFFETTIVAMENTE RECUPERATI
PIÙ CONTESTO ≠ RISPOSTA AUTOMATICAMENTE MIGLIORE
Per l'avvocato la sequenza corretta rimane:
INFORMAZIONI → SELEZIONE DEL CONTESTO → ELABORAZIONE DELL'IA → VERIFICA → VALUTAZIONE PROFESSIONALE → DECISIONE UMANA