Compressione del contesto consapevole della query

Ogni risposta ha inizio con un elemento probatorio. In un sistema di ricerca, tale elemento solitamente deriva dai documenti: titoli, riassunti, segmenti e snippet trasmessi come contesto a un modello o agente di risposta.

Tale contesto grezzo è soggetto a interferenze. Ad esempio, una pagina web può contenere informazioni necessarie per la richiesta dell'utente, ma anche elementi di disturbo. Tali elementi possono essere presenti sia nel corpo principale che in elementi ancillari, come elementi testuali di navigazione, pubblicità irrilevanti, metadati e altro ancora. Trasmettere tali elementi di disturbo a un agente a valle genera tre problemi.

In primo luogo, compromette l'accuratezza. Anche i modelli più potenti hanno una capacità finita. Flussi prolungati di informazioni irrilevanti sprecano la capacità del modello, portando a un “deterioramento del contesto” che compromette la capacità del modello di soddisfare l'effettiva richiesta dell'utente. Di conseguenza, è più probabile che la risposta finale ometta fatti chiave, sovrastimi informazioni di scarsa qualità o produca affermazioni difficilmente supportabili dalla fonte.

In secondo luogo, causa un peggioramento della latenza. Un contesto più esteso implica un numero maggiore di token che il modello a valle deve elaborare, specialmente quando una query richiede elementi probatori da numerose pagine candidate. Sebbene una parte di questo costo di latenza venga sostenuta nella fase di pre-riempimento, un costo molto più significativo viene pagato nel ragionamento, poiché i modelli richiedono più token di ragionamento per gestire il contesto irrilevante.

In terzo luogo, comporta un aumento dei costi. Ogni token non necessario trasmesso al modello rende più costoso soddisfare la richiesta dell'utente, poiché sia l'utilizzo dei token di input che quello dei token di ragionamento aumentano con un contesto più disturbato. Gli elementi di disturbo non riducono solo la qualità; finiscono per costringere a pagare di più per una qualità inferiore.

Espandi

Per far avanzare simultaneamente accuratezza, velocità ed efficacia in termini di costi attraverso le applicazioni di Perplexity e la API Platform, investiamo significativamente nel miglioramento della precisione del contesto. Un metodo consiste nel perfezionamento dei nostri algoritmi di generazione degli snippet. Trattiamo la generazione degli snippet come un problema di compressione del contesto. I modelli che ricercano informazioni specifiche non traggono beneficio da riassunti o estratti generalizzati di un documento. Richiedono invece la porzione di informazioni di origine più piccola e estratta in modo più chirurgico per rispondere alla richiesta dell'utente. Tutto il resto può e deve essere rimosso.

Uno snippet efficace dovrebbe quindi assolvere a tre compiti:

Promuovere l'accuratezza presentando gli elementi probatori precisi necessari per supportare la risposta del modello.

Ridurre la latenza e i costi eliminando il contesto irrilevante prima della chiamata LLM.

Garantire la tracciabilità preservando l'integrità delle citazioni e mantenendo intatta la formulazione della fonte.

Questo mese, abbiamo implementato un nuovo generatore di snippet all'avanguardia all'interno delle nostre applicazioni e della API Platform. Il nucleo di questo modulo è un modello di compressione del contesto consapevole della query che decide, per ogni query e risultato candidato, il sottoinsieme di segmenti da preservare. Questo articolo descrive il nostro approccio alla creazione e all'addestramento del modello per ottenere prestazioni eccellenti in questa attività cruciale.

Snippet come compressione consapevole della query

Il primo passo fondamentale consiste nel definire l'attività stessa. Cosa vogliamo che il modello esegua e come dobbiamo definire lo schema di input e output?

I metodi per gli snippet si suddividono in due ampie categorie. La prima è basata sulla selezione: trovare una finestra, un segmento, una frase o un passaggio rilevante e trasmetterlo a valle. La seconda è basata sulla generazione: richiedere a un modello di redigere un riassunto focalizzato sulla query partendo dalla pagina.

