Query-bewuste contextcompressie voor betere fragmenten

Elk antwoord begint met bewijs. In een zoeksysteem is dit bewijs doorgaans afkomstig van documenten: titels, samenvattingen, tekstblokken en fragmenten die als context aan een antwoordmodel of agent worden doorgegeven.

Deze ruwe context bevat ruis. Een webpagina kan bijvoorbeeld informatie bevatten die nodig is voor het verzoek van de gebruiker, maar kan ook afleidende elementen bevatten. Deze afleidende elementen kunnen zowel in de hoofdtekst als in ondersteunende elementen voorkomen, zoals navigatietekst, irrelevante advertenties, metagegevens en meer. Het doorgeven van deze afleidende elementen aan een downstream-agent veroorzaakt drie problemen.

Ten eerste schaadt het de nauwkeurigheid. Zelfs de krachtigste modellen hebben een beperkte capaciteit. Lange reeksen irrelevante informatie verspillen de capaciteit van het model, wat resulteert in "contextrot" die het vermogen van een model om het daadwerkelijke verzoek van de gebruiker te adresseren, belemmert. Als gevolg hiervan is de kans groter dat het uiteindelijke antwoord belangrijke feiten mist, minderwaardige informatie te zwaar laat meewegen of claims produceert die moeilijker te onderbouwen zijn met de bron.

Ten tweede zorgt het voor extra latentie. Een langere context betekent meer tokens die het downstream-model moet verwerken, vooral wanneer een zoekopdracht bewijs nodig heeft uit vele kandidaat-pagina's. Hoewel een deel van deze latentiekosten wordt gedragen tijdens de prefill-fase, worden aanzienlijk hogere kosten betaald tijdens het redeneren, omdat modellen meer redeneertokens nodig hebben om om te gaan met irrelevante context.

Ten derde verhoogt het de kosten. Elk onnodig token dat aan het model wordt doorgegeven, maakt het duurder om het verzoek van de gebruiker te bedienen, aangezien zowel het gebruik van invoertokens als redeneertokens toeneemt bij een context met meer ruis. Afleidende elementen verminderen niet alleen de kwaliteit; ze dwingen u uiteindelijk om meer te betalen voor die lagere kwaliteit.

Vergroten

Om de nauwkeurigheid, snelheid en kosteneffectiviteit van Perplexity's applicaties en API Platform tegelijkertijd te verbeteren, investeren we zwaar in de verfijning van contextprecisie. Een manier waarop we dit doen is door onze algoritmen voor fragmentgeneratie te verfijnen. We beschouwen fragmentgeneratie als een probleem van contextcompressie. Modellen die op zoek zijn naar specifieke informatie hebben geen baat bij algemene samenvattingen of uittreksels van een document. Ze hebben daarentegen het kleinste, meest chirurgisch geëxtraheerde stukje broninformatie nodig om op het verzoek van de gebruiker te reageren. Al het andere kan en moet worden verwijderd.

Een goed fragment zou daarom drie dingen moeten doen:

De nauwkeurigheid bevorderen door het precieze bewijs te presenteren dat nodig is om het antwoord van het model te onderbouwen.

Latentie en kosten verlagen door irrelevante context te verwijderen vóór de LLM-aanroep.

Traceerbaarheid waarborgen door de getrouwheid van citaten te behouden en de formulering van de bron intact te laten.

Deze maand hebben we een nieuwe, state-of-the-art fragmentgenerator ingezet binnen onze applicaties en ons API Platform. De kern van deze module is een query-bewust contextcompressiemodel dat voor elke zoekopdracht en elk kandidaatresultaat bepaalt welke subset van tekstfragmenten behouden moet blijven. Dit artikel beschrijft onze aanpak voor het bouwen en trainen van het model om topprestaties te behalen bij deze kritieke taak.

Fragmenten als query-bewuste compressie

De eerste prioriteit is om de taak zelf te definiëren. Wat willen we dat dit model doet en hoe moeten we het invoer- en uitvoerschema definiëren?

Methoden voor fragmenten vallen uiteen in twee brede categorieën. De eerste is gebaseerd op selectie: zoek een relevant venster, blok, zin of passage en geef dit door aan het downstream-proces. De tweede is gebaseerd op generatie: vraag een model om een zoekopdrachtgerichte samenvatting van de pagina te schrijven.

