Compressió de context conscient de la consulta per a millors fragments

Cada resposta comença amb proves. En un sistema de cerca, aquestes proves solen provenir de documents: títols, resumits, fragments i talls que es passen com a context a un model de resposta o agent.

Aquest context brut té soroll. Per exemple, una pàgina web pot contenir informació necessària per a la sol·licitud de l'usuari, però també pot contenir elements de distracció. Aquests elements poden aparèixer tant al cos principal com en elements auxiliars, com ara elements de text de navegació, anuncis irrellevants, metadades i molt més. Passar aquests elements de distracció a un agent descendent crea tres problemes.

Primer, perjudica la precisió. Fins i tot els models més potents tenen una capacitat finita. Els llargs fluxos d'informació irrellevant malgasten la capacitat del model, la qual cosa provoca una «putrefacció del context» que perjudica la capacitat del model per abordar la sol·licitud real de l'usuari. Com a resultat, és més probable que la resposta final s'oblidi de fets clau, doni massa importància a informació de baixa qualitat o produeixi afirmacions que són més difícil de fonamentar en la font.

Segon, regressa la latència. Un context més llarg significa més tokens perquè el model descendent els processi, especialment quan una consulta necessita proves de moltes pàgines candidates. Tot i que part d'aquest cost de latència s'assumeix a l'etapa de preemplenament, s' Paga un cost molt més significatiu en el raonament, amb models que requereixen més tokens de raonament per tractar amb el context irrellevant.

Tercer, augmenta el cost. Cada token innecessari passat al model fa que sigui més costós satisfer la sol·licitud de l'usuari, ja que tant l'ús de tokens d'entrada com de tokens de raonament augmenta amb un context més sorollós. Els elements de distracció no només redueixen la qualitat; acaben obligant-vos a pagar més per aquesta pitjor qualitat.

Amplia

Per avançar simultàniament en precisió, velocitat i rendibilitat a les aplicacions de Perplexity i la API Platform, invertim intensament a millorar la precisió del context. Una de les maneres de fer-ho és perfeccionant els nostres algorismes de generació de fragments. Tractem la generació de fragments com un problema de compressió de context. Els models que busquen informació específica no es beneficien de resums generalitzats o extractes d'un document. Més aviat, necessiten la peça d'informació d'origen més petita i extreta quirúrgicament per respondre a la sol·licitud de l'usuari. Tot allò altre es pot i s'ha d'eliminar.

Per tant, un bon fragment ha de fer tres coses:

Promoure la precisió presentant les proves precises necessàries per fonamentar la resposta del model.

Reduir la latència i el cost eliminant el context irrellevant abans de la crida a l'LLM.

Garantir la traçabilitat preservant la fidelitat de les citacions i mantenint intacta la redacció de la font.

Aquest mes, hem desplegat un generador de fragments nou i d'última generació a les nostres aplicacions i a la API Platform. El nucli d'aquest mòdul és un model de compressió de context conscient de la consulta que decideix, per a cada consulta i resultat candidat, el subconjunt de trams que s'han de preservar. Aquest article descriu el nostre enfocament per construir i entrenar el model per aconseguir el millor rendiment de la categoria en aquesta tasca crítica.

Fragments com a compressió conscient de la consulta

La primera prioritat és definir la tasca en si. Què volem que faci aquest model i com hauríem de definir l'esquema d'entrada i sortida?

Els mètodes de fragments es divideixen en dues grans famílies. El primer es basa en la selecció: trobar una finestra, un fragment, una frase o un passatge rellevant i passar-lo cap avall. El segon es basa en la generació: demanar a un model que escrigui un resum centrat en la consulta a partir de la pàgina.

El nostre enfocament en la precisió, la latència i el cost deixa clara l'elecció de disseny. Podem descartar la generació, ja que crear un nou resum per a cada pàgina perjudica el rendiment en els tres focus. La resumització s'ajusta poc a la capa d'evidència que ens importa. Pot parfrasejar la font, cosa que dificulta l'alineació de les citacions. També pot introduir una redacció que no estava present a la pàgina, la qual cosa és arriscada quan el fragment s'utilitza com a prova en lloc de com a resposta final. La latència i el cost que comporta fan que la generació sigui encara menys acceptable.

Més aviat, definim la nostra tasca com una compressió extractiva conscient de la consulta: separar les parts útils del context recuperat de les parts que distreuen. Concretament, el nostre model ha d'acceptar una consulta i un resultat candidat, i decidir quins trams preservar, aquells que donen més suport a la consulta, i quins descartar, la resta. La sortida del model preserva el text d'origen en lloc de reescriure'l. Això fa que el resultat sigui més fàcil de citar, més fàcil de verificar i més barat de passar avall.

