Potenziamento del contesto LLM: Una guida per gli sviluppatori per migliorare i risultati delle RAG e dell'IA agenziale

Ultimamente le finestre di contesto negli LLM sono diventate enormi. Alcuni modelli possono accettare un milione di token o più in un singolo passaggio, e ogni nuova versione sembra aumentare questo numero. È entusiasmante, ma se avete costruito qualcosa che utilizza un contesto lungo, sapete che c'è un divario tra ciò che è possibile e ciò che è utile.

Solo perché un modello è in grado di leggere un intero libro con un solo prompt, non significa che si debba darglielo. La maggior parte degli input lunghi sono pieni di cose di cui il modello non ha bisogno. Quando si iniziano a inserire centinaia di migliaia di token in un prompt, di solito si ottengono risposte più lente, costi di calcolo più elevati e talvolta risposte di qualità inferiore, perché il modello cerca di prestare attenzione a tutto contemporaneamente.

Quindi, anche se le finestre di contesto continuano a diventare più grandi, la vera domanda diventa: che cosa dobbiamo inserire? È qui che entra in gioco il Context Pruning. Si tratta fondamentalmente di tagliare le parti del contesto recuperato o assemblato che non aiutano il modello a rispondere alla domanda. Se fatto bene, mantiene il sistema veloce, stabile e molto più prevedibile.

In questo articolo parleremo del motivo per cui i contesti lunghi spesso si comportano in modo diverso da quanto ci si aspetterebbe, di come il pruning aiuti a tenere le cose sotto controllo e di come gli strumenti di pruning come Provence si inseriscano nelle pipeline RAG reali senza complicare la configurazione.

Quattro modalità di fallimento comuni nei sistemi a contesto lungo

Una finestra di contesto più grande non rende magicamente il modello più intelligente. Anzi, una volta che si inizia a inserire una tonnellata di informazioni nel prompt, si apre una serie di nuovi modi in cui le cose possono andare storte. Ecco quattro problemi che si presentano di continuo quando si costruiscono sistemi a contesto lungo o RAG.

1. Scontro tra contesti

Lo scontro di contesto si verifica quando le informazioni accumulate in più turni diventano internamente contraddittorie.

Ad esempio, un utente potrebbe dire "mi piacciono le mele" all'inizio di una conversazione e successivamente affermare "non mi piace la frutta". Quando entrambe le affermazioni rimangono nel contesto, il modello non ha un modo affidabile per risolvere il conflitto, il che porta a risposte incoerenti o esitanti.

2. Confusione del contesto

La confusione del contesto si verifica quando il contesto contiene una grande quantità di informazioni irrilevanti o debolmente correlate, rendendo difficile per il modello selezionare l'azione o lo strumento corretto.

Questo problema è particolarmente visibile nei sistemi con strumenti. Quando il contesto è ingombro di dettagli non correlati, il modello può interpretare male l'intento dell'utente e selezionare lo strumento o l'azione sbagliata, non perché manchi l'opzione corretta, ma perché il segnale è sepolto dal rumore.

3. Distrazione del contesto

La distrazione da contesto si verifica quando un'eccessiva quantità di informazioni contestuali domina l'attenzione del modello, riducendo il suo affidamento sulla conoscenza preformata e sul ragionamento generale.

Invece di affidarsi a schemi ampiamente appresi, il modello dà troppo peso ai dettagli recenti del contesto, anche quando sono incompleti o inaffidabili. Questo può portare a un ragionamento superficiale o fragile, che rispecchia troppo da vicino il contesto invece di applicare una comprensione di livello superiore.

4. Avvelenamento del contesto

L'avvelenamento del contesto si verifica quando le informazioni errate entrano nel contesto e vengono ripetutamente citate e rafforzate nel corso di più turni.

Una singola affermazione falsa introdotta all'inizio della conversazione può diventare la base del ragionamento successivo. Man mano che il dialogo prosegue, il modello si basa su questo presupposto errato, aggravando l'errore e allontanandosi ulteriormente dalla risposta corretta.

Cos'è il Context Pruning e perché è importante

Quando si inizia ad avere a che fare con contesti lunghi, ci si rende subito conto che è necessario più di un trucco per tenere la situazione sotto controllo. Nei sistemi reali, i team di solito combinano un insieme di tattiche: RAG, loadout degli strumenti, riepilogo, messa in quarantena di determinati messaggi, scarico della vecchia cronologia e così via. Tutte aiutano in modi diversi. Ma il Context Pruning è quello che decide direttamente cosa viene effettivamente fornito al modello.