Il nostro focus su accuratezza, latenza e costi rende la scelta progettuale chiara. Possiamo escludere la generazione, poiché creare un nuovo riassunto per ogni pagina compromette le prestazioni in tutti e tre gli ambiti. La riassunzione non è adatta al livello di prova di cui ci occupiamo. Può parafrasare la fonte, rendendo più complesso l'allineamento delle citazioni. Può inoltre introdurre una formulazione non presente nella pagina, il che comporta dei rischi quando lo snippet viene utilizzato come prova anziché come risposta finale. La latenza e i costi associati rendono la generazione ancora meno preferibile.

Definiamo piuttosto il nostro compito come una compressione estrattiva consapevole della query: separare le parti utili del contesto recuperato da quelle disturbanti. Nello specifico, il nostro modello deve accettare una query e un risultato candidato e decidere quali segmenti preservare, quelli che meglio supportano la query, e quali eliminare, ovvero il resto. L'output del modello preserva il testo sorgente anziché riscriverlo. Ciò rende il risultato più facile da citare, più facile da verificare e meno costoso da trasmettere a valle.

Si considerino, ad esempio, questa query e il risultato recuperato:

Espandi

Un output del modello plausibile consisterebbe nel selezionare la frase in grassetto: “In Comet, l'assistente può ...”.

Il nostro approccio segue la medesima linea concettuale di lavori precedenti sulla compressione del contesto come FliCo, Provence e LooComp, adattati per la generazione di snippet in un sistema di ricerca in produzione. È importante sottolineare che il modello opera come fase di precisione dopo la nostra fase di recupero grezzo. Come discusso nel nostro precedente articolo di ricerca Perplexity, Introducing the Perplexity Search API, progettiamo i nostri sistemi di recupero affinché operino nativamente a livello di sotto-documento, o snippet, il che ci consente già di bilanciare efficacemente precisione e richiamo. L'introduzione di un modello di compressione del contesto consapevole della query sposta ulteriormente la frontiera di Pareto precisione-richiamo.

Creazione e addestramento di un modello di compressione del contesto

Sviluppiamo il nostro modello tenendo presenti tre considerazioni principali: comprensione congiunta di query e contesto, selezione granulare a livello di frase ed efficienza per rientrare in un limite di latenza estremamente rigido.

Architettura del modello

Utilizziamo un modello pplx-diffusion come base. Si tratta della stessa famiglia di modelli dietro pplx-embed-v1, e sia i nostri precedenti lavori accademici, Diffusion-Pretrained Dense and Contextual Embeddings, che i nostri benchmark di produzione confermano che si tratta di un solido codificatore bidirezionale per coppie query-contesto. Una delle proprietà chiave di questa famiglia di modelli è il contesto bidirezionale: ogni rappresentazione di token può prestare attenzione all'intera query e all'intero contesto candidato prima che il modello decida cosa conservare.

Sopra questa base, addestriamo una testata di compressione leggera che prevede quali parti del contesto debbano essere mantenute. Poiché non è coinvolta alcuna generazione, queste previsioni vengono effettuate in parallelo sull'intero contesto. In fase di servizio, il motore degli snippet aggrega tali previsioni a livello di frase, applica una soglia e riduce il risultato al budget di token richiesto.

Pipeline di supervisione

L'addestramento di questo compressore richiede una supervisione al giusto livello di granularità. Un'etichetta di rilevanza a livello di documento è chiaramente inadeguata per la nostra attività di compressione estrattiva. Per generare dati sufficientemente granulari per l'apprendimento supervisionato, abbiamo creato una pipeline di etichettatura dei segmenti che contrassegna i segmenti di prova rilevanti per la query, insieme ai segmenti di disturbo che dovrebbero essere rimossi.

La nostra pipeline utilizza una configurazione LLM-as-a-judge. Data una query dell'utente e una pagina web candidata con il relativo link, titolo e riassunto, il giudice esegue innanzitutto una comprensione della query, analizzando la query e producendo un elenco di possibili intenti dell'utente. Basandosi su tali intenti, il giudice elabora quindi il contesto candidato e restituisce segmenti copiati testualmente dal contenuto, con una categoria per ciascun segmento per facilitare l'ispezione delle etichette.

