Compressão de contexto consciente da consulta para melhores trechos

Cada resposta começa com evidências. Em um sistema de busca, essa evidência geralmente vem de documentos: títulos, resumos, partes e trechos que são passados como contexto para um modelo de resposta ou agente.

Esse contexto bruto contém ruído. Por exemplo, uma página da web pode conter as informações necessárias para a solicitação do usuário, mas também pode conter 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 subsequente cria três problemas.

Primeiro, prejudica a precisão. Mesmo os modelos mais poderosos têm capacidade finita. Longos fluxos de informações irrelevantes desperdiçam a capacidade do modelo, resultando em "deterioração do contexto" que prejudica a capacidade do modelo de atender à solicitação real do usuário. Como resultado, é mais provável que a resposta final perca fatos importantes, dê peso excessivo a informações de baixa qualidade ou produza alegações mais difíceis de fundamentar na fonte.

Segundo, regride a latência. Um contexto mais longo significa mais tokens para o modelo subsequente processar, especialmente quando uma consulta precisa de evidências de muitas páginas candidatas. Embora parte desse custo de latência seja suportado na fase de preenchimento, um custo muito mais significativo é pago no raciocínio, com os modelos exigindo mais tokens de raciocínio para lidar com contextos irrelevantes.

Terceiro, aumenta o custo. Cada token desnecessário passado para o modelo torna mais caro atender à solicitação do usuário, já que 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 promover simultaneamente a precisão, a velocidade e a relação custo-benefício em todas as aplicações da Perplexity e na API Platform, investimos pesadamente na melhoria da precisão do contexto. Uma maneira de fazer isso é refinando nossos algoritmos de geração de trechos. Tratamos a geração de trechos 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 origem para responder à solicitação do usuário. Todo o restante pode e deve ser removido.

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

Promover a precisão, apresentando a evidência precisa necessária para fundamentar a resposta do modelo.

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

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

Este mês, implementamos um novo gerador de trechos de última geração em nossas aplicações e na API Platform. O núcleo deste módulo é um modelo de compressão de contexto consciente da consulta, que decide, para cada consulta e resultado candidato, o subconjunto de 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.

Trechos como compressão consciente da consulta

A primeira ordem de serviço é definir a tarefa em si. O que queremos que este modelo faça e como devemos definir o esquema de entrada e saída?

Os métodos de trechos dividem-se em duas grandes famílias. A primeira baseia-se na seleção: encontrar uma janela, parte, frase ou passagem relevante e passá-la adiante. A segunda baseia-se na 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, já que criar um novo resumo para cada página prejudica o desempenho em todos os três focos. A sumarização não se adapta bem à camada de evidência que nos interessa. Ela pode parafrasear a fonte, tornando o alinhamento de citações mais difícil. Também pode introduzir uma redação que não estava presente na página, o que é arriscado quando o trecho é usado como evidência em vez de resposta final. A latência e o custo envolvidos tornam a geração ainda mais inaceitável.

Em vez disso, definimos nossa tarefa como uma compressão extrativa consciente 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 spans preservar — aqueles que melhor suportam 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 adiante.

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 ampla de trabalhos anteriores de compressão de contexto, como FliCo, Provence e LooComp, adaptada para a geração de trechos em um sistema de pesquisa de produção. É importante ressaltar que o modelo funciona como uma etapa de precisão após nossa etapa de recuperação bruta. Conforme discutido em nosso artigo anterior de pesquisa da Perplexity, Introduzindo a API de pesquisa da Perplexity, projetamos nossos sistemas de recuperação para operar nativamente no nível de subdocumento, ou trecho, o que já nos permite equilibrar muito bem a precisão e a recuperação. A introdução de um modelo de compressão de contexto consciente da consulta desloca a fronteira de Pareto de precisão-recuperação ainda mais para fora.

Construindo e treinando um modelo de compressão de contexto

Desenvolvemos nosso modelo com três considerações principais em mente: entendimento conjunto da consulta e do contexto, seleção de nível de frase refinada e eficiência para caber em um orçamento de latência extremamente apertado.