Per exemple, considereu aquesta consulta i resultat recuperat:

Amplia

Una sortida plausible del model seria seleccionar la frase en negreta: «A Comet, l'assistent pot...».

El nostre enfocament segueix la mateixa línia general que treballs anteriors de compressió de context com FliCo, Provence i LooComp, adaptats per a la generació de fragments en un sistema de cerca de producció. És important destacar que el model funciona com una etapa de precisió després de la nostra etapa de recuperació en brut. Tal com es va comentar al nostre article anterior de recerca de Perplexity, Introducing the Perplexity Search API, dissenyem els nostres sistemes de recuperació perquè funcionin de manera nativa a nivell de subdocument o fragment, la qual cosa ja ens permet equilibrar bastant bé la precisió i la exhaustivitat. Introduir un model de compressió de context conscient de la consulta desplaça la frontera de Pareto de precisió i exhaustivitat encara més cap enfora.

Construcció i entrenament d'un model de compressió de context

Desenvolupem el nostre model tenint en compte tres consideracions principals: la comprensió conjunta de la consulta i el context, la selecció a nivell de frase de gra fi i l'eficiència per ajustar-se a un pressupost de latència extremadament ajustat.

Arquitectura del model

Utilitzem un model pplx-diffusion com a eix vertebrador. Aquesta és la mateixa família de models darrere de pplx-embed-v1, i tant el nostre treball acadèmic anterior, Diffusion-Pretrained Dense and Contextual Embeddings, com els nostres punts de referència de producció confirmen que és un codificador bidireccional sòlid per a parelles de consulta i context. Una de les propietats clau d'aquesta família de models és el context bidireccional: cada representació de token pot prestar atenció a la consulta completa i al context candidat complet abans que el model decideixi què s'ha de conservar.

A més d'aquest eix vertebrador, entrenem un capçal de compressió lleuger que prediu quines parts del context s'han de conservar. Com que no hi ha cap generació implicada, aquestes prediccions es fan en paral·lel a tot el context. En el moment de servir, el motor de fragments agrupa aquestes prediccions a nivell de frase, aplica un llindar i retalla el resultat al pressupost de tokens sol·licitat.

Canalització de supervisió

L'entrenament d'aquest compressor requereix supervisió al nivell de granularitat adequat. Una etiqueta de rellevància a nivell de document és clarament inadequada per a la nostra tasca de compressió extractiva. Per generar dades prou granulars per a l'aprenentatge supervisat, hem creat una canalització d'etiquetatge de trams que marca els trams de proves rellevants per a la consulta, juntament amb els trams de distracció que s'haurien d'eliminar.

La nostra canalització utilitza una configuració d'LLM com a jutge. Donada la consulta d'un usuari i una pàgina web candidata amb el seu enllaç, títol i resum, el jutge primer realitza la comprensió de la consulta, analitzant-la i produint una llista de possibles intencions de l'usuari. Anclant-se en aquestes intencions, el jutge processa aleshores el context candidat i retorna trams copiats literalment del text, amb una categoria per a cada tram per fer que les etiquetes siguin més fàcils d'inspeccionar.

Aleshores hem fet coincidir els trams retornats amb el text d'origen. Com era d'esperar, la majoria de les sortides del jutge ja eren còpies exactes: la concordança de cadenes naïf va recuperar el 98% dels trams. Afegir un pas de concordança senzill basat en expressions regulars va portar la recuperació de trams al 100%. Això ens va proporcionar trams fiables i granulars que es podien convertir en una supervisió de conservació/eliminació a nivell de token.

Hem avaluat aquesta canalització de supervisió utilitzant un petit conjunt de dades comissariat amb trams etiquetats manualment, comparant models de jutge més petits, diferents indicis i diferents configuracions de passos. La configuració amb millor rendiment va ser una canalització de dues etapes: primer la comprensió de la consulta, seguida de l'etiquetatge de trams categoritzats. També hem validat el conjunt de trams extrets mitjançant avaluacions descendents verificables com ara BrowseComp i SimpleQA, on l'ús exclusiu dels trams de proves conservats mantenia puntuacions sòlides alhora que reduïa significativament els tokens d'entrada.

Utilitzant aquesta canalització, hem etiquetat 750 milions de parelles de consulta-document i hem utilitzat els trams resultants per entrenar el capçal de compressió amb entropia creuada binària. Aquest procés permet que el nostre model de compressió conscient de la consulta mantingui intacte el text d'origen alhora que elimina el context que és poc probable que ajudi el model descendent a satisfer la sol·licitud de l'usuari.

Garantir la latència en temps real