Il Context Pruning, in parole povere, è il processo di rimozione automatica delle informazioni irrilevanti, di basso valore o in conflitto prima che entrino nella finestra del contesto del modello. In pratica, si tratta di un filtro che mantiene solo le parti di testo più importanti per il compito corrente.

Altre strategie possono riorganizzare il contesto, comprimerlo o mettere da parte alcune parti per un secondo momento. Il pruning è più diretto: risponde alla domanda "Questa informazione deve essere inserita nel prompt?".

Ecco perché il pruning diventa particolarmente importante nei sistemi RAG. La ricerca vettoriale è ottima, ma non è perfetta. Spesso restituisce una grande quantità di candidati, alcuni utili, altri vagamente correlati, altri ancora completamente fuori strada. Se si scaricano tutti nel prompt, si verificano le modalità di fallimento descritte in precedenza. Il pruning si colloca tra il recupero e il modello, agendo come un guardiano che decide quali pezzi conservare.

Quando il pruning funziona bene, i vantaggi si vedono subito: un contesto più pulito, risposte più coerenti, un minore utilizzo di token e meno effetti collaterali dovuti all'inserimento di testo irrilevante. Anche se non si cambia nulla dell'impostazione del reperimento, l'aggiunta di una solida fase di pruning può migliorare sensibilmente le prestazioni complessive del sistema.

In pratica, il pruning è una delle ottimizzazioni più utili in una pipeline long-context o RAG: idea semplice, grande impatto.

Provenza: Un modello pratico di potatura del contesto

Mentre esploravo gli approcci al context pruning, mi sono imbattuto in due interessanti modelli open-source sviluppati da Naver Labs Europe: Provence e la sua variante multilingue, XProvence.

Provence è un metodo per l'addestramento di un modello leggero di context pruning per la generazione aumentata dal reperimento, con particolare attenzione alla risposta alle domande. Data una domanda dell'utente e un brano recuperato, il modello identifica e rimuove le frasi irrilevanti, mantenendo solo le informazioni che contribuiscono alla risposta finale.

Tagliando i contenuti di scarso valore prima della generazione, Provence riduce il rumore nell'input del modello, accorcia le richieste e riduce la latenza dell'inferenza LLM. Inoltre, è plug-and-play e funziona con qualsiasi sistema LLM o di retrieval senza richiedere una stretta integrazione o modifiche architettoniche.

Provence offre diverse caratteristiche pratiche per le pipeline RAG del mondo reale.

1. Comprensione a livello di documento

Provence analizza i documenti nel loro complesso, anziché valutare le frasi in modo isolato. Questo è importante perché i documenti del mondo reale contengono spesso riferimenti come "it", "this" o "the method above". Da sole, queste frasi possono essere ambigue o addirittura prive di significato. Se considerate nel contesto, la loro rilevanza diventa chiara. Modellando il documento in modo olistico, Provence produce decisioni di potatura più accurate e coerenti.

2. Selezione adattiva delle frasi

Provence determina automaticamente il numero di frasi da conservare in un documento recuperato. Invece di affidarsi a regole fisse come "mantenere le prime cinque frasi", si adatta alla domanda e al contenuto.

Ad alcune domande si può rispondere con una sola frase, mentre altre richiedono più affermazioni di supporto. Provence gestisce questa variazione in modo dinamico, utilizzando una soglia di rilevanza che funziona bene in tutti i domini e che può essere regolata quando necessario, senza alcuna regolazione manuale nella maggior parte dei casi.

3. Alta efficienza con il reranking integrato

Provence è stato progettato per essere efficiente. Si tratta di un modello compatto e leggero, che lo rende significativamente più veloce ed economico da eseguire rispetto agli approcci di pruning basati su LLM.

Inoltre, Provence è in grado di combinare il reranking e il context pruning in un unico passaggio. Poiché il reranking è già una fase standard delle moderne pipeline RAG, l'integrazione del pruning a questo punto rende il costo aggiuntivo del context pruning prossimo allo zero, migliorando comunque la qualità del contesto passato al modello linguistico.

4. Supporto multilingue tramite XProvence

Provence ha anche una variante chiamata XProvence, che utilizza la stessa architettura ma è addestrata su dati multilingue. Ciò gli consente di valutare query e documenti in diverse lingue, come il cinese, l'inglese e il coreano, rendendolo adatto ai sistemi RAG multilingue e interlinguistici.

