Compression de contexte sensible aux requêtes pour de meilleurs extraits

Chaque réponse commence par des données probantes. Dans un système de recherche, ces données proviennent généralement de documents : titres, résumés, segments et extraits qui sont transmis sous forme de contexte à un modèle de réponse ou à un agent.

Ce contexte brut est bruyant. Par exemple, une page Web peut contenir des informations nécessaires à la demande de l'utilisateur, mais aussi des éléments perturbateurs. Ces éléments perturbateurs peuvent apparaître à la fois dans le corps principal et dans des éléments accessoires, tels que les éléments textuels de navigation, les annonces publicitaires non pertinentes, les métadonnées, etc. Transmettre ces éléments perturbateurs à un agent en aval crée trois problèmes.

Premièrement, cela nuit à la précision. Même les modèles les plus puissants ont une capacité finie. De longues séries d'informations non pertinentes gaspillent la capacité du modèle, entraînant une « dégradation du contexte » qui nuit à la capacité du modèle à répondre à la véritable demande de l'utilisateur. Par conséquent, la réponse finale est plus susceptible d'omettre des faits clés, de surévaluer des informations de faible qualité ou de produire des affirmations plus difficiles à étayer par la source.

Deuxièmement, cela augmente la latence. Un contexte plus long signifie davantage de jetons à traiter pour le modèle en aval, en particulier lorsqu'une requête nécessite des données probantes provenant de nombreuses pages candidates. Bien qu'une partie de ce coût de latence soit supportée lors de la phase de pré-remplissage, un coût beaucoup plus important est payé lors du raisonnement, les modèles nécessitant davantage de jetons de raisonnement pour traiter un contexte non pertinent.

Troisièmement, cela augmente les coûts. Chaque jeton inutile transmis au modèle rend le traitement de la demande de l'utilisateur plus coûteux, car l'utilisation des jetons d'entrée et de raisonnement augmente avec un contexte plus bruyant. Les éléments perturbateurs ne se contentent pas de réduire la qualité ; ils finissent par vous forcer à payer plus cher pour cette qualité moindre.

Agrandir

Pour améliorer simultanément la précision, la vitesse et la rentabilité dans l'ensemble des applications de Perplexity et de la plateforme d'API, nous investissons massivement dans l'amélioration de la précision du contexte. Pour ce faire, nous affinons notamment nos algorithmes de génération d'extraits. Nous traitons la génération d'extraits comme un problème de compression de contexte. Les modèles à la recherche d'informations spécifiques ne bénéficient pas de résumés généralisés ou d'extraits d'un document. Au contraire, ils ont besoin de l'élément d'information source le plus petit et le plus chirurgicalement extrait pour répondre à la demande de l'utilisateur. Tout le reste peut et doit être supprimé.

Un bon extrait doit donc remplir trois fonctions :

Favoriser la précision en présentant les données probantes exactes nécessaires pour étayer la réponse du modèle.

Réduire la latence et les coûts en supprimant le contexte non pertinent avant l'appel au grand modèle de langage (LLM).

Assurer la traçabilité en préservant la fidélité des citations et en maintenant la formulation de la source intacte.

Ce mois-ci, nous avons déployé un nouveau générateur d'extraits de pointe au sein de nos applications et de notre plateforme d'API. Le cœur de ce module est un modèle de compression de contexte sensible aux requêtes qui détermine, pour chaque requête et chaque résultat candidat, le sous-ensemble d'intervalles à préserver. Cet article décrit notre approche pour concevoir et entraîner le modèle afin d'atteindre des performances de premier ordre pour cette tâche essentielle.

Les extraits comme compression sensible aux requêtes

La première étape consiste à définir la tâche elle-même. Que voulons-nous que ce modèle fasse, et comment devons-nous définir le schéma d'entrée et de sortie ?