La compressió de context se situa abans del model descendent, convertint-la en una operació de bloqueig. A més, cada compressió depèn de la consulta. Per tant, el camí en línia ha de puntuar parelles de consulta-context per a cada document candidat dins d'un límit de latència exigent. Un model de compressió lent és contraproduent, ja que els beneficis de latència d'una major precisió s'esborren per la pròpia latència de compressió. Al mateix temps, un model de compressió menys intel·ligent prendrà decisions pitjors sobre què tallar i què retenir.

La qüestió pràctica és quanta capacitat de model podem eliminar de manera segura abans que la qualitat de la compressió comenci a degradar-se. Comparem l'eix vertebrador complet de 28 capes de pplx-diffusion amb variants d'11 i 17 capes produïdes per poda de capes i orientades al camí de cerca. Per a cadascuna, fem un escombrat del llindar de compressió i mesurarem dues quantitats: el nombre mitjà de tokens de context enviats cap avall per consulta, i la fracció de proves útils conservades després de la compressió.

La Figura 2 mostra la frontera de qualitat-eficiència. Un model és millor quan es mou cap a la part superior esquerra: menys tokens descendents amb més proves útils conservades. El model de 28 capes proporciona la referència de qualitat. El model d'11 capes demostra els riscos de comprimir el model de manera massa agressiva. El model podat de 17 capes representa un terme mitjà: s'ajusta estretament al model de 28 capes en el règim saturat, però s'obre una petita bretxa en la porció pronunciada de la corba on opera la majoria del trànsit de producció.

Per tancar aquesta bretxa, fem servir la distillació de coneixement a nivell de token. El nostre enfocament és rutinari: augmentem la pèrdua estàndard amb un terme d'entropia creuada tova sobre les prediccions del model professor, ponderat per un coeficient de distillació. Això és suficient per portar el model alumne a la paritat, permetent-nos canviar completament al model destil·lat de 17 capes en producció. Aquest nou model de producció produeix una disminució del 35-40% en la latència d'inferència i una disminució del 40-45% en el còmput total de GPU sense caiguda de qualitat en relació amb el professor de 28 capes. La latència de producció es situa per sota dels 20 ms (p99): prou petita per afegir-la al camí de servei alhora que redueix considerablement el total de tokens passats al model de resposta.

Amplia

Qualitat i eficiència de tokens

Utilitzem l'Agent API de Perplexity com a banc de proves per analitzar l'eficàcia de la compressió de context. Avaluem tres preajustos de l'API d'agents:

Un preajust de context «baix» que restringeix el pressupost de tokens per a cada conjunt de resultats a 1000 tokens.

Un preajust de context «mitjà» que restringeix el pressupost de tokens per a cada conjunt de resultats a 4000 tokens.

Un preajust de context «alt» que restringeix el pressupost de tokens per a cada conjunt de resultats a 10000 tokens.

Tant la configuració estàndard, sense compressió, com la de compressió estan configurades per respectar aquests pressupostos de tokens.

Cerca multi-pas de tipus agent (BrowseComp)

Primer examinem l'impacte de la compressió en els fluxos de treball de cerca multipas de tipus agent al punt de referència BrowseComp. Realitzem aquesta avaluació utilitzant el nostre arnès de codi obert search_evals. La qualificació és idèntica en totes les execucions, utilitzant el jurats LLM de BrowseComp canònic d'OpenAI.

Les dues dimensions d'interès són la precisió del punt de referència i l'ús de tokens. És important destacar que mesuràvem l'ús de tokens a nivell de consulta en lloc d'a nivell de pas individual per tal de mesurar la càrrega real de tokens incorreguda al llarg del cicle de vida de la sol·licitud. La Figura 3 mostra la frontera «puntuació-token», la puntuació de precisió enfront de l'ús de tokens.

Amplia

La compressió ofereix una nova frontera de Pareto arreu. Per a cada configuració, introduir la compressió redueix l'ús de tokens a nivell de consulta entre un 10% i un 70%, amb guanys de precisió que oscil·len entre 4 i 4,81 punts percentuals. Introduir la compressió permet fins i tot que el nostre preajust «baix» superi el preajust «alt» sense compressió, tot reduint l'ús de tokens més de tres vegades.

Observem que amb la compressió, el «alt» produeix una major precisió que el «mitjà» com podríem esperar. Curiosament, però, ho fa amb un ús de tokens més baix. Això revela un efecte subtil però important de la compressió: amb la compressió, fins i tot augmentar la mida del context per pas pot permetre que el model faci menys passos per arribar al resultat correcte. Explorar aquesta no-monotonicitat és una direcció prometedora per a un treball futur.

