Compresión de contexto consciente de la consulta para mejores extractos

Toda respuesta comienza con evidencia. En un sistema de búsqueda, esta evidencia generalmente proviene de documentos: títulos, resúmenes, fragmentos y extractos que se pasan como contexto a un modelo o agente de respuesta.

Este contexto sin procesar contiene ruido. Por ejemplo, una página web puede contener la información necesaria para la solicitud del usuario, pero también puede contener distractores. Estos distractores pueden aparecer tanto en el cuerpo principal como en elementos auxiliares, tales como elementos de texto de navegación, anuncios irrelevantes, metadatos y más. Pasar estos distractores a un agente posterior genera tres problemas.

Primero, afecta la precisión. Incluso los modelos más potentes tienen una capacidad finita. Las largas secuencias de información irrelevante desperdician la capacidad del modelo, lo que resulta en una “degradación del contexto” que perjudica la capacidad del modelo para atender la solicitud real del usuario. Como resultado, es más probable que la respuesta final omita hechos clave, sobrepondere información de baja calidad o produzca afirmaciones que son más difíciles de fundamentar en la fuente.

Segundo, provoca una regresión en la latencia. Un contexto más largo significa más tokens para que el modelo posterior los procese, especialmente cuando una consulta necesita evidencia de muchas páginas candidatas. Aunque parte de este costo de latencia se asume en la etapa de prellenado, un costo mucho más significativo se paga en el razonamiento, ya que los modelos requieren más tokens de razonamiento para tratar con un contexto irrelevante.

Tercero, aumenta el costo. Cada token innecesario pasado al modelo hace que sea más costoso atender la solicitud del usuario, ya que tanto el uso de tokens de entrada como de razonamiento aumenta con un contexto más ruidoso. Los distractores no solo reducen la calidad; terminan obligándole a pagar más por esa calidad inferior.

Ampliar

Para avanzar simultáneamente en la precisión, la velocidad y la rentabilidad en todas las aplicaciones de Perplexity y la API Platform, invertimos fuertemente en mejorar la precisión del contexto. Una forma de hacerlo es refinando nuestros algoritmos de generación de extractos. Tratamos la generación de extractos como un problema de compresión de contexto. Los modelos que buscan información específica no se benefician de resúmenes generalizados o extractos de un documento. Más bien, necesitan la pieza de información de origen más pequeña y quirúrgicamente extraída para responder a la solicitud del usuario. Todo lo demás puede y debe ser eliminado.

Por lo tanto, un buen extracto debe cumplir tres objetivos:

Promover la precisión presentando la evidencia exacta necesaria para fundamentar la respuesta del modelo.

Reducir la latencia y los costos eliminando el contexto irrelevante antes de la llamada al LLM.

Garantizar la trazabilidad preservando la fidelidad de las citas y manteniendo intacta la redacción de la fuente.

Este mes, implementamos un nuevo generador de extractos de última generación dentro de nuestras aplicaciones y la API Platform. El núcleo de este módulo es un modelo de compresión de contexto consciente de la consulta que decide, para cada consulta y resultado candidato, el subconjunto de tramos que deben preservarse. Este artículo describe nuestro enfoque para construir y entrenar el modelo con el fin de lograr un rendimiento líder en su clase en esta tarea crítica.

Los extractos como compresión consciente de la consulta

La primera prioridad es definir la tarea en sí misma. ¿Qué queremos que haga este modelo y cómo debemos definir el esquema de entrada y salida?

Los métodos de extracción se dividen en dos grandes familias. La primera se basa en la selección: encontrar una ventana, fragmento, oración o pasaje relevante y pasarlo al modelo posterior. La segunda se basa en la generación: pedirle a un modelo que redacte un resumen centrado en la consulta a partir de la página.

Nuestro enfoque en la precisión, la latencia y los costos hace que la elección del diseño sea clara. Podemos descartar la generación, ya que crear un nuevo resumen para cada página perjudica el rendimiento en los tres focos. La síntesis no es adecuada para la capa de evidencia que nos interesa. Puede parafrasear la fuente, dificultando la alineación de las citas. También puede introducir una redacción que no estaba presente en la página, lo cual es arriesgado cuando el extracto se utiliza como evidencia en lugar de como respuesta final. La latencia y los costos involucrados hacen que la generación sea aún menos aceptable.

Más bien, definimos nuestra tarea como una de compresión extractiva consciente de la consulta: separar las partes útiles del contexto recuperado de las partes que distraen. Específicamente, nuestro modelo debe aceptar una consulta y un resultado candidato, y decidir qué tramos conservar, aquellos que mejor respaldan la consulta, y cuáles descartar, el resto. La salida del modelo conserva el texto original en lugar de reescribirlo. Esto hace que el resultado sea más fácil de citar, verificar y económico de pasar al modelo posterior.