Les méthodes d'extraction d'extraits se répartissent en deux grandes familles. La première est basée sur la sélection : trouver une fenêtre, un segment, une phrase ou un passage pertinent et le transmettre en aval. La seconde est basée sur la génération : demander à un modèle de rédiger un résumé axé sur la requête à partir de la page.

Notre accent sur la précision, la latence et les coûts rend notre choix de conception évident. Nous pouvons écarter la génération, car la création d'un nouveau résumé pour chaque page nuit aux performances dans ces trois domaines. La résume n'est pas adaptée à la couche de données probantes qui nous intéresse. Elle peut paraphraser la source, ce qui rend l'alignement des citations plus difficile. Elle peut également introduire des formulations qui n'étaient pas présentes dans la page, ce qui est risqué lorsque l'extrait est utilisé comme preuve plutôt que comme réponse finale. La latence et les coûts impliqués rendent la génération encore moins souhaitable.

Au contraire, nous définissons notre tâche comme une compression extractive sensible aux requêtes : séparer les parties utiles du contexte extrait des parties distrayantes. Plus précisément, notre modèle doit accepter une requête et un résultat candidat, et décider quels intervalles préserver — ceux qui soutiennent le mieux la requête — et lesquels abandonner — le reste. La sortie du modèle préserve le texte source plutôt que de le réécrire. Le résultat est ainsi plus facile à citer, à vérifier et moins coûteux à transmettre en aval.

Par exemple, considérez cette requête et ce résultat extrait :

Agrandir

Une sortie de modèle plausible consisterait à sélectionner la phrase en gras : « Dans Comet, l'assistant peut... ».

Notre approche suit la même idée générale que les travaux antérieurs sur la compression de contexte tels que FliCo, Provence et LooComp, adaptés pour la génération d'extraits dans un système de recherche en production. Fait important, le modèle fonctionne comme une étape de précision après notre étape de récupération brute. Comme indiqué dans notre précédent article de recherche Perplexity, Présentation de l'API de recherche Perplexity, nous concevons nos systèmes de recherche pour fonctionner nativement au niveau du sous-document ou de l'extrait, ce qui nous permet déjà d'équilibrer assez bien la précision et le rappel. L'introduction d'un modèle de compression de contexte sensible aux requêtes pousse la frontière de Pareto de la précision et du rappel encore plus loin.

Conception et entraînement d'un modèle de compression de contexte

Nous développons notre modèle en gardant à l'esprit trois considérations principales : la compréhension conjointe de la requête et du contexte, la sélection granulaire au niveau des phrases, et l'efficacité pour respecter un budget de latence extrêmement serré.

Architecture du modèle

Nous utilisons un modèle pplx-diffusion comme base. Il s'agit de la même famille de modèles que celle qui se cache derrière pplx-embed-v1, et tant nos travaux académiques antérieurs, Diffusion-Pretrained Dense and Contextual Embeddings, que nos repères de production confirment qu'il s'agit d'un encodeur bidirectionnel robuste pour les paires requête-contexte. L'une des propriétés clés de cette famille de modèles est le contexte bidirectionnel : chaque représentation de jeton peut analyser l'ensemble de la requête et le contexte candidat complet avant que le modèle ne décide ce qui doit être conservé.

En plus de cette base, nous entrainons une tête de compression légère qui prédit quelles parties du contexte doivent être conservées. Aucune génération n'étant impliquée, ces prédictions sont faites en parallèle sur l'ensemble du contexte. Au moment de la diffusion, le moteur d'extraits agrège ces prédictions au niveau de la phrase, applique un seuil et réduit le résultat au budget de jetons demandé.

Pipeline de supervision

L'entraînement de ce compresseur nécessite une supervision au bon niveau de granularité. Une étiquette de pertinence au niveau du document est manifestement inadaptée à notre tâche de compression extractive. Pour générer des données suffisamment granulaires pour l'apprentissage supervisé, nous avons construit un pipeline de marquage d'intervalles qui repère les intervalles de données probantes pertinents pour la requête, ainsi que les intervalles perturbateurs qui doivent être supprimés.