Abbiamo quindi fatto corrispondere i segmenti restituiti al testo di origine. Com'era prevedibile, la maggior parte degli output del giudice erano già copie esatte: la corrispondenza ingenua di stringhe ha recuperato il 98% dei segmenti. L'aggiunta di un semplice passaggio di corrispondenza basato su espressioni regolari ha portato il recupero dei segmenti al 100%. Questo ci ha fornito segmenti granulari e affidabili che potevano essere convertiti in una supervisione di conservazione/eliminazione a livello di token.

Abbiamo valutato questa pipeline di supervisione utilizzando un piccolo set di dati curato con segmenti etichettati manualmente, confrontando modelli di giudizio più piccoli, diversi prompt e diverse configurazioni dei passaggi. La configurazione con le migliori prestazioni è stata una pipeline a due stadi: prima la comprensione della query, seguita dall'etichettatura categorizzata dei segmenti. Abbiamo inoltre convalidato il set di segmenti estratti tramite valutazioni verificabili a valle come BrowseComp e SimpleQA, dove l'utilizzo dei soli segmenti di prova conservati ha mantenuto punteggi elevati riducendo significativamente i token di input.

Utilizzando questa pipeline, abbiamo etichettato 750 mila coppie query-documento e utilizzato i segmenti risultanti per addestrare la testata di compressione con cross-entropy binaria. Questo processo consente al nostro modello di compressione consapevole della query di mantenere intatto il testo di origine rimuovendo al contempo il contesto che difficilmente aiuterà il modello a valle a soddisfare la richiesta dell'utente.

Garantire la latenza in tempo reale

La compressione del contesto precede il modello a valle, rendendola un'operazione bloccante. Inoltre, ogni compressione dipende dalla query. Pertanto, il percorso online deve valutare le coppie query-contesto per ogni documento candidato entro un rigido limite di latenza. Un modello di compressione lento è controproducente, poiché i vantaggi di latenza derivanti da una maggiore precisione vengono annullati dalla latenza di compressione stessa. Allo stesso tempo, un modello di compressione meno intelligente prenderà decisioni peggiori su cosa tagliare e cosa mantenere.

La questione pratica è quanta capacità del modello possiamo rimuovere in sicurezza prima che la qualità della compressione inizi a degradare. Confrontiamo la base completa pplx-diffusion a 28 strati con varianti a 11 e 17 strati prodotte tramite potatura degli strati e mirate al percorso di ricerca. Per ciascuna, eseguiamo una scansione sulla soglia di compressione e misuriamo due quantità: il numero medio di token di contesto inviati a valle per query e la frazione di elementi probatori utili preservati dopo la compressione.

La Figura 2 mostra la frontiera qualità-efficienza. Un modello è migliore quando si sposta verso l'alto a sinistra: meno token a valle con più elementi probatori utili preservati. Il modello a 28 strati fornisce il riferimento di qualità. Il modello a 11 strati dimostra i rischi di una compressione troppo aggressiva. Il modello a 17 strati potato rappresenta una via di mezzo: segue da vicino il modello a 28 strati nel regime di saturazione, ma si apre un piccolo divario nella parte ripida della curva dove opera la maggior parte del traffico di produzione.

Per colmare tale divario, impieghiamo la distillazione della conoscenza a livello di token. Il nostro approccio è di routine: aumentiamo la perdita standard con un termine di cross-entropy soft sulle previsioni del modello insegnante, ponderato da un coefficiente di distillazione. Ciò è sufficiente a portare il modello studente alla parità, consentendoci di passare completamente al modello distillato a 17 strati in produzione. Questo nuovo modello di produzione produce una diminuzione del 35-40% della latenza di inferenza e una diminuzione del 40-45% del calcolo GPU aggregato senza alcun calo di qualità rispetto all'insegnante a 28 strati. La latenza di produzione si attesta al di sotto dei 20 ms (p99): sufficientemente ridotta per essere aggiunta al percorso di servizio, riducendo notevolmente i token totali passati al modello di risposta.

Espandi

Qualità ed efficienza dei token

Usiamo l'Agent API di Perplexity come banco di prova per analizzare l'efficacia della compressione del contesto. Valutiamo tre preset di Agent API:

