Compressione del contesto

I chunk recuperati sono rumorosi: un chunk rilevante può essere costituito quasi interamente da testo standard, con una sola frase essenziale. La compressione del contesto riduce il testo recuperato alle sole parti che rispondono effettivamente alla query, prima che raggiunga il generatore.

I vantaggi si sommano: minori costi per i token, latenza ridotta, meno elementi fuorvianti e un effetto meno marcato della perdita nel mezzo, grazie alla riduzione del contesto che il modello deve attraversare.

La compressione estrattiva seleziona intervalli testuali letterali (frasi, passaggi) rilevanti per la query, preservando la formulazione esatta e la provenienza. La compressione astrattiva parafrasa o riassume, ottenendo una compressione maggiore, ma rischiando perdita di informazioni e introduzione di errori.

Per un RAG fattuale con citazioni, preferire l'estrattiva per mantenere le affermazioni riconducibili alla fonte; usare l'astrattiva solo quando è possibile verificarne la fedeltà.

Una tecnica leggera e robusta consiste nel valutare ogni frase di ciascun chunk rispetto alla query, usando un cross-encoder di piccole dimensioni o la similarità tra embedding, e nell'eliminare le frasi con punteggio basso. In questo modo si conservano le frasi ad alto valore e si scarta il testo superfluo.

Mantenere un contesto minimo per ogni chunk, per evitare di eliminare la frase circostante che dà significato al fatto riportato.

Un LLM può comprimere ogni chunk: richiedergli di estrarre solo le parti di un passaggio rilevanti per la query, restituendo il chunk con il testo originale ma ritagliato, oppure un indicatore vuoto se non contiene nulla di rilevante.

Questo è il pattern LangChain ContextualCompressionRetriever. È più accurato dei filtri basati sugli embedding, ma aggiunge una chiamata LLM per ogni chunk; pertanto, riservarlo alle pipeline ad alta criticità oppure elaborare i chunk in batch.

Metodi come LLMLingua comprimono a livello di token usando un modello di piccole dimensioni per stimare l'informatività dei token ed eliminare quelli con poche informazioni. Possono raggiungere elevati rapporti di compressione preservando al contempo il segnale di cui il modello più grande ha bisogno.

Il compromesso è una minore leggibilità per le persone del testo compresso; questa tecnica è quindi adatta al contesto usato esclusivamente dalle macchine, non alla visualizzazione per l'utente.

La compressione sensibile alla query conserva ciò che è rilevante per questa query e produce il contesto più circoscritto, ma deve essere eseguita a ogni richiesta. La compressione indipendente dalla query (con riassunti dei chunk precalcolati) è più economica al momento della richiesta, ma non può concentrarsi sulla domanda specifica.

Un approccio ibrido memorizza offline versioni condensate dei chunk e applica online un leggero ritaglio sensibile alla query.

Una compressione aggressiva può eliminare proprio la clausola essenziale. Proteggersi con una verifica del recall: verificare che il contesto compresso implichi ancora la risposta, oppure mantenere un fallback al chunk non compresso quando il compressore restituisce una quantità di testo sospettosamente ridotta.

Non lasciare mai che la compressione riduca a vuoto un chunk che il reranker ha valutato altamente rilevante: questo indica un errore del compressore, non un'irrilevanza.

La compressione deve mantenere intatta l'attribuzione della fonte. Contrassegnare ogni intervallo conservato con l'ID del chunk e del documento, così che il generatore possa citarlo. Se si elimina dai metadati ciò che viene compresso, si perdono la verificabilità e la possibilità di rilevare le allucinazioni.

Trasportare gli ID nella pipeline come campi strutturati, mai come testo libero che la compressione potrebbe eliminare.

La compressione consente di recuperare più candidati per aumentare il recall, mantenendo al contempo ridotte le dimensioni del prompt finale. Impostare un budget di token per la finestra di contesto e inserire avidamente gli intervalli compressi di maggior valore fino a raggiungere il limite.

In questo modo si disaccoppia la quantità recuperata dalla quantità spesa per la generazione: una leva fondamentale per l'efficienza.

Monitorare tre valori: il rapporto di compressione (token risparmiati), l'accuratezza della risposta (la qualità è rimasta invariata?) e la fedeltà (il compressore ha evitato di alterare i fatti?). L'obiettivo è ottenere il rapporto più elevato senza modificare l'accuratezza della risposta.

Valutare diversi livelli di aggressività della compressione e scegliere il punto Pareto che soddisfa l'obiettivo di costo senza perdita di qualità.

Dall'inizio alla fine: recuperare ampiamente, applicare il reranking, comprimere ogni chunk rimasto (con metodo estrattivo o basato su LLM) mantenendone la provenienza, proteggersi da un ritaglio eccessivo, inserire i contenuti entro un budget di token e generare la risposta con le citazioni.

La compressione è il livello che rende economicamente sostenibile il recupero ad alto recall e mantiene il generatore concentrato su ciò che conta.

Scegliere l'approccio di compressione corretto per un sistema RAG fattuale con citazioni.

Punti chiave:

• La compressione riduce i chunk recuperati al contenuto rilevante per la query, tagliando costi, latenza ed elementi fuorvianti.
• Per un RAG fattuale con citazioni, preferire la compressione estrattiva (testo invariato e tracciabile) a quella astrattiva; il pruning a livello di token è adatto al contesto usato esclusivamente dalle macchine.
• La compressione sensibile alla query è la più circoscritta, ma va eseguita a ogni richiesta; combinarla con riassunti offline per maggiore efficienza.
• Proteggersi dalla perdita di informazioni e preservare la provenienza di chunk e documenti per le citazioni.
• Usare la compressione per recuperare ampiamente mantenendo ridotte le dimensioni dei prompt; regolarla per massimizzare il rapporto senza perdere accuratezza nella risposta.