Compresión de contexto consciente da consulta para mellores fragmentos

Cada resposta comeza con evidencias. Nun sistema de busca, estas evidencias adoitan proceder de documentos: títulos, resumos, fragmentos e anacos que se pasan como contexto a un modelo de resposta ou axente.

Este contexto en bruto ten ruído. Por exemplo, unha páxina web pode conter información necesaria para a solicitude do usuario, mais tamén pode conter elementos de distracción. Estes distractores poden aparecer tanto no corpo principal coma en elementos auxiliares, tales como elementos de texto de navegación, anuncios irrelevantes, metadatos e moito máis. Pasar estes distractores a un axente posterior crea tres problemas.

Primeiro, prexudica a precisión. Mesmo os modelos máis potentes teñen unha capacidade finita. As longas series de información irrelevante desaproveitan a capacidade do modelo, o que resulta nun "deterioro do contexto" que menoscaba a capacidade dun modelo para atender a solicitude real do usuario. Como resultado, é máis probable que a resposta final pase por alto feitos clave, sobrevaloración de información de baixa calidade ou produza afirmacións máis difíciles de fundamentar na fonte.

Segundo, empeora a latencia. Un contexto máis longo significa máis tokens para que o modelo posterior os procese, especialmente cando unha consulta precisa evidencias de moitas páxinas candidatas. Aínda que parte deste custo de latencia asúmese na etapa de preenchimento, pagarase un custo moito máis significativo no raciocínio, xa que os modelos requiren máis tokens de raciocínio para lidar co contexto irrelevante.

Terceiro, eleva o custo. Cada token innecesario pasado ao modelo fai que atender a solicitude do usuario sexa máis custoso, xa que tanto o uso de tokens de entrada coma de tokens de raciocínio aumenta cun contexto máis ruidoso. Os distractores non só reducen a calidade; acaban obrigándote a pagar máis por esa peor calidade.

Ampliar

Para mellorar simultaneamente a precisión, a velocidade e a relación custo-eficacia nas aplicacións de Perplexity e a API Platform, investimos moito en mellorar a precisión do contexto. Unha forma de facelo é refinando os nosos algoritmos de xeración de fragmentos. Tratamos a xeración de fragmentos como un problema de compresión de contexto. Os modelos que buscan información específica non se benefician de resumos xeneralizados ou extractos dun documento. Pola contra, necesitan a peza de información fonte máis pequena e extraída coidadosamente para responder á solicitude do usuario. Todo o demais pode e debe eliminarse.

Un bo fragmento debería, polo tanto, facer tres cousas:

Promover a precisión presentando a evidencia exacta necesaria para fundamentar a resposta do modelo.

Reducir a latencia e o custo eliminando o contexto irrelevante antes da chamada ao LLM.

Garantir a trazabilidade preservando a fidelidade das citas e mantendo intacta a redacción da orixe.

Este mes, despregamos un novo xerador de fragmentos de última xeración nas nosas aplicacións e na API Platform. O núcleo deste módulo é un modelo de compresión de contexto consciente da consulta que decide, para cada consulta e resultado candidato, o subconxunto de intervalos que se deben conservar. Este artigo describe o noso enfoque para construír e adestrar o modelo co fin de acadar un rendemento líder na súa clase nesta tarefa crítica.

Fragmentos como compresión consciente da consulta

A primeira orde do día é definir a propia tarefa. Que queremos que faga este modelo e como debemos definir o esquema de entrada e saída?

Os métodos de fragmentos divídense en dúas grandes familias. A primeira está baseada na selección: atopar unha xanela, anaco, frase ou pasaxe relevante e pasala ao seguinte nivel. A segunda está baseada na xeración: pedir a un modelo que escriba un resumo centrado na consulta a partir da páxina.

O noso enfoque na precisión, a latencia e o custo deixa clara a decisión de deseño. Podemos descartar a xeración, xa que crear un novo resumo para cada páxina prexudica o rendemento nos tres focos. A sumarización encaixa mal na capa de evidencias que nos importa. Pode parafrasear a fonte, o que dificulta a aliñación das citas. Tamén pode introducir redacción que non estaba presente na páxina, o que é arriscado cando o fragmento se usa como evidencia en lugar de como resposta final. A latencia e o custo que implica fan que a xeración sexa aínda menos atractiva.

Pola contra, definimos a nosa tarefa como unha compresión extractiva consciente da consulta: separar as partes útiles do contexto recuperado das partes que distraen. En concreto, o noso modelo debe aceptar unha consulta e un resultado candidato, e decidir que intervalos preservar, aqueles que apoian mellor a consulta, e cales descartar, o resto. A saída do modelo conserva o texto fonte en lugar de reescrevelo. Isto fai que o resultado sexa máis fácil de citar, máis fácil de verificar e máis barato de pasar ao seguinte nivel.