Notre pipeline utilise une configuration de grand modèle de langage (LLM) en tant qu'arbitre. Étant donné une requête d'utilisateur et une page Web candidate avec son lien, son titre et son résumé, l'arbitre effectue d'abord une analyse de la requête, en analysant cette dernière et en produisant une liste d'intentions possibles de l'utilisateur. En s'appuyant sur ces intentions, l'arbitre traite ensuite le contexte candidat et renvoie des intervalles copiés mot pour mot du texte, avec une catégorie pour chaque intervalle afin de faciliter l'inspection des étiquettes.

Nous avons ensuite fait correspondre les intervalles renvoyés avec le texte source. Sans surprise, la plupart des sorties de l'arbitre étaient déjà des copies exactes : la correspondance de chaînes naïve a permis de récupérer 98 % des intervalles. L'ajout d'une simple passe de correspondance basée sur les expressions régulières a porté la récupération des intervalles à 100 %. Cela nous a fourni des intervalles fiables et granulaires qui ont pu être convertis en une supervision de conservation/suppression au niveau des jetons.

Nous avons évalué ce pipeline de supervision à l'aide d'un petit ensemble de données sélectionnées avec des intervalles étiquetés manuellement, en comparant des modèles d'arbitrage plus petits, différentes invites et différentes configurations d'étapes. La configuration la plus performante était un pipeline en deux étapes : d'abord la compréhension de la requête, suivie du marquage des intervalles par catégorie. Nous avons également validé l'ensemble des intervalles extraits par le biais d'évaluations vérifiables en aval telles que BrowseComp et SimpleQA, où l'utilisation des seuls intervalles de preuves conservés a permis de préserver des scores élevés tout en réduisant considérablement les jetons d'entrée.

À l'aide de ce pipeline, nous avons étiqueté 750 000 paires requête-document et utilisé les intervalles résultants pour entraîner la tête de compression avec une entropie croisée binaire. Ce processus permet à notre modèle de compression sensible aux requêtes de garder le texte source intact tout en supprimant le contexte qui a peu de chances d'aider le modèle en aval à répondre à la demande de l'utilisateur.

Garantie d'une latence en temps réel

La compression de contexte se situe en amont du modèle en aval, ce qui en fait une opération bloquante. De plus, chaque compression dépend de la requête. Par conséquent, le parcours en ligne doit évaluer les paires requête-contexte pour chaque document candidat dans le cadre d'une enveloppe de latence rigoureuse. Un modèle de compression lent est contre-productif, car les avantages en termes de latence découlant d'une plus grande précision sont effacés par la latence de la compression elle-même. En même temps, un modèle de compression moins intelligent prendra de moins bonnes décisions quant aux éléments à couper et à conserver.

La question pratique est de savoir quelle quantité de capacité du modèle nous pouvons supprimer en toute sécurité avant que la qualité de la compression ne commence à se dégrader. Nous comparons la base complète pplx-diffusion à 28 couches avec des variantes à 11 et 17 couches obtenues par élagage de couches et ciblées sur le chemin de recherche. Pour chacune d'elles, nous balayons le seuil de compression et mesurons deux grandeurs : le nombre moyen de jetons de contexte envoyés en aval par requête, et la fraction de données probantes utiles préservées après la compression.

La figure 2 présente la frontière entre qualité et efficacité. Un modèle est meilleur lorsqu'il se déplace vers le haut et vers la gauche : moins de jetons en aval avec plus de preuves utiles préservées. Le modèle à 28 couches sert de référence de qualité. Le modèle à 11 couches illustre les risques d'une compression trop agressive du modèle. Le modèle à 17 couches élagué représente un juste milieu : il suit de près le modèle à 28 couches dans le régime saturé, mais un léger écart apparaît dans la partie abrupte de la courbe où s'exerce l'essentiel du trafic de production.