Por ejemplo, considere esta consulta y el resultado recuperado:

Ampliar

Una salida plausible del modelo sería seleccionar la oración en negrita: “In Comet, the assistant can ...”.

Nuestro enfoque sigue la misma idea general que el trabajo anterior de compresión de contexto, como FliCo, Provence y LooComp, adaptado para la generación de extractos en un sistema de búsqueda de producción. Es importante destacar que el modelo funciona como una etapa de precisión después de nuestra etapa de recuperación sin procesar. Como se discutió en nuestro artículo anterior de Perplexity Research, Introducing the Perplexity Search API, arquitectamos nuestros sistemas de recuperación para operar de forma nativa a nivel de subdocumento o extracto, lo que ya nos permite equilibrar bastante bien la precisión y la recuperación. La introducción de un modelo de compresión de contexto consciente de la consulta desplaza la frontera de Pareto de precisión-recuperación aún más hacia afuera.

Construcción y entrenamiento de un modelo de compresión de contexto

Desarrollamos nuestro modelo teniendo en cuenta tres consideraciones principales: comprensión conjunta de la consulta y el contexto, selección a nivel de oración de grano fino y eficiencia para ajustarse a un presupuesto de latencia extremadamente ajustado.

Arquitectura del modelo

Utilizamos un modelo pplx-diffusion como columna vertebral. Esta es la misma familia de modelos detrás de pplx-embed-v1, y tanto nuestro trabajo académico anterior, Diffusion-Pretrained Dense and Contextual Embeddings, como nuestros puntos de referencia de producción confirman que es un codificador bidireccional sólido para pares consulta-contexto. Una de las propiedades clave de esta familia de modelos es el contexto bidireccional: cada representación de token puede atender a la consulta completa y al contexto candidato completo antes de que el modelo decida qué debe conservarse.

Sobre esta columna vertebral, entrenamos un cabezal de compresión ligero que predice qué partes del contexto deben conservarse. Debido a que no hay generación involucrada, estas predicciones se realizan en paralelo en todo el contexto. En el momento de la entrega, el motor de extractos agrega estas predicciones a nivel de oración, aplica un umbral y recorta el resultado al presupuesto de tokens solicitado.

Canal de supervisión

Entrenar este compresor requiere supervisión en el nivel correcto de granularidad. Una etiqueta de relevancia a nivel de documento es claramente inapropiada para nuestra tarea de compresión extractiva. Para generar datos suficientemente granulares para el aprendizaje supervisado, construimos un canal de etiquetado de tramos que marca los tramos de evidencia relevantes para la consulta, junto con los tramos distractores que deben eliminarse.

Nuestro canal utiliza una configuración de LLM como juez. Dada una consulta de usuario y una página web candidata con su enlace, título y resumen, el juez primero realiza la comprensión de la consulta, analizando la consulta y produciendo una lista de posibles intenciones del usuario. Anclándose en estas intenciones, el juez luego procesa el contexto candidato y devuelve tramos copiados textualmente del texto, con una categoría para cada tramo para facilitar la inspección de las etiquetas.

Luego hicimos coincidir los tramos devueltos con el texto original. Como era de esperar, la mayoría de las salidas del juez ya eran copias exactas: la coincidencia de cadenas ingenua recuperó el 98 % de los tramos. Agregar una simple pasada de coincidencia basada en expresiones regulares llevó la recuperación de tramos al 100 %. Esto nos dio tramos fiables y granulares que podrían convertirse en supervisión de mantener/descartar a nivel de token.

Evaluamos este canal de supervisión utilizando un pequeño conjunto de datos curado con tramos etiquetados manualmente, comparando modelos de juez más pequeños, diferentes avisos y diferentes configuraciones de pasos. La configuración de mejor rendimiento fue un canal de dos etapas: comprensión de la consulta primero, seguido de etiquetado de tramos categorizados. También validamos el conjunto de tramos extraídos a través de evaluaciones verificables posteriores como BrowseComp y SimpleQA, donde el uso exclusivo de los tramos de evidencia conservados mantuvo puntuaciones sólidas mientras reducía significativamente los tokens de entrada.

Utilizando este canal, etiquetamos 750 mil pares de consulta-documento y utilizamos los tramos resultantes para entrenar el cabezal de compresión con entropía cruzada binaria. Este proceso permite que nuestro modelo de compresión consciente de la consulta mantenga intacto el texto original mientras elimina el contexto que es poco probable que ayude al modelo posterior a atender la solicitud del usuario.

