Compressão de contexto ciente da consulta para melhores fragmentos

Toda resposta começa com evidências. Em um sistema de busca, essa evidência geralmente vem de documentos: títulos, resumos, trechos (chunks) e fragmentos (snippets) que são repassados como contexto para um modelo de resposta ou agente.

Esse contexto bruto é ruidoso. Por exemplo, uma página da web pode conter informações necessárias para a solicitação do usuário, mas também pode conter elementos distratores. Esses distratores podem aparecer tanto no corpo principal quanto em elementos auxiliares, como elementos de texto de navegação, anúncios irrelevantes, metadados e muito mais. Passar esses distratores para um agente a jusante cria três problemas.

Primeiro, prejudica a precisão. Mesmo os modelos mais potentes têm capacidade finita. Longas sequências de informações irrelevantes desperdiçam a capacidade do modelo, resultando em "podridão de contexto" ("context rot"), o que prejudica a capacidade do modelo de atender à solicitação real do usuário. Como resultado, a resposta final tem mais probabilidade de omitir fatos fundamentais, dar peso excessivo a informações de baixa qualidade ou produzir afirmações mais difíceis de fundamentar na fonte.

Segundo, causa regressão na latência. Um contexto mais longo significa mais tokens para o modelo a jusante processar, especialmente quando uma consulta precisa de evidências de muitas páginas candidatas. Embora parte desse custo de latência ocorra no estágio de pré-preenchimento (prefill), um custo muito mais significativo é pago no raciocínio, com os modelos exigindo mais tokens de raciocínio para lidar com o contexto irrelevante.

Terceiro, aumenta o custo. Cada token desnecessário passado para o modelo torna mais custoso atender à solicitação do usuário, pois o uso de tokens de entrada e de raciocínio aumenta com um contexto mais ruidoso. Os distratores não apenas reduzem a qualidade; eles acabam forçando você a pagar mais por essa qualidade inferior.

Expandir

Para avançar simultaneamente em precisão, velocidade e custo-benefício em todas as aplicações da Perplexity e na API Platform, investimos fortemente na melhoria da precisão do contexto. Uma das maneiras de fazermos isso é refinando nossos algoritmos de geração de fragmentos. Tratamos a geração de fragmentos como um problema de compressão de contexto. Modelos que procuram informações específicas não se beneficiam de resumos generalizados ou trechos de um documento. Em vez disso, eles precisam da menor e mais cirurgicamente extraída peça de informação de fonte para responder à solicitação do usuário. Todo o resto pode e deve ser removido.

Um bom fragmento deve, portanto, fazer três coisas:

Promover a precisão, apresentando as evidências precisas necessárias para fundamentar a resposta do modelo.

Reduzir a latência e o custo, removendo o contexto irrelevante antes da chamada de LLM.

Garantir a rastreabilidade, preservando a fidelidade das citações e mantendo a redação da fonte intacta.

Este mês, implementamos um novo gerador de fragmentos de ponta em nossas aplicações e na API Platform. O núcleo deste módulo é um modelo de compressão de contexto ciente da consulta (query-aware), que decide, para cada consulta e resultado candidato, o subconjunto de trechos (spans) que deve ser preservado. Este artigo descreve nossa abordagem para construir e treinar o modelo para alcançar o melhor desempenho da categoria nesta tarefa crítica.

Fragmentos como Compressão Ciente da Consulta (Query-Aware)

A primeira ordem do dia é definir a própria tarefa. O que queremos que este modelo faça e como devemos definir o esquema de entrada e saída?

Os métodos de fragmentos dividem-se em duas grandes famílias. A primeira é baseada em seleção: encontrar uma janela, chunk, frase ou passagem relevante e passá-la para a frente. A segunda é baseada em geração: pedir a um modelo que escreva um resumo focado na consulta a partir da página.

Nosso foco em precisão, latência e custo torna a escolha de design clara. Podemos descartar a geração, pois criar um novo resumo para cada página prejudica o desempenho em todos os três focos. A sumarização não se encaixa bem na camada de evidências de que nos importamos. Ela pode parafrasear a fonte, dificultando o alinhamento de citações. Também pode introduzir termos que não estavam presentes na página, o que é arriscado quando o fragmento é usado como evidência em vez de como a resposta final. A latência e o custo envolvidos tornam a geração ainda mais indesejável.

Em vez disso, definimos nossa tarefa como uma compressão extrativa ciente da consulta: separar as partes úteis do contexto recuperado das partes que distraem. Especificamente, nosso modelo deve aceitar uma consulta e um resultado candidato, e decidir quais trechos (spans) preservar (aqueles que melhor apoiam a consulta) e quais descartar (o restante). A saída do modelo preserva o texto de origem em vez de reescrevê-lo. Isso torna o resultado mais fácil de citar, mais fácil de verificar e mais barato de passar para a frente.