Pour combler cet écart, nous employons la distillation des connaissances au niveau des jetons. Notre approche est classique : nous enrichissons la perte standard avec un terme d'entropie croisée douce sur les prédictions du modèle enseignant, pondéré par un coefficient de distillation. Cela suffit pour amener le modèle étudiant à parité, ce qui nous permet de passer entièrement au modèle distillé à 17 couches en production. Ce nouveau modèle de production génère une diminution de 35 à 40 % de la latence d'inférence et de 40 à 45 % du calcul global par processeur graphique (GPU) sans baisse de qualité par rapport au professeur à 28 couches. La latence en production s'établit à moins de 20 ms (p99) : un résultat suffisamment faible pour être ajouté au chemin de service tout en réduisant considérablement le nombre total de jetons transmis au modèle de réponse.

Agrandir

Qualité et efficacité des jetons

Nous utilisons l'API d'agent de Perplexity comme banc d'essai pour analyser l'efficacité de la compression de contexte. Nous évaluons trois préréglages d'API d'agent :

Un préréglage de contexte « faible » qui limite le budget de jetons pour chaque ensemble de résultats à 1 000 jetons.

Un préréglage de contexte « moyen » qui limite le budget de jetons pour chaque ensemble de résultats à 4 000 jetons.

Un préréglage de contexte « élevé » qui limite le budget de jetons pour chaque ensemble de résultats à 10 000 jetons.

Les paramètres standard, sans compression et avec compression, sont tous configurés pour respecter ces budgets de jetons.

Recherche multi-étape orientée agent (BrowseComp)

Nous examinons d'abord l'impact de la compression sur les flux de travail de recherche multi-étape orientés agent sur le banc d'essai BrowseComp. Nous effectuons cette évaluation à l'aide de notre outil open source search_evals. La notation est identique pour toutes les exécutions, en utilisant l'invite d'arbitre LLM BrowseComp canonique d'OpenAI.

Les deux dimensions d'intérêt sont la précision du banc d'essai et l'utilisation des jetons. Fait important, nous mesurons l'utilisation des jetons au niveau de la requête plutôt qu'au niveau de l'étape individuelle afin de mesurer la charge réelle en jetons encourue tout au long du cycle de vie de la requête. La figure 3 montre la frontière « score-jeton », soit le score de précision par rapport à l'utilisation des jetons.

Agrandir

La compression offre une nouvelle frontière de Pareto sur toute la ligne. Pour chaque paramètre, l'introduction de la compression réduit l'utilisation des jetons au niveau de la requête de 10 % à 70 %, avec des gains de précision compris entre 4 et 4,81 points de pourcentage. L'introduction de la compression permet même à notre préréglage « faible » de surpasser le préréglage « élevé » sans compression, tout en réduisant l'utilisation des jetons de plus de trois fois.

Nous observons qu'avec la compression, le paramètre « élevé » génère une plus grande précision que le paramètre « moyen », comme on pouvait s'y attendre. Il est intéressant de noter, cependant, qu'il y parvient avec une utilisation moindre de jetons. Cela révèle un effet subtil mais important de la compression : avec la compression, même l'augmentation de la taille du contexte par étape peut permettre au modèle d'effectuer moins d'étapes pour arriver au résultat correct. L'exploration de cette non-monotonie est une voie prometteuse pour les travaux futurs.

SimpleQA : factualité en une seule étape

BrowseComp met l'accent sur la recherche multi-étape, mais de nombreux flux de travail de production impliquent une recherche factuelle en une seule étape. Pour déterminer si la compression aide également dans le régime à étape unique, nous examinons également les performances sur SimpleQA, un banc d'essai comprenant 4 326 questions auxquelles il faut répondre en une seule étape de recherche, plutôt que dans une boucle d'agent.