Come viene addestrato Provence

Provence utilizza un design di addestramento pulito ed efficace, basato su un'architettura cross-encoder. Durante l'addestramento, l'interrogazione e ogni brano recuperato vengono concatenati in un unico input e codificati insieme. Ciò consente al modello di osservare l'intero contesto della domanda e del brano in una sola volta e di ragionare direttamente sulla loro rilevanza.

Questa codifica congiunta consente a Provence di apprendere da segnali di rilevanza a grana fine. Il modello è stato messo a punto su DeBERTa come codificatore leggero e ottimizzato per svolgere due compiti contemporaneamente:

1. Punteggio di rilevanza a livello di documento (rerank score): Il modello predice un punteggio di rilevanza per l'intero documento, che indica la corrispondenza con la query. Ad esempio, un punteggio di 0,8 rappresenta una forte rilevanza.

2. Etichettatura della rilevanza a livello di token (maschera binaria): In parallelo, il modello assegna un'etichetta binaria a ciascun token, indicando se è rilevante (1) o irrilevante (0) per la query.

Di conseguenza, il modello addestrato è in grado di valutare la rilevanza complessiva di un documento e di identificare quali parti dovrebbero essere mantenute o rimosse.

Al momento dell'inferenza, Provence predice le etichette di rilevanza a livello di token. Queste previsioni vengono poi aggregate a livello di frase: una frase viene mantenuta se contiene più token rilevanti di quelli irrilevanti, altrimenti viene eliminata. Poiché il modello è addestrato con una supervisione a livello di frase, le previsioni dei token all'interno della stessa frase tendono a essere coerenti, rendendo questa strategia di aggregazione affidabile nella pratica. Il comportamento di potatura può anche essere regolato regolando la soglia di aggregazione per ottenere una potatura più conservativa o più aggressiva.

È importante notare che Provence riutilizza la fase di reranking che la maggior parte delle pipeline RAG già include. Ciò significa che la potatura del contesto può essere aggiunta con un overhead minimo o nullo, rendendo Provence particolarmente pratico per i sistemi RAG del mondo reale.

Valutazione delle prestazioni del context pruning tra i vari modelli

Finora ci siamo concentrati sulla progettazione e sull'addestramento di Provence. Il passo successivo è quello di valutare le sue prestazioni nella pratica: quanto bene pota il contesto, come si confronta con altri approcci e come si comporta in condizioni reali.

Per rispondere a queste domande, abbiamo progettato una serie di esperimenti quantitativi per confrontare la qualità della potatura del contesto tra più modelli in contesti di valutazione realistici.

Gli esperimenti si concentrano su due obiettivi principali:

• Efficacia della potatura: Misuriamo l'accuratezza con cui ogni modello conserva i contenuti rilevanti rimuovendo le informazioni irrilevanti, utilizzando metriche standard come precisione, richiamo e punteggio F1.

• Generalizzazione fuori dal dominio: Valutiamo il rendimento di ciascun modello su distribuzioni di dati diverse da quelle di addestramento, valutando la robustezza in scenari fuori dal dominio.

Modelli a confronto

• Provenza

• XProvence