Garantizar la latencia en tiempo real

La compresión de contexto se sitúa antes del modelo posterior, convirtiéndola en una operación de bloqueo. Además, cada compresión depende de la consulta. Por lo tanto, la ruta en línea tiene que calificar los pares consulta-contexto para cada documento candidato dentro de un sobre de latencia exigente. Un modelo de compresión lento es contraproducente, ya que los beneficios de latencia de una mayor precisión se ven anulados por la propia latencia de la compresión. Al mismo tiempo, un modelo de compresión menos inteligente tomará decisiones más pobres sobre qué cortar y retener.

La pregunta práctica es cuánta capacidad del modelo podemos eliminar de manera segura antes de que la calidad de la compresión comience a degradarse. Comparamos la columna vertebral pplx-diffusion completa de 28 capas con variantes de 11 y 17 capas producidas por poda de capas y dirigidas a la ruta de búsqueda. Para cada una, hacemos un barrido sobre el umbral de compresión y medimos dos cantidades: el número promedio de tokens de contexto enviados posteriormente por consulta y la fracción de evidencia útil conservada después de la compresión.

La Figura 2 muestra la frontera de calidad-eficiencia. Un modelo es mejor cuando se mueve hacia la parte superior izquierda: menos tokens posteriores con más evidencia útil conservada. El modelo de 28 capas proporciona la referencia de calidad. El modelo de 11 capas demuestra los riesgos de comprimir el modelo de forma demasiado agresiva. El modelo podado de 17 capas representa un punto medio: sigue de cerca al modelo de 28 capas en el régimen saturado, pero se abre una pequeña brecha en la porción pronunciada de la curva donde opera la mayor parte del tráfico de producción.

Para cerrar esa brecha, empleamos destilación de conocimiento a nivel de token. Nuestro enfoque es rutinario: aumentamos la pérdida estándar con un término de entropía cruzada suave sobre las predicciones del modelo maestro, ponderado por un coeficiente de destilación. Esto es suficiente para llevar al modelo alumno a la paridad, permitiéndonos cambiar completamente al modelo destilado de 17 capas en producción. Este nuevo modelo de producción produce una disminución del 35-40 % en la latencia de inferencia y una disminución del 40-45 % en el cómputo total de la GPU sin caída de calidad en relación con el maestro de 28 capas. La latencia de producción se registra en menos de 20 ms (p99): lo suficientemente pequeña como para añadirla a la ruta de servicio mientras se reducen enormemente los tokens totales pasados al modelo de respuesta.

Ampliar

Calidad y eficiencia de tokens

Utilizamos la Agent API de Perplexity como banco de pruebas para analizar la eficacia de la compresión de contexto. Evaluamos tres preajustes de Agent API:

Un preajuste de contexto “bajo” que limita el presupuesto de tokens para cada conjunto de resultados a 1000 tokens.

Un preajuste de contexto “medio” que limita el presupuesto de tokens para cada conjunto de resultados a 4000 tokens.

Un preajuste de contexto “alto” que limita el presupuesto de tokens para cada conjunto de resultados a 10000 tokens.

Tanto la configuración estándar, sin compresión, como la configuración de compresión están configuradas para respetar estos presupuestos de tokens.

Búsqueda agente de múltiples pasos (BrowseComp)

Primero examinamos el impacto de la compresión en los flujos de trabajo de búsqueda agente de múltiples pasos en el punto de referencia BrowseComp. Realizamos esta evaluación utilizando nuestro arnés de código abierto search_evals. La calificación es idéntica en todas las ejecuciones, utilizando el aviso de juez LLM de BrowseComp canónico de OpenAI.

Las dos dimensiones de interés son la precisión del punto de referencia y el uso de tokens. Es importante destacar que medimos el uso de tokens a nivel de consulta en lugar de a nivel de paso individual para medir la carga real de tokens incurrida a lo largo del ciclo de vida de la solicitud. La Figura 3 muestra la frontera “puntuación-token”, la puntuación de precisión frente al uso de tokens.

Ampliar

La compresión ofrece una nueva frontera de Pareto en todos los ámbitos. Para cada configuración, la introducción de la compresión reduce el uso de tokens a nivel de consulta entre un 10 % y un 70 %, con ganancias de precisión entre 4 y 4.81 puntos porcentuales. La introducción de la compresión permite que incluso nuestro preajuste “bajo” supere al preajuste “alto” sin compresión, todo ello mientras se reduce el uso de tokens en más de tres veces.