Por exemplo, considere esta consulta e o resultado recuperado:

Expandir

Uma saída plausível do modelo seria selecionar a frase em negrito: "No Comet, o assistente pode...".

Nossa abordagem segue a mesma ideia geral de trabalhos anteriores de compressão de contexto, como FliCo, Provence e LooComp, adaptada para a geração de snippets em um sistema de busca em produção. Importante: o modelo atua como uma etapa de precisão após nossa etapa de recuperação bruta. Conforme discutido em nosso artigo anterior da Perplexity Pesquisa, Introducing the Perplexity Search API, arquitetamos nossos sistemas de recuperação para operar nativamente no nível de subdocumento, ou snippet, o que já nos permite equilibrar muito bem precisão e recall. A introdução de um modelo de compressão de contexto ciente da consulta desloca ainda mais para fora a fronteira de Pareto entre precisão e recall.

Construção e Treinamento de um Modelo de Compressão de Contexto

Desenvolvemos nosso modelo com três principais considerações em mente: compreensão conjunta da consulta e do contexto, seleção refinada no nível de frase e eficiência para se encaixar em um orçamento de latência extremamente restrito.

Arquitetura do modelo

Usamos um modelo pplx-diffusion como espinha dorsal (backbone). Esta é a mesma família de modelos por trás do pplx-embed-v1, e tanto o nosso trabalho acadêmico anterior, Diffusion-Pretrained Dense and Contextual Embeddings, quanto nossos benchmarks de produção confirmam que ele é um codificador bidirecional forte para pares de consulta e contexto. Uma das propriedades-chave desta família de modelos é o contexto bidirecional: cada representação de token pode prestar atenção (attend) a toda a consulta e ao contexto candidato completo antes que o modelo decida o que deve ser mantido.

Além dessa espinha dorsal, treinamos um cabeçote (head) de compressão leve que prevê quais partes do contexto devem ser mantidas. Como nenhuma geração está envolvida, essas previsões são feitas em paralelo em todo o contexto. No momento da serveção (serving), o motor de fragmentos agrega essas previsões no nível da frase, aplica um limite (threshold) e corta o resultado para o orçamento de tokens solicitado.

Pipeline de supervisão

Treinar este compressor requer supervisão no nível correto de granularidad. Um rótulo de relevância em nível de documento é claramente inadequado para nossa tarefa de compressão extrativa. Para gerar dados suficientemente granulares para aprendizado supervisionado, construímos um pipeline de rotulação de trechos que marca trechos de evidência relevantes para a consulta, juntamente com trechos distratores que devem ser removidos.

Nosso pipeline usa uma configuração de LLM como juiz (LLM-as-a-judge). Dada uma consulta do usuário e uma página da web candidata com seu link, título e resumo, o juiz primeiro realiza a compreensão da consulta, analisando-a e produzindo uma lista de possíveis intenções do usuário. Ancorando-se nessas intenções, o juiz processa o contexto candidato e retorna trechos copiados literalmente (verbatim) do texto, com uma categoria para cada trecho para tornar os rótulos mais fáceis de inspecionar.

Em seguida, correspondemos (matched) os trechos retornados de volta ao texto de origem. Sem surpresa, a maioria das saídas do juiz já eram cópias exatas: a correspondência de strings ingênua recuperou 98% dos trechos. A adição de uma passagem de correspondência simples baseada em expressões regulares (regex) elevou a recuperação de trechos para 100%. Isso nos deu trechos confiáveis e granulares que puderam ser convertidos em supervisão de manter/descartar (keep/drop) no nível de token.

Avaliamos este pipeline de supervisão usando um pequeno conjunto de dados curado com trechos rotulados manualmente, comparando modelos de juízes menores, diferentes prompts e diferentes configurações de etapas. O arranjo de melhor desempenho foi um pipeline de dois estágios: primeiro a compreensão da consulta, seguida pela rotulação de trechos categorizados. Também validamos o conjunto de trechos extraídos por meio de avaliações verificáveis a jusante, como BrowseComp e SimpleQA, onde o uso apenas dos trechos de evidência mantidos preservou pontuações fortes enquanto reduziu significativamente os tokens de entrada.

Usando este pipeline, rotulamos 750 mil pares de consulta-documento e usamos os trechos resultantes para treinar o cabeçote de compressão com entropia cruzada binária. Esse processo permite que nosso modelo de compressão ciente da consulta mantenha o texto de origem intacto enquanto remove o contexto que dificilmente ajudará o modelo a jusante a atender à solicitação do usuário.

Garantindo latência em tempo real

