Come gestire il contesto degli agenti? RAG, LLM Wiki e GraphRAG

Ricordo distintamente di quando ero piccolo, a 10 o 11 anni: vivevamo a Ponta Delgada e arrivavo a casa entusiasta per guardare i documentari di History Channel e di Discovery. Ogni giorno, senza eccezione, la mia testa memorizzava migliaia di dettagli: «Oh, in alcuni templi gli antichi greci avevano macchine che distribuivano acqua benedetta in cambio di monete!». Sono stati anni e anni passati a costruire un’abitudine che ho ancora oggi. In questi ultimi (quasi) 36 anni devo aver visto decine di migliaia di documentari e video di divulgazione scientifica, storia, filosofia e altri temi. E la (ovvia) verità è che il 99,9% di ciò che ho sentito, visto e letto non mi è rimasto da nessuna parte in testa.

Alcuni fatti sono rimasti, perché erano curiosi come quello delle macchine dei greci, o perché li avevo annotati e alla fine li ho riletti, o perché li ho interiorizzati al punto che fanno ormai parte della mia cultura generale, o perché sono legati ad altri ricordi importanti, o perché il ricordo è ancora fresco.

Possiamo ricavarne un’analogia interessante, anche se non un’equivalenza. Anche i foundation model (modelli di IA addestrati su grandi volumi di dati diversificati, che possono essere adattati a compiti diversi) non hanno tutto a disposizione in ogni istante. Ma conviene distinguere la conoscenza appresa durante l’addestramento dal contesto attivo, cioè le informazioni che ricevono per una determinata chiamata al modello.

Quando vengono addestrati, sono esposti a più dati di quanti un essere umano riuscirebbe a consumare in tutta la sua vita. Parte di quei contenuti finisce nell’amalgama della conoscenza di base del modello. Anzi, proprio come gli esseri umani, i modelli possono assimilare fake news e idee false.

Nell’uso quotidiano, i modelli combinano questa conoscenza di base con una serie di fonti di contesto. Se voglio che un agente di IA automatizzi il filtraggio e la prioritizzazione della mia casella email, userà la conoscenza di base che porta con sé, la conoscenza del processo (le istruzioni) che gli ho dato e i dati delle email stesse (la conoscenza del compito specifico). Ma qui inciampiamo in uno dei maggiori limiti di questa tecnologia: i modelli hanno una finestra di contesto limitata. Ci sono modelli di frontiera con finestre dell’ordine di 1 milione di token. Ogni token corrisponde, in media e come approssimazione per un testo in inglese, a circa quattro caratteri. Un milione di token, quindi, equivale più o meno a una volta e mezza il testo dei tre volumi de Il Signore degli Anelli, nell’originale inglese.

Definisco qui un agente come un programma che usa un foundation model (FM) per prendere decisioni e usare strumenti. Ogni volta che deve ricevere informazioni e prendere una decisione, chiama il modello. Le informazioni non incluse in quella chiamata non saranno disponibili come contesto, anche se sono comparse in una chiamata precedente. L’industria si è evoluta per aggirare questo limite. L’insieme di pratiche con cui si passa all’agente il contesto necessario, quando è necessario, qui lo chiamo tecniche di gestione del contesto. Una delle idee di base è la progressive disclosure of information, cioè il modo in cui si fornisce contesto nel tempo, accompagnato da strumenti con cui l’agente va a cercare le informazioni di cui ha bisogno.

Trattandosi di un’area relativamente recente, non esiste una soluzione one-size-fits-all. Nell’industria esistono diverse euristiche comuni, e una delle più usate è la Retrieval-Augmented Generation (RAG). Con questa tecnica, i documenti vengono di solito divisi in segmenti secondo criteri diversi: dimensione fissa, contesto semantico, gerarchia del documento, tra gli altri. Spesso questi segmenti vengono convertiti in rappresentazioni numeriche, che chiamiamo embedding.¹ Quando serve, l’agente fa una ricerca su queste informazioni, riceve i segmenti considerati rilevanti per il suo compito e li usa per generare la risposta. Tipicamente, può fare una ricerca lessicale (cerca termini specifici), semantica (cerca segmenti con un significato simile a quanto richiesto dal compito) o ibrida (entrambe). È eccellente quando bisogna trovare informazioni specifiche in documenti molto grandi, come nel classico esempio di estrarre le informazioni rilevanti da un contratto di 500 pagine. Tuttavia, anche se l’agente formula bene la ricerca, potrebbe non ricevere tutti i segmenti necessari per il compito e restare con un contesto incompleto. Ciononostante, sia nell’industria sia nel mondo accademico, di questa tecnica si parla ancora molto, ed è stata usata praticamente in tutti i casi di implementazione che ho visto.