Un preset di contesto “basso” che limita il budget di token per ogni set di risultati a 1000 token.

Un preset di contesto “medio” che limita il budget di token per ogni set di risultati a 4000 token.

Un preset di contesto “alto” che limita il budget di token per ogni set di risultati a 10000 token.

Sia le impostazioni standard, senza compressione, che quelle di compressione sono configurate per rispettare questi budget di token.

Ricerca multi-step agentica (BrowseComp)

Esaminiamo innanzitutto l'impatto della compressione sui flussi di lavoro di ricerca multi-step agentica sul benchmark BrowseComp. Eseguiamo questa valutazione utilizzando il nostro strumento open-source search_evals. La classificazione è identica in tutte le esecuzioni, utilizzando il prompt di giudizio LLM di BrowseComp canonico di OpenAI.

Le due dimensioni di interesse sono l'accuratezza del benchmark e l'utilizzo dei token. È importante sottolineare che misuriamo l'utilizzo dei token a livello di query anziché a livello di singolo passaggio, al fine di misurare l'effettivo carico di token sostenuto durante l'intero ciclo di vita della richiesta. La Figura 3 mostra la frontiera “punteggio-token”, ovvero punteggio di accuratezza rispetto all'utilizzo dei token.

Espandi

La compressione fornisce una nuova frontiera di Pareto su tutta la linea. Per ogni impostazione, l'introduzione della compressione riduce l'utilizzo dei token a livello di query dal 10% al 70%, con guadagni di accuratezza compresi tra 4 e 4,81 punti percentuali. L'introduzione della compressione consente persino al nostro preset “basso” di superare il preset “alto” senza compressione, riducendo al contempo l'utilizzo dei token di oltre tre volte.

Osserviamo che con la compressione, l'impostazione “alta” produce una maggiore accuratezza rispetto a quella “media”, come ci si potrebbe aspettare. È interessante notare, tuttavia, che ciò avviene con un minore utilizzo di token. Ciò rivela un effetto sottile ma importante della compressione: con la compressione, anche l'aumento delle dimensioni del contesto per passaggio può consentire al modello di eseguire meno passaggi per arrivare al risultato corretto. Esplorare questa non monotonicità è una direzione promettente per il lavoro futuro.

SimpleQA: fattualità a singolo passaggio

BrowseComp mette alla prova la ricerca multi-step, eppure molti flussi di lavoro di produzione implicano una ricerca fattuale a singolo passaggio. Per determinare se la compressione aiuti anche nel regime a singolo passaggio, esaminiamo anche le prestazioni su SimpleQA, un benchmark che comprende 4.326 domande a cui rispondere in un singolo passaggio di ricerca, anziché in un ciclo agentico.

Come in precedenza, tracciamo l'accuratezza rispetto ai token totali medi per attività utilizzando il prompt del giudice canonico. La Figura 4 mostra la frontiera punteggio-token in questa impostazione a singolo passaggio. Sebbene le dimensioni dell'effetto siano più compresse nell'impostazione a singolo passaggio, osserviamo ancora una volta che la compressione migliora simultaneamente accuratezza ed efficienza in tutti i preset, introducendo così una nuova frontiera di Pareto. Con la compressione abilitata, il preset medio raggiunge il 95% di accuratezza con una media di soli 200 token per documento. Data la lunghezza media del documento di oltre 10.000 token, ciò rappresenta una prestazione di livello frontiera con un rapporto di compressione superiore a 50.

Espandi

Cosa finisce negli snippet?

I guadagni a valle nelle Sezioni 4.1 e 4.2 sono end-to-end. Per comprendere in che modo la compressione modifichi i singoli snippet, eseguiamo una valutazione separata che utilizza un giudice LLM per classificare ogni token di ogni snippet recuperato in una delle sei categorie:

Vitale: prove essenziali per rispondere alla richiesta dell'utente.

Fuori tema: informazioni che potrebbero essere utili per altri scopi ma che non riguardano la query in oggetto.

Annunci: pubblicità irrilevante che distoglie dalla risposta alla richiesta dell'utente.

Metadati: metadati relativi ai contenuti del documento.

UI & navigazione: elementi per la visualizzazione frontend e la navigazione.

