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

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

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

Primero, perjudica 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 un “deterioro del contexto” (context rot) que afecta la capacidad del modelo para atender la solicitud real del usuario. Como resultado, es más probable que la respuesta final omita datos clave, otorgue demasiado peso a información de baja calidad o produzca afirmaciones que sean más difíciles de fundamentar en la fuente.

Segundo, empeora 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 (prefill), un costo mucho más significativo se paga en el razonamiento, ya que los modelos requieren más tokens de razonamiento para lidiar con el 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 el de tokens de razonamiento aumentan con un contexto con más ruido. Los distractores no solo reducen la calidad; terminan obligándote a pagar más por esa peor calidad.

Figura 1. El contexto recuperado sin procesar a menudo contiene la respuesta rodeada de texto irrelevante. La evidencia útil está presente, pero se encuentra oculta entre encabezados, pies de página, texto predeterminado (boilerplate), metadatos y contenido fuera de tema antes de que el modelo de respuestas la vea.

Para avanzar simultáneamente en precisión, velocidad y rentabilidad en las aplicaciones de Perplexity y la API Platform, invertimos fuertemente en mejorar la precisión del contexto. Una de las formas en que lo hacemos es mediante el refinamiento de nuestros algoritmos de generación de fragmentos. Tratamos la generación de fragmentos 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 fuente más pequeña y extraída quirúrgicamente para responder a la solicitud del usuario. Todo lo demás puede y debe eliminarse.

Por lo tanto, un buen fragmento debe hacer tres cosas:

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

Reducir la latencia y el costo 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 fragmentos 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 fragmentos (spans) que debe conservarse. Este artículo describe nuestro enfoque para construir y entrenar el modelo con el fin de lograr el mejor rendimiento de su clase en esta tarea crítica.

El primer orden del día es definir la tarea en sí. ¿Qué queremos que haga este modelo y cómo debemos definir el esquema de entrada y salida?

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

Nuestro enfoque en la precisión, la latencia y el costo deja clara la decisión de diseño. Podemos descartar la generación, ya que crear un nuevo resumen para cada página perjudica el rendimiento en los tres enfoques. La sumarización no encaja bien en la capa de evidencia que nos importa. Puede parafrasear la fuente, lo que dificulta 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 fragmento se utiliza como evidencia en lugar de como la respuesta final. La latencia y el costo involucrados hacen que la generación sea aún menos atractiva.

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é fragmentos (spans) conservar —aquellos que respaldan mejor la consulta— y cuáles descartar (el resto). La salida del modelo conserva el texto fuente en lugar de reescribirlo. Esto hace que el resultado sea más fácil de citar, más fácil de verificar y más económico de pasar a las etapas posteriores.

Por ejemplo, considere esta consulta y el resultado recuperado:

La compresión extractiva consciente de la consulta conserva la oración fuente relevante para la consulta y descarta el contexto no relacionado.