Observamos que con la compresión, “alto” produce una mayor precisión que “medio” como cabría esperar. Curiosamente, sin embargo, lo hace con un menor uso de tokens. Esto revela un efecto sutil pero importante de la compresión: con la compresión, incluso aumentar el tamaño del contexto por paso puede permitir que el modelo tome menos pasos para llegar al resultado correcto. Explorar esta no monotonicidad es una dirección prometedora para el trabajo futuro.

SimpleQA: factualidad de un solo paso

BrowseComp enfatiza la investigación de múltiples pasos, sin embargo, muchos flujos de trabajo de producción implican una búsqueda factual de un solo paso. Para determinar si la compresión también ayuda en el régimen de un solo paso, también examinamos el rendimiento en SimpleQA, un punto de referencia que comprende 4,326 preguntas que deben responderse en un solo paso de búsqueda, en lugar de un bucle de agente.

Como antes, representamos la precisión frente al total de tokens promedio por tarea utilizando el aviso de juez canónico. La Figura 4 muestra la frontera puntuación-token en este escenario de un solo paso. Aunque los tamaños de los efectos están más comprimidos en el escenario de un solo paso, observamos nuevamente que la compresión mejora simultáneamente la precisión y la eficiencia en todos los preajustes, introduciendo así una nueva frontera de Pareto. Con la compresión habilitada, el preajuste medio logra un 95 % de precisión con un promedio de solo 200 tokens por documento. Dada la longitud media del documento de más de 10,000 tokens, esto representa un rendimiento de nivel fronterizo con una relación de compresión de más de 50.

Ampliar

¿Qué termina en los extractos?

Las ganancias posteriores en las Secciones 4.1 y 4.2 son de extremo a extremo. Para entender cómo la compresión cambia los extractos individuales, realizamos una evaluación separada que utiliza un juez LLM para clasificar cada token de cada extracto recuperado en una de seis categorías:

Vital: evidencia esencial para responder a la consulta del usuario.

Fuera de tema: información que puede ser útil para algún otro propósito pero que no se relaciona con la consulta en cuestión.

Anuncios: publicidad irrelevante que distrae de responder a la consulta del usuario.

Metadatos: metadatos sobre el contenido del documento.

UI y navegación: elementos para la visualización y navegación del frontend.

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

Nuestra evaluación se ejecuta en 1,000 consultas de dominio mixto de nuestro conjunto de validación, comparando la pila de producción contra una línea base por lo demás idéntica con la compresión desactivada. Como se muestra en la Figura 5, la compresión aumenta la proporción de tokens vitales por extracto en un promedio del 63 % sobre la línea base sin compresión. Observamos una disminución correspondiente del 29 % en los tokens irrelevantes, con caídas particularmente pronunciadas en UI/navegación (-58 %), metadatos (-46 %) y anuncios (-43 %). Estos resultados confirman el mecanismo para las mejoras de calidad-eficiencia discutidas anteriormente: la compresión mejora el rendimiento en ambas dimensiones al aumentar drásticamente la relación señal-ruido de cada extracto individual.

Ampliar

La Figura 6 ilustra este cambio para una consulta individual. Para la consulta “ingesta de leche de recién nacido de 6 días de edad por alimentación”, mostramos tanto los extractos sin comprimir, la línea base y los extractos comprimidos. La compresión elimina las categorías de contenido no vital y conserva solo la información de alimentación relacionada con el recién nacido. Es importante destacar que la compresión elimina con éxito el contenido que podría ser generalmente relevante para la página, pero fuera de tema para esta consulta específica enfocada en el recién nacido.

Ampliar

Conclusión

Los sistemas de IA dependen de información de alta señal para atender las solicitudes de los usuarios de forma inteligente y eficiente. Esta información debe presentarse de la manera más quirúrgica posible para maximizar la relevancia para cada solicitud. Nuestros nuevos modelos de compresión consciente de la consulta hacen precisamente esto al maximizar la evidencia relevante por extracto y eliminar agresivamente los distractores irrelevantes.

Al desplegar estos nuevos modelos dentro de nuestra pila de búsqueda, podemos proporcionar respuestas más rápidas y mejores a quienes confían en nuestros productos y API. Nuestro enfoque crea una superficie de control simple, permitiendo a nuestros sistemas y clientes de API ajustar el grado de compresión para equilibrar entre recuperación, latencia y costo.

La curación de contexto es un campo en desarrollo, y queda mucho más por hacer para optimizar el valor de cada token utilizado dentro de los sistemas de inteligencia de frontera actuales. Estamos trabajando activamente para hacer que nuestras técnicas de curación de contexto sean aún mejores a través de mejoras en el modelo y la arquitectura del sistema para hacer un uso aún más expansivo de estos modelos.

Referencias

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

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

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

Citación

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