Duplicati: ripetizione di informazioni precedentemente incorporate.

La nostra valutazione viene eseguita su 1.000 query a dominio misto dal nostro set di convalida, confrontando lo stack di produzione rispetto a una baseline altrimenti identica con compressione disabilitata. Come mostrato nella Figura 5, la compressione aumenta la proporzione di token vitali per snippet in media del 63% rispetto alla baseline senza compressione. Osserviamo una corrispondente diminuzione del 29% nei token irrilevanti, con cali particolarmente netti nell'interfaccia utente/navigazione (-58%), metadati (-46%) e annunci (-43%). Questi risultati confermano il meccanismo per i miglioramenti qualità-efficienza discussi sopra: la compressione migliora le prestazioni in entrambe le dimensioni aumentando nettamente il rapporto segnale-rumore di ogni singolo snippet.

Espandi

La Figura 6 illustra questa variazione per una singola query. Per la query “assunzione di latte del neonato di 6 giorni per poppata”, mostriamo sia gli snippet non compressi, di baseline, che quelli compressi. La compressione elimina le categorie di contenuti non vitali e conserva solo le informazioni relative all'alimentazione del neonato. È importante sottolineare che la compressione elimina con successo contenuti che potrebbero essere generalmente pertinenti per la pagina, ma fuori tema per questa specifica query focalizzata sul neonato.

Espandi

Conclusione

I sistemi di IA si affidano a informazioni ad alto segnale per rispondere in modo intelligente ed efficiente alle richieste degli utenti. Queste informazioni devono essere presentate nel modo più chirurgico possibile per massimizzare la rilevanza per ogni richiesta. I nostri nuovi modelli di compressione consapevole della query fanno esattamente questo massimizzando le prove pertinenti per snippet ed eliminando in modo aggressivo gli elementi di disturbo irrilevanti.

Implementando questi nuovi modelli all'interno del nostro stack di ricerca, siamo in grado di fornire risposte più rapide e migliori a coloro che si affidano ai nostri prodotti e alle nostre API. Il nostro approccio crea una superficie di controllo semplice, consentendo ai nostri sistemi e ai clienti API di regolare il grado di compressione per bilanciare richiamo, latenza e costi.

La cura del contesto è un campo in via di sviluppo e c'è molto altro da fare per ottimizzare il valore di ogni token utilizzato all'interno degli attuali sistemi di intelligenza all'avanguardia. Stiamo lavorando attivamente per migliorare ulteriormente le nostre tecniche di cura del contesto attraverso miglioramenti del modello e dell'architettura di sistema, al fine di fare un uso ancora più estensivo di questi modelli.

Riferimenti

N. Chirkova, T. Formal, V. Nikoulina e S. Clinchant. Provence: Efficient and Robust Context Pruning for Retrieval-Augmented Generation, 2025. Accettato a ICLR 2025. arXiv:2501.16214.

T. Do, D. P. Tran, A. Vo, S. K. Kim e D. Kim. LooComp: Leverage Leave-One-Out Strategy to Encoder-only Transformer for Efficient Query-Aware Context Compression, 2026. arXiv:2603.09222.

S. Eslami, M. Gaiduk, M. Krimmel, L. Milliken, B. Wang e D. Bykov. Diffusion-Pretrained Dense and Contextual Embeddings, 2026. arXiv:2602.11151.

Z. Wang, J. Araki, Z. Jiang, M. R. Parvez e G. Neubig. Learning to Filter Context for Retrieval-Augmented Generation, 2023. arXiv:2311.08377.

Citazione

@online{perplexity2026QueryAwareContextCompressionForBetterSnippets,
  author = {{Perplexity} and Bo Wang and Hao Zhang and Ismail Gadzhiev and Kirill Priemko and Markus Krimmel and Nandor Licker and Vitalii Polshkov and Sarah Eslami and Louis Milliken and Maksim Gaiduk and Nikita Kireev and Jerry Ma},
  title = {{Query-aware context compression for better snippets}},
  date = {2026-05-14},
  url = {https://www.perplexity.ai/hub/blog/query-aware-context-compression-for-better-snippets}
}