Onze focus op nauwkeurigheid, latentie en kosten maakt de ontwerpkeuze duidelijk. We kunnen generatie uitsluiten, aangezien het maken van een nieuwe samenvatting voor elke pagina de prestaties op alle drie de focuspunten schaadt. Samenvatting is minder geschikt voor de bewijzellaag waar wij ons op richten. Het kan de bron parafraseren, waardoor citatie-afstemming moeilijker wordt. Het kan ook formuleringen introduceren die niet in de pagina aanwezig waren, wat riskant is wanneer het fragment wordt gebruikt als bewijs in plaats van als het uiteindelijke antwoord. De latentie en kosten die hiermee gepaard gaan, maken generatie nog onaantrekkelijker.

We definiëren onze taak liever als query-bewuste extractieve compressie: het scheiden van de nuttige delen van de opgehaalde context van de afleidende delen. Specifiek moet ons model een zoekopdracht en kandidaatresultaat accepteren en beslissen welke fragmenten behouden moeten blijven, namelijk die welke de zoekopdracht het best ondersteunen, en welke verwijderd moeten worden, namelijk de rest. De modeluitvoer behoudt de brontekst in plaats van deze te herschrijven. Dit maakt het resultaat gemakkelijker te citeren, gemakkelijker te verifiëren en goedkoper om door te geven aan het downstream-proces.

Beschouw bijvoorbeeld deze zoekopdracht en het opgehaalde resultaat:

Vergroten

Een aannemelijke modeloutput zou zijn om de vetgedrukte zin te selecteren: “In Comet kan de assistent ...”.

Onze aanpak volgt hetzelfde brede idee als eerder werk op het gebied van contextcompressie, zoals FliCo, Provence en LooComp, aangepast voor fragmentgeneratie in een productiesysteem voor zoekopdrachten. Belangrijk is dat het model werkt als een precisiefase na onze ruwe ophaalfase. Zoals besproken in ons vorige Perplexity Research-artikel, Introductie van de Perplexity Search API, ontwerpen we onze ophaalsystemen om native te werken op het niveau van sub-documenten, of fragmenten, wat ons al in staat stelt om precisie en recall redelijk goed in balans te brengen. Het introduceren van een query-bewust contextcompressiemodel verschuift de Pareto-grens van precisie en recall nog verder naar buiten.

Bouwen en trainen van een contextcompressiemodel

We ontwikkelen ons model met drie belangrijke overwegingen in gedachten: gezamenlijk begrip van zoekopdracht en context, verfijnde selectie op zinsniveau en efficiëntie om binnen een extreem krap latentiebudget te passen.

Modelarchitectuur

We gebruiken een pplx-diffusion-model als basis. Dit is dezelfde modelfamilie achter pplx-embed-v1, en zowel ons eerdere academische werk, Diffusion-Pretrained Dense and Contextual Embeddings, als onze productiebenchmarks bevestigen dat het een sterke bidirectionele encoder is voor paren van zoekopdracht en context. Een van de belangrijkste eigenschappen van deze modelfamilie is bidirectionele context: elke tokenrepresentatie kan de volledige zoekopdracht en de volledige kandidaat-context in acht nemen voordat het model beslist wat behouden moet blijven.

Bovenop deze basis trainen we een lichtgewicht compressiehoofd dat voorspelt welke delen van de context behouden moeten blijven. Omdat er geen generatie bij betrokken is, worden deze voorspellingen parallel gemaakt over de gehele context. Tijdens de serveertijd aggregeert de fragment-engine deze voorspellingen op zinsniveau, past een drempelwaarde toe en trimt het resultaat naar het gevraagde tokenbudget.

Supervisiepijplijn

Het trainen van deze compressor vereist supervisie op het juiste granulariteitsniveau. Een relevantielabel op documentniveau is volkomen ongeschikt voor onze extractieve compressietaak. Om voldoende granulaire data voor supervised learning te genereren, hebben we een pijplijn voor het labelen van tekstfragmenten gebouwd die relevante bewijsfragmenten voor een zoekopdracht markeert, samen met afleidende fragmenten die verwijderd moeten worden.