Comme précédemment, nous représentons graphiquement la précision par rapport au nombre total moyen de jetons par tâche en utilisant l'invite d'arbitre canonique. La figure 4 montre la frontière score-jeton dans ce cadre à étape unique. Bien que les tailles d'effet soient plus réduites dans le cadre à étape unique, nous observons à nouveau que la compression améliore simultanément la précision et l'efficacité pour tous les préréglages, introduisant ainsi une nouvelle frontière de Pareto. Avec la compression activée, le préréglage moyen atteint une précision de 95 % avec une moyenne de seulement 200 jetons par document. Étant donné que la longueur moyenne des documents dépasse 10 000 jetons, cela représente des performances de pointe à un taux de compression supérieur à 50.

Agrandir

Qu'est-ce qui se retrouve dans les extraits ?

Les gains en aval des sections 4.1 et 4.2 sont de bout en bout. Pour comprendre comment la compression modifie les extraits individuels, nous menons une évaluation distincte qui utilise un arbitre LLM pour classer chaque jeton de chaque extrait récupéré dans l'une des six catégories suivantes :

Vital : éléments probants essentiels pour répondre à la requête de l'utilisateur.

Hors sujet : informations qui peuvent être utiles à d'autres fins mais qui ne sont pas liées à la requête en cours.

Annonces : publicité non pertinente qui détourne l'attention de la réponse à la requête de l'utilisateur.

Métadonnées : métadonnées concernant le contenu du document.

Interface utilisateur et navigation : éléments d'affichage frontal et de navigation.

Doublon : répétition d'informations précédemment intégrées.

Notre évaluation porte sur 1 000 requêtes de domaines mixtes provenant de notre ensemble de validation, comparant la pile de production à une référence par ailleurs identique avec la compression désactivée. Comme le montre la figure 5, la compression augmente la proportion de jetons vitaux par extrait de 63 % en moyenne par rapport à la référence sans compression. Nous observons une diminution correspondante de 29 % des jetons non pertinents, avec des baisses particulièrement marquées dans l'interface utilisateur/navigation (-58 %), les métadonnées (-46 %) et les annonces (-43 %). Ces résultats confirment le mécanisme des améliorations de la qualité et de l'efficacité discutées ci-dessus : la compression améliore les performances dans les deux dimensions en augmentant fortement le rapport signal sur bruit de chaque extrait individuel.

Agrandir

La figure 6 illustre ce changement pour une requête individuelle. Pour la requête « 6 day old newborn milk intake per feeding », nous présentons à la fois les extraits non compressés (de référence) et les extraits compressés. La compression élimine les catégories de contenu non vital et ne conserve que les informations relatives à l'alimentation du nouveau-né. Fait important, la compression élimine avec succès le contenu qui peut être généralement pertinent pour la page, mais hors sujet pour cette requête spécifique axée sur le nouveau-né.

Agrandir

Conclusion

Les systèmes d'IA s'appuient sur des informations à signal élevé pour répondre aux demandes des utilisateurs de manière intelligente et efficace. Ces informations doivent être présentées de la manière la plus chirurgicale possible afin de maximiser la pertinence par rapport à chaque requête. Nos nouveaux modèles de compression sensibles aux requêtes font précisément cela en maximisant les données probantes pertinentes par extrait et en éliminant agressivement les éléments perturbateurs non pertinents.

En déployant ces nouveaux modèles au sein de notre pile de recherche, nous sommes en mesure de fournir des réponses plus rapides et de meilleure qualité à ceux qui utilisent nos produits et nos API. Notre approche crée une surface de contrôle simple, permettant à nos systèmes et aux clients de nos API d'ajuster le degré de compression pour trouver un équilibre entre le rappel, la latence et le coût.

La conservation du contexte est un domaine en plein développement, et il reste encore beaucoup à faire pour optimiser la valeur de chaque jeton utilisé dans les systèmes d'intelligence de pointe d'aujourd'hui. Nous travaillons activement à l'amélioration de nos techniques de conservation du contexte, tant par des améliorations de modèles que par l'architecture des systèmes, afin d'utiliser ces modèles de manière encore plus étendue.

Références

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

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

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

Citation

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