Por exemplo, considere esta consulta e resultado recuperado:

Ampliar

Unha saída plausible do modelo sería seleccionar a frase en negriña: “En Comet, o asistente pode...“.

O noso enfoque segue a mesma idea xeral que traballos anteriores de compresión de contexto como FliCo, Provence e LooComp, adaptados para a xeración de fragmentos nun sistema de busca en produción. É importante destacar que o modelo funciona como unha etapa de precisión despois da nosa etapa de recuperación en bruto. Tal e como se comentou no noso artigo anterior de Perplexity Research, Introducing the Perplexity Search API, deseñamos os nosos sistemas de recuperación para operar de xeito nativo a nivel de subdocumento, ou fragmento, o que xa nos permite equilibrar moi ben a precisión e a recuperación. Introducir un modelo de compresión de contexto consciente da consulta empurra a fronteira de Pareto de precisión e recuperación aínda máis cara ao exterior.

Construción e adestramento dun modelo de compresión de contexto

Desenvolvemos o noso modelo tendo en conta tres consideracións principais: comprensión conxunta da consulta e do contexto, selección detallada a nivel de frase e eficiencia para axustarse a un orzamento de latencia extremadamente axustado.

Arquitectura do modelo

Usamos un modelo pplx-diffusion como espinha dorsal. Esta é a mesma familia de modelos detrás de pplx-embed-v1, e tanto o noso traballo académico anterior, Diffusion-Pretrained Dense and Contextual Embeddings, coma os nosos benchmarks de produción confirman que é un codificador bidireccional sólido para pares de consulta-contexto. Unha das propiedades clave desta familia de modelos é o contexto bidireccional: cada representación de token pode atender á consulta completa e ao contexto candidato completo antes de que o modelo decida que se debe conservar.

Ademais desta espinha dorsal, adestramos unha cabeza de compresión lixeira que predice que partes do contexto se deben conservar. Como non hai xeración involucrada, estas predicións realícense en paralelo en todo o contexto. No momento do servizo, o motor de fragmentos agrega estas predicións a nivel de frase, aplica un limiar e recorta o resultado ao orzamento de tokens solicitado.

Pipeline de supervisión

Adestrar este compresor require supervisión no nivel correcto de granularidad. Unha etiqueta de relevancia a nivel de documento é claramente inadecuada para a nosa tarefa de compresión extractiva. Para xerar datos suficientemente granulares para a aprendizaxe supervisada, construímos unha canalización de etiquetaxe de intervalos que marca os intervalos de evidencias relevantes para a consulta, xunto cos intervalos distractores que se deben eliminar.

A nosa canalización usa unha configuración de LLM como xuíz. Dado unha consulta de usuario e unha páxina web candidata co seu enlace, título e resumo, o xuíz realiza primeiro a comprensión da consulta, analizando a consulta e producindo unha lista de posibles intencións do usuario. Baseándose nestas intencións, o xuíz procesa logo o contexto candidato e devolve intervalos copiados textualmente do texto, cunha categoría para cada intervalo para facilitar a inspección das etiquetas.

A continuación, coincidimos cos intervalos devoltos de volta ao texto fonte. Como era de agardar, a maioría das saídas do xuíz xa eran copias exactas: a coincidencia de cadeas inxenua recuperou o 98% dos intervalos. Engadir unha simple pasada de coincidencia baseada en expresións regulares elevou a recuperación de intervalos ao 100%. Isto deunos intervalos fiables e granulares que se puideron converter en supervisión de mantemento/eliminación a nivel de token.

Evaluamos esta canalización de supervisión utilizando un pequeno conxunto de datos comisariado con intervalos etiquetados manualmente, comparando modelos de xuíz máis pequenos, diferentes indicacións e diferentes configuracións de pasos. A configuración con mellor rendemento foi unha canalización de dúas etapas: primeiro a comprensión da consulta, seguida dunha etiquetaxe de intervalos categorizados. Tamén validamos o conxunto de intervalos extraídos mediante avaliacións verificables posteriores como BrowseComp e SimpleQA, onde o uso exclusivo dos intervalos de evidencias gardados preservou puntuacións fortes ao tempo que reduciu significativamente os tokens de entrada.

Usando esta canalización, etiquetamos 750 mil pares de consulta-documento e usamos os intervalos resultantes para adestrar a cabeza de compresión con entropía cruzada binaria. Este proceso permite que o noso modelo de compresión consciente da consulta manteña intacto o texto fonte mentres elimina o contexto que probablemente non axude ao modelo posterior a atender a solicitude do usuario.