A compressão de contexto fica antes do modelo a jusante, tornando-a uma operação bloqueante. Além disso, cada compressão depende da consulta. Portanto, o caminho online precisa pontuar pares de consulta-contexto para cada documento candidato dentro de um envelope de latência rigoroso. Um modelo de compressão lento é contraproducente, pois os benefícios de latência de uma maior precisão são apagados pela própria latência de compressão. Ao mesmo tempo, um modelo de compressão menos inteligente tomará decisões piores sobre o que cortar e reter.

A questão prática é quanta capacidade do modelo podemos remover com segurança antes que a qualidade da compressão comece a se degradar. Comparamos a espinha dorsal completa de 28 camadas do pplx-diffusion com variantes de 11 e 17 camadas produzidas por poda de camadas (layer pruning) e direcionadas ao caminho de busca. Para cada uma, varremos o limite de compressão e medimos duas grandezas: o número médio de tokens de contexto enviados a jusante por consulta e a fração de evidência útil preservada após a compressão.

A Figura 2 mostra a fronteira de qualidade-eficiência. Um modelo é melhor quando se move em direção ao canto superior esquerdo: menos tokens a jusante com mais evidência útil preservada. O modelo de 28 camadas fornece a referência de qualidade. O modelo de 11 camadas demonstra os riscos de comprimir o modelo de forma muito agressiva. O modelo podado de 17 camadas representa um meio-termo: ele acompanha de perto o modelo de 28 camadas no regime saturado, mas uma pequena lacuna se abre na parte íngreme da curva onde a maior parte do tráfego de produção opera.

Para fechar essa lacuna, empregamos destilação de conhecimento no nível do token. Nossa abordagem é rotineira: aumentamos a perda padrão com um termo de entropia cruzada suave nas previsões do modelo professor (teacher), ponderado por um coeficiente de destilação. Isso basta para levar o modelo aluno (student) à paridade, permitindo-nos mudar totalmente para o modelo de 17 camadas destilado em produção. Este novo modelo de produção resulta em uma diminuição de 35-40% na latência de inferência e de 40-45% na computação agregada de GPU, sem queda de qualidade em relação ao professor de 28 camadas. A latência em produção registra menos de 20 ms (p99): pequena o suficiente para ser adicionada ao caminho de atendimento, reduzindo drasticamente o total de tokens passados para o modelo de resposta.

Expandir

Qualidade e Eficiência de Tokens

Usamos a Agent API da Perplexity como um ambiente de teste para analisar a eficácia da compressão de contexto. Avaliamos três predefinições (presets) da Agent API:

Uma predefinição de contexto "baixa" que restringe o orçamento de tokens para cada conjunto de resultados a 1.000 tokens.

Uma predefinição de contexto "média" que restringe o orçamento de tokens para cada conjunto de resultados a 4.000 tokens.

Uma predefinição de contexto "alta" que restringe o orçamento de tokens para cada conjunto de resultados a 10.000 tokens.

Tanto as configurações padrão (sem compressão) quanto as configurações de compressão são configuradas para respeitar esses orçamentos de tokens.

Busca em etapas múltiplas baseada em agentes (BrowseComp)

Primeiro, examinamos o impacto da compressão em fluxos de trabalho de busca multi-etapa baseados em agentes no benchmark BrowseComp. Realizamos essa avaliação usando nosso arnês (harness) de código aberto search_evals. A pontuação (grading) é idêntica em todas as execuções, usando o prompt canônico de juiz LLM do BrowseComp da OpenAI.

As duas dimensões de interesse são a precisão do benchmark e o uso de tokens. É importante destacar que medimos o uso de tokens no nível da consulta, e não no nível de cada etapa individual, para medir a carga real de tokens incorrida ao longo do ciclo de vida da solicitação. A Figura 3 mostra a fronteira "pontuação-token" (score-token), pontuação de precisão vs. uso de tokens.

Expandir

A compressão entrega uma nova fronteira de Pareto em todos os aspectos. Para cada configuração, a introdução da compressão reduz o uso de tokens no nível da consulta entre 10% e 70%, com ganhos de precisão situando-se entre 4 e 4,81 pontos percentuais. A introdução da compressão permite que até mesmo nossa predefinição "baixa" supere a predefinição "alta" sem compressão, tudo isso enquanto reduz o uso de tokens em mais de três vezes.

Observamos que, com a compressão, a opção "alta" produz maior precisão do que a "média", como poderíamos esperar. Curiosamente, no entanto, ela faz isso com menor uso de tokens. Isso revela um efeito sutil, mas importante da compressão: com a compressão, até mesmo aumentar o tamanho do contexto por etapa pode permitir que o modelo realize menos etapas para chegar ao resultado correto. Explorar essa não-monotonicidade é uma direção promissora para trabalhos futuros.