• OpenSearch Semantic Highlighter (un modello di pruning basato su un'architettura BERT, progettato specificamente per compiti di evidenziazione semantica)

Set di dati

Come dataset di valutazione utilizziamo WikiText-2. WikiText-2 deriva da articoli di Wikipedia e contiene diverse strutture di documenti, in cui le informazioni rilevanti sono spesso distribuite su più frasi e le relazioni semantiche possono essere non banali.

È importante notare che WikiText-2 differisce in modo sostanziale dai dati tipicamente utilizzati per addestrare i modelli di potatura del contesto, pur assomigliando a contenuti del mondo reale e ricchi di conoscenza. Questo lo rende adatto alla valutazione fuori dal dominio, che è uno degli obiettivi principali dei nostri esperimenti.

Generazione di query e annotazione

Per costruire un compito di pruning fuori dal dominio, abbiamo generato automaticamente coppie domanda-risposta dal corpus grezzo di WikiText-2 utilizzando GPT-4o-mini. Ogni campione di valutazione è costituito da tre componenti:

• Domanda: Una domanda in linguaggio naturale generata dal documento.

• Contesto: Il documento completo, non modificato.

• Ground Truth: annotazioni a livello di frase che indicano quali frasi contengono la risposta (da mantenere) e quali sono irrilevanti (da eliminare).

Questa impostazione definisce naturalmente un compito di potatura del contesto: data una query e un documento completo, il modello deve identificare le frasi che hanno effettivamente importanza. Le frasi che contengono la risposta sono etichettate come rilevanti e devono essere mantenute, mentre tutte le altre frasi sono trattate come irrilevanti e devono essere eliminate. Questa formulazione consente di misurare quantitativamente la qualità del pruning con precisione, richiamo e punteggio F1.

È fondamentale che le domande generate non compaiano nei dati di addestramento di nessun modello valutato. Di conseguenza, le prestazioni riflettono la vera generalizzazione piuttosto che la memorizzazione. In totale, abbiamo generato 300 campioni, che spaziano da semplici domande basate sui fatti, a compiti di ragionamento multi-hop e a richieste analitiche più complesse, per riflettere meglio i modelli di utilizzo del mondo reale.

Linea di valutazione

Ottimizzazione degli iperparametri: Per ogni modello, eseguiamo una ricerca a griglia su uno spazio di iperparametri predefinito e selezioniamo la configurazione che massimizza il punteggio F1.

Risultati e analisi

I risultati rivelano chiare differenze di prestazioni tra i tre modelli.

Provence ottiene le migliori prestazioni complessive, con un punteggio F1 del 66,76%. La precisione(69,53%) e il richiamo(64,19%) sono ben bilanciati, il che indica una robusta generalizzazione al di fuori del dominio. La configurazione ottimale utilizza una soglia di potatura di 0,6 e α = 0,051, suggerendo che i punteggi di rilevanza del modello sono ben calibrati e che il comportamento di potatura è intuitivo e facile da regolare nella pratica.

XProvence raggiunge un punteggio F1 del 58,97%, caratterizzato da un elevato richiamo (75,52%) e una minore precisione (48,37%). Ciò riflette una strategia di potatura più conservativa, che privilegia la conservazione delle informazioni potenzialmente rilevanti rispetto alla rimozione aggressiva del rumore. Questo comportamento può essere auspicabile in ambiti in cui i falsi negativi sono costosi, come le applicazioni sanitarie o legali, ma aumenta anche i falsi positivi, riducendo la precisione. Nonostante questo compromesso, la capacità multilingue di XProvence lo rende un'opzione valida per i contesti non inglesi o multilingue.

Al contrario, OpenSearch Semantic Highlighter ottiene risultati sostanzialmente peggiori, con un punteggio F1 del 46,37% (Precision 62,35%, Recall 36,98%). Il divario rispetto a Provence e XProvence indica limiti nella calibrazione del punteggio e nella generalizzazione fuori dal dominio, soprattutto in condizioni fuori dal dominio.

Evidenziazione semantica: Un altro modo per trovare ciò che conta davvero nel testo

Dopo aver parlato di potatura del contesto, vale la pena di esaminare un pezzo del puzzle correlato: l'evidenziazione semantica. Tecnicamente, entrambe le funzioni svolgono quasi lo stesso lavoro: assegnano un punteggio alle parti di testo in base alla loro rilevanza per una query. La differenza sta nel modo in cui il risultato viene utilizzato nella pipeline.

La maggior parte delle persone sente parlare di "evidenziazione" e pensa ai classici evidenziatori di parole chiave che si vedono in Elasticsearch o Solr. Questi strumenti cercano fondamentalmente le corrispondenze letterali delle parole chiave e le avvolgono in qualcosa come <em>. Sono economici e prevedibili, ma funzionano solo quando il testo utilizza esattamente le stesse parole della query. Se il documento parafrasa, usa sinonimi o formula l'idea in modo diverso, gli evidenziatori tradizionali non la colgono completamente.

L'evidenziazione semantica segue una strada diversa. Invece di verificare le corrispondenze esatte tra le stringhe, utilizza un modello per stimare la somiglianza semantica tra la query e le diverse parti del testo. Questo permette di evidenziare i contenuti rilevanti anche quando la formulazione è completamente diversa. Per le pipeline RAG, i flussi di lavoro ad agenti o qualsiasi sistema di ricerca AI in cui il significato conta più dei token, l'evidenziazione semantica offre un quadro molto più chiaro del motivo per cui un documento è stato recuperato.

Il problema è che la maggior parte delle soluzioni di evidenziazione semantica esistenti non sono costruite per carichi di lavoro AI di produzione. Abbiamo testato tutte le soluzioni disponibili e nessuna ci ha fornito il livello di precisione, latenza e affidabilità multilingue di cui avevamo bisogno per i sistemi RAG e ad agenti reali. Così abbiamo finito per addestrare e rendere open-sourcing il nostro modello: zilliz/semantic-highlight-bilingual-v1.

Ad alto livello, il context pruning e l'evidenziazione semantica risolvono lo stesso compito fondamentale: data una query e un pezzo di testo, capire quali parti sono effettivamente importanti. L'unica differenza è ciò che accade dopo.

• Il context pruning elimina le parti irrilevanti prima della generazione.

• L'evidenziazione semantica mantiene il testo completo, ma fa emergere visivamente le parti importanti.

Poiché l'operazione sottostante è così simile, spesso lo stesso modello può alimentare entrambe le funzioni. In questo modo è più facile riutilizzare i componenti in tutto lo stack e il sistema RAG rimane complessivamente più semplice ed efficiente.

Evidenziazione semantica in Milvus e Zilliz Cloud

L'evidenziazione semantica è ora pienamente supportata in Milvus e Zilliz Cloud (il servizio completamente gestito di Milvus) e si sta già rivelando utile per chiunque lavori con RAG o con la ricerca guidata dall'intelligenza artificiale. La funzione risolve un problema molto semplice ma doloroso: quando la ricerca vettoriale restituisce una tonnellata di pezzi, come si fa a capire rapidamente quali frasi all'interno di quei pezzi sono effettivamente importanti?

Senza l'evidenziazione, gli utenti finiscono per leggere interi documenti solo per capire perché qualcosa è stato recuperato. Con l'evidenziazione semantica incorporata, Milvus e Zilliz Cloud contrassegnano automaticamente gli intervalli specifici che sono semanticamente correlati alla query, anche se la formulazione è diversa. Non è più necessario andare a caccia di corrispondenze di parole chiave o indovinare il motivo per cui un pezzo è stato trovato.

Questo rende il recupero molto più trasparente. Invece di restituire solo "documenti rilevanti", Milvus mostra dove risiede la rilevanza. Per le pipeline RAG, questo è particolarmente utile, perché è possibile vedere immediatamente a cosa dovrebbe assistere il modello, rendendo molto più semplice il debugging e la costruzione di prompt.

Abbiamo integrato questo supporto direttamente in Milvus e Zilliz Cloud, in modo che non dobbiate aggiungere modelli esterni o eseguire un altro servizio solo per ottenere un'attribuzione utilizzabile. Tutto viene eseguito all'interno del percorso di recupero: ricerca vettoriale → punteggio di rilevanza → intervalli evidenziati. Funziona su scala immediata e supporta carichi di lavoro multilingue con il nostro modello zilliz/semantic-highlight-bilingual-v1.

Guardando al futuro

L'ingegneria del contesto è ancora piuttosto nuova e c'è ancora molto da capire. Anche se il pruning e l'evidenziazione semantica funzionano bene all'interno di Milvus e Zilliz Cloud, non siamo vicini alla fine della storia. Ci sono molte aree che necessitano ancora di un vero lavoro di ingegneria: rendere i modelli di potatura più accurati senza rallentare le cose, migliorare la gestione di query strane o fuori dal dominio e collegare tutti i pezzi insieme in modo che retrieval → rerank → prune → highlight sembrino un'unica pipeline pulita invece di un insieme di hack incollati insieme.

Con la crescita delle finestre di contesto, queste decisioni diventano sempre più importanti. Una buona gestione del contesto non è più un "bel bonus", ma sta diventando una parte fondamentale per rendere affidabili i sistemi a contesto lungo e RAG.

Continueremo a sperimentare, a fare benchmarking e a distribuire i pezzi che fanno davvero la differenza per gli sviluppatori. L'obiettivo è semplice: rendere più facile la creazione di sistemi che non si rompano in presenza di dati disordinati, query imprevedibili o carichi di lavoro su larga scala.

Se volete parlare di tutto questo, o semplicemente avete bisogno di aiuto per il debug, potete collegarvi al nostro canale Discord o prenotare una sessione individuale di 20 minuti per ottenere approfondimenti, indicazioni e risposte alle vostre domande attraverso Milvus Office Hours.

Siamo sempre felici di chiacchierare e scambiare appunti con altri costruttori.