Onze pijplijn gebruikt een LLM-as-a-judge-opstelling. Gegeven een zoekopdracht van een gebruiker en een kandidaat-webpagina met bijbehorende link, titel en samenvatting, voert de beoordelaar eerst een begrip van de zoekopdracht uit, waarbij de zoekopdracht wordt geanalyseerd en een lijst met mogelijke intenties van de gebruiker wordt gegenereerd. Gebaseerd op deze intenties verwerkt de beoordelaar vervolgens de kandidaat-context en retourneert fragmenten die letterlijk uit de tekst zijn gekopieerd, met voor elk fragment een categorie om de labels gemakkelijker te kunnen inspecteren.

Vervolgens hebben we de geretourneerde fragmenten teruggekoppeld aan de brontekst. Het is niet verrassend dat de meeste outputs van de beoordelaar al exacte kopieën waren: naïeve stringmatching herstelde 98% van de fragmenten. Het toevoegen van een eenvoudige matching-stap op basis van regex bracht het herstel van fragmenten naar 100%. Dit leverde ons betrouwbare, granulaire fragmenten op die konden worden omgezet in supervisie voor het behouden/verwijderen op token-niveau.

We hebben deze supervisiepijplijn geëvalueerd met behulp van een kleine gecureerde dataset met handmatig gelabelde fragmenten, waarbij we kleinere beoordelaarmodellen, verschillende prompts en verschillende configuraties van stappen vergeleken. De best presterende opstelling was een pijplijn in twee fasen: eerst begrip van de zoekopdracht, gevolgd door gecategoriseerde labeling van fragmenten. We hebben de set geëxtraheerde fragmenten ook gevalideerd door middel van downstream verifieerbare evaluaties zoals BrowseComp en SimpleQA, waarbij het gebruik van alleen de behouden bewijsfragmenten sterke scores behield en tegelijkertijd het aantal invoertokens aanzienlijk verminderde.

Met behulp van deze pijplijn hebben we 750.000 paren van zoekopdracht en document gelabeld en de resulterende fragmenten gebruikt om het compressiehoofd te trainen met binaire cross-entropy. Dit proces stelt ons query-bewuste compressiemodel in staat om brontekst intact te laten terwijl context wordt verwijderd die waarschijnlijk niet helpt bij het bedienen van het verzoek van de gebruiker door het downstream-model.

Garanderen van realtime latentie

Contextcompressie bevindt zich vóór het downstream-model, wat het een blokkerende operatie maakt. Bovendien is elke compressie afhankelijk van de zoekopdracht. Daarom moet het online pad paren van zoekopdracht en context scoren voor elk kandidaat-document binnen een strikte latentie-envelop. Een traag compressiemodel is contraproductief, aangezien de latentievoordelen van een hogere precisie teniet worden gedaan door de latentie van de compressie zelf. Tegelijkertijd zal een minder intelligent compressiemodel slechtere beslissingen nemen over wat te knippen en wat te behouden.

De praktische vraag is hoeveel modelcapaciteit we veilig kunnen verwijderen voordat de compressiekwaliteit begint af te nemen. We vergelijken de volledige pplx-diffusion-basis van 28 lagen met varianten van 11 en 17 lagen die zijn geproduceerd door laag-pruning en gericht zijn op het zoekpad. Voor elk model variëren we de compressiedrempel en meten we twee hoeveelheden: het gemiddelde aantal context-tokens dat per zoekopdracht downstream wordt verzonden en het deel van het nuttige bewijs dat na compressie behouden blijft.

Figuur 2 toont de grens van kwaliteit en efficiëntie. Een model presteert beter wanneer het naar linksboven beweegt: minder downstream-tokens met meer nuttig bewijs behouden. Het model met 28 lagen biedt de kwaliteitsreferentie. Het model met 11 lagen demonstreert de risico's van het te agressief comprimeren van het model. Het geprunede model met 17 lagen vertegenwoordigt een middenweg: het volgt het model met 28 lagen nauwgezet in het verzadigde regime, maar er ontstaat een kleine kloof in het steile deel van de curve waar het meeste productie-verkeer plaatsvindt.