SimpleQA: factualidade em etapa única

O BrowseComp enfatiza a pesquisa em várias etapas, mas muitos fluxos de trabalho de produção envolvem busca factual em etapa única. Para determinar se a compressão também ajuda no regime de etapa única, examinamos o desempenho no SimpleQA, um benchmark composto por 4.326 perguntas a serem respondidas em uma única etapa de busca, em vez de um loop de agente.

Como antes, traçamos a precisão em relação à média total de tokens por tarefa usando o prompt de juiz canônico. A Figura 4 mostra a fronteira pontuação-token neste cenário de etapa única. Embora os tamanhos dos efeitos sejam mais comprimidos no cenário de etapa única, observamos novamente que a compressão melhora simultaneamente a precisão e a eficiência em todas as predefinições, introduzindo assim uma nova fronteira de Pareto. Com a compressão ativada, a predefinição média atinge 95% de precisão com uma média de apenas 200 tokens por documento. Dado o comprimento médio do documento de mais de 10.000 tokens, isso representa desempenho de nível de fronteira a uma taxa de compressão superior a 50.

Expandir

O que acaba nos fragmentos (snippets)?

Os ganhos a jusante nas Seções 4.1 e 4.2 são de ponta a ponta. Para entender como a compressão altera fragmentos individuais, executamos uma avaliação separada que usa um juiz LLM para classificar cada token de cada fragmento recuperado em uma de seis categorias:

Vital: evidência essencial para responder à solicitação do usuário.

Fora do tópico (Off-topic): informação que pode ser útil para algum outro propósito, mas não se relaciona com a consulta em questão.

Anúncios (Ads): publicidade irrelevante que distrai da resposta à solicitação do usuário.

Metadados: metadados sobre o conteúdo do documento.

IU e navegação (UI & navigation): elementos para exibição em frontend e navegação.

Duplicado: repetição de informações previamente incorporadas.

Nossa avaliação é executada em 1.000 consultas de domínio misto do nosso conjunto de validação, comparando a pilha de produção com uma linha de base (baseline) idêntica, mas com a compressão desativada. Conforme mostrado na Figura 5, a compressão aumenta a proporção de tokens vitais por fragmento em uma média de 63% em relação à linha de base sem compressão. Observamos uma diminuição correspondente de 29% em tokens irrelevantes, com quedas particularmente acentuadas em IU/navegação (-58%), metadados (-46%) e anúncios (-43%). Esses resultados confirmam o mecanismo para as melhorias de qualidade e eficiência discutidas acima: a compressão melhora o desempenho em ambas as dimensões ao aumentar drasticamente a proporção sinal-ruído de cada fragmento individual.

Expandir

A Figura 6 ilustra essa mudança para uma consulta individual. Para a consulta "6 day old newborn milk intake per feeding" (ingestão de leite de recém-nascido de 6 dias por mamada), mostramos tanto os fragmentos não comprimidos (linha de base) quanto os comprimidos. A compressão elimina as categorias de conteúdo não vital e retém apenas as informações de alimentação relacionadas ao recém-nascido. É importante ressaltar que a compressão elimina com sucesso o conteúdo que pode ser geralmente relevante para a página, mas irrelevante para esta consulta específica focada no recém-nascido.

Expandir

Conclusão

Os sistemas de IA dependem de informações de alto sinal para atender de forma inteligente e eficiente às solicitações dos usuários. Essas informações devem ser apresentadas da forma mais cirúrgica possível para maximizar a relevância para cada solicitação. Nossos novos modelos de compressão cientes da consulta fazem exatamente isso, maximizando a evidência sobre o tópico por fragmento e eliminando agressivamente distratores irrelevantes.

Ao implantar esses novos modelos em nossa pilha de busca, somos capazes de fornecer respostas mais rápidas e melhores para aqueles que dependem de nossos produtos e APIs. Nossa abordagem cria uma superfície de controle simples, permitindo que nossos sistemas e clientes de API ajustem o grau de compressão para equilibrar revocação, latência e custo.

A curadoria de contexto é um campo em desenvolvimento, e há muito mais a ser feito para otimizar o valor de cada token usado nos sistemas de inteligência de ponta de hoje. Estamos trabalhando ativamente para aprimorar ainda mais nossas técnicas de curadoria de contexto, tanto por meio de melhorias de modelo quanto de arquitetura de sistema, para fazer um uso ainda mais extensivo desses modelos.

Referências

N. Chirkova, T. Formal, V. Nikoulina, e S. Clinchant. Provence: Efficient and Robust Context Pruning for Retrieval-Augmented Generation, 2025. Aceito no 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.

Citação

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