Garantir a latencia en tempo real

A compresión de contexto sitúase antes do modelo posterior, o que a converte nunha operación bloqueante. Ademais, cada compresión depende da consulta. Polo tanto, a ruta en liña ten que puntuar pares de consulta-contexto para cada documento candidato dentro dun marco de latencia esixente. Un modelo de compresión lento é contraproducente, xa que os beneficios de latencia dunha maior precisión son borrados pola propia latencia de compresión. Ao mesmo tempo, un modelo de compresión menos intelixente tomará peores decisións sobre que cortar e reter.

A cuestión práctica é quanta capacidade do modelo podemos eliminar de forma segura antes de que a calidade da compresión comece a degradarse. Comparamos a espiña dorsal completa de pplx-diffusion de 28 capas con variantes de 11 e 17 capas producidas mediante poda de capas e dirixidas á ruta de busca. Para cada unha, barremos o limiar de compresión e medimos dúas cantidades: o número medio de tokens de contexto enviados ao seguinte nivel por consulta e a fracción de evidencias útiles conservadas despois da compresión.

A Figura 2 mostra a fronteira de calidade-eficiencia. Un modelo é mellor cando se move cara arriba e á esquerda: menos tokens posteriores con máis evidencias útiles conservadas. O modelo de 28 capas ofrece a referencia de calidade. O modelo de 11 capas demostra os riscos de comprimir o modelo de forma demasiado agresiva. O modelo poda de 17 capas representa un punto intermedio: segue de preto ao modelo de 28 capas no réxime saturado, mais ábrese unha pequena brecha na porción empinada da curva onde opera a maioría do tráfico de produción.

Para pechar esa brecha, empregamos a destilación de coñecemento a nivel de token. O noso enfoque é rutineiro: aumentamos a perda estándar cun termo de entropía cruzada suave sobre as predicións do modelo profesor, ponderado por un coeficiente de destilación. Isto é suficiente para acadar a paridade no modelo alumno, o que nos permite cambiar por completo ao modelo de 17 capas destilado en produción. Este novo modelo de produción produce unha diminución do 35-40% na latencia de inferencia e unha diminución do 40-45% no cómputo de GPU agregado sen caída de calidade en relación co profesor de 28 capas. A latencia de produción sitúase por debaixo dos 20 ms (p99): o suficientemente pequena como para engadila á ruta de servizo ao tempo que reduce enormemente o total de tokens pasados ao modelo de resposta.

Ampliar

Calidade e eficiencia de tokens

Usamos a Agent API de Perplexity como banco de probas para analizar a eficacia da compresión de contexto. Avaliamos tres predefinicións da Agent API:

Unha predefinición de contexto “baixa” que restrinxe o orzamento de tokens para cada conxunto de resultados a 1.000 tokens.

Unha predefinición de contexto “media” que restrinxe o orzamento de tokens para cada conxunto de resultados a 4.000 tokens.

Unha predefinición de contexto “alta” que restrinxe o orzamento de tokens para cada conxunto de resultados a 10.000 tokens.

Tanto a configuración estándar, sen compresión, como a de compresión están configuradas para respectar estes orzamentos de tokens.

Busca multi-paso axéntica (BrowseComp)

Examinamos primeiro o impacto da compresión nos fluxos de traballo de busca multi-paso axéntica no benchmark BrowseComp. Realizamos esta avaliación utilizando o noso arnés de código aberto search_evals. A cualificación é idéntica en todas as execucións, utilizando a indicación de xuíz LLM de BrowseComp canónica de OpenAI.

As dúas dimensións de interese son a precisión do benchmark e o uso de tokens. É importante destacar que medimos o uso de tokens a nivel de consulta en lugar de a nivel de paso individual para medir a carga real de tokens incorrida ao longo do ciclo de vida da solicitude. A Figura 3 mostra a fronteira “puntuación-token”, a puntuación de precisión fronte ao uso de tokens.

Ampliar

A compresión ofrece unha nova fronteira de Pareto en todos os ámbitos. Para cada configuración, introducir a compresión reduce o uso de tokens a nivel de consulta entre un 10% e un 70%, con ganancias de precisión que se sitúan entre 4 e 4,81 puntos porcentuais. Introducir a compresión permite que incluso a nosa predefinición “baixa” supere á predefinición “alta” sen compresión, ao tempo que reduce o uso de tokens máis de tres veces.