Una salida plausible del modelo sería seleccionar la oración en negrita: “En Comet, el asistente puede...`.”

Nuestro enfoque sigue la misma idea general que los trabajos previos de compresión de contexto como FliCo, Provence y LooComp, adaptados para la generación de fragmentos en un sistema de búsqueda en 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 analizó en nuestro artículo anterior de Perplexity Research, Introducing the Perplexity Search API, estructuramos nuestros sistemas de recuperación para que operen de forma nativa a nivel de subdocumento, o fragmento, lo que ya nos permite equilibrar muy bien la precisión y la recuperación (recall). Introducir 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.

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

Utilizamos un modelo pplx-diffusion como base (backbone). 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 benchmarks de producción confirman que es un codificador bidireccional sólido para pares de consulta-contexto. Una de las propiedades clave de esta familia de modelos es el contexto bidireccional: cada representación de token puede atender a toda la consulta y a todo el contexto candidato antes de que el modelo decida qué se debe conservar.

Además de esta base, entrenamos una cabeza de compresión ligera que predice qué partes del contexto se deben conservar. Debido a que no hay generación involucrada, estas predicciones se realizan en paralelo en todo el contexto. En el momento de la inferencia (serving), el motor de fragmentos agrupa estas predicciones a nivel de oración, aplica un umbral y recorta el resultado al presupuesto de tokens solicitado.

El entrenamiento de este compresor requiere supervisión al nivel correcto de granularidad. Una etiqueta de relevancia a nivel de documento es claramente inadecuada para nuestra tarea de compresión extractiva. Para generar datos suficientemente granulares para el aprendizaje supervisado, construimos una canalización de etiquetado de fragmentos (span labeling pipeline) que marca los fragmentos de evidencia relevantes para la consulta, junto con los fragmentos distractores que deben eliminarse.

Nuestra canalización utiliza una configuración de LLM como juez (LLM-as-a-judge). Dada la consulta de un usuario y una página web candidata con su enlace, título y resumen, el juez primero realiza la comprensión de la consulta, analizándola y produciendo una lista de posibles intenciones del usuario. Anclándose en estas intenciones, el juez procesa el contexto candidato y devuelve fragmentos copiados textualmente del texto, con una categoría para cada fragmento para facilitar la inspección de las etiquetas.

Luego, emparejamos los fragmentos devueltos con el texto fuente. 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 fragmentos. Agregar una simple pasada de coincidencia basada en expresiones regulares (regex) elevó la recuperación de fragmentos al 100%. Esto nos proporcionó fragmentos confiables y granulares que pudieron convertirse en supervisión de conservación/descarte a nivel de token.

Evaluamos esta canalización de supervisión utilizando un pequeño conjunto de datos seleccionado con fragmentos etiquetados manualmente, comparando modelos jueces más pequeños, diferentes indicaciones (prompts) y diferentes configuraciones de pasos. La configuración con mejor rendimiento fue una canalización de dos etapas: primero la comprensión de la consulta, seguida del etiquetado de fragmentos categorizados. También validamos el conjunto de fragmentos extraídos mediante evaluaciones verificables posteriores como BrowseComp y SimpleQA, donde el uso exclusivo de los fragmentos de evidencia conservados preservó puntuaciones sólidas al tiempo que redujo significativamente los tokens de entrada.

Utilizando esta canalización, etiquetamos 750 mil pares de consulta-documento y utilizamos los fragmentos resultantes para entrenar la cabeza 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 fuente mientras elimina el contexto que probablemente no ayudará al modelo posterior a atender la solicitud del usuario.

La compresión de contexto se sitúa antes del modelo posterior, lo que la convierte en una operación bloqueante. Además, cada compresión depende de la consulta. Por lo tanto, la ruta en línea debe calificar los pares de consulta-contexto para cada documento candidato dentro de un margen de latencia estricto. Un modelo de compresión lento se descalifica a sí mismo, ya que los beneficios de latencia de una mayor precisión son borrados por la latencia de la compresión en sí. Al mismo tiempo, un modelo de compresión menos inteligente tomará peores decisiones sobre qué recortar y retener.

La cuestión práctica es cuánta capacidad del modelo podemos eliminar de forma segura antes de que la calidad de la compresión comience a degradarse. Comparamos la base pplx-diffusion completa de 28 capas con variantes de 11 y 17 capas producidas mediante la poda de capas (layer pruning) y orientadas a la ruta de búsqueda. Para cada una, barremos el umbral de compresión y medimos dos cantidades: el número promedio de tokens de contexto enviados a las etapas posteriores por consulta, y la fracción de evidencia útil preservada después de la compresión.

La Figura 2 muestra la frontera de calidad-eficiencia. Un modelo es mejor cuando se desplaza hacia la parte superior izquierda: menos tokens posteriores con más evidencia útil preservada. El modelo de 28 capas proporciona la referencia de calidad. El modelo de 11 capas demuestra los riesgos de comprimir el modelo de manera 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 la destilación de conocimientos a nivel de token (token-level knowledge distillation). Nuestro enfoque es rutinario: aumentamos la pérdida estándar con un término de entropía cruzada suave en las predicciones del modelo profesor, ponderado por un coeficiente de destilación. Esto es suficiente para llevar al modelo estudiante a la paridad, lo que nos permite cambiar por completo al modelo de 17 capas destilado en producción. Este nuevo modelo de producción ofrece una disminución del 35-40% en la latencia de inferencia y una disminución del 40-45% en el cómputo de GPU agregado sin caída de calidad en relación con el profesor de 28 capas. La latencia de producción se sitúa en menos de 20 ms (p99): lo suficientemente pequeña como para agregarla a la ruta de servicio mientras se reducen en gran medida los tokens totales pasados al modelo de respuestas.

Figura 2. Rendimiento de la compresión en varias profundidades de modelo. El estudiante destilado de 17 capas, nuestro modelo de producción, iguala al profesor de 28 capas en el rendimiento de compresión en todos los umbrales, con un costo de cómputo en línea menor.

Utilizamos la Agent API de Perplexity como banco de pruebas para analizar la eficacia de la compresión de contexto. Evaluamos tres opciones preestablecidas (presets) de la Agent API:

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

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

Un ajuste preestablecido 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 con compresión están configuradas para respetar estos presupuestos de tokens.

Primero examinamos el impacto de la compresión en los flujos de trabajo de búsqueda multi-paso basados en agentes en el benchmark 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 indicador canónico de juez LLM de BrowseComp de OpenAI.

Las dos dimensiones de interés son la precisión del benchmark 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 en todo el ciclo de vida de la solicitud. La Figura 3 muestra la frontera “puntuación-token”, que contrasta la puntuación de precisión frente al uso de tokens.

Figura 3. Frontera de puntuación-token en BrowseComp. Los puntos en la parte superior representan una mayor precisión, mientras que los puntos de la izquierda representan una mayor eficiencia. La compresión mejora la frontera de Pareto en todos los ajustes preestablecidos. Las líneas horizontales punteadas representan sistemas de búsqueda ajenos a Perplexity, incluidos los benchmarks de Parallel. GPT-5.5 impulsa el bucle del agente.

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 que se sitúan entre 4 y 4.81 puntos porcentuales. Introducir la compresión permite que incluso nuestro ajuste preestablecido “bajo” supere al ajuste preestablecido “alto” sin compresión, todo ello reduciendo el uso de tokens en más de tres veces.

Observamos que con la compresión, el ajuste “alto” produce una mayor precisión que el “medio”, como cabría esperar. Sin embargo, curiosamente, 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 futuros trabajos.

BrowseComp enfatiza la investigación multi-paso, pero muchos flujos de trabajo de producción implican la búsqueda factual de un solo paso. Para determinar si la compresión también ayuda en el régimen de un solo paso, examinamos asimismo el rendimiento en SimpleQA, un benchmark que comprende 4,326 preguntas que deben responderse en un solo paso de búsqueda, en lugar de un bucle de agentes.

Como antes, graficamos la precisión frente al total promedio de tokens por tarea utilizando el indicador (prompt) de juez canónico. La Figura 4 muestra la frontera de puntuación-token en este entorno de un solo paso. Aunque los tamaños de los efectos están más comprimidos en el entorno de un solo paso, observamos nuevamente que la compresión mejora simultáneamente la precisión y la eficiencia en todos los ajustes preestablecidos, introduciendo así una nueva frontera de Pareto. Con la compresión habilitada, el ajuste preestablecido medio alcanza una precisión del 95% con un promedio de solo 200 tokens por documento. Dado que la longitud promedio de los documentos supera los 10,000 tokens, esto representa un rendimiento de nivel de vanguardia con una relación de compresión de más de 50.

Figura 4. Frontera de puntuación-token en SimpleQA. Los puntos en la parte superior representan una mayor precisión, mientras que los puntos de la izquierda representan una mayor eficiencia. La compresión mejora la frontera de Pareto en todos los ajustes preestablecidos. Las líneas horizontales punteadas representan sistemas de búsqueda ajenos a Perplexity, incluidas las evaluaciones de la API de Exa.

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

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

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

Anuncios (Ads): publicidad irrelevante que distrae de la respuesta a la consulta del usuario.

Metadatos (Metadata): metadatos sobre el contenido del documento.

IU y navegación (UI & navigation): elementos para la visualización en la interfaz de usuario y la navegación.

Duplicado (Duplicate): repetición de información incorporada anteriormente.

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

Figura 5. Cambio en la composición de tokens por fragmento debido a la compresión, promediado en 1,000 consultas. La proporción de contenido vital aumenta, con disminuciones correspondientes en las categorías de contenido no vital.

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

Figura 6. Fragmentos emitidos por la línea base sin compresión (arriba) y la pila comprimida (abajo) para un par de consulta-documento de ejemplo. La compresión retiene solo el primer 19% del fragmento de la línea base, descartando el 81% restante por considerarlo irrelevante.

Los sistemas de IA dependen de información de alta señal para atender de manera inteligente y eficiente las solicitudes de los usuarios. 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 conscientes de la consulta hacen precisamente esto al maximizar la evidencia sobre el tema por fragmento y eliminar agresivamente los distractores irrelevantes.

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

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

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.

BibTeX

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

Fragmentos como compresión consciente de la consulta

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

Arquitectura del modelo

Canalización de supervisión (Supervision pipeline)

Garantizar la latencia en tiempo real

Calidad y eficiencia de tokens

Búsqueda multi-paso basada en agentes (BrowseComp)

SimpleQA: factualidad de un solo paso

¿Qué termina en los fragmentos?

Conclusión

Referencias

Citación