Om die kloof te dichten, maken we gebruik van kennisdistillatie op token-niveau. Onze aanpak is routine: we vullen het standaard verlies aan met een soft cross-entropy term op de voorspellingen van het leraarmodel, gewogen door een distillatiecoëfficiënt. Dit is voldoende om het leerlingmodel op gelijk niveau te brengen, waardoor we volledig kunnen overschakelen naar het gedestilleerde model met 17 lagen in productie. Dit nieuwe productiemodel levert een afname van 35-40% in inferentiel latentie en 40-45% afname in totaal GPU-rekenwerk zonder kwaliteitsverlies ten opzichte van de leraar met 28 lagen. De productielatentie klokt in op minder dan 20 ms (p99): klein genoeg om toe te voegen aan het serveerpad, terwijl het totaal aantal tokens dat aan het antwoordmodel wordt doorgegeven aanzienlijk wordt verminderd.

Vergroten

Kwaliteit en token-efficiëntie

We gebruiken de Agent API van Perplexity als testbed om de effectiviteit van contextcompressie te analyseren. We evalueren drie voorinstellingen van de Agent API:

Een "lage" context-voorinstelling die het tokenbudget voor elke resultatenset beperkt tot 1000 tokens.

Een "gemiddelde" context-voorinstelling die het tokenbudget voor elke resultatenset beperkt tot 4000 tokens.

Een "hoge" context-voorinstelling die het tokenbudget voor elke resultatenset beperkt tot 10000 tokens.

Zowel de standaardinstellingen, zonder compressie, als de compressie-instellingen zijn geconfigureerd om deze tokenbudgetten te respecteren.

Agent-gebaseerde zoekopdracht in meerdere stappen (BrowseComp)

We onderzoeken eerst de impact van compressie op agent-gebaseerde zoekworkflows in meerdere stappen op de BrowseComp-benchmark. We voeren deze evaluatie uit met behulp van onze open-source search_evals-harness. De beoordeling is identiek voor alle runs, met gebruik van de canonieke BrowseComp LLM-beoordelaarsprompt van OpenAI.

De twee relevante dimensies zijn benchmark-nauwkeurigheid en tokengebruik. Belangrijk is dat we het tokengebruik op zoekopdrachtniveau meten in plaats van op het niveau van individuele stappen, om de werkelijke tokenbelasting over de levenscyclus van het verzoek te meten. Figuur 3 toont de "score-token"-grens, nauwkeurigheidsscore versus tokengebruik.

Vergroten

Compressie levert over de hele linie een nieuwe Pareto-grens. Voor elke instelling vermindert het introduceren van compressie het tokengebruik op zoekopdrachtniveau met 10% tot 70%, met nauwkeurigheidswinsten tussen 4 en 4,81 procentpunten. Door compressie te introduceren, presteert zelfs onze "lage" voorinstelling beter dan de "hoge" voorinstelling zonder compressie, terwijl het tokengebruik meer dan drievoudig wordt verminderd.

We observeren dat "hoog" met compressie een hogere nauwkeurigheid oplevert dan "gemiddeld", zoals we zouden verwachten. Interessant is echter dat dit gebeurt bij een lager tokengebruik. Dit onthult een subtiel maar belangrijk effect van compressie: met compressie kan zelfs het vergroten van de contextgrootte per stap het model in staat stellen minder stappen te nemen om tot het juiste resultaat te komen. Het onderzoeken van deze niet-monotoniciteit is een veelbelovende richting voor toekomstig werk.

SimpleQA: feitelijkheid in één stap

BrowseComp benadrukt onderzoek in meerdere stappen, maar veel productieworkflows omvatten feitelijk opzoeken in één stap. Om te bepalen of compressie ook helpt in het regime van één stap, onderzoeken we ook de prestaties op SimpleQA, een benchmark met 4.326 vragen die in één zoekstap moeten worden beantwoord, in plaats van in een agent-lus.

Zoals voorheen zetten we de nauwkeurigheid uit tegen het gemiddelde totale aantal tokens per taak met behulp van de canonieke beoordelaarsprompt. Figuur 4 toont de score-token-grens in deze instelling van één stap. Hoewel de effectgroottes in de instelling van één stap meer gecomprimeerd zijn, observeren we opnieuw dat compressie tegelijkertijd de nauwkeurigheid en efficiëntie voor alle voorinstellingen verbetert, waardoor een nieuwe Pareto-grens wordt geïntroduceerd. Met ingeschakelde compressie behaalt de gemiddelde voorinstelling een nauwkeurigheid van 95% met gemiddeld slechts 200 tokens per document. Gezien de gemiddelde documentlengte van meer dan 10.000 tokens, vertegenwoordigt dit prestaties op grens-niveau bij een compressieratio van meer dan 50.