Arquitetura do modelo

Usamos um modelo pplx-diffusion como espinha dorsal. Esta é a mesma família de modelos por trás do pplx-embed-v1, e tanto nosso trabalho acadêmico anterior, Embeddings densos e contextuais pré-treinados por difusão, quanto nossos benchmarks de produção confirmam que ele é um forte codificador bidirecional para pares de consulta-contexto. Uma das principais propriedades desta família de modelos é o contexto bidirecional: cada representação de token pode atender à consulta completa e ao contexto do candidato completo antes que o modelo decida o que deve ser mantido.

Além desta espinha dorsal, treinamos uma cabeça de compressão leve que prevê quais partes do contexto devem ser mantidas. Como não há geração envolvida, essas previsões são feitas em paralelo em todo o contexto. No momento da entrega, o mecanismo de trechos agrega essas previsões no nível da frase, aplica um limite e corta o resultado para o orçamento de tokens solicitado.

Pipeline de supervisão

Treinar este compressor requer supervisão no nível certo de granularidade. Um rótulo de relevância em nível de documento é claramente impróprio para nossa tarefa de compressão extrativa. Para gerar dados suficientemente granulares para aprendizado supervisionado, construímos um pipeline de rotulagem de span que marca os spans de evidência relevantes para a consulta, juntamente com os spans distratores que devem ser removidos.

Nosso pipeline usa uma configuração de LLM-como-juiz. Dada uma consulta de 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 nessas intenções, o juiz então processa o contexto candidato e retorna spans copiados verbatim do texto, com uma categoria para cada span para facilitar a inspeção dos rótulos.

Em seguida, combinamos os spans retornados com o texto de origem. Sem surpresa, a maioria das saídas do juiz já eram cópias exatas: a correspondência de string ingênua recuperou 98% dos spans. Adicionar uma etapa simples de correspondência baseada em regex levou a recuperação de span a 100%. Isso nos forneceu spans confiáveis e granulares que puderam ser convertidos em supervisão de manter/descartar em nível de token.

Avaliamos este pipeline de supervisão usando um pequeno conjunto de dados curado com spans rotulados manualmente, comparando modelos de juízes menores, diferentes prompts e diferentes configurações de etapa. A configuração de melhor desempenho foi um pipeline de duas etapas: compreensão da consulta primeiro, seguida de rotulagem de span categorizada. Também validamos o conjunto de spans extraídos por meio de avaliações verificáveis subsequentes, como BrowseComp e SimpleQA, onde usar apenas os spans de evidência mantidos preservou pontuações altas enquanto reduzia significativamente os tokens de entrada.

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

Garantindo latência em tempo real

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

A questão prática é quanto da capacidade do modelo podemos remover com segurança antes que a qualidade da compressão comece a degradar. Comparamos a espinha dorsal de 28 camadas completa do pplx-diffusion com variantes de 11 e 17 camadas produzidas por poda de camadas e direcionadas ao caminho de pesquisa. Para cada uma, analisamos o limite de compressão e medimos duas quantidades: o número médio de tokens de contexto enviados adiante 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 subsequentes com mais evidências úteis preservadas. 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 segue 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 em nível de token. Nossa abordagem é rotineira: aumentamos a perda padrão com um termo de entropia cruzada suave nas previsões do modelo professor, ponderado por um coeficiente de destilação. Isso é suficiente para trazer o modelo aluno à paridade, permitindo-nos mudar totalmente para o modelo destilado de 17 camadas em produção. Este novo modelo de produção gera uma redução de 35-40% na latência de inferência e 40-45% de redução na computação agregada de GPU sem perda de qualidade em relação ao professor de 28 camadas. A latência de produção registra menos de 20 ms (p99): pequena o suficiente para adicionar ao caminho de serviço, enquanto reduz 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 uma bancada de testes para analisar a eficácia da compressão de contexto. Avaliamos três predefinições da Agent API:

Uma predefinição de contexto "baixo" que limita o orçamento de tokens para cada conjunto de resultados a 1000 tokens.