Observamos que, coa compresión, a opción “alta” produce maior precisión que a “media” como poderiamos agardar. Curiosamente, con todo, faino cun menor uso de tokens. Isto revela un efecto subtil mais importante da compresión: coa compresión, mesmo aumentar o tamaño do contexto por paso pode permitir que o modelo dea menos pasos para chegar ao resultado correcto. Explorar esta non monotonicidade é unha dirección prometedora para futuros traballos.

SimpleQA: faticidade dun só paso

BrowseComp fai fincapé na investigación multi-paso, mais moitos fluxos de traballo de produción implican unha busca fática dun só paso. Para determinar se a compresión tamén axuda no réxime dun só paso, examinamos tamén o rendemento en SimpleQA, un benchmark que comprende 4.326 preguntas que se deben responder nun único paso de busca, en lugar dun bucle axéntico.

Como antes, representamos a precisión fronte á media de tokens totais por tarefa utilizando a indicación de xuíz canónica. A Figura 4 mostra a fronteira de puntuación-token neste configuración dun só paso. Aínda que os tamaños dos efectos están máis comprimidos no escenario dun só paso, observamos de novo que a compresión mellora simultaneamente a precisión e a eficiencia en todas as predefinicións, introducindo así unha nova fronteira de Pareto. Con esta activada, a predefinición media acada unha precisión do 95% cunha media de só 200 tokens por documento. Dado que a lonxitude media do documento supera os 10.000 tokens, isto representa un rendemento de nivel de fronteira cunha taxa de compresión superior a 50.

Ampliar

Que acaba nos fragmentos?

As ganancias posteriores nas Seccións 4.1 e 4.2 son de extremo a extremo. Para comprender como cambia a compresión os fragmentos individuais, executamos unha avaliación separada que usa un xuíz LLM para clasificar cada token de cada fragmento recuperado nunha de seis categorías:

Vital: evidencia esencial para responder á solicitude do usuario.

Fóra do tema: información que pode ser útil para algún outro propósito pero que non está relacionada coa consulta en cuestión.

Anuncios: publicidade irrelevante que distrae de responder á solicitude do usuario.

Metadatos: metadatos sobre o contido do documento.

IU e navegación: elementos para a visualización de frontend e a navegación.

Duplicado: repetición de información incorporada previamente.

A nosa avaliación execútase en 1.000 consultas de dominios mixtos do noso conxunto de validación, comparando a pila de produción cunha liña de base idéntica pero coa compresión deshabilitada. Tal e como se mostra na Figura 5, a compresión aumenta a proporción de tokens vitais por fragmento nun 63% de media en comparación coa liña de base sen compresión. Observamos unha diminución correspondente do 29% nos tokens irrelevantes, con caídas especialmente pronunciadas na IU/navegación (-58%), metadatos (-46%) e anuncios (-43%). Estes resultados confirman o mecanismo das melloras de calidade-eficiencia analizadas anteriormente: a compresión mellora o rendemento en ambas as dimensións ao aumentar drasticamente a relación sinal-ruído de cada fragmento individual.

Ampliar

A Figura 6 ilustra este cambio para unha consulta individual. Para a consulta “6 day old newborn milk intake per feeding”, mostramos tanto os fragmentos sen comprimir, da liña de base, coma os comprimidos. A compresión elimina as categorías de contido non vital e conserva só a información de alimentación relacionada co recén nacido. É importante destacar que a compresión elimina con éxito o contido que pode ser xeralmente relevante para a páxina, mais fóra do tema para esta consulta específica centrada no recén nacido.

Ampliar

Conclusión

Os sistemas de IA confían en información de alto sinal para atender de xeito intelixente e eficiente as solicitudes dos usuarios. Esta información debe presentarse do xeito máis coidadoso posible para maximizar a relevancia para cada consulta. Os nosos novos modelos de compresión consciente da consulta fan exactamente isto maximizando a evidencia sobre o tema por fragmento e eliminando de forma agresiva os distractores irrelevantes.

Ao desplegar estes novos modelos dentro da nosa pila de busca, somos quen de ofrecer respostas máis rápidas e mellores a aqueles que confían nos nosos produtos e APIs. O noso enfoque crea unha superficie de control simple, o que permite aos nosos sistemas e clientes da API axustar o grao de compresión para equilibrar entre recuperación, latencia e custo.

A curación de contexto é un campo en desenvolvemento, e aínda queda moito por facer para optimizar o valor de cada token usado nos sistemas de intelixencia de vangarda actuais. Estamos a traballar activamente para facer que as nosas técnicas de curación de contexto sexan aínda mellores mediante melloras nos modelos e na arquitectura do sistema para facer un uso aínda máis expansivo destes modelos.

Referencias

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

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

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

Cita

@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}
}