Compression de contexte sensible à la requête pour de meilleurs extraits

Toute réponse repose sur des éléments de preuve. Dans un système de recherche, ces éléments proviennent généralement de documents : titres, résumés, segments et extraits transmis en tant que 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 requête de l'utilisateur, mais aussi des éléments perturbateurs. Ces éléments peuvent apparaître aussi bien dans le corps principal que dans des éléments annexes, tels que les textes de navigation, les publicités non pertinentes, les métadonnées, et plus encore. La transmission de ces éléments à un agent en aval engendre trois problèmes.

Premièrement, cela nuit à la précision. Même les modèles les plus puissants ont une capacité limitée. Les longs flux d'informations non pertinentes gaspillent la capacité du modèle, entraînant une « dégradation du contexte » qui altère la capacité du modèle à répondre à la demande réelle de l'utilisateur. En conséquence, la réponse finale est plus susceptible d'omettre des faits essentiels, de surpondérer des informations de faible qualité ou de formuler des affirmations difficiles à étayer par la source.

Deuxièmement, cela affecte la latence. Un contexte plus long signifie davantage de jetons à traiter pour le modèle en aval, surtout lorsqu'une requête nécessite des preuves issues 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 gérer le contexte non pertinent.

Troisièmement, cela augmente les coûts. Chaque jeton inutile transmis au modèle rend le traitement de la requête de l'utilisateur plus onéreux, car l'utilisation des jetons d'entrée et de raisonnement augmente avec un contexte plus bruyant. Les éléments perturbateurs ne réduisent pas seulement la qualité ; ils finissent par vous contraindre à payer davantage pour cette qualité inférieure.

Figure 1. Le contexte brut récupéré contient souvent la réponse entourée de texte non pertinent. Les preuves utiles sont présentes, mais elles sont enfouies parmi les en-têtes, pieds de page, textes passe-partout, métadonnées et contenus hors sujet avant que le modèle de réponse ne les visualise.

Pour améliorer simultanément la précision, la vitesse et la rentabilité des applications de Perplexity et de la API Platform, nous investissons massivement dans l'amélioration de la précision du contexte. L'une de nos méthodes consiste à perfectionner 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 tirent aucun avantage de résumés généralisés ou d'extraits de documents. Ils ont plutôt besoin de la plus petite fraction d'information source, extraite chirurgicalement, pour répondre à la requête de l'utilisateur. Tout le reste peut et doit être supprimé.

Un bon extrait doit donc accomplir trois choses :

Favoriser la précision en présentant les preuves 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 LLM.

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

Ce mois-ci, nous avons déployé un nouveau générateur d'extraits de pointe au sein de nos applications et de notre API Platform. Au cœur de ce module se trouve un modèle de compression de contexte sensible à la requête qui décide, pour chaque requête et chaque résultat candidat, du sous-ensemble d'intervalles qui doit être conservé. Cet article décrit notre approche pour construire et entraîner le modèle afin d'atteindre des performances optimales pour cette tâche critique.

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

Les méthodes d'extraction se divisent en deux grandes familles. La première est fondé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 fondée sur la génération : demander à un modèle de rédiger un résumé ciblé sur la requête à partir de la page.

Notre priorité accordée à la précision, à la latence et au coût rend le choix de conception évident. Nous pouvons exclure la génération, car la création d'un nouveau résumé pour chaque page nuit aux performances sur ces trois axes. La synthèse ne convient pas à la couche de preuve qui nous intéresse. Elle peut paraphraser la source, rendant l'alignement des citations plus complexe. Elle peut également introduire un libellé absent de la page, ce qui est risqué lorsque l'extrait est utilisé comme preuve plutôt que comme réponse finale. La latence et le coût induits rendent la génération encore moins acceptable.

Nous définissons plutôt notre tâche comme une compression extractive sensible à la requête : séparer les parties utiles du contexte récupéré des parties distrayantes. Plus précisément, notre modèle doit accepter une requête et un résultat candidat, et décider quels segments conserver — ceux qui soutiennent le mieux la requête — et lesquels éliminer — le reste. La sortie du modèle préserve le texte source plutôt que de le réécrire. Cela facilite la citation, la vérification et la transmission en aval à moindre coût.

Par exemple, considérons cette requête et ce résultat récupéré :

La compression extractive sensible à la requête conserve la phrase source pertinente pour la requête et supprime le contexte sans rapport.

Une sortie plausible du modèle 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 à la génération d'extraits dans un système de recherche en production. Il est important de noter que le modèle fonctionne comme une étape de précision après notre phase de récupération brute. Comme nous l'avons discuté dans notre précédent article de recherche Perplexity, Présentation de l'API de recherche Perplexity, nous concevons nos systèmes de récupération pour qu'ils fonctionnent nativement au niveau du sous-document, ou 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 à la requête déplace encore davantage la frontière de Pareto précision-rappel.

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