Uma predefinição de contexto "médio" que limita o orçamento de tokens para cada conjunto de resultados a 4000 tokens.

Uma predefinição de contexto "alto" que limita o orçamento de tokens para cada conjunto de resultados a 10000 tokens.

Tanto a configuração padrão, sem compressão, quanto a configuração com compressão são configuradas para respeitar esses orçamentos de tokens.

Pesquisa agente de várias etapas (BrowseComp)

Primeiro, examinamos o impacto da compressão nos fluxos de trabalho de pesquisa de várias etapas do agente no benchmark BrowseComp. Realizamos esta avaliação usando nosso harness de código aberto search_evals. A classificação é idêntica em todas as execuções, usando o prompt de juiz LLM BrowseComp canônico da OpenAI.

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

Expandir

A compressão oferece uma nova fronteira de Pareto em todos os aspectos. Para cada configuração, a introdução da compressão reduz o uso de tokens em nível de consulta de 10% a 70%, com ganhos de precisão 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 reduzindo o uso de tokens em mais de três vezes.

Observamos que com a compressão, a "alta" produz maior precisão do que a "média", como poderíamos esperar. Curiosamente, no entanto, isso ocorre 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 tome menos etapas para chegar ao resultado correto. Explorar essa não monotonicidade é uma direção promissora para trabalhos futuros.

SimpleQA: factualidade de etapa única

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

Como antes, plotamos a precisão em relação ao total médio de tokens por tarefa usando o prompt de juiz canônico. A Figura 4 mostra a fronteira pontuação-token nesta configuração de etapa única. Embora os tamanhos dos efeitos sejam mais compactados na configuração 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 um desempenho de nível de fronteira a uma taxa de compressão de mais de 50.

Expandir

O que acaba nos trechos?

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

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

Fora do tópico: informações que podem ser úteis para algum outro propósito, mas que não se relacionam com a consulta em questão.

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

Metadados: metadados sobre o conteúdo do documento.

UI e navegação: elementos para exibição de front-end e navegação.

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

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 idêntica, mas com a compressão desativada. Como mostrado na Figura 5, a compressão aumenta a proporção de tokens vitais por trecho 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 UI/navegação (-58%), metadados (-46%) e anúncios (-43%). Esses resultados confirmam o mecanismo para as melhorias de qualidade-eficiência discutidas acima: a compressão melhora o desempenho em ambas as dimensões ao aumentar drasticamente a relação sinal-ruído de cada trecho individual.

Expandir

A Figura 6 ilustra essa mudança para uma consulta individual. Para a consulta “ingestão de leite por mamada de recém-nascido de 6 dias de vida”, mostramos os trechos não comprimidos, a linha de base e os trechos 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 essa consulta específica focada em recém-nascidos.

Expandir

Conclusão

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

Ao implantar esses novos modelos em nossa pilha de pesquisa, 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 recall, 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 fronteira atuais. Estamos trabalhando ativamente para tornar nossas técnicas de curadoria de contexto ainda melhores por meio de melhorias de modelo e arquitetura de sistema para fazer um uso ainda mais expansivo desses modelos.

Referências

N. Chirkova, T. Formal, V. Nikoulina e S. Clinchant. Provence: Poda de contexto eficiente e robusta para geração aumentada por recuperação, 2025. Aceito no ICLR 2025. arXiv:2501.16214.

T. Do, D. P. Tran, A. Vo, S. K. Kim e D. Kim. LooComp: Aproveitando a estratégia Leave-One-Out para Transformer apenas codificador para compressão de contexto consciente da consulta eficiente, 2026. arXiv:2603.09222.

S. Eslami, M. Gaiduk, M. Krimmel, L. Milliken, B. Wang e D. Bykov. Embeddings densos e contextuais pré-treinados por difusão, 2026. arXiv:2602.11151.

Z. Wang, J. Araki, Z. Jiang, M. R. Parvez e G. Neubig. Aprendendo a filtrar o contexto para a geração aumentada por recuperação, 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://perplexity.coolkeypoint.com/hub/blog/query-aware-context-compression-for-better-snippets}
}