SimpleQA: factualitat d'un sol pas

BrowseComp posa èmfasi en la recerca multipas, però molts fluxos de treball de producció impliquen la cerca factual d'un sol pas. Per determinar si la compressió també ajuda en el règim d'un sol pas, també examinem el rendiment a SimpleQA, un punt de referència que comprèn 4.326 preguntes que s'han de respondre en un sol pas de cerca, en lloc d'un bucle de tipus agent.

Com abans, representem gràficament la precisió enfront dels tokens totals mitjans per tasca utilitzant l'indicis de jutge canònic. La Figura 4 mostra la frontera puntuació-token en aquest entorn d'un sol pas. Tot i que les mides dels efectes estan més comprimides en l'entorn d'un sol pas, tornem a observar que la compressió millora simultàniament la precisió i l'eficiència en tots els preajustos, introduint així una nova frontera de Pareto. Amb la compressió habilitada, el preajust mitjà aconsegueix una precisió del 95% amb una mitjana de només 200 tokens per document. Atesa la longitud mitjana del document de més de 10.000 tokens, això representa un rendiment de nivell de frontera a una ràtio de compressió de més de 50.

Amplia

Què acaba als fragments?

Els guanys descendents de les seccions 4.1 i 4.2 són d'extrem a extrem. Per entendre com canvia la compressió els fragments individuals, executem una avaluació independent que utilitza un jutge LLM per classificar cada token de cada fragment recuperat en una de les sis categories:

Vital: proves essencials per respondre a la consulta de l'usuari.

Fora del tema: informació que pot ser útil per a algun altre propòsit, però que no està relacionada amb la consulta en qüestió.

Anuncis: publicitat irrellevant que distreu de respondre a la consulta de l'usuari.

Metadades: metadades sobre el contingut del document.

IU i navegació: elements per a la visualització de la interfície d'usuari i la navegació.

Duplicat: repetició d'informació incorporada anteriorment.

La nostra avaluació s'executa en 1.000 consultes de domini mixt del nostre conjunt de validació, comparant la pila de producció amb una línia de base idèntica amb la compressió desactivada. Tal com es mostra a la Figura 5, la compressió augmenta la proporció de tokens vitals per fragment en una mitjana del 63% respecte a la línia de base sense compressió. Observem una disminució corresponent del 29% en els tokens irrellevants, amb caigudes especialment pronunciades en IU/navegació (-58%), metadades (-46%) i anuncis (-43%). Aquests resultats confirmen el mecanisme de les millores de qualitat-eficiència discutides anteriorment: la compressió millora el rendiment en ambdues dimensions augmentant fortament la relació senyal-soroll de cada fragment individual.

Amplia

La Figura 6 il·lustra aquest canvi per a una consulta individual. Per a la consulta «ingesta de llet de nounat de 6 dies per presa», mostrem tant els fragments sense comprimir, de línia de base, com els comprimits. La compressió elimina les categories de contingut no vital i reté només la informació d'alimentació relacionada amb el nounat. És important destacar que la compressió elimina amb èxit el contingut que pot ser generalment pertinent per a la pàgina, però fora del tema per a aquesta consulta específica centrada en el nounat.

Amplia

Conclusió

Els sistemes d'IA depenen d'informació d'alt senyal per satisfer de manera intel·ligent i eficient les sol·licituds dels usuaris. Aquesta informació s'ha de presentar de la manera més quirúrgica possible per maximitzar la rellevància per a cada sol·licitud. Els nostres nous models de compressió conscient de la consulta fan exactament això maximitzant les proves pertinents per fragment i eliminant agressivament els elements de distracció irrellevants.

Mitjançant el desplegament d'aquests nous models dins de la nostra pila de cerca, podem proporcionar respostes més ràpides i millors a aquells que depenen dels nostres productes i APIs. El nostre enfocament crea una superfície de control senzilla, permetent als nostres sistemes i clients de l'API ajustar el grau de compressió per equilibrar la recuperació, la latència i el cost.

La curació de context és un camp en desenvolupament, i queda molt per fer per optimitzar el valor de cada token utilitzat dins dels sistemes d'intel·ligència de frontera actuals. Treballem activament per fer que les nostres tècniques de curació de context siguin encara millors tant a través de millores del model com de l'arquitectura del sistema per fer un ús encara més expansiu d'aquests models.

Referències

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

T. Do, D. P. Tran, A. Vo, S. K. Kim i 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 i D. Bykov. Diffusion-Pretrained Dense and Contextual Embeddings, 2026. arXiv:2602.11151.

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

Citació

@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://perplexity.coolkeypoint.com/hub/blog/query-aware-context-compression-for-better-snippets}
}