Ma non è l’unico modo di farlo. Uno dei nomi più citati in questo mondo dell’IA generativa, Andrej Karpathy, ha proposto la LLM Wiki.² Questo approccio usa file Markdown (.md), che sono semplici file di testo con una formattazione specifica, per mantenere un indice e pagine collegate tra loro con la conoscenza sintetizzata dalle fonti. L’agente può consultare per intero le pagine rilevanti quando ne ha bisogno. È l’equivalente di quando consulto il manuale d’uso di un oggetto nuovo e leggo, scegliendo in base all’indice, solo i riferimenti che mi servono. È stato il mio approccio preferito per vari casi d’uso, per la coerenza e per la facilità di manutenzione o di modifica manuale. Nei casi d’uso complessi, però, può creare un onere di manutenzione maggiore rispetto, per esempio, a generare gli embedding di una nuova versione di un documento e aggiornare l’indice. Possiamo creare pipeline di distillazione dell’informazione (intendo ridurre la quantità di testo mantenendo la densità di informazione) per la manutenzione di una LLM Wiki. Del resto, è proprio quello che propone Karpathy. Secondo la mia esperienza, però, questa distillazione è ancora piuttosto fallibile da parte dei modelli, ai quali sfuggono spesso le sfumature dell’informazione originale e la visione d’insieme dell’obiettivo del documento. E lo sforzo di cura diventa rapidamente pesante.

Infine, dato che il testo è già lungo e non voglio scoraggiare chi l’ha letto fin qui, vorrei soffermarmi brevemente sull’approccio GraphRAG, o Graph Retrieval-Augmented Generation. Forse conviene partire da che cos’è un grafo: una struttura matematica o computazionale formata da un insieme di vertici (nodi) collegati da archi (o collegamenti)... pausa per respirare. In parole semplici, è un modo di rappresentare le informazioni e le relazioni tra i dati, come qui sotto. Un buon esempio è un social network, in cui ci possono essere i nomi di varie persone collegate tra loro, ma i collegamenti hanno una direzione: Joaquina segue Manuel, che segue Ramiro, che a sua volta segue Joaquina. Questo non significa che Manuel segua Joaquina, né che Joaquina segua Ramiro. Le persone sono i nodi; i collegamenti sono i follow. L’informazione può avere una direzione, e le relazioni sono esplicite.

Una freccia da A a B significa «A segue B». La relazione inversa non è implicita.

GraphRAG usa un grafo di conoscenza, con entità (concetti, oggetti, persone) e relazioni tra di esse, per creare una rete che si può interrogare. Per un agente diventa più semplice seguire un percorso di ricerca attraverso queste relazioni, alla ricerca delle informazioni che servono per completare un compito. Le informazioni trovate vengono poi passate al modello come contesto per produrre la risposta. Questa capacità può essere particolarmente utile quando bisogna incrociare informazioni di più documenti. Come negli altri approcci, serve una cura delle informazioni e delle relazioni, in particolare quando le produce l’agente in modo autonomo. Per esempio, se le relazioni sono sbagliate, incomplete o non aggiornate, l’agente può lasciare fuori informazioni importanti o basare la risposta su collegamenti che non hanno più senso. Mi è già capitato di applicare questo approccio e di ritrovarmi con una rete così complessa che né io né l’agente (shoutout al Sig. Alfredo) capivamo cosa ci fosse dentro.

Questi tre approcci non si escludono a vicenda, e un progetto di implementazione aziendale relativamente complesso e con un approccio maturo potrebbe, al limite, usarli tutti e tre, a seconda del caso. Una wiki può essere interrogata con la RAG, e lo stesso GraphRAG è un modo di supportare la generazione con informazioni recuperate. Ecco il riassunto del mio modello mentale su quando usare ciascuno:

Ma il tema della gestione del contesto non finisce qui. Questo è solo il primo articolo di una serie in cui affronterò questo argomento. In futuro parleremo di caching, compaction, context pruning e isolamento del contesto con subagenti. Ci vediamo presto.