Nous utilisons un modèle pplx-diffusion comme base. Il s'agit de la même famille de modèles que pplx-embed-v1, et nos travaux académiques antérieurs, Diffusion-Pretrained Dense and Contextual Embeddings, ainsi que nos benchmarks 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 prendre en compte l'intégralité de la requête et le contexte candidat complet avant que le modèle ne décide ce qui doit être conservé.

Au-dessus de cette base, nous entraînons une tête de compression légère qui prédit quelles parties du contexte doivent être conservées. Comme aucune génération n'est impliquée, ces prédictions sont effectuées 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 ajuste le résultat au budget de jetons demandé.

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 d'étiquetage d'intervalles qui marque les segments de preuves pertinents pour la requête, ainsi que les segments perturbateurs qui doivent être supprimés.

Notre pipeline utilise une configuration LLM-as-a-judge (LLM en tant qu'arbitre). Étant donné une requête utilisateur et une page web candidate avec son lien, son titre et son résumé, l'arbitre effectue d'abord une compréhension de la requête, analyse la requête et produit une liste d'intentions possibles de l'utilisateur. En s'appuyant sur ces intentions, l'arbitre traite ensuite le contexte candidat et renvoie des segments copiés mot à mot du texte, avec une catégorie pour chaque segment afin de faciliter l'inspection des étiquettes.

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

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

Grâce à ce pipeline, nous avons étiqueté 750 000 paires requête-document et utilisé les segments 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 à la requête de conserver intact le texte source tout en supprimant le contexte peu susceptible d'aider le modèle en aval à répondre à la demande de l'utilisateur.

La compression de contexte se situe avant le 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 chemin en ligne doit noter les paires requête-contexte pour chaque document candidat dans une enveloppe de latence exigeante. Un modèle de compression lent est contre-productif, car les avantages de latence issus d'une plus grande précision sont annulés par la latence de compression elle-même. Parallèlement, un modèle de compression moins intelligent prendra des décisions moins pertinentes sur ce qu'il faut couper et conserver.

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

La Figure 2 montre la frontière qualité-efficacité. Un modèle est meilleur lorsqu'il se déplace vers le haut à gauche : moins de jetons en aval avec plus de preuves utiles conservées. Le modèle à 28 couches fournit la référence de qualité. Le modèle à 11 couches démontre les risques d'une compression trop agressive du modèle. Le modèle élagué à 17 couches 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 s'ouvre dans la partie abrupte de la courbe où s'effectue la plupart du trafic de production.

Pour combler cet écart, nous employons la distillation de connaissances au niveau du jeton. Notre approche est classique : nous augmentons 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 à mettre le modèle élève à parité, nous permettant 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 GPU agrégé, sans baisse de qualité par rapport à l'enseignant de 28 couches. La latence en production est inférieure à 20 ms (p99) : suffisamment faible pour être ajoutée au chemin de diffusion tout en réduisant considérablement le nombre total de jetons transmis au modèle de réponse.

Figure 2. Performance de compression selon diverses profondeurs de modèle. L'élève distillé à 17 couches, notre modèle de production, égale l'enseignant à 28 couches en termes de performances de compression pour tous les seuils, avec un coût de calcul en ligne inférieur.

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

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.

Nous examinons d'abord l'impact de la compression sur les flux de travail de recherche multi-étapes agentiques sur le benchmark BrowseComp. Nous effectuons cette évaluation en utilisant notre harnais open-source search_evals. La notation est identique pour toutes les exécutions, en utilisant le prompt d'arbitre LLM BrowseComp canonique d'OpenAI.

Les deux dimensions d'intérêt sont la précision du benchmark et l'utilisation des jetons. Il est important de noter que 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 de jetons encourue tout au long du cycle de vie de la requête. La Figure 3 montre la frontière « score-jeton », score de précision par rapport à l'utilisation des jetons.

Figure 3. Frontière score-jeton sur BrowseComp. Les points situés en haut représentent une précision plus élevée, tandis que les points situés à gauche représentent une plus grande efficacité. La compression améliore la frontière de Pareto pour tous les préréglages. Les lignes horizontales pointillées représentent les systèmes de recherche hors Perplexity, incluant les benchmarks parallèles. GPT-5.5 alimente la boucle de l'agent.

La compression offre une nouvelle frontière de Pareto dans tous les domaines. 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 par plus de trois fois.

Nous observons qu'avec la compression, le préréglage « élevé » produit une plus grande précision que le « moyen », comme on pouvait s'y attendre. Il est intéressant de noter, cependant, qu'il le fait 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. Explorer cette non-monotonie est une direction prometteuse pour les travaux futurs.

BrowseComp met l'accent sur la recherche multi-étapes, pourtant 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 en une seule étape, nous examinons aussi les performances sur SimpleQA, un benchmark comprenant 4 326 questions auxquelles répondre en une seule étape de recherche, plutôt que dans une boucle agentique.

Comme précédemment, nous tracons la précision par rapport au nombre total moyen de jetons par tâche en utilisant le prompt d'arbitre canonique. La Figure 4 montre la frontière score-jeton dans ce cadre à une seule étape. Bien que les effets soient plus compressés dans ce cadre, 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 95 % de précision avec une moyenne de seulement 200 jetons par document. Étant donné la longueur moyenne des documents supérieure à 10 000 jetons, cela représente une performance de niveau frontière à un taux de compression supérieur à 50.

Figure 4. Frontière score-jeton sur SimpleQA. Les points situés en haut représentent une précision plus élevée, tandis que les points situés à gauche représentent une plus grande efficacité. La compression améliore la frontière de Pareto pour tous les préréglages. Les lignes horizontales pointillées représentent les systèmes de recherche hors Perplexity, incluant les évaluations de l'API Exa.

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 effectuons une évaluation séparée qui utilise un arbitre LLM pour classer chaque jeton de chaque extrait récupéré dans l'une des six catégories :

Vital : preuve essentielle pour répondre à la requête de l'utilisateur.

Hors sujet : information pouvant être utile à une autre fin mais sans rapport avec la requête en cours.

Publicités : publicité non pertinente distrayant de la réponse à la requête de l'utilisateur.

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

Interface et navigation : éléments pour l'affichage frontal et la navigation.

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

Notre évaluation porte sur 1 000 requêtes de domaines mixtes issues de notre ensemble de validation, comparant la pile de production à une base de 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 base de 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/navigation (-58 %), les métadonnées (-46 %) et les publicités (-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 sur les deux dimensions en augmentant nettement le rapport signal sur bruit de chaque extrait individuel.

Figure 5. Modification de la composition des jetons par extrait due à la compression, moyennée sur 1 000 requêtes. La proportion de contenu vital augmente, avec des diminutions correspondantes dans les catégories de contenu non vital.

La Figure 6 illustre ce changement pour une requête individuelle. Pour la requête « apport de lait par tétée pour un nouveau-né de 6 jours », nous montrons à la fois les extraits non compressés, de base et compressés. La compression élimine les catégories de contenu non vital et ne conserve que les informations relatives à l'alimentation du nouveau-né. Il est important de noter que la compression élimine avec succès le contenu qui pourrait être globalement pertinent pour la page, mais hors sujet pour cette requête spécifique axée sur le nouveau-né.

Figure 6. Extraits émis par la référence sans compression, en haut, et la pile compressée, en bas, pour un exemple de paire requête-document. La compression ne conserve que les 19 % premiers de l'extrait de base, supprimant les 81 % restants comme non pertinents.

Les systèmes d'IA s'appuient sur des informations à fort signal pour répondre intelligemment et efficacement aux requêtes des utilisateurs. Ces informations doivent être présentées aussi chirurgicalement que possible afin de maximiser la pertinence pour chaque requête. Nos nouveaux modèles de compression sensibles à la requête font précisément cela en maximisant les preuves sur le sujet 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 meilleures à ceux qui s'appuient sur nos produits et API. Notre approche crée une surface de contrôle simple, permettant à nos systèmes et clients API d'ajuster le degré de compression pour équilibrer le rappel, la latence et le coût.

La curation de contexte est un domaine en plein développement, et il reste beaucoup à faire pour optimiser la valeur de chaque jeton utilisé au sein des systèmes d'intelligence de pointe actuels. Nous travaillons activement à améliorer nos techniques de curation de contexte grâce à la fois à des améliorations du modèle et à l'architecture système pour faire un usage encore plus étendu de ces modèles.

N. Chirkova, T. Formal, V. Nikoulina, et S. Clinchant. Provence : Élagage de contexte efficace et robuste pour la génération augmentée par récupération, 2025. Accepté à l'ICLR 2025. arXiv:2501.16214.

T. Do, D. P. Tran, A. Vo, S. K. Kim, et D. Kim. LooComp : tirer parti de la stratégie « laisser-un-dehors » vers un transformateur uniquement encodeur pour une compression de contexte efficace sensible à la requête, 2026. arXiv:2603.09222.

S. Eslami, M. Gaiduk, M. Krimmel, L. Milliken, B. Wang, et D. Bykov. Plongements denses et contextuels pré-entraînés par diffusion, 2026. arXiv:2602.11151.

Z. Wang, J. Araki, Z. Jiang, M. R. Parvez, et G. Neubig. Apprendre à filtrer le contexte pour la génération augmentée par récupération, 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://www.perplexity.ai/hub/blog/query-aware-context-compression-for-better-snippets}
}

Les extraits en tant que compression sensible à la requête

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

Architecture du modèle

Pipeline de supervision

Assurer une latence en temps réel

Qualité et efficacité des jetons

Recherche multi-étapes agentique (BrowseComp)

SimpleQA : exactitude en une seule étape

Qu'est-ce qui finit dans les extraits ?

Conclusion

Références

Citation