Vergroten

Wat komt er in de fragmenten terecht?

De downstream-winsten in secties 4.1 en 4.2 zijn end-to-end. Om te begrijpen hoe compressie individuele fragmenten verandert, voeren we een afzonderlijke evaluatie uit die een LLM-beoordelaar gebruikt om elk token van elk opgehaald fragment in een van de zes categorieën in te delen:

Vitaal: bewijs dat essentieel is om de zoekopdracht van de gebruiker te beantwoorden.

Off-topic: informatie die nuttig kan zijn voor een ander doel, maar die geen betrekking heeft op de betreffende zoekopdracht.

Advertenties: irrelevante reclame die afleidt van het beantwoorden van de zoekopdracht van de gebruiker.

Metagegevens: metagegevens over de inhoud van het document.

UI & navigatie: elementen voor frontend-weergave en navigatie.

Duplicaat: herhaling van eerder opgenomen informatie.

Onze evaluatie draait op 1.000 zoekopdrachten in gemengde domeinen uit onze validatieset, waarbij de productiestack wordt vergeleken met een verder identieke baseline waarbij compressie is uitgeschakeld. Zoals weergegeven in Figuur 5, verhoogt compressie het aandeel vitale tokens per fragment met gemiddeld 63% ten opzichte van de baseline zonder compressie. We observeren een overeenkomstige afname van 29% in irrelevante tokens, met bijzonder sterke dalingen in UI/navigatie (-58%), metagegevens (-46%) en advertenties (-43%). Deze resultaten bevestigen het mechanisme voor de hierboven besproken verbeteringen in kwaliteit en efficiëntie: compressie verbetert de prestaties in beide dimensies door de signaal-ruisverhouding van elk individueel fragment scherp te verhogen.

Vergroten

Figuur 6 illustreert deze verandering voor een individuele zoekopdracht. Voor de zoekopdracht “melkinname per voeding bij pasgeborene van 6 dagen oud” tonen we zowel de ongecomprimeerde baseline-fragmenten als de gecomprimeerde fragmenten. Compressie elimineert de niet-vitale inhoudscategorieën en behoudt alleen de voedingsinformatie met betrekking tot de pasgeborene. Belangrijk is dat compressie met succes inhoud elimineert die in het algemeen misschien relevant is voor de pagina, maar niet relevant voor deze specifieke zoekopdracht gericht op pasgeborenen.

Vergroten

Conclusie

AI-systemen vertrouwen op informatie met een hoog signaal om zoekopdrachten van gebruikers intelligent en efficiënt te bedienen. Deze informatie moet zo chirurgisch mogelijk worden gepresenteerd om de relevantie voor elk verzoek te maximaliseren. Onze nieuwe query-bewuste compressiemodellen doen precies dit door het on-topic bewijs per fragment te maximaliseren en irrelevante afleidende elementen agressief te verwijderen.

Door deze nieuwe modellen binnen onze zoekstack in te zetten, kunnen we snellere en betere antwoorden bieden aan degenen die vertrouwen op onze producten en API's. Onze aanpak creëert een eenvoudig bedieningsoppervlak, waardoor onze systemen en API-klanten de mate van compressie kunnen afstemmen om een balans te vinden tussen recall, latentie en kosten.

Contextcuratie is een vakgebied in ontwikkeling en er moet nog veel meer worden gedaan om de waarde van elk token dat binnen de huidige intelligente systemen wordt gebruikt, te optimaliseren. We werken er actief aan om onze contextcuratietechnieken nog beter te maken door middel van zowel modelverbeteringen als systeemarchitectuur om nog uitgebreider gebruik te maken van deze modellen.

Referenties

N. Chirkova, T. Formal, V. Nikoulina, en S. Clinchant. Provence: Efficient and Robust Context Pruning for Retrieval-Augmented Generation, 2025. Geaccepteerd voor ICLR 2025. arXiv:2501.16214.

